Представлен (https://lists.freebsd.org/pipermail/freebsd-stable/2018-Dece...) третий кандидат в релизы FreeBSD 12.0. Выпуск FreeBSD 12.0-RC3 доступен для архитектур amd64, i386, powerpc, powerpc64, powerpcspe, sparc64 и armv6, armv7 и aarch64. Дополнительно подготовлены образы для систем виртуализации (QCOW2, VHD, VMDK, raw) и облачных окружений Amazon EC2.
По сравнению с прошлым тестовым выпуском в состав включен модуль ядра if_ixlv.ko, который для обеспечения обратной совместимости ссылается на модуль if_iavf.ko. В остальном отмечается только исправление ошибок и устранение утечек памяти. Ожидается, что FreeBSD 12.0-RC3 станет последним тестовым выпуском и если не будет выявлено значительных проблем 7 декабря начнётся процесс сборки финального релиза. Релиз FreeBSD 12.0 запланирован на 11 декабря.
Дополнительно можно отметить устранение опасных уязвимостей (https://lists.freebsd.org/pipermail/freebsd-announce/2018-No...) (CVE-2018-17157, CVE-2018-17158, CVE-2018-17159) в реализации сервера NFS. Выявленные проблемы потенциально позволяют выполнить код с правами ядра через отправку специально оформленного пакета на сетевой порт 2049. Пользователям NFS рекомендуется срочно установить обновление или ограничить доступ к порту 2049. Проблема затрагивает все поддерживаемые ветки FreeBSD.
Кроме того, в форме Errata-уведомлений раскрыты данные о ещё двух уязвимостях:
- Возможность (https://lists.freebsd.org/pipermail/freebsd-announce/2018-No...) обойти реализуемую в загрузчике парольную защиту входа. Уязвимость позволяет несмотря на установку пароля полностью контролировать процесс загрузки (при выборе режима отложенной загрузки загрузчик не находит ядро и выводит приглашение командной строки, через которое пользователь может загрузить систему без проверки загрузочного пароля);
- Уязвимость (https://lists.freebsd.org/pipermail/freebsd-announce/2018-No...) (CVE-2018-17156) в сетевом стеке, приводящая к переполнению буфера по нижней границе при обработке пакетов ICMP. Уязвимость позволяет инициировать крах ядра через отправку специального оформленного ICMP-пакета (Ping of Death). Проблема вызвана ошибкой в коде функции icmp_error(), определённой в файле sys/netinet/ip_icmp.c. Проблема затрагивает только 64-разрядные сборки FreeBSD, в которых изменено значение параметра sysctl net.inet.icmp.quotelen.URL: https://lists.freebsd.org/pipermail/freebsd-stable/2018-Dece...
Новость: https://www.opennet.ru/opennews/art.shtml?num=49691
они там по поводу релизов договорились?))
референдум будет по этому поводу
4-я Фря имела в своё время 11 крупных обновлений («сервис-паков»), 10-я — всего лишь 4, 11-я — только 2. Как бы тенденция налицо. Не вижу поводов для оптимизма.
Ну... Посмотрите на браузеры, докеры, js'ные всякие приблуды. А сколько ядро 2.6 тянулось? Тенденция, конечно, сомнительная, но просто современная.
>А сколько ядро 2.6 тянулось?Шёл 2.6.2006 год, люди рождалиь, взрослели заводили детей, выходили на пенсию, рассказывая внукам о своей молодости и минорных релизах.
4я фря имела 11 релизов потому что 5я была в разработке слишком долго, релиз ее (5й) делали из current, а не stable (фактически код был нестабилен) и чтобы не дропнуть пользователей, 5ю и 4ю ветки поддерживали параллельно. Так что 11 релизов в 4й скорее очень сильное исключение из правил
> Так что 11 релизов в 4й скорее очень
> сильное исключение из правилИсключение это или нет, но отношение к людям было правильное. А все эти коды кондухтора и прочие роллинг-релизы — это, извините, не про стабильный продукт. Надо ли ещё такого продукта будет нам в будушем? Вот и посмотрим.
Это прям нуочень мотивировало 3rd party studios писать для Linux, но, главное, их очень сильно мотивировал делать это Габен и Ко, они в очередь выстроились к нему с мольбами принять их творения в стим, ага (сарказм, на самом деле нет). Так мотивировал, аж в напилил из опенсорц-компонентов (Wine, OpenAL, SDL2 ) нечто под названием Phonon в последствии, наверное от хорошей жизни и большого желания разработчиков писать свой код для SteamOS это сделал
Copy-paste FAIL? :)
Скорее не на ту ссылку в профиле жмакнул
Мне эти слова мало о чём говорят, ибо не интересуюсь детскими игрушками, а для правильной мультимедии у меня есть оффтопик и мак.
Сори, промахнулся ответом в профиле
>> Так что 11 релизов в 4й скорее очень
>> сильное исключение из правил
> Исключение это или нет, но отношение к людям было правильное. А все
> эти коды кондухтора и прочие роллинг-релизы — это, извините, не про стабильный
> продукт. Надо ли ещё такого продукта будет нам в будушем? Вот
> и посмотрим.Да вроде и никто пока не предлагает роллинг-релизы (кроме совсем уж поехавших TrueOS, да и тех, похоже, отпустило, после того того как пользователи бузить начали). Вроде бы с тех пор процесс разработки особо не претерпел изменений. Остальное - will see, will see
Единственно правильные релизы в мире СПО у Шапки: ядро и все его известные особенности «замораживаются» на весь срок жизни поколения ОС, новые функции избирательно бэкпортируются, плюс обновления безопасность.Я не думаю, что надо это объяснять в подробностях, ибо кто знает, те и так знают, а кто не в курсе, тем и не надо. Если конкретная ОС используется как основа для работы собственного ПО (заказного, кастомизированного, ещё какого-нибудь не с открытого рынка), то неизменность программной и аппаратной среды становятся критически важными свойствами всей информационной системы. Поэтому так мучительно больно бывает от упразднения по EOL твоей системной основы — будь то DOS, OS/2, Windows старых версий или что угодно. Есть много таких мест и обстоятельств, где нельзя заменить компьютер и программу, которую он выполняет. Например, потому что нельзя остановить производственный цикл.
Если у ОС срок жизни год, то я даже смотреть не буду в её сторону. В мире чистогана за отдельные деньги можно заказать отдельный сервис даже с латанием обнаруженных прорех безопасности для ПО, которое для остальных уже EOL. А в мире СПО так можно? Вот в этом-то и проблема. Они даже известные баги не закрывают, потому что, дескать, морально устарело, берите новую версию. А если мне нужна не новая версия, а некая конкретная «старая»? Компилятор, допустим, у меня требует конкретного программного окружения, а новые компиляторы мне не подходят, потому что их оптимизации вредят, скажем, стабильности и отказоустойчивости моего ПО (которое, таки нет, нельзя переписать на модном пихтоне или заказать на стороне написать ещё раз, потому что оно, например, военного назначения или в нём захардкодили коммерческие тайны моего бизнеса).
Между ежегодным обновление базовой системы и роллинг-релизом нет никакой сущностной разницы. Потому, например, OpenBSD в продакшыне видеть не очень торопятся. Хотя система ведь хорошая. И обновляется легко. Только всё программное окружение дважды в год меняется — подумаешь, какая мелочь…
>[оверквотинг удален]
> не новая версия, а некая конкретная «старая»? Компилятор, допустим, у меня
> требует конкретного программного окружения, а новые компиляторы мне не подходят, потому
> что их оптимизации вредят, скажем, стабильности и отказоустойчивости моего ПО (которое,
> таки нет, нельзя переписать на модном пихтоне или заказать на стороне
> написать ещё раз, потому что оно, например, военного назначения или в
> нём захардкодили коммерческие тайны моего бизнеса).
> Между ежегодным обновление базовой системы и роллинг-релизом нет никакой сущностной разницы.
> Потому, например, OpenBSD в продакшыне видеть не очень торопятся. Хотя система
> ведь хорошая. И обновляется легко. Только всё программное окружение дважды в
> год меняется — подумаешь, какая мелочь…Ток по сути ежегодное обновление базовой системы это не мажорное, а минорное обновление (по сути багфикс-релиз, и не говорите что в красношапке ядро 2.6.x никогда не обновлялось, а бэкпортирование фичей в старую версию из новой - вот совсем не изменение кода и никак не вносит своих корректив. Ага-да.
> Компилятор, допустим, у меня требует конкретного программного окружения, а новые компиляторы мне не подходят
Берете тот компилятор, который вам нужен.
/usr/ports/lang # ls |grep gcc
gcc
gcc-ecj45
gcc48
gcc49
gcc5
gcc6
gcc6-aux
gcc7
gcc7-devel
gcc8
gcc8-devel
gcc9-devel# ls -la |grep llvm
drwxr-xr-x 3 root wheel 8 18 нояб. 09:12 llvm-cheri
drwxr-xr-x 3 root wheel 9 18 нояб. 09:12 llvm-devel
drwxr-xr-x 3 root wheel 7 18 нояб. 09:12 llvm35
drwxr-xr-x 3 root wheel 7 18 нояб. 09:12 llvm38
drwxr-xr-x 3 root wheel 7 2 дек. 08:39 llvm40
drwxr-xr-x 3 root wheel 7 18 нояб. 09:12 llvm50
drwxr-xr-x 3 root wheel 7 25 нояб. 09:06 llvm60
drwxr-xr-x 3 root wheel 7 29 нояб. 04:11 llvm70
drwxr-xr-x 2 root wheel 5 18 нояб. 09:12 py-llvmcpy
drwxr-xr-x 3 root wheel 6 21 нояб. 10:57 py-llvmlite
drwxr-xr-x 3 root wheel 5 18 нояб. 09:12 xtoolchain-llvm-devel
drwxr-xr-x 2 root wheel 3 18 нояб. 09:12 xtoolchain-llvm40
drwxr-xr-x 2 root wheel 3 18 нояб. 09:12 xtoolchain-llvm50
drwxr-xr-x 2 root wheel 3 18 нояб. 09:12 xtoolchain-llvm60
drwxr-xr-x 2 root wheel 3 18 нояб. 09:12 xtoolchain-llvm70кроме того компиляторы обратносовместимы в большинстве своем друг с другом, а флаги оптимизации можете задать те, которые нравятся лично вам.
Собсно говоря, внутри одного ABI оно все - один релиз. А внутри одного релиза все окружение совершенно инвариантно относительно юзерленда. Ну, можно, конечно, пересобрать софт с обновленными либами, но если этого не сделать - ничего не поломается. Вдобавок, пипл не заметил, как из нумерации убрали патч-левелы. Так что, нумерация вполне логична. А что она не совпадает с привычной для линуксистов... Ну, никто и не обещал, что можно будет натянуть пингвина на любой произвольно взятый глобус.
> Ток по сути ежегодное обновление базовой системы это не мажорное, а минорное
> обновление (по сути багфикс-релиз, и не говорите что в красношапке ядро
> 2.6.x никогда не обновлялось, а бэкпортирование фичей в старую версию из
> новой - вот совсем не изменение кода и никак не вносит
> своих корректив. Ага-да.Такого я и не говорил. Не понимаю, как можно превратно понять написанное мною. У Шапки всегда своё кастомизированное ядро, которое она ведёт на протяжении многих лет для каждого конкретного выпуска RHEL. При обновлениях в пределах основной версии ОС, естественно, ядро тоже заменяется, но это ядро той же основной версии, что отражено и в нумерации пакетов. То есть обладатели систем на данном выпуске RHEL могут быть почти уверены, что обновление ничего не сломает.
А вот отслеживанием изменений между релизами OpenBSD, NetBSD или FreeBSD, придётся самостоятельно, исправлять баги в старом нужном софте, как ни странно, в ряде случаев — тоже. Вендор с обязательствами в данном случае отсутствует как таковой, следовательно не будет заниматься сохранением неизменности и полноты ОС.
Потому-то для ответственных применений мы выбираем не СПО вообще, а СПО, за которым стоит поставщик — Red Hat, IBM, Oracle, Novell/SUSE/_кто-там-нынче_ и так далее. Или сразу коммерческое ПО.
Думается даже, что если сегодня зайти к Шапке с запросом на допиливание под некие специальные потребности уже снятых с обслуживания RHEL 4, 3 или даже 2.1 за соответствующую случаю плату, там не откажут. А идти к ребятам из сообществ как бы некоммерческих ОС заведомо нет никакого смысла, тупо пустая затея.
>> Компилятор, допустим, у меня требует конкретного программного окружения, а новые компиляторы мне не подходят
> Берете тот компилятор, который вам нужен.
> кроме того компиляторы обратносовместимы в большинстве своем друг с другом, а флаги
> оптимизации можете задать те, которые нравятся лично вам.Ну, конечно, это замечательно, и я рад, что вы так хорошо знаете предмет, но я имел в виду кое-что другое. ИТ, вопреки странной вере многих айтишников, не является важнейшей или определяющей подсистемой бизнеса или производства, но только служебной, вроде электричества в проводах или воды в канализации — вот о чём требуется помнить. Ради новых функций новых программ, сколь бы сказочны они ни были, никто в здравом уме не будет сносить завод и строить новый. ИТ для таких объектов, как правило, проектируется (если вообще проектируется в понятиях ИТ, ибо кроме цифровых компьютеров есть и аналоговые) один раз и на многие годы (на весь срок жизни предприятия, в идеале).
>А идти к ребятам из сообществ как бы некоммерческих ОС заведомо нет никакого смысла, тупо пустая затея.Запросто. Если ты готов оплатить фуллтайм для 3-4-5 тел по ставкам страны проживания, они тебе какой угодно окаменелый кал будут пилить. А на халяву - жри что дают. Такая вот она, ля ви, хе-хе.
Ну как бы обычно никто не открывает NFS наружу. Остаются лишь негодяи внутри локальной сети :)
И на пинги еще не отвечать. А лучше вообще сеть выключить. Будет очень в тему к удалению дров сетевок. Можно поудалять нахрен вообще все драйверы - во хакеры обломаются.
>Проблема затрагивает только 64-разрядные сборки FreeBSD, в которых изменено значение параметра sysctl net.inet.icmp.quotelenНу разогнался прям, на пинги не отвечать. Ты менял? Я вот сумлеваюсь что ты вообще пользователь ФриБСД.
> Можно поудалять нахрен вообще все драйверы - во хакеры обломаются.Да-да, ISA дровины - это тааак актуально!
Кстати, что скажет Знаток на
> Проведена одна из крупнейших чисток кодовой базы от устаревшего кода (удалено 467 тысяч строк кода), в ходе которой удалена поддержка архитектур blackfin, cris, frv, m32r, metag, mn10300, score и tile, а также специфичные для данных архитектур драйверы.?
> И на пинги еще не отвечать. А лучше вообще сеть выключить. Будет
> очень в тему к удалению дров сетевок. Можно поудалять нахрен вообще
> все драйверы - во хакеры обломаются.В смысле, как вот тут:
https://www.opennet.ru/opennews/art.shtml?num=46503
> 05.05.2017 10:54 Уязвимость в реализации NFS-сервера, поставляемой в ядре Linux
> В сервере NFS (NFSv2 и NFSv3), входящем в состав ядра Linux, выявлена удалённо эксплуатируемая уязвимость (CVE-2017-7895), позволяющая прочитать содержимое произвольных областей памяти ядра и пространства
> пользователя (от 1 до 4 Мб) через отправку специально оформленных запросов к NFS.?
Лол. И эти люди прикалывались над другими за ping of death. Двойной фэйспалм.
>Лол. И эти люди прикалывались над другими за ping of death. Двойной фэйспалм.Ну так и выловили в rc3, какие проблемы?
выловили за 10 дней до релиза. олажались , так облажались))) потеря лица на лицо))) хахах
Ау, знатоки фрюхи.
По уязвимостям (11.2):
Мир пересобирать, или достаочно ядра?
я не знаток фрюхи, но подсказываю: если ты эксплуатируешь ее не для нетаковости-как-все, а по делу - надо не на опеннете задавать эти вопросы, а давным-давно подписаться на рассылку - хотя бы security.в каждом релизе там черным по белому пишут, что именно нужно сделать для исправления проблемы, и можно ли это сделать вообще.
в данном случае - достаточно пересобрать только ядро (и это было там написано, правда, как обычно, в самом-самом конце списка фееричных в своей бесполезности советов обновиться до последней версии автомагическими автотулзами)
Спасибо!
Я не "нетаковости-как-все" - впн-днс-почтовик.
Если не сложно - тыкни где подписываться на рассылку.
Фрю очень давно кручу, но как-то не видел необходимости...
Поставь домашней страницу в браузере эту: https://svnweb.freebsd.org/base/stable/11/?sortby=date
Для релиза эту: https://svnweb.freebsd.org/base/releng/11.2/?sortby=date
https://lists.freebsd.org/mailman/listinfo/freebsd-security
(там еще есть -notifications )необходимости нет, если binary upgrade по крону гонять, а за портами следить хотя бы по ежевечерним отчетам ports security.
Но автообновляющаяся винда у меня уже есть, ее вполне хватит. Во фре я хочу, обычно, знать, что и как обновилось, этакая видимость контроля над ситуацией...
Посмотри по изменениям, svn up и пыришь что за файло новое качается. Была пара апдейтов, в которых было достаточно вообще пару библиотек пересобрать, ну и ядро чтобы бампнуть патчсет версию. Можно подумать знатоки фрюхи сидят и заучивают на изусть чейнджлоги, делать больше нечего
да, собственно, после новости и запустил, и файло посмотрел. Видел, что файло нфс подтянулось.. Но не знаю, по каким критериям определять - что пересобирать.
Не программист, так, чуть-чуть..
Ну если NFS, то и то, и другое (он ведь и ядро, и юзерспейс)
На сабже что в bhyve, что в virtualbox винда после пары-тройки перезагрузок просто вешается. И ничем её не починить. Если бы не это, держал бы FreeBSD на десктопе. Винда нужна только для связки криптопро+континент ап.
А что, в вайне это гэ не работает?p.s. а когда кто-нибудь будет рассказывать как офуенно в бзде с виртуализацией - пусть вот это прокоментит сначала, чтоли.
> p.s. а когда кто-нибудь будет рассказывать как офуенно в бзде с виртуализацией - пусть вот это прокоментит сначала, чтоли.А что именно нужно комментировать? Недовольное курлыканье криворукого анонима постом выше?
Тестил десятку под bhyve еще в конце 2016. В игрушки поиграть с наскоку не получилось, в фотошопах/дельфях/офисах разницы с железом не увидел. Через три перезагружки наглухо не вешалось, нет. Прокомментируйте вот это. Можно сначала, можно потом. Что ли.
и, кстати, нахрена вот он ее без конца перезагружает? У меня сервера перезагружаются раз в неделю, во время тихое, потому что обновления этого хотят - и то половина этих перезагрузок отменяется по соображениям "не настолько важное обновление, чтоб лишний раз дергаться".
(с линуховыми, что характерно, такая же точно фигня)
Захотел обновить 11-STABLE на 12-STABLE на удалённой машине. Подключил каталоги /usr/src и /usr/obj, как это я обычно делаю, и начал устанавливать:
cd /usr/src/ && make installworld
И тут ошибка: "Тулчейн ваш находится на другой машине в кэшированном виде и недоступен. Установка невозможна." Кто сталкивался с этим? Как решить проблему?
(Компиляция системы на удалённой машине слишком длительная - процессор слабоват)
> Как решить проблему?примонтируй корень дохломашины к билдхосту, и make install DESTDIR=гдеонотам, а не наоборот. И у mergmaster аналогичный параметр есть.
Это точно никогда не поломают.
Проблема решена. Походу вскрылась другая нестыковка.
Давно это было, ещё под 4-кой. mount_nfs в rw режиме.