Состоялся долгожданный релиз FreeBSD 7.0

>Последние полгода Xorg, Gtk, библиотеки GNOME и KDE, Xfce4 DE >собираются без "танцев с бубнами".

Ну надо же. Через пятнадцать лет существования фряхи они как-то довели порты основных приложений до юзабельного состояния. Респект.

>Ниасилил сборку из портов — в рукопашную, на амбразуры!!

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

>база установленных портов небозь давно порушена.

И не только база порушена. Сама фряха давно порушена. Снесена нах несколько лет назад. Оставались маршрутизаторы VPN для маленьких сетей на старой 4.11 но и они дожили свой век в начале прошлого года.

>Может вы спутали его с Евгением Касперским или Алексом Экслером? Ж) Это >три разных человека, каждый со своим мнением.

Ну да. Меня уже в маразматики записали :)

Именно Крис Касперски.

> Бугага, а вы в курсе про вирусные прогнозы этого авторитетного источника? Вы бы еще привели Касперского в качестве авторитета по нейрохирургии или ракетостроению.

Ой, дураг. Не путай Евгешу Касперыча с Крисом. Ж)

> Фрагментации ufs и ext* подвержены в равной мере, т.к. дизайн очень и очень похож,

Ext3FS не умеет использовать недоконца заполненные блоки ("фрагменты"). Из-за этого увеличивается общая фрагментированность файловой системы при интенсивных операциях перезаписи файлов. В результате дисковое пространство "течёт" как на FAT. Журнал добавляет транзакционность дисковых операций и консистентность файловой системы в любой момент времени, но от потери данных никоим образом не спасает. Если при сбое питания навернётся журнал, то пиздец всей Ex3FS — спасёт только переформатирвоание.

UFS2 умеет распоряжаться фрагментами недоконца занятых блоков, так что фрагментация не превышает 5%. Журнал не нужен из-за механизма "плавных обновлений" и фонового демона-"ремонтника" fsck, вычищающего повреждённые файлы, которые были неполностью записаны в момент аварии (фактически мусор).

> в ext4 есть средства автодефрагментации, ничего подобного в ufs никто делать не собирается.

Для FS, умеющей использовать недоконца занятые блоки, это ненужно принципиально. Кроме того, из-за ДЕфрагментации изнашиваются винчестеры и флэш-память.

> Хотя некотрые архитектурные изменения делаются и в freebsd тоже, например планировщик (да-да, разработка ule3 основана на линуксовом планировщике тоже).

O(1) == ULE1 (последний раз редактировался в 2005 году)
ULE3 — новый планировщик SMP во FreeBSD 7.0-CURRENT.

>> в ext4 есть средства автодефрагментации, ничего подобного в ufs никто делать не собирается.

>Для FS, умеющей использовать недоконца занятые блоки, это ненужно принципиально. Кроме того, из-за ДЕфрагментации изнашиваются винчестеры и флэш-память.

Надо немного подумать и понять, что написан бред.

>Журнал добавляет транзакционность дисковых операций и консистентность файловой системы в любой момент времени, но от потери данных никоим образом не спасает. Если при сбое питания навернётся журнал, то пиздец всей Ex3FS — спасёт только переформатирвоание.

и это тоже

>Кроме того, из-за ДЕфрагментации изнашиваются винчестеры и флэш-память.

Да и вообще операции чтения-записи убивают винт..

Смотрите в кинотеатрах страны:"Патрик нансосит ответный удар" !

> На десктопе у меня всё работает. ЧЯДНТ?

Судишь о ситуации по своему убогому десктопу со специально подобранным для фри железом?

> В Ubuntu 6.06 адаптеры Bluetooth (USB) и IrDA (COM) работали со сбоями, теряли связь, а во FreeBSD 6.1 завелись и работали как часы.

А у мну bluetooth работает нормально, а на фре не завелся твтюнер, вебкамера и не оказалось официальных драйверов для ATI(fglrx).

> ZFS, pf, UFS2+SU без необходимости журнала, фрагментация FS не более 5%, jail... ? Linux'у бежать и бежать за этим.

LVM был в Linux еще тогда, когда бсдшники не успели стырили ZFS из соляры. ext3 работал без всяких извращений, без fsck думающего час и без разваливания ФС при пропадании питания. Фрагментация у ext3 минимальная, у моей сильно поюзанной настольной системы - 1.93%. jail - UML.

> FUSE — не Linux разработка.

Неужели? Сначала FUSE появляется в Linux, затем - во фре.

> O(1) (SCHED_ULE во FreeBSD 5.5, 6.x) не используется и не развивается после 2005 года

Но ведь стырили и это документально подтверждено?

> ULE 3.0 (SCHED_ULE во FreeBSD 7.0). Вопросы?

Ссылку на подтверждение слов, что ULE 3.0 был переписан с нуля и не имеет никакого отношения к ULE, базировавшемуся на O(1) из Linux?

>> отсутствие policy routing со множеством таблиц маршрутизации,

> pf, ipfw, ipf могут работатать параллельно. Вопросы?

При чём здесь параллельные pf, ipf и ipf? Где аналог:

ip rule add from 192.168.1.10 table routing_table1
ip rule add from 192.168.1.20 table routing_table2
ip route add default via 1.2.3.4 dev eth1 table routing_table1
ip route add to 3.4.5.0/24 via 4.3.2.1 dev eth2 table routing_table1
ip route add default via 4.3.2.1 dev eth2 table routing_table2
ip route add to 5.6.7.0/24 via 1.2.3.4 dev eth1 table routing_table2

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

Какие нафиг метапакеты?! Пакет php4 реальный и валяется он строго собранный под одну версию и тянул он за собой вполне конкретный apache 1.3, который был нахрен не нужен, т.к. стоял apache2 из пакета!

> Компилирование является лишь одним из способов установки,

Единственный, т.е. pkg_add глючит.

> согласно идеологии POSIX

Простите, где в стандартах POSIX написано об идеологии установки программ путем из сборки из исходников?

> но во FreeBSD этот способ не единственный.

Второй не работает.

> Кто бы говорил о качестве кода,

Хотите упрекнуть автоматизированную систему проверку кода в пристрастнии?

> когда драйверы в Linux работают по принципу "лишь бы завелось а там посмотрим".

Примеры будут?

> Тормозная и убогая Ext3FS с ненужным журналированием и дикой фрагментированностью как у NTFS (более 20%).

Покури матчасть про ext3. http://www.tldp.org/LDP/sag/html/filesystems.html

Modern Linux filesystem keep fragmentation at a minimum by keeping all blocks in a file close together, even if they can't be stored in consecutive sectors. Some filesystems, like ext3, effectively allocate the free block that is nearest to other blocks in a file. Therefore it is not necessary to worry about fragmentation in a Linux system.

In the earlier days of the ext2 filesystem, there was a concern over file fragmentation that lead to the development of a defragmentation program called, defrag.

ext3 всегда делала по производительности UFS и никогда не сыпалась как фря при пропадании питания.

> Не умеет утилизировать фрагменты неполностью занятых блоков.

reiserfs умеет. Только это вырубают в первую очередь.

> Порядка 15-30% дискового пространства теряется из-за "дырок" и ненужного журнала. Аргументы против?

Если журнал не нужен, тогда что вы радуетесь gjournal как дети? 15-30% наверное намерено тем же херометром, что и 20% фрагментации:

------ cdavl result start ------
fstype ext3
mount mount
f-per 1.93%
blocks 6223179
sblocks 108935
xattrs 0
fblocks 4220711
frags 81536
sfrags 16
cfiles 483602
ffiles 16206
depth 16

Книжки для кулхацкеров это фленовы & журнальчик и прочаа макулатура.

Что касается "уровня", вы хотя-бы пару его книг осильте, не статей прочитанных Вами в "журнальчике", а именнно книг.

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

>Что касается "уровня", вы хотя-бы пару его книг осильте, не статей прочитанных Вами в "журнальчике", а именнно книг.

Пососи у мамы сиську и баиньки, тебе завтра в садик идти..

В садик мне рано, я пока только в ясли хожу.

> Обновление портов и их стабильность зависят от желаний и профессионализма мантейнеров и там и там.

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

> так как новые версии несут фактически не только добавление новых ошибок в код, но и исправляют гораздо более серьёзные АРХИТЕКТУРНЫЕ_ОШИБКИ такого ПО.

А политика обновлений стабильной ветви Debian основывается на простом принципе "работает - не трогай". Если программа работает и с какими-то дефектами в архитектуре, то она после обновления будет работать. А с политикой фрибсд "лучшее - враг хорошего" в новой версии получаем новые баги и проблемы с изменением API, формата конфигов, изменениями синтаксиса и многие другие функциональные изменения, которые вылазят и обрушивают работавщие скрипты, запросы и модули.

> Дебианщики занимаются исправлением ошибок в УСТАРЕВШЕМ ПО РАДИ_СТАБИЛЬНОСТИ,

Именно.

> вообще не занимаясь рефакторингом архитектуры кода.

Работает - не трогай!

> Это губит инновации на корню.

У дебьянщиков всегда есть выбор поставить backports, перейти на testing или спокойно ждать следующего инновационного стабильного релиза с отлаженными скриптами гладкой миграции. Развитие идет в testing/unstable/experimental. Проводить эксперименты над стабильными машинами как это делает редхат над педорой и фрибсдшники - кощунственно.

> Да, на сервере они не нужны, но вот производительность Апача с SQL-сервером будут отставать от более новых версий.

И если сервер не разгонять, то его производительно будет ниже. И что с того? А про регрессии производительности с ростом версии вы слышали?

> Надо немного подумать и понять, что написан бред.

В каком месте?

Я основываюсь на информации из книжки Маршалл Кирк МакКузик, Джордж В. Невилл-Нил "FreeBSD: архитектура и реализация", М.: КУДИЦ-ОБРАЗ, 2006
Глава 8.9 Быстрая файловая система Беркли, стр.433

и из книжки Крис Касперски "Восстановление данных. Практическое руководство", СПб.: БХВ-Петербург, 2006.

Ещё статья: http://www.filesystems.nm.ru/my/freebsd_fs.pdf

Дяди, а скажите почему все так дрочат на этот ZFS ?

Почитал описание и не понял чем оно лучше mdadm+LVM+ext3|4/XFS/JFS/ReiserFS ?

Ебаторий какой-то.....

> ext3 всегда делала по производительности UFS и никогда не сыпалась как фря при пропадании питания.

Давайте не будем произность слово "никогда" в отношении тормознутой и фрагментированной Ext3FS с порушенным журналом. Ж))

>> Не умеет утилизировать фрагменты неполностью занятых блоков.

> reiserfs умеет. Только это вырубают в первую очередь.

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

> Если журнал не нужен, тогда что вы радуетесь gjournal как дети?

gjournal лично мне не нужен. Ну раз есть, то пусть будет, жалко что ли?

> Дяди, а скажите почему все так дрочат на этот ZFS ?

> Почитал описание и не понял чем оно лучше mdadm+LVM+ext3|4/XFS/JFS/ReiserFS ?

> Ебаторий какой-то.....

Фишка фтом, што менеджер томов для ZFS НЕНУЖЕН. ;)

>В каком месте?

Фрагментация возникает не из-за мелких файлов, а из-за добавлений в файлы.

А по поводу производительности внимательнее читать надо

http://www.filesystems.nm.ru/my/freebsd_fs.pdf

стр.12 Планы на будущее.

Если коротко, то добавить журнал, В+ деревья, extents, все это уже есть в XFS, JFS, reiser4, ext4

>Фишка фтом, што менеджер томов для ZFS НЕНУЖЕН. ;)

Да сама эта поделка не нужна.

>> Это губит инновации на корню.

> У дебьянщиков всегда есть выбор поставить backports, перейти на testing или спокойно ждать следующего инновационного стабильного релиза с отлаженными скриптами гладкой миграции. Развитие идет в testing/unstable/experimental. Проводить эксперименты над стабильными машинами как это делает редхат над педорой и фрибсдшники - кощунственно.

В общем, у меня сложилось впечатление, что для нормальной работы дебъянщики используют backports из-за безвыходных ситуаций (конечно, раз stable отстаёт от прогресса ПО минимум на полгода-год), а пакеты из stable только для некритичных к производительности приложений.

Тогда чем backports принципиально отличаются от ports FreeBSD? Вроде качество кода и там и там одно и то же, или нет? Во всяком случае ports во FreeBSD РАБОТАЮТ.

Я так рад что в stable нет прогресса! Просто работает НУЖНАЯ мне версия годами и все.

>Ext3FS не умеет использовать недоконца заполненные блоки ("фрагменты"). Из-за этого увеличивается общая фрагментированность файловой системы при интенсивных операциях перезаписи файлов. В результате дисковое пространство "течёт" как на FAT.

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

При простой перезаписи _никогда_ не увеличивается фрагментация, только при интенсивном удалении/создании или при операциях, меняющих размер файла.

Для справки: только reiserfs умеет дописывать блоки до конца и то только при специальной опции монтирования, которая включает tail packing.

> Фрагментация возникает не из-за мелких файлов, а из-за добавлений в файлы.

Несовсем то.

В UFS2 под "фрагментацией" подразумевается разбиение блока на "фрагменты". Например, блок размером 4 килобайт делится на фрагменты по 512 байт. И при записи файла по размеру не кратного блоку, появляется "хвостовой" блок, который занят недоконца, а именно: три, два или один "фрагмент" последнего блока, принадлежащего такому файлу будут незаняты. UFS2 умеет распределять не только свободные блоки, но и незанятые "фрагменты" для новых файлов, сводя общую фрагментацию файловой системы к минимуму и экономя дисковое пространство. Здесь игра слов: "фрагменты" и "фрагментация", их просто нужно различать в контексте обсуждения.

Ext3FS не может оперировать "фрагментами" блоков, она может выделять только отдельные блоки. Из-за чего быстрее растёт общая фрагментация файловой системы, чем на UFS2. Дисковое пространство на Ext3FS используется с той же эффективностью, что и на FAT32.

(Походу замечу, что на FAT32 и NTFS блок называется "кластером", чтобы не было разночтений и в другом аспекте)

>Ext3FS не может оперировать "фрагментами" блоков, она может выделять только отдельные блоки. Из-за чего быстрее растёт общая фрагментация файловой системы, чем на UFS2. Дисковое пространство на Ext3FS используется с той же эффективностью, что и на FAT32.

Не растет фрагментация файловой системы из-за того, что для 100 байт данных используется 4 кб на диске. НЕ РАСТЕТ, т.к. это совершенно независимые друг от друга параметры.

> А по поводу производительности внимательнее читать надо
> http://www.filesystems.nm.ru/my/freebsd_fs.pdf
> стр.12 Планы на будущее.
> Если коротко, то добавить журнал, В+ деревья, extents, все это уже есть в XFS, JFS, reiser4, ext4

Судя по ссылкам в конце статьи и невзирая на дату публикации, содержимое статьи основывается на обзоре кода FreeBSD 6.1 и оригинальной статье Маршалла Кирка МакКузика конференции BSDCon 2003. Что, согласитесь, устарело, и приоритеты могли поменяться. Кстати, GJOURNAL к GEOM уже прикручен, но восторгу мало.

>НЕ РАСТЕТ, т.к. это совершенно независимые друг от друга параметры.

Кому ты это нах расказываешь? Это же известный на лоре троль и вендузятнег, но теперь он видно еще и к бздунам решил прибиться.

>> Ext3FS не может оперировать "фрагментами" блоков, она может выделять только отдельные блоки. Из-за чего быстрее растёт общая фрагментация файловой системы, чем на UFS2. Дисковое пространство на Ext3FS используется с той же эффективностью, что и на FAT32.

> Не растет фрагментация файловой системы из-за того, что для 100 байт данных используется 4 кб на диске. НЕ РАСТЕТ, т.к. это совершенно независимые друг от друга параметры.

Конечно независимые параметры! Их связывает в общую формулу ещё два параметра: количество файлов разного размера и процент заполнения диска. Ж) Так всё замечательно, когда диск заполнен на 10-50%, поверьте, всё очень быстро и там и там. Ж)

> Давайте не будем произность слово "никогда" в отношении тормознутой

http://posix.ru/system/test_free_vs_linux/

> фрагментированной Ext3FS

f-per 1.93%
blocks 6223179

f-per 1.24%
blocks 19358325

> с порушенным журналом.

Какой ужас, крушение журнала приведет к невозможности отмены последних транзакций, хоть плачь! Слив засчитан!

> Почему вырубают? Да потомушта пионэрия неасилила производительную работу с фрагментами блоков, вот и бросила на полпути.

Чтобы не было мусора внутри файлов при отмене транзакций.

> gjournal лично мне не нужен. Ну раз есть, то пусть будет, жалко что ли?

Ну что, ткнуть тебя еще ив сановский UFS с журналом, чтобы поумнел? Вот дефрагментация для ext3 не нужна, поэтому и дефрагментаторов нет, только для древней ext2 когда-то были, до того как в ext3 улучшили алгоритм выделения блоков, оптимизировав под минимальную фрагментацию.

Таки да.. И это не может не радовать.. Готовим обновления..

гуманитарий?

> а пакеты из stable только для некритичных к производительности приложений.

Для любых приложений, в т.ч. и требовательных к производительности. Точно также как и с энтерпрайзнутыми RHEL/SLES. Если бы они гонялись за 1-5% производительности, жертвуя стабильностью, ходя по граблям регрессий производительности, функциональных изменений приводящих к поломкам, то были бы не дебьянщиками, а гентушниками или бсдшниками.

> Тогда чем backports принципиально отличаются от ports FreeBSD? Вроде качество кода и там и там одно и то же, или нет? Во всяком случае ports во FreeBSD РАБОТАЮТ.

backports принципиально не отличаются. Они подключается как дополнительный официальный репозитарий и пакеты из него можно ставить _индивидуальные_(уже показывал пример /etc/apt/preferences для выбора некоторых пакетов из backports), вся остальная система остается стабильной и возможные проблемы из-за функциональных изменений будут наблюдаться _только_ с пакетами из бэкпортов, а не со всеми установленными портами как это происходит во фре. Если потребовалась новая версия программы, она была установлена из бэкпортов, при этом не торчит в сеть так что не создает угрозы для безопасности, то можно протестировать пакет и заморозить _индивидуально_ его обновление, поставив на hold. В этом вся гибкость.

> Вроде качество кода и там и там одно и то же, или нет? Во всяком случае ports во FreeBSD РАБОТАЮТ.

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

зря на альфу забили. Жаль. У меня как-раз две рабочии станции Compaq XP1000 появились.

Аналитики в курсе, что JunOS сделана на основе FreeBSD?

> Аналитики в курсе, что JunOS сделана на основе FreeBSD?

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

я рад

> Фишка фтом, што менеджер томов для ZFS НЕНУЖЕН. ;)

Кто вас убедил в этом ???? Как раз это тянет на недостаток ZFS.

> Роутер/VPN на 2 сетевых интерфейса. Вот ее продакшн-потолок в плане функциональности.

Это не так уж плохо. Вот в WinServer 2003 вообще нельзя вставить две карты - как я вот убедился, что никакой MCSE не в состоянии их правильно настроить. :)

Дык, с ветки на ветку только обезьяны прыгают!
(ИМХО) Трудоемкость таже что и при установке с нуля...
а потому бессмысленно. Прыгать стоит например с 6.2 на 6.3...
хотя... кто меня спрашивает?

Ну раз на то пошло, то это явление называется кластеризацией и приводит к неэкономному расходованию дискового пространства, но никак не влияет на производительность! // Demon37

> Кто вас убедил в этом ???? Как раз это тянет на недостаток ZFS.

Во фре есть два способа: заюзать GEOM-модуль + любая FS из поддерживаемых (а не только UFS) использовать ZFS, к-ая является и VM, и FS и прикручена к GEOM. Да, zfs является раздутым geom-модулем, к-ый носит в себе FS (все остальные модули выполняют только функции VM).

В линуксе есть возможность только использовать LVM + любая поддерживаемая им FS. Отсюда получаем секс в двойном размере, т.к. кроме FS надо еще трахаться с VM.

> чем так принципиально FreeBSD != к примеру Debian?

Только тем, что:
- API не ломается каждый раз при выходе нового ядра;
- Железа поддерживается пусть чуть меньше, но если оно поддерживается, то поддерживается нормально, а не через жопу (вспомним хотя бы ACPI);
- Более быстрая (по моим ощущениям) работа;
- Вообще меньше заморочек с системой;
- Есть гораздо более хорошая документация.

А вообще, ничем.

> Вот в WinServer 2003 вообще нельзя вставить две карты - как я вот убедился, что никакой MCSE не в состоянии их правильно настроить. :)

4.2

> Или обрадывались бабло крутым фирмам отваливать?

Видишь ли, мальчик... Есть такой принцип "система выбирается под задачу". И если у меня база на 40 гигов, данные раскиданы по 800 таблицам, и типичный запрос включает от 8 таблиц в выражение FROM, то никакой MySQL или PostgreSQL меня не спасут, и выбирать я буду Oracle (СУБД выбирается под задачу). А под Oracle Подставлю линукс, соплярис или винду (ОС выбирается под задачу).

http://www.opennet.ru/opennews/art.shtml?num=14429 новость на русском. Для тех кто не осилил вышеприведенные ссылки на англицком.

> чем так принципиально FreeBSD != к примеру Debian?

>Только тем, что:

>- API не ломается каждый раз при выходе нового ядра;

>- Железа поддерживается пусть чуть меньше, но если оно поддерживается, то поддерживается нормально, а не через жопу (вспомним хотя бы ACPI);

>- Более быстрая (по моим ощущениям) работа;

>- Вообще меньше заморочек с системой;

>- Есть гораздо более хорошая документация

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

Кто еще не понял - семерка это бомба по Линух. Потому что BSD не курятник с пристройками. Разница в количестве строк кода при примерно равных возможностях хорошо это показывает. Вобщем смотрим тесты, думаем..

Понаехало, блин...

ну это ты фре плюсы перечислил, причем очень очень очень сомнительные

1) API не ломается каждый раз при выходе нового ядра - тебя это так волнует???
2) Железа поддерживается пусть чуть меньше, но если оно поддерживается, то поддерживается нормально, а не через жопу - ага, только сейчас добавили поддержку emu10k и Marvell, это пиздец...
3) работа чего? гуя? если вы не можете позволить себе нормальный комп, то есть дистры линуса на компы от уровня 486 и выше - и работают они очень быстро
4) насмешил :)))) бубунту когда ставишь( от 7.10 ) вообще практически ничего не надо настраивать, или к примеру Suse - где такая вещь Yast есть
5) ни разу не встречал случая когда man или google не помог, если вам надо "более хорошая документаци", то видно вам надо что-то пособия:
- откройте файл такой-то
- замените то-то на то-то
- закройте файл
и т.д., а это называется руки :))))

плюсы линукса перечислять не буду - времени столько нет :))) но один пример- вы сами знаете, что у линукса гораздо более обширная область применения, в отличие от других ОС, фря - серверная ОС, винда - для юзерей и т.д., а линукс используется на серверах, десктопах, болидах F1, TOP500, КПК, мобилках, роботах и т.д. и т.п., так что если говорить о качестве ядра, то помолчали бы :)

http://www.opennet.ru/opennews/art.shtml?num=14429 Тут более менее вменяем расписано