>> куцая поддержка 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
Я обратил внимание на эрланг, поскольку он обладает уникальной совокупностью качеств, наиболее актуальных в программировании сетевых приложений. А красивости везде есть, даже в Си.
