>> А вот этого не надо. От замшелого PCC 70-х сейчас там практически
>> ничего не осталось.
> Я о другом хотел сказать: у них всегда находятся отговорки, чтобы не
> использовать что-то, выходящее за рамки привычных, но морально устаревших технологий,
> и при этом на доводку и переделывание привычного выделяются очень значительные
> ресурсы, которых было бы вполне достаточно для создания того же транслятора
> оберона в Си, для освоения эрланга под прикладные задачи и т.п..
> Плюс NIH-синдром.Я не могу сказать ничего про OpenBSD. Но вот в NetBSD после долгого и кровопролитного
(почти без кавычек) обсуждения все-таки приняли решение включить Lua в базовую систему.
Во FreeBSD тянут D-Trace и zfs.
То есть не совсем уж BSD-ки невосприимчивы ко всему новому. Не знаю, как во FreeBSD
и в OpenBSD, а в NetBSD опять же с большим уважением относятся к дизайну Соляриса,
и периодически тянут оттуда внутриядерные API для подсистем. Кое-что тянут и из Линукса, скажем /proc/cpuinfo и /proc/<pid>/maps. Мелочи, но тем не менее.
Несколько лет назад, оплатив услуги одного (одного!!!) человека избавились практически полностью от Giant lock, и реализовали 1:1 потоки,
не растягивая этот процесс на 8 лет, в отличие от других.
Кого это касается, поймут ;-) Правда, с sheduled activations поигрались в 2.0-4.0,
но аккуратнее, никого не тряся и не сбрасывая с лодки.
С другой чтороны FUSE реализовали лучше, чем у других, не став тупо копировать
чужие ошибки проектирования.
Включили, наконец, stack smashing protection по умолчанию.
Вроде и на ядро, и на libc и на юзерспейс, но тут надо проверить.
Обсуждалось по крайней мере тоже долго.
То есть, я бы сказал, вполне адекватно они воспринимают окружающий мир.
Но надо иметь ввиду вот что. BSD - это не линупс и не соляра.
Здесь нет миллиардов/миллионов вливаемых
долларов, поэтому очень важный момент -- эффективность труда каждого
отдельного человека и соответственное всего процесса разработки. Я не оправдываю имеющийся консерватизм, но все же, сколько денег (времени) понадобиться для того, чтобы обучить каждого разработчика {Net,Open,Free}BSD
языку Erlang, D или Oberon2? Сколько времени понадобится на поддержку кода g++?
Выкинули его из базовой системы -- и правильно сделали. Выкинули плюсовый groff --
туда ему дорога, следом за С++.
Оно дешевле в долговременной перспективе. И по деньгам и по времени.
Ну а с тем, сколько "весят" Erlang и Oberon2 надо еще разобраться.
Я не интересовался. Отдельный вопрос по лицензии.
Что касается NIH синдрома. Да покажите мне ХОТЬ одну систему, где его нет!
Вот почему, скажем в Линупсе нет kqueue???
Или strl* - так это же вообще сказка. Два человека, Торвальдс и Дреппер против.
Все, пипец. Эти функции есть ВЕЗДЕ (Cygwin, Interix, Haiku, OpenBSD, NetBSD, DragonFlyBSD, MacOS-X, Solaris, IRIX).
А эти "аргументы" про "мастурбирующих обезъян" или "некомпетентных идиотов".
Ну это это чистая дикость!
Параноики в AltLinux глаза двух Богов не побоялись, включили у себя в libc функции strlcat/strlcpy. Честь им и хвала, хоть в этом, за смелость.
>> Не надо ля-ля. Это сильно зависит от конкретного типа и вида "типобезопасного"
>> языка.
> Это очень слабо зависит от "типа и вида", если не притягивать за
> уши JIT-компиляцию и не занижать планку требований к качеству оптимизаций.
Ядро и юзерспейс на SML или Caml? Прикольненько! ;-) Я буду одним из первых, кто
покрутит такую поделку в руках, при условии, конечно, что она будет POSIX-compatible.
Дайте мне тоже! ;-)
>> "И другие языки"? Гониво! Fortran ПРАВИЛЬНО конвертировать в С, и соблюсти при
>> этом
> Ну почему гонево. Допустим, фортран нельзя, но он уже в GCC и
> сфера применения у него узкая. Я имел ввиду прежде всего обероны
> и D2. Другие языки тут на их месте сложнее представить. Тем
> более фортран. :)
Кодогенерация в язык С в подавляющем большинстве случаев является совершенно убогой и кривой технологией, о которой нужно писать в книжках как об эпохе древних вымерших мамонтов.
Если уж брать Oberon2 (допустим, решили, что берем), то нормальный, с местным компилятором, еще лучше прикрутить его к llvm или к pcc, там вроде тоже есть внутренний язык, через который собственно кодогенерация машинного кода и происходит, вместе с оптимизацией.
Язык D? Я не в курсе, насколько он велик, и не уверен насчет его портабельности и кросс-собираемости. Именно эти три фактора были решающими при выборе Lua в NetBSD.
Рассматривались другие варианты типа scheme. Жирные Python, Perl, Tcl отмелись мнгновенно.
