>> Я не говорил обо всех 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) - это, по-вашему, "ничего такого"? :)
