LINUX.ORG.RU
ФорумTalks

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

 ,


1

6

Сабж

The scheme we propose is built around the variety of concepts of btrfs and Linux file system name-spacing. btrfs at this point already has a large number of features that fit neatly in our concept, and the maintainers are busy working on a couple of others we want to eventually make use of.

[…]

app:<vendorid>:<runtime>:<architecture>:<version> — This encapsulates an application bundle. It contains a tree that at runtime is mounted to /opt/<vendorid>, and contains all the application's resources. The <vendorid> could be a string like org.libreoffice.LibreOffice, the <runtime> refers to one the vendor id of one specific runtime the application is built for, for example org.gnome.GNOME3_20:3.20.1. The <architecture> and <version> refer to the architecture the application is built for, and of course its version. Example: app:org.libreoffice.LibreOffice:GNOME3_20:x86_64:133

[…]

  • We want a unified scheme, how we can install and update OS images, user apps, runtimes and frameworks.
  • We want a unified scheme how you can relatively freely mix OS images, apps, runtimes and frameworks on the same system.
  • 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.
  • We want to allow app vendors to write their programs against very specific frameworks, under the knowledge that they will end up being executed with the exact same set of libraries chosen.
  • We want to allow parallel installation of multiple OSes and versions of them, multiple runtimes in multiple versions, as well as multiple frameworks in multiple versions. And of course, multiple apps in multiple versions.
  • We want everything double buffered (or actually n-fold buffered), to ensure we can reliably update/rollback versions, in particular to safely do automatic updates.
  • We want a system where updating a runtime, OS, framework, or OS container is as simple as adding in a new snapshot and restarting the runtime/OS/framework/OS container.
  • We want a system where we can easily instantiate a number of OS instances from a single vendor tree, with zero difference for doing this on order to be able to boot it on bare metal/VM or as a container.
  • We want to enable Linux to have an open scheme that people can use to build app markets and similar schemes, not restricted to a specific vendor.

    […]

The future is going to be awesome!

★★★★★

Последнее исправление: x3al (всего исправлений: 2)

Т.е. факт, что все нормальные люди пользуются ext4 во внимание не принимается?

Deleted
()
Ответ на: комментарий от Deleted

Т.е. факт, что все нормальные люди пользуются ext4 во внимание не принимается?

Ты еще ext2 вспомни, ретроград.

mandala ★★★★★
()
Ответ на: комментарий от Deleted

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

erzent ☆☆
()
Ответ на: комментарий от vurdalak

А вообще они похоже изобрели nix

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

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

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

Потому что единственное рабочее подобие неймспейсов в линаксе.

shatsky ★★
()
Ответ на: комментарий от shatsky

не дает возможности, например, запустить сферическую программу в вакууме

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

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от erzent

Я видел твои темы на лоре. Не примазывайся к нормальным людям.

Deleted
()
Ответ на: комментарий от mandala

Ты еще ext2 вспомни, ретроград.

Кто ретроград — ты ретроград, поехавший. Ext4, какбэ, единственная стабильная ФС в линуксе, на данный момент. Мы же говорим о нормальных людях, а не о норкоманах альфа-тестерах, которым заняться нечем.

Deleted
()
Ответ на: комментарий от erzent

спасибо, в 27 лет снова в школу пойду, содержать меня будешь ты?а так же моих детей и жену?

Учиться надо было, а у тебя, как вижу, на уме были только водка, бабы и сигареты.

bluesman
()
Ответ на: комментарий от shatsky

А в Plan 9 неймспейсы ФС-независимы или нет?

Они и в линуксе ФС-независимы. ФС монтируется внутри неймспейса, не неймспейс внутри ФС.

А в btrfs он хочет добавить криптографию (хотя бы проверку подписи) на уровне отдельных подтомов. В других ФС нет подтомов, хотя можно было бы представить подобное в LVM: там есть те же снапшоты, например. Но я не уверен, что накладные расходы от тонны смонтированных ФС в этом случае ничтожны.

x3al ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Да всё, расслабиться можно, 1 сентября на дворе.

Hertz ★★★★★
()
Ответ на: комментарий от daemonpnz

только вот ext3 требует оптимизации ручками.

erzent ☆☆
()
Ответ на: комментарий от robot12

А что, CLONE_NEWNS уже отменили ???

Это про точки монтирования, а мы про файловые неймспейсы, как в Plan 9, или недопиленные UnionFS в Linux.

shatsky ★★
()
Ответ на: комментарий от wisp

Тем, что более низкоуровнево. Можно проверять подписи каждый раз при монтировании, делать/откатывать снапшоты, загружать разные ОС тупо передав ключ в загрузчике (Поттеринг предлагает подтома под *всё*, начиная с ОС и заканчивая эндюзерским софтом), изолировать любой софт в его личном неймспейсе.

И он ожидает, что можно будет, например, поставить СофтПодГном в одном дистрибутиве, перезагрузиться в другой и запустить его.

x3al ★★★★★
() автор топика
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от ptarh

Если оно прикончит помойку из форматов пакетов и их менеджеров

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

AX ★★★★★
()
Ответ на: комментарий от wisp

Чем это тогда отличается от слотов?

!!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict

Ну, ты понял

shatsky ★★
()
Ответ на: комментарий от erzent

то есть превратить линукс в винду, где каждый пакет таскает с собой библиотеки?И будет у нас 2002 копии одного пакета gtk в системе.

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

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

zloelamo ★★★★
()
Ответ на: комментарий от erzent

Опять ничего не понял, но лужи уже газифицируешь?

Ivan_qrt ★★★★★
()
Ответ на: комментарий от vurdalak

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

В никсе нет USE-флагов, к сожалению.

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

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

shatsky ★★
()
Последнее исправление: shatsky (всего исправлений: 1)
Ответ на: комментарий от shatsky

В никсе нет USE-флагов, к сожалению.

На флаги в принципе пофигу, более интересны авто-слоты.

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

Ну значит никто не мешает и портеж поверх этого накрутить, с флагами.

vurdalak ★★★★★
()
Ответ на: комментарий от shatsky

Ну в смысле чтобы у любого софта можно было поставить любое количество версий, а не жёстко прописанные слоты как в портеже.

vurdalak ★★★★★
()
Ответ на: комментарий от x3al

Они и в линуксе ФС-независимы. ФС монтируется внутри неймспейса, не неймспейс внутри ФС.

По-моему, мы о разных неймспейсах. Я не о видимых процессу точках монтирования, а о том, что в линуксах имитируют различные недопиленные UnionFS'ы. Типа прозрачное монтирование, когда процесс видит файлы с множества смонтированных в одной точке ФС.

shatsky ★★
()
Ответ на: комментарий от x3al

Но я не уверен, что накладные расходы от тонны смонтированных ФС в этом случае ничтожны.

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

shatsky ★★
()
Ответ на: комментарий от robot12

mount --bind ?

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

shatsky ★★
()

Леннарт Поттеринг (Lennart Poettering) опубликовал заметку, в которой подробно рассказал об идеях на будущее по переработке организации построения дистрибутивов Linux. Главной целью предложенных изменений является упрощение формирования пакетов с приложениями или окружениями операционной системы и обеспечение возможности их установки независимо от применяемого дистрибутива.

Отмечается, что в настоящее время новые веяния в построении дистрибутивов уже развиваются в таких системах, как Ubuntu Apps, Docker, ChromeOS и CoreOS, но каждая из этих систем узко специализирована и не подходит для универсального применения. Например, Ubuntu Apps рассчитан только на распространение приложений для рабочего стола, Docker жестко завязан на изолированных контейнерах, ChromeOS и CoreOS оперируют только системными образами. При этом ключевой идеей всех этих систем является предоставление готовых окружений, заменяемых целиком и не зависящих от базового программного окружения.

Благодаря использованию подразделов (sub-volume) Btrfs и предоставляемых ядром Linux изолированных пространств имён, разработчики Systemd намереваются подготовить унифицированное решение, подходящее для установки и обновления как целых операционных систем и изолированных контейнеров, так и для отдельных приложений и программных интерфейсов, упакованных в самодостаточные пакеты. Также предлагается реализовать возможность полной верификации всех компонентов системы по цифровым подписям, включая конечные приложения и образы преднастроенных изолированных контейнеров.

Осуществление установки с использованием снапшотов, с сохранением прошлого состояния программы или ОС, обеспечит атомарное применение изменений и предоставит пользователю возможность возврата к прошлой конфигурации. Процесс установки по сути сведётся к репликации готового образа, который будет оставаться неизменен во время работы системы. Пространства имён и подразделы Btrfs помогут организовать сосуществование нескольких идентичных веток в ФС. Например, можно установить несколько подразделов /root и /usr с начинкой разных дистрибутивов, между которыми можно будет переключаться. Появится возможность подключать разные подразделы с частями ФС для разных пользователей и приложений. Кроме того, будет обеспечена возможность установки разных версий runtime-компонентов/фреймворков/библиотек для их подключения в привязке к приложению, производитель которого определил данные версии в числе зависимостей.

Runtime-компоненты и библиотеки предлагается оформлять в виде урезанного образа раздела /usr, содержащего только файлы, необходимые для работы заданного приложения. Приложения предлагается размещать в области /opt/ (например, /opt/org.libreoffice.LibreOffice), при этом экземпляр программы будет размещён в подразделе, привязанном к runtime-компонентам и версии (например, app:org.libreoffice.LibreOffice:GNOME3_20:x86_64:133). Размещение обособленного образа программы в отдельном подразделе позволит организовать доступ к данному подразделу из разных дистрибутивов, установленных на текущем ПК. Для обеспечения доступа к пользовательским данным из окружения разных дистрибутивов и приложений, также предлагается размещать содержимое home-директории пользователя в отдельном подразделе Btrfs.

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

http://www.opennet.ru/opennews/art.shtml?num=40494

Сразу нафиг!

Freiheits-Sender ★★
()
Последнее исправление: Freiheits-Sender (всего исправлений: 1)

не дай Б-г, Поц и это пропихнет во все основные дистрибутивы! просто ужасно! этот дебил правда не понимает, что ресурсы в одном месте это одна из причин, по которой люди используют *nix? теперь он предлагает их разделять! привет, Program Files!

Lincor
()
Ответ на: комментарий от Lincor

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

Lincor
()
Ответ на: комментарий от Lincor

btrfs на десктопе офигенна, особенно если ставить напрямую, без всяких там mbr/gpt. производительность многих ide возрастает, стандартные глюки пропадают.

erzent ☆☆
()
Ответ на: комментарий от Lincor

Если ты про базовую систему, она будет в одном месте. А в том, что эндюзерский гуевый софт перекочует в /opt, лично я не вижу трагедии. В конце концов, если юзеру он понадобится в $PATH — сделает симлинк в ~/.local/bin или куда-нибудь.

x3al ★★★★★
() автор топика
Ответ на: комментарий от erzent

прекрасно поживает, я извращениями с ней не занимаюсь.

Создать кучу мелких файлов - извращение? Мой пример, конечно, искусственный, но распаковка дерева portage даст примерно тот же эффект. Отсюда вывод: btrfs не готова для gentoo.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

я использую её в кальке, проблем нет, УМВР?

erzent ☆☆
()
Ответ на: комментарий от x3al

ага, симлинк, симлинк, симлинк. поттеринг помешался на симлинках. systemd использует симлинки, /{,s}bin и /lib - симлинки внутрь /usr, да, да... а то, что это адовое засирание ФС, его не волнует? пока еще трудно, но возможно знать каждый файл в своей ОС. благодаря леннарту это скоро станет нереально.

Lincor
()
Ответ на: комментарий от Lincor

а то, что это адовое засирание ФС, его не волнует?

А какая ФС разница, сколько там симлинков? Это же не винда, где всё тормозит от мусора в системе.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

ФС может и без разницы (хотя это не так, много inode - это нехорошо, они даже дисковое пространство отъедают, хотя и мизерно), а вот человеку разница есть. и find тоже.

Lincor
()
Ответ на: комментарий от Lincor

а то, что это адовое засирание ФС, его не волнует?

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

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Lincor

а вот человеку разница есть

Зачем человеку лазить в эти симлинки? Религия заставляет каждое утро повторять список файлов в каждом каталоге из корня?

vurdalak ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.