Думаю, что из заголовка очевидно, что речь в моём посте пойдёт проблемах ванильного ядра.
Интересно, много ли активистов ЛОРа так же обеспокоены проблемой вытеснения старых модулей (особенно, не касающихся оборудования) и неприятия новых (или уже не очень), весьма (с Вашей, но не старого маразматика) важных модулей?
Не беспокоит ли Вас, что ядро теперь развивается не с упором на функционал и огромные возможности, а с точки зрения фимозга и фапания на энергопотребление?
Приведу пример: до сих пор в ванильное ядро не включены BFS, BFQ, frandom/erandom, TuxOnIce, Reiser4. При том, что часть из этих проектом либо активно поддерживаются, либо вообще не нуждаются в поддержке, т.к. не лезут во внутренности ядра.
Из ядра выкинули модуль dmrai45, из-за чего только с zen-kernel теперь можно использовать win-software RAID, а также рейды, созданные на аппаратных контроллерах, что, бесспорно, нужнее, чем NTFS in kernelspace.
При этом включается какая-то непонятная фигня для энергосбережения, и из этого делают новость года! Реально ли старный маразматик совсем решился рассудка, что корпорации зла пришлось несколько лет капать ему на мозг, чтобы он принят, таки, ИМИ разработанные и ИМИ поддерживаемые патчи?
До этого долгое время Торвальдс не шел на компромис касательно адаптации в ванильном ядре к Xen (когда Xen не был ещё настолько независим от ядра, а ядро было частично паравиртуализированным в ксене) и требовалась большая модификация ядра для работы с ним).
Так же был написан код NTFS-модуля (который нафиг не нужен, т.к. для внешнего харда с порнухой и FUSE нормально работает, а серверах только ССЗБ будут ставить NTFS). Вместо того, чтобы поддержать портирование ZFS в актуальном состоянии, я уже не говорю о том, что вместо покупки ещё одной спортивной машины работники фонда могли оплатить системых программистов для вытаскивания из могилы Reiser4, который даже сейчас бьёт по производительности ext4, и который взял лучшее от ZFS, при этом не ограничивая пользователя.
До недавнего времени там не было даже элементарных RT-патчей (а многие и до сих не включены).
Не пора ли переходить к гибридной архитектуре? Сделать специальный kernel-IPC и рожать сетевой стек (особенно netfilter), cryptoAPI и прочий код в обычных процессах в непривилегированном кольце с собственной Virtual Memory, а не заниматься фимозгом, не пуская в ядро нужные вещи под предлогом раздутости ядра.
Также, я хочу заметить, что я не случайно занёс этот пост в раздел Admin, т.к. именно серверный сегмент двигает развитие важных для меня частей ядра. А в энерпрайзе zen и pf неведомо. ЕМНП!?
Подведя итог, я хотел бы сказать о том, что включение кода в ванильное ядро - это куда больше, чем Вы думаете. Если у кода уже был мейнтейнер, то у него не опустятся руки, т.к. тысячи людей будут использоваться его код и приложат все усилия, чтобы это продолжалось и впредь. Если мейтейнер умер или отказался от своего ребёнка, то этот код поддержат другие альтруисты (потому что они будут хотеть использовать его далее, мало того, он может уже быть задействован в бизнес-процессах, что вообще меняет ситуацию).
Когда же код находится в форках ядра, то интерес к нему крайне скуден, а порой его вообще некому даже поддерживать, не то, что развивать. Это связано с низкой популярностью форков, Ваш кэп.
Перемещено post-factum из admin
