MiniOS 3.3.4: Обновленный дистрибутив для съемных накопителей

Давайте будем честны: рандомный пользователь не будет читать инструкцию и будет ставить с помощью Rufus из винды:)

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

Вот-вот, а некоторые ещё вопрошают, мол, «зачем всё упаковывать в образ, где это видано, чтобы не было интернета».

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

Нетушки, давайте красноглазить. Рандомный пользователь именно миниос скорее будет хотя бы отчасти луноходом, чем чистым виндузятником. Хотя бы потому, что вся эта специфическая тема интересна прежде всего тем, кто уже в теме более общей. А виндузятнику только подавай Гейшит Инфаркт и Хонк-Хонк-Стар, ну или что там из игр нынче захватило умы, зачем ему миниос?

У нас для этих целей есть статистика. Более 50% посещений сайта именно с Windows, а оставшаяся доля — далеко не Linux, а в основном мобильные устройства. Да и в чате пишут чаще всего про установку из Windows. Пользователи Linux тоже не любят читать инструкции и чаще всего жалуются на невозможность сохранить изменения после записи различными графическими оболочками над dd:)

Ну посещение сайта это такое себе мерило... обещать, как известно, не значит жениться. Хотя бы загрузки надо измерять, а то мало ли. Скачало 100 виндузятников и 500 линуксоидов, из них 50 виндузятников пожаловались на установку, а 20 линуксоидов вопили про dd — вот и складывается превратное впечатление, что виндузятников в 2.5 раза больше.

И ещё пара вопросов по эксплуатации.

1. На сайте сказано: «с возможностью расширения системы до Ultra функциональности и даже больше за счет заранее подготовленных модулей, которые доступны на нашем сайте.» А где именно они скачиваются? Я пока вижу только вариант вынимать их из других образов. А где они по отдельности лежат?

2. Про persistence. Вот я взял, и ради эксперимента попробовал установить vim. Сначала потребовалось обновить данные apt, потом поставились два пакета. И после перезагрузки он по-прежнему в системе. Вопрос: сильно ли я нагадил, установив программу штатными средствами, а не через модуль? Насколько стандартная установка в целом совместима с особой технической основой системы?

Статистика есть и по загрузкам. За месяц скачали:

• 11 217 — Windows
• 3 190 — Android
• 2 999 — Linux
• меньше 1000 в сумме — остальные системы.

По моему личному мнению, дистрибутив чаще скачивают те, кому Linux на десктопе не нужен в качестве основной системы, что вполне логично, так как он для съёмных устройств.

У нас для этих целей есть статистика

У всех «есть статистика»... ;)

Но это просто ужас какой-то, что вытворяет с ней User-Agent Switcher на некоторых сайтах, когда я захожу туда с Forefox под Linux... ;) :))

2 999 — Linux и меньше

Из них 3 — я 😊

1. Был в планах репозиторий модулей (уже нет), эту формулировку нужно исправить. Модули для Puzzle в полной его версии, модули между редакции друг с другом несовместимы (отличается софт в слоях).
2. Желательно, конечно, не комбинировать способы установки, но это поддерживается. Поддерживается, причём, во всех редакциях, нужно только в других изменить в minios.conf SYSTEM_TYPE на puzzle. Нежелательно комбинировать только из-за недостаточного отклика по этой фиче. При лабораторном тестировании всё работает как часы, но мало ли…

Вы - погрешность:) Любителей менять User-Agent не так уж и много:)

Модули для Puzzle в полной его версии, модули между редакции друг с другом несовместимы (отличается софт в слоях).

А вот это уже не очень хорошо. Потому что изначально я так понял, что как раз-таки можно модули туда-сюда перебрасывать, добавляя целыми пачками нужный софт.

Желательно, конечно, не комбинировать способы установки, но это поддерживается. Поддерживается, причём, во всех редакциях, нужно только в других изменить в minios.conf SYSTEM_TYPE на puzzle.

А вот я вим поставил, ничего не меняя. Чем конкретно моя ситуация отличается от ситуации, где я бы сначала изменил указанный параметр? Где грабли?

Любая редакция, кроме Puzzle, работает как обычная система. Если не создавать модули, можно спокойно устанавливать любой софт с apt. Проблемы возникнут только если после установки пакетов удалить какой-нибудь модуль. Удалить Firefox, например. Его физически не будет в системе, как и нужных ему библиотек, но в базе DPKG он с библиотеками будет числиться как установленный, что вызовет проблемы при установке пакетов, требующих эти библиотеки, в будущем. Установка SYSTEM_TYPE в puzzle позволяет отключать и подключать модули (база автоматически пересобирается, исходя из информации во всех модулях), используя при этом apt, но нужно это тестировать большому количеству пользователей, чтобы заявлять о надёжности.

Окей. Тогда у меня возникает логичный вопрос: а зачем нужно 6 редакций, если их модули не взаимозаменяемы? Ведь смысл модульности чего бы то ни было — именно в свободной комбинации стандартизованных частей. Поэтому выглядело бы более логичным сделать всего несколько редакций на базе некоторой стандартной основы + постепенно увеличивающегося количества аддонов, плюс и правда — репозиторий модулей, которые уже каждый будет скачивать самостоятельно. И более того, люди могли бы создавать свои модули под свои задачи (например, набор нужного для организации софта), с расчётом на установку в типовую конфигурацию. А как сейчас — выходит, что модули никакие не модули, а обычные детали, которые имеют смысл только для разработчика дистрибутива, облегчая ему жизнь, но никак не несут пользы собственно конечным пользователям.

модули между редакции друг с другом несовместимы (отличается софт в слоях).

Помнится, когда обсуждали MagOS, так разрабы заявляли, что можно запускать модули хоть в обратном порядке, на работоспособность это не повлияет. Вот это я понимаю ‘вылизанные’ модули:

В магос можно перевернуть всю сборку и загрузиться. Единственный файл который дублируется в двух модулях это файл который отвечает за дефолтный ДЕ. То есть при перевороте модулей и без параметра desktop= загрузится lxqt вместо kde.

Прочитал, по прежнему непонятно чем это отличается от обычного Debian live?

Как это раскондировать?

https://letmegooglethat.com/?q=base64 decode

отличается своей модульностью и гибкостью.

;)

6 редакций для разного стартового набора софта. Модули нужны для базового выбора необходимой функциональности, реализовано всё как луковица: если не нужен Firefox - удаляем модуль 06, если не нужен Xfce - удаляем модули 04-06, если не нужен Xorg и вообще мы планируем использовать систему исключительно в консоли - удаляем 02-06. Это удобно для админов, когда нужно сделать что-то для конкретной задачи.

Думаю, я всё-таки доделаю 4.0 не позже конца сентября, там будет уже 3 редакции. Minimum, Ultra и Puzzle пойдут под нож, а Maximum будет сильно переделана для целей администрирования. В чате уже выкладывал тестовые сборки, система готова на 99%.

У MagOS совсем другая философия и эти фокусы проще проворачивать из-за RPM. Там упор именно на модульность ради модульности, чего я делать не хочу. Я считаю, что лучше предоставить пользователю выбор того, что он хочет поставить в систему и как он будет это делать. Хочет использовать как классический дистрибутив - пусть использует. Хочет модули - дать понятные инструменты для создания и пусть сам делает модули любого ПО, а не только те, что предложили разработчики дистрибутива.

Вы - погрешность:) Любителей менять User-Agent не так уж и много:)

Я не погрешность! Я — недосягаемая высота!.. ;P :)))

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

00 - ядро
01 - минимальная консольная система с самыми важными тулзами
02 - иксы + какой-то маленький WM (вот тот же флуксбокс) + чуть-чуть утилит (простенький терминал)
03 - дополнительные консольные утилиты
04 - xfce
05 - дополнительные гуёвые утилиты
06 - файрфокс
07 и далее — крупные наборы программ (офис, гимп, сетевые приблуды и так далее), по возможности друг от друга не зависящие.

И эти модули должны быть одни и те же везде, а не свои у каждой версии. Вот и получится, что 00-02/03 даёт минимальную систему, 00-04/05 даёт полноценную графическую оболочку, 00-06+ даёт полный фарш, а начиная с 07 модули можно выбирать в произвольных сочетаниях и тупо закидывать на флешку по необходимости. Я могу развить эту идею пополнее, когда приду домой и посмотрю внутрь образов миниос.

Для реализации подобной схемы нужно усложнить модули: прописать зависимости модулей и создать их репозиторий, запретить установку софта стандартным менеджером пакетов и так далее. Какое-то время назад мы хотели реализовать что-то подобное, добавив экспериментальный Puzzle, но позже из-за трудоёмкости реализации и необходимости постоянной поддержки репозитория решили отказаться, как и от самого Puzzle.

P.S.: я очень ленив, поэтому всё автоматизирую, а историю с репозиторием модулей автоматизировать будет проблематично.

я очень ленив, поэтому всё автоматизирую, а историю с репозиторием модулей автоматизировать будет проблематично.

Как вариант, распространять только сборку Maximum, с максимальным набором модулей (приложений). Она по сути и будет этаким репозитарием.
А юзерам объяснить, что сборка Maximum «легким движением руки, может превращатся в элегантный» Minimum. Типа того, что выше написали.

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

Нет, не нужно этого всего. Нужно просто не разбивать отдельные идеи релизов на уникальные для каждого кейса модули, а сделать нечто усреднённое. Опять же, ядро системы должно укладываться менее, чем в 10 модулей, и для них можно чётко прописать в доках, например, что модули с 4 по 6 не работают без модулей с 1 по 3, и так далее. Типа, если удалил — ССЗБ. К дополнительным модулям зависимости можно прописать в описании, тем более если предполагать, что они по возможности будут или самодостаточны, или полагаться на «базовые модули». Итого в описании модуля будет написано, в худшем случае, что потребуется установить ещё 1-2. Это не сложнее, чем скриптом ставить систему на флешку.

Запрещать установку софта стандартным менеджером тоже не нужно. Потому что, как мне кажется, сценарий постоянной перетасовки модулей представляется крайне маловероятным. Скорее кто-то подберёт себе к «ядру» несколько нужных ему штук, кинет на флешку, и дальше будет так пользоваться годами.

А вот репозиторий дополнительных модулей это как раз идея на миллион, которую вы почему-то старательно закапываете. Вместо этого плодите релизы, которые, в общем-то, ничего особо нового не привносят; особенно сложно мне представить, кому может понадобиться вариант с голым флуксбоксом, а ведь на него тратились и труд, и время! Репозиторий не должен быть гигантским. Пары дюжин тематических модулей вполне должно хватить. Если кому-то надо будет на уровне «±2 программы» системой управлять, так он не по адресу пришёл.

Потому что вот что я сейчас вижу:

Скорость работы — отлично.
Простота установки — отлично. Ещё и флешка своих функций не теряет.
Persistence — просто отлично, совершенно прозрачно работает, вообще ничего делать не надо. Не знаю, как вы этого добились, но результат офигенный.
Внешний вид — совершенно замечательно (кроме темы флуксбокса).
Модульность — для галочки.

Но вот эту идею с модульностью надо довести до логического завершения. Комплектация «мини», «стандарт», «макси» — и сколько-то модулей сверху, уже по частным случаям. Там не должно быть всё на свете вообще, достаточно разумных подборок по разным темам. Скажем, графика: Gimp, Inkscape, Blender. Аудио-видео: Audacity, VLC, Pitivi, OBS. Восстановление данных и бекапы: clonezilla, photorec, ddrecsue, dvdisaster. И так далее. B вот человек ставит на обычную флешку какой-то релиз, кидает дополнительно пригоршню модулей, и больше об этом не вспоминает. У него дальше просто всё работает, а если и правда надо ещё что-то отдельное поставить или убрать, так пусть включает apt-get. К которому можно прикрутить окно-предупреждалку «с этого момента мы ни за что не отвечаем». Ну и нужно отметить, что заинтересованные люди (скажем, учебные организации) смогут делать свои модули чисто под свои задачи. Например, модуль «всё для R». И всё. Будет система на миллион.

И хранить в Maximum готовые пресеты наборов модулей - редакции, давая выбор в момент установки. Если что-то недоустановил, вставил флешку, добавил модуль и дальше работаешь. Для админов, как вариант, предусмотреть добавление на флешку своего файла сценария, который будет виден в выборе редакции.

PS. Тоже присоединяюсь к мыслям вслух и ни на чем не настаиваю…

Тут ведь штука-то в чём: модулями система набирается «крупными мазками», и такой набор по идее должен удовлетворять типовые потребности в разных сценариях использования. А для гранулярного контроля есть и работает стандарный APT. Т.е. по идее типовой манерой использования должен быть подбор модулей, наиболее близкий по содержанию к тому, что нужно, а если этого не хватило, то ещё кое-что по мелочи уже можно доставить APT-ом по ходу. И всё, «best of both worlds».

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

Просто как сейчас сделано, выходит, что вот эти вот модули в основном облегчают задачу самим разработчикам. А пользователям от них ни тепло, ни холодно, потому что их можно только убирать, а в этом смысла меньше, чем в добавлении. Но вот если сделать модули с подборками полезного софта по темам, ситуация кардинально изменится. Потому что можно будет тупо докинуть на флешку 1-2 модуля, которые будут нужны, это быстро и результативно. Киллер-фича. Самому-то всё можно собрать, но тогда можно и просто что угодно поставить на внешний SSD, потому что если самому всё ручками крутить, то какая разница-то. Миниос тогда особо и не нужна.

Флакс тоже можно сделать симпатичным, кстати говоря. В Mint Community Edition когда-то был флакс, и очень неплохо выглядел. Дело чисто в теме оформления. Тут такая же история, как с IceWM, у которого все умолчальные темы вырвиглазные, а сам WM ни в чём ни виноват. Вот как флаксбокс выглядел в 9 минте: https://imgur.com/a/Qm3uCd8

Собственно, панелька-то у вас симпатичная. Тема меню и окон трындец.

Слака то и 14.2 до сих пор поддерживается вроде. А с кноппиксом не все так хорошо

Так никто ж не мешает собрать свои модули и докинуть. Инструменты для этого есть. Существующие слои можно использовать так, как в голову взбредёт. Можно убрать, к примеру, 04-06 и собрать самостоятельно модуль Gnome за пару минут, так же поверх него собрать нужный софт.

sudo apt2sb -l 3 gnome-desktop

Так я об этом и говорю. В текущей ситуации модули хороши только для того, чтобы их убирать, а это не особо полезная штука. Добавить самому — всё-таки уже дело не минутное, и не плёвое, на коленке за пять минут до выхода из дома не сделаешь. А должно быть, как мне представляется, иначе. Опять же, я не говорю, что нужно запихать весь дебиан заранее в модули, чтобы юзер не дай бог не перетрудился. Нет, просто предоставить некоторый набор готовых аддонов. Иначе выходит, что потенциал модульной системы используется лишь в малой степени.

Опять же, подчёркиваю, что развитие логики «пользователь сам может всё сделать» (что чисто технически, конечно, сущая правда) за несколько шагов рассуждения приводит к идее «minios не нужен», и довольно непротиворечивым образом. Если рассуждать чисто с материальной точки зрения, то minios по существу экономит стоимость внешнего SSD. Потому что если есть внешний SSD, то скорость работы с носителя уже не проблема, и можно ставить вообще любой дистр, какой захочешь — самостоятельно, ручками, теми самыми, которыми можно самому модули minios собирать. Причём поставить на SSD даже проще, потому что вообще ничего нового узнавать не нужно. Т.е. речь о примерно 2500 руб.

Кому как. Мне удобнее носить с собой маленькую флешку, чем значительно более крупное устройство. MiniOS уже не один год и давно сложилось представление о том, что нужно большинству пользователей (спойлер: не модульность Puzzle). Они предпочитают сами ставить то, что им надо в модули, либо использовать как обычную систему с apt. Сделать репозиторий модулей мне, как уже писал выше, мешает лень. Я просто не хочу это поддерживать, у меня и так свободного времени мало:) Если кто-то сам возьмётся — флаг в руки и барабан на шею — окажу всю необходимую моральную поддержку.

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

Кому как. Мне удобнее носить с собой маленькую флешку, чем значительно более крупное устройство.

SSD тоже небольшие, хотя и побольше флешки. Если подороже купить, то можно и вполне миниатюрные найти. Например: https://www.dns-shop.ru/product/477d020694e1ed20/250-gb-vnesnij-ssd-silicon-p...

Опять же, в номинации «чтоб с флешки работало» выступает очень много претендентов. Тот же минт со своими стоковыми установочными образами предоставляет в живом режиме столько же софта, сколько minios ultra. И можно доставить через apt. И с secure boot проблем нет. При этом ни на какие лавры минт по этой части не претендует, разработчики вообще никак не педалируют тему работы минта с флешки.

Сделать репозиторий модулей мне, как уже писал выше, мешает лень.

Я вот сейчас посмотрел, во всех релизах кроме ядра, судя по размеру, все модули разные, даже тот же файрфокс, не говоря уже о xfce-… и т.п. И вот этот зоопарк собирать почему-то не лень. А схему с одним-единственным модулем файрфокса — лень. Схему с одним «деревом технологий» поддерживать времени нет, зато с шестью — хватает. Где логика?

Минт - это совсем другое. Во первых, с таким же набором полезного софта он занимает в два раза больше места, и не всегда же нужен полный набор, для того и модульность. Указываем в параметрах ядра noload=03-09 и загружаем систему в чистой консоли без рабочего стола и прочего софта. Это можно приправить toram для запуска в ОЗУ и задать user_name=vasya user_password=G2NdPLL^dEwu$ZfwpGI^JT$7LH543Pp5 enable_services=ssh hide_credentials, подключиться извне и работать удалённо с минимальным расходом памяти.

Во-вторых, единственный способ изменить Минт (и все аналогичные системы) под себя - Cubic, но достичь того же результата, который можно реализовать с MiniOS в нём не выйдет. Например, можно написать скрипт установки Firefox, добавить в него необходимые действия для запуска браузера в режиме киоска, собрать модуль и сгенерировать iso без модулей DE и выше, получив готовый киоск.

Это лишь примеры, ограниченные фантазией, можно придумать сценарии гораздо большее и интереснее.

Что касается моей лени, на сборку 40 образов я трачу своего времени меньше минуты:) Всё ведь полностью автоматизировано. А с модулями сложнее. Нужно следить за обновлениями, периодически их обновлять — это уже не работа с кодом, где можно придумать что-то интересное, а жутко скучная рутина. И, к слову, такой дистрибутив уже есть. Можно найти на форуме PuppyRus, он на базе миниоси, его собирает и поддерживает sfs, ему этим заниматься не лень:)

Минт - это совсем другое. Во первых, с таким же набором полезного софта он занимает в два раза больше места, и не всегда же нужен полный набор, для того и модульность.

Согласен, минт побольше. Но всё равно 3 гигабайта. Т.е. влезет на самую маленькую 4 гб флешку, а она найдётся у подавляющего большинства «обычных пользователей».

Указываем в параметрах ядра noload=03-09 и загружаем систему в чистой консоли

Это не модульность, я уж дико извиняюсь за прямоту. Это всё про отключение кусков ОС. Тогда и загрузка в runlevel 3 это модульность, тоже всё загружается в консоль. Я вот решительно не понимаю этого акцента на отключении кусков системы, когда типовой сценарий скорее будет подразумевать добавление, потому что людям свойственно по возможности хотеть больше, а место на флешке экономить уже никто не будет, это в 2003 году флешка на 128 метров обходилась в весомую сумму. Сейчас можно 8, а то и 16 гб за 300 рублей взять, это цена бургера с мясом.

Во-вторых, единственный способ изменить Минт (и все аналогичные системы) под себя - Cubic, но достичь того же результата, который можно реализовать с MiniOS в нём не выйдет. Например, можно написать скрипт установки Firefox, добавить в него необходимые действия для запуска браузера в режиме киоска, собрать модуль и сгенерировать iso без модулей DE и выше, получив готовый киоск.

Вот тут нет возражений, минт действительно монолитен. Но при этом всё равно получается, что авторы, во-первых, щедро насыпали туда софта, а во-вторых, хотя юзабилити этой конструкции не является их приоритетом, этим всем можно пользоваться, хотя включение той же persistence, прямо скажем, на порядок неудобнее minios (повторюсь — реализации лучше, чем в minios, я не видал вообще), да и всё равно получается ограниченно.

Это лишь примеры, ограниченные фантазией, можно придумать сценарии гораздо большее и интереснее.

Да, согласен, сценарии интересные — но нишевые. А типичный сценарий — набрать себе софта по-быстрому и поехать пользоваться по назначению — считается недостойным делом.

Что касается моей лени, на сборку 40 образов я трачу своего времени меньше минуты:) Всё ведь полностью автоматизировано. А с модулями сложнее. Нужно следить за обновлениями, периодически их обновлять — это уже не работа с кодом, где можно придумать что-то интересное, а жутко скучная рутина. И, к слову, такой дистрибутив уже есть. Можно найти на форуме PuppyRus, он на базе миниоси, его собирает и поддерживает sfs, ему этим заниматься не лень:)

Минуточку. А почему, если сделать ещё несколько модулей, то их придётся обновлять чаще, чем релизы ОС, которые есть сейчас? И почему их создание будет большей морокой, чем генерация 6 версий ОС, которые есть сейчас? Так-то то выходит, что в текущей ситуации просто уже есть готовые скрипты, которые эти образы генерят. Ну так и при изменении схемы построения системы тоже останутся скрипты, и будут дальше генерировать всё, что надо, за минуту сами. А трудозатраты вырасти не должны, потому что произойдёт обмен части труда, который затрачивается на зоопарк релизов, на труд по части модулей.

Опять-таки, идея с модулями — идея на миллион. И просто обидно видеть, как она закапывается в землю. Потому что ничего подобного я не видал (ну вот форк minios не в счёт, васяносборка). Набрать себе систему «крупными кусками», которые просто кидаются на флешку, под свои задачи, которая потом с полной persistence (блин, какой нормальный термин-то использовать на родном языке?) будет быстро работать с флешки, это было бы мегакруто.

Возможно, когда-нибудь в будущем я ещё вернусь к этому вопросу, но пока это нереально реализовать, так как для репозитория модулей, как минимум, уже недостаточно бесплатного репозитория на GitHub, а вкладывать в проект ещё больше средств, чем вкладывается сейчас, я не готов.

так как для репозитория модулей, как минимум, уже недостаточно бесплатного репозитория на GitHub

Почему же? Если они будут такого же размера, что и текущие модули, и их будет немного, то в чём проблема? Штук 12 модулей по 50-100-150 мегабайт...

Кстати, заметил ещё такую штуку: в редакции ultra тема оформления по умолчанию «плоская», без градиента на заголовке окна. А в остальных с градиентом, и чтобы добиться такого эффекта, нужно включать опцию «применять тему xfce4» в настройках внешнего вида. При это в самой ultra эта опция тоже не включена, но никакого эффекта не оказывает.

Максимальный размер файла в репозитории GitHub — 100 МБ. LibreOffice уже не проходит. Даже не хочу заморачиваться :) Будет спонсор сервера — реализуем.

Надеюсь, когда-нибудь поправим.

Так можно же через механизм релизов выкладывать. На них-то вроде как ограничения нет. Вон, 1780 мегабайтный образ лежит спокойно, а всего к 3.3.4 аж 44 файла приложены. Я ж говорю — не надо суетиться и модули постоянно обновлять. Они должны быть примерно такими же постоянными, как файлы релизов, а не гоняться за каждым апдейтом и переделываться раз в неделю.

Зачем это, если есть если есть MagOs

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

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

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

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

Ну так тогда ничего в предлагаемой схеме не изменится по сравнению с текущим положением вещей. Просто будет 2-3 образа из разного количества унифицированных пакетов + дополнительно штук 12 пакетов опциональных. И меняться будет с очередным релизом.