Поттеринг: «Давайте заменим пакетный менеджер подтомами btrfs»

http://capec.mitre.org/data/definitions/132.html - это один из примеров. Они (симлинки) скорее способствуют, итак непомерному, бардаку в дистрибутивах.

Вроди бы, да же есть альтернатива - вские AuFS и UnionFS, НО нет поддержки файлов с одинаковым именем в одном каталоге.

Убейте его уже, кто-нибудь...

Поц — всего лишь исполнитель, инструмент в руках красношляпого менеджмента.

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

Кто запрещает? Где этот негодяй?

Интересно, что мешает сейчас применять такой подход? Симлинки+чрут или неймспейсы есть.

Ну-ка расскажи мне, как сделать так, чтобы firefox, глядя на несуществующий /usr/lib64/libgtk-x11-2.0.so.0, видел файл /pkgs/gtk-2.24-2.24/build/image/usr/lib64/libgtk-x11-2.0.so.0, а глядя на несуществующий /usr/lib64/libglib-2.0.so.0 - видел /pkgs/dev-libs/glib-2.40.0/build/image/usr/lib64/libglib-2.0.so.0?

Ась? Подобная идея приходила хоть раз любому пользователю линукса.

Почему поцерофаги такие безграмотные?

Еще один поттерингохейтер порвался

http://man.cat-v.org/plan_9/1/bind

только завязанный на btrfs зачем-то.

Гыгы. За тем же, зачем и udev не бывает без journald.

Как это вообще должно работать? Так?

1. Ввожу я в терминале firefox.

2. С помощью cgroups(?) создается изолированное окружение с отдельной памятью, процессором и пустой ФС

3. Для этого окружения конструируется собственная ФС - результат скрещивания полсотни отдельных маленьких ФС, каждая из которых это библиотека или фреймворк (gtk, libpng, ...) - всё, что потребуется для запуска браузера.

4. В этом окружении запускается исполняемый файл

А зачем ему смотреть на несуществующие файлы? Пусть юзает /pkgs/gtk-2.24-2.24/build/image/usr/lib64/libgtk-x11-2.0.so.0 и /pkgs/dev-libs/glib-2.40.0/build/image/usr/lib64/libglib-2.0.so.0

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

чтобы firefox, глядя на несуществующий /usr/lib64/libgtk-x11-2.0.so.0

Когда у разработчиков либ и фреймворков всё хорошо, то должно быть что-то типа «$LD_LIBRARY_PATH/libgtk-x11-2.0.so»

Нет никакой помойки. Кто юзает сильноумные надстройки (костыли), должен страдать.

pkg_add/addpkg десятилетиями нормально работали и тянули бинарные зависимости. А то, что каждый «вендор» себе выдумывает новое смешное название управления пакетами, проблемы вендора. Ну так RH же!

Я как понял он у меня идею украл ?

Что не патентовал ? Сейчас бы затроллил жёстко и зарубил. :-)

В контексте больших кластеров VM-ов просто охрененный план. Наконец-т Поттеринг делом занялся, а не ломанием работающих (!) вещей.

В некоторых случаях даже нужна ext3, например.

И как его заставить это делать? Линковщик ищет либы в заданных директориях. Перечисление ${PKG_PATH}/lib для всех установленных пакетов в /etc/ld.so.conf скажется на производительности. И линковщик libc - далеко не единственный компонент системы, прибитый гвоздями к концепции «содержимое пакетов раскидано по общей ФС».

Я думаю, понадобится какой-нибудь враппер типа pkg-exec <пакет> <путь к бинарнику в пакете>. Только, во-первых, сишным линкером проблема не исчерпывается. Во-вторых, остается вопрос, как задействовать враппер в описаниях служб системы инициализации, .desktop-файлах и т. п.

Это Linux :)

Звучит как приговор

Зачем нужен этот костыль да еще и в качестве стандарта?

Это не костыль. Это красивое решение, делающее множество костылей ненужными.

Можно же просто собирать разные версии в разные каталоги?

Проблема не в этом, а в том, как их после этого запускать. См. сообщения выше.

Во-вторых

Вот мне и кажется, что Поттеринг хочет целиком переписать world, но всё равно всё останется по-старому, только названия сменятся.

Звучит как приговор

Диагноз :)

В оригинале — порядка 5 маленьких ФС, не больше. Библиотеки объединены в крупные рантаймы (или фреймворки — то же самое, но debug-версия).

Поц — всего лишь исполнитель, инструмент в руках красношляпого менеджмента.

Ну значит и менеджмент за компанию

А как тогда насчет маленьких либ? Если их объединить по какому-то критерию и у одной из них появится новая версия - начнется кошмар

unionfs?

Наконец то, годная идея

We want a fully trusted system, where cryptographic verification of all executed code can be done, all the way to the firmware, as standard feature of the system.

Ох, как Большой Брат-то обрадуется. Зонды и кактусы на всех уровнях!

unionfs?

В мэйнлайн ведре его нет.

Пригодность разрабатываемых юнионов для монтирования десятков или даже сотен оверлеев под вопросом.

В мэйнлайн ведре его нет.

unionfs-fuse

$ ldd /home/user/test2/bin/php 
	linux-vdso.so.1 =>  (0x00007fff67bc4000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007faad45e5000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faad42df000)
	libxml2.so.2 => /home/user/test/lib/libxml2.so.2 (0x00007faad3f86000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faad3d82000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faad39bc000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007faad37a2000)
	/lib64/ld-linux-x86-64.so.2 (0x00007faad4825000)

Обращать внимание на libxml2

$ set | grep PKG
$ set | grep LD_
            completions="$COMMON_OPTIONS $BUILD_OPTIONS"

этот дебил правда не понимает, что ресурсы в одном месте это одна из причин, по которой люди используют *nix?

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

unionfs-fuse

Производительность.

возможно знать каждый файл в своей ОС

мм, полезное знание. Мне оно в работе, правда, никогда не было нужно, но тебе лучше знать. /var/log/* по ночам заучиваешь тоже?

Не понял. Как линкер ее находит? Что за переменная completions и как она влияет на поиск?

Ну может слегка просесть. А вообще бы тесты увидеть.

И первоначальный вопрос был «как?». Я показал как. Достаточно приемлемое решение. Ещё бы добавить сюда какую-нибудь FUSE-фс, позволяющую показывать только нужные файлы, например, для защиты $HOME.

тебе оно в работе может и не нужно, а индексатору - нужно.

Это bash completitions, к вопросу отношения не имеют. Я не в курсе, как линкер ее находит, но работает - факт, можешь сам проверить, все опции сборки я указал. Может как-то в бинарь статично зашит путь. Что по твоему делают опции сборки --with-... ?

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

Весьма спорно :) Предлагаю ознакомится с презентацией - http://herpolhode.com/rob/utah2000.pdf

Что по твоему делают опции сборки --with-... ?

задается макросом. по дефолту пишет в config.h #define ENABLE_... 1

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

Что по твоему делают опции сборки --with-... ?

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

Чтобы могло собраться. Мне помнится, я в аналогичной ситуации при запуске потом еще указывал дополнительный LD_LIBRARY_PATH, без этого не работало.

И чтобы от винды отличий было поменьше.

В винде все намнгого изящнее. При запуске любой програмы всё затемняется и появляется окошко «а можно мне полный контроль над твоим анусом?». Ты привычно жмешь «да, да, отъ***сь уже». И все довольны - пользователи - потомучто с правами все также легко и приятно как в винCE-вин98. А майкрософт - потомучто можно на конференциях говорить о современных технологиях защиты

нет, это делает AC_CHECK_LIB, не имеющий никакого отношения к кастомным опциям configure.

Круто, чо.

SUSE Linux Enterprise или в openSUSE? Где про это посмотреть если второе.

AC_CHECK_LIB

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

https://stackoverflow.com/questions/10199754/adding-a-path-to-ac-check-lib

Я ее читал, конечно. Только не понял, к чему ты это.

Можно враппер сделать и более прозрачным. Будет исполнимый файл firefox в /usr/bin, который будет скриптом-конфигом для какого-нибудь /usr/bin/makeenv. В конфиге будет перечислен путь к бинарнику нужной версии, нужные версии библиотек и т.д. и т.п. Пользователи могут иметь и свои скрипты с отличной версией.

.desktop-файлы, я так понимаю, не потребуют никакой модификации.

Службы инициализации и прочее базовое системное можно оставить работающим по-старинке.