DragonFly BSD 2.4

Для начала холивара можно освежить в памяти содержание предыдущих серий:

Интервью с разработчиками http://www.linux.org.ru/view-message.jsp?msgid=606190#comment-606784

Сравнение сабжа с Линуксом http://www.linux.org.ru/view-message.jsp?msgid=698731

Интервью с Диланом http://www.linux.org.ru/view-message.jsp?msgid=786158#comment-787069

Диллана Матвея, блджад. Матвея Диллана нах.

Кто-нибудь, убейте аффтара новости.

Во, новость толково оформлена. Сразу дан ответ на вопрос "а чем эта бздя лучше еще 10 других бздей".

Ты мне скажи чем Альт лучше других Линукс.. Чем хуже не надо, это и так все знают...

Казалось бы, причем тут альт?

А вы не с альта? Я вспомнил ваш предидущий аватар "пингвина с молотком" и у меня это вызвало определённые асоциации.

Сделайте в предидущем моём посте 's/Альт/ваш любимый дистр/'

> А вы не с альта? Сделайте в предидущем моём посте 's/Альт/ваш любимый дистр/'

Я с дебьяна. Дебьян хорош тем, что "просто работает".

> Я вспомнил ваш предидущий аватар "пингвина с молотком" и у меня это вызвало определённые асоциации.

Можете их озвучить? Не знал, что альт как-то связан с кувалдами. И боюсь даже предположить, какие ассоциации может вызвать нынешний аватар :D

>Я с дебьяна. Дебьян хорош тем, что "просто работает".

А я с генты которая лучше и быстрее деба, но топик сегодня не об этом...

>> Я вспомнил ваш предидущий аватар "пингвина с молотком" и у меня это вызвало определённые асоциации.

>Можете их озвучить? Не знал, что альт как-то связан с кувалдами. И боюсь даже предположить, какие ассоциации может вызвать нынешний аватар :D

Оставлю эти фантазии при себе.. хорошо?

Может кто просветит чем особенно хороша данная FS? Особенно интересно если вы ее где то применяете или применяли.

> А я с генты которая лучше и быстрее деба

Критерий относительно скорости такой: компьютер должен ждать когда пользователь отреагирует, пользователь же должен получать реакцию компьютера моментально, без ожидания. С этой колокольни разницы между дебом, гентой и почти любым другим дистром - нету. За то деб максимально отлажен и не требует возни (которая лично мне абсолютно не интересна).

> но топик сегодня не об этом...

Да. Мне тоже не понятно, зачем ты поднял эту тему: http://www.linux.org.ru/jump-message.jsp?msgid=4071750&cid=4072014 ;)

> Существенным недостатком системы субъективно считаю сложность мат-модели

Можно попросить линк на мат модель? В википедии ссылка на первоисточник дохлая. Ковыряться в официальном сайте - не Ъ.

> Может кто просветит чем особенно хороша данная FS?

http://www.dragonflybsd.org/hammer/hammer.pdf

facepalm.gif
Либо «робот переводчик использовать идея дурак», либо «русская езыка сцуко сложная».

>считаю сложность мат-модели

Неужели материться на моделей так сложно?

// Нет, это не Петросян. Это Розенталь.

Видите ли... Фундаментальные недостатки неоклассических ядер пока не перевешивают недостатки Стрекозы как крайне непопсовой системы. Если считать априори, что аудитория фрюниксов хотя бы наполовину состоит не из хомячков, и что она принимает решения осознанно, можно сказать, что хороший дизайн (в смысле архитектура) для системы значит не так много, как хотелось бы. Если допускать здоровый цинизм, то при всех отдельных достоинствах различных BSD систем, а также опенсоляриса, Linux остаётся наиболее обжитой и безпроблемной системой из FOSS OS. Пока что это перевешивает всё остальное. Почему так вышло? В лицензии ли тут дело, или в мировом заговоре, но из фриниксов только Линукс может пока считаться реальным конкурентом венде на любых фронтах.

т.е система будет хорошо работать с двумя ядрами также как с двумя процессорами?

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

Это не повод сворачивать исследования в области архитектуры. Всевозможные minix, l4 и прочие DragonFly крайне полезны для дальнейшего развития FOSS.

Меня подташнивает и от POSIX, и от ISO C. И то, и другое по самые помидоры перегружено всевозможным legacy. Из-за большого объема они тяжелы для первоначального освоения, а корректность их использования всегда не очевидна. Тут я хочу в очередной раз плюнуть в спину тем, кто не знает про sequence points в си; и тем, кто не проверяет код возврата системного вызова close; и тем, кто полагает, что системный вызов write не может завершиться после записи только части буффера; и тд и тд - многие даже не догадываются, что их код по пояс в дерьме.

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

> не проверяет код возврата системного вызова close

Всегда было интересно - ну, вернул close ошибку, и что с ней делать? %)

> Нужно сказать большое Спасибо людям, которые тратят свою драгоценную жизнь и свои силы на исследования в области архитектур ОС и языков

И как же их усилия спасают тебя от ISO C и POSIX?

> Всегда было интересно - ну, вернул close ошибку, и что с ней делать? %)

Например, не делать rename временного файла на постоянный.

> И как же их усилия спасают тебя от ISO C и POSIX?

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

> спасают тебя от ISO C и POSIX?

Нас с тобой уже не спасти. Спасти можно тех, кто придет после нас.

>> спасают тебя от ISO C и POSIX?

> Нас с тобой уже не спасти. Спасти можно тех, кто придет после нас.

А их как спасает? Все эти миниксы и стрекозы - тот же ISO C и POSIX.

> Все эти миниксы и стрекозы - тот же ISO C и POSIX.

Внути себя стрекоза пытается быть дюже асинхронной, построенной на сообщениях (привет l4). POSIX для нее - лишь обертка. Нужная для совместимости с юзерспейсом. И не самая интересная, как я подозреваю.

От Си она никак не спасает. Для этого есть другие проекты. В частности, oberon.

> Всегда было интересно - ну, вернул close ошибку, и что с ней делать? %)

:)))) Поступить как настоящий индус - присвоить это локальной переменной и выйти из функции. Но потом не удивляться, что вся система насквозь дырявая и глюкавая.

Си давно уже просится на костёр, POSIX - в землю, но привычка трясти традициями не даёт это сделать - цепляются за свои тухлые поделки, поддерживая совместимость - создаётся ощущение, что они собираются жить со своими поделками в 22 веке...

>> Всегда было интересно - ну, вернул close ошибку, и что с ней делать? %)

> :)))) Поступить как настоящий индус - присвоить это локальной переменной и выйти из функции.

О, я знал, что Великий Матумба поможет дельным советом.

>> Все эти миниксы и стрекозы - тот же ISO C и POSIX.

> Внути себя стрекоза пытается быть дюже асинхронной, построенной на сообщениях (привет l4)

На l4 это не похоже совсем - то же монолитное ядро, "you go - we go" (c) Да и вообще - 6 лет в разработке, а где профит?

> POSIX для нее - лишь обертка.

POSIX - ее основной (и единственный на сегодня) API.

> От Си она никак не спасает. Для этого есть другие проекты. В частности, oberon.

Доо, уж лет 20 он спасает нас от Си, да никак не спасет. "Это не борьба, и это не результат" (с)

Только не нужно при этом так явно обсирать то, что работает, причём работает неплохо

> На l4 это не похоже совсем - то же монолитное ядро

В плане монолитности - не похоже. В плане обмена сообщениями - сходство есть.

> POSIX - ее основной (и единственный на сегодня) API.

Не вполне так.
http://www.dragonflybsd.org/goals/#messaging
http://www.dragonflybsd.org/goals/#userapi

> Доо, уж лет 20 он спасает нас от Си, да никак не спасет. "Это не борьба, и это не результат" (с)

Результат: спецификация Oberon07 занимает 14 страниц, спецификация ISO/IEC 9899:TC2 занимает 550 страниц. Хотя обе спецификации не полны в том смысле, в каком мне хотелось бы.

> Только не нужно при этом так явно обсирать то, что работает, причём работает неплохо

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

>> POSIX - ее основной (и единственный на сегодня) API.

> Не вполне так.

> http://www.dragonflybsd.org/goals/#messaging

> http://www.dragonflybsd.org/goals/#userapi

От того, что ты завернешь POSIX-вызов в сообщение, он не перестанет быть POSIX-вызовом.

>> Доо, уж лет 20 он спасает нас от Си, да никак не спасет. "Это не борьба, и это не результат" (с)

> Результат: спецификация Oberon07 занимает 14 страниц, спецификация ISO/IEC 9899:TC2 занимает 550 страниц

Это не результат. Не знаю, читал ли ты великий флем начала 80-х "Pascal vs C". Если не читал - рекомендую, очень поучительно.

> От того, что ты завернешь POSIX-вызов в сообщение, он не перестанет быть POSIX-вызовом.

Posix живет исключительно в emulation layer. А нативный message-based api к posix-у особо не привязан.

> Не знаю, читал ли ты великий флем начала 80-х "Pascal vs C". Если не читал - рекомендую, очень поучительно.

Давай линк :)

>> Результат: спецификация Oberon07 занимает 14 страниц, спецификация ISO/IEC 9899:TC2 занимает 550 страниц

> Это не результат.

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

Отличная новость! У кого-нибудь есть опыт юзания HAMMER в продакшн? Насколько надёжно?

>> От того, что ты завернешь POSIX-вызов в сообщение, он не перестанет быть POSIX-вызовом.

> Posix живет исключительно в emulation layer.

POSIX живет в генах.

> А нативный message-based api к posix-у особо не привязан.

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

>> Не знаю, читал ли ты великий флем начала 80-х "Pascal vs C". Если не читал - рекомендую, очень поучительно.

> Давай линк :)

"Языки программирования Си, Pascal и Ada - сравнение и оценка"

>>> Результат: спецификация Oberon07 занимает 14 страниц, спецификация ISO/IEC 9899:TC2 занимает 550 страниц

>> Это не результат.

> Почему ты так считаешь? Аргументируй.

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

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

:D Именно в 10? Не в 8, не 4?

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

Не знаю, по той же ссылке написано, что они перекроили VFS. Про MESI применительно к кускам файлов. Про асинхронность большинства девайсов. Ты вычитвыал исходники стрекозы (в сравнении с фряхой), чтобы утверждать о суровой позиксовости подсистем? Форк он на то и форк, что постепенно расходится с прародителем.

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

Десяток реализаций наберется. Про жизнь ничего сказать не могу, но операционная система на обероне написана :)

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

> :D Именно в 10? Не в 8, не 4?

Примерно в 10. Может - в 20, а может - и в 5. Я на глазок оценил, исходя из объема спецификации ,)

> "Языки программирования Си, Pascal и Ada - сравнение и оценка"

По этому запросу гугл дает одну-единственную ссылку: на твое сообщение.

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

Всё это - перекhаивание внутриядерных интерфейсов, но не семантики пользовательских API (просто потому, что новая ОС с POSIX-несовместимым API никому не нужна).

> Ты вычитвыал исходники стрекозы (в сравнении с фряхой), чтобы утверждать о суровой позиксовости подсистем?

Нет. Я читал роадмап и сообщения о статусе - ни на что, отличное от POSIX, претензий там не было.

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

> Десяток реализаций наберется

Независимых? Или все из ETH?

> операционная система на обероне написана :)

Ну надо же было куда-то приложить любимую игрушку.

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

Уууу... man cyclone, man ivy, man jekyll - если Си и заменят на что нибудь, то на что-то похожее.

>> "Языки программирования Си, Pascal и Ada - сравнение и оценка"

> По этому запросу гугл дает одну-единственную ссылку: на твое сообщение.

Наверное, потому, что это бумажная книга? %)

> Всё это - перекhаивание внутриядерных интерфейсов, но не семантики пользовательских API (просто потому, что новая ОС с POSIX-несовместимым API никому не нужна).

Posix api обеспечивается отдельным compatability layer. В том числе, и posix семантика.

> Наверное, потому, что это бумажная книга? %)

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

> Уууу... man cyclone, man ivy, man jekyll - если Си и заменят на что нибудь, то на что-то похожее.

Ни один из них не избегает главной проблемы Си: нетривиальной, требующей экспертных знаний, семантики.

>> Всё это - перекhаивание внутриядерных интерфейсов, но не семантики пользовательских API (просто потому, что новая ОС с POSIX-несовместимым API никому не нужна).

> Posix api обеспечивается отдельным compatability layer. В том числе, и posix семантика. "Creating a Portable User API" - это просто механизм вызова.

Блин. Откуда это вообще? Вот цели проекта: http://www.dragonflybsd.org/goals/ Создания не-POSIX API для userspace здесь просто нет.

>> Наверное, потому, что это бумажная книга? %)

> В таком случае, ни один интернет-магазин ей не торгует. И скачать ее нигде не предлагают.

Она старая - 1982 или около того.

> не избегает главной проблемы Си: нетривиальной, требующей экспертных знаний, семантики.

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

> Создания не-POSIX API для userspace здесь просто нет.

Всему свое время.

>> не избегает главной проблемы Си: нетривиальной, требующей экспертных знаний, семантики.

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

Лично ты ее знаешь?

>> Создания не-POSIX API для userspace здесь просто нет.

> Всему свое время.

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

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

> Лично ты ее знаешь?

Не уверен (например, за определением sequence point вечно лезу в гугль). Но никогда не имел проблем от этого незнания.

> Не уверен (например, за определением sequence point вечно лезу в гугль). Но никогда не имел проблем от этого незнания.

За то я видел много кода, который от смены компилятора вдруг менял свое поведение. Видел код, где программист имел ввиду одно, а компилятор понял совсем другое (потому что местами спецификации языка нихрена не интуитивные).

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

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

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

Нет, это всего лишь libvanga.so :)

> Но я думаю, что Диллону даже по опубликованным целям хватит работы еще на годы.

Дык это ж опен сорс. Если проект будет успешным, и без Диллона докрутят. В опубликованных планах _эмуляция_ linux, freebsd, и тд. И переделка внутренностей для messaging. Это значит, что нативный апи имеет все шансы уплыть далеко от posix-a.

> я видел много кода, который от смены компилятора вдруг менял свое поведение. Видел код, где программист имел ввиду одно, а компилятор понял совсем другое (потому что местами спецификации языка нихрена не интуитивные)

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

> Твоя позиция - наиболее распространенная. Человек искренне уверен, что знает, что он пишет.

Или он и в самом деле это знает.

> с posix та же хрень. Не слишком эффективный по отношению к аппаратуре

Фигасе. Раскрой тему, а? Я драйверы пишу, если что. Хочу знать, как POSIX мне мешает.

> абсолютно не очевидный в использовании.

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

> Значительная часть имеющегося кода не не способна сколько-нибудь вменяемо реагировать на ошибки. Глюкодром.

Это не проблема POSIX.

Отлично оформленная новость. Спасибо.

Молодец Матвей.

http://faqs.org.ru/progr/other_l/adafaq2.htm

2. Языки пpогpаммиpования Ада, Си, Паскаль. Сpавнение и оценка.
Сб. статей п/p А.Фьюэpа и H.Джехани. М.:Радио и Связь, 1989

Hазвание говоpит само за себя. Как сбоpник статей почтенного
возpаста, эта книжка заметно утpатила актуальность. Хотя все еще
может быть если не полезна, то интеpесна.

Статьи "алгольщиков" отличаются тонким юмоpом, блеском и
иногда жестоким саpказмом ( местами невозможно удеpжаться от
злоpадного смеха ). Хоpошая иллюстpация к Янгу.

Изложена и обоснована мысль о том, что многие "маленькие/
компактные" ЯВУ таковыми только кажутся вследствие неполноты
описания ( камешек в огоpод уважаемого ( без тени иpонии )
сэнсэя H.Виpта ).

p.s. use www.nigma.ru ))

> альтернативный путь развития ядра
И эти люди ещё упрекают в зоопарке пингвиньих дистрибутивов! Тут хоть ядро единое.

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

Чтоб далеко не ходить, http://www.linux.org.ru/view-message.jsp?msgid=3880660 . И попытка разобрать полеты: http://www.linux.org.ru/jump-message.jsp?msgid=3880660&cid=3881595

> Или он и в самом деле это знает.

Если он не взботнул хотя бы 550 страниц Стандарта, знать этого он не может. Более того, взботнуть Стандарт - не достаточно. Нужно пристально его анализировать: "чего же в нем не обещано такого, на что я могу неосознанно рассчитывать".

>> с posix та же хрень. Не слишком эффективный по отношению к аппаратуре

> Фигасе. Раскрой тему, а? Я драйверы пишу, если что. Хочу знать, как POSIX мне мешает.

Например, поковыряй в окрестностях этого поста: http://lkml.org/lkml/2009/3/27/310 Вкратце. Для железа, ФС и многих юзерспейс приложений очень хорошо подошел бы системный вызов fbarrier - но его в дремучем posix нет. За то в posix есть fsync, который предоставляет больше гарантий, но за то убивает производительность. То есть posix не позволяет использовать дисковую подсистему с дОлжной эффективностью.

>> Значительная часть имеющегося кода не не способна сколько-нибудь вменяемо реагировать на ошибки. Глюкодром.

> Это не проблема POSIX.

Нет, это проблема POSIX. Проблема в том, что он предоставляет api, располагающий к некорректному использованию. Недавний срач вокруг ext4, говенного userspace софта и обнулившихся файлов - тому подтверждение.

>И эти люди ещё упрекают в зоопарке пингвиньих дистрибутивов! Тут хоть ядро единое.

Свобода выбора — это прекрасно. Главное, чтобы хватало ресурсов поддерживать поиски в альтернативных направлениях, не оставляя мейнстрим застрявшим в болоте.

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

P.S. Да, огромное человеческое спасибо тому модератору или корректору, который расставил запятые. Новость оформлена хорошо, но без запятых читать ее было нелегко.

> великий флем начала 80-х "Pascal vs C"

гы

> начала 80-х

Тут этот флейм всякий раз возобновляется, как только выйдет новая версия fpc или lazarus. Или кто-нибудь поимеет неосторожность на них прикладную программу написать.

А раньше ещё и кайликс был, и на нём тоже имели неосторожность писать. Я думаю, что Великий Срач По Ссылке Ниже четырёхзвёздный tailgunner наверняка помнит:

http://www.linux.org.ru/view-message.jsp?msgid=114929