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

[alv]

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

и опять некорректное сравнение
софт, управляющий баллистической ракетой, делает только одно - управляет баллистической ракетой
ему не нужно заниматься воспроизведением звука, взаимодействовать с периферией, поддерживать сетевые протоколы и прочая, и прочая, и прочая
потому его и отдраить до полного блеска гораздо проще
Марк Шаттлворт рассказывал, что на Союзе, на котором он летал, бортовые компьютеры - восьмибитные машины, программируемые напрямую в машинных кодах

[Apocalypse]

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

Ага, а еще широко известные ошибки с определением "больших" винтов и т.п...

[rolano]

потому его и отдраить до полного блеска гораздо проще

↑

При всем уважении, alv, но в таком случае проще вообще ничего не тестировать и не проверять. А зачем, если все равно и так слишком много ошибок, чтобы большинство из них выловить?

Ага, а еще широко известные ошибки с определением "больших" винтов и т.п...

↑

Ну собственно можно ведь большие винты прикручивать и на машины уровня Пентиума 2. Только БИОС того времени не знал о подобных богачествах. Покупайте новые материнки - и все будет путем. Конечно, у меня дома особо больших винтов нету, но даже на старой Чайнтек с Селероном 1100 мой 120-гигабайтник опредеился нормально и без проблем работал (и работает сейчас на другой машине). Если хотите поддержку топового винта - берите топовую материнку.

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

↑

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

[alv]

потому его и отдраить до полного блеска гораздо проще

↑

При всем уважении, alv, но в таком случае проще вообще ничего не тестировать и не проверять.

Это уже даже не утрирование, а доведение до абсурда
Повторяю, в исходном тексте и его первоначальном обсуждении речь шла только о том, чему отдать более высокий приоритет сейчас - тестированию старых фич или изобретеню новых: Вы, как юниксоид, понимаете, что более высокий приоритет одной задачи вовсе не означает приостановки задачи менее приоритетной
и ни слова там не было об изменении архитектуры ядра
хорошо это или плохо, но тут как раз та ситуация, когда каждый отдельный индивидуум имеет возможность изменить ситуацию - в отличие от политики, экономики, метеоусловий и почти всего другого
и даже три пути:
1) взять много много рашн уодка, поехать к Линусу, напоить его до такой степени, чтобы наутро он закричал: отныне Linux - микроядерная, только дайте мне пивка-а-а-а-а... (как Вы понимаете, я тоже несколько утрирую)
2) стать линукс-кернел-хакером, добиться автритета в этом сообществе и убедить его в том, что курс надо меня
3) сделать свой форк и делать с ним все, что душе угодно

А пытаться объяснить разработчикам ядра, что они должны делать, на некоем форуме (пусть даже Линуксфоруме) - это... ну несколько странно

[vidliks]

alv, 100% поддерживаю.

[Pirren]

Да кто это заново писать будет..

[snake]

1) взять много много рашн уодка....
2) стать линукс-кернел-хакером....
3) сделать свой форк...

↑

Есть еще 4-й путь: сделать все с нуля по-своему Но, похоже, сначала нужно выполнить первых три пункта :lol: B)

[steepz]

dsf

[rolano]

Ну я и не пытаюсь советовать кернел-хакерам. Я высказываю свои собственные соображения, привожу аргументы в обоснование своей позиции. Судя по всему, аналогия с ростом корпорации и возникающими трудностями не убеждает... Ну да ладно. Действительно, что я погу посоветовать кернел-хакерам?
По поводу приоритетености отладки новых возможностей или изобретению старых. Смотря чейнджлоги, почему-то в большинстве случаев натыкаюсь на ошибки в драйверах устройств, а не реализвциях семафоров или механизма подкачки страниц. Мож я не так их смотрю? Однако при существующем подходе именно кернел-девелоперы отвечают за ошибки в драйверах - кто как не они принимают в дерево эти тексты? Вот и получается замечательный результат: увеличение количества поддерживаемого железа*ограниченность времени между релизами*ограниченность трудовых ресурсов разработчиков -> увеличение ошибок в коде драйверов -> возрастание их нестабильности -> возрастание нестабильности ядра. Ну что ж... раз Линус выбрал этот путь - вперед. Нет Бога кроме Линукса, и Линус - пророк его.

P.S. Лично мне вообще фиолетово как там выпускаются ядра Линукса - сам-то сижу на BSD.

[Bruce]

имхо модульность ядра не сделает его микроядерным. Сорцы можно и нужно разделить на части (разумное количество) - так же, как сделали с X11R7. А то заниматься аудитом кода в 200 метрах исходников как-то не очень весело.

и курс менять на самом деле надо. с 2.6.18 похоже будет 45 метров в .tar.bz2, уже немного маразм разрабатывать такой моделью. Плюс не мы (вы ) просили не делать 2.7.*. Новые фишки кидаются в стабильную ветку == уменьшают её стабильность (хотя честно скажу - висло только от cko3 ), просто надо признать, что был выбран неправильный подход (без тестовой ветки). 23 патча на .16 - это уже слишком в любом случае.

Сам же сижу на 2.6.14-nitro2 и в общем-то апгрейдиться буду только уже до 2.6.18 (и то непонятно зачем).

[alv]

пофантазирую и я
то, что объем ядра растет как на стероидах - факт, и факт неприятный
полагаю, что и сами разработчики этот рост замечают
и, имхо, напрашивающееся решение для сокращения кода - исключение поддержки старого железа
помню, меня очень повеселило в ченчлоге 2.6 сообщение о том, что наконец-то достигнута хорошая поддержка микроканальной архитектуры
аккурат в это примерно, время, наверное, сносили на помойку последние IBM PS/2...
опять же - всякие не-PC'шные архитектуры
есть на свете NetBSD, устанавливающаяся на все, что способно запуститься - и зачем вторая?
а Linux создавался для PC - и на них и должен работать
я, конечно, понимаю, что разработчикам поддержки MCA или 680XX жалко своего труда, да м.б. это кому и нужно в реале
но ведь, вероятно, можно, выкинув все не-PC'шное хозяйство из главной ветки, оставить в виде боковых веток или отдельных патчей

[rolano]

Согласен, что модульность ядра не сделает его микроядерным. Просто в условиях возрастания объемов кода ИМХО более разумно отделить ядро от драйверов, предоставив стабильный интерфейс взаимодействия компонентов, что и позволит разрабатывать ядро и драйвера для конкретного железа независимо. Я НЕ НАСТАИВАЮ НА ИСКЛЮЧИТЕЛЬНО МИКРОЯДЕРНОЙ АРХИТЕКТУРЕ, просто ИМХО настало время изменений, а Линус противится изменениям вообще. Конечно, можно ведь и сыграть дракона, спящего на горах золота, но будет ли от этого толк? ИМХО это-то и неправильно. Уж если микроядро реализовать сложно (сам не пробовал, но со слов других ), то необходимо найти нечто другое, что будет соответствовать задачам развития проекта. Однако пока нет (если есть - поделитесь) никаких заявлений об изменении структуры проекта - все идет как и было в самом начале: весь код свален в одну кучу.

[snake]

2alv: выброс на свалку истории поддержки старого оборудования, конечно, немножко сократит ядро, но...
Во-первых, очень не значительно, ибо как раз старого железа и не шибко то и много существовало в природе вообще, по сравнению с кооличеством всяческих девайсин появившихся в эпоху взрывного роста рынка компутерных технологий. Коссвенно это подтверждается компактным размером старых ядер.
Во-вторых, количество всяческого оборудования, которое не плохо было бы поддерживать, в мире растет почти-что в геометрической прогресии. На смену тем 2 - 3 мегам, что освободятся, если выкинуть из ядра всяческие анахронизмы, тут же придет с десяток метров драйверов для новейших супер-дупер шин и модулей для поддержек всяческих тирлямпампаций. Пусть не сразу прям завтра, но через год-два, но, если все останеться как есть, это неизбежно.
В-третьих, что собственно, считать анахранизмами? Если подойти к вопросу осторожно и изъять то, что уж совсем только в музеях встреть можно (типа тех же MCA, 680XX), то выигрыш получиться совсем незначительный. Последствия рассмотрены в предыдущих пунктах. Если вопросс рассмотреть широко, то есть риск, что окажуться обделенными владельцы сравнительно старой техники, до сих пор с успехам использующие её для разных нужд. Да и, потом, все-равно существенного сокращения ядра давбиться навряд ли удастся таким путем.

[Bruce]

а никто не говорил - существенного. Просто рациональное улучшение.

насчёт оборудования нового: дрова-то делают (сами производители в том же числе), но вот как раз из-за бинарной их несовместимости (извините, принудить использовать gpl нельзя) или изменения api ядра (что случается довольно таки часто) использовать их часто не получается, из-за чего собственно, дрова и находятся в одном дереве. В этом плане windows как раз и лучше, ибо предоставляет для дровов стабильный api (вот только не надо уж требовать одного апи у xp и висты, а? это слишком уже ) и сами дрова от ядра зависят не особо. Стабильность конечно под вопросом, но имхо подход более чем здравый.

[rolano]

а никто не говорил - существенного. Просто рациональное улучшение.

↑

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

[Лис]

В этом плане windows как раз и лучше, ибо предоставляет для дровов стабильный api

А разве так сильно изменяется ядро (оно вообще изменяется?) от ХР через XP SP1 к XP SP2?

[Bruce]

А разве так сильно изменяется ядро (оно вообще изменяется?) от ХР через XP SP1 к XP SP2?

вообще уверен, что меняется, но при этом практически гарантирована совместимость уже установленных дровов и т.п. В линуксе имхо такого не будет (к примеру, почитайте faq по nvidia). или подумайте, а почему собственно у вас нет никакой возможности сидеть скажем на старых дровах, или юзать (когда-то к примеру честно купленную) vmware 4.0 с новыми ядрами.

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

Сейчас разработчиков Линукса - на порядок больше, а инфраструктура (имеется в виду среда, в которой обитает текст) как была на уровне тех времен, так и осталась

простите, не было ни bitkeeper и сейчас не юзается git, да? вроде работают и к самой инфраструктуре претензий имхо нет. С другой стороны не понятно, почему нельзя было сделать нормальный cvs, но целесообразно ли это - думаю, Линусу это точно виднее.

[Лис]

вообще уверен, что меняется

Так все-таки уверены или действительно ядро изменяется?

[Bruce]

Так все-таки уверены или действительно ядро изменяется?

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

[rolano]

2 Bruce
Под инфраструктурой разработки я не имел в виду конкретный способ хранения и поддержки дерева. Я имел в виду саму среду, окружение, когда ядро нужно тестировать целиком, а не по частям. Есди хотите, то назоваите это парадигмой или чем-то подобным. С ростом числа включенных компонентов процесс доведения ядра до ума усложняется и затягивается, или же в угоду срокам выпуска снижается его качество. За все в этой жизни надо платить (как бы мы ни хотели все бесплатно) - качество и время выпуска являются конкурирующими целями. Именно в силу появления отрицательного эффекта масштаба производства крупные компании проводят выделение "дочек", филиалов, дивизоинальных подразделений и т.д. Конечно, на фига Линусу опыт функционирования транснациональных корпораций Он же - БОГ!!! Против БОГА не попрешь, совета ему не дашь...
Да и самой идее Линукса чужды эти проявления капитализма - ведь "мы наш, мы новый мир построим", где не будет места деньгам, и опыт других отраслей деятельности для нас не указ, потому что они живут по законом рыночной, капиталистической экономики, которая классово чужда данному проекту и БОГУ. Ну были в СССР "лженауки" - кибернетика, генетика. Философия - продажная девка капитализма. Где сейчас научный коммунизм Сталина, Суслова, Брежнева, Черненко? А где сейчас кибернетика, генетика, философия? С существущим подходом ядру Линукса уготовано загнивание прямо пропорционально росту объема кода - разработчики ведь не рабы и не штатные сотрудники, им тоже очень скоро надоест выпускать то, что не будет находить своего потребителя (а иначе на фига они вообще что-то пишут, тем более бесплатно?), потому что рост популярности Линукса обусловлен не победным шествием на десктопах простых юзеров, а прежде всего корпоративной средой (где доверие потерять можно за минуты, а на его восстановление уйдут годы). Это в начале можно было говорить, что проект молод и постепенно стабильность ядра повышается, поэтому имеет смысл использовать существующие разработки, чтобы потом внедрять комплексные решения на стабильных вариантах. Те времена уже прошли, поэтому снижение стабильности теперь будет только подрывать реноме. Ну на то он и БОГ, чтобы решать единственно правильно...

[alv]

2rolano
Ну Вы и загнули...
Где это Вы видели или слышали, что бы Линус писал или говорил нечто подобное?
И вообще, все это называется передергиванием
Это уж вообще всем оффтопикам оффтопик - от багофиксов до Сталина с Брежневым
лучше уж давайте про выпивку и дам - это и тематически, и классово нам ближе

[Лис]

Насколько я могу судить по публичным высказывания, Линус то как раз не фанатик наподобие РМС. Он вполне трезво оценивает ситуацию. Одно закрывание глаз на нарушение GPL проприентарными модулями, с которыми может работать ядро, о чем то да говорит. Вам уже говорили, что Линус - не БОГ, а человек, который видит весь процесс работы на ядром изнутри, причем не один год.

Ну были в СССР "лженауки" - кибернетика, генетика. Философия - продажная девка капитализма. Где сейчас научный коммунизм Сталина, Суслова, Брежнева, Черненко? А где сейчас кибернетика, генетика, философия?

Не знаю как там на счет кибернетики, а объявление генетики вне закона было обусловлено вполне материальными причинами. На тот период она действительно мешалась. А философия вне закона никогда не объявлялась. Просто была "правильная" и "неправильная" философия. Но такое отношение характерно к ней в любое время. Так, сейчас официально считаются "неправильными" философии Ницше и Хайдеггера.

[rolano]

Под руководством Линуса ядро доросло до того размера, который и имеет сейчас. Едва ли надо быть гением чтобы понять - сложная конструкция ломается чаще простой, потому что приходится подгонять много деталей ко многим деталям.
Заметьте - речь не идет о принципиальном пересмотре самой системы разработки или построения ядра, чтобы учесть с одной стороны необходимость возможно более широкого охвата оборудования и с другой стороны разграничить, разделить ядро таким образом, чтобы ошибки вылавливались задоллго до общих тестовых сборок (никто не отменяет генеральных прогонов, но при каждом изменении в драйвере пересобирать ядро - это тоже не очень хорошо). Единственно, что мне представляется возможным - микроядро (не пинайте, я на нем не настаиваю, это просто один из вариантов) или действительная, хотя бы среднесрочная (2-3 года) стабилизация API. Увы, пока не слышно о революционных изменениях...
По поводу БОЖЕСТВЕННОСТИ Линуса - это заимствовано (пусть и в несколько иной форме) у одного из авторов, участвующих в обсуждении. Речь шла о том, что Линус лучше других знает что и как рулить. Если провести параллели между ядром и большой корпорацией, то совет директоров далеко не всегда вникает в текущие вопросы - для этого есть директора и их заместители, ведущие специалисты и т.д. Начиная с определенного момента жесткая иерархическая структура ничинает давать сбои - это бич всех крупных корпораций, а ядро можно сравнивать с ними, потому что здесь также есть работники с разными функциями, разным положением в структуре управления, достигающими некоторую поставленную им цель, правда денег нет Заметьте, ни один генеральный директор не занимается налогами - для этого есть бухгалтерия, с которой он спрашивает за выполнение своих фукнций. Есть отдел маркетинга, с которого он спрашивает за продажи, есть НИОКР, с которых спрашивает за разработку новых товаров и т.д. ГЛАВА КРУПНОГО ПРОЕКТА НЕ МОЖЕТ ЗАНИМАТЬСЯ ТЕКУЩИМИ ВОПРОСАМИ, ДЛЯ ЭТОГО У НЕГО НЕТ ВРЕМЕНИ. А мне тут говорят - Линус все ведет, он лучше всех знает это ядро, поэтому его видение - лучшее. Линус воспринимается в таком контексте именно как непогрешимый, идеальный, почему я и сравнил его с БОГОМ. Очень интересно посмотреть на процесс проверки Линусом текстов ядра - у меня 2.6.12 в распакованном виде занимает 198 метров. При этом нужно хранить в уме зависимости, паральлельно анализировать код. Если Линус это может - он действительно БОГ. Никого не хотел дразнить этими сравнениями, это мое собственное видение вопроса.

[alv]

2rolano
Ваши негодующие посты скоро превзойдут по объему ядро Линуса

[Лис]

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

[rolano]

Многоуважаемый alv!
Негодование - это когда "все плохо, потому что плохо". Разве я где-нить говорил, что Линукс - это г..но? Просто почему-то основной аргумент против перемен - решение Линуса. Если Вы обладаете информацией, опровергающей мои рассуждения - выскажитесь. Я пока что оперирую фактами (вроде размера ядра) и заявлениями других участников обсуждения. Если есть конкретные факты, опровергающие мои посты - милости прошу. Я вовсе не претендую на истину в последней инстанции, однако на - как я считаю - обоснованную критику существующего положения мне приводят аргументы, что Линус всегда прав (ну прямо церковные догматы, честное слово). Господа, Генри Форд, когда понял невозможности развития своей фирмы в условиях его видения этого процесса, пригласил менеджера, который и вывел фирму из кризиса. Неужели Генри Форд был тупым и никчемным, что поступил так? Уже пора здраво подойти к объективной необходимости развития - переменам. ИМХО.

[rolano]

Вам говорят о компетентности.

↑

Так чем же Линус компетентнее сообщества разработчиков, если он 1) не пишет 2) не анализирует исходные коды?

Отдельные люди разрабатывают модули.

↑

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

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

↑

Философский вопрос - включать все в единый монолит под названием "ядро" или разбить все на блоки сообразно выполняемым функциям. Не спорю, что возможность выбора - это хорошо, но нужно понимать, что за эту возможность проект расплачивается стабильностью.
Я против жесткого включения драйверов к тексты ядра - ядро рулит ресурсами, пусть рулит и дальше, и ему не за чем знать, что для инициализации устройства нужно опросить один порт, послать индекс в другой для получения доступа к управлению и потом уже загрузить данные инициализации. ИМХО ядру это должно быть фиолетово. Оно только должно уметь определить тип оборудования, чтобы подобрать для него драйвер. Тут вам и проприетарные дрова - да какая разница ядру, как там работает? Оно может вести диалог с драйвером - вот и замечательно.
При существущем подходе ядро будет расти пропорционально росту числа поддерживаемых железок. Сами видите, что выпускают новые девайсы с пугающей скоростью. Соотвтетственно с такой же скоростью будет расти количество ошибок - все ведь люди.

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

↑

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

[Лис]

Так чем же Линус компетентнее сообщества разработчиков, если он 1) не пишет 2) не анализирует исходные коды?

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

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

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

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

Отнюдь нет, просто количество железок, которым нужно срочно обеспечить поддержку, растет в геометрической прогрессии. Линукс давно уже вырос из обычной программы Just for fun, на этом деле уже крутится добрый десяток коммерческих дистрибутивов, которые взяли своей целью не много не мало, оттяпать большой кусок от рынка Винды. Никто не говорит, что можно обойтись без перемен. Но не нужно бросаться в них, сломя голову. Уже сам факт того, что Линус не кодит (или практически не кодит) - является переменой, не так ли?

[rolano]

Так вы высказываетесь от имени сообщества разработчиков?

↑

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

Это уже вопрос из разряда бюрократических.

↑

Не совсем. Ведь эти модули не принес Вася Пупкин и не сказал - я тут реализовал кое-что и включаю это в ядро. Код принимается в ядро не просто так, его кто-то туда принимает. О чем говорит такая ситуация - существующее сообщество разработчиков не в состоянии осуществлять должный контроль в старые сроки, ядро просто выросло из тех пеленок, когда это было возможно. Почему же тогда возобладал подход клепания недоделанных ядер вместо более тщательного тестирования? Едва ли на корпоративном рынке (который реально и дал Линуксу такую популярность) поймут ситуации с глюками, это грозит эррозией существующей базы пользователей.
Разрастание числа разработчиков имеет одно очень неприятное последствие - размывание знаний о ядре по все большему числу людей. Если раньше десяток основных девелоперов могли объяснить 90% кода, то теперь все стало слишком сложным, чтобы это даже сводить вместе. В этой связи я и высказывал мысль о необходимости вынести разработку большиства драйверов за пределы ядра. Да на фига тому же Линусу знать тонкости программирования сетевых адаптеров? Ядро не становится лучше или хуже от количества поддерживаемого обрудования. Оборудование - забота разработчиков драйверов, а не ядра. Разработчики ядра должны только предоставить качественное описание стабильного API, чтобы другие люди (может быть сами производители) создали драйвер. В этих условиях проблема поддержки оборудования сильно упростится - если ОСь популярна, то под нее будут делать драйвера, а это опять же работает на ее популярность. А если эти драйвера не обязывать быть открытыми, то снимается препон в части сохранения каких-то "ноу-хау" производителя. Какая мне разница - открытый драйвер или закрытый, если он стабильно работает и не выдает 2 fps вместо 20? Ну и пусть ATI пишет дрова под Радеоны, NVidia - под Гефорсы, Филипс - под тюнеры и т.д. Все равно они будут делать это быстрее, чем добровольцы из сообщества. А разработчикам можно будет заняться проектированием новых файловых систем, механизмов диспетчеризации и т.д. Ради чего хватать куски, которые проект уже не в силах прожевать?

[Лис]

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

Хорошо. С этим я согласен. Но вы ведь не относитесь к активным разработчикам ядра. Я говорю всего лишь о том, что ни вы, ни я не можем критиковать Линуса, поскольку некомпетентны в вопросе.

Почему же тогда возобладал подход клепания недоделанных ядер вместо более тщательного тестирования? Едва ли на корпоративном рынке (который реально и дал Линуксу такую популярность) поймут ситуации с глюками, это грозит эррозией существующей базы пользователей.

Такую ситуацию мы имеем вследствие устранения "по многочисленным просьбам трудящихся" ветки для тестирования. Особенности структуры ядра тут ни при чем. Более того, подозреваю, что в роли трудящихся выступали именно компании, нацеленные на корпоративный рынок.
Что касается второго вашего высказывания, то вы опять же правильно говорите. Однако это только теория. То, что вы описали неплохо работает в Винде, однако в принципе не подходит Линуксу на данном этапе развития. М$ может себе позволить не писать дрова практически ни для каких устройств, ограничиваясь только непосредственно ядром, потому что уверено, что дрова напишут производители железа. В Линуксе такой уверености не только нет, более того, к сожалению, есть уверенность в противоположном. Хотя ситуация и со скрипом сдвигается с мертвой точки, но только чуть-чуть. Таким образом, для большинства своих устройств, мы вынуждены использовать дрова, написанные сторонними разработчиками. И ситуация не изменится до тех пор, пока численность пользователей Линукса значительно не увеличится. Но для того, чтобы значительно увеличить популярность системы, нужна в том числе поддержка оборудования, причем нужна уже сегодня. Т.е., мы не можем, подобно БСД, ограничить поддержку оборудования. Далее, Линукс - это уже не просто набор кодов "сделай сам". В этом продукте заинтерисованы многие довольно влиятельные компании. Ясное дело, что принимать дрова от Васи Пупкина, которые никто не тестировал, они не будут (а этих Вась будет ой-как много). Сейчас сообщество разработчиков ядра весьма серьезно просматривает исходные коды (вспомните сообщение о комментарии на транслите) и отвечает за их качество. В случае отделения модулей от ядра придется либо создавать еще одно сообщество, либо груз написания дров ляжет на разработчиков дистрибутивов. Оба случая явно не являются хорошими решениями.
Я не хочу ничего говорить на счет стабильного API. Повторюсь, это было бы великолепно, но я уверен, что имеются серьезные причины для изменения API. Не специально же разработчики ядра его изменяют, чтобы всем насолить.