Мортон: В Linux-ядре возникает все больше ошибок

[Sergey T]

Не ошибается только тот, кто ничего не делает.

[Vaganto]

ИМХО спор переходит к вопросу определения понятия "ядро" - это лишь средства распределения ресурсов или же еще и хранилище кода драйверов.

А вот это очень правильно. Действительно в любом споре начинать следует с определения терминов, иначе спорящие зачастую говорят о разных вещах. Но сама формулировка несколько не верна, на мой взгляд. Мое мнение - ядро, это некая программа работающая с ресурсами на низком уровне, и предоставляющая упомянутые ресурсы программам через неизменный интерфейс таким образом, чтобы работа программ пользователя минимально (а в идеале совсем не) зависила от типа железа системы. Но вот способ построения ядра - модульный или монолитный в это определение входить не может. И то и другое ядро. Просто разный подход. Мне кажется тут разделение "вот так сделаное это ядро, а вот так - это уже не ядро" не применим.

Несмоненно, пересборка ядра - занятие увлекательное, но я предпочел бы вместо этого поиграть с модулями, которые можно на гораздо более скромное ядро навесить без дополнительных пересборок. Тут вам и разделение и специализация труда - ядро и драйвера друг для друга являются "черными ящиками", есть стабильный интерфейс, можно гораздо проще выловить косяки, потому что размер этих независимых фрагментов позволяет ограниченной группе лиц охватить почти всю логику его выполнения.

Да. Действительно некоторые приимущества очевидны, но вот со стабильным интерфейсом мне кажется вы погорячились. При таком, как вы говорите, темпе выпуска железок интерфейс даже для одного и того же типа оборудования просто не может долгое время сохраняться неизменным. У тех же видео карт все время появляются новые возможности, о которых мы даже и не предпологали несколько лет назад. И для обеспечения доступа к ним надо изминять или как-то расширять протокол. Следовательно изменеие ядра, следовательно отладка (нестабильность). Далее неизбезно появится обычная проблема совместимости со старым. В данном случае железом/драйверами - мы ведь не знаем какие модули пользователь сейчас на данной машине включит а какие нет, а ядро вашими пожеланиями должно быть как можно менее изменяемым. И вот мы уже тащим за собой груз прошлого из версии в версию. Как сказал кто-то известный: "Все беды от совместимости."

Я не говорю что то что работает сейчас намного лучше и не обладает недостатками. Я просто хочу сказать, что идеальную схему реализовать неудастся. Всегда приходится выберать меньшее зло и потом стремиться к лучшему.
И скорее всего истина, как обычно, где-то посередине между модульным и монолитным.

ИМХО.
С уважением.

[alv]

И скорее всего истина, как обычно, где-то посередине между модульным и монолитным.

и эта истина реализована практически - и в ядре Линукс, и во FreeBSD

а вообще спор беспредметен
на любое заявление типа "Ядро Линукс должно развиваться так" (как - не важно) можно ответить двояко:
1) бери бутылку, поезжай к Линусу и уговаривай его
2) создавай свой форк - благо никто не запрещает
Потому что генеральную линию партии (пардон, ядра), менять на микроядерную вроде не собираются

PS кстати, есть ведь микроядерный Линукс
кто-нибудь щупал?

[Deus Ex Machina]

И скорее всего истина, как обычно, где-то посередине между модульным и монолитным.

и эта истина реализована практически - и в ядре Линукс, и во FreeBSD

а вообще спор беспредметен
на любое заявление типа "Ядро Линукс должно развиваться так" (как - не важно) можно ответить двояко:
1) бери бутылку, поезжай к Линусу и уговаривай его
2) создавай свой форк - благо никто не запрещает
Потому что генеральную линию партии (пардон, ядра), менять на микроядерную вроде не собираются

PS кстати, есть ведь микроядерный Линукс
кто-нибудь щупал?

Винда микроядерная? Почему драйвера для нее пишутся без изменения ядра винды и без малейших усилий со стороны микрософт? Какая разница как назвать подход, главное чтобы он был рабочим! В линухе вроде бы есть механизм динамических модулей (dcms кажется называется) но он почти не используется.

Насчет поездок с бутылкой к Линуксу и создания своего форка... 1. С бутылкой к нему я не поеду 2. Если человек создал такое коммунити и пользуется авторитетом то именно на него ложится большая отвественность. Надо найти смелость признать ошибку и перевести развитие на новый уровень. Его послушают, а меня с моим форком - нет

[alv]

Надо найти смелость признать ошибку и перевести развитие на новый уровень.

Видимо, он не считает это ошибкой
А поскольку думаю, что а) он не глупей нас с Вами, и б) в существе дела немножечно разбирается, у него есть на то основание
А вообще, в исходном для поста тексте речь шла о чисто тактическом вопросе - добавлять новые фичи или отлаживать уже включенные
Причем никто не спорит, что нужно и то, и другое, вопрос только в том, что приоритетней на данном этапе ядростроения

[phasma]

мне лично FreeBSD в последнее время больше нравится .... стабильная ОС ... и никто не кричит, что она умрет )))

[Zak_]

но!
фря не поддерживает 64х битные дрова NVIDIA
и чипсет nforce не поддерживается официально - так написано на nvidia.com

[rolano]

Да. Действительно некоторые приимущества очевидны, но вот со стабильным интерфейсом мне кажется вы погорячились. При таком, как вы говорите, темпе выпуска железок интерфейс даже для одного и того же типа оборудования просто не может долгое время сохраняться неизменным. У тех же видео карт все время появляются новые возможности, о которых мы даже и не предпологали несколько лет назад. И для обеспечения доступа к ним надо изминять или как-то расширять протокол. Следовательно изменеие ядра, следовательно отладка (нестабильность). Далее неизбезно появится обычная проблема совместимости со старым. В данном случае железом/драйверами - мы ведь не знаем какие модули пользователь сейчас на данной машине включит а какие нет, а ядро вашими пожеланиями должно быть как можно менее изменяемым. И вот мы уже тащим за собой груз прошлого из версии в версию. Как сказал кто-то известный: "Все беды от совместимости."

↑

ИМХО ядру вообще должно быть фиолетово, что у видеокарты новые возможности есть. Его задача - выделить ресурсы драйверу видюхи, а дальше пусть сам разгребает. Максимально, что для этого необходимо - поддержка шины. Если уж речь зашла о видюхах, то наткнулся как-то на одну статью (ссылку не дам - не помню) по драйверам на Винду. Народ в открытую говорит, что для ускорения работы драйвера видюхи просто аццки оптимизируются - наряду с работой посредством вызова внутренних функций практикуется прямой доступ к железке. Конечно, это все вылизывается для обеспечения нормальной работы оборудования, но в Линуксе такой подход едва ли применим: хочет драйвер видюхи послать что-то железке - пусть скажет ядру, что нужно отправить такие-то данные по в такой-то порт.

[Vaganto]

ИМХО ядру вообще должно быть фиолетово, что у видеокарты новые возможности есть. Его задача - выделить ресурсы драйверу видюхи, а дальше пусть сам разгребает. Максимально, что для этого необходимо - поддержка шины.
Если уж речь зашла о видюхах, то наткнулся как-то на одну статью (ссылку не дам - не помню) по драйверам на Винду. Народ в открытую говорит, что для ускорения работы драйвера видюхи просто аццки оптимизируются - наряду с работой посредством вызова внутренних функций практикуется прямой доступ к железке. Конечно, это все вылизывается для обеспечения нормальной работы оборудования, но в Линуксе такой подход едва ли применим: хочет драйвер видюхи послать что-то железке - пусть скажет ядру, что нужно отправить такие-то данные по в такой-то порт.

И тут мы получим либо крайне неустойчивую систему, которая будет валиться от любой ошибки в драйвере, либо, если ядро будет контролировать корректность действий драйвера - оно будет тормозить.

Хотя если честно это лишь мои представления о том что и как может получиться. Как я уже говорил - я не спец в разработке структуры ядра ОС. И если вы не разработчик ОС, то скорее всего вы тоже не знаете всех аспектов того или иного решения. Всех плюсов и минусов. В таком положении несколько самоуверенно что-либо утверждать.

Я же повторю вслед за Alv, поскольку это и мое мнение тоже - человек который в одиночку написал исходную систему, и который контролирует разработку её уже не малый срок и не за деньги, скорее всего разбирается в том что он делает. Лично я доверяю его мнению в том каким должно быть ядро ОС.

ИМХО.
С уважением.

[rolano]

человек который в одиночку написал исходную систему, и который контролирует разработку её уже не малый срок и не за деньги, скорее всего разбирается в том что он делает.

↑

В этом то весь фокус: ядро 2.0.1 - 4,5 метра, 2.2.0 - 10 метров, 2.4.0 - 19 метров, 2.6.0 - 32 метра. При построении зависимости размеров текстов ядра от времени и аппроксимации по линейной зависимости получается величина достоверности R2 равной 0,9675, по степенной - 0,9888. Расчетная величина ядра 2.8.0 - не менее 39 метров. В то же самое время возможности человека выражаются кривой с явно выраженной асимптотой, ограничивающей значения сверху - в силу физических причин человек не может контролировать слишком большие тексты. Для решения этой задачи человек привлекает других людей и делит с ними работу, но в условиях OpenSource это червато как раз ошибками, поскольку каждый смотрит на одно и то же, но видит немного разное. Если перейти на микроядро, то это позволит существенно сократить темпы его разрастания, а разработку драйверов переложить на других людей.

И тут мы получим либо крайне неустойчивую систему, которая будет валиться от любой ошибки в драйвере, либо, если ядро будет контролировать корректность действий драйвера - оно будет тормозить.

↑

ИМХО Задача драйвера - попросить выделить ему определенный диапазон портов ввода/вывода и работать по этому диапазону. Но почему драйвер должен быть так жестко связан с ядром? Более того, если посмотреть чейндж-логи, то можно обнаружить, что там собственно ошибок ядра (диспетчеризация, выделение памяти и т.д.) немного, а ошибки идут в блютузах, вай-фаях, драйверах контроллеров дисков и т.д., что при микроядерной структуре позволит вынести их за область ответственности разработчиков ядра. Единственное, за что они будут отвечать из оборудования - поддержка возможностей чипсетов и шин, которые мне не представляется возможным/целесообразным реализовать во внешних драйверах.
Что касается того, что Линус не первый год поддерживает разработку, то это несколько слабоватый аргумент. Некорректно сравнивать компанию на начальной стадии развития, когда она управляется одним человеком, и мегахолдинг, где структура управления предполагает разветвленную иерархию власти. Чем сложнее структура управления, тем выше вероятность искажения управленческого сигнала при его передаче по звеньям цепи, т.е. ошибки. В свое время с этой проблемой столкнулась Дженерал Моторз и успешно провела реструктуризацию структуры управления, выделив ряд практически самостоятельных подразделений, объединенных общей стратегией. Сейчас Линус по объективным причинам не может контролировать все и вся, он не имеет по-настоящему действенных рычагов давления на разработчиков ядра, потому что они - добровольцы. Эти добровольцы помимо некоторых общих принципов имеют собственные убеждения, предпочтения и т.д. С ростом объема ядра разработчики тоже перестают справляться со своими функциями и делегируют часть полномочий на более низкий уровень - своим помощникам. В итоге получается, что де-юре ядро поддерживает Линус, а де-факто его пишут неизвестно сколько малосвязанных между собой программистов. ИМХО это точно не приведет ни к чему хорошему.

[Deus Ex Machina]

2rolano
согласен на 110%

[vidliks]

Линус по объективным причинам не может контролировать все и вся, он не имеет по-настоящему действенных рычагов давления на разработчиков ядра, потому что они - добровольцы.

↑

Он никогда и не пытался. Отправляю вас читать Just for fun. А микроядро уже давно имело шансы на развитие, например в лице Minix, но воз и ныне там. Единственная более менее работоспособная микроядерная ось имхо - QNX. Но движения, кроме постоянного выпендрежа микроядерщиков и наездов на Linusa я лично не вижу.
Отношение Linusa к микроядру опять же было высказано в книге, как и его отношение к проэкту.

Уважаемый rolano, если вы считаете что микроядро лучше, не вижу проблем, форкайте Linux и делайте с ним что хотите. Или переходите на Minix. Линус потратил кучу своего времени на разработку операционки и тратит его до сих пор, он имеет полное право вести проэкт так как он считает нужным. Это его детище а не ваше. Вашу критику считаю не обоснованной.

Кстате вами предложенная модель напоминает метод разработки BSD. Не могу назвать это положительным примером. Да простят меня BSDешники.

[rolano]

Уважаемый rolano, если вы считаете что микроядро лучше, не вижу проблем, форкайте Linux и делайте с ним что хотите. Или переходите на Minix. Линус потратил кучу своего времени на разработку операционки и тратит его до сих пор, он имеет полное право вести проэкт так как он считает нужным. Это его детище а не ваше. Вашу критику считаю не обоснованной.

↑

А вот Вы представьте себя на месте Торвальдса - у него ведь семья, работа и т.д. А тут вдруг из /dev/null выскакивают разные разработчики - типа давай блютуз приделаем, давай примем в исходники дрова на новый рейд-контроллер и т.д. Только не надо меня убеждать, что Линус лично все протестит и потом одобрит - много работы делают другие люди. У этих других людей по мере развития проекта тоже возрастает нагрузка и они передоверяют часть работы еще более широкому кругу людей. В итоге проект ведет вроде Линус (все проверяет, всех наставляет), а код пишет хренова темень программеров. Попробуйте в этих условиях обеспечить строгость в тестированиии и стопроцентную безглючность. Отсутствие должного контроля и резкое возрастание его стоимости (не только денежной, но и сугубо трудовой) по мере роста проекта - бич всех развивающихся фирм. Именно поэтому крупные проекты развиваются медленно - сложно все состыковать, приходится до фига времени тратить на стандартизацию, дивизионально разделить проект и т.д. Пока Линукс был под контролем (реальным, а не номинальным) со стороны ограниченного круга людей он развивался в едином русле. А разные программеры и пишут по-разному: кто-то аппроксимирует полиномом Лагранжа, кто-то - Ньютона. Каждый из методов имеет свои недостатки и преимущества.

Единственная более менее работоспособная микроядерная ось имхо - QNX. Но движения, кроме постоянного выпендрежа микроядерщиков и наездов на Linusa я лично не вижу.

↑

Вот демократия - хорошая идея? Всеобщее участие в управлении, сопричастность к власти, свобода личности и т.д. А с другой стороны демократия - это власть большинства над меньшинством (как правило, более кваоифицированным, потому что интеллект - редкий ресурс). И всякие скинхедовские банды терроризируют чернокожих студентов. Первое - это идея, а второе - ее претворение в жизнь. Не нужно их путать.
Я высказывал идею о необходимости выноса подавляющего большиства драйверов за пределы ядра. ИМХО это переложит ответственности за косяки на разработчиков этих драйверов и упростит процедуры добавления в систему новых драйверов. Ведь не секрет, что далеко не все разработки принимаются в дерево. Сколько времени в ядре не было человеческого MPPE/MPPC? До фига. А товарищи для включения этих возможностей патчили ядро на протяжении немалого числа выпусков 2.4 и 2.6. Замечательная ситуация, учитывая наличие дохренищенского списка поддерживаемых железок, часть из которых - хлам.

Кстате вами предложенная модель напоминает метод разработки BSD. Не могу назвать это положительным примером. Да постят меня BSDешники.

↑

Сравните списки обнаружиаемых уязвимостей в ОпенБСД, ФриБСД и в ядрах Линукса. По отдельным аспектам с ФриБСД Линукс еще может потягаться, но с ОпенБСД - вряд ли. БСД представляет из себя гораздо более законченную, но в то же время модульную архитектуру - многие ругают NETGRAPH, но мне он понравился. Добавление новых возможностей для меня не связано с освоением всего заново - я просто задействую новый крючок. Как в Линуксе, так и в БСД родилось немало достойных решений, но взрыной рост популярности Линкса сыграл злую шутку - проект просто захлебывается. Именно в ветке 2.6 появилась четвертая цифра в нумерации ядра - или это первоапрельская шутка Линуса? Нет, просто спрос на новые возможности и количество косяков настолько опрережают время их предполагаемого доведения до ума, что проще выпускать промежуточный релиз. Заметьте - Опенок выпускает релиз раз в полгода, но потом систему не надо патчить и пилить напильником. Это не плохо и не хорошо - это просто ПО-ДРУГОМУ. Араб никогда не поймет религиозные аргументы христианина, хотя оба верят в высшую силу - Бога.

И уж если Линукс и не перейдет на микроядро (что имеет свои плюсы и минусы, бесспорно), но при таком контроле над разработкой как сейчас проект загнется, не в силах прожевать слишком крупные куски. Я сейчас БСДшник, сидел на Слаке. Но когда пошли 2.6 убежал на фиг - политика написания стала лильно смахивать на Мелкософт: быстро отдать полуфабрикат, а потом его доделывать.

[vidliks]

[quote] А вот Вы представьте себя на месте Торвальдса - у него ведь семья, работа и т.д. А тут вдруг из /dev/null выскакивают разные разработчики - типа давай блютуз приделаем, давай примем в исходники дрова на новый рейд-контроллер и т.д. [quote]
а вам больше по душе аскетичность BSD с минимумом драйверов и минимальной поддержкой устройств?

[quote]Только не надо меня убеждать, что Линус лично все протестит и потом одобрит - много работы делают другие люди.[quote]
Естественно. Но это его политика. Он никого не просит. Или делает сам или ждёт пока пришлют варианты решения и выберет из них лучший.

[quote] Попробуйте в этих условиях обеспечить строгость в тестированиии и стопроцентную безглючность.[quote]
Мicrosoft прступает по другому. Может всётаки это не показатель?

[quote]Отсутствие должного контроля и резкое возрастание его стоимости (не только денежной, но и сугубо трудовой) по мере роста проекта - бич всех развивающихся фирм. [quote]
Здесь нет контроля. Это всё Just for fun.

[quote]Пока Линукс был под контролем (реальным, а не номинальным) со стороны ограниченного круга людей он развивался в едином русле.
[quote]
О каком контроле вы говорите? Это же GPL. Просто ему верят. Если вы считаете что и за вами пойдут люди - делайте альтернативное ядро и развивайте эго как хотите.

[quote] Вот демократия - хорошая идея? [quote]
Это компромис между интересами индивидума и общества. ИМХО это наилучший вариант для развития личности в обществе. Потому что демократия не предпологает расстрелов интелегенции и прочих прелестей. Но для развития челевечества как вида, демократия менее эффективна.

[quote]И всякие скинхедовские банды терроризируют чернокожих студентов.[quote]
болезнь общества имхо не относиться к методу правления. Скорее это результат навязывания чужих стандартов. А как известно, насильно мил не будешь. Просто запад пришёл к равноправию сам а россия пытаеться всучить всё обществу наскоком. К тому же национальный вопрос всегда был достаточно спорным.

[quote] Я высказывал идею о необходимости выноса подавляющего большиства драйверов за пределы ядра. ИМХО это переложит ответственности за косяки на разработчиков этих драйверов и упростит процедуры добавления в систему новых драйверов. [quote]
А я утверждаю, на примере Minix что такую систему намного сложнее развивать. Хотя приемущества микроядра не оспаримы, на данной стадии ещё не у кого не удалось сделать нормальную реализацию, и это имхо уже показатель.
И не недо ставить на Linux эксперементов. Для этого есть микроядерные системы. Когда будет чёткая необходимость в переходе, это произойдёт само сабой. Пока я не вижу причин трогать то что работает. <C>

[quote]Ведь не секрет, что далеко не все разработки принимаются в дерево. Сколько времени в ядре не было человеческого MPPE/MPPC? До фига. А товарищи для включения этих возможностей патчили ядро на протяжении немалого числа выпусков 2.4 и 2.6. Замечательная ситуация, учитывая наличие дохренищенского списка поддерживаемых железок, часть из которых - хлам.[quote]
боюсь обладателт этого хлама с вамт не согласяться. Когда к железке будит идти Linux driver cd возможно я и соглашусь.

[quote]Сравните списки обнаружиаемых уязвимостей в ОпенБСД, ФриБСД и в ядрах Линукса. По отдельным аспектам с ФриБСД Линукс еще может потягаться, но с ОпенБСД - вряд ли.[quote]
Спорное заявление. Сравните количество поддержываемого железа. Меня добивает отсутствие в BSD хоть одной нормальной Journal FS. И так далее. Вобще моё мнение о BSD сложилось после просмотра кода init в Linux и BSD. В linux он в 3 раза меньше. В bsd жутко нагромаждён. Если она вся так написана, то я не понимаю смысла спора. Колво уязвимостей в Linux обьясняеться его наааамного большей распространённостью. И во вторых вы считаете одекватным сумировать уязвимости всез дистров? Ядро то одно но каждый наклалывает на него свой патчи призванные с этим бороться.

[quote]Нет, просто спрос на новые возможности и количество косяков настолько опрережают время их предполагаемого доведения до ума, что проще выпускать промежуточный релиз. [quote]
Эти возможности рано или поздно доведут до ума. Это лучше чем полное их отсутствие в BSD.

[quote]И уж если Линукс и не перейдет на микроядро (что имеет свои плюсы и минусы, бесспорно), но при таком контроле над разработкой как сейчас проект загнется, не в силах прожевать слишком крупные куски. [quote]
Но коммент. Одни эмоции. Слухи о кончине Linux сильно преувеличены. Скорее захлебнётся BSD, разработчики которого постоянно клянчат денги у сообщества на новый комп.

[quote]Я сейчас БСДшник, сидел на Слаке. Но когда пошли 2.6 убежал на фиг - политика написания стала лильно смахивать на Мелкософт: быстро отдать полуфабрикат, а потом его доделывать.[quote]
Ещё раз повторю. У вас есть выбор. Сидите на слаке с 2.4 или перейдите на Деб с 2.6 и тд. Пропатчайте ядро сами в конце концов. Нельзя же ждать пока всё сделают другие.
Напишите письмо Linusu. Может быть он согласиться.

ЗЫ я не в настроении участвовать в религиозных войнах, но критику Linusa считаю необоснованной.

[polachok]

а вам больше по душе аскетичность BSD с минимумом драйверов и минимальной поддержкой устройств?

неправда

Здесь нет контроля. Это всё Just for fun.

давно уже не так

Именно в разнообразии и выборе и преимущество Linux.

ядро не имеет отношения к этому прекрасному принципу

[vidliks]

ядро не имеет отношения к этому прекрасному принципу

На сколько я знаю почти каждый дистр патчит ядро под себя.

[rolano]

я не в настроении участвовать в религиозных войнах, но критику Linusa считаю необоснованной.

↑

Уважаемый, если бы со стороны Коперника не звучала критика по поводу официально поддерживаемой геоцентрической модели, то вы бы сейчас не за компьютером сидели, а совершали/планировали набеги на Новгород и думали, что Земля - плоская.

[vidliks]

я не в настроении участвовать в религиозных войнах, но критику Linusa считаю необоснованной.

↑

Уважаемый, если бы со стороны Коперника не звучала критика по поводу официально поддерживаемой геоцентрической модели, то вы бы сейчас не за компьютером сидели, а совершали/планировали набеги на Новгород и думали, что Земля - плоская.

в ситуации когда другая сторона называет иные точки зрения ересью - да. Но насколько я знаю Линус никогда не отрицал приемуществ микро ядра. Он лишь говорил о сложности реализации.

[rolano]

Он лишь говорил о сложности реализации.

↑

Так никто и не говорит, что это легко. Сделать процессор на несколько мильярдов транзисторов - тоже не фигня, но ведь делают. Собственно тема топика - рост количества ошибок в ядре. Это следствие его разрастания. А тридцать метров исходников сложнее контролировать, чем два? Или фиолетово? Вот и предлагается разделить собственно ядро (диспетчеризация, система памяти и т.д.) и код для подавляющего большинства железок. И никто не говорит, что уже завтра должно выйти рабочее микроядро - все начинается с первого шага. Собственно и микроядро - не единственное решение. Но Вы, как сторонник свободы, с другим вариантом не согласитесь - ужесточить требования к контролю за состоянием системы. Популярность Линукса не в последнюю очередь базируется на устойчивости и бесплатности. При дальнейшем росте придется сделать выбор - устойчивость (но за денюжку, потому что дистростроители много буду дописывать и переписывать) или бесплатность (но с глюками, потому что их некому будет патчить достаточно быстро для возможности применения системы на практике). И то, и другое - не самые лучшие варианты, потому что глюкавые систему быстро становятся непопулярными, а платные скорее всего будут распространяться без исходных текстов (потому что там будет слишком много собственного кода), что подорвет саму идею ОпенСорса. Нельзя и в Кремль сесть, и Рыбкина съесть.

[vidliks]

При дальнейшем росте придется сделать выбор - устойчивость (но за денюжку, потому что дистростроители много буду дописывать и переписывать) или бесплатность (но с глюками, потому что их некому будет патчить достаточно быстро для возможности применения системы на практике).

Или взять например модель разработки Дебиан и перенести её на ядро.

что подорвет саму идею ОпенСорса.

Просто кроме технических проблем, есть ещё и личная неприязнь Линуса к микроядерщикам и конкретно к Tanenbaumu, за его критику Linuxa в начале проэкта.
И я сомневаюсь что что то измениться.

И хотя с техническими доводами я согласен, всё равно, это его проэкт и его решение.

[rolano]

это его проэкт и его решение.

↑

Дык никто и не спорит Просто у всех разные взгляды на будущее ядра Линукса в том виде, как оно видится исходя из текущей ситуации. Я не отношусь к сторонникам анархической свободы - необходим качественный менеджмент разработок, только тогда они могут быть внедрены с минимальным количеством ошибок. Именно поэтому уже сейчас надо задумываться над подобными вопросами, потому что когда они реально предстанут, то будет уже поздно.

Просто кроме технических проблем, есть ещё и личная неприязнь Линуса к микроядерщикам и конкретно к Tanenbaumu, за его критику Linuxa в начале проэкта.

↑

Очень жаль, что личная неприязнь вмешивается в это дело. Собственно я пока нигде слышал, чтобы Линус предложил какие-нибудь изменения в существующую схему работы. А то, что она далеко не идеальна, заявляют сами разработчики: название темы свидетельствует об этом. Даже наоборот - некоторое время назад читал, что Линус заявил о снижении внимания к разработке (времени нету, дела), он вроде собирался осуществлять только общее руководство. Пока что не очень видно плодов этой деятельности. ИМХО пример Форда как раз в тему - для вывода предприятия из кризиса Форд нанял управленца, который привнес новые идеи и все наладилось. Проекту тоже нужны новые идеи, однако Линус по-видимому занимает позицию гегемона, для которого есть два мнения - его и неправильное.

[fatboy]

Спорьте, не спорьте а ядра продолжают клепать вместо ьтого чтобы фиксить написанные: http://lkml.org/lkml/2006/7/6/2

[Aku]

Винда микроядерная? Почему драйвера для нее пишутся без изменения ядра винды и без малейших усилий со стороны микрософт? Какая разница как назвать подход, главное чтобы он был рабочим!

Винда такой же модульный монолит как и линукс. Только она пишется по другому. Ее сначала долго пишут, а потом когда все якобы устаканится выпускают версию. Поэтому есть впечатление некой стабильности. Хотя далеко не факт, что ХП-шные драйвера будут безглючно работать в висте. На руку МС играет еще то, что она монополист и разработчкик железа вынуждены подстраиватся. Хочешь продавать железо - имей безглючные драйвера для последнее версии винды.

В линухе вроде бы есть механизм динамических модулей (dcms кажется называется) но он почти не используется.

Используются по полной программе. Глянь в /lib/modules/2.6.bla-bla-bla
У меня в стандартном ядре 2.6.17-ARCH 1310 модулей (*.ko) для сравнения в винде в system32/drivers всего 210 файлов

[WolfON]

Клепают и правильно делают - большинство багов обнаруживается как-раз таки в процессе добавления фич и тестирования ядра.

[fatboy]

Клепают и правильно делают - большинство багов обнаруживается как-раз таки в процессе добавления фич и тестирования ядра.

Я и говорил о тестировании и отладке. А фичи нужно прикручивать к стабильной и надежной базе. Пусть побольше тестируют но зачем выпускать релизы?

[Bruce]

разве не собирались форкать 2.6.16 под стабильную ветку + ещё чего-то там?

с виндой модель дровов линукса имхо вообще сравнивать некорректно. одно могу сказать точно - наличествует бинарная совместимость. И работает

[rolano]

Клепают и правильно делают - большинство багов обнаруживается как-раз таки в процессе добавления фич и тестирования ядра.

↑

Да пусть себе клепают! На баллистические ракеты тоже разное программное обеспечения ставят, только не пускают его в серию, пока оно не будет тщательно протестировано. А ядра только и успевают переводить в стабильные ветки, зато потом с наслаждением вылавливают баги и исправляют их (чтобы в следующем выпуске наступить на те же грабли ). Операционная система - это вам не Акробат. Чем ближе к оборудованию, тем более качественным должен быть код, а кто к железкам ближе ядра? Ну только если код, вшитый в БИОС, может сравниться, но что-то не слышал я про ошибки в нем. ИМХО вопрос не в том - выпускать или не выпускать, а в том - насколько часто. Не думаю, что сообщество сильно будет возмущаться, если ядра будут выходить не раз в месяц (как это было в самом начале ветки 2.6), а раз в полгода или даже раз в 7-8 месяцев. В ядре 2.6.16 было 5,1 метра патча при самом ядре в 39 метров. Уважаемые - это 13%! А в 2.6.0 размер патча составил 10 килобайт при ядре в 32 метра. Конечно, можно сказать, что в 2.6.0 было мало нововведений, это было стартовое ядро, но ведь никто и не заставляет девелоперов все ядра выпускать за одинаковый промежуток времени. ЭТО НЕ ЯВЛЯЕТСЯ ХАРАКТЕРИСТИКОЙ РАЗВИТИЯ ПРОЕКТА. ИМХО сли разработчики думают, что скоростным клепанием они заслужат дополнительный авторитет, то это огромное заблуждение. Ядро - это не прикладной софт, хотя даже в нем ошибки могут быть чреваты (если невзначай начнут валиться корпоративные базы под Ораклом, то контора может вообще потерять клиентскую базу). Сейчас ядро Линукса движется по этому пути: "шипка быстра" выпустить релиз и всем говорить - а вот мы сумели реализовать эту фичу раньше всех, мы самые продвинутые. А в этом ли "продвинутость"?

[snake]

а кто к железкам ближе ядра?

↑

Драйверы.

Ну только если код, вшитый в БИОС, может сравниться, но что-то не слышал я про ошибки в нем.

↑

Вы многое потеряли... Знаете ли, очень забавно черти скока поиметь нетрадиционного секса с железяками ни как не уживающимися вместе, а потом узнать, что есть прошивка BIOS'а фисксищая эту проблему.

[Bruce]

А в 2.6.0 размер патча составил 10 килобайт при ядре в 32 метра.

фактическая неточность. это был патч, накладываемый скорее всего на 2.6.0-test#. Кому надо - могут прикинуть разницу между 2.4.какое-было-тогда и 2.6.0

[alv]

А в 2.6.0 размер патча составил 10 килобайт при ядре в 32 метра.

фактическая неточность. это был патч, накладываемый скорее всего на 2.6.0-test#.

совершенно верно
именно потому, что в последней тестовой версии выкопали багов всего на 10 кил, и рискнули обозвать 2.6.0 релизом

Кому надо - могут прикинуть разницу между 2.4.какое-было-тогда и 2.6.0

если мне склероз не изменяет, разница составляла мегабайт 12