Команда разработчиков OpenBSD сообщила (http://marc.info/?l=openbsd-announce&m=128862690027921&w=2) о выходе версии 4.8 (http://www.openbsd.org/48.html). В отличие от предыдущего релиза, выпуск OpenBSD 4.8 практически не содержит серьёзных изменений, которые могли бы привести к возникновению неудобств при обновлении, но зато имеет немало приятных добавлений.
Ниже следует неполный список основных новшеств по сравнению с версией 4.7 (http://www.openbsd.org/47.html). Полная версия списка для желающих доступна на сайте (http://www.openbsd.org/plus48.html). Следует учесть, что OpenBSD-CURRENT (ветка разработки, которая со временем станет OpenBSD 4.9) содержит ряд изменений, который не успели попасть в релиз; изменения в ней будут освещены отдельно в традиционном ежемесячном отчёте.Спящий режим (а главное — возвращение из него) работает на большей части компьютеров с графическими адаптерами на базе Intel и ATI. Машины с графическими чипами NVIDIA, к сожалению, не могут «...
URL: http://marc.info/?l=openbsd-announce&m=128862690027921&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=28472
Уже скачал образ. Скоро буду ставить на десктоп
На Desktop? Странно, что там вообще X11 работает...
Чего странного? Система замечательная и в качестве десктопа абсолютно юзабельна.
> На Desktop? Странно, что там вообще X11 работает...А вот если бы вы хотя бы новость читали внимательно (молчу про чтение FAQ, например), то знали бы, что там и 3D-акселерация поддерживается, для ATI и Intel.
Расскажите, что там с автоконфигурацией иксов.
Работает. Причем даже игры требующие ускорения запускаются. При желании можно сгенерить себе xorg.conf и затюнить его по желанию.
> На Desktop? Странно, что там вообще X11 работает...http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&num...
почему бы и нет :)
а оно уже поддерживает 4G мозгов?
> а оно уже поддерживает 4G мозгов?Четыре-то поддерживает. Детали для i386, например, можно глянуть здесь: http://www.atmnis.com/~proger/openkyiv/openkyiv2009_proger_s... (поиск по фразе «4G»).
Вот с bigmem (>4G) на ряде amd64-машин ещё есть нерешённые проблемы. :( Кое-где работает стабильно, можно попробовать включить в ядре после установки на свой страх и риск; лучше для этого, конечно, заюзать -CURRENT.
А где можно скачать все альбомы песенок быстро и сразу? Хочется ознакомиться с творчеством этой группы. (сам openbsd не интересует)
http://openbsd.org/lyrics.html
то есть типаfor n in `seq 30 48`
do
wget -c http://www.openbsd.org/songs/song$n.ogg
done?
>Gcc 2.95.3 (+ патчи), 3.3.5 (+ патчи) и 4.2.1 (+патчи).Лидеры некрофилии
не гоняются за самым свежим.
Да уж. В других системах найти такие раритеты как апач 1.3 или GCC 2.x уже проблематично :)
> Да уж. В других системах найти такие раритеты как апач 1.3 или
> GCC 2.x уже проблематично :)GCC 2.x используется там, где в новых версиях дропнута поддержка соответствующих архитектур (это к слову о кроссплатформенности GCC, ага). А Apache 1.3 в опёнке — это совсем не то же, что стоковый Apache 1.3. Впрочем, для желающих есть и Apache 2 в портах.
> А Apache 1.3 в опёнке — это совсем не то же, что стоковый Apache 1.3.Да, уже загнул мысленно палец -- "когда-нить глянуть, потырить патчей". :)
>> А Apache 1.3 в опёнке — это совсем не то же, что стоковый Apache 1.3.
> Да, уже загнул мысленно палец -- "когда-нить глянуть, потырить патчей". :)Сдается мне, сильно девешле будет взять весь.
Кстати, к вопросу о...
http://mova.org/~cheusov/pub/mk-configure/nbawk/
Легким движением руки, BSD-шный софт превращается в переносимый
в том числе и на Линукс. В принципе, то же самое применимо, думаю, и к
OpenBSD-шному apache, если они его на свои mk files перевели,
лениво проверять.
> Кстати, к вопросу о...
> http://mova.org/~cheusov/pub/mk-configure/nbawk/Само собой то же самое можно сделать с ЛЮБЫМ
софтом из ЛЮБЫХ BSD систем. mk files более менее
все похожи. Так что "понатырить" не проблема.
>>> А Apache 1.3 в опёнке — это совсем не то же, что стоковый Apache 1.3.
>> Да, уже загнул мысленно палец -- "когда-нить глянуть, потырить патчей". :)
> Сдается мне, сильно девешле будет взять весь.
> Кстати, к вопросу о...
> http://mova.org/~cheusov/pub/mk-configure/nbawk/
> Легким движением руки, BSD-шный софт превращается в переносимый
> в том числе и на Линукс. В принципе, то же самое применимо,
> думаю, и к
> OpenBSD-шному apache, если они его на свои mk files перевели,
> лениво проверять.Не совсем перевели, сделали обёртку: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/Mak...
2all: www.openbsd.org уже в строю.
>> В принципе, то же самое применимо,
>> думаю, и к
>> OpenBSD-шному apache, если они его на свои mk files перевели,
>> лениво проверять.
> Не совсем перевели, сделали обёртку: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/Mak...В таком случае, все еще проще. Инфраструктура ./configure, как я вижу,
сохраняется.
Все, что нужно сделать -- избавиться от диалектов OpenBSD make и перевести
их в диалекты NetBSD make-а :-) Потом, немного причесать переменные и таргеты,
т.е. привести их в соответствие mk-configure.
День работы максимум, и супер-пупер пропатченный OpenBSD-шниками apache-1.3,
работающий подо все, что вижется у вас в кармане.Если чуть дольше, то можно и от configure избавиться.
Было бы кому-то это нужно.
> Все, что нужно сделать -- избавиться от диалектов OpenBSD...ну ты понял :]
Миша, не дразни меня, а то ведь я сделаю.
апача 1.3.27 входит в поставку и устраивает по лицензии. Хотите свежее - пакеты и порты доступны и свежи. Да и кому в голову придет поднимать на опенке высокопроизводительный вебсервер и на самом свежем apache? за gcc не скажу.
Важно то, что система стабильна и гонки "вооружений"(свежий софт) в ней не придерживаются.
А то, что требуется от этой системы, в ней есть из коробки: все что нужно для фильтрации пакетов, маршрутизации и постороения ipsec тунелей. Список можно продолжить.
Спасибо разработчикам.
прежде чем употреблять слово "раритет" (я об apache) тебе, думаю, стоило бы ознакомиться с предметом обсуждения.
да зачем ему, у него же очки +200 к интеллекту на черепушке :)
>Уже скачал образ. Скоро буду ставить на десктопОт Вас разит
>ldapd(8)LDAP-сервер, лёгкая альтернатива OpenLDAP.А вот это интересно, а вот это зачем?
>>Уже скачал образ. Скоро буду ставить на десктоп
> От Вас разитНа домашнем компе, на ноутбуке, на рабочем компе стоит опёнок. Полёт уже не первый год нормальный. Будете спорить о вкусе устриц с теми, кто их ел?
>>ldapd(8)LDAP-сервер, лёгкая альтернатива OpenLDAP.
> А вот это интересно, а вот это зачем?Наверное, затем, что это лёгкая альтернатива? Быстрая, компактная и простая в обслуживании. Если её возможностей кому-то будет хватать, почему бы и нет?
>>> Уже скачал образ. Скоро буду ставить на десктоп
>> От Вас разит
> На домашнем компе, на ноутбуке, на рабочем компе стоит опёнок. Полёт уже
> не первый год нормальный. Будете спорить о вкусе устриц с теми,
> кто их ел?А мне и в QNX нравиться рабочий стол. Хотя по старинке пользуюсь Widnows. Скоро правдо придется серьезно задуматься, так как практически все операции приходиться делать под виртуалками Lunux/FreeBSD.
сайт лежит
> сайт лежитЕсть такое. Этот сервер обслуживает несколько проектов, так что трудно сказать, кто там виноват. Сведений пока нет. :(
все качают
> все качаютКогда уже TORRENT будет.
>> все качают
> Когда уже TORRENT будет.Сделайте. Это open source, причём ни разу не коммерческий. А вообще дело не в скачивании, конечно; больше похоже на технические проблемы.
Пока что можно пользоваться http://openbsd.org/ (без «www.») — но учтите, что это совсем другой сервер, личная машина Тео, с ограниченным каналом.
> Сделайте.Что значит "сделайте"? Взломать их сервер и поднять там трекер, только чтобы самому скачать? Сделайте сами если это так легко.
>> Сделайте.
> Что значит "сделайте"? Взломать их сервер и поднять там трекер, только чтобы
> самому скачать? Сделайте сами если это так легко.Никто не говорил, что что-то там легко. Зачем взламывать, не пойму? Можно просто попробовать договориться. Сами разработчики не особо заинтересованы в торрентах, AFAIK, но вряд ли будут иметь что-то против, если вы соответствующую инфраструктуру обеспечите.
>>> все качают
>> Когда уже TORRENT будет.
> Сделайте. Это open source, причём ни разу не коммерческий. А вообще дело
> не в скачивании, конечно; больше похоже на технические проблемы.
> Пока что можно пользоваться http://openbsd.org/ (без «www.») — но учтите,
> что это совсем другой сервер, личная машина Тео, с ограниченным каналом.А лучше — вот список зеркал:
http://openbsd.md5.com.ar/
http://openbsd.das.ufsc.br/
http://www.openbsd.dk/
http://openbsd.bsdfrog.org/
http://openbsd.corebsd.or.id/
http://www.openbsd.it/
http://www.openbsdindia.org/
http://www.jp.openbsd.org/
http://www.openbsd.org.my/
http://openbsd.nuug.no/
http://openbsd.chem.uw.edu.pl/
http://openbsd.default.rs/
http://openbsd.alphix.se/
http://www.obsd.si/
http://www.tw.openbsd.org/
http://openbsd.fries.net/
кто из торрента будет тянуть, когда есть фтп/хттп?
> кто из торрента будет тянуть, когда есть фтп/хттп?Очевидно, не успевший взять по ftp/http до захлёбывания дисковых подсистем/каналов и по каким бы то ни было причинам не хотящий откладывать.
>Появилась начальная поддержка UTF-8 в libc и консоли.Погодите. То есть в самой консоли тоже появилась? Я считал, что пока что она работает только в эмуляторах терминала, которые умеют юникод. Но сам драйвер консоли (wscons, верно) в OpenBSD юникод не поддерживает, а значит, в текстовом режиме (без иксов) юникода не будет. Я ошибаюсь? Если да, то просто охренительно круто)
В current вроде уже попала поддержка UTF в ncurses, что еще осталось для полной поддержки юникода?
>>Появилась начальная поддержка UTF-8 в libc и консоли.
> Погодите. То есть в самой консоли тоже появилась?Ключевое слово — начальная.
> Я считал, что пока
> что она работает только в эмуляторах терминала, которые умеют юникод. Но
> сам драйвер консоли (wscons, верно) в OpenBSD юникод не поддерживает, а
> значит, в текстовом режиме (без иксов) юникода не будет. Я ошибаюсь?
> Если да, то просто охренительно круто)Да обсуждали мы уже это всё, когда эти изменения только-только вносились...
> В current вроде уже попала поддержка UTF в ncurses, что еще осталось
> для полной поддержки юникода?Решить вопросы со шрифтами и драйвером консоли, как я понимаю. Самый тонкий и трудный момент, в том числе потому, что если с libc можно было ориентироваться как-то на фряху, то wscons-то оттуда давным давно выпилили... Спросите на misc@ , если не боитесь, что отправят лесом. :)
http://bsdly.blogspot.com/2010/10/if-it-runs-openbsd-it-has-... - небольшая заметка от одного из разработчиков OpenBSD. Среди прочих перлов - рекомендации ставить систему, сверяя целостность файлов с нескольких зеркал. :)
> http://bsdly.blogspot.com/2010/10/if-it-runs-openbsd-it-has-... - небольшая
> заметка от одного из разработчиков OpenBSD. Среди прочих перлов - рекомендации
> ставить систему, сверяя целостность файлов с нескольких зеркал. :)Перл, не перл, а логика в этом есть. Помните, как появилась в своё время большущая дырка в OpenSSH? А за зеркалами следят далеко не всегда столь же серьёзно, как за основным сервером.
Конечно логика есть. Уж релизы-то подписывать ЭЦП они могли бы, согласитесь. Я вот всё жду, когда же начнут... Даже давний взлом FTP-сервера проекта их, видимо, ничему не научил. А ведь усилий минимум, и не пришлось бы предлагать ерунду о проверке хэшей с разных зеркал.Проблема есть, косвенно признанна, но решение предлагается негодное. Что, если взломщик контролирует канал связи жертвы? В этом случае он может подменить файлы, с каких бы зеркал они запрошены ни были. Но если жертва для проверки целостности файлов применяет настоящий публичный ключ (условимся, что он был успешно получен ранее - например, для проверки файлов предыдущих релизов), то подсадка трояна значительно усложнится.
О сложности эксплуатации уязвимостей в ядре OpenBSD (по ссылке об этом тоже написано) - неправда. Корректность кода усложняет поиск уязвимостей, поскольку встречаются они реже, но не их экслпуатацию, оцените сами: http://www.securiteam.com/exploits/5JP092KKAM.html
В последних версиях подобный эксплойт работать не будет, потому что в 2009-ом в OpenBSD ввели запрет на маппинги нулевого адреса (кстати, где-то на год позже, чем в ванильном линуксе). То есть, сработает конкретный механизм защиты от эксплуатации, а не некие последствия от аккуратного написания и аудита кода.
Ну и вообще, априори склоняться к версии о троянах в установочных файлах - непрофессионально, как минимум. Разработчики OpenBSD не тратят на аудит и толику того времени, которое будет потрачено на поиск уязвимостей взломщиком, который поставит перед собой чёткую цель и не будет стеснён сроками.
> Конечно логика есть. Уж релизы-то подписывать ЭЦП они могли бы, согласитесь. Я
> вот всё жду, когда же начнут... Даже давний взлом FTP-сервера проекта
> их, видимо, ничему не научил. А ведь усилий минимум, и не
> пришлось бы предлагать ерунду о проверке хэшей с разных зеркал.
> Проблема есть, косвенно признанна, но решение предлагается негодное. Что, если взломщик
> контролирует канал связи жертвы? В этом случае он может подменить файлы,
> с каких бы зеркал они запрошены ни были. Но если жертва
> для проверки целостности файлов применяет настоящий публичный ключ (условимся, что он
> был успешно получен ранее - например, для проверки файлов предыдущих релизов),
> то подсадка трояна значительно усложнится.Насчёт ЭЦП — AFAIK, дело в первую очередь в том, что для её проверки надо увеличивать объём всех установочных образов на размер соответствующих библиотек. Когда бой идёт за каждый килобайт, это практически неприемлемо. :(
Были разговоры об ЭЦП для бинарных пакетов. В принципе, функции для работы с ними утилиты pkg_* заложены, однако централизованное подписывание, по словам, если правильно помню, Marc Espie, упирается в сложности организационного характера.
А так, да, выход для параноиков — сливать через анонимный SFTP исходники и собирать релиз самостоятельно. :)
> О сложности эксплуатации уязвимостей в ядре OpenBSD (по ссылке об этом тоже
> написано) - неправда. Корректность кода усложняет поиск уязвимостей, поскольку встречаются
> они реже, но не их экслпуатацию, оцените сами: http://www.securiteam.com/exploits/5JP092KKAM.html
> В последних версиях подобный эксплойт работать не будет, потому что в 2009-ом
> в OpenBSD ввели запрет на маппинги нулевого адреса (кстати, где-то на
> год позже, чем в ванильном линуксе). То есть, сработает конкретный механизм
> защиты от эксплуатации, а не некие последствия от аккуратного написания и
> аудита кода.С другой стороны, последствия аккуратного написания и аудита кода не так-то легко вычислить порой. ;) Кто знает, не будь этого аудита, была бы во-о-он в той функции такая-то ошибка, или нет? :)
> Ну и вообще, априори склоняться к версии о троянах в установочных файлах
> - непрофессионально, как минимум. Разработчики OpenBSD не тратят на аудит и
> толику того времени, которое будет потрачено на поиск уязвимостей взломщиком, который
> поставит перед собой чёткую цель и не будет стеснён сроками.Хых, это-то понятно. Но и относится это к любой системе, а не только к OpenBSD. ;)
> Насчёт ЭЦП — AFAIK, дело в первую очередь в том, что для
> её проверки надо увеличивать объём всех установочных образов на размер соответствующих
> библиотек. Когда бой идёт за каждый килобайт, это практически неприемлемо. :(Это относится только к образам установочных дискет. Есть образы установочных сидюков - там места хватает. Как минимум можно подписывать файлы без включения библиотек в образ установочных дискет, и пусть пользователи проверяют их хотя бы в полуавтоматическом режиме.
> Были разговоры об ЭЦП для бинарных пакетов. В принципе, функции для работы
> с ними утилиты pkg_* заложены, однако централизованное подписывание, по словам, если
> правильно помню, Marc Espie, упирается в сложности организационного характера.Жаль. Я думал, хотя бы пакеты начали подписывать.
> А так, да, выход для параноиков — сливать через анонимный SFTP исходники
> и собирать релиз самостоятельно. :)Да, можно сливать исходники системы и дерева портов по SSH, и всё собирать самому. Я так и делал, когда пользовался.
> С другой стороны, последствия аккуратного написания и аудита кода не так-то легко
> вычислить порой. ;) Кто знает, не будь этого аудита, была бы
> во-о-он в той функции такая-то ошибка, или нет? :)Аудит не бесполезен, но эксплуатацию уязвимостей он может усложнить лишь косвенно - только в тех случаях, когда эксплуатация "основной" уявзимости невозможна или сильно затруднена без использования каких-то "вспомогательных". Но в этом смысле написание эксплойтов к большинству опубликованных уязвимостей аудит опять-таки никак не затруднил.
> Хых, это-то понятно. Но и относится это к любой системе, а не
> только к OpenBSD. ;)Я критиковал отдельно взятое мнение Петера Ханстеена (многие другие разработчики его разделяют). Фактически, это лицемерие: внедрить ряд механизмов зищиты пользовательских процессов от эксплуатации, и не сделать ничего подобного для ядра, в котором, как и в приложениях, были, есть и будут уязвимости, и при этом создавать впечатление у пользователей о достаточности аудита, как меры предотвращения эксплуатации (а не усложнения поиска) уязвимостей. Это подмена практически значимых понятий.
>> Насчёт ЭЦП — AFAIK, дело в первую очередь в том, что для
>> её проверки надо увеличивать объём всех установочных образов на размер соответствующих
>> библиотек. Когда бой идёт за каждый килобайт, это практически неприемлемо. :(
> Это относится только к образам установочных дискет. Есть образы установочных сидюков -
> там места хватает. Как минимум можно подписывать файлы без включения библиотек
> в образ установочных дискет, и пусть пользователи проверяют их хотя бы
> в полуавтоматическом режиме.Ну и как вы это себе представляете? Подписывание означает шифрование. То есть надо тогда два комплекта установочных файлов распространять, получается, подписанные и неподписанные? А какой из этих комплектов записывать на оригинальные диски с релизом?..
>> Были разговоры об ЭЦП для бинарных пакетов. В принципе, функции для работы
>> с ними утилиты pkg_* заложены, однако централизованное подписывание, по словам, если
>> правильно помню, Marc Espie, упирается в сложности организационного характера.
> Жаль. Я думал, хотя бы пакеты начали подписывать.Можно спросить, в принципе. Сложность, повторюсь, в организации центра сертификации и тому подобных вещах.
>> С другой стороны, последствия аккуратного написания и аудита кода не так-то легко
>> вычислить порой. ;) Кто знает, не будь этого аудита, была бы
>> во-о-он в той функции такая-то ошибка, или нет? :)
> Аудит не бесполезен, но эксплуатацию уязвимостей он может усложнить лишь косвенно -
> только в тех случаях, когда эксплуатация "основной" уявзимости невозможна или сильно
> затруднена без использования каких-то "вспомогательных". Но в этом смысле написание эксплойтов
> к большинству опубликованных уязвимостей аудит опять-таки никак не затруднил.Согласен.
>> Хых, это-то понятно. Но и относится это к любой системе, а не
>> только к OpenBSD. ;)
> Я критиковал отдельно взятое мнение Петера Ханстеена (многие другие разработчики его разделяют).
> Фактически, это лицемерие: внедрить ряд механизмов зищиты пользовательских процессов
> от эксплуатации, и не сделать ничего подобного для ядра, в котором,
> как и в приложениях, были, есть и будут уязвимости, и при
> этом создавать впечатление у пользователей о достаточности аудита, как меры предотвращения
> эксплуатации (а не усложнения поиска) уязвимостей. Это подмена практически значимых понятий.Ну, положим, в ядре OpenBSD есть свои механизмы защиты. Той же рандомизации там немало... Насчёт же создания впечатления — OpenBSD не создаётся для пользователей, которые сами не могут рассчитать, что им нужно. ;) Именно этим она сильно выделяется среди большинства других ОС. Подмена понятий происходит у тех, у кого и так каша в голове. У вас ведь не происходит? ;)
> Ну и как вы это себе представляете? Подписывание означает шифрование. То естьНе верю, что вы всерьёз так заблуждаетесь. Наверное это какой-то троллинг. :) Но на всякий случай: нет, подписывание не означает шифрование и не требует создания отдельных комплектов файлов.
> Можно спросить, в принципе. Сложность, повторюсь, в организации центра сертификации и тому
> подобных вещах.Сложностей на самом деле нет, усилий - минимум. Они просто по-своему расставили приоритеты и банально не хотят этим заниматсья, как в ванильном линуксе не хотят заниматься безопасностью или проблемой с вводом-выводом на некоторых винтах.
> Ну, положим, в ядре OpenBSD есть свои механизмы защиты. Той же рандомизации
Последний раз, когда мне говорили, что они там есть, я проверял и не нашёл. Подозреваю, что воз и ныне там. Это продолжение всё той же проблемы: факты искажаются и замалчиваются, у пользователей формируется ложное впечатление, а чётко поданой информации в открытых источниках нет.
> там немало... Насчёт же создания впечатления — OpenBSD не создаётся для
> пользователей, которые сами не могут рассчитать, что им нужно. ;) ИменноВ таком случае зачем все эти петеры ханстеены пишут глупости в блогах? Чтобы ложно изложить суть дела для тех, кто и сам разбирается? Или вот типичный пример казуистики от разработчиков OpenBSD: http://quigon.bsws.de/papers/2010/bsdcan/mgp00056.html
Зрителям кагбе намекают, что в джаве тоже есть целочисленные переполнения, и из этого следует что? Что в джаве можно эксплуатировать переполнения для выполнения произвольного кода, как в Си? Ну так на самом-то деле нельзя. И что же это, как не игра слов и подмена понятий? И на кого она рассчитана? Явно не на пользователей-экспертов. Далее против джавы выдвинуты аргументы, общие для подавляющего большинства языков - если их отбросить, станет ясно, что в плане безопасности Си джаве просто нечего противопоставить.
О существовании других типобезопасных языков, в т.ч. совместимых с Си (D, D2, Cyclone + трансляторы в Си с других языков), почему-то умалчивается. Где же конструктивная самокритика и умение признать недостатки сделанного выбора? "Да, есть хорошие типобезопасные языки, но проект OpenBSD их не использует по ряду причин нетехнического характера" - вот, что я бы хотел услышать от них вместо этой казуистики. Хотя бы раз!
> этим она сильно выделяется среди большинства других ОС. Подмена понятий происходит
> у тех, у кого и так каша в голове. У вас ведь не происходит? ;)Раньше происходила. Я просто не стал зацикливаться и верить разработчикам на слово.
>> Ну и как вы это себе представляете? Подписывание означает шифрование. То есть
> Не верю, что вы всерьёз так заблуждаетесь. Наверное это какой-то троллинг. :)
> Но на всякий случай: нет, подписывание не означает шифрование и не
> требует создания отдельных комплектов файлов.Меня тут уже поправили, я чего-то стормозил: достаточно подписывать файлы сумм. Но это таки обозначает шифрование. Подписывание = шифрование закрытым ключом. Проверка = расшифровка открытым ключом. Так что исходный тезис остаётся в силе. А иметь образы, которые не делают проверку — это половинчатое решение. Из разряда «с вероятностью 1/10 данный сервис будет запущен с правами рута». Это как раз и будет видимость защиты.
>> Можно спросить, в принципе. Сложность, повторюсь, в организации центра сертификации и тому
>> подобных вещах.
> Сложностей на самом деле нет, усилий - минимум. Они просто по-своему расставили
> приоритеты и банально не хотят этим заниматсья, как в ванильном линуксе
> не хотят заниматься безопасностью или проблемой с вводом-выводом на некоторых винтах.Можно сказать и так, про приоритеты.
>> Ну, положим, в ядре OpenBSD есть свои механизмы защиты. Той же рандомизации
> Последний раз, когда мне говорили, что они там есть, я проверял и
> не нашёл. Подозреваю, что воз и ныне там. Это продолжение всё
> той же проблемы: факты искажаются и замалчиваются, у пользователей формируется ложное
> впечатление, а чётко поданой информации в открытых источниках нет.В основном они касаются рандомизации (много как источников, так и потребителей случайных данных), ну и стандартно включённые в GCC механизмы. Тот же ProPolice в OpenBSD включён по дефолту, и сейчас перепроверил — при сборке ядра -fno-stack-protector не используется.
>> там немало... Насчёт же создания впечатления — OpenBSD не создаётся для
>> пользователей, которые сами не могут рассчитать, что им нужно. ;) Именно
> В таком случае зачем все эти петеры ханстеены пишут глупости в блогах?
> Чтобы ложно изложить суть дела для тех, кто и сам разбирается?Излагает своё видение, только и всего. Иногда сны, это просто сны. ;) Теорию заговоров оставьте тем, кого хватает лишь на переложение Умберто Эко. :)
> Или вот типичный пример казуистики от разработчиков OpenBSD: http://quigon.bsws.de/papers/2010/bsdcan/mgp00056.html
Хм. Не совсем понял, что здесь не так? Утверждение, что нет ни одной абсолютно безопасной системы? :)
> Зрителям кагбе намекают, что в джаве тоже есть целочисленные переполнения, и из
> этого следует что? Что в джаве можно эксплуатировать переполнения для выполнения
> произвольного кода, как в Си? Ну так на самом-то деле нельзя.
> И что же это, как не игра слов и подмена понятий?
> И на кого она рассчитана? Явно не на пользователей-экспертов.Это вы домыслили, что их (переполнения) напрямую можно для этого использовать. Так что кто ещё занимается подменой понятий. ;) Если хотите узнать, что стояло за этими словами, надо бы спросить аффтара. Это ж всё-таки только презентация, без расшифровки речи её ведущего. Насколько я понимаю идею, путём провоцирования переполнений можно как минимум вызвать удалённый DoS...
> Далее против
> джавы выдвинуты аргументы, общие для подавляющего большинства языков - если их
> отбросить, станет ясно, что в плане безопасности Си джаве просто нечего
> противопоставить.Так смысл в не в том, что «Java — суксь», а в том, что она не есть панацея.
> О существовании других типобезопасных языков, в т.ч. совместимых с Си (D, D2,
> Cyclone + трансляторы в Си с других языков), почему-то умалчивается. Где
> же конструктивная самокритика и умение признать недостатки сделанного выбора? "Да, есть
> хорошие типобезопасные языки, но проект OpenBSD их не использует по ряду
> причин нетехнического характера" - вот, что я бы хотел услышать от
> них вместо этой казуистики. Хотя бы раз!OpenBSD их не использует по ряду причин как технического, так и нетехнического характера. Это где-то в списках рассылки мелькало... Суть аргументов опёнковцев сводится к тому, что: 1. На Си _можно_ писать удобочитаемый безопасный код, и при этом остаётся доступной его несравненная гибкость и нетребовательность к ресурсам; 2. Компиляторы C, по крайней мере некоторые, на порядок надёжнее компиляторов С++ (это к вопросу о плавной миграции), не говоря о D и иже с ним; 3. Портабельность как одна из основных идей фактически вынуждает к использованию Си — потому что код на Си уже есть и работает, а тот же какой-нибудь Оберон _и_все_необходимые_библиотеки_ портировать на кучу платформ... «сам топи урановые ломы в ртути» © BOR. :)
Типобезопасное ядро? Это возможно, конечно. Только кто им будет пользоваться, если оно будет при этом нещадно тормозить по сравнению с конкурентами? А оно будет.
А так — разработчики и Perl не брезгуют (pkg_*), и шелл-скриптингом (sysmerge и ещё один сюрприз, который будет в новом отчёте)... они, правда, тоже не слишком типобезопасные. :-\ Впрочем, pkg_* написаны в ООП-стиле, почти весь функционал вынесен в модули.
Так что Си — это просто данность, да. И опёнковцы сделали немало, чтобы эту данность максимально улучшить. По крайней мере, уязвимостей во всей системе находят меньше, чем в том же OpenJDK. ;)
>> этим она сильно выделяется среди большинства других ОС. Подмена понятий происходит
>> у тех, у кого и так каша в голове. У вас ведь не происходит? ;)
> Раньше происходила. Я просто не стал зацикливаться и верить разработчикам на слово.Значит, у вас всё в порядке, как я понимаю. :) Чему, собственно, искренне рад.
> Меня тут уже поправили, я чего-то стормозил: достаточно подписывать файлы сумм. Но
> это таки обозначает шифрование. Подписывание = шифрование закрытым ключом. Проверка =
> расшифровка открытым ключом. Так что исходный тезис остаётся в силе. А*facepalm* Тезис о необходимости двух комлпектов файлов? С ним уже разобрались. Остальное - игра в слова вне изначального контекста.
> иметь образы, которые не делают проверку — это половинчатое решение. Из
Повторяю: ничто не мешает реализовать проверку подписей в инсталляторе для сидюков. И кстати, целостность этих образов пользователь тоже должен будет проверять самостоятельно.
> разряда «с вероятностью 1/10 данный сервис будет запущен с правами рута».
> Это как раз и будет видимость защиты.Ничего вероятностного в проверке подписей нет: они или совпадут, или нет.
> Можно сказать и так, про приоритеты.
Да. Но вместо этого они рассказывают о сложностях, об иллюзорности защиты с помощью ЭЦП (подменяют наличие рисков иллюзорностью защиты вообще) и вместе с тем о незначительности этих рисков, связанных с подменой файлов, предлагая негодные решения для их минимизации (вроде сопоставления файлов с нескольких зеркал).
> В основном они касаются рандомизации (много как источников, так и потребителей случайных
> данных), ну и стандартно включённые в GCC механизмы. Тот жеТо есть, ничего существенного (за исключением недавнего запрета на маппинг нулевого адреса). Ядро - очень сложная программа с массой внешних интерфейсов, в которых априори есть уязвимости к утечкам ифнормации, включая рандомизированные значения. Нельзя считать рандомизацию (которая там, допустим, есть ещё где-то, кроме как на стеке) сколько-нибудь достаточной мерой. Сомневаетесь - спросите мнения экспертов на Full-Disclosure.
Уязвимость в IPv6 помните? Выполнение кода в области данных, внутриядерным аналогом W^X предотвращается на раз. При этом CORE Security предложили реализовать именно такую защиту (в т.ч. для x86). И где же пресловутый проактивный подход к обеспечению безопасности в OpenBSD? Вопрос риторический, ибо даже с реактивным запаздывают.
> ProPolice в OpenBSD включён по дефолту, и сейчас перепроверил — при
> сборке ядра -fno-stack-protector не используется.А если он в спецификациях GCC указан? Лучше посмотрите в дизассемблере код функций перед возвратом.
> Излагает своё видение, только и всего. Иногда сны, это просто сны. ;)
Это "видение" вводит читателей в заблуждение. Вот пара выводов оттуда:
1. Для проверки целостности установочных файлов достаточно получить их с нескольких надёжных зеркал и удостовериться, что содержимое одинаково.
2. Аудит кода усложняет эксплуатацию (а не поиск) уязвимостей в ядре.Почему эти выводы ложные, я уже объяснил.
> Теорию заговоров оставьте тем, кого хватает лишь на переложение Умберто Эко.
> :)Не доводите до абсурда. Выдавать желаемое за действительное можно по многим причинам.
> Хм. Не совсем понял, что здесь не так? Утверждение, что нет ни
> одной абсолютно безопасной системы? :)Я уже сказал, что не так: игра слов вокруг integer overflow, которые в Си и в джаве совершенно разные по семантике (в джаве нет мутабельных указателей на произвольные адреса, есть только индексы).
> Это вы домыслили, что их (переполнения) напрямую можно для этого использовать. Так
Конечно я домыслил - смысловой контекст к этому и подводит.
> что кто ещё занимается подменой понятий. ;) Если хотите узнать, что
Хватит юлить. Термин "integer overflow" дан в контексте, который способствует неверному толкованию.
> стояло за этими словами, надо бы спросить аффтара. Это ж всё-таки
> только презентация, без расшифровки речи её ведущего. Насколько я понимаю идею,Слайдом раньше этот искренний и непредвзятый автор предложил погуглить "java vulnerability", чем и подготовил контекст для термина "integer overflow". Можно, конечно, предположить, что на словах он выразил суть более чётко и ясно. Кстати, в случае с "java vulnerability" снова подмена понятий: были смешаны джава как платформа и джава как язык - то есть без уточнений.
> путём провоцирования переполнений можно как минимум вызвать удалённый DoS...
Даже DoS далеко не во всех случаях. В джаве можно ловить исключения.
> Так смысл в не в том, что «Java — суксь», а в
> том, что она не есть панацея.Смыслов тут может быть больше одного - риторика в слайдах оставляет выводы на совести зрителей.
> OpenBSD их не использует по ряду причин как технического, так и нетехнического
При наличии нетехнических причин, технические очень легко надумать: ой нестабильность, ой низкая производительность, ой непортабельность. И главное, априори.
А на деле... Код на типобезопасных языках гораздо более стабилен, особенно если писать его так же аккуратно. На типобезопасных языках написаны высоконадёжные системы такой сложности, рядом с которой OpenBSD со всеми потрохами и рядом не валялась.
То же самое с производительностью. Эти люди дробят приложения на непривилегированные процессы, увеличивая число переключения контекстов и циклов сериализации/десериализации для обмена данными между процессами только ради того, чтобы подпереть костылём небезопасные типы в Си.
То же самое с надуманной непериносимостью, как будто Си тут непревзойдён. Пляски вокруг выравнивания структур, endianess, размеров буферов в динамической памяти и разных размеров значений типов на разных платформах - это переносимость? Не смешно.
> характера. Это где-то в списках рассылки мелькало... Суть аргументов опёнковцев сводится
> к тому, что: 1. На Си _можно_ писать удобочитаемый безопасный код,Нельзя на Си писать такой код.
> и при этом остаётся доступной его несравненная гибкость и нетребовательность к
> ресурсам; 2. Компиляторы C, по крайней мере некоторые, на порядок надёжнееЧто вы понимаете под несравненной гибкостью? И в сравнении с чем, по-вашему, она несравненна? Даже если спорить на эту тему не хотите, просто дайте ответ - мне интересно для личной статистики.
> компиляторов С++ (это к вопросу о плавной миграции), не говоря о
> D и иже с ним; 3. Портабельность как одна из основныхВот так вот: и иже с ним. То есть, пилить собственный доисторический PCC, плетясь далеко позади GCC в плане оптимизации кода - это как по-вашему, надёжнее, проще, эффективнее, производительнее? Вы хотя бы отдаёте себе отчёт, что проще написать оптимизирующий компилятор для типобезопасного, статически типизированного языка, нежели для Си или С++?
> идей фактически вынуждает к использованию Си — потому что код на
Интересно получается: других не вынуждает, а разработчиков OpenBSD фактически вынуждает. Я думаю, отсутствие заинтересованности тут не следствие, а причина.
> Си уже есть и работает, а тот же какой-нибудь Оберон _и_все_необходимые_библиотеки_
> портировать на кучу платформ... «сам топи урановые ломы в ртути» ©
> BOR. :)Какой-нибудь оберон, как и другие языки, можно транслировать в Си и собирать любым доступным компилятором. Вы как-то очень избирательно комментируете.
> Типобезопасное ядро? Это возможно, конечно. Только кто им будет пользоваться, если оно
> будет при этом нещадно тормозить по сравнению с конкурентами? А оно
> будет.Это сейчас ядро, написанное на Си, нещадно тормозит по сравнению с конкурентами, потому что мутабельные структуры данных облепили совместным доступом с блокировками, и совершенствовать это чудо научно-технической мысли и венец гибкости языка Си с оглядкой на реалии почему-то вдруг стало сложно.
> А так — разработчики и Perl не брезгуют (pkg_*), и шелл-скриптингом (sysmerge
> и ещё один сюрприз, который будет в новом отчёте)... они, правда,Ещё бы они брезговали: старый, привычный ширпотреб - учиться самим и учить других ничему новому не надо.
> Так что Си — это просто данность, да. И опёнковцы сделали немало,
> чтобы эту данность максимально улучшить. По крайней мере, уязвимостей во всей
> системе находят меньше, чем в том же OpenJDK. ;)Вы хотя бы понимаете, что в процессе аудита и корректирования кода многие уязвимости правятся без огласки и осознания их статуса? В деталях вы сами себе противоречите и путаетесь в понятиях: исправляют, находят, публикуют.
> Значит, у вас всё в порядке, как я понимаю. :) Чему, собственно,
> искренне рад.Что вы, порядок нам только снится. На практике в силу разных причин приходится применять костыли, ширпотреб, убогое наследие предков и прочий срам.
> То же самое с производительностью. Эти люди дробят приложения
> на непривилегированные процессы,
> увеличивая число переключения контекстов и циклов сериализации/десериализации для обмена
> данными между процессами только ради того, чтобы подпереть костылём небезопасные типы
> в Си.Ох, как же я с тобой здесь согласен. Черт побери! :-)
То же самое на самом деле касается и пресловутой новомодной виртуализации,
когда для отдельного сервиса(!) отводят отдельную виртуальную машину
в целях безопастности. Ну бред же в чистом виде! Очередной костыль под
небезопасный С.> Вот так вот: и иже с ним. То есть, пилить собственный доисторический
> PCC, плетясь далеко позади GCC в плане оптимизации кода - это
> как по-вашему, надёжнее, проще, эффективнее, производительнее?А вот этого не надо. От замшелого PCC 70-х сейчас там практически ничего не осталось.
Что касается отсталости в оптимизации от gcc, она есть и наверняка будет еще долго,
но это не так важно. От 3% процентного выигрыша никому легче не станет, а вот код
pcc на несколько порядков меньше кода gcc, что является несомненным преимуществом
в плане его поддержки и развития.
Simplicity is a prerequisite for stability. Это не единственный фактор,
но он тоже очень важен.> Вы хотя бы отдаёте себе
> отчёт, что проще написать оптимизирующий компилятор для
> типобезопасного, статически типизированного
> языка, нежели для Си или С++?Не надо ля-ля. Это сильно зависит от конкретного типа и вида "типобезопасного" языка.
В общем случае утверждение ложно. Разработка же JIT настолько дорога в плане людских ресурсов, что BSD-ки вряд ли это потянут. Да оно и не нужно, достаточно более менее эффективного шитого кода, он разрабатывается задешего.> Какой-нибудь оберон, как и другие языки, можно транслировать в Си и собирать
> любым доступным компилятором. Вы как-то очень избирательно комментируете."И другие языки"? Гониво! Fortran ПРАВИЛЬНО конвертировать в С, и соблюсти при этом
все отребования Фортрана к работе с плавающей точки нельзя. Я сейчас пруфлинки не приведу,
но такие места есть. f2c идет в..., я не скажу куда он идет.> Что вы, порядок нам только снится. На практике в силу разных причин
> приходится применять костыли, ширпотреб, убогое наследие предков и прочий срам.Eric Raymond.
"Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough."Я надеюсь, очевидно, что Plan-9 тут ни причем ;-)
> А вот этого не надо. От замшелого PCC 70-х сейчас там практически
> ничего не осталось.Я о другом хотел сказать: у них всегда находятся отговорки, чтобы не использовать что-то, выходящее за рамки привычных, но морально устаревших технологий, и при этом на доводку и переделывание привычного выделяются очень значительные ресурсы, которых было бы вполне достаточно для создания того же транслятора оберона в Си, для освоения эрланга под прикладные задачи и т.п.. Плюс NIH-синдром.
> Не надо ля-ля. Это сильно зависит от конкретного типа и вида "типобезопасного"
> языка.Это очень слабо зависит от "типа и вида", если не притягивать за уши JIT-компиляцию и не занижать планку требований к качеству оптимизаций.
> "И другие языки"? Гониво! Fortran ПРАВИЛЬНО конвертировать в С, и соблюсти при
> этомНу почему гонево. Допустим, фортран нельзя, но он уже в GCC и сфера применения у него узкая. Я имел ввиду прежде всего обероны и D2. Другие языки тут на их месте сложнее представить. Тем более фортран. :)
>> А вот этого не надо. От замшелого PCC 70-х сейчас там практически
>> ничего не осталось.
> Я о другом хотел сказать: у них всегда находятся отговорки, чтобы не
> использовать что-то, выходящее за рамки привычных, но морально устаревших технологий,
> и при этом на доводку и переделывание привычного выделяются очень значительные
> ресурсы, которых было бы вполне достаточно для создания того же транслятора
> оберона в Си, для освоения эрланга под прикладные задачи и т.п..
> Плюс NIH-синдром.Я не могу сказать ничего про OpenBSD. Но вот в NetBSD после долгого и кровопролитного
(почти без кавычек) обсуждения все-таки приняли решение включить Lua в базовую систему.
Во FreeBSD тянут D-Trace и zfs.
То есть не совсем уж BSD-ки невосприимчивы ко всему новому. Не знаю, как во FreeBSD
и в OpenBSD, а в NetBSD опять же с большим уважением относятся к дизайну Соляриса,
и периодически тянут оттуда внутриядерные API для подсистем. Кое-что тянут и из Линукса, скажем /proc/cpuinfo и /proc/<pid>/maps. Мелочи, но тем не менее.Несколько лет назад, оплатив услуги одного (одного!!!) человека избавились практически полностью от Giant lock, и реализовали 1:1 потоки,
не растягивая этот процесс на 8 лет, в отличие от других.
Кого это касается, поймут ;-) Правда, с sheduled activations поигрались в 2.0-4.0,
но аккуратнее, никого не тряся и не сбрасывая с лодки.С другой чтороны FUSE реализовали лучше, чем у других, не став тупо копировать
чужие ошибки проектирования.Включили, наконец, stack smashing protection по умолчанию.
Вроде и на ядро, и на libc и на юзерспейс, но тут надо проверить.
Обсуждалось по крайней мере тоже долго.То есть, я бы сказал, вполне адекватно они воспринимают окружающий мир.
Но надо иметь ввиду вот что. BSD - это не линупс и не соляра.
Здесь нет миллиардов/миллионов вливаемых
долларов, поэтому очень важный момент -- эффективность труда каждого
отдельного человека и соответственное всего процесса разработки. Я не оправдываю имеющийся консерватизм, но все же, сколько денег (времени) понадобиться для того, чтобы обучить каждого разработчика {Net,Open,Free}BSD
языку Erlang, D или Oberon2? Сколько времени понадобится на поддержку кода g++?
Выкинули его из базовой системы -- и правильно сделали. Выкинули плюсовый groff --
туда ему дорога, следом за С++.
Оно дешевле в долговременной перспективе. И по деньгам и по времени.Ну а с тем, сколько "весят" Erlang и Oberon2 надо еще разобраться.
Я не интересовался. Отдельный вопрос по лицензии.Что касается NIH синдрома. Да покажите мне ХОТЬ одну систему, где его нет!
Вот почему, скажем в Линупсе нет kqueue???
Или strl* - так это же вообще сказка. Два человека, Торвальдс и Дреппер против.
Все, пипец. Эти функции есть ВЕЗДЕ (Cygwin, Interix, Haiku, OpenBSD, NetBSD, DragonFlyBSD, MacOS-X, Solaris, IRIX).
А эти "аргументы" про "мастурбирующих обезъян" или "некомпетентных идиотов".
Ну это это чистая дикость!Параноики в AltLinux глаза двух Богов не побоялись, включили у себя в libc функции strlcat/strlcpy. Честь им и хвала, хоть в этом, за смелость.
>> Не надо ля-ля. Это сильно зависит от конкретного типа и вида "типобезопасного"
>> языка.
> Это очень слабо зависит от "типа и вида", если не притягивать за
> уши JIT-компиляцию и не занижать планку требований к качеству оптимизаций.Ядро и юзерспейс на SML или Caml? Прикольненько! ;-) Я буду одним из первых, кто
покрутит такую поделку в руках, при условии, конечно, что она будет POSIX-compatible.Дайте мне тоже! ;-)
>> "И другие языки"? Гониво! Fortran ПРАВИЛЬНО конвертировать в С, и соблюсти при
>> этом
> Ну почему гонево. Допустим, фортран нельзя, но он уже в GCC и
> сфера применения у него узкая. Я имел ввиду прежде всего обероны
> и D2. Другие языки тут на их месте сложнее представить. Тем
> более фортран. :)Кодогенерация в язык С в подавляющем большинстве случаев является совершенно убогой и кривой технологией, о которой нужно писать в книжках как об эпохе древних вымерших мамонтов.
Если уж брать Oberon2 (допустим, решили, что берем), то нормальный, с местным компилятором, еще лучше прикрутить его к llvm или к pcc, там вроде тоже есть внутренний язык, через который собственно кодогенерация машинного кода и происходит, вместе с оптимизацией.Язык D? Я не в курсе, насколько он велик, и не уверен насчет его портабельности и кросс-собираемости. Именно эти три фактора были решающими при выборе Lua в NetBSD.
Рассматривались другие варианты типа scheme. Жирные Python, Perl, Tcl отмелись мнгновенно.
> Язык D? Я не в курсе, насколько он велик, и не уверен
> насчет его портабельности и кросс-собираемости. Именно эти три фактора были решающими
> при выборе Lua в NetBSD.Ну еще скорость конечно же. По сравнению с Lua жирные Python, Ruby, TCL, PHP и Perl даже рядом не валялись.
Да, рассматривался также Java Script. Тоже вполне неплохой выбор был бы.
> Я не могу сказать ничего про 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.
> Но дело даже не в этом, а в дезинформации, которой в
> OpenBSD кормят пользователей, и в ложных отговорках против чего угодно необычного.Эту мысль ты уже озвучивал, и я с ней полностью согласен.
"Деза" вредна даже не для пользователей, а для самой системы и ее разработчиков.
И насчет примера про переполнение целого в Жабе я с тобой тоже согласен.
Мягко говоря, некрасиво. В NetBSD (пардон :-) ) давно признают, что по поддержке
железа Линупс их давно обогнал. Поддержка современного железа тоже,
насколько мне известно, не всегда на высоте. Поддержку SheevaPlug, к примеру,
по-моему вот только-только сделали, было письмо в ports-arm@.
Но здесь я не уверен, я не по этим делам.
Вообще, я считаю, NetBSD имидж "Of course it runs NetBSD"(C) только вредит,
но это так, к слову.> Кстати, лгут и лицемерят многие, не только разработчики OpenBSD. Я об этом
> тоже стараюсь упоминать, если уж разговор заходит.Вот именно.
> Я не говорил обо всех BSD. Во FreeBSD практически не решаются проблемы
> безопасности, но в остальном другие BSD гораздо реже брезгуют чем-то новым,
> более полезным.patch? ;-)
> К слову, если /proc/<pid>/maps доступен для чтения не только root'у и владельцу
> процесса, то это источник информации для написания более надёжных эксплойтов.Согласен. Но ASLR в NetBSD нет как класса, поэтому проблема пока не актуальна.
По к. PIE тоже нет AFAIK.
Когда/Если появится, надо будет иметь ввиду.
Мне /proc/$$/maps был нужен для моего отладчика.>> То есть, я бы сказал, вполне адекватно они воспринимают окружающий мир.
> Проблемы безопасности недооцениваются почти повсеместно.
> У меня даже сложилось впечатление,
> что либо разработчики не соприкасались с этими проблемами на серьёзных объектах,
> либо не замечали следов и последствий проникновения...Ну, возможно процесс идет не так быстро, как некоторым хотелось бы,
но он как-то идет, и в этом направлении тоже.
Повторюсь, многие вещи объясняются сильно
ограниченными людскими ресурсами. Можно по этому поводу долго сокрушаться,
но факт остается фактом. Что касается аналогов pax и grsecurity,
я не могу сказать, есть ли что-то подобное в NetBSD или нет.
Скорее всего, нет.Я согласен, дополнительной степенью защиты от дырок в ядре
является более полная защита пользовательских процессов от самого ядра
специальными средствами. Ну что тут добавить?>> сколько денег (времени) понадобиться для того, чтобы
>> обучить каждого разработчика {Net,Open,Free}BSD
>> языку Erlang, D или Oberon2? Сколько времени понадобится на поддержку кода g++?
> На Erlang вместе с OTP - месяца 2, часа по 3-4 в
> день. На обероны примерно столько же. D относительно более сложный -
> допустим, на него уйдёт около полугода. Это в случае с Си
> нужно годами учиться нюансам и дисциплине, и толку не много будет.Ну, Оберон ладно. Банальная императивщина. Насчет Erlang-а я не согласен.
Функциональная парадигма -- не для всех, не говоря уже об ОБЪЕКТИВНЫХ
сложностях в реализации на соответствующих ЯП сложных нетривильных алгоритмов,
для которых имеются императивные описания, начиная с 50-60.
Для ФП их нужно переформулировать, т.е. переизобретать ЗАНОВО.
По этому вопросу люди пишут диссертации и толстенные книги. Оно надо?
В общем случае, выхлоп неочевиден. Кроме того ФЯП для типичных приложений
и не нужны.> И таки да, вопрос лицензии в OpenBSD - это всегда очень отдельный
> вопрос. ;)В NetBSD GPL тоже не любят, уверен, как и во FreeBSD, но в первую очередь
смотрят на качество, судя по тому, что я вижу. Прежде чем выбросить GNU groff
и заменить его нделана огромная работа. GNU grep
не смотря на все усилия многих BSD-шников пока идет по дефолту.
То есть пыхтят, стараются, но выбросят только тогда, когда сделают лучше.
Беспричинные регрессии в качестве не допускаются.
На GNU toolchain тоже скрипят зубами, но делать другой банально некому.> Во многих других системах он как-то менее выражен, чем в OpenBSD.
Возможно, OpenBSD меня, честно говоря, интересует постольку поскольку.
Я не люблю системы с ярковыраженным Фюрером во главе.
На мой взгляд BSD-унам нужен общий userspace.
Это высвободило бы значительную часть людских ресурсов.
То же касается всяких там Minix-ов, Syllable-ов.
Пилите свои ядра хоть до посинения, но зачем ls каждому свой???
И то же самое относится к пакетным системам.
Вот, Диллон (добрый фюрер) перешел на pkgsrc 5 лет назад.
Minix тоже совсем недавно. pkgsrc под QNX кто-то там пинает,
но не сильно успешно.>> Вот почему, скажем в Линупсе нет kqueue???
> Разговор принимает всё более неожиданные повороты. :) NIH-синдром всюду, это и так
> понятно.Ну а к чему тогда сокрушаться по этому поводу, выставляя именно
OpenBSD-шников? ;-) В этом плане все одинаково хороши.>> Параноики в AltLinux глаза двух Богов не побоялись, включили у себя в
>> libc функции strlcat/strlcpy. Честь им и хвала, хоть в этом, за
>> смелость.
> Будет честь и хвала, когда возьмутся за защиту ядра.Что-то мне подсказывает, что альтовцы здесь есть,
и, возможно, уже приняли к сведению ;-)
Ядер у них в комплекте точно больше одного.
Вполне прилично собираются модули для каждого в виде отдельного пакета.
То есть инфраструктура вроде есть и налажена.
В принципе, они известны своей паранойей.
При наличии желания пнуть их не проблема.
А самому сделать -- еще надежнее ;-)>> Ядро и юзерспейс на SML или Caml? Прикольненько! ;-) Я буду одним
> Тогда уж на обероне, но это всё мечты, мечты.Как бы там ни было, все это сейчас на уровне университетского проекта,
а еще точнее, набора голых идей.>> Кодогенерация в язык С в подавляющем большинстве случаев является совершенно убогой и
>> кривой технологией, о которой нужно писать в книжках как об эпохе
>> древних вымерших мамонтов.
> Так надо писать о Си и ему подобных вообще.С -- значительная и поучительная часть истории и сегодняшнего дня IT.
Его нельзя не изучать.>> Рассматривались другие варианты типа scheme. Жирные Python, Perl, Tcl отмелись мнгновенно.
> Если Scheme рассматривался всерьёз, снимаю шляпу перед разработчиками NetBSD.Мне трудно судить о глубине знаний функциональной парадигмы
всех разработчиков NetBSD. Но предложение такое было.
На мой взгляд scheme лучше clisp, но ничего ТАКОГО он
из себя не представляет. Для типичных несложных задач Lua и JavaScript лучше.
По уровню "легковесности", повторюсь, очень важный фактор, Scheme
вполне им неплохой конкурент. Для встраивания тоже подходит хорошо.
>> Я не говорил обо всех 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?> Это не прогресс,
> это недоразумение. Вместо реальных мер защиты ядра налегают на 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, ох и наговорили
они прелестей господину-товарищу-барину Пайку :-)
>> куцая поддержка 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Я обратил внимание на эрланг, поскольку он обладает уникальной совокупностью качеств, наиболее актуальных в программировании сетевых приложений. А красивости везде есть, даже в Си.
>> Я думаю так. Если бардак прекратить нельзя, нужно его возглавить.
> Мне хватает CentOS и Hardened Gentoo. Зачем поощрять лицемерие, выбирая FreeBSD? Я
> считаю, незачем. К тому же, у FreeBSD есть другие существенные недостатки,
> из-за которых от неё нам и пришлось отказаться.Были приведены примеры лицемерия в OpenBSD, но я что-то не припомню ничего подобного
про FreeBSD. В этом году я был на KievBSD, был там товарищ Белоусов, кажется,
FreeBSD core team member. Много говорил о проблемах проекта. Но среди прочего сказал
примерно следующее (не дословно), у нас тут не лавочка по исполнению желаний,
вам нужно -- вы приходите и делайте.
Патч, даже готовый, нужно продвигать, мало ли где чего валяется.
Мои и не только патчи на awk из NetBSD
Brian Kernighan тоже завернул года два назад
по, ээээ, как бы это помягче выразиться, чтоб не обидеть светилу,
очень странным причинам. Надо делать вторую попытку, может он чего недопонял,
и такое бывает, может, не в духе был, уволили его из belllabs,
может мой английский плоховат,
или поклон был недостаточно низок. Такой вот он апстрим, капризный местами.
Арнольд Роббинс вот отличный апстрим, очень, очень адекватен в плане принятия багов.
Тут как повезет.> О том, чтобы что-то "возглавить", можно говорить только при наличии заинтересованности
> основных разработчиков. Её нет.Если интерес настолько велик, что задело АЖ ВОТ ТАК, надо становится разработчиком
самому, а не кивать на них плохих. Можно даже стать тамошним экспертом по безопасности.
Не? Ну тогда плюнуть на них на всех свысока
и молча использовать то, где уже все готово, CentOS или Hardened Gentoo -- всё равно.>> http://www.zbh.uni-hamburg.de/pubs/pdf/GieKur1995a.pdf
>> Буквально первых два предложения из Conclusion.
> Прочитал. Не вижу повода для печали, скорее для радости. В чём мораль-то?Моя работа непосредственно связана с разработкой алгоритмов, сложных.
За ресерч в этом направлении, т.е. за переливание из императивного стакана
в функциональный в рабочее время, меня просто уволят. Это непродуктивно.
Не надо повторять про обилие библиотек для ерланга. Я понял с первого раза.
Да, "их есть", некоторое количество. Но я даже не гляда точно знаю, что того,
что нужно мне там нет. Этого нет во всем опенсорсе, а то, что есть мнээээ :-/>> Основные плюшки и фишки Erlang-а я знаю, хотя в детали не влезал
>> и в подробностях не изучал.
> Напомнило: "Набокова не читал, но осуждаю".По поводу Erlanga и его применимости в СЕТЕВЫХ приложениях я по-моему выразился на русском языке и вполне конкретно. Да, здесь он на своем месте, и я не вижу причин,
почему его нельзя использовать при реализации некоторых проектов и списка тех, что
ведут в OpenBSD.> в той же OpenBSD долго и упорно пилят
> на Си.- А давайте отрубим удаву голову!
- Нет, давайте лучше хвост.
- Во-во! По самую голову!> c2k? Может быть c10k?
Да. Ошибся.
> После такого отказа ознакомиться с коротенькой презентацией абсолютно по теме,
Отказа? Где? Url? ;-) Меня не нужно убеждать в том, что Ерланг может то и это.
Я почитаю внимательнее, и найду, что мне будет интересно, и я об этом сказал между прочим тоже по-русски. И я не разработчик OpenBSD или FreeBSD, я мимо проходил.> Эрланг это возможная альтернатива для товарищей из OpenBSD, а они пишут вполне
> конкретные клиент-серверные приложения на Си.Мы говорим об одном и том же. В этом конкретном месте не вижу предмета для спора.
> "Типичные приложения" и "общие случаи" -
> из другой оперы, и не я о них заговорил.Их имел ввиду как раз я. Или мы будем совать Ерланг во все дырки, не глядя на то, подходит он или не подходит? Мне вот приложение на ncurses склепать нужно, к примеру,
для управлением пакетами в системе. Ерланг? Да за каким хреном у там нужен?> С окружением не повезло. ФП как таковое здесь ни при чём.
Типичный лиспофил кроме того даже не видит границы между чистой функциональной парадигмой и всего лишь динамичностью языка Лисп. Эти люди регулярно выдают первое за второе, а второе за первое, банально не понимая разницы. С окружением не повезло? Да это не мое окружение. Это интернет.
> Были приведены примеры лицемерия в 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, я мимо проходил."Да я уже начитался, спасибо" против "Я почитаю внимательнее" - это без комментариев.
> Мы говорим об одном и том же. В этом конкретном месте не вижу предмета для спора.
Я тоже не вижу. И вижу одновременно. Вернее, по мере чтения твоих комментариев: вижу, не вижу, вижу, не вижу... Потому что высказываешься очень противоречиво.
> Типичный лиспофил кроме того даже не видит границы между чистой функциональной парадигмой
> и всего лишь динамичностью языка Лисп. Эти люди регулярно выдают первое
> за второе, а второе за первое, банально не понимая разницы. С
> окружением не повезло? Да это не мое окружение. Это интернет.А я вот почему-то сплошь и рядом слышу мнения приверженцев статически типизированных ФЯ. Наверное, у меня другой интернет.
>>> в той же OpenBSD долго и упорно пилят на Си.
>> - А давайте отрубим удаву голову!
>> - Нет, давайте лучше хвост.
>> - Во-во! По самую голову!
> И тут уместно задать вопрос: в чём мораль этой басни, и что
> же там на счёт признания применимости эрланга, в конце-то концов? :)В общем, я думаю, стороны высказались. И по делу и не по делу.
Каждый в меру способностей услышал то, что хотел услышать.
Я, пожалуй, пойду погремушками займусь.hint: оставленое напоследок оставлено не зря.
> для освоения эрланга под прикладные задачи(просыпаясь)
Оно им надо?
(и вообще -- интересно, какая доля эрлангистов страны у нас работает...)
Опять же -- кроме прикладных бывают и системные, надо ж на чём-то beam'ы подымать.
(засыпая)PS 2 vle: насчёт c10k и масштабируемости конкретно эрланга можешь спрашивать, у нас на ём кластерный мониторинг построен калибра "на петафлопсник".
> О существовании других типобезопасных языков, в т.ч. совместимых с Си (D, D2,
> Cyclone + трансляторы в Си с других языков), почему-то умалчивается. Где
> же конструктивная самокритика и умение признать недостатки сделанного выбора? "Да, есть
> хорошие типобезопасные языки, но проект OpenBSD их не использует по ряду
> причин нетехнического характера" - вот, что я бы хотел услышать от
> них вместо этой казуистики. Хотя бы раз!JFYI. Совсем недавно в базовую систему NetBSD внесли Lua, хороший
мощный и безопасный язык.
Есть люди, которые продвигают его в даже ядро(!!!) для каких-то там задач.
Не знаю, как у них получится с ядром, это пока только незаконченный проект, но,
надеюсь, в NetBSD станут больше писать на Lua и меньше на С.
> Ну и как вы это себе представляете? Подписывание означает шифрование. То есть
> надо тогда два комплекта установочных файлов распространять, получается, подписанные
> и неподписанные? А какой из этих комплектов записывать на оригинальные диски
> с релизом?..ваапщета -- вполне достаточно файлика формата
имя_файла размер md5hash sha1hash
имя_файла размер md5hash sha1hash
имя_файла размер md5hash sha1hash
....и его подписать -- всего один файл и никакого шифрования
> рекомендации ставить систему, сверяя целостность файлов с нескольких зеркалА вы не согласны?
Не согласен. Эта задача несравнимо надёжнее решается с помощью ЭЦП.
glob(3) не патченный, что вообщемто понятно - не успели, а вот чистая errata при этом как-то не комильфо...
> glob(3) не патченный, что вообщемто понятно - не успели, а вот чистая
> errata при этом как-то не комильфо...Проблему с glob(3) не сочли проблемой безопасности...
> Проблему с glob(3) не сочли проблемой безопасности...На RELIABILITY FIX тоже не тянет?
>> Проблему с glob(3) не сочли проблемой безопасности...
> На RELIABILITY FIX тоже не тянет?Угу. Иначе бы давно в errata для 4.6 и 4.7 появилось. Честно говоря, сам не понимаю логику. Насколько я понимаю, дело в том, что для успешной эксплуатации требуется пройти аутентификацию на системе (анонимный вход — тоже аутентификация, со всеми вытекающими рисками), а аутентифицированный пользователь может устроить DoS и с «лимитированным» glob(3). Но это лишь моё предположение. vsftpd рулит. :)