https://m.opennet.dev/openforum/vsluhforumID3/71986.html Команда разработчиков OpenBSD сообщила (http://marc.info/?l=openbsd-announce&m=128862690027921&w=2) о выходе версии 4.8 (http://www.openbsd.org/48.html). В отличие от предыдущего релиза, выпуск OpenBSD 4.8 практически не содержит серьёзных изменений, которые могли бы привести к возникновению неудобств при обновлении, но зато имеет немало приятных добавлений.<br><br><br>Ниже следует неполный список основных новшеств по сравнению с версией 4.7 (http://www.openbsd.org/47.html). Полная версия списка для желающих доступна на сайте (http://www.openbsd.org/plus48.html). Следует учесть, что OpenBSD-CURRENT (ветка разработки, которая со временем станет OpenBSD 4.9) содержит ряд изменений, который не успели попасть в релиз; изменения в ней будут освещены отдельно в традиционном ежемесячном отчёте.<br><br><br><br>Спящий режим (а главное &#8212; возвращение из него) работает на большей части компьютеров с графическими адаптерами на базе Intel и ATI. Машины с графическими чипами NVIDIA, к сожалению, не могут &#171;...<br><br>URL: http://marc.in https://m.opennet.dev/openforum/vsluhforumID3/71986.html#83 Mon, 08 Nov 2010 18:08:13 GMT &gt; для освоения эрланга под прикладные задачи<br><br>(просыпаясь)<br>Оно им надо?<br>(и вообще -- интересно, какая доля эрлангистов страны у нас работает...)<br>Опять же -- кроме прикладных бывают и системные, надо ж на чём-то beam'ы подымать.<br>(засыпая)<br><br>PS 2 vle: насчёт c10k и масштабируемости конкретно эрланга можешь спрашивать, у нас на ём кластерный мониторинг построен калибра "на петафлопсник".<br> https://m.opennet.dev/openforum/vsluhforumID3/71986.html#82 Sat, 06 Nov 2010 22:42:02 GMT &gt;&gt;&gt; в той же OpenBSD долго и упорно пилят на Си.<br>&gt;&gt; - А давайте отрубим удаву голову!<br>&gt;&gt; - Нет, давайте лучше хвост.<br>&gt;&gt; - Во-во! По самую голову!<br>&gt; И тут уместно задать вопрос: в чём мораль этой басни, и что<br>&gt; же там на счёт признания применимости эрланга, в конце-то концов? :)<br><br>В общем, я думаю, стороны высказались. И по делу и не по делу.<br>Каждый в меру способностей услышал то, что хотел услышать.<br>Я, пожалуй, пойду погремушками займусь.<br><br>hint: оставленое напоследок оставлено не зря.<br> https://m.opennet.dev/openforum/vsluhforumID3/71986.html#81 Sat, 06 Nov 2010 18:30:03 GMT &gt; Были приведены примеры лицемерия в OpenBSD, но я что-то не припомню ничего<br>&gt; подобного про FreeBSD. <br><br>Привожу цитаты отсюда: http://www.freebsd.org/features.html<br><br>"TrustedBSD MAC Framework extensible kernel security"<br><br>Аргументы против как и для LSM в линуксе. Почитать можно здесь: http://grsecurity.net/lsm.php - в части "Why LSM will harm the security of all Linux systems".<br><br>"TrustedBSD Audit is a security event logging service, providing fine-grained, secure, reliable logging of system events via the audit service."<br><br>При отсутствии даже базовых механизмов защиты ядра (как минимум запрет на маппинг нулевого адреса и W^X) "secure, reliable" - это ложь.<br><br>"The FreeBSD developers are as concerned about security as they are about performance and stability."<br><br>Пример лицемерия. Даже если разработчики не понимают, что тот же MAC-фреймворк малополезен и увеличивает риски, связанные с перманентной компрометацией (при наличии в системе руткита), следуя букве и смыслу цитаты они это знать обязаны, ибо это https://m.opennet.dev/openforum/vsluhforumID3/71986.html#80 Sat, 06 Nov 2010 16:40:04 GMT &gt;&gt; Я думаю так. Если бардак прекратить нельзя, нужно его возглавить.<br>&gt; Мне хватает CentOS и Hardened Gentoo. Зачем поощрять лицемерие, выбирая FreeBSD? Я<br>&gt; считаю, незачем. К тому же, у FreeBSD есть другие существенные недостатки,<br>&gt; из-за которых от неё нам и пришлось отказаться.<br><br>Были приведены примеры лицемерия в OpenBSD, но я что-то не припомню ничего подобного<br>про FreeBSD. В этом году я был на KievBSD, был там товарищ Белоусов, кажется,<br>FreeBSD core team member. Много говорил о проблемах проекта. Но среди прочего сказал<br>примерно следующее (не дословно), у нас тут не лавочка по исполнению желаний,<br>вам нужно -- вы приходите и делайте.<br>Патч, даже готовый, нужно продвигать, мало ли где чего валяется.<br>Мои и не только патчи на awk из NetBSD<br>Brian Kernighan тоже завернул года два назад<br>по, ээээ, как бы это помягче выразиться, чтоб не обидеть светилу,<br>очень странным причинам. Надо делать вторую попытку, может он чего недопонял,<br>и такое бывает, может, не в духе был, уволили его из belllabs,<br>может мо https://m.opennet.dev/openforum/vsluhforumID3/71986.html#79 Sat, 06 Nov 2010 11:47:38 GMT &gt;&gt; куцая поддержка SSP - это следствие наличия NX-бита в x86_64 и<br>&gt;&gt; включения -fstack-protector по умолчанию в последних версиях GCC.<br>&gt; В последних версиях gcc gpl3. gcc&gt;=4.3 (или когда там gpl-v3 появился?)<br>&gt; включили во FreeBSD?<br><br>А вот не знаю. Сейчас посмотрел - нигде он не включён, вплоть до 4.4. Тут либо я неправильно понял коллег, либо они где-то напутали. Возможно, они имели ввиду включение реализации SSP в апстримный GCC. В любом случае, появление ограниченной поддержки SSP во FreeBSD в 2009-ом - сродни противопоставлению античных колесниц современной бронетехнике. Напомню, патч для включения SSP во FreeBSD 5.x появился где-то в начале 2005-го. Четыре года промедлений, а в итоге - шажок вперёд с оглядкой на апстрим.<br><br>&gt; Ну, справедливости ради, не забываем, что jail-ы выполняют более одной функции.<br>&gt; Одна из ниш, где FreeBSD в свое время широко использовалась -- это<br>&gt; дешевый jail хостинг. Так что фича эта для них действительно важна.<br><br>Важна для изоляции неуловимых джо. Коммерческая целесообр https://m.opennet.dev/openforum/vsluhforumID3/71986.html#78 Fri, 05 Nov 2010 23:23:43 GMT &gt; куцая поддержка SSP - это следствие наличия NX-бита в x86_64 и<br>&gt; включения -fstack-protector по умолчанию в последних версиях GCC.<br><br>В последних версиях gcc gpl3. gcc&gt;=4.3 (или когда там gpl-v3 появился?)<br>включили во FreeBSD?<br><br>&gt; Это не прогресс,<br>&gt; это недоразумение. Вместо реальных мер защиты ядра налегают на jail'ы, даже<br>&gt; не запретив маппинги нулевого адреса, и реализуют фреймворки<br>&gt; "для развёртывания руткитов" (MAC, KLD).<br><br>Ну, справедливости ради, не забываем, что jail-ы выполняют более одной функции.<br>Одна из ниш, где FreeBSD в свое время широко использовалась -- это дешевый<br>jail хостинг. Так что фича эта для них действительно важна.<br><br>&gt;&gt; Повторюсь, многие вещи объясняются сильно<br>&gt;&gt; ограниченными людскими ресурсами. Можно по этому поводу долго сокрушаться,<br>&gt; Их дело - придумывать себе любые оправдания, но когда начинаютя старые песни<br>&gt; о главном о безопасности FreeBSD, это просто враньё. PaX и Grsecurity<br>&gt; - это два человека, к слову.<br><br>Я думаю так. Если бардак прекратить нельзя, нужно ег https://m.opennet.dev/openforum/vsluhforumID3/71986.html#77 Fri, 05 Nov 2010 16:10:01 GMT &gt;&gt; Я не говорил обо всех BSD. Во FreeBSD практически не решаются проблемы<br>&gt;&gt; безопасности, но в остальном другие BSD гораздо реже брезгуют чем-то новым,<br>&gt;&gt; более полезным.<br>&gt; patch? ;-)<br><br>А толку от этих патчей, когда их полтора человека используют? Пять лет, как есть патчи с ASLR от Hiroaki Etoh, а воз и ныне там.<br><br>&gt; Ну, возможно процесс идет не так быстро, как некоторым хотелось бы,<br>&gt; но он как-то идет, и в этом направлении тоже.<br><br>Да не идёт-то процесс совсем, не во FreeBSD. Проблема как раз в отказе называть вещи своими именами. То что там, как тут говорят, для каких-то архитектур наличие/отсутствие PROT_EXEC теперь даёт реальный эффект, и появилась куцая поддержка SSP - это следствие наличия NX-бита в x86_64 и включения -fstack-protector по умолчанию в последних версиях GCC. Это не прогресс, это недоразумение. Вместо реальных мер защиты ядра налегают на jail'ы, даже не запретив маппинги нулевого адреса, и реализуют фреймворки "для развёртывания руткитов" (MAC, KLD).<br><br>&gt; Повторюсь, многие вещи объяс https://m.opennet.dev/openforum/vsluhforumID3/71986.html#76 Fri, 05 Nov 2010 13:55:36 GMT &gt; Но дело даже не в этом, а в дезинформации, которой в<br>&gt; OpenBSD кормят пользователей, и в ложных отговорках против чего угодно необычного.<br><br>Эту мысль ты уже озвучивал, и я с ней полностью согласен.<br>"Деза" вредна даже не для пользователей, а для самой системы и ее разработчиков.<br>И насчет примера про переполнение целого в Жабе я с тобой тоже согласен.<br>Мягко говоря, некрасиво. В NetBSD (пардон :-) ) давно признают, что по поддержке<br>железа Линупс их давно обогнал. Поддержка современного железа тоже,<br>насколько мне известно, не всегда на высоте. Поддержку SheevaPlug, к примеру,<br>по-моему вот только-только сделали, было письмо в ports-arm@.<br>Но здесь я не уверен, я не по этим делам.<br>Вообще, я считаю, NetBSD имидж "Of course it runs NetBSD"(C) только вредит,<br>но это так, к слову.<br><br>&gt; Кстати, лгут и лицемерят многие, не только разработчики OpenBSD. Я об этом<br>&gt; тоже стараюсь упоминать, если уж разговор заходит.<br><br>Вот именно.<br><br>&gt; Я не говорил обо всех BSD. Во FreeBSD практически не решаются проблемы<br>&gt; безоп https://m.opennet.dev/openforum/vsluhforumID3/71986.html#75 Fri, 05 Nov 2010 10:04:30 GMT &gt; Я не могу сказать ничего про OpenBSD. Но вот в NetBSD после<br>&gt; долгого и кровопролитного<br>&gt; (почти без кавычек) обсуждения все-таки приняли решение включить Lua в базовую систему.<br><br>Вот. В OpenBSD такие перемены очень сложно представить - прецедентов не было. Но дело даже не в этом, а в дезинформации, которой в OpenBSD кормят пользователей, и в ложных отговорках против чего угодно необычного.<br><br>Кстати, лгут и лицемерят многие, не только разработчики OpenBSD. Я об этом тоже стараюсь упоминать, если уж разговор заходит.<br><br>&gt; Во FreeBSD тянут D-Trace и zfs.<br>&gt; То есть не совсем уж BSD-ки невосприимчивы ко всему новому. Не знаю,<br>&gt; как во FreeBSD<br><br>Я не говорил обо всех BSD. Во FreeBSD практически не решаются проблемы безопасности, но в остальном другие BSD гораздо реже брезгуют чем-то новым, более полезным.<br><br>&gt; и периодически тянут оттуда внутриядерные API для подсистем. Кое-что тянут и из<br>&gt; Линукса, скажем /proc/cpuinfo и /proc/&lt;pid&gt;/maps. Мелочи, но тем не менее.<br><br>К слову, если /proc/&lt;pid&gt;/maps доступен