> Таненбаум против Торвальдса - часть вторая

Второй раунд? Интересно кто кого отправит в нокдаун...

> Ок, какая система делает вклад в науку?

Cray :)

А если в данном случае "наука" == "computer science", то этих систем было много, и о них мало кто знает. Atlas, Hydra - из того, что знаю я.

Хотя мы тут наверное, все инженеры, и вот вклад Линуса и Linux в software engineering очень даже весом - выработка, обкатка и популяризация open-source модели разработки. То, что ESR назвал Bazaar.

Всё это жестокий оффтоп для этого треда 8)

>Ок, какая система делает вклад в науку?
система Си :-)

> "Время показало", что правда на стороне Линуса.

"Время показало" на стороне винды. Количественное преимущество налицо. Если судить такими категориями, то другие ОС вообще не нужны.

> а реально многие фишки мыкроядра - уже в linux kernel, например, подгружаемые модули и автомонтирование flash'ек.

Муахахахаха. Туземцы размышляют о ядерной физике.

> Откуда мне знать, что память съедается кешами, а не прожорливым софтом?

free прочитать по словам и понять, что же эта команда выводит.

>выработка, обкатка и популяризация open-source модели разработки

А что же папаша RMS и FSF все это время делали? Я думаю что приоритет все-таки за ними.

>>выработка, обкатка и популяризация open-source модели разработки

>А что же папаша RMS и FSF все это время делали? Я думаю что приоритет все-таки за ними.

А они Cathedral практиковали ;) И ты же не станешь спорить, что обкатка модели разработки на реально большом проекте, и популяризация - дело именно Linux?

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

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

Естественно, моё утверждение верно при правильном дизайне ОС.

Ну, почему большинство не понимает сути вопроса?

Вот, к стати пример живой ОС http://www.morphos.org/ , правда у вас она работать не будет ;-)) (а вот у меня работает)

> * QNX * Integrity * PikeOS * Symbian * L4Linux * Singularity * K42 * Mac OS X * HURD * Coyotos

L4Linux - это просто порт Линукса поверх микроядра. Дизайном там и не пахнет. Его используют исключительно для пиара и демонстрации скорости L4. Не следует считать что L4Linux - микроядерная ОС. Это заблуждение.

> А в прослойке между микроядром и пользовательскими задачами (т.е. в том, что мы называем ОС) блокировки как раз не нужны - потоки общаются между собой посредством сообщений. Вся синхронизация происходит на уровне IPC.

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

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

Он абсолютно прав. Его теория совершенно верная. Вы хоть одну его книгу прочитали или судите по отвывам тех, кто тоже не читал? А вот кодер он неважный. Это да.

Вклад в науку делают обычно экспериментальные системы, которые после выжимания всего этого "вклада" выкидывают на помойку. Имена их мало кому известны ;) Самая "попса" из них - план9, синерж, тот ж же миних, всякие наноядра...

А разработка "базарная" - Линусом только используется. Ничего нового в нее он тоже не принес (более того, он довольно хреново ее использует - если вспомнить, когда и как он начал применять управлениям версиями).

> И ты же не станешь спорить, что обкатка модели разработки на реально большом проекте, и популяризация - дело именно Linux?

Этим "делом" занимается и Linux ТОЖЕ. Наряду с апачем (включая все жабские приблуды на apache.org), иксами, мозиллой, гномом, кде,... Ничего пионерского (кроме наступления на грабли биткипера) Линус в этом месте не сделал.

> Но Линус написал ОС. Работающую ОС, которая уже известна всему миру. А профессор до сих пор теоретизирует и пишет игрушки для второклассников

Историю миникса знаешь? Он появился в аккурат после того, как AT&T ужесточила лицензию на юникс для учебных заведений. Миникс создавался исключительно для изучения внутренннего устройства операционных систем.

>> А в прослойке между микроядром и пользовательскими задачами (т.е. в том, что мы называем ОС) блокировки как раз не нужны - потоки общаются между собой посредством сообщений. Вся синхронизация происходит на уровне IPC.

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

Ну, почему же муйня... Считай, что для синхронизации используется передача сообщений, а данные, к которым есть параллельный доступ, имеются только в микроядре. Микроядро очень маленькое (4000 строк в Minix3), поэтому его планируется сделать bug-free. Совместно используемые ресурсы аппаратуры - это только процессор (им как раз занимается микроядро). У каждого девайса есть свой сервер (драйвер), который имеет эксклюзивный доступ к этому девайсу. Какие еще ресурсы аппаратуры, кроме CPU и девайсов?

И прочитай статью - там интересно :)

> тот же таненбаум просто не смог не заметить на l4linux но саныч ведь не читает статьи по ссылкам

Ёпт! Если L4Linux считать микроядерной операционной системой, то чем считать линукс под WMWare? Всё отношение l4linux к микроядру заключается лишь в том, что он работает поверх микроядра. От этого менее монолитным он не стал. Читать до просветления.

Вышла новая OPERA

10.05.2006 12:15 Linux ядро 2.6.16.15 и .16. Рост числа ошибок в 2.6 ядре тревожит разработчиков: http://www.opennet.ru/opennews/art.shtml?num=7488

Кому насрать?

> так что не надо ля-ля про смерть монолитного линукса - он уже обеспечил себе загробную жизнь в массово-параллельном мире

Там же на чистом английском языке написано что Linuз исполняется в userspace. Причём всем монолитом и исполняется. Просто парням из Дрездена нужно было показать крутость своего L4 Fiasco.

>> И ты же не станешь спорить, что обкатка модели разработки на реально большом проекте, и популяризация - дело именно Linux?

>Этим "делом" занимается и Linux ТОЖЕ. Наряду с апачем (включая все жабские приблуды на apache.org), иксами, мозиллой, гномом, кде

Все упомянутые вами проекты (кроме X) появились _позже_ Linux, а "жабские приблуды" - так и ГОРАЗДО позже, Еще раз - за счет своей величины и популярности Linux сделал гораздо больше, чем _любой_ другой проект. Так же, как Форд не изобретал автомобиль - но благодаря ему автомобиль пошел в массы. И автомобильных технологий на заводах Форда разработано было уйма.

> Sun-ch какая связь между микроядерностью и массовой параллельностью?

Inter Process Communication (IPC).

До Linux никто не верил, что сообщество сможет "с нуля" разработать такую сложную вещь, как Unix-like ядро. Linux это доказал (первые годы его разрабатывали почти исключительно добровольцы), и в open source поверили. Что не менее важно, и сообщество само в себя поверило.

Кстати, X - неудачный пример, его разработал консорциум университетов и корпораций. А когда появился XFree86 (IIRC, позже Linux), в его распоряжении была вся кодовая база X Consortium.

> Профессор по большей части не прав. То, что драйвер аудио, видео, принтера, сканера не могут прибить систему - это хорошо,

Так в чём же его неправота?

> но на критических системах обычно нет этих драйверов и нет (и драйверы принтеров/сканеров и так не в ядре). А баг в драйвере диска или ФС прибьет и MINIX тоже.

Баг в драйвере флоппи диска прибьёт этот драйвер, но система продолжит работать. Это утрированный пример. А вот другой пример - баг в драйвере файловой системы может перегрузить драйвер файловой системы, но TCP/IP стек при этом будет работать как ни в чём не бывало. Очень неплохая возможность для PC based марщрутизаторов.

>> тот же таненбаум просто не смог не заметить на l4linux но саныч ведь не читает статьи по ссылкам

>Ёпт! Если L4Linux считать микроядерной операционной системой, то чем считать линукс под WMWare? Всё отношение l4linux к микроядру заключается лишь в том, что он работает поверх микроядра. От этого менее монолитным он не стал. Читать до просветления.

В L4linux вроде как могут работать "родные" задачи L4? И если в L4Linux упадет Linux-сервер, "родные" L4-задачи продолжат работать, а Linux можно будет перезапустить. А в VMWare "родных" задач нет.

То есть Linux, он, конечно, монолитный. Но L4Linux - это на L4 больше, чем Linux :)

>Миникс создавался исключительно для изучения внутренннего устройства операционных систем.
И продавался за деньги. Студентам. Этот баум профессор или манагер по продажам?

> О DMA слышал, и даже программировал 8-P.

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

>> но на критических системах обычно нет этих драйверов и нет (и драйверы принтеров/сканеров и так не в ядре). А баг в драйвере диска или ФС прибьет и MINIX тоже.

>Баг в драйвере флоппи диска прибьёт этот драйвер, но система продолжит работать.

У меня вопрос - а если этот баг вызвал порчу данных? По-хорошему, сервер смонтированной с этого флоппи ФС должен устроить fsck после перезапуска, так? И что делать, если данные повреждены?

> А вот другой пример - баг в драйвере файловой системы может перегрузить драйвер файловой системы, но TCP/IP стек при этом будет работать как ни в чём не бывало.

Если его сервер не был запущен с той самой файловой системы, или после запуска его mlock в памяти. А если часть страниц процесса - в памяти, а часть - еще в файле? Вообще, вся эта "мультисерверная надежность" хорошо работает, пока данные всегда копируются. А если используется виртуальная память и demand-loading исполняемых файлов? Я не говорю, что всe это невозможно решить, но (ИМХО) это сложно. А сложность - враг надежности, о которой печется профессор.

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

И наконец, мнение показало что люди, на чьё мнение насрать разработчикам, "голосуют ногами" - т.е. уходят.

> Все упомянутые вами проекты (кроме X) появились _позже_ Linux,

Появиться - это одно. Стать большим проектом - другое. Апач появился 1994г (дада, сильно позже линухового анонса). В 1999г. - 68% серверов. Сколько тогда было машин с линухом?

> Еще раз - за счет своей величины и популярности Linux сделал гораздо больше, чем _любой_ другой проект.

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

> Кстати, X - неудачный пример

Почему это неудачный ?

> Если под понятием "процесс" понимается "изолированное адресное пространство с одной или несколькими нитями",

Верное определение процесса.

> то получается, что микроядро - это "маахонькое изолированное адресное пространство с одной или несколькими нитями, которое всего-то и умеет, что загружать/выгружать процессы ядра".

Я сейчас начну кипеть. Это _НЕПРАВИЛЬНЫЙ_ вывод на основе правильной предпосылки. Вы забыли о средставх взаимодействия потоков / процессов, без коих эти потоки и процессы не имеют практического смысла.

>И наконец, мнение показало что люди, на чьё мнение насрать разработчикам, "голосуют ногами" - т.е. уходят.
Примеры?
Таненбаум? Так он и не приходил :-)

>> О DMA слышал, и даже программировал 8-P.

О том, как программировал? Это просто - пишешь значения в регисры, а по завершению обмена приходит прерывание 8))))

>А с этого места пожалуйста подробнее. С каких это пор любой процесс микроядра может обращаться к любому диапазону портов ввода вывода?

Я этого и не говорил, гражданин судья! И вообще - я читал обсуждаемую статью, и ссылку на Reliability Fetures, реализованные в Minix3

[а что такое "процесс микроядра"? ;)]

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

Ну, если это и заблуждение - то не мое. Но дело в том, что при использовании DMA и отсуствии IOMMU драйвер может случайно или намеренно затереть ЛЮБУЮ область памяти в системе, даже не имея доступа к "чужим" портам и регистрам. Устройства оперируют физическими (ну ладно, шинными :)) адресами, мимо MMU, и пишут туда, куда скажет драйвер. Если же в системе есть IOMMU, и его контролирует микроядро - тогда другое дело. Если дать доступ к IOMMU драйверу - мы снова там, где начали.

> Как измерять будем? Статистику какую-нибудь имеете? Я вот, например, считаю, что мозилла и файрфокс сделали больше. И апач сделал больше.

Забудь. Ядро + терминал + Х !

> И вообще - вызывает сомнение, что полной надежности ОС можно достичь _только_ изоляцией процессов. Нужна возможность изолировать и "перезапускать" устройства - какой смысл перезапускать драйвер, если он уже "подвесил" устройство?

Что значит подвесил устройство? Почти все устройства поддерживают аппаратный сброс, так что проблема надумана.

> А как перезапустить сервер, который находится в середине стека?

Какого стека? Стека протоколов? Верхний протокол отвалится по таймауту. В резельтате какой либо вызов вернёт ошибку. Ничего фатального не случится.

> По теме: открытые микроядра - это Mach, Hurd и Minix 3 сейчас, может ещё какие есть ?

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

>Я сейчас начну кипеть.
Остынь и скажи, что произойдет в твоей микроядерной системе в случае отказа оборудования, к примеру, HDD, при условии:
1. модуль работает отлично, HDD сдох (физицски).
2. сбой модуля (ошибка в коде модуля, повторная его загрузка приводит к тому же сбою), HDD жив.

В чем преимущество микроядерного ядра (в реальной ситуации)?

>> то получается, что микроядро - это "маахонькое изолированное адресное пространство с одной или несколькими нитями, которое всего-то и умеет, что загружать/выгружать процессы ядра".

>Я сейчас начну кипеть. Это _НЕПРАВИЛЬНЫЙ_ вывод на основе правильной предпосылки. Вы забыли о средставх взаимодействия потоков / процессов, без коих эти потоки и процессы не имеют практического смысла.

Это был не вывод, а простая подстановка. Я ничего не забывал. То определение микроядра - оно не мое. Наличие в микроядре средств IPC не имело отношения к рассматриваемому вопросу.

Помимо IPC, в микроядра входят (обычно) еще планировщики ;) Но это тоже не имеет отношения к вопросу, который рассматривался. Вопросу о том, являются ли Win2k, QNX и Mach "микроядерными", если исходить из _приведенного_ определения.

И в том же посте я просил ссылок на общепринятое определение микроядра (только не википедию).

> Вообще хорошая идея - скачать миникс и посмотреть как это сделано там

первоначально достаточно почитать книгу Таненбаума "Разработка и реализация ОС", нам многое достаточно хорошо описано

>Хорошо что это работает: "О выставлении параметров"

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

Что касается кэшей - это легко посмотреть.

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

Вы не в теме. На примере какого устройство пояснить? Даю подсказку - как правило, непосредственно устройством управляет один поток. Все обращения к устройству выполняются из этого потока. Все остальные ядерные потоки взаимодействуют не устройством, а с управляющим потоком. Синхронизация происходит на уровне IPC.

Как страшно жить...

http://www.morphzone.org/ Микроядро на десктопе. Солидное количество пользователей, которые брезгуют PC. Чем не пример состоятельности микроядра? Или вашего внимания заслуживает только то, что работает на PC ??

>> И вообще - вызывает сомнение, что полной надежности ОС можно достичь _только_ изоляцией процессов. Нужна возможность изолировать и "перезапускать" устройства - какой смысл перезапускать драйвер, если он уже "подвесил" устройство?

>Что значит подвесил устройство? Привел его в состояние, из которого оно не может выйти.

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

Ээх... если бы 8( Ты драйверов не писал, так ведь? Как сказал Alan Cox: "Everything has bugs". Устройства тоже. Некоторые их этих багов обходятся в драйверах, некоторые - нет. Некоторые могут убить не только устройство, а и машину (на shared bus вроде PCI). Точно так же - ошибки в драйвере, причем этого никакое микроядро и не заметит.

>> А как перезапустить сервер, который находится в середине стека?

> Какого стека? Стека протоколов?

Да

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

А нижний?

Насчет ошибки - а если, скажем, пейджер не смог загрузить страницу процесса - процесс будет прибит? Если да, то получается, что, хотя система и выжила, приложение, ради которого система и нужна, померло. Где надежность?

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

>Объекты синхронизации нужны для пользовательских приложений. А в прослойке между микроядром и пользовательскими задачами (т.е. в том, что мы называем ОС) блокировки как раз не нужны - потоки общаются между собой посредством сообщений. Вся синхронизация происходит на уровне IPC.

>Естественно, моё утверждение верно при правильном дизайне ОС.

Тогда на каждое событие необходим запрос/ответ по ipc, что существенно медленнее блокировки в разделяемом контексте.

IPC - это главная характерная черта (и главный тормоз) microkernel.

>alman * (*) (16.05.2006 18:27:30)

>Баг в драйвере флоппи диска прибьёт этот драйвер, но система продолжит работать. Это утрированный пример. А вот другой пример - баг в драйвере файловой системы может перегрузить драйвер файловой системы, но TCP/IP стек при этом будет работать как ни в чём не бывало. Очень неплохая возможность для PC based марщрутизаторов.

Да, dma или bus master по линейному адресному пространству ядра - все умрут, хотя всего лишь один драйвер виноват...

>alman * (*) (16.05.2006 19:05:24)

> У меня вопрос - а если этот баг вызвал порчу данных? По-хорошему, сервер смонтированной с этого флоппи ФС должен устроить fsck после перезапуска, так? И что делать, если данные повреждены?

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

А вот в ситуации, когда данные не повреждены, система продолжает работать как ни в чем не бывало, в отличие от Kernel Panic и BSOD

> Если его сервер не был запущен с той самой файловой системы, или после запуска его mlock в памяти. А если часть страниц процесса - в памяти, а часть - еще в файле? Вообще, вся эта "мультисерверная надежность" хорошо работает, пока данные всегда копируются. А если используется виртуальная память и demand-loading исполняемых файлов? Я не говорю, что всe это невозможно решить, но (ИМХО) это сложно. А сложность - враг надежности, о которой печется профессор.

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

>http://www.morphzone.org/ Микроядро на десктопе. Солидное количество пользователей, которые брезгуют PC.
Ой, зря ты это здесь привел. Линуксоиды зайдут, посмотрят и уйдут, а вот виндузятники, которым надоело гадить здесь, найдут себе еще одну "отдушину" :-)
>Чем не пример состоятельности микроядра?
На отдельно взятой платформе. Ну и что?

> Как страшно жить...

Почему ?