> Но дело даже не в этом, а в дезинформации, которой в
> OpenBSD кормят пользователей, и в ложных отговорках против чего угодно необычного.Эту мысль ты уже озвучивал, и я с ней полностью согласен.
"Деза" вредна даже не для пользователей, а для самой системы и ее разработчиков.
И насчет примера про переполнение целого в Жабе я с тобой тоже согласен.
Мягко говоря, некрасиво. В NetBSD (пардон :-) ) давно признают, что по поддержке
железа Линупс их давно обогнал. Поддержка современного железа тоже,
насколько мне известно, не всегда на высоте. Поддержку SheevaPlug, к примеру,
по-моему вот только-только сделали, было письмо в ports-arm@.
Но здесь я не уверен, я не по этим делам.
Вообще, я считаю, NetBSD имидж "Of course it runs NetBSD"(C) только вредит,
но это так, к слову.
> Кстати, лгут и лицемерят многие, не только разработчики OpenBSD. Я об этом
> тоже стараюсь упоминать, если уж разговор заходит.
Вот именно.
> Я не говорил обо всех BSD. Во FreeBSD практически не решаются проблемы
> безопасности, но в остальном другие BSD гораздо реже брезгуют чем-то новым,
> более полезным.
patch? ;-)
> К слову, если /proc/<pid>/maps доступен для чтения не только root'у и владельцу
> процесса, то это источник информации для написания более надёжных эксплойтов.
Согласен. Но ASLR в NetBSD нет как класса, поэтому проблема пока не актуальна.
По к. PIE тоже нет AFAIK.
Когда/Если появится, надо будет иметь ввиду.
Мне /proc/$$/maps был нужен для моего отладчика.
>> То есть, я бы сказал, вполне адекватно они воспринимают окружающий мир.
> Проблемы безопасности недооцениваются почти повсеместно.
> У меня даже сложилось впечатление,
> что либо разработчики не соприкасались с этими проблемами на серьёзных объектах,
> либо не замечали следов и последствий проникновения...
Ну, возможно процесс идет не так быстро, как некоторым хотелось бы,
но он как-то идет, и в этом направлении тоже.
Повторюсь, многие вещи объясняются сильно
ограниченными людскими ресурсами. Можно по этому поводу долго сокрушаться,
но факт остается фактом. Что касается аналогов pax и grsecurity,
я не могу сказать, есть ли что-то подобное в NetBSD или нет.
Скорее всего, нет.
Я согласен, дополнительной степенью защиты от дырок в ядре
является более полная защита пользовательских процессов от самого ядра
специальными средствами. Ну что тут добавить?
>> сколько денег (времени) понадобиться для того, чтобы
>> обучить каждого разработчика {Net,Open,Free}BSD
>> языку Erlang, D или Oberon2? Сколько времени понадобится на поддержку кода g++?
> На Erlang вместе с OTP - месяца 2, часа по 3-4 в
> день. На обероны примерно столько же. D относительно более сложный -
> допустим, на него уйдёт около полугода. Это в случае с Си
> нужно годами учиться нюансам и дисциплине, и толку не много будет.
Ну, Оберон ладно. Банальная императивщина. Насчет Erlang-а я не согласен.
Функциональная парадигма -- не для всех, не говоря уже об ОБЪЕКТИВНЫХ
сложностях в реализации на соответствующих ЯП сложных нетривильных алгоритмов,
для которых имеются императивные описания, начиная с 50-60.
Для ФП их нужно переформулировать, т.е. переизобретать ЗАНОВО.
По этому вопросу люди пишут диссертации и толстенные книги. Оно надо?
В общем случае, выхлоп неочевиден. Кроме того ФЯП для типичных приложений
и не нужны.
> И таки да, вопрос лицензии в OpenBSD - это всегда очень отдельный
> вопрос. ;)
В NetBSD GPL тоже не любят, уверен, как и во FreeBSD, но в первую очередь
смотрят на качество, судя по тому, что я вижу. Прежде чем выбросить GNU groff
и заменить его нделана огромная работа. GNU grep
не смотря на все усилия многих BSD-шников пока идет по дефолту.
То есть пыхтят, стараются, но выбросят только тогда, когда сделают лучше.
Беспричинные регрессии в качестве не допускаются.
На GNU toolchain тоже скрипят зубами, но делать другой банально некому.
> Во многих других системах он как-то менее выражен, чем в OpenBSD.
Возможно, OpenBSD меня, честно говоря, интересует постольку поскольку.
Я не люблю системы с ярковыраженным Фюрером во главе.
На мой взгляд BSD-унам нужен общий userspace.
Это высвободило бы значительную часть людских ресурсов.
То же касается всяких там Minix-ов, Syllable-ов.
Пилите свои ядра хоть до посинения, но зачем ls каждому свой???
И то же самое относится к пакетным системам.
Вот, Диллон (добрый фюрер) перешел на pkgsrc 5 лет назад.
Minix тоже совсем недавно. pkgsrc под QNX кто-то там пинает,
но не сильно успешно.
>> Вот почему, скажем в Линупсе нет kqueue???
> Разговор принимает всё более неожиданные повороты. :) NIH-синдром всюду, это и так
> понятно.
Ну а к чему тогда сокрушаться по этому поводу, выставляя именно
OpenBSD-шников? ;-) В этом плане все одинаково хороши.
>> Параноики в AltLinux глаза двух Богов не побоялись, включили у себя в
>> libc функции strlcat/strlcpy. Честь им и хвала, хоть в этом, за
>> смелость.
> Будет честь и хвала, когда возьмутся за защиту ядра.
Что-то мне подсказывает, что альтовцы здесь есть,
и, возможно, уже приняли к сведению ;-)
Ядер у них в комплекте точно больше одного.
Вполне прилично собираются модули для каждого в виде отдельного пакета.
То есть инфраструктура вроде есть и налажена.
В принципе, они известны своей паранойей.
При наличии желания пнуть их не проблема.
А самому сделать -- еще надежнее ;-)
>> Ядро и юзерспейс на SML или Caml? Прикольненько! ;-) Я буду одним
> Тогда уж на обероне, но это всё мечты, мечты.
Как бы там ни было, все это сейчас на уровне университетского проекта,
а еще точнее, набора голых идей.
>> Кодогенерация в язык С в подавляющем большинстве случаев является совершенно убогой и
>> кривой технологией, о которой нужно писать в книжках как об эпохе
>> древних вымерших мамонтов.
> Так надо писать о Си и ему подобных вообще.
С -- значительная и поучительная часть истории и сегодняшнего дня IT.
Его нельзя не изучать.
>> Рассматривались другие варианты типа scheme. Жирные Python, Perl, Tcl отмелись мнгновенно.
> Если Scheme рассматривался всерьёз, снимаю шляпу перед разработчиками NetBSD.
Мне трудно судить о глубине знаний функциональной парадигмы
всех разработчиков NetBSD. Но предложение такое было.
На мой взгляд scheme лучше clisp, но ничего ТАКОГО он
из себя не представляет. Для типичных несложных задач Lua и JavaScript лучше.
По уровню "легковесности", повторюсь, очень важный фактор, Scheme
вполне им неплохой конкурент. Для встраивания тоже подходит хорошо.
