From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=unavailable autolearn_force=no version=3.4.1 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udalov.online; s=mail; t=1738333217; bh=rL84Xg6BpNK+IY85BCnaTaQhCDuI5OpA5WqEUJFqcxU=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=Lwp4/ulNOIFwwtUOGgOR6Swn+m8oQCDQtycByTCEk3B/PQaMSguPn+MAP4QdX8+7n 7UXZLsjKcIP4CSnyfycJSLlI8JHhZSoa4D2L+1QIW/+j85yOpgzNdlrqNse0SO+5VR xAg3oVHT8qB8jMlVeljTMBI8s8LO1Yp87mPYP5UY= Authentication-Results: mail-nwsmtp-smtp-production-main-77.klg.yp-c.yandex.net; dkim=pass header.i=@udalov.online Message-ID: Date: Fri, 31 Jan 2025 20:20:15 +0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Arseny Maslennikov , Distributions development References: <14B322BC-80D3-4CD1-AE0B-80241A4ED46B@basealt.ru> Content-Language: en-US, ru-RU From: =?UTF-8?B?0JTQvNC40YLRgNC40Lk=?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel-distro] =?utf-8?b?0JDRgtC+0LzQsNGA0L3Ri9C5INC+0LHRgNCw0Lc=?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2025 14:20:21 -0000 Archived-At: List-Archive: Согласен что каждый решает какой механизм использовать, но если оно не мешает друг друга почему бы и его не развивать по /тихоньку/? На мой взгляд это только в плюс пойдет сообществу ALT. Что касается количества слоев ostree внутри машины, по умолчанию их всегда два, акутальный и предыдущий. Есть возможно "закрепить" состояние и тогда будет еще один слой, зависит от использования. Боюсь ошибиться но timeshift в регулярном образе максимально будет хранить около 20 бэкапов для @ и @home, но конечно это все можно настроить. Я это скорее к тому что избыточность определяет пользователь и дистрибьютор и если оно избыточно - значит таков был план ) Вижу здесь избыточность у самой технологии только в размере базового образа, но тут есть куда стремиться и как оптимизировать доставку, я пока не достиг полного понимания в этом вопросе. 31.01.2025 19:51, Arseny Maslennikov пишет: >> 31 января 2025 г. 14:30:37 GMT+04:00, "Дмитрий" пишет: >>> Здравствуйте, хотел бы обсудить реализацию атомарного образа для домашних систем. >>> Описание текущего состояния проекта: ссылка > On Fri, Jan 31, 2025 at 03:10:44PM +0400, Евгений Синельников wrote: >> Дмитрий, >> >> спасибо за подробное описание, внятное изложение и полезные ссылки. >> >> Думаю, эту историю нужно "переварить". Хотелось бы понять и осмыслить >> куда мы движемся и общий прогресс вместе с нами куда движется. В каком >> смысле оказывается, в этом случае, существенной роль сопровождающего >> пакетной базы - то есть, мэйнтейнера? Как не разорваться между этими >> мирами - пакетным и контейнерным? > Они концентрически вкладываются друг в друга. Пакеты формируются и > сопровождаются по-прежнему, а из них уже (для тех, кому так удобнее) > складываются образы. > > Вообще, насколько я понимаю, всё это движение за распространение ОС в > образах не пытается совсем вытеснить пакеты (кроме фанатиков от GNOME OS > people — тот же человек-colord Richard Hughes успел 6 лет назад нагло > объявить[1], что packagekit устарел — будто он в одно лицо это решает! — > но и фиг с ними), а предлагает альтернативные механизмы обновления и, > возможно, установки. > Лучше эти механизмы, чем существующие, или хуже, каждый решает сам... > > Они говорят: мол, чем держать btrfs + timeshift, плодить там сложность и > хранимую избыточность, лучше перетащить хранимую избыточность в > инфраструктуру доставки + установки, на тот же уровень, где apt и rpm, а > также упростить эту инфраструктуру, ещё увеличив эту хранимую > избыточность. (Все ж согласны, что домашнему пользователю терабайтный > диск нужен не для лично ценных данных, а для бесконечных логов и > доккерных слоёв. %D %D %D) > > Главный, imho, аргумент в пользу всего этого — R/O /usr надёжнее, чем R/W > /usr. > > Есть ещё те, кто и так собирает герметичную ОС-прошивку и никогда не > делал никаких распространяемых независимо пакетов, вроде yocto. Мы тоже > не про них. > > [1] https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > >> По уму, кроме таких артефактов, как gear-репозитории, rpm-пакеты, >> apt-репозитории и iso-образы, уже имеются docker/podman, flatpak (и >> др.) образы... >> А тут мы получаем еще образы, и тоже через генерацию докерных чрутов, >> при этом rpm-базу зачем-то им выпиливаем... >> https://github.com/alt-gnome/alt-atomic >> Хотя, в целом, понятно зачем - используем генерацию docker-образов >> вместо оригинальной. > Я не всё понял в первом тексте Дмитрия (много как buzzwords, так и > совсем непонятных утверждений), но удалось выцепить идею применять > Docker при подготовке ОС для настольной персоналки, а то и в процессе её > использования. > > Конкретно Docker для этого не подходит, он не предназначен для > применения в самосопровождающейся инсталляции, т. е. с отсутствующим > сисадмином. > > Да и из примера по ссылке не очень понятно, что Docker даёт такого, чего > нельзя добиться без него. > >> В общем, спасибо, интересная тема. Но концептуальные детали нужно >> вычитывать. Видимо, из первоисточников. Какие посоветуете? >> >> PS: схема доверенной сборки контейнеров на сборочнице у нас, кстати, >> прорабатывалась. Как для iso-образов, так и для docker-контейнеров. >> Нужны добровольцы для развития и отладки этой истории. Особенно, и в >> первую очередь, в рамках сообщества. > Да, конечно, мы всегда рады предложениям. Я к image based updates, > особенно в свете альта как операционки общего назначения, отношусь > скорее скептически, но если есть желающие развивать такой путь > и желающие этим пользоваться — почему нет. :)