В 2.6.16.15 (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.15) Linux ядре исправлено 4 ошибки (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.15), которые потенциально могут быть использованы для совершения удаленной DoS атаки.
Мантейнер 2.6.x ветки Linux ядра, Andrew Morton, на конференции LinuxTag выразил свои опасения (http://news.zdnet.co.uk/0,39020330,39267255,00.htm) по поводу ухудшения ситуации с качеством кода в ядре. По его словам число неисправленных ошибок преобладает над числом исправляемых, что приводит к накапливанию проблем.
Некоторые ошибки, особенно связанные с устаревшим оборудованием, разработчики не исправляют уже несколько лет, несмотря на непрекращающийся поток сообщений об их наличии. Более того, около 25% присылаемых новых патчей для помещения в ядро, вызывают тривиальные ошибки компиляции.
Для примера, в разных местах ядра удалось найти 65 переопределений (http://marc2.theaimsgroup.com/?l=linux-kernel&m=114250357613993) типов TRUE и FALSE.
Хакер ядра Dave Jones, продолжил тему опубликовав заметку "bug++" (http://kernelslacker.livejournal.com/37851.html) в своем блоге, в которой проанализировал число сообщений об ошибках ядра в bugzilla репозитории проекта Fedora Core Linux (переход на новое ядро приводит к заметному росту числа нерешенных проблем).
Linus Torvalds по данному поводу высказал предположение (http://www.linux.com/article.pl?sid=06/05/08/1439236) что ядро 2.6.16 используют или планируют использовать в качестве базового многие коммерческие дистрибутивы, что приведет к стабилизации данного ядра
из-за исправления ошибок их силами.URL: http://www.kernel.org/
Новость: https://www.opennet.ru/opennews/art.shtml?num=7488
ну да конечно - [quote] то ядро 2.6.16 используют или планируют использовать в качестве базового многие коммерческие дистрибутивы, что приведет к стабилизации данного ядра из-за исправления ошибок их силами.[/quote]- типа мы вам тут нашлепали кода, правда там туева хуча ошибок, в общем разберетесь сами, поправите если что, а мы тут пока вам новое ядрышко напишем, с еще большем количеством дырок :(
прогресс, епта ;)
главное чтобы был выбор: хочу-юзаю, не хочу-не юзаю.
А только так и надо. :)
Чем быстрее код уйдет в массы, тем быстрее баги вылезут.
Выбора-то людей никто не лишает - кому критична стабильность, тот может юзать ядра типа 2.4.32, или консервативные дистры навроде CentOS.
Фигасе тревожит разработчиков, а меня как конечного пользователя это тоже слеХка тревожит. :) Такое впечатление, что разработчики всё время куда-то спешат и за кем-то гоняться...
FreeBSD
за неуловимым Билли они гонятся
Да ладно, мужики, кто из вас использует этот SCTP?
Я думаю так - баги есть, но какая часть из них затрагивает наиболее часто используемые компоненты ядра? Думаю малая (доказательств нет :-) Так что большинство может не париться. У меня стоит 2.6.16.12 и этой .15 я обновлять не намерен.
Дело не в том, кто что использует, а в том, кто и как пишет.Вот спрашивается, какого ... переопределять TRUE, FALSE?
но так какого х...я Пингвин Торвальдс не запихнёт #define TRUE 1 и #define FALSE 0 в <linux/kernel.h> или в <linux/stddef.h> и мы бы спокойно делали #include
Да хрен бы с ними, с дырами. Ни одна из них меня не коснулся, ибо эти подсистемы я никогда не использовал и не собираюсь, как, полагаю, и _подавляющее_ большинство пользователей.Но вы посмотрите на эти патчи -- ошибки-то просто детские. То длину строки без NULL-байта посчитают, то зависимые выражения местами перепутают. А ведь еще месяц назад я был уверен, что ядро Linux пишут и сопровождают опытные программитсты...
И как тут не зауважать разработчиков BSD?
Ядро Linux пишут все кому не лень - присылают патчи всем миром.
Как кто-то там сказал - количество переходит в качество - и это свершившийся факт.
Да ошибок много. Их будут исправлять. Но по скорости Linux уже (чуть не написал "давно уже" и понял, что это будет неправда) опережает FreeBSD.
А, как ты правильно заметил, подсистемы, в которых в последнее время находят ошибки, используются далеко не всеми - именно поэтому команда Linux и вылавливает ошибки по одной.
Я наверное ошибаюсь, что-то в моих рассуждениях не так.
Да, по-моему, ты просто упустил маленький факт. Утверждение про количество и качество - необязательно к исполнению. Т.е. количество может перейти, а может и не перейти. Потому девелоперы и бьют тревогу - их похоже потихоньку заваливает некачественными патчами, и кол-во проблем растет.А какой толк в пингвине, который бегает быстрее всех, но чаще всех при этом клеит ласты? Не факт, кстати, что быстрее, но такое ощущение, что линукс керн девелоперы именно это и поставили своим идеалом и упорно к этому стремятся, забив на все остальное. Ну, может еще и кол-во фич, но опять же, какой толк серверу от mp3 плейера в kernspace (работает на 30% быстрее), если он вызывает панику каждые 30 минут.
P.S. А недавно проскользнувшая нотка (DEPRECATED)(NEW) у одной фичи меня здорово удивила - это что они этим хотели сказать-то?
хм. удивило про "часто ласты клеит"?
вы живете в 2001 году (ядро 2.4.0-2.4.19)?как отладили тогда ядрышко под smp/highmem - так проблем и нет. или что-то осталось принципиальное?
к сожалению freebsd (5/6) на sata - на интеловских серверах очень нестабильны, в отличии от linux. *я про ядро, окружение/дистрибутив значения не имеет*
> Ну, может еще и кол-во фич, но опять же, какой толк серверу
> от mp3 плейера в kernspace (работает на 30% быстрее), если
> он вызывает панику каждые 30 минут.Даже если и не вызывает -- никакого толку :)
> к сожалению freebsd (5/6) на sata - на интеловских серверах очень нестабильны, в отличии от linuxНекомпетентная чушь.
Анонимус, вы болван. "Чушь" компетентная, и проверенная лично :) серверов много, и глючат они одинаково. Ситуация воспроизводиться на ура. Только вот Linux я умею отлаживать - и багрепортить, а FreeBSD нет :):)
Ну вот, опять сейчас щас начнется флейм по осям. Собственно, обсуждается что - ядро пигвина, в частности тенденция накопления ошибок и перекладывание исправления оных на владельцев коммерческих дистрибутивов, что особо не радует.
Сам пользую и демона и пингвина, и не вижу повода начинать дискутировать "чье ядро лучше". Будьте более конкретны, господа. ;)
А не будут комерческие дистрибутивы править "на опережение" баги..
У того же RH в багзиле бывают такие вещи (репортер кто-то из redhat.com) - "тут в mainstream багу пофиксили, похоже она и у нас есть" ответ - "кто-то из клиентов на нее наступил? нет - тогда когда наступят тогда и пофиксим".
А это, между прочим, правильный подход.
Исправление баги может породить другую багу.
Главный принцип продакшена: работает - не трогай.
А по-моему зря они все дрова в ядро кидают. Налабали бы "ядро ядра", а дрова патчами/модулями к нему - хочешь качай, хочешь нет. Тогда и можно было бы говорить о реальном количестве багов в "ядре" и в модулях.
Я не за микроядро - монолит Linux прекрасно работает. Но раз ядро допускает "патчность" и модульность - это надо использовать. Предполагаю, что из >30MB всякой хрени в 2.6.16 мне лично потребовалось не более 10. Ну и нахрен всё остальное? Ведь это могло быть и патчами. Хочешь специфический драйвер - пожалуйста, хочешь поддержку bluetooth - пожалуйста, скачал патчик и вперед, ловить ошибки. А "ядро" как было стабильным, так и осталось.
Кто по англицки хорошо ботает - киньте мысль на линуксовый ядерный maillist.
Да, по идее можно сделать и так. Мне лично от этих 30 Мб (средний размер обычной дистрибутивной сборки "все в одном") надо только 4-5 (и это с модулями).А в lkml сейчас и без нас че тока не предлагают...
А микроядро, кстати, было бы идеальным выходом из положения, ИМХО.
а в чем проблема?устанавливайте QNX и стабильнаая система в вашем разпоряжении.
Или вам надо линукс микроядерный?
если его сделать микроядерным, то что0то мне кажется что это получится MINIX :-)но проще уж перейти на хурд, если его вдруг когдато допишут(L4).
MINIX не получится в любом случае :) И если уж на то пошло -- проще перейти на BSD.Но дело в том, что Linux -- это не просто "один из UNIX". И уже достаточно давно. Даже на простом десктопе есть задачи, которые ни одна ОС , кроме Linux, быстро и качественно не решит. Кроме того, есть огромное множество научных и промышленных проектов, перевод которых с Linux на другие рельсы (будь то некие расширения BSD, QNX, или что-то совсем новое, типа Inferno) обернется миллиардными убытками и необходимостью переучивать тысячи разработчиков. Пора понять, что Linux -- это уже не только операционная система, это -- технология. А когда технология долгое время развивается лишь количественно, без качественных переходов (что мы и наблюдаем на примере эволюции 2.4->2.6), она заходит в тупик и, с большой долей вероятности, в последствие отмирает.
Полагаю, что последствия этого варианта развития событий не порадуют даже фанатичных БСДшников. Поэтому и считаю, что "спасти" Linux от превращения, через пару лет, в монстробразный глюкодром (каким уже стала mswin) может только некая революционная реорганизация его архитектуры, типа (но не обязательно) перехода на микроядро.
>Но дело в том, что Linux -- это не просто "один из UNIX". И уже достаточно давно. Даже на простом десктопе есть задачи, которые ни одна ОС , кроме Linux, быстро и качественно не решит. Кроме того, есть огромное множество научных и промышленных проектов, перевод которых с Linux на другие рельсы (будь то некие расширения BSD, QNX, или что-то совсем новое, типа Inferno) обернется миллиардными убытками и необходимостью переучивать тысячи разработчиков. Пора понять, что Linux -- это уже не только операционная система, это -- технология.Странноватое высказывание. Неочевидное. Аргументы, примеры?
>
> А когда технология долгое время развивается лишь количественно, без качественных переходов (что мы и наблюдаем на примере эволюции 2.4->2.6), она заходит в тупик и, с большой долей вероятности, в последствие отмирает.
>
Ни хрена ж себе только количественно. А повсеместное внедрение RCU? а разве плаг энд плей не лучше(и по другой системе однако) стал работать? И это только то, что я знаю. Кроме того видел один тест - время установления tcp соединения - в 2.4.х рост задержки с ростом кол-ва одновременных соединений - линейный, в 2.6 - задержка - константа - Это разве не _качественный_ переход?Другое дело - никто ядро с нуля не будет переписывать, никому это нах ненадо.
Паралельный пример: PHP - тормоз и урод. Даже не меняя (в худшую сторону) семантику языка, но изменив полностью реализацию можно ускорить его раза в два (см - Python и супер быстрый Lua). Но куда девать сотню C-шных библиотек?
> Но куда девать сотню C-шных библиотек?А выход тот же. Не меняя интерфейсов, переделать реализацию.
И меня тревожит. Все метаюсь, никак не могу выбрать себе основную систему из следующего выбора: Windows, Solaris, Linux и FreeBSD. Всюду свои недостатки.
>И меня тревожит. Все метаюсь, никак не могу выбрать себе основную систему
>из следующего выбора: Windows, Solaris, Linux и FreeBSD. Всюду свои недостатки.
>Мультизагрузка спасет. У меня на машине спокойно живет FreeBSD, Хрюша и пингвин. И дружат :)
>И меня тревожит. Все метаюсь, никак не могу выбрать себе основную систему
>из следующего выбора: Windows, Solaris, Linux и FreeBSD. Всюду свои недостатки.
>Plan9 РУЛЕЗ!
http://cm.bell-labs.com/plan9/
http://ask.km.ru/plan9/Выбирай маздай, не ошибёшься.
Маздай всегда будут юзать, ламмеры никогда не переведутся.
А хэкер ты или нет - это не твой выбор.
Какой на свет уродился, и с этим ничего не поделаешь.
Ты мне про Plan9 не говори. Я с трудом скачал его несколько лет назад, когда его никому еще не давали. Заходил через штатовские прокси, знакомился с людьми и выпрашивал. Дерьмо Plan9, больше крить его не буду :)
Вот не понимаю я такого отношения. Это же хорошо, что столько патчей выходит. Значит ошибки НАХОДЯТ. А если их не находят, это не значит, что их там нет.А кому не нравится - идите на ветку 2.4 - там, AFIAK уже все стабилизировано.
Короче. Даешь 2.6.16.253! :)
>Короче. Даешь 2.6.16.253! :)
Потом 2.6.16.254,
потом 2.6.16.255,
а потом kernel panic
:)