> Это обычная практика с метапакетами. Тот же xorg-minimal или gnome/gnome-light.

Я не любитель линуксовых пакетов в целом. Метапакеты мне кажутся ущербной концепцией. Проблема gmome-light/gnome-max гораздо изящнее решается при помощи FLAVORS, как в портах FreeBSD и OpenBSD.

> Объединить много маленьких в большие с помошью метапакетов намного проще, чем выдрать из большого пакета куски софта.

Имхо, это вообще не правильное направление движения. Лепить из потенциально по-разному собранных частей одной программы/набора программ своего франкенштейна - зачем?
Не проще ли обеспечить возможность собраться и так и эдак и иметь возможность взаимозаменяемо использовать их в системе?

> Нет, в pkgbase этого нет, но скорее потому что им, судя по активности в списке рассылок, так почти никто и не пользуется.

Ну это так или иначе ещё "не продакшен". И, надеюсь, никогда им не станет.

>[оверквотинг удален]
>     8,0 MiB [      
>     ] /lib
>     8,0 MiB [      
>     ] /lib
>     7,8 MiB [      
>     ] /rescue
>     5,2 MiB [      
>     ] /sbin
> Total disk usage: 315,5 MiB
>

Ничего не понял, особенно про 400Gb. Какие 400Gb?

> Может и вру про 2GB, но близко - в основном урезан компилятор, вынесено всякое разное вида zfsтулз, mlxtools, bluetooth, профайл и дебагсимволы и оно этими 315МiB размером в пожатый релизный образ FreeBSD-12.0-RELEASE-arm-armv7-RPI2.img.xz

https://download.freebsd.org/ftp/releases/amd64/amd64/12.0-R... - 147 метров, какие 2Gb? На диске побольше будет, да, метров 200-300.

> Ну и при создании виртуалок/джейлов хочется иметь как можно меньшую исходную базу.

Так TrueOSный подход никак этому не препятствует. Собирай свой freebsd-base и деплой куда тебе нужно.

> Либо оно не используется, но им может воспользоваться нападающий. Тоже классика жанра.

Нападающий воспользуется дырой в не запущенном демоне? Не рассажешь, как например?

> Вообще-то это  делается в первую очередь для отсева деятелей "50 ответов спустя: а да, забыл сказать, что я прописал еще тучу опций в make.conf и собрал часть c помошью дев-версии кланга, а другую с GCC".

Это не противоречит тому, что написал я.

> Возможность поставить нужную конфигурацию из кирпичиков оф. сборки, без заимения всех этих "_твоих проблем_" на ровном месте - это как раз в плюс.

Ты эти "кирпичики" будешь всё равно собирать все вместе единовременно, во время сборки базы. Хочешь "кирпичики" из N разных баз - будешь собирать N разных баз. И не факт, что результат будет работоспособный. Какой в этом смысл, если можно просто запаковать всё в одну тарбомбу и таскать её куда нужно?

> Скажите, зачем на одноплатнике или в базе джейла держать с гигабайт дебагсимволов?

Не держите. Собирайте свой freebsd-base без дебагсимволов и вперёд.

> Или этот мерзкий и бибикающий vi?

Еретик.

> И вообще, вы так говорите, как будто для этого нужно перепахать пол-базы.

Это уже есть и можно собрать пакетированную базу. Я попробовал и больше не хочу.

>> Объединить много маленьких в большие с помошью метапакетов намного проще, чем выдрать из большого пакета куски софта.
> Имхо, это вообще не правильное направление движения. Лепить из потенциально по-разному
> собранных частей одной программы/набора программ своего франкенштейна - зачем?
> Не проще ли обеспечить возможность собраться и так и эдак и иметь
> возможность взаимозаменяемо использовать их в системе?

Почему "по-разному собранных частей"? Смысл в том, что тогда есть оф. и одним куском, так как задуманно разработчиками, собранная база. Но благодаря опакечиванию можно не устанавливать пакет с компилятором или пакеты с дебагсимволами.
Для упрощения поисков багов можно сделать какой-нибудь официальный "так должна выглядеть система по нашему представлению", т.е. перед багрепортом ставишь все то, что по мнению разработчиков должно быть в системе.
А не идешь заменять свою кастомную установку полностью.

> Ничего не понял, особенно про 400Gb. Какие 400Gb?

Там MB были! Видимо, шутник модератор тайно подменил ))

>> Может и вру про 2GB, но близко - в основном урезан компилятор, вынесено всякое разное вида zfsтулз, mlxtools, bluetooth, профайл и дебагсимволы и оно этими 315МiB размером в пожатый релизный образ FreeBSD-12.0-RELEASE-arm-armv7-RPI2.img.xz
> https://download.freebsd.org/ftp/releases/amd64/amd64/12.0-R... -
> 147 метров, какие 2Gb? На диске побольше будет, да, метров 200-300.

Нет, речь конкретно вот об этом:
https://download.freebsd.org/ftp/releases/arm/armv7/ISO-IMAG.../
FreeBSD-12.0-RELEASE-arm-armv7-RPI2.img.xz     307371508
Т.е. пожатый исошник весит 307 MB и распаковывается в 2 или 4 GB.
А приведенная в качестве примера кастомная сборка, с компилятором в базе - после установки всего 315МБ.

Ну и лукавите вы немного с размером в вашем примере:
> 147 метров, какие 2Gb? На диске побольше будет, да, метров 200-300.

xz -l base.txz
Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
    1      33    147,2 MiB    772,5 MiB  0,191  CRC64   base.txz
А на диске под все 800 будут.

>> Либо оно не используется, но им может воспользоваться нападающий. Тоже классика жанра.
> Нападающий воспользуется дырой в не запущенном демоне? Не рассажешь, как например?

Принципиальные примеры:
https://gist.github.com/hugsy/5933831 - даже если вы не пользуетесь ping, SUID у него никто не отбирал. Т.е. получаем классическое "privilege escalation" из nobody в рута.

Или как сдесь:
https://www.opennet.me/opennews/art.shtml?num=47792
>  выявлена серия уязвимостей, которые могут быть использованы локальным атакующим для запуска кода с правами ядра через загрузку специально оформленного eBPF-приложения.

Про уязвимости в старых драйверах думаю можно не упоминать, а их в GENERIC тоже много загружается.

>> Вообще-то это  делается в первую очередь для отсева деятелей "50 ответов спустя: а да, забыл сказать, что я прописал еще тучу опций в make.conf и собрал часть c помошью дев-версии кланга, а другую с GCC".
> Это не противоречит тому, что написал я.

Не противоречит, но акценты расставлены по разному. Грубо говоря, убирание той же zfs-обвязки при неиспользовании zfs и сборка с "-O3" или новейшим компилятором - на мой взгляд две большие разницы.
И если для второго я в принципе согласен с разработчиками "сначала попробуйте собрать нормально", то вот для первого пересборка всего и вся все же перебор.

>> Возможность поставить нужную конфигурацию из кирпичиков оф. сборки, без заимения всех этих "_твоих проблем_" на ровном месте - это как раз в плюс.
> Ты эти "кирпичики" будешь всё равно собирать все вместе единовременно, во время  сборки базы. Хочешь "кирпичики" из N разных баз - будешь собирать
> N разных баз. И не факт, что результат будет работоспособный.

Не-не-не. Зачем кирпичики из N баз?
Речь о кирпичиках в виде готовых пакетов из той самой, одной официальной фряшной базы, собранные так, как представлялось правильным разработчикам.

Просто не таскать всегда и повсюду все "кирпичики" (см. дебагсимволы) а только нужную часть.

Что любители экзотики пусть собирают и поддерживают свои хотелки сами, я даже не спорю. Но вот объявлять любой "шаг влево-вправо" (например отсутствие в базе vi или mlxtools или дебагсимволов) экзотикой, как это по факту делается сейчас - это по-моему тоже крайность.

> Почему "по-разному собранных частей"? Смысл в том, что тогда есть оф. и одним куском, так как задуманно разработчиками, собранная база. Но благодаря опакечиванию можно не устанавливать пакет с компилятором или пакеты с дебагсимволами.

Для этого нужно не просто побить базу на пакеты. Ещё нужно тестировать работоспособность системы в "кастрированных" конфигурациях и правильно прописать зависимости. Чтобы при удалении чего-то не нужного на твой взгляд у тебя не переставало работать что-то, от этого зависящее. И наоборот: чтобы при установке чего-то нужного доезжало всё необходимое.
А это не так просто, как может показаться. В линуксе это работает из-за другой модели разработки.

> Нет, речь конкретно вот об этом:
> https://download.freebsd.org/ftp/releases/arm/armv7/ISO-IMAG.../
> FreeBSD-12.0-RELEASE-arm-armv7-RPI2.img.xz  307371508
> Т.е. пожатый исошник весит 307 MB и распаковывается в 2 или 4 GB.

Ну и причём тут ISO-то? Когда ты jail сетапишь, например, он тебе не нужен, скачиваешь базу по ссылке и распаковываешь, куда надо.

> А приведенная в качестве примера кастомная сборка, с компилятором в базе - после установки всего 315МБ.
> Ну и лукавите вы немного с размером в вашем примере:
>> 147 метров, какие 2Gb? На диске побольше будет, да, метров 200-300.
> xz -l base.txz
> Strms  Blocks   Compressed Uncompressed  Ratio  Check  
>  Filename
>     1      33  
>   147,2 MiB    772,5 MiB  0,191
>  CRC64   base.txz
> А на диске под все 800 будут.

Ок, гигабайт на диске. И 147 метров в архиве - столько мы тащим по сети. Это не копейки?

>>> Либо оно не используется, но им может воспользоваться нападающий. Тоже классика жанра.
>> Нападающий воспользуется дырой в не запущенном демоне? Не рассажешь, как например?
> Принципиальные примеры:
> https://gist.github.com/hugsy/5933831 - даже если вы не пользуетесь ping, SUID у него никто не отбирал. Т.е. получаем классическое "privilege escalation" из nobody в рута.

Для этого у nobody должен быть shell на машину. Если он есть, ping автоматически переходит в категорию "используется" и, следовательно, должен обновляться.
Или предполагается, что ты на этапе сборки базы из пакетов-кубиков сможешь предугадать все дыры в ПО в каждом из пакетов и удалить именно их, оставив только неуязвимое?

> Или как сдесь: https://www.opennet.me/opennews/art.shtml?num=47792
>>  выявлена серия уязвимостей, которые могут быть использованы локальным атакующим для запуска кода с правами ядра через загрузку специально оформленного eBPF-приложения.

Аналогично - нужен локальный shell и права на eBPF для непривилегированных пользователей.

> Про уязвимости в старых драйверах думаю можно не упоминать, а их в GENERIC тоже много загружается.

То, что не используется - не загружается. Но можно загрузить, да. Работать, правда, от этого такой драйвер не начнёт.
В OpenBSD, например, вообще нет загружаемых модулей ядра (хотя кастомизировать его можно, без пересборки - man config), т.е. в дефолтной конфигурации ядро включает в себя если не всё, то очень многое. При этом, одна из целей OpenBSD - "security by default".

> Не противоречит, но акценты расставлены по разному. Грубо говоря, убирание той же zfs-обвязки при неиспользовании zfs и сборка с "-O3" или новейшим компилятором - на мой взгляд две большие разницы.
> И если для второго я в принципе согласен с разработчиками "сначала попробуйте собрать нормально", то вот для первого пересборка всего и вся все же перебор.

Почему? По-хорошему, это первое, что нужно делать - проверить, работает ли стандартная конфигурация. Если да, мы уже на пути к локализации проблемы. Если нет - мы точно знаем, что это не связано и мб мы нашли баг.

> Не-не-не. Зачем кирпичики из N баз?
> Речь о кирпичиках в виде готовых пакетов из той самой, одной официальной фряшной базы, собранные так, как представлялось правильным разработчикам.

1) Что мне помешает решить, что я умнее всех и заменить N пакетов на "более свежие" из другой сборки? Или поставить пакеты без вредной на мой взгляд функциональности?
(со всеми вытекающими последствиями)
2) Что мешает мне прописать нужные WITHOUT_* в src.conf и сделать make BATCH_DELETE_OLD_FILES=true delete-old delete-old-libs? Выкину из базы лишнее вообще без пересборки.
3) Я собрал свою версию, скажем, openssl и решил вкорячить её вместо базовой. Как отговорить меня от выстрела в ногу?
На самом деле, так можно очень долго продолжать, но не очень хочется.

> Просто не таскать всегда и повсюду все "кирпичики" (см. дебагсимволы) а только нужную часть.

Это можно делать и разбивая систему на меньшее число частей. Какие плюсы именно от увеличения гранулярности?

> Что любители экзотики пусть собирают и поддерживают свои хотелки сами, я даже не спорю. Но вот объявлять любой "шаг влево-вправо" (например отсутствие в базе vi или mlxtools или дебагсимволов) экзотикой, как это по факту делается сейчас - это по-моему тоже крайность.

Ну WITHOUT_VI (или как там) - это, ИМХО, плохой повод заворачивать багрепорты, да. Только это вопрос всё равно не про способы пакетирования. Ну будут тебе говорить "доустановите freebsd-base-vi чтобы мы рассмотрели ваш багрепорт" - какая разница?

Думаю тут идёт к тому, чтоб была альтернатива пакетам. К примеру либы опенсорсные закинуть, вместо родных. Или тот же стэк zfs on Linux  и т.п.

Ээээ... а родные либы фряхи - неопенсорсные?

> Думаю тут идёт к тому, чтоб была альтернатива пакетам. К примеру либы опенсорсные закинуть, вместо родных. Или тот же стэк zfs on Linux и т.п.

В каком смысле альтернатива? Тут как раз в обычные фрибсдшные пакеты упаковали базу и ядро.
Можно будет, например, собрать базу с нужными тебе опциями и деплоить её как пакеты, без freebsd-update. Возможности заменить, например, openssl из базы openssl'ем из портов будет нельзя. Только если собрать новый пакет базы с другим openssl.
Теоретически, pkgbase и фрибсдшной вики может (в перспективе) позволять такое - там как раз база разбита на отдельные пакеты. Но, как я уже писал, я считаю этот вариант вопиюще неадекватным для реалий FreeBSD, делающим поддержку системы более сложной, чем это нужно.
Оверинжиниринг, короче.

> если бы разработка всех компонентов FreeBSD велась независимо, как в Linux. Тогда мы бы просто брали дистрибутивы программ из репозиториев

И имели бы перманентный головняк с разными мелкими "гвоздями в сапоге", потому что все независимые, все сами по себе и все работают по принципу "кто в лес, кто по дрова".

>> если бы разработка всех компонентов FreeBSD велась независимо, как в Linux. Тогда мы бы просто брали дистрибутивы программ из репозиториев
> И имели бы перманентный головняк с разными мелкими "гвоздями в сапоге", потому что все независимые, все сами по себе и все работают по принципу "кто в лес, кто по дрова".

Да я, собственно, не призываю к такому, а пытаюсь показать, что модель распространения дистрибутивов Linux неприминима as-is для FreeBSD.

Согласен с Доном (и его нижними постами). Базовая система фри - это то, чего не хватает линуксу. Я имел дело с 4 и 6 версиями freebsd, потом это стало не востребовано для меня, все работают с линуксом. Но такие вещи, как отсутствие базовой системы, кажутся странными в линуксе до сих пор. Поэтому, больше всего нравится центос, несмотря на галимую проприрастическую RH, суть в долгоиграющем и поддерживаемом минимуме пакетов "базовой системы", а остальное всё кастомное и ставится сверху. Ну в центе, как всем известно, пакеты составляющие "базу" мелкие, обычные линуксовые, но хотя бы консистентны и обновляются на протяжении нескольких лет.

Все в мире стремится к идеальным формам унификации, вот и "лохматый монстр" BSD потянулась туда же. Может быть вектор направления и верный, полный переход к бинарному обновлению, но как быть если требуются опции пакета, которые не включены в предлагаемый бинарник? Компилировать самому с необходимыми опциями в бинарник и его устанавливать? А не проще ли выбрать make config`ом все нужное из порта и установить интересующий пакет? Может быть от многолетнего использования я и не прав. все новое принимается с трудом, так же было с systemd в Linux... время покажет. Нынче в тренде какая то новомодная тенденция, меньше думать, больше нажимать кнопки в интерактиве, так недалеко и до приложений, которые будут за Вас код писать, путем складывания кубиков на рабочем столе монитора ИМХО.

> не проще ли выбрать make config`ом все нужное из порта и установить интересующий пакет

Нет не проще. Наелись уже зоопарка, когда у тебя на трёх разных машинах пакет собран чуть-чуть по разному, и ты тратишь полдня чтобы это выяснить. Если сильно надо - poudriere в зубы и компилять под свой случай на отдельной машине. Нахрен порты с прода.

> как быть если требуются опции пакета, которые не включены в предлагаемый бинарник

Писать автору софта, чтоб не ленился делать свое поделие модульным; писать мейнтейнеру чтоб тот не ленился включать часто используемые фичи сразу. Например тот же sasl для svn'а или spf для exim'а.

>писать мейнтейнеру чтоб тот не ленился включать часто используемые фичи сразу

Это приводит к тому, что все опции включаются сразу, и пакет тянет за собой dependency hell.
А что, в бзде уже не так? Говнотык больше за вимом не тащится?

Так решение есть. Если софт состоит из плагинов, то их можно в отдельные пакеты паковать. Другой вопрос, что в вряхе это делается весьма больно, т.к. из одного порта нельзя собрать несколько пакетов. Впрочем, в федоре и дебиане это тоже очень муторно, если плагинов много.

> Другой вопрос, что в вряхе это делается весьма
> больно, т.к. из одного порта нельзя собрать несколько пакетов.

FLAVORs уже завезли. С разморозкой!
pkg rquery %o emacs-nox, emacs
editors/emacs
editors/emacs

pkg rquery %o py27-openssl
security/py-openssl
pkg rquery %o py36-openssl

Два пакета: vim и vim-console, второй без иксовых зависимостей

>Писать автору софта, чтоб не ленился делать свое поделие модульным

А какой толк от модульности, если ты собрался на этапе сборки этим управлять? ffmpeg вон не модульный, но отключить почти всё можно.

>Писать автору софта....  Не вариант, одному опция нужна другому нет, эдак проще все до кучи включить, но в этом случае теряется весь смысл унификации и самой сути индивидуальности ОС.

Вы сами себе противоречите, если у Вас пакет собран чуть чуть по разному на 3-х разных машинах, то предлагаемый бинарник с отсутствующими опциями Вам ничем не поможет, т.к. собирать будете сами, "чуть чуть по разному" для трех разных машин, если там нужно на них это чуть чуть разное. За более чем 20 лет работы с ОС на кодовой базе UNIX, ни разу не столкнулся с описываемой Вами проблемой. Иногда нужно быстро установить пакет, из порта эта операция будет быстрее чем путем включения нужной опции с последующей сборкой бинарника. В бинарном формате есть свои неоспоримые преимущества, как раз шаблонное теражирование на одинаковые конфигурации, та же синхронизация конфигураций из одного общего репозитория,но описываемый Вами пример не к этой теме.

>недалеко и до приложений, которые будут за Вас код писать

Да скорее бы уже.

Ну вот, а то все рассказывали, что, дескать, базовая система - это величайшая ценность, так надо, в пакетах ее не будет, потому что не будет никогда, а вы ничего не понимаете и дураки. :-)

Ты почитай как они разбили, и станет ясно, что базовая система никуда не делась. Просто видимо их базовая система распухла до невозможности, и они решили выделить в userland-base то, что действительно является базовой системой, а остальные куски сделать опциональными.
Так что ничего-то вы не понимаете и дураки. ;)

В качестве первого шага и это очень неплохо, а дальше посмотрим. :-)

> Ну вот, а то все рассказывали, что, дескать, базовая система - это
> величайшая ценность, так надо, в пакетах ее не будет, потому что
> не будет никогда, а вы ничего не понимаете и дураки. :-)

Вообще-то оно уже пару лет как:
https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-Mar...
просто очередной NIH от ТруЪОСников с гигантскими пакетами и заточенное под ZFS.

> Вообще-то оно уже пару лет труп

поправил, не благодари.

Нивзлетело за полной бесполезностью на тех немногих уцелевших промышленных системах, где еще крутится фря, и сомнительной нужностью хомеюзверю - он и ставил-то ради того чтоб каждые три часа все собирать из исходников.

труезники решили зайти с другого конца, может чего и выгорит - для их категории пользователей (если таковые вообще существуют не в их воображении)

>Нивзлетело за полной бесполезностью на тех немногих уцелевших промышленных системах, где еще крутится фря,

промышленность - это сеть ларьков с 1с?

у 1С везде линукс, не переживай за них так.

Говно идея. Получится еще один дистр линукса - голое ядро, само по себе ни для чего не годное, подпертое кучей кривых костылей.

>[оверквотинг удален]
> базовая система преобразована в набор связанных между собой пакетов. Сборки развиваются
> в рамках проекта pkgbase (https://trueos.github.io/pkgbase-docs/), предоставляющего
> средства для использования штатного пакетного менеджера pkg для управления пакетами, образующими
> базовую систему.
> Поставка в форме раздельных пакетов позволяет существенно упростить процесс обновления
> базовой системы и использовать единую утилиту pkg как для обновления дополнительных
> приложений (портов), так и для обновления базовой системы, включая компоненты пространства
> пользователя и ядро. Проект также даёт возможность сгладить ранее жёстко очерченные
> рамки между базовой системой и портами/репозиторием пакетов, а в процессе обновления
> учитывать сочетаемость сторонних программ с компонентами основного окружения и ядром.

Идея не нова, в gentoo-freebsd давно разбили.

>[оверквотинг удален]
> и buildkernel-debug (файл /usr/dist/kernel-debug.txz с отладочным логом сборки ядра).
> Пакеты для ветки 13-CURRENT будут обновляться раз в неделю, а для ветки
>  12-STABLE каждые 48 часов. В случае изменения предлагаемых по умолчанию
> файлов конфигурации, в процессе установки обновления производится их слияние с локальными
> изменениями в каталоге /etc. Если выявляется конфликт, не позволяющий объединить настройки,
> то оставляется локальный вариант, а предлагаемые изменения сохраняются в файлах с
> расширением ".pkgnew" для последующего ручного разбора (для вывода списка конфликтующих
> файлов с настройками можно использовать команду "find /etc | grep '.pkgnew$'").
> URL: https://lists.freebsd.org/pipermail/freebsd-current/2019-Apr...
> Новость: https://www.opennet.me/opennews/art.shtml?num=50598

Надеюсь, в основную FreeBSD эти "замечательные" идеи ни у кого не хватит ума перенести. Ну а авторам TrueOS удачи в попытках сделать простое сложным и решать таким образом несуществующие проблемы. Они вообще затейники - то серверами займутся, то десктопами, то свой десктоп с запилят, который ничего кроме содроганий вызвать не может, то обвязку к джейлам сделают сначала с гуями, а потом без, то переименуют дистрибутив, то теперь вот решили распилить базовую систему, потому что... почему бы и нет?
Даже интересно - те, кто их деятельность спонсируют, вообще следят за расходованием средств? И адекватности получаемого результата производимым денежным вложениям.

О, бизнес-оналитика подъехала. Уроки сделал?

>О, бизнес-оналитика подъехала. Уроки сделал?

Все требует средств, халявы не бывает. Это голожопые совки про бюджет-фонды не думают, потому что отсохло.

Думать о расходе средств по проекту и про соотвествие прагматичным целям это базовое.

> Это голожопые совки про бюджет-фонды не думают, потому что отсохло.
> Думать о расходе средств по проекту и про соотвествие прагматичным целям это базовое.

Всё у тебя смешалось в кучу. Взболтай кашку в голове, чтобы не пригорало.
То, о чём ты пишешь характерно только для пост-совка. Именно в пост-совке деньги выделяются и ожидается хоть что-то на выходе. На Западе огромное количество доноров, которые могут вливать миллионы долларов в проекты ради исследовательских целей. Люди буквально могут проработать всю жизнь и получить результаты только через N лет. Такой овер-донат в итоге оказывается результативным, не одно, так другое выстрелит. А в пост-совке наука в деградационном состоянии, потому нет финансирования, нет вливания в исследовательские проекты. Ура-патриотический идиотизм не в счёт, это чисто формальная пропаганда, которая к пратике мало отношения имеет.

отлично, мы вас поняли - где нам получить миллион на ремонт провала? Ну, чтоб не очень проваливался!

Исключительно ради исследовательских целей - вдруг вы дадите мне миллион, я всю жизнь проработаю (по дороге подумаю, над чем) и он выстрелит.

P.S. какое отношение к науке имеет васян-сборка freebsd current я уж и не спрашиваю - вполне возможно, что это исследование такое - например, в области психологии простейших. Ну, или паразитологии... Все это неважно - важно что я тоже хочу из г-на на курорт, и даже умею собирать пакеты пакетов в пакеты! Не подскажете, в какой бы это фонд обратиться?

> где нам получить миллион на ремонт провала?

вы из рфии? тогда нигде. лично вам рекомендую включить кисилёва, соловьёва, супругов скабеевых. они вам расскажут о том, как отечественная наука бороздит просторы космоса...

>> где нам получить миллион на ремонт провала?
> вы из рфии?

А что, эти миллионы раздает фонд Сорося (запрещенная в Рფ террористическая организация) ?
Ну ок, я могу переехать в Берлин, на какие только жертвы не пойдешь ради миллиона - но миллион-то от этого как образуется? Как получить bk не надо, это я знаю, там миллионами не пахнет, а работать заставят больше чем тут.

> скабеевых. они вам расскажут о том, как отечественная наука бороздит просторы
> космоса...

пока что вы нам рассказываете сказки - похоже, из приграничного failed state, о том как у белых людей за морем груши размером с арбуз сами в рот падают, стоит только его открыть.

А я, в отличие от вас, за тем морем бывал, и нифига полей золотых деревьев не видал. Не бежали там со всех сторон осчастливить предложениями взять миллион и поразрабатывать что-нибудь этакое, с неопределенным сроком достижения неопределенных результатов, а все требовали либо бизнес-план, либо программу исследований, с обоснованиями что откуда берется и как планируется в результате обналичивать.

отдельным ловким жуликам действительно удавалось хапнуть миллионы и профукать их в воздух, а совсем отдельным так даже и не совсем профукать, но таких успешных и ловких - единицы, да и врали они поубедительней вас.

А разработчики васян-форка current очень навряд ли из таких. Хотя какой-то грант видимо таки пилят, но это малоинтересно.

> я могу переехать в Берлин

Не можешь. Ты старый и хочешь просто взять денег и ничего не делать. А нужны молодые, которые возьмут деньги и будут делать хоть что-то полезное.

>> переехать в Берлин
> Ты старый и хочешь просто взять денег и ничего не делать. А нужны молодые, которые возьмут деньги и будут делать хоть что-то полезное.

Я правильно тебя понял, брат Аноним что в Берлине и других местах массового скопления эльфов гранты раздаются только молодым и с них в свою очередь потом не требуется никакая отдача?

> какое отношение к науке имеет васян-сборка freebsd current

хех, да никакого... но ведь пациент в ветке затронул фундаментальный и такой животрепещущий вопрос халявы, такой милый и любимый вопрос для любого жителя пост-совка... в том числе и для нашего замечательного юзверя поха...

> в какой бы это фонд обратиться?

В Сколково. Там вам вручат в руки изобретённую лет 50 назад советскую спистоперделку, которую вы будете выдавать за новейшее чудо российского ноу-хау.

>> в какой бы это фонд обратиться?
> В Сколково.

не, не катит, это надо было родиться в правильной семье, ходить в правильную секцию и быть вообще правильным пацанам.
У нас с вами, в лучшем случае, получится трюк Абби повторить. Которым сначала дали денег - потому что у  них на самом деле был продукт, которым страна могла бы гордиться. А потом велели отдавать назад и с процентами - потому что те имели наглость на 1/10000000 этих денег купить печеньки сотрудникам. А вот такого быть не должно - кормить холопов на казенные деньги, ишь чо удумали! "Этак каждый пролетарий жрать захочет тоже!"

но вот товарищ из недалекого (во всех смыслах) зарубежья вещает, что уж он-то почти может протянуть руку и хапнуть пачку денег просто за то что умный и красивый.

>А потом велели отдавать назад и с процентами - потому что те имели наглость на 1/10000000 этих денег купить печеньки сотрудникам.

Ух ты, стало интересно. А где можно почитать, что конкретно случилось? По каким словам гуглить?

abby сколково, каких тебе еще слов? гугль нынче у каждого свой, что он тебе принесет - понятия не имею. Мне вот секс с лошадками и поняшами в основном, независимо от контекста поиска.

> паразитологии

хорошо, что вы акцентировали внимание на паразитологии. пора прекращать слать русские слова по буржуйским сетям передачи данных, с буржуйских ос, с буржуйских компьютеров. пора возвращаться к лаптя^W к истокам! кстати, когда вас загонят в чебурне^W в резервацию подальше от прогресса, то чем планируете заняться? если у вас возникнет желание начать писать свою ОС - какую-нибудь БалалайкаОС, то потом вам порекомендую толковую литературу по написанию загрузчиков.

>Всё у тебя смешалось в кучу. Взболтай кашку в голове, чтобы не пригорало.

Ты специалист по кашам в голове? Или просто наболело?

>На Западе огромное количество доноров, которые ...

Космические корабли бороздят просторы космоса...

По теме TrueBSD есть информация?

> Ты специалист по кашам в голове? Или просто наболело?

Что? Чего наболело? Ты о чём? Тебе выше написали, что ты бизнес-оналитик мамкиного уровня. Суждения о капитализме уровня "утилитаризм 19-го века".

> По теме TrueBSD есть информация?

Какая информация тебе нужна? Прекрати вилами по воде грести, аналитик и горе-критик. Иди беги уроки делай.

>Что? Чего наболело? Ты о чём? Тебе выше написали, что ты бизнес-оналитик мамкиного уровня.

Эй, взросляк, ты вообще на никнеймы смотришь? Или просто в космос сообщения пишешь? =)

>Надеюсь, в основную FreeBSD эти "замечательные" идеи ни у кого не хватит ума перенести.

Нет, не смогут.
В Makefiles много условий WITH_*(MK_*), и результат учета зависимостей, прежде всего библиотечных - матрица с десятками вариантов вариантов.

Траблов много, толку мало.

Я за 600 пакетов вместо 10.
Тут есть один маркетинговый и не очень плюс.
Живя в эпоху контейнеризации хочется иметь маленький такой jail с минимальным набором пакетов.

Собери кастомную систему с нужными WITHOUT_* в chroot один раз.
Достаточно на одной системе, потом копировать.
m4/cpp/ансиблы в руки, и генерить конфигурацию автомагически.

> Собери кастомную систему с нужными WITHOUT_* в chroot один раз.

убедись, что даром потратил несколько часов жизни, поскольку результат отличается от некастомного на 5% размера.
Заплачь и [роснадзор], ты не нужен миру.

в реальности - минималистичная система в jail - это одна-единственная программа и нужные ей .so (у меня долгое время так жил named) - тут вам чай не линyпс с доскером, где непременно надо затолкать в "контейнер" полноценную систему целиком, иначе пользы от него никакой. Все скрипты, сокеты, логи и прочее при этом остаются в хост-системе, внутри джейла они нафиг не нужны.

$ du -sch /lib* /*bin /usr/lib* /usr/*bin /usr/share
12M    /lib
449K    /libexec
1.1M    /bin
7.9M    /sbin
76M    /usr/lib
270K    /usr/libdata
3.2M    /usr/libexec
216M    /usr/bin
18M    /usr/sbin
82M    /usr/share
416M    total

если потыкать WITHOUT_, то можно получить минус 25-30%
SVN, GROFF, CLANG, MAN, ZFS, ...

это больше чем 5%.

другой вопрос, когда это необходимо.

>Собери кастомную систему с нужными WITHOUT_* в chroot один раз.

И все равно там куча гoвна останется.
Фря - это тяжкое наследие 90-х, когда компы были слабыми, а интернеты дорогими, и в базовую поставку по дефолту включалось все, что могдо понадобиться для развертывания сервака для универовской локалки. Вот так оно чучелом священной коровы и существует по сей день.

ага, то ли дело вот сейчас - "live" (других - нету!) "серверный" дистрибутив б-жественной бубунточки из закрытой от интернета сети (или при банальном отсутствии нужного драйвера) поставить нельзя, никак, вообще, совсем. На 800 мегабайтный образ (не помещающийся на нормальную cd болванку даже если б и были) не поместилось, понимаешь, минимума, который позволял бы хотя бы в принципе поставить систему. А в чем, собственно, тогда "live"? А хз, слово, наверное, красивое.

Нет, сетевая установка тоже не работает - ломится (не спрашивая, надо ли и можно ли вообще) в интернет, и плевать что его тут не предусмотрено в принципе, а все нужные пакеты лежат локально - генитальных аффтаров это не колебет.

Если вы считаете что фря "тяжкое" наследие - выбросите его нахрен и убейте себя. Ну или поставьте любимую бубунточку, там все так как вы любите, и не лезьте в то, в чем не соображаете ничего.

Ты кроме "божественной" бyбyнточки других дистров не знаешь, да?

>Фря - это тяжкое наследие 90-х, когда компы были слабыми, а интернеты дорогими,

А также дорогие диски... и скорость записи на них тот еще....

Л - логика.

У меня другой вопрос - уважаемый балагур, ты вообще freebsd систему видел? =)

А че, chroot как один сервис запустить несудьба?
/usr/bin/ldd `find * -type f -perm +0111` | /usr/bin/awk '/=>/ { print $3 }' | /usr/bin/xargs -J % cp -p % <jaildir>/lib

> А че, chroot как один сервис запустить несудьба?
> /usr/bin/ldd `find * -type f -perm +0111` | /usr/bin/awk '/=>/ { print
> $3 }' | /usr/bin/xargs -J % cp -p % <jaildir>/lib

Много ж так накопируешь …
ldd -a -f "%p\n" $(find foo) |sort -u|grep -v ":$"

NanoBSD

42

43

https://github.com/z0nt/pkg
и @@@дь на это понадобилось каких-то 7 лет?!

это просто никому не нужное ненужно - можете потратить на него и следующие стосемь.

> это просто никому не нужное ненужно - можете потратить на него и следующие стосемь.

Это мягко говоря не так: аналогичная конструкция использовалась, по меньшей мере, в одной из крупнейших инсталляций FreeBSD. Пока она, эта инсталляция, имела место быть.
То, что по ссылке, позволяет деплоить базовую систему тремя пакетами: freebsd-{base,kernel} и freebsd-rescue. Это сильно более практично, чем пе*долинг с freebsd-update, если ты хочешь обновлять им свою сборку базы. Единственный минус - не будет обновления дельтами.

> То, что по ссылке, позволяет деплоить базовую систему тремя пакетами: freebsd-{base,kernel}
> и freebsd-rescue. Это сильно более практично, чем пе*долинг с freebsd-update, если

это точно более практично чем банальный installworld с примонтированной по nfs эталонной сборки?

Просто это-то работало, и, возможно, работает посейчас (не уверен - мои последние полупромышленные системы, где это имело смысл, умерли задолго до Aug 15, 2012), причем все, кому нужно было полуавтоматическо решение - уже тогда его примерно в этом же виде и применяли.

миллиард мелких пакетов понятен - можно обновлять только то что поменялось, и, если поменялось что-то несущественное - обновлять неглядя. А в таком варианте - по-моему, только зряшная потеря времени на опакечивание того, что все равно осталось монолитом. Ну и зачем?

> это точно более практично чем банальный installworld с примонтированной по nfs эталонной сборки?

Всё как всегда зависит от задач. Плюсы подхода с разбитой не незначительное число пакетов базы:
* мы можем иметь несколько баз в зависимости от потребностей и не придётся велосипедить с метадатой - используются средства pkg
* в продолжение про метаданные: из коробки версионирование
* можно проверить целостность базы средствами pkg check
* последствия от помершей сети в случае NFS могут быть более печальными

> Просто это-то работало, и, возможно, работает посейчас (не уверен - мои последние полупромышленные системы, где это имело смысл, умерли задолго до Aug 15, 2012), причем все, кому нужно было полуавтоматическо решение - уже тогда его примерно в этом же виде и применяли.

У меня такое тоже было и работало. Тоже во времена до pkg.

> миллиард мелких пакетов понятен - можно обновлять только то что поменялось, и, если поменялось что-то несущественное - обновлять неглядя.

Это бы сработало, если бы база была бы модульной с точки зрения процесса разработки.
Сначала упихивать пакеты в базу, фризить версии и поддерживать их как часть базы, чтобы синхронизировать релизные циклы, а потом пилить обратно на куски, чтобы рассинхронизировать их?
Выглядит как слишком хитрый план.
Т.е. пока FreeBSD не станет bare kernel + packages, как Linux, все схемы с базой в 100500 пакетов будут являться изнасилованием здравого смысла. А нужен ли нам второй Linux вместо FreeBSD?..

> А в таком варианте - по-моему, только зряшная потеря времени на опакечивание того, что все равно осталось монолитом. Ну и зачем?

Пока с точки зрения разработчиков FreeBSD - монолит, т.е. одна система, монолитом и останется. Pkgbase не от TrueOS тоже - порубленный на куски, но монолит.
А зачем - чтобы обновлять базу штатными средствами без секаса с freebsd-update, поддерживать который не очень просто.

> https://github.com/z0nt/pkg
> и @@@дь на это понадобилось каких-то 7 лет?!

Еще один.

usr/src % git log release/packages
Author: bapt <bapt@FreeBSD.org>
Date:   Sun Feb 8 18:07:23 2015 +0000
    Add a packages/ subdirectory which will contain the metadata for packaging base
    Add a first example to package the kernel

Здравое решение. Вопрос только в качестве реализации.

Реальность: TrueOS пытается запилить свои пакеты.
Новость на опеннете: в BSD только-только завозят пакетные системы.

А так самый лучший вариант наверное у гайки, но там свобода никакая, всё сугубо по правилам.

Заголовок новости не соответствует содержанию : труосники могут тестировать что им угодно,но к ванильной фре это имеет очень опосредованное отношение.

А почему они вообще, называют свои исошки фрибзд а не труос?

Ваще зе бест. Еще и если pkg audit будет уязвимости по ядру показывать, так цены не будет!

kris at ixsystems.com kris at ixsystems.com написал буквально следующее:

"I'm pleased to announce "

то есть "Я рад объявить..."

и он это объявил не от имени труос, а от себя.

Не "Проект TrueOS объявил о " а владелец компании продвигающей труос и заодно фрю объявил о...

> сгладить ранее жёстко очерченные рамки между базовой системой и портами/репозиторием пакетов

и вот зачем это сглаживать? умники тоже мне

Это чё, теперь не надо будет иметь две версии OpenSSL - одну древнюю, прибитую гвоздями к базовой системе, другую свежую из портов?

Ишь чего захотел! Может тебе и две версии компилера в системе не надо и **дорский сендмейл из базы выкинуть?

> Это чё, теперь не надо будет иметь две версии OpenSSL - одну
> древнюю, прибитую гвоздями к базовой системе, другую свежую из портов?

как только пересоберете всю систему  с новой-модной из-портов (где совместимость поломана с чем можно и с чем нельзя) - так и не надо будет.

Там уже всё не так плохо, libressl в этот раз всего пару портов сломал :)

Кагбэ, никто не запрещает посмотреть релизнотесы опенссл, а потом прогрепать код на предмет обращений к поломаным функциям.

Жаль, что gentoo/freebsd загнулась. Для неё это была бы хорошая новость.

Через 20 лет они придумали  генту

>Через 20 лет они придумали  генту

не, просто следущее поколении пепси решило еще раз повторить грабли линуксо-свалки.

Дeбилы блин...
FreeBSD - цельная система, все компоненты спаяны вместе и протестированы, разрабатываются и обновляются вместе, оттого и стройность кода, стабильность.
Зачем превращаться в линух?!
Давить таких недоумков надо

Полегче.

То что предложили фактически есть чуть более мелкая нарезка того что уже существует.

Параллельная тема с тем чтобы запаковать в отдельный пакет каждую либу и прогу отдельно - оно тоже имеет смысл - в случае бинарного обновления скачается только то что реально нужно обновить.
Скорее всего так не выйдет потому что для этого нужна готовая автоматическая система, которой нет, а следить за этим как с портами просто нет рук.

Клал я болт с прибором на вот эти твои "все компоненты спаяны вместе и протестированы, разрабатываются и обновляются вместе, оттого и стройность кода, стабильность.".
Софт что идёт в коробке или не нужен или устарел, обычно всё тоже самое есть в портах.
(я тут про всякие опенссл, анбоунд, опенссл и прочее что есть в портах)

Всякий специфичный для фри мусор мне тоже часто не нужен, в том числе и zfs - я им не пользуюсь и не собираю.

Насчёт протестировано - ох, ты просто теорик.
Фряшники умудрились сломать поведение accept()+close() при переходе на 11 - ну это просто праздник какой то, и я потратил пару дней чтобы понять почему наш софт не работает, потом написать замечательную кроссплатформенную утилиту на сях которая гоняла разные варианты accept()+close() и показать разницу что линукс, драгонфлай и фря10 - ок, а фря11 - фейл.
Ну и пользователи астериска тоже напоролись на это.

Или вон на днях проапгрейдили linuxkpi и дрова спёртые из линукса для видюх сломались разом.

И таких случаев хватает, и это я на стабле сижу а не на курренте.

Вообще-то, это разрабы фряхи клали чугунный шкворень с прибором на то, что тебе нужно или не нужно, что ты пользуешься и собираешь, а чем ты не пользуешься и не собираешь.

>потратил пару дней чтобы понять почему наш софт не работает, потом написать замечательную кроссплатформенную утилиту на сях которая гоняла разные варианты accept()+close()

у меня есть пару фиговинок для управления, одна на голых
socket/kqueu + std::thread & co, вторая на asio (по сути там тоже socket/kqueu)

как работали, так и работают, включая 10-STABLE начиная с ~ 10.1

вот интересно, я что-то пропустил? че было то-то?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259
У меня тоже вроде больше ничего не сломалось, но подозреваю что кроме софтины на работе и астериска было что то ещё, просто не репортили или не связали с тем что я накопал.

>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259

r285910 attempted to make shutdown() be POSIX compliant by returning
ENOTCONN when shutdown() is called on unconnected sockets.

хз, я прям не настолько много пишу кода, знаю стек, и могу ошибаться,
везде перед закрытием обычно гасят клиентские сокеты, останавливают обработку, и потом сразу закрывают серверный.
промежуток между accept и работой с клиентским, и между стоп и close слущающего тоньше чем у комара, поэтому обрабатывать результат shutdown как-то не с руки.

поэтому не стал бы пафосно писать "все поломали", скажем, разработчик изменил не часто используемое поведения shutdown без объявления.

Смысл бага в другом.
Приложуха запускается, и запускает поток, который создаёт слушающий сокет блокирующий и через accept() засыпает и ждёт новые конекты.
В этот момент основной поток получает сигнал что надо приложуху прибить или просто конфиг поменялся и нужно всё преинитить, он делает close() или shutdown() + close() для того слушающего сокета в надежде что поток проснётся и помрёт.
Вот в 11 это сломали и поток не просыпался.
В качестве воркароунда я сделал засыпание на poll() или select().

https://svnweb.freebsd.org/base/head/sys/kern/uipc_socket.c?...

из diff, как понял, и может быть, неверно, вы по сигналу запускали обработчик в том же потоке что и socket(), он вызывал shutdown() на блокирующем сокете в состоянии listen, и тут то обработчик и оставливался.

большинство юзало просто close() или еще как, и в ус не дуло (иначе релиз бы не состоялся, ибо ни одно серверное приложение не работало бы).

ну переделали, ладно.

Нет.
Я же написал, у нас было два потока.
Основной на старте запускал дополнительный поток, который создавал слушающий сокет и спал в accept() пока не придут соединения или пока сокет не закроют.
Сокет закрывался из основного потока.
В 11 фре никакие манипуляции с сокетом из основного потока не пробуждали второй поток который спал на accept().

>манипуляции с [слушающим] сокетом из основного [другого] потока

"жесть".

Как то слишком крупная нарезка.
Я бы с удовольствием нарезал по всем опциям из src.conf, потому что когда базовую систему ставит новичёк он получает помойку с кучей ненужного барахла типа почти всего что есть в src.conf :)
И ядро бы порезал, там слишком много модулей развелось в принципе и слишком много напихали в generic.

Собственно для себя я уже всё так и сделал:
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/12.0/
все мои кастомизации под сервер и десктоп, накатываются поверх базовой части и предусмотрена обработка специфичных для данного компа конфигов loader.conf.machine, make.conf.machine, src.conf.machine. И видимо будет ещё sysctl.conf.machine, пока просто не нужно было.
Патчи на ядро и порты у меня лежат отдельно.

И отдельная большая боль в том что FreeBSD не обжитая нихрена :(
Те на сервере с десятком пакетов ещё более-менее, а на десктопе постоянно приходится чинить то одно то другое.

Почему вы не используете системы управления конфигурациями?

Потому что у меня тут не только конфигурация но и скрипты.
И мне проще рсинком это втягивать.
Думаю надо бы положить это в гит.