> куцая поддержка SSP - это следствие наличия NX-бита в x86_64 и
> включения -fstack-protector по умолчанию в последних версиях GCC.В последних версиях gcc gpl3. gcc>=4.3 (или когда там gpl-v3 появился?)
включили во FreeBSD?
> Это не прогресс,
> это недоразумение. Вместо реальных мер защиты ядра налегают на jail'ы, даже
> не запретив маппинги нулевого адреса, и реализуют фреймворки
> "для развёртывания руткитов" (MAC, KLD).
Ну, справедливости ради, не забываем, что jail-ы выполняют более одной функции.
Одна из ниш, где FreeBSD в свое время широко использовалась -- это дешевый
jail хостинг. Так что фича эта для них действительно важна.
>> Повторюсь, многие вещи объясняются сильно
>> ограниченными людскими ресурсами. Можно по этому поводу долго сокрушаться,
> Их дело - придумывать себе любые оправдания, но когда начинаютя старые песни
> о главном о безопасности FreeBSD, это просто враньё. PaX и Grsecurity
> - это два человека, к слову.
Я думаю так. Если бардак прекратить нельзя, нужно его возглавить.
То, что мне *сильно* не нравилось в NetBSD я исправлял, сам. PR там больше двух сотен.
Больше 180 успешно исправлено и закрыто. В основном это, конечно, жалобы на pkgsrc.
Но и патчей на userspace достаточно. В основном, мелочь, правда.
> А во FreeBSD от решения
> проблем с безопасностью отвадили даже тех, кто ими занимался (тот же
> Hiroaki Etoh). Вот это факты.
Ok. Два вопроса. 1) Сколько в строках кода занимают эти pax/grsecurity в случае Линупса?
2) Отвадили как? Публичное обсуждение было? Где его можно увидеть?
Какова аргументация "противной" стороны?
> чтобы
> задумались те, кто хочет и может задумываться (но едва ли многие
> из них читают комменты ;)
О да, я не знаю, что такое лор сейчас, но судя по моим воспоминаниям,
опеннет к нему стремительно приближается.
>> Ну, Оберон ладно. Банальная императивщина. Насчет Erlang-а я не согласен.
> и надёжным. А что взамен этих "неудобств"?
http://www.amazon.com/Purely-Functional-Structures-Chris-Oka...
И ВСЁ начинаем учить заного. Не?
http://www.zbh.uni-hamburg.de/pubs/pdf/GieKur1995a.pdf
Буквально первых два предложения из Conclusion.
Оно мне надо? ТАКИМ трудом добиваться банального результата,
рыться днями на citeseer-е???
> Уникальная модель легковесных процессов,
> отсутствие проблем с совместным доступом к данным, автоматическое распараллеливание кода
> на уровне ВМ, прозрачная кластеризация, типобезопасность, прозрачно асинхронный
> ввод-вывод
> и уникальный набор пользователських библиотек (имею ввиду прежде всего OTP) для
> решения ряда наиболее актуальных задач.
Основные плюшки и фишки Erlang-а я знаю, хотя в детали не влезал
и в подробностях не изучал.
Во-первых, он в этой нише не один. Есть раскручиваемый гугловский Go,
есть полуакадемический Oz и многие прочие.
> "Очень императивные", быстрые или системные алгоритмы
> можно реализовать на Си - в виде драйвера или самостоятельных Си-нод,
В этом случае нам нужен будет полностью реентерабельный код, желательно еще
и lock-free.
Даже jemalloc и tcmalloc такого не умеют, т.е. упираемся во все те же локи
и переключение контекста с очевидными проблемами и ограничениями 1:1 поточности.
Проблема c2k не решается, даже если кто-то ее себе и ставит.
Но я думаю, это явно за рамками ***BSD.
Но "если б я была царицей", я бы, да, для некоторых проектов из их пачки OpenXXX
erlang рассмотрел бы в качестве варианта, особенно сетевых.
> Функциональная парадигма -- не для всех, не говоря уже об ОБЪЕКТИВНЫХ
> А я ведь не с потолка взял короткие сроки обучения. Очень рекомендую
> почитать, как оно именно на практике: http://materials.it-event.ru/1550/erlang.pdf
Да я уже начитался, спасибо.
И про Хаскель, и про SML, и про CAML/OCAML и прочие SICP-ы
и Лиспы, и близнецов братьев введения Гордона и Харисона.
Но на Ерланг я гляну, конечно, я давно хочу ради
самообучения dictd на erlang-е переписать. Нет времени.
>> В общем случае, выхлоп неочевиден. Кроме того ФЯП для типичных приложений
>> и не нужны.
> "В общем случае", "для типичных приложений"... Не стыдно? :)
Нет. Абсолютно. ЯП подбираются по конкретные задачи и нужды. Мы же пытаемся
рассуждать о сферическом ЯП в вакууме для сферической же в вакууме задачи. При этом каждый под этими задачами имеет свое.
>> Возможно, OpenBSD меня, честно говоря, интересует постольку поскольку.
>> Я не люблю системы с ярковыраженным Фюрером во главе.
> Хорошо сказано. ;) Жаль, в линуксе тоже есть свой фюрер.
Этим ОпенСорс и вообще IT и живет.
Святой Патрик, Столман, Тео, Торвальдс, Дреппер, Яблочный дядя, Диллан.
От скандала до скандала. От сенсации до сенсации.
Разьве что последний пока нигде ничего вроде не отжег.
> Идей написания ядра на оберонах? Обноимённые ОС были написаны на оберонах ещё
> в конце 80-ых. Есть несколько современных реализаций, включая как минимум две
> ОСРВ.
1) URL? 2) "Оно" POSIX? Чистый RT мне мало интересен.
>> С -- значительная и поучительная часть истории и сегодняшнего дня IT.
>> Его нельзя не изучать.
> Можно изучать, но о моральном устаревании и проблемах с надёжностью и безопасностью
> - рассказать обязательно.
Кто-то спорит?
> Впрочем, в том же Оксфорде CS преподают на
> базе Scheme и Oberon-2.
Oberon-2 -- замечательный выбор. Scheme -- у меня вызывает вопросы.
Архаизм доисторический обыкновенный.
Мое общение с "функциональщиками из народа" показывает, что эти так сказать
программисты АБСОЛЮТНО НИЧЕГО НЕ СМЫСЛЯТ В ЭЛЕМЕНТАРНЫХ ОСНОВАХ АЛГОРИТМИЗАЦИИ.
Именно так, всё с большими буквами, им просто наплевать. Умеет компилятор их ленивости раскручивать или не умеет -- насрать, компы нынче быстрые, память дешевая.
MIT-шный SICP я читал, правда по-русски (каюсь, дурак был)
и драфт перевода без картинок.
Есть вещи красивые, но они есть много где. Forth, Oz, Haskel, TCL
и прочие и прочие. hint: я тут недавно (ну, ладно, давно) читал в рассылке Lua
обсуждение Go. Повыползали дяденьки и начали толкать речь про Algol-68, ох и наговорили
они прелестей господину-товарищу-барину Пайку :-)
