Майкл Штапельберг (Michael Stapelberg), автор мозаичного оконного менеджера i3wm и в прошлом активный разработчик Debian (сопровождал около 170 пакетов), развивает (https://michael.stapelberg.ch/posts/2019-08-17-introducing-d.../) экспериментальный дистрибутив distri (https://distr1.org/) и одноимённый пакетный менеджер. Проект позиционируется как исследование возможных путей увеличения производительности систем управления пакетами и воплощает некоторые новые идеи построения дистрибутивов. Код пакетного менеджера написан на языке Go и распространяется (https://github.com/distr1/distri/) под лицензией BSD.Ключевой особенностью предложенного в дистрибутиве формата пакетов является поставка пакета в форме образов SquashFS, вместо сжатых tar-архивов. Применение SquashFS, по аналогии с форматами AppImage и Snap, позволяет "примонтировать" пакет без необходимости выполнения распаковки, что экономит дисковое пространство, допускает атомарные изменения и делает содержимое пакета мгновенно доступным. При этом пакеты distri, как и в классическом формате "deb", содержат только отдельные компоненты, связанные зависимостями с другими пакетами (библиотеки не дублируются в пакетах, а устанавливаются как зависимости). Иными словами, distri пытается совместить гранулированную пакетную структуру классических дистрибутивов, таких как Debian, с методами поставки приложений в форме монтируемых контейнеров.
Каждый пакет в distri монтируется в свой каталог в режиме только для чтения (например, пакет с zsh доступен как "/ro/zsh-amd64-5.6.2-3"), что положительно влияет на безопасность и защищает от случайных или злонамеренных изменений. Для формирования иерархии служебных каталогов, таких как /usr/bin, /usr/share и /usr/lib, применяется специальный FUSE-модуль, объединяющий содержимое всех установленных SquashFS-образов в одно целое (например, каталог /ro/share предоставляет доступ к подкаталогам share из всех пакетов). Пакеты (https://repo.distr1.org/distri/jackherer/docs/package-format...) в distri принципиально избавлены (https://michael.stapelberg.ch/posts/2019-07-20-hooks-and-tri.../) от вызываемых в процессе установки обработчиков, а разные версии пакета могут сосуществовать друг с другом, поэтому становится возможным распараллеливание установки пакетов.
Предложенная структура ограничивает производительность пакетного менеджера пропускной способностью сети, через которую загружаются пакеты. Непосредственно установка или обновление пакета выполняется атомарно и не требует дублирования содержимого. Конфликты при установке пакетов исключаются так как каждый пакет связывается со своим каталогом и в системе допускается наличие разных версий одного пакета (в сводные каталоги подключается содержимое каталога с более свежей ревизией пакета). Сборка пакетов также осуществляется очень быстро и не требует установки пакетов в отдельное сборочное окружение (в сборочном окружении создаётся представления необходимых зависимостей из каталога /ro).
Поддерживаются (https://repo.distr1.org/distri/jackherer/docs/rosetta-stone....) типовые команды управления пакетами, такие как "distri install" и "distri update", но вместо информационных команд можно применять штатную утилиту "ls" (например, для просмотра установленных пакетов достаточно вывести список каталогов в иерархии "/ro", а для того чтобы узнать в состав какого пакета входит файл, посмотреть куда ведёт ссылка с этого файла).Предложенный для экспериментов прототип дистрибутива включает около 1700 пакетов (https://repo.distr1.org/distri/jackherer/pkg/) и готовые установочные образы (https://repo.distr1.org/distri/jackherer/img/) с инсталлятором, пригодные как для установки в качестве основной ОС, так и для запуска в QEMU, Docker, Google Cloud и VirtualBox. Поддерживается загрузка с шифрованного дискового раздела и набор типовых приложений для создания рабочего стола на базе оконного менеджера i3 (в качестве браузера предлагается Google Chrome). Предоставляется (https://repo.distr1.org/distri/jackherer/docs/building.html) полноценный инструментарий для сборки дистрибутива, подготовки и формирования пакетов пакетов, распространения пакетов по зеркалам и т.п.
URL: https://michael.stapelberg.ch/posts/2019-08-17-introducing-d.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=51407
В Slax уже было.
> Для формирования иерархии служебных каталогов, таких как /usr/bin, /usr/share и /usr/lib, применяется специальный FUSE-модуль, объединяющий содержимое всех установленных SquashFS-образов в одно целоеВот же дурило. Хорошо будет если система до этого FUSE загнётся в лагах.
Это эксперимент. Если он пойдет дальше, можно и в ядро лезть
возможно я не так понял, но как это поможет? Поднимать систему, если проблема возникла до объединения и у тебя россыпь squashfs файлов, может быть увлекательно
Лучше б nix или guix поконтрибьютил - идеальные в плане задумки, малопригодные в плане реализации.
>специальный FUSE-модульМожно было бы и в ядро внести. Fuse же имеет отвратную производительность.
Потому и экспериментальный. Когда устаканится API (и вообще станет понятно, что оно нужно, что не факт) - тогда можно и в ядро.
> Fuse же имеет отвратную производительность.Зажр^W Дожили. Как бы не шустрее 8 летнего, неплохого (пусть и консумерского) SSD – "отвратная производительность".
Плюс, туда завезли splice, плюс опять же, возможность в собственном "дистре" использовать патченую версию FUSE с возможностью проброса fd (т.е. чтение будет без FUSE-прослойки, которая возьмет на себя роль лишь транслятора путей)Ну и еще определенную роль играет тот факт, что, к сожалению, не все могут быть анонимами опеннета и сходу выдавать правильный код и доведенный до ума концепт
> Over the last year or so I have worked on a research linux distribution in my spare time.поэтому простым неанонимам может быть намного удобнее экспериментировать в Go и юзерспейсе :(
Задумка интересная. Сидя из-под i3, хочу пожелать Майклу Штапельбергу счастья, здоровья и успехов в его новом проекте.
Присоединяюсь. Человек, который сделал такую охренительную штуку, как i3wm, говна не сделает
Присоединяюсь.
Аналогично
поясните языком попроще - это лучше nix или нет? Что там что тут есть возможность держать разные версии одних и тех же пакетов в системе, в зависимости от зависимостей. Только у nix еще можно, при желании, ставить вот это вот все от пользователя. Ну и работает менеджер пакетов благодаря этому хоть на nixos, хоть на демьяне, хоть на раче
> поясните языком попроще - это лучше nix или нет?это как Slax старых версий
причём в slax можно было пакеты через httpfs монтировать, не скачивая, что ещё больше экономило место
> httpfsИ такая FS есть? O_O
Вообще под таким названием есть две fs. Есть httpfs которая про http, и которая заброшена уже 13 лет. Есть Hadoop HDFS over HTTP, которая так же именуется httpfs. Подозреваю что выше имелась в виду заброшенная 13 лет, а не расширение хадупа
Благодарю!
> заброшенная 13 лет...Не удивительно, это даже в теории страшно звучит и совсем не представляется как это может надёжно и быстро работать.
А главное зачем?
Я помню, что даже тыкал в нее палочкой, правда когда она еще была живая, году в 2005, наверное. Зачем? По приколу :-D Монтируешь себе distfiles для Генты и оно оттуда берет файлы. Но оно работало так себе.
> Я помню, что даже тыкал в нее палочкой, правда когда она еще
> была живая, году в 2005, наверное. Зачем? По приколу :-D Монтируешь
> себе distfiles для Генты и оно оттуда берет файлы. Но оно
> работало так себе.Я помню, лет 8 назад, узнал про ftpfs и пробовал это использовать, но оно то зависало, то оборвалось.
Потом узнал что любой ФМ (дельфин) может отобразить ФС фтп-сервера и это было более удобнее, надёжнее и быстрее.
Но о таком как httpfs извращении я даже не представлял...
curlftpfs я много лет использовал для заливки бэкапов на 100 гигов, которые Хецнер выделяет под хранение бэкапов при аренде сервера. Отказался так как что-то в нем сломалось и порой файлы стали битые заливаться, сейчас отказался от Хецнера, потому и curlftpfs стал не нужен.
Кроме sshfs как тогда так и сейчас, другие *fs просто игрушки. :-)
К сожалению Хецнер не давал в те годы, когда я его использовал, sftp/scp на хранилище, только ftp или smb. Использовать smb для бэкапа с линуховых серверов это совсем уж какой-то дурдом, по этой причине юзал curlftpfs.Да, помимо sshfs еще davfs2 не игрушка, а нормальный инструмент, монтирую им свое хранилище юзающее Nextcloud.
> поясните языком попроще - это лучше nix или нет?Это по-другому. Есть свои недостатки, типа /usr/bin в fuse, есть свои достоинства - squashfs, меньше места - быстрее запуск приложений на медленных дисках, скорость работы самого менеджера и т.д.
В никсе какая-то воспроизводимость, декларативность, сложнааа. А тут всё по-мужицки и на Go.
> и не для соседа дяди Пашиа вот это обидно было
> Именно по этой причине линукс никогда не станет мейнстримом на десктопах.предлагаю каждому опеннетовцу сделать свой дистр винды. а ещё лучше 14. тогда винда никогда не станет маинстримом
> Чтобы вирусописатели переключились с венды и мака на линукс?зачем нужны вирусы когда есть куча дыр безопасности абсолютно во всём? зловреды без проблем проникают, а про взлом на автомате от китайских ботов я вообще молчу
> зловреды без проблем проникаютПогоди. Если не заметил, по-умолчанию брандмауэры винды и линукса работают принципиально по-разному: в линуксе стремятся никого не впускать, а в винде -- никого не выпустить. Дыры безопасности есть и там, и там, а вирусня на практике только в винде. Поэтому касперские и прочие не пытаются продавать свои ширпотребы линуксоидам.
Но опять-таки, оставайся в винде. В линуксе "дыры безопасности", а еще "много дистров", а еще нет GTA5 и фотошопа. Я страдаю на линуксе. А винда - твой выбор.
Файервол Windows работает в обе стороны, так, по умолчанию блокируются ICMP-запросы. Просто на потребительских устройствах устанавливаются, как правило, сетевые клиенты, а этот ваш гнилюникс — для серверов.Касперские и прочие успешно продают свои поделия для гнильюникса корпорастам и мученикам-бюджетникам. Но ClamAV — выбор мамкиных хакеров.
P.S.: Простите, если недостаточно токсично. Я новичок.
> P.S.: Простите, если недостаточно токсично. Я новичок.Ты сможешь лучше, старайся!
P.S. отключать по дефолту ICMP это за гранью добра и зла. А еще попило крови мне и некоторым знакомым в своё время.
они исправляются - полностью он был отключен только в XP sp2 (когда и появился примитивный файрвол по умолчанию)
В современных версиях он зачем-то разрешен - из локальной сети. Не переживайте, в линухах рано или поздно - скопипастят и эту глупость.
заметно что новичок - в it в том числе.Достаточно токсично, только безграмотно, уровня опеннета. Файрвол в винде по умолчанию ничего на out не блокирует, и уж такие-то вещи - не мешало бы знать. Он до фига всего блокирует на in, точнее, имеет включенный по умолчанию deny и разрешает лишь отдельные протоколы и приложения, в том числе, зачем-то, да, блокируя внешний icmp (привет, неработающий pmtud) - что как бы говорит нам то ли о грамотности индусов, его разработавших, то ли о качестве виндового стека (возможно дело не в грамотности, а в въевшейся в подкорку истории с ping-of-death, и хрен с ним, с ip протоколом, шибко умными придуманным, зато безопастно!)
в типичном линухе никакого "файрвола по умолчанию" нет вообще. Удивительный факт, да? Исключением является нелюбимый шк...запрещенными на опеннете персонажами redhat и его клоны, по умолчанию блокирующий вообще все подряд, и требующий нетривиальных действий чтобы хоть что-то работало (поскольку научить им все постинсталл-скрипты оказалось непосильной задачей). Ну или тривиальных - сноса всей защиты нафиг, это-то каждый девляпс умеет. И, возможно, еще suse, которой раньше даже ssh надо было не забыть отдельно включить (опять ниасилен постинсталл - зачем я по их мнению ставил sshd, если он заблокирован - загадка), но я ляпов и прочих новых поделок не пользователь.
> даже ssh надо было не забыть отдельно включитьТребование руководящих документов )))
И да, в yast2 включается влёт.
>> даже ssh надо было не забыть отдельно включить
> Требование руководящих документов )))
> И да, в yast2 включается влёт.если разглядеть мелкую-мелкую нажимаемую фигнюшку в громадной простыне настроек в процессе установки - то да, достаточно попасть в нее мышью.
Ну а если не разглядел, а с физическим доступом сложности - то как хочешь, так и крутись.Но корпорация зла - microsoft, смотри не перепутай!
> Файрвол в винде по умолчанию
> ничего на out не блокирует, и уж такие-то вещи - неEvent ID 4226
> мешало бы знать.
> Файервол Windows работает в обе стороныВ десктопе. В сервере выдает что-то типа "Вы в своем уме" блокировать приложения, уже попавшие на компьютер?
экшперт опеннета, ага.
Автору хочется обкатать идею: пакеты иммутабельные и монтируются прямо без распаковки.Если зайдёт, можно и /nix/store на подобный принцип перевести.
жду лайв сд
> Пакеты в distri принципиально избавлены от вызываемых в процессе установки обработчиков (нет хуков и триггеров)Точно? "implement kernel hook" https://github.com/distr1/distri/issues/12
> а разные версии пакета могут сосуществовать друг с другом
Можно установить несколько версий libfoo-dev? А как при сборке выбирать (pkg-config)?
>несколько версий libfoo-devТут первичная сущность это не библиатека а прикладной пакет. Так что такая задача как "несколько версий libfoo-dev" не имеет смысла.
Во-первых, "библиОтека". Во-вторых, человек весьма резонный вопрос поднял -- поскольку Вы явно не в курсе, давайте поясню.Часть библиотек, предназначенная для разработки (в основном заголовки), берётся не из сферического вакуума, а из библиотечных или вовсе прикладных пакетов, где произрастает. Соответственно вне зависимости от того, есть ли нарезка пакетов или нет, допустимы ли множественные версии или нет -- при желании использовать данный дистрибутив для сборки неизбежно возникает поставленный вопрос: откуда именно будет тот pkgconfig-ный файлик, по которому подхватится _одна_ конкретная версия библиотеки (варианты исполнения могут быть разные, но на линкере они все сойдутся в один).
Исключение сходу вижу только одно: не использовать такой дистрибутив для сборки таких пакетов, а собирать их в некотором смысле "кроссом" с того же дебиана. Годится ровно на экспериментальной стадии, дальше начинаются свистопляски с разъездами версий и ограничениями [политики] базового дистрибутива.
Про хуки и триггеры туда же -- далеко без подобных сущностей не уедешь при построении _и_ сопровождении сколь-нибудь универсального и практически полезного дистрибутива в более чем две руки, по опыту (те же триггеры нужны редко, но больно).
Ну и про скорость fuse уже все желающие будто высказались -- остаётся прибавить, что здесь в чистом виде противоположность к "лучше час постоять, потом за пять минут долететь", причём фундаментальная -- вынос слойки в ядро поможет снизить накладные расходы, но вовсе не обнулить их.
Тем не менее идея занятная, хорошо, что новость долетела :-)
С fuse интересно, зачем вообще нужна такая прослойка. В NixOS вроде хватает симлинков. Возможно, тут в итоге на лету будет генерироваться лишь малая часть, как раз для разруливания версий библиотек.
>Вы явно не в курсе, давайте поясню.Я тоже поясню. Описанная в новости идея не то, что не нова, она стара. Целое семейство дистрибутивов живет подобным образом c 2003 года под кодовым названием Puppy Linux. Семейство это большое, потому, что идея подобной слоености и модульности понравилась многим. Мейнстримные снобы воротили нос и говорили: маргинальщина. Но нам было все равно. Идея прекрасна, дистрибутивы просты, легки и все в них есть, а вот снобы отсутствуют напрочь. Нет у них и systemd.
Как выяснилось, в подобной системе можно и нужно сидеть root'ом. Это реально удобно! А все потому, что основа на squash с ro обеспечивает гарантию от ошибок. Модули (целые пакеты, даже метапакеты) ставятся ro-слоем выше основы, добавляя и замещая то что есть в ней. Так, вы можете подключить dev-пакеты, библиотеки и компилятор на время компиляции, а потом отключить модуль. Можете подключить, не знаю, модуль со всеми QT5 библиотеки и отключить их потом за ненадобностью. Все изменения rw сохраняются в именованной вами папке, которая на самом высоком слое этого слоенного пирога.
В этой связи может быть один дистр и несколько save-папок: которые преображают дистр до неузнаваемости (это не home папки, это слои сохраненных сессий, перекрывающие сверху любые файлы низших слоев). Песочницы, модели для сборки, эксперементальные дрова к железу -- все может лежить в разных save-папках (ранее это были save-файлы, которые появились изначально для возможности жить Puppy на флешках с fat32 и дисках с NTFS).
Очень распространенным явлением у дистров puppy стало "паразитирование" на репах других дистрибутивов при сохранении оригинальной философии (структуры). Бинарно-совместимые со Slackware, Ubuntu, Debian, Arch pupplet'ы получили возможность выкачивать пакеты напрямую из родительских реп со всеми зависимостями. Есть ли проблемы о которых Вы пишете? Я не заметил.
Касаемо разных версий при сборке: вы просто создаете dev-модуль для конкретной сборки, подключаете его на лету, для других версий у вас другие модули. Подключение/отключение занимает секунды. И все. Есть ли проблема с кликом на мета-пакет, для его подмонтирования и таким же кликом для отмонтирования? Нет.Итак, идея не нова. Более того, есть уже дистры, которые давно реализуют все вышеназванное и стоят особняком, то есть не относят себя к puppy, живя своей жизнью. К примеру, Porteus. С runit на борту и модульно-слоенной системой он просто летает! Установка пакета занимает скачивание и монтирование. Как описано в новости. Porteus совместим с репами Слаки. И никакого fuse!
Я поддерживаю автора прекрасного i3. Пусть он возьмет то, что есть и сделает лучше. Barry Kauler, создатель puppy, тоже не стоит на месте и развивает новые идеи в своем Easy Linux, добавляя туда в частности, ядерные контейнеры в два клика и прочее.
Такие дела.
Fiat Linux!
Vivat Linux!!!
Это получается, что при загрузке системы оно будет монтировать все эти пакеты? Интересно, насколько влияет подобный подход на скорость загрузки.
197(8)х editionЭто получается, что при загрузке бинарнарного файла оно будет грузить с диска код программы в память? Интересно, насколько влияет подобный подход на скорость загрузки.
> 197(8)х edition
> Это получается, что при загрузке бинарнарного файла оно будет грузить с диска
> код программы в память? Интересно, насколько влияет подобный подход на скорость
> загрузки.Это получается, что при традиционном отображении (mmap) файла из ext4 -- PTE в заносится дескриптор блока на диске? И процессор сразу по SATA читает данные в кеш, минуя ОЗУ?
> Каждый пакет в distri монтируется в свой каталог в режиме только для чтения (например, пакет с zsh доступен как "/ro/zsh-amd64-5.6.2-3"), что положительно влияет на безопасность и защищает от случайных или злонамеренных изменений.Как же задолбали этой навязанной безопасностью... В итоге, чтобы что-то поменять в системных файлах хотя бы для теста, придётся делать значительно больше действий. Да, это "неправильно", но иногда вполне даже требуется. В итоге и оказывается, что в той же Windows у тебя значительно больше контроля над системой, без кучи всяких условностей, которые тебе на локальной машине нафиг не нужны (кто .deb пакет собирал по честному, без checkinstall?).
> Пакеты в distri принципиально избавлены от вызываемых в процессе установки обработчиков (нет хуков и триггеров), а разные версии пакета могут сосуществовать друг с другом, поэтому становится возможным распараллеливание установки пакетов.
Сильно, конечно. Но в реальном мире это, скорее всего, сломает немало юзкейсов.
Слаку, кажется, еще никто не запрещал, контролируй сколько душе угодно.
Если deb package собирать правильно (в чистом окружении и т.п.), то нужно пройти тот ещё квест. Сами разработчики Debian говорят о сложной устаревшей системе сборки.Куда проще собрать rpm пакет. Spec файл пишется в два счета, никаких подводных камней. Далее одной командой отправляем его mock и на выходе получаем готовый пакет.
> Куда проще собрать rpm пакет. Spec файл пишется в два счета, никаких подводных камней. Далее одной командой отправляем его mock и на выходе получаем готовый пакет.*Смех в pacman*
Это в чруте или нет? Если нет -- можете смеяться дальше... над собой.Потому что даже моск -- это всё-таки хоть и кривая, но изолированная сборка. И у дебиана давно есть pbuilder.
А кто не понимает, зачем фарш готовить в чистом помещении -- тому уже мало что поможет.
> А кто не понимает, зачем фарш готовить в чистом помещении -- тому
> уже мало что поможет.Я не понимаю. Как помещение могло до такого состояния докатиться? Неужели пакетный менеджер допустил?
Пакетный менеджер тут ни при чём, разные приложения и библиотеки используют множество различных систем сборки, autotools, cmake, ant, meson, setuptools и т. п. они не всегда правильно и адекватно настроены авторами приложения или сами по себе не всегда правильно могут найти зависимости. Поэтому для корректности _их_ работы (а не пакетного менеджера) сборку обычно производят в чистом окружении, без лишних пакетов, ненужных для этой сборки.
Когда учился в школе, ходил на курсы "Оператор ПЭВМ". Там же занимались очень взрослые тётеньки. Когда требовалось отредактировать текст, они сперва стирали символы на экране, а потом на том месте печатали новые -- со словами «мало ли чего эта ЭВМ неправильно подумает». На БК-0010 можно было просто печатать буквы поверх имеющихся, поэтому мы с пацанами втихаря над ними посмеивались. ИЧСХ, теперь при наборе текста по умолчанию приходится делать как те тётеньки.
https://wiki.archlinux.org/index.php/DeveloperWiki:Building_...
Костыль, да.
> Если deb package собирать правильно (в чистом окружении и т.п.), то нужно пройти тот ещё квест.pbuilder сильно упрощает прохождение. Хотя согласен, без курения вики его осилить затруднительно.
> Spec файл пишется в два счета, никаких подводных камней.
Видал я таких, пишущих спеки в два счёта. Потом замучаешься последствия разгребать.
Таких как Distri раз два и обчёлся. Если не пользоваться Ubuntu (которая apparmor всё и вся запрещает) или любым из RedHat (анологично Убунте), то все остальные дистры разрешают делать что угодно.
> кто .deb пакет собирал по честному, без checkinstall?Вы что, издеваетесь? .msi собирали? Соберите, затем будете рассказывать про "больше контроля над системой" в виндах.
А так -- почти двадцать лет собираю rpm-ы, в целом это оказалось не так страшно, как виделось до изучения вопроса (спасибо Володе Бормотову, опять же). И с deb-ами тогда всё было сильно более замороченное-развесистое, уже давно стало возможно оформлять их попроще.
Ну и вишенка на торте: а теперь найдите/попробуйте "checkinstall" для windows. :)
> Ну и вишенка на торте: а теперь найдите/попробуйте "checkinstall" для windows. :)Когда-то, "в глубоком детстве", был такой:
-rw-r--r-- 1 69392 июн 3 1997 SYSDIFF.EXE
Конечно-безусловно, умел и мог не всё и не всегда.
> кто .deb пакет собирал по честному, без checkinstall?Всегда так делаю. Вот только недавно решил для разнообразия воспользоваться checkinstall и сразу же обломался: не пашет у него fstrans в buster. Так что аккуратно, без риска угробить систему, пакет им не собрать.
А loop-устройств-то хватит? Да и сомнительное удовольствие -
иметь с несколько тысяч записей в mtab
Идеи ради можно и потерпеть!
> Пакеты в distri принципиально избавлены от вызываемых в процессе установки обработчиков (нет хуков и триггеров)Так, а если нужно пользователя для устанавливаемого сервера добавить? Это как теперь делаться будет?
Как в старые добрые - useradd
Зачем? Пусть все от рута работает, нефиг красивую идею ломать!
Конечно же добавить пользователя можно только через ж^W^W единственно верным способом, а не, например, добавлением в манифест пакета
USERS= anonim_openneta
GROUPS= anonim, petrosyan, expert
И кто же будет этот манифест претворять в жизнь, если хуков и триггеров нет? Или всё-таки есть?
> И кто же будет этот манифест претворять в жизнь, если хуков и
> триггеров нет? Или всё-таки есть?https://michael.stapelberg.ch/posts/2019-07-20-hooks-and-tri.../ (многолетний мейнтейнер дебиана конечно же не подумал о таких вещах и только после упоминания на опеннете задним числом оформил постинг )))
> If the hook is not specific to the package, it can be moved to the package manager. The desired system state should either be derived from the package contents (e.g. required system users can be discovered from systemd service files) or declaratively specified in the package build instructions—more on that in another blog post.
> This turns hooks (arbitrary code) into configuration, which allows the package manager to collapse and sequence the required state changes.А вообще, лучше почитать его определение хуков и триггеров, а не гадать на кофейной гуще перевода.
Странно, что системд за такую же идею тут хейтят.
> Странно, что системд за такую же идею тут хейтят.Какую "такую же"?
Оно теперь что, еще и пользователя добавляет автоматом?
>> Странно, что системд за такую же идею тут хейтят.
> Какую "такую же"?Декларативную.
> Оно теперь что, еще и пользователя добавляет автоматом?
И хорошо, что хуки не вызываются в процессе установки. Это не мешает для каждого пакета иметь конфиг этих самых хуков, который можно вызвать/применить в любое время
ostree
gobolinux?>увеличения производительности систем управления пакетами
>написан на языке Go/0
еще бы на джаваскрипте написал бы
>Применение SquashFS
что там с кол-во loop девайсов? а почему нельзя сделать FUSE для прямого чтения из архивов
>экономит дисковое пространство
можно взять и другие фс со сжатием
>допускает атомарные изменения
нет, скорее оно обеспечивает невозможность заменить (отмонтировать) пакет, пока им кто-то пользуется
>Каждый пакет в distri монтируется в свой каталог в режиме только для чтения (например, пакет с zsh доступен как "/ro/zsh-amd64-5.6.2-3"), что положительно влияет на безопасность и защищает от случайных или злонамеренных изменений.
ага, будто сейчас у юзера-не-рута есть возможность записи в исполняемые бинарники / а у этой поделки нельзя будет подменить сквош-файлы
>Конфликты при установке пакетов исключаются так как каждый пакет связывается со своим каталогом и в системе допускается наличие разных версий одного пакета
гентушники орут в голос, а потом плачут. Конфликты библиотек, когда либа A хочет либу C мажорной версии X, а либа B хочет либу C мажорной версии Y и никак иначе (и обе либы A и B "юзаются"/крашатся в одной проге) - это же хлеб и много соли гентушников. Все конечно решается пересборкой системы (и ликвидацией одной из версий либы C), но в этой поделке будет жесть
TCL постучал Debian и сказал будь как я. :D
ПМ на языке с принудительным скачиванием зависимостей - это хипстоССЗБ.
Ну, поддерживать пакеты в актуальном состоянии эта поделка точно не помогает (не успело родиться, а на две трети протухло):https://repology.org/repositories/statistics#distri
А вообще выглядит так как будто накладные расходы при инсталляции пакетов (распаковка, например) просто перенесены всё время эксплуатации системы.
А атомарные обновления уже не новость - кто только их не умеет.
> Ну, поддерживать пакеты в актуальном состоянии эта поделка точно не помогает (не
> успело родиться, а на две трети протухло):
> https://repology.org/repositories/statistics#distrihttps://github.com/distr1/distri/graphs/contributors
И правда, раз не помогает поддерживать 430 пакетов (а они там наверняка именно уже для "продакшона", а не тестирования и экспериментов с пакетником) в 1 лицо – значит поделка 🙄
> И правда, раз не помогает поддерживать 430 пакетов (а они там
> наверняка именно уже для "продакшона", а не тестирования
> и экспериментов с пакетником) в 1 лицо – значит поделка 🙄См. http://altlinux.org/robots на тему поддержки и количеств... там практик писал, у которого пакетов -- сотни, тысячи и десятки тысяч по разным "полочкам".
Squashfs это конечно хрень, уж распаковать-то можно разок... ну и fuse бы да, на что-то поменять, а в остальном да, прикольно, в принципе.
Вместо того, чтобы один раз потратить время на распаковку - нужно каждый раз в рантайме тратить время на монтирование и собирание единого дерева каталогов в /usr/ ?Я еще идею придумал! Вместо того, чтобы использовать скомпилированные бинарные программы - будем компиляторовать исходники при каждом запуске! А то компилируется долго...
>Для формирования иерархии служебных каталогов, таких как /usr/bin, /usr/share и /usr/lib, применяется специальный FUSE-модульЗачем fuse, когда есть AUFS? Кто что думает?