> Я не могу сказать ничего про OpenBSD. Но вот в NetBSD после
> долгого и кровопролитного
> (почти без кавычек) обсуждения все-таки приняли решение включить Lua в базовую систему.Вот. В OpenBSD такие перемены очень сложно представить - прецедентов не было. Но дело даже не в этом, а в дезинформации, которой в OpenBSD кормят пользователей, и в ложных отговорках против чего угодно необычного.
Кстати, лгут и лицемерят многие, не только разработчики OpenBSD. Я об этом тоже стараюсь упоминать, если уж разговор заходит.
> Во FreeBSD тянут D-Trace и zfs.
> То есть не совсем уж BSD-ки невосприимчивы ко всему новому. Не знаю,
> как во FreeBSD
Я не говорил обо всех BSD. Во FreeBSD практически не решаются проблемы безопасности, но в остальном другие BSD гораздо реже брезгуют чем-то новым, более полезным.
> и периодически тянут оттуда внутриядерные API для подсистем. Кое-что тянут и из
> Линукса, скажем /proc/cpuinfo и /proc/<pid>/maps. Мелочи, но тем не менее.
К слову, если /proc/<pid>/maps доступен для чтения не только root'у и владельцу процесса, то это источник информации для написания более надёжных эксплойтов.
> То есть, я бы сказал, вполне адекватно они воспринимают окружающий мир.
Проблемы безопасности недооцениваются почти повсеместно. У меня даже сложилось впечатление, что либо разработчики не соприкасались с этими проблемами на серьёзных объектах, либо не замечали следов и последствий проникновения... Либо вся ценная информация была похищена с машин под виндой, как это обычно и случается. Юниксы в последнем случаяе выступают в роли гордых неуловимых джо и защищены соответственно.
> Но надо иметь ввиду вот что. BSD - это не линупс и
> не соляра.
> Здесь нет миллиардов/миллионов вливаемых
> долларов, поэтому очень важный момент -- эффективность труда каждого
> отдельного человека и соответственное всего процесса разработки. Я не оправдываю имеющийся
> консерватизм, но все же, сколько денег (времени) понадобиться для того, чтобы
> обучить каждого разработчика {Net,Open,Free}BSD
> языку Erlang, D или Oberon2? Сколько времени понадобится на поддержку кода g++?
На Erlang вместе с OTP - месяца 2, часа по 3-4 в день. На обероны примерно столько же. D относительно более сложный - допустим, на него уйдёт около полугода. Это в случае с Си нужно годами учиться нюансам и дисциплине, и толку не много будет.
C g++ правильно поступили.
> Ну а с тем, сколько "весят" Erlang и Oberon2 надо еще разобраться.
Вот именно. Было бы желание.
> Я не интересовался. Отдельный вопрос по лицензии.
Эрланг под деривативом Mozilla Public License, D2 - зависит от компилятора (есть под BSD+GPL). Обероны - большинство под BSD, OCC под GPL+LGPL.
И таки да, вопрос лицензии в OpenBSD - это всегда очень отдельный вопрос. ;)
> Что касается NIH синдрома. Да покажите мне ХОТЬ одну систему, где его
> нет!
Во многих других системах он как-то менее выражен, чем в OpenBSD.
> Вот почему, скажем в Линупсе нет kqueue???
Разговор принимает всё более неожиданные повороты. :) NIH-синдром всюду, это и так понятно.
> А эти "аргументы" про "мастурбирующих обезъян" или "некомпетентных идиотов".
> Ну это это чистая дикость!
Согласен, это даже в комментариях не нуждается.
> Параноики в AltLinux глаза двух Богов не побоялись, включили у себя в
> libc функции strlcat/strlcpy. Честь им и хвала, хоть в этом, за
> смелость.
Будет честь и хвала, когда возьмутся за защиту ядра.
> Ядро и юзерспейс на SML или Caml? Прикольненько! ;-) Я буду одним
Тогда уж на обероне, но это всё мечты, мечты.
> Кодогенерация в язык С в подавляющем большинстве случаев является совершенно убогой и
> кривой технологией, о которой нужно писать в книжках как об эпохе
> древних вымерших мамонтов.
Так надо писать о Си и ему подобных вообще.
> Если уж брать Oberon2 (допустим, решили, что берем), то нормальный, с местным
> компилятором, еще лучше прикрутить его к llvm или к pcc, там
> вроде тоже есть внутренний язык, через который собственно кодогенерация машинного кода
> и происходит, вместе с оптимизацией.
Эх, если бы. Но у меня вызывает возражения не отсутствие оберонов в опене (это их дело), а казуистика и лживые аргументы против любых альтернатив. Все эти игры в слова вокруг integer overflow, превознесение аудита, скачка файлов с нескольких зеркал и прочие глупости.
> Язык D? Я не в курсе, насколько он велик, и не уверен
> насчет его портабельности и кросс-собираемости. Именно эти три фактора были решающими
> при выборе Lua в NetBSD.
D сложноват. У него есть более простые альтернативы в лице оберонов, а также функциональных языков (в частости, эрланга) для решения прикладных задач.
> Рассматривались другие варианты типа scheme. Жирные Python, Perl, Tcl отмелись мнгновенно.
Если Scheme рассматривался всерьёз, снимаю шляпу перед разработчиками NetBSD.
