> Я не могу сказать ничего про 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.

>> Я не говорил обо всех BSD. Во FreeBSD практически не решаются проблемы
>> безопасности, но в остальном другие BSD гораздо реже брезгуют чем-то новым,
>> более полезным.
> patch? ;-)

А толку от этих патчей, когда их полтора человека используют? Пять лет, как есть патчи с ASLR от Hiroaki Etoh, а воз и ныне там.

> Ну, возможно процесс идет не так быстро, как некоторым хотелось бы,
> но он как-то идет, и в этом направлении тоже.

Да не идёт-то процесс совсем, не во FreeBSD. Проблема как раз в отказе называть вещи своими именами. То что там, как тут говорят, для каких-то архитектур наличие/отсутствие PROT_EXEC теперь даёт реальный эффект, и появилась куцая поддержка SSP - это следствие наличия NX-бита в x86_64 и включения -fstack-protector по умолчанию в последних версиях GCC. Это не прогресс, это недоразумение. Вместо реальных мер защиты ядра налегают на jail'ы, даже не запретив маппинги нулевого адреса, и реализуют фреймворки "для развёртывания руткитов" (MAC, KLD).

> Повторюсь, многие вещи объясняются сильно
> ограниченными людскими ресурсами. Можно по этому поводу долго сокрушаться,

Их дело - придумывать себе любые оправдания, но когда начинаютя старые песни о главном о безопасности FreeBSD, это просто враньё. PaX и Grsecurity - это два человека, к слову. А во FreeBSD от решения проблем с безопасностью отвадили даже тех, кто ими занимался (тот же Hiroaki Etoh). Вот это факты.

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

Да в общем-то ничего. Я тут столько пишу ровно для того, чтобы задумались те, кто хочет и может задумываться (но едва ли многие из них читают комменты ;) ). И не важно, кто при каком мнении останется.

> Ну, Оберон ладно. Банальная императивщина. Насчет Erlang-а я не согласен.

Вот много таких, априори несогласных. Erlang => ФП => сложно и непрактично. От взгляда теоретиков как-то ускользает, что эрланг от императивных языков заметно отличается разве что немутабельными переменными - он намеренно сделан предельно простым и надёжным. А что взамен этих "неудобств"? Уникальная модель легковесных процессов, отсутствие проблем с совместным доступом к данным, автоматическое распараллеливание кода на уровне ВМ, прозрачная кластеризация, типобезопасность, прозрачно асинхронный ввод-вывод и уникальный набор пользователських библиотек (имею ввиду прежде всего OTP) для решения ряда наиболее актуальных задач. "Очень императивные", быстрые или системные алгоритмы можно реализовать на Си - в виде драйвера или самостоятельных Си-нод, к которым применимы всё те же принципы разделения привилегий. Плюс "мелочи", вроде наличия библиотеки криптографических функций (включая нативную реализацию SSL и TLS с быстрым кодом шифров на базе OpenSSL), встроенной распределённой СУБД, поддержки юникода (OpenBSD, I'm looking at you!), наличия асинхронных ODBC-драйверов, компиляции в нативный код (HiPE), наличия сторонних библиотек для внешней связи с JS, Python, а также для запуска Python-кода на эрланг-нодах, наличия рабочей реализации на базе JVM (Erjang), возможности гибкого юнит- и интеграционного тестирования (отдельные процессы в роли mock-объектов с простыми внешними итерфейсами) и так далее.

> Функциональная парадигма -- не для всех, не говоря уже об ОБЪЕКТИВНЫХ

А я ведь не с потолка взял короткие сроки обучения. Очень рекомендую почитать, как оно именно на практике: http://materials.it-event.ru/1550/erlang.pdf

> сложностях в реализации на соответствующих ЯП сложных нетривильных алгоритмов,
> для которых имеются императивные описания, начиная с 50-60.
> Для ФП их нужно переформулировать, т.е. переизобретать ЗАНОВО.
> По этому вопросу люди пишут диссертации и толстенные книги. Оно надо?

Как уже сказал: драйверы, Си-ноды.

> В общем случае, выхлоп неочевиден. Кроме того ФЯП для типичных приложений
> и не нужны.

"В общем случае", "для типичных приложений"... Не стыдно? :)

> В NetBSD GPL тоже не любят, уверен, как и во FreeBSD, но
> в первую очередь

К слову, лицензия Erlang/OTP далека по смыслу от GPL. Почти BSD.

> смотрят на качество, судя по тому, что я вижу. Прежде чем выбросить
> GNU groff
> и заменить его нделана огромная работа. GNU grep
> не смотря на все усилия многих BSD-шников пока идет по дефолту.
> То есть пыхтят, стараются, но выбросят только тогда, когда сделают лучше.

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

> Возможно, OpenBSD меня, честно говоря, интересует постольку поскольку.
> Я не люблю системы с ярковыраженным Фюрером во главе.

Хорошо сказано. ;) Жаль, в линуксе тоже есть свой фюрер.

> Ну а к чему тогда сокрушаться по этому поводу, выставляя именно
> OpenBSD-шников? ;-) В этом плане все одинаково хороши.

Вообще-то, о NIH-синдроме я только вскользь упомянул. ;) Не согласен, что все одинаково хороши: в OpenBSD на этой почве просто культ луддитов какой-то. :) Впрочем, их дело - мне бы хватило, если б они просто прекратили вводить людей в заблуждение.

> В принципе, они известны своей паранойей.

Мне кажется, их паранойя запитана от Owl, где с безопасностью ядра тоже застой.

>>> Ядро и юзерспейс на SML или Caml? Прикольненько! ;-) Я буду одним
>> Тогда уж на обероне, но это всё мечты, мечты.
> Как бы там ни было, все это сейчас на уровне университетского проекта,
> а еще точнее, набора голых идей.

Идей написания ядра на оберонах? Обноимённые ОС были написаны на оберонах ещё в конце 80-ых. Есть несколько современных реализаций, включая как минимум две ОСРВ.

> С -- значительная и поучительная часть истории и сегодняшнего дня IT.
> Его нельзя не изучать.

Можно изучать, но о моральном устаревании и проблемах с надёжностью и безопасностью - рассказать обязательно. Впрочем, в том же Оксфорде CS преподают на базе Scheme и Oberon-2.

> На мой взгляд scheme лучше clisp, но ничего ТАКОГО он
> из себя не представляет. Для типичных несложных задач Lua и JavaScript лучше.

То есть, например, продолжения (continuations) - это, по-вашему, "ничего такого"? :)

>> куцая поддержка SSP - это следствие наличия NX-бита в x86_64 и
>> включения -fstack-protector по умолчанию в последних версиях GCC.
> В последних версиях gcc gpl3. gcc>=4.3 (или когда там gpl-v3 появился?)
> включили во FreeBSD?

А вот не знаю. Сейчас посмотрел - нигде он не включён, вплоть до 4.4. Тут либо я неправильно понял коллег, либо они где-то напутали. Возможно, они имели ввиду включение реализации SSP в апстримный GCC. В любом случае, появление ограниченной поддержки SSP во FreeBSD в 2009-ом - сродни противопоставлению античных колесниц современной бронетехнике. Напомню, патч для включения SSP во FreeBSD 5.x появился где-то в начале 2005-го. Четыре года промедлений, а в итоге - шажок вперёд с оглядкой на апстрим.

> Ну, справедливости ради, не забываем, что jail-ы выполняют более одной функции.
> Одна из ниш, где FreeBSD в свое время широко использовалась -- это
> дешевый jail хостинг. Так что фича эта для них действительно важна.

Важна для изоляции неуловимых джо. Коммерческая целесообразность этого мне понятна. Не понятно (я конечно утрирую - на самом деле всё, как говорится, ясно), почему в man jail пользователь не видит предостережений против применения джейлов для обеспечения безопасности в более серьёзных ситуациях.

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

Мне хватает CentOS и Hardened Gentoo. Зачем поощрять лицемерие, выбирая FreeBSD? Я считаю, незачем. К тому же, у FreeBSD есть другие существенные недостатки, из-за которых от неё нам и пришлось отказаться.

> То, что мне *сильно* не нравилось в NetBSD я исправлял, сам. PR
> там больше двух сотен.
> Больше 180 успешно исправлено и закрыто. В основном это, конечно, жалобы на
> pkgsrc.
> Но и патчей на userspace достаточно. В основном, мелочь, правда.

Я уже приводил пример с патчами для ASLR - они до сих пор не включены. Частичная поддержка SSP появилась спустя 4 года после написания патчей. При этом оба набора патчей  работали лично у меня в продакшене с FreeBSD 5.4 по 6.4 включительно. Жалоб на стабильность и сложность сопровождения не имею.

О том, чтобы что-то "возглавить", можно говорить только при наличии заинтересованности основных разработчиков. Её нет.

> Ok. Два вопроса. 1) Сколько в строках кода занимают эти pax/grsecurity в
> случае Линупса?

Совмещённый патч изменяет 27000+ строк кода. Но значительная часть - это констификация объявлений чувствительных данных. Объём нешаблонных изменений где-то в полтора раза меньше.

Отдельно хочу отметить: защита от маппинга нулевого адреса - несколько десятков - едва ли сотен - строк. Во FreeBSD нет даже этого.

> 2) Отвадили как? Публичное обсуждение было? Где его можно увидеть?
> Какова аргументация "противной" стороны?

Отвадили, не приняв патчи (до сих пор). Дискуссии не видел - едва ли была, гугль тоже молчит.

> http://www.amazon.com/Purely-Functional-Structures-Chris-Oka...
> И ВСЁ начинаем учить заного. Не?

Нет. Есть стандартные библиотеки, есть сторонние, есть сообщество, есть простые рекурсивные алгоритмы обработки структур, нет проблемы организации совместного доступа - только межпроцессное сообщение. Есть, в конце-концов, возможность писать на Си несколькими способами.

> http://www.zbh.uni-hamburg.de/pubs/pdf/GieKur1995a.pdf
> Буквально первых два предложения из Conclusion.

Прочитал. Не вижу повода для печали, скорее для радости. В чём мораль-то?

> Оно мне надо? ТАКИМ трудом добиваться банального результата,
> рыться днями на citeseer-е???

Каким трудом? Да и эрланг язык активный.

> Основные плюшки и фишки Erlang-а я знаю, хотя в детали не влезал
> и в подробностях не изучал.

Напомнило: "Набокова не читал, но осуждаю".

> Во-первых, он в этой нише не один. Есть раскручиваемый гугловский Go,
> есть полуакадемический Oz и многие прочие.

В какой нише? Ни один из перечисленных (в т.ч. ниже) языков не обладает и половиной качеств эрланга, наиболее актуальных для программирования клиент-серверных приложений, аналоги которых в той же OpenBSD долго и упорно пилят на Си.

>> "Очень императивные", быстрые или системные алгоритмы
>> можно реализовать на Си - в виде драйвера или самостоятельных Си-нод,
> В этом случае нам нужен будет полностью реентерабельный код, желательно еще
> и lock-free.

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

> Даже jemalloc и tcmalloc такого не умеют, т.е. упираемся во все те
> же локи

В отсутствие интереса и ложные поверхностные суждения мы упираемся, а вовсе не в локи.

> и переключение контекста с очевидными проблемами и ограничениями 1:1 поточности.

И переключения контекста между тяжёлыми синхронными и лёгкими асинхронными нодами тоже более, чем оправдано. Не встречал ни одного приложения ни на одном языке, где асинхронная обработка запросов оправданно и эффективно соседствует с тяжёлыми вычислениями в том же процессе.

> Проблема c2k не решается, даже если кто-то ее себе и ставит.
> Но я думаю, это явно за рамками ***BSD.

c2k? Может быть c10k? Эрланг создавался ровно для её решения, как параллельный пролог с асинхронным вводом-выводом. Для AXD-301 написана система в 1,7 миллионов строк на эрланге. Сюрприз, как говорится.

> Но "если б я была царицей", я бы, да, для некоторых проектов
> из их пачки OpenXXX
> erlang рассмотрел бы в качестве варианта, особенно сетевых.

Вот-вот, особенно для сетевых. А то пилят свои местечковые велосипеды...

> Да я уже начитался, спасибо.
> И про Хаскель, и про SML, и про CAML/OCAML и прочие SICP-ы

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

>>> В общем случае, выхлоп неочевиден. Кроме того ФЯП для типичных приложений
>>> и не нужны.
>> "В общем случае", "для типичных приложений"... Не стыдно? :)
> Нет. Абсолютно. ЯП подбираются по конкретные задачи и нужды. Мы же пытаемся
> рассуждать о сферическом ЯП в вакууме для сферической же в вакууме задачи.
> При этом каждый под этими задачами имеет свое.

Эрланг это возможная альтернатива для товарищей из OpenBSD, а они пишут вполне конкретные клиент-серверные приложения на Си. "Типичные приложения" и "общие случаи" - из другой оперы, и не я о них заговорил.

> 1) URL? 2) "Оно" POSIX? Чистый RT мне мало интересен.

"Oberon System", "Active Oberon", "Bluebottle", "Jbed" - гугль в помощь.

"XOberon/2" ака "XO/2", "HeliOS" - эти ОСРВ. По XO/2 материалов почти нет, но сам суслик есть.

Нет, не POSIX, конечно. В Plan-9 многое позаимствовано из оберонов, на сколько я могу судить (взомжно, и пруфлинки есть - не искал).

> Oberon-2 -- замечательный выбор. Scheme -- у меня вызывает вопросы.
> Архаизм доисторический обыкновенный.

Как всё просто, оказывается.

> Мое общение с "функциональщиками из народа" показывает, что эти так сказать
> программисты АБСОЛЮТНО НИЧЕГО НЕ СМЫСЛЯТ В ЭЛЕМЕНТАРНЫХ ОСНОВАХ АЛГОРИТМИЗАЦИИ.
> Именно так, всё с большими буквами, им просто наплевать. Умеет компилятор их
> ленивости раскручивать или не умеет -- насрать, компы нынче быстрые, память
> дешевая.

С окружением не повезло. ФП как таковое здесь ни при чём.

> MIT-шный SICP я читал, правда по-русски (каюсь, дурак был)
> и драфт перевода без картинок.
> Есть вещи красивые, но они есть много где. Forth, Oz, Haskel, TCL

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

> Были приведены примеры лицемерия в OpenBSD, но я что-то не припомню ничего
> подобного про FreeBSD.

Привожу цитаты отсюда: http://www.freebsd.org/features.html

"TrustedBSD MAC Framework extensible kernel security"

Аргументы против как и для LSM в линуксе. Почитать можно здесь: http://grsecurity.net/lsm.php - в части "Why LSM will harm the security of all Linux systems".

"TrustedBSD Audit is a security event logging service, providing fine-grained, secure, reliable logging of system events via the audit service."

При отсутствии даже базовых механизмов защиты ядра (как минимум запрет на маппинг нулевого адреса и W^X) "secure, reliable" - это ложь.

"The FreeBSD developers are as concerned about security as they are about performance and stability."

Пример лицемерия. Даже если разработчики не понимают, что тот же MAC-фреймворк малополезен и увеличивает риски, связанные с перманентной компрометацией (при наличии в системе руткита), следуя букве и смыслу цитаты они это знать обязаны, ибо это основы. Резюме: разработчики FreeBSD настолько "concerned", что либо не знают даже основ, либо пренебрегают даже основами.

А где хотя бы базовая защита пользовательских процессов (W^X и ASLR)? Ею тоже пренебрегли. Concerned. Yea, right.

Джейлы полезны не более MAC-фреймворка и в силу тех же причин, но читаем дальше:

"These features can be used to support highly secure hosting of mutually untrusting customers or consumers, the strong partitioning of network segments, and the construction of secure pipelines for information scrubbing and information flow control."

И видим: "highly secure hosting of mutually untrusting customers or consumers". Srsly?

> примерно следующее (не дословно), у нас тут не лавочка по исполнению желаний,
> вам нужно -- вы приходите и делайте.

Хочется сказать, как в анекдоте: или крест снимите, или штаны оденьте. К чему все эти маркетинговые пассажи "highly secure"? За слова надо отвечать, а не перекладывать ответственность на других.

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

Опять-таки, настолько разработчики concerned, что даже простой патч, реализующий часть базовых механизмов защиты, оказывается, нужно продвигать! Старые песни о главном. В линуксе примерно то же самое сейчас.

> Если интерес настолько велик, что задело АЖ ВОТ ТАК, надо становится разработчиком
> самому, а не кивать на них плохих. Можно даже стать тамошним экспертом по безопасности.

Один в поле не воин. Почему я выбрал Hardened Gentoo и CentOS - там уже многое сделано, и результаты моей работы дополняют результаты работы других людей на этом поприще. А зачем мне FreeBSD? Чтобы с каждым патчем ходить к батькам на поклон и за годы не добиться того, что уже несколько лет, как достигнуто другими проектами?

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

> Не? Ну тогда плюнуть на них на всех свысока и молча использовать то, где уже все
> готово, CentOS или Hardened Gentoo -- всё равно.

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

> Моя работа непосредственно связана с разработкой алгоритмов, сложных.

Твоя работа, как я понял, к теме разговора прямого отношения не имеет.

> За ресерч в этом направлении, т.е. за переливание из императивного стакана
> в функциональный в рабочее время, меня просто уволят. Это непродуктивно.

К теме это не относится.

> Не надо повторять про обилие библиотек для ерланга. Я понял с первого раза.

Замечательно!

> Да, "их есть", некоторое количество. Но я даже не гляда точно знаю, что того,
> что нужно мне там нет. Этого нет во всем опенсорсе, а то, что есть мнээээ :-/

Сожалею, но причём тут разработчики OpenBSD и обсуждение инструментария для их проектов? Вопрос риторический.

> Их имел ввиду как раз я. Или мы будем совать Ерланг во
> все дырки, не глядя на то, подходит он или не подходит?

Я упомянул эрланг во вполне ясном контексте, о котором уже устал повторять.

> Мне вот приложение на ncurses склепать нужно, к примеру,
> для управлением пакетами в системе. Ерланг? Да за каким хреном у там
> нужен?

Вот после таких вопросов мне и приходится повторять.

> По поводу Erlanga и его применимости в СЕТЕВЫХ приложениях я по-моему выразился на
> русском языке и вполне конкретно. Да, здесь он на своем месте, и я не вижу причин,

Да ну?! Вот буквально в предыдущем комментарии ты сказал о нерешённости проблемы c10k в эрланге, о каких-то локах и реннтрабельности (похоже, не вдумавшись в мои слова о Си-нодах), не имеющих отношения к делу. ЭТО никак не назовёшь признанием применимости эрланга, и уж тем более, вполне кронкретным!

Но дело не в признании: мне приходится повторять и разжёвывать, пробиваясь сквозь поверхностные суждения, выносимые безапелляционно с апломбом, и повторять уже сказанное - многократно! Я хочу только ясности и надеюсь на понимание. И это для ясности.

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

Вот и я не вижу причин, технических. О нетехнических знаю и уже высказался на их счёт.

>> в той же OpenBSD долго и упорно пилят
>> на Си.
> - А давайте отрубим удаву голову!
> - Нет, давайте лучше хвост.
> - Во-во! По самую голову!

И тут уместно задать вопрос: в чём мораль этой басни, и что же там на счёт признания применимости эрланга, в конце-то концов? :)

До абсурда попрошу не доводить - это дешёвая полемика, которая здесь ни к чему.

> Отказа? Где? Url? ;-) Меня не нужно убеждать в том, что Ерланг может то и это.

Да в предыдущем комменте:

> Да я уже начитался, спасибо.
> И про Хаскель, и про SML, и про CAML/OCAML и прочие SICP-ы
> и Лиспы, и близнецов братьев введения Гордона и Харисона.

Это в ответ на моё обоснование коротких сроков обучения эрлангу. А презентация короткая. И ворох упомянутых языков к этому не относится. Кстати, именно с таким отношением я сталкиваюсь всякий раз, пытаясь что-то объяснить или чего-то добиться от незаинтересованных людей.

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

"Да я уже начитался, спасибо" против "Я почитаю внимательнее" - это без комментариев.

> Мы говорим об одном и том же. В этом конкретном месте не вижу предмета для спора.

Я тоже не вижу. И вижу одновременно. Вернее, по мере чтения твоих комментариев: вижу, не вижу, вижу, не вижу... Потому что высказываешься очень противоречиво.

> Типичный лиспофил кроме того даже не видит границы между чистой функциональной парадигмой
> и всего лишь динамичностью языка Лисп. Эти люди регулярно выдают первое
> за второе, а второе за первое, банально не понимая разницы. С
> окружением не повезло? Да это не мое окружение. Это интернет.

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