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)
← iCloud взломали
Если бы ЯП были оружием #12375 →
 ← 1 2 3 4 5 6

Ein btrfs, ein systemd, ein Poettering!

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

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

rezedent12 ☆☆☆
()

Смех смехом, а кое-чо кверху мехом. Некоторый софт на шиндошс (в частности кошмарский и SQL Server) давно использует служебные потоки NTFS в собственных целях.

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

Ну не факт, что это прогресс, но в качестве «одного из» подходов — почему нет?
Беда ведь не то, что он что-то там странное пилит, беда в том, что многие дистрибутивы начали внедрять его код не дождавшись окончательного проекта.
Никто не знает ЧТО получится в конце. А ведь есть шанс что ничего не получится. А код уже внедрён.

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

Основной смысл — не в подтомах, а в том, что апстрим сможет паковать пакеты сам, а не ждать даунстрима. Линкуя с вполне конкретным рантаймом. Получая оттестированный пакет в оттестированном окружении. btrfs-подтома — всего лишь вариант имплементации всего этого.

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

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

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

Nix?

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

Nix?

Camel ★★★★★
()

Лор, пора собирать деньги на Киллера, это уже реально жесть.Я конечно активный пользователь BTRFS, но блин, отменить пакетный менеджер, это уже вообще идиотизм, скоро в винду превратит линукс.

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

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

Novell-ch ★★★★★
()

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

Поттерингу показали Plan 9?

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

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

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

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

Нет. Тут идёт разделение на «софт» и «фреймворки». У пакетов с «софтом» явно записана зависимость от конкретной версии фреймворка. Если у нас не будет 2002 пакета, зависящих от разных версий gtk, то и не будет 2002 копий.

x3al ★★★★★
() автор топика
Ответ на: Nix? от Camel

Я так понимаю, в никсе все основано на пропатченном линкере?

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

я таким образом показал важность его найма

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

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

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

Лор, пора собирать деньги на Киллера, это уже реально жесть

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

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

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

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

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

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

Зачем? У него впереди как минимум лет пять изучения английского языка в школе.

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

я и не читал вообще

Вся суть прогрессхейтеров в одной фразе.

shatsky ★★
()

С нетерпением ждем!

P.S.: Если оно прикончит помойку из форматов пакетов и их менеджеров, то будет просто отлично. Даже если через раз будет падать и упрямо распаковывать ядро в \var\log Ибо Поттеринг, пшшшшшшш.

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

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

Нет. В её контейнере — только она сама + указана версия фреймворка/рантайма. Фреймворк/рантайм — ещё один контейнер (юзеры юзают рантайм, девелоперы — фреймворк той же версии). Естественно, он — один для всех использующих эту версию программ.

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

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

Пока что непонятно, как хранится информация о требуемых фреймворках/рантаймах и как она обрабатывается при запуске программы из контейнера.

shatsky ★★
()

Страдайте, хейтеры, страдайте.

eugeno ★★★★★
()

Разработчики Systemd намерены внедрить кардинально новые методы построения дистрибутивов Linux

Леннарт Поттеринг (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

Жаль сегодня не пятница.

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

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

Namespace есть Namespace :) и он не зависит от ФС, потому как ФС в Plan9 это и не ФС вовсе, а может представлять что угодно. Вот пример - http://man.cat-v.org/plan_b/4/x10

robot12 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6
← iCloud взломали
Talks
Если бы ЯП были оружием #12375 →