zfs send + zfs receive

zfs send что именно?

Спорно. Вот есть условный веб-сайт с nginx + php-fpm + mysql + redis. И надо его быстро перенести на другую машину.

nginx динамически слинкован с libcurl. Например. Дальше смотрим ldd /usr/bin/curl - полсистемы утащится.

zfs send + zfs receive

это секретная технология! :)

ну частично саомдостаточный вряд ли имеет большой смысл

Можно статически линковаться со всеми либами, кроме libc и в пределах дистрибутива/версии ОС ты будешь вполне самодостаточным. Если тебе нужно деплоить приложение на кластер, а не распространять пользователям, то вполне себе ок. А можно собраться статически с musl под linux-i386 (взять хедеры от какого-нибудь старого ядра, типа 3.12.6) и тогда бинарь будет работать (без зависимостей) в современных линуксах i386 и x86-64, и в линиксулаторе. Например. Т.е. в зависимости от задачи смысл может и быть.

nginx динамически слинкован с libcurl. Например. Дальше смотрим ldd /usr/bin/curl - полсистемы утащится.

А причем тут libcurl и /usr/bin/curl ?

Можно статически линковаться со всеми либами, кроме libc и в пределах дистрибутива/версии ОС ты будешь вполне самодостаточным. Если тебе нужно деплоить приложение на кластер, а не распространять пользователям, то вполне себе ок. А можно собраться статически с musl под linux-i386 (взять хедеры от какого-нибудь старого ядра, типа 3.12.6) и тогда бинарь будет работать (без зависимостей) в современных линуксах i386 и x86-64, и в линиксулаторе. Например. Т.е. в зависимости от задачи смысл может и быть.

а почему именно с musl?

А причем тут libcurl и /usr/bin/curl ?

ну а как без них nginx заработает, если слинкован с ними не статически?

Можно статически линковаться со всеми либами, кроме libc и в пределах дистрибутива/версии ОС ты будешь вполне самодостаточным. Если тебе нужно деплоить приложение на кластер, а не распространять пользователям, то вполне себе ок. А можно собраться статически с musl под linux-i386 (взять хедеры от какого-нибудь старого ядра, типа 3.12.6) и тогда бинарь будет работать (без зависимостей) в современных линуксах i386 и x86-64, и в линиксулаторе. Например. Т.е. в зависимости от задачи смысл может и быть.

А хедеры ядра при чем здесь, не совсем понял? Где и как они участвуют в процессе сборки?

Можно статически линковаться со всеми либами, кроме libc и в пределах дистрибутива/версии ОС ты будешь вполне самодостаточным. Если тебе нужно деплоить приложение на кластер, а не распространять пользователям, то вполне себе ок. А можно собраться статически с musl под linux-i386 (взять хедеры от какого-нибудь старого ядра, типа 3.12.6) и тогда бинарь будет работать (без зависимостей) в современных линуксах i386 и x86-64, и в линиксулаторе. Например. Т.е. в зависимости от задачи смысл может и быть.

У меня коллега втягивал newlib и libstd++, в а итоге не зависел ни от чего

потому что статически линковаться с glibc плохо, и это скорее не работает. https://stackoverflow.com/questions/14567689/static-linking-of-glibc другие libc тупо не пробовал.

вы чот с темы все спрыгнули

потому что статически линковаться с glibc плохо, и это скорее не работает. https://stackoverflow.com/questions/14567689/static-linking-of-glibc другие libc тупо не пробовал.

хм, интересно.

на исходный вопрос "откуда базовая система" ответ получен был?

точнее, "информация к размышлению", что лучше готового ответа

на исходный вопрос "откуда базовая система" ответ получен был?

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

А хедеры ядра при чем здесь, не совсем понял? Где и как они участвуют в процессе сборки?

версия kernel abi. В новых ядрах есть сисколы, которых нет в старых. А если мы хотим запускаться максимально везде...

версия kernel abi. В новых ядрах есть сисколы, которых нет в старых. А если мы хотим запускаться максимально везде...

да, это я знаю, но не вкурю, как хедеры ядра тут участвуют в сборке?

на исходный вопрос "откуда базовая система" ответ получен был?

Так что мешает быть base-system метапакетом с определенным набором зависимостей?

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

ну потому что вопросы правильно задавать - тоже искусство)) один человек сказал про половину ответа так что вот я и исправил вопрос

Так что мешает быть base-system метапакетом с определенным набором зависимостей?

я вот сегодня интервью Лимонова Дудю смотрел

так вот знаешь, Эдичка молодец, он вместо тупых "да/нет" предлагал несколько раз неожиданные вещи

У меня коллега втягивал newlib и libstd++, в а итоге не зависел ни от чего

Ты про то, что можно и не с musl? Возможно, я писал о том, с чем сам имел дело.

Так что мешает быть base-system метапакетом с определенным набором зависимостей?

это неудобно. Слишком сложно вносить и мержить правки в базовой системе. Сейчас freebsd-update мержит правки, конфиги.

я тебя соответственно спрошу встречно - а нахера вариант именно "base-system метапакетом с определенным набором зависимостей" ?

есть другие варианты, обоснуй именно этот

да, это я знаю, но не вкурю, как хедеры ядра тут участвуют в сборке?

При сборке libc же?

...всё, @pragus слился? =)

При сборке libc же?

о. о таком не думал. Сейчас посмотрю сборочные зависимости glibc

Мне тут сказали что portmgr держит курс на отказ от статических либ вообще

При сборке libc же?

kfreebsd-kernel-headers [kfreebsd-any] То есть при сборке (g)libc на FreeBSD ядерные заголовки нужны, а на линуксе не нужны.

Не знаю насколько правда, но было бы неплохо

например, я когда-то предлагал базу как не метапакет, а мегапакет, с вынесением contrib в отдельные

А вообще, ещё из забавных пакетных менеджеров можно вспомнить nix из nixos. Он странный, но можно держать одновременно несколько версий пакетов. Или ставить их из под юзера в домашнюю директорию без рутовых прав. Имхо, иногда это небесполезные возможности.

Небесполезные... Это все должны уметь в обязательном порядке по-хорошему

kfreebsd-kernel-headers [kfreebsd-any] То есть при сборке (g)libc на FreeBSD ядерные заголовки нужны, а на линуксе не нужны.

В линуксе емнип они вместе с ядром приезжают? В арче по крайней мере да. Хоть и отдельным пакетом.

В линуксе емнип они вместе с ядром приезжают? В арче по крайней мере да. Хоть и отдельным пакетом.

нет. в линуксе можно сопкойно жить без кернел хедеров

Небесполезные... Это все должны уметь в обязательном порядке по-хорошему

Я вот с тобой согласен, но многие имеют иное мнение на этот счёт. Т.е. видимо не всегда полезные =)

В линуксе емнип они вместе с ядром приезжают? В арче по крайней мере да. Хоть и отдельным пакетом.

в арче не отделяют заголовочные файлы и *.so без версии в -devel пакеты, там все в одной куче, и вообще на подпакеты не разбивают

нет. в линуксе можно сопкойно жить без кернел хедеров

Жить можно) А собирать glibc?

Не знаю насколько правда, но было бы неплохо

А что хорошего в отказе от статических либ?

Жить можно) А собирать glibc?

ну я сейчас посмотрел debian/control от glibc. Там ядерные заголовки в сборочных зависимостях только для сборки на kfreebsd

Я вот с тобой согласен, но многие имеют иное мнение на этот счёт. Т.е. видимо не всегда полезные =)

Хотел бы посмотреть на того кто считает их вредными. Просто они требуют нетривиальных изменений всей архитектуры

Жить можно) А собирать glibc?

А может я чего-то не понял. Вот здесь https://abf.io/import/glibc/blob/rosa2016.1/glibc.spec kernel-headers есть в сборочных зависимостях

Хотел бы посмотреть на того кто считает их вредными. Просто они требуют нетривиальных изменений всей архитектуры

Встречал любителей apt и rpm, которые считают всё иное злом неправославным. А изменения архитектуры, это или управжнения в духе nixos или, внезапно, статическая сборка.

А где сейчас во фре статическая линковка?

Встречал любителей apt и rpm, которые считают всё иное злом неправославным. А изменения архитектуры, это или управжнения в духе nixos или, внезапно, статическая сборка.

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

А где сейчас во фре статическая линковка?

Нигде, к счастью

Нигде, к счастью

Это хорошо. А о чем тогда речь выше, откуда выкинуть собрались?

Это хорошо. А о чем тогда речь выше, откуда выкинуть собрались?

Статические либы ставятся в систему. Но по факту почти никогда не используются

Статические либы ставятся в систему. Но по факту почти никогда не используются

Не понял, что в итоге в системе из коробки слинковано статически?

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

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

Не понял, что в итоге в системе из коробки слинковано статически?

Почти ничего

Не понял, что в итоге в системе из коробки слинковано статически?

как минимум /rescue и init

как минимум /rescue и init

спасибо

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

Это сейчас так. А в nix обновление openssl не затронет установленные приложения. Просто будет установлена еще одна версия

в nix извращения с RPATH

насколько я слышал

Это сейчас так. А в nix обновление openssl не затронет установленные приложения. Просто будет установлена еще одна версия

Всё так. Но так как в nix - сложно. Переусложнённо в смысле. Имхо.

Разве? Я думал там симлинки

И каждый пакет в своей директории вида <хэш> со своими ссылками в директории зависимостей

Разве? Я думал там симлинки

И извращения с rpath тоже. patchelf - их рук дело, при установке применяется к бинарям.

Всё так. Но так как в nix - сложно. Переусложнённо в смысле. Имхо.

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

И извращения с rpath тоже. patchelf - их рук дело, при установке применяется к бинарям.

Навскидку не вижу зачем оно нужно если есть симлинки

Приложение видит свой lib/ со своим libdepend.so.N, и всё остальное в таком же виде

ERROR: S client not available

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

Можно собирать приложения в самодостаточные (статическя линковка, опционально, со всем кроме libc, ибо в полностью статическом бинаре dlopen не работает). От nixos оставить только атомарную установку симлинками, резолвинг зависимостей оставить только на стадии сборки. Научить пакетный менеджер знать, с какими либами какой версии собрана программа (чтобы пачкой обновлять то, что дырявое). Будет громоздко,но просто. Нюансов конечно всё равно будет много, но имхо правильнее двигаться в эту сторону.

Приложение видит свой lib/ со своим libdepend.so.N, и всё остальное в таком же виде

а с чего оно увидит свой lib? LD_PRELOAD_PATH ставить? он чреват, например, в LD_PRELOAD подгружаем libz, а libpng берем системный, однако libpng сам требует libz, в итоге рано или поздно получим расхождение, системный libpng не сможет загрузиться с нашим libz, и программа не запустится. про libz+libpng реальный случай - BricsCAD полгода не могли это починить.

Приложение видит свой lib/ со своим libdepend.so.N, и всё остальное в таком же виде

Я не настоящий сварщик. Но что значит "видит свой /lib"? Особенно, если речь о > 1 приложения, которые зависят от разных версий одной либы? И хочется использовать их оба?

Я не настоящий сварщик. Но что значит "видит свой /lib"? Особенно, если речь о > 1 приложения, которые зависят от разных версий одной либы? И хочется использовать их оба?

Это надо у @AMDmi3 спросить. Свой lib/ никто с нихрена не видит, это /etc/ld.so.conf

а с чего оно увидит свой lib? LD_PRELOAD_PATH ставить? он чреват, например, в LD_PRELOAD подгружаем libz, а libpng берем системный, однако libpng сам требует libz, в итоге рано или поздно получим расхождение, системный libpng не сможет загрузиться с нашим libz, и программа не запустится. про libz+libpng реальный случай - BricsCAD полгода не могли это починить.

В этой схеме не будет ничего системного

В этой схеме не будет ничего системного

Как ld будет искать библиотеки?

Каждое приложение будет зависеть от своей libz лежащей в отдельном поддереве

Каждое приложение будет зависеть от своей libz лежащей в отдельном поддереве

Но это же rpath и есть?

Как ld будет искать библиотеки?

LD_LIBRARY_PATH, вестимо

(по сути)

Каждое приложение будет зависеть от своей libz лежащей в отдельном поддереве

так, и как мы бинарнику скажем подгружать именно эту libz? LD_PRELOAD придется использовать. А значит нам придется контролировать зависимости libz, чтобы не было описанного выше рассинхрона. чтобы таким не заниматься, придумали RPATH.

Но это же rpath и есть?

rpath захардкожен, тут потребуется в рантайме строить список путей. Иначе нельзч будет обновить промежуточную библиотеку

rpath захардкожен, тут потребуется в рантайме строить список путей. Иначе нельзч будет обновить промежуточную библиотеку

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

rpath захардкожен, тут потребуется в рантайме строить список путей. Иначе нельзч будет обновить промежуточную библиотеку

Ну так они и патчат rpath при помощи patchelf при установке, емнип. Читаю https://nixos.wiki/wiki/Packaging/Binaries для освежения памяти, присоединяйся

так, и как мы бинарнику скажем подгружать именно эту libz? LD_PRELOAD придется использовать. А значит нам придется контролировать зависимости libz, чтобы не было описанного выше рассинхрона. чтобы таким не заниматься, придумали RPATH.

Понятно как, LD_LIBRARY_PATH=/nix/store/libz1.2.3/lib

Понятно как, LD_LIBRARY_PATH=/nix/store/libz1.2.3/lib

еще раз: так не надо делать.

народ как у стэйбла с ath10k?

хреново даже не у стейбла, увы

Это выстрел в ноги

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

Общесистемного быть не должно, это делает всю схему бесполезной

Общесистемного быть не должно, это делает всю схему бесполезной

в итоге мы получаем snap-пакет?

в котором вообще ВСЁ

потому что при такой схеме потребуется по цепочке зависимостей именно до такого дойти

Ну так они и патчат rpath при помощи patchelf при установке, емнип. Читаю https://nixos.wiki/wiki/Packaging/Binaries для освежения памяти, присоединяйся

А. Да, это наверное правильнее ибо окружение можно внезапно сбросить

А. Да, это наверное правильнее ибо окружение можно внезапно сбросить

На мой взгляд статическая линковка ещё правильнее. lto тем более. И ни окружение не сбросить, ни rpath не поменять. Всё отлито в бетоне)

в итоге мы получаем snap-пакет?

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

На мой взгляд статическая линковка ещё правильнее. lto тем более. И ни окружение не сбросить, ни rpath не поменять. Всё отлито в бетоне)

Она ничего не даёт кроме проблем. Следить за путями все равно нужно, поскольку у зависимостей есть ещё и share/, размер пухнет жо небес, обновление убивает время и батарейку потому что нужно перетряхнуть половину диска. Да, который занят дубликатами кода. Которые в случае lto и не задедублицировать. Алсо, для статической сборки нужно очень сильно колдовать - ее никто уже не поддерживает

Резолвинг цепочки библиотечных зависимостей для статической сборки умел емнип только libtool, который канул в Лету вместе с autocrap, к великому счастью

Кажется его .la повыпилили уже несколько лет назад

Она ничего не даёт кроме проблем. Следить за путями все равно нужно, поскольку у зависимостей есть ещё и share/, размер пухнет жо небес, обновление убивает время и батарейку потому что нужно перетряхнуть половину диска. Да, который занят дубликатами кода. Которые в случае lto и не задедублицировать. Алсо, для статической сборки нужно очень сильно колдовать - ее никто уже не поддерживает

Мой опыт говорит скорее об обратном, хотя я допускаю, что не очень репрезентативен. Объём для меня проблемой не является, диска точно хватит на толстые статические бинари. Колдовать иногда надо, это правда. А насчёт дубликатов кода.. Вот в погоне за самодостаточностю линукс сейчас ушёл в тотальный докер. Получается, что мы таскаем с собой всё как при статической сборке (и даже больше!), при этом, компилятор не может, например, инлайнить библиотечную функцию, или выкинуть те функции из библиотеки, которые не нужны. И это никто не считает толстотой и проблемой. И дубликатами кода. Как по мне, из этого следует, что статическая линковка - куда более экономный к памяти способ создания самодостаточных приложений.

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

сейчас почитал man ld.so. Если у нас в заданной через LD_LIBRARY_PATH есть libz, то описанная выше ситуация происходит, т.к. формально этот libz подошел, не важно, что потом libpng не смог с ним запуститься. Но здесь в названиях айлов нет мажорной/минорной версии либы. А что будет, если в названии файла будет версия библиотеки - уже пора спать, а не о таком думать, но место очень узкое.

На мой взгляд статическая линковка ещё правильнее. lto тем более. И ни окружение не сбросить, ни rpath не поменять. Всё отлито в бетоне)

Да, и кроме .so есть еще всевозможные модули всевозможных динамических языков, для которых это в той же степени актуально