LF01 x86_64. Двойной модульный FRUGAL : LFA1801 (Arch) + LFD10 (Debian)

[sfs]

Изменения линейки дистрибутивов 2021
C 2021.04 LFA1801 не поддерживается (переходите на LFA20.08). Поэтому LF01 больше выпускаться не будет
LFD10 выпускается отдельным iso
Последний LF01.iso

LF01 = LFD10 + LFA1801
LFA1801 ранее назывался PRA6408 и PRAR1801. Переименован для унификации

для загрузки LFA1801:

По итогу DDR01 + PRA09 и этой темы возникла идея двойного дистра
Наиболее показательный пример
Т.е. две базы от разных доноров со своими ПакетнымиМенеджерами и совместимые, портированные модули софта (одинаковые для обоих дистров)
Зачем: чтобы можно было дособрать модулей, которых нет конвертацией пакетов того дистра, где они есть или где это удобнее
Ну и работать с тем донором, который больше нравится + экономия труда на сборку модулей

Чтобы получилось - надо согласовать версии некоторых пакетов:
gtk3 ffmpeg - приблизительно (чтобы либы одинаково назывались)
qt5  openssl icu - точно
glibc glib2 - легко обновляются до свежего в любом дистре
Если один дистр арч - подбираем замороженный срез его репы наиболее близкий ко второму дистру
Если какие-то пакеты нужно других версий - создаем свою репу и прописываем выше арчовой. В пределах полугода все должно получиться

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

Можно будет попробовать на следующей LTS ubuntu x86_64
LTS - чтобы дистр подольше жил и были патчи по безопасности

[krasnyh]

Раз пошла такая 'пьянка',  то перевести и ddr на minirc. Как говорили в армии, "безобразно, но однообразно." )

[sfs]

Получается по хорошему ждать ubuntu 20.04 - видимо в апреле 2020
или делать на deb10

Проанализировал даты арч репы на близость по версиям пакетов (ffmpeg qt5 ...) к deb10
20181120 - очень близко. Именно она в пра-roll . Это существенно облегчит задачу

[ШАМАНЯ]

В новостях где-то было, что продлили срок поддержки ubuntu 18.04 LTS до 10 лет, до апреля 2028 г. Так что ждать ubuntu 20.04 не обязательно.
Но лучше без убунты
Там systemd , где-то тесты были, что в два раза медленнее работает она , чем devuan - debian, который без systemd.
Да и на глаз видно, что ddr медлительная.
Или Antix 19, он на debian 10 , есть и 64 bit, скоро выйдет стабильная версия, сейчас бета 3.
MX-Linux от тех же авторов, но с системд, тоже медленнее антикса.

[ШАМАНЯ]

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

не очень получается
В меню каша из программ мими и пра.

Так получается, если добавить в мими базовый модуль от пра1710ретро , отдельно  DE от него или и то и другое.
Другой вариант  с базой от пра1405, примерно также.
Можно добавлять ещё и 070*, тогда из меню больше программ работают, но всё равно путаница.
Если добавить только граф. pfs-utils от pra, то из-за того, что нет sudo, графические pfs-utils не работают из меню  и половина программ пра из меню не запускается,их нет в мими. От рута если запустить spacefm из него можно подключать модули программой open_pfs, отключать/подключать  разделы диска слева в окне.
 SFS-GET, запущенный от рута, не показывает подключенные модули, потому они в /mnt/bundles в mimi, а в пра они в  /mnt/live/memory.
Добавлять беспарольный sudo не хочется
И с модуями ядра и с firmware тоже не получается, в  убунту и в мими они должно быть в lib/modules и lib/firmware , а в пра в /usr/lib/modules, /usr/lib/firmware.
Надо придумать, может просто ссылки сделать, чтобы одинаково было.
А в ддр модуль отдельный есть apt, он свою базу создаёт, как она будет с базой арча синхронизироваться? И наоборот?  И где база арча с установленными пакетами находится?
Ещё может добавить формат appimage дополнительно, чтобы меньше модулей вручную переделывать в портированные

[sfs]

с модуями ядра и с firmware тоже не получается, в  убунту и в мими они должно быть в lib/modules и lib/firmware , а в пра в /usr/lib/modules, /usr/lib/firmware.

В чем проблема сделать симлинки - см. ДДР

А в ддр модуль отдельный есть apt, он свою базу создаёт, как она будет с базой арча синхронизироваться? И наоборот?

Никак. Фишка только в том, что т.к. основные пакеты сопостовимых версий  - скомпиленное (собранное родным ПМ) в одном дистре можно юзать в другом. Особенно если портировать
Иллюзий по прикручиванию к арчу apt и наоборот быть не должно.
Главный приз всей затеи - доступность софта из реп арча и деб для обоих наших фругалов

В ДДР все уже реализовано. Что там не понятно по идее?
Просто там не было подгонки версий пакетов. Но и так много чего подошло
Новизна только в этом

[sfs]

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

Это получилось. Причем даже более широко, чем ожидалось. Совместимо не только с prar1811 но и с pra6408

два донора - арч и дебиан в исо и загружать разными пунктами в меню   noload=001-pra  и другой пункт  noload=001-deb  и получаем один новый 64-х битный дистр вместо ещё одного 64-х битного.

В один исо теоретически возможно.
Но , наверное, лучше в 3 этапа :
1. Довести дебиан
2. Переделать пра6408 (glibc и пр.)
3. Объединять

Если 001 089 положить в /optional - 001 окажется выше, чем обычно. Возможны проблемы
Пожалуй, оптимально в  /base базовые модули обоих дистров. И noload=ненужный
...только в меню и так жесть, а станет совсем...
С другой стороны хранить дубли модулей в двух папках с двумя дистрами тоже не очень
Можно намутить симлинков, но с их обновлением придется какой-то скрипт синрхронизации писать
Надо пробовать...

[RoDoN]

Да, времена меняются... Когда-то меня критиковали за то, что я хотел и делал в дистре несколько WM с переключением, чтоб можно было оценить и выбрать какой понравится, а тут два разных дистра в один iso + жесть в меню и ничего, все нормально...   

[sfs]

Именно горячее переключение ВМ - проблемная и бесполезная вещь
В остальном - сам в шоке 

[sfs]

оптимально в  /base базовые модули обоих дистров. И noload=ненужный

И модули ТК и пр. продублировать, а потом noload=-d10- или noload=-1801

[sfs]

Потому, что ТК модули и еще некоторые системные вряд ли подойдут от одного дистра к другому

[sfs]

lf-test2-x86_64.iso
Обединил 2 дистра в 1.
Для этого пришлось немного переделать initrd - об этом подробнее завтра
В виртуалке у меня криво работает в комбинации deb+kern 5.1 и arch + kern 5/1. На двух пк проверил - норм

Оставил - чтобы без адских load noload загрузился по минимуму деб
Альтернативно можно было везде положить рядом 001  03x и пр. модули , но тогда без load noload получится каша
Как удобнее?

[krasnyh]

Выскажу крамольную мысль. Может быть интересной сборка, использующая модули от разных дистров, типа lfd10. Но вот это, "Двойной модульный FRUGAL дистрибутив (2 разных дистра + одинаковые модули)"... 
Зря что ли все разбегались по 'своим' линуксам. 

p.s. Если я конечно все правильно понял и там действительно что-то типа DDR01 + PRA09 (debian+archlinux).

В виртуалке у меня криво работает в комбинации deb+kern 5.1 и arch + kern 5/1. На двух пк проверил - норм

Похоже не все так страшно и базы двух дистров не слиты в одну.

[sfs]

Может быть интересной сборка, использующая модули от разных дистров, типа lfd10. Но вот это, "Двойной модульный FRUGAL дистрибутив (2 разных дистра + одинаковые модули)"... 

Выкидываем один из дублей 001 ffmpeg и еще пары модулей и получаем pra6408 или lfd10
Кто юзает оба дистра - удобно
Один - выкинуть лишнее не сложно.
Кроме того - если модули софта окажутся хорошо совместимы с более свжими версиями либ - можно легко настрогать свежих арчей и чуть сложнее дебианов , а можно и других дистров (есть понять зачем нам такое многообразие)

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

[sfs]

connman-p-1.36_64-sf03.pfs
Подкрутил для использования в обоих дистрибутивах

Из отдельных для каждого дистра модулей остается :
ffmpeg

mesa - т.к. завязано с версией Xorg - только отдельно

По ядру - может достаточно одного свежего?
Или вместо 414 - более старое 44? У кого как где пошли ядра?