Svitlo GNU/Linux. Незалежний дистрибутив з нуля, свій пакетний менедже

[res2500]

Вітаю. Викочую на обговорення проєкт, над яким працюю майже рік у
вільний час. Svitlo GNU/Linux. Незалежний дистрибутив для x86_64,
зібраний повністю з вихідного коду, не форк.

Суть коротко. Уся система, від тулчейна (binutils, gcc, glibc) і ядра до
робочого столу, збирається з вихідного коду єдиним рушієм. Під нею немає
чужої пакетної бази. Окремого кроку накатати готову чужу систему і
поставити косметику зверху немає.

Пакетний менеджер свій, promin, написаний на Python. Модель близька до
Nix. Кожен пакет ставиться у шлях, ключем якого є хеш усіх входів збірки,
тому кілька версій співіснують без конфлікту, а відкат покоління це
атомарна операція. Встановлення binary-first, спершу готовий бінарник за
збігом хеша з перевіркою sha256, складання з джерела лише як крайній
випадок. Рецепти на YAML, окремого DSL свідомо немає, щоб не плодити мову
для вивчення.

Робочий стіл COSMIC (Rust), чистий Wayland, без X11 у базі. Зібраний з
вихідного коду, без бінарних блобів.

Чесно про стан. Це бета. Інфраструктура збірки і менеджер працюють, образ
із графічним столом запускається. Частина речей, як шифрування даних і
відсутність телеметрії, поки закладена як ціль архітектури, а не готовий
стан. Для продакшену рано.

Окремою гілкою опрацьовую RT-варіант на PREEMPT_RT для embedded і
промобладнання, на тому самому рушії, але це поки концепт, реалізація
після стабілізації десктопу.

Спробувати можна в QEMU без встановлення на диск. Вхід svitlo / svitlo.

  wget https://cache.svitlolinux.org/images/svitlo-cosmic-0.3.img.zst
  zstd -d svitlo-cosmic-0.3.img.zst
  qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -m 3072 \
    -drive file=svitlo-cosmic-0.3.img,format=raw,if=virtio \
    -vga none -device virtio-gpu-pci -device qemu-xhci -device usb-tablet

Стабільної версії немає, перезбірки регулярні, тож місцями може бути
зламано.

Відкрита частина пакетної бази, основний код відкриватиму цього року
поетапно, починаючи з менеджера.

Сайт https://svitlolinux.org/

Буду радий технічному розбору, особливо по моделі менеджера і по підходу
до незалежної збірки. Питання і критику вітаю.

автор Юрій Качанюк

[yvs115]

критика:

відносно nixos - саме з ним не працював, але трохи крутив guix який по ідеї має такогож типу підхід: не сподобався - і повільний, і конфігурувати нелегко було

відносно cosmic - полуекспериментальний DE, полірувати софт на такій стадії бажання не дуже часто виникає у когось

а ще onlyofice - взагалі без їдей чому

p.s. просетапити не вдалося - максимум з декількох різних спроб вдалося дійти до "rsync .... завершився з кодом Some(10):", спробував ще в типу live сесії щось подивитись - але не знайшов навіть git, потім закинув (чесно кажучи - очі шкода на такому рендерінгу який був після завантаження іміджу) -
тобто в цілому виглядає як дуже і дуже початкова версія

[BeSiDa]

- і повільний, і конфігурувати нелегко було

Це не  важливо для того застосування, яке описане у запланованому.
Такий вид менеджера описує "стан системи" і може перетворювати всю систему зі "стан1" у "стан2" які описані конфігом. Це потрібно коли у вас є 100 та більше компів і вам їх треба всі разом змінити зі "стан1" у "стан2" та ще й щоб воно не зламалося у процесі (не видаляти старі ліби, коли вони все ще використовуються у запущених у цей момент процесах які повинні нормально завершитися).
Фактично ви можете зробити комп який одночасно запускає програми скомпільовані під 2 різні версіі станів (під дві версіі дистрібутива, а не так що "аргрейд" ламає стару версію та замінює новою без варіантів).

а ще onlyofice - взагалі без їдей чому

Мабуть тому що він може більше ніж лібре. Європейський клон обрав онлі (здається) через наявність розвиненої веб-версії.

[BeSiDa]

Цікавий проект.

Можете детальніше розказати про плани щодо промобладнання та ембед? Буде лише х86.. чи арм та ріск? (колись)

Чи буде крім РТ ще жорсткі обмеження інших ресурсів? Ну от щоб можна було бравзер запхати у рамки Н гб пам'яті і не більше. Або не бравзер. Або 2 різні ігри. Або сервер та кліентів. Або програмні частини робота.

Пакетний менеджер свій, promin, написаний на Python. Модель близька до Nix. Кожен пакет ставиться у шлях, ключем якого є хеш усіх входів збірки, тому кілька версій співіснують без конфлікту, а відкат покоління це атомарна операція.

А що таке "покоління"?
Всі файли пакету? І конфіги, і шрифти, і малюнки та ін?
Це більш схоже на снап пакети. Тільки без заборони програмам міняти файли у інших шлахах інших пакетів. Як розділяєте? Може по юзерам? (як Андроїд)

Які саме "усі входи"? Ключі конфіга компілювання також?

Окремою гілкою опрацьовую RT-варіант на PREEMPT_RT для embedded і промобладнання, на тому самому рушії, але це поки концепт, реалізація після стабілізації десктопу.

Для роботів та віртуальної реальності (це "робот навиворіт", бо сенсори, рендеринг та "світ гри" мають незалежно одне від одного працювати з різними швидкостями та реагуванням (наприклад, сенсор рухів та світ гри не прив'язаний до 90Гц оновлення екрану і може бути 300Гц чи більше), тобто це робот якій існує всередині компа, а не зовні)?
Анонс підтримки вр може привабити людей, що працюють у сфері РТ та мають зовсім інше сприйняття світу (ніж ті хто на заводах та з 3д принтерами працюють). У цій сфері вже багато протестовано і вирішено задач, про які в інших сферах ще не думали (от як, наприклад, вплив інтерференції блутус з вайфай на обробку сенсорів і малювання картинки чи реагування на дії (бо контролери у руках по блутус працюють і заважають лів стрімінгу 3д світу через вай-фай з іншого компа) та ін). Тому вже є обладнання з чотирма антенами, що незалежні одна від одної (окремо стрімінг, окремо дані, окремо сенсори та ін).

Буду радий технічному розбору, особливо по моделі менеджера і по підходу до незалежної збірки. Питання і критику вітаю.

А розкажіть про менеджер? Які варіанти залежностей реалізовано? Тільки один-до-одного (лише вказана точна версія (хеш?)) чи варіанти "будь яка не старіша за..." також?

Чи планується використовувати цю систему для розробки самої цієї системи? Чи розробка та компілювання в іншому дистрі буде?

[BeSiDa]

А чи розглядали варіант із зовнішньою графікою?
Щоб графічні програми в системі були, але сервера в системі не було, а лише під'єднання до іншого компа з монітором та (можливо) мишкою і клавіатурою.
Щоб не витрачати час на вейленд, графічні драйвери та не концентруватися на розділенні часу (для РТ) між графікою та основною корисною програмою.

[res2500]

Так це все поки початок, автор пише всюди на сайтах, але про цей сайт або не знає, або ще не дійшов, потрібні люди для розробки, так що на сайт "світла" і допомагайте, пропонуйте і так дальше, щоб не було так як з лінукс груша

[yvs115]

Так це все поки початок

архітектурно вибір непривабливий

лінукс груша

відносно локалізації - практично любий сучасний лінукс-дистро вже достатньо локалізовн щоб не займатися велосипедами
відносно "лінукс груша" - і не стикався і не чув

для розробки (якщо хтось побачить в тому сенс) - треба мати принаймні доцільність

[trimbler]

Автор Svitlo тут, тему сюди приніс res2500 раніше за мене. По пунктах

Установка і образ. Наразі постійні перезбірки, фікси і деплої, тому стабільність у конкретний момент може плавати. rsync з кодом 10 це обрив передачі при витягу з cache. git у базі поки немає, база мінімальна і бінарна, інше ставиться промином поверх, тому голий образ під тик наосліп очікуваний, набір утиліт розшириться, але не одразу

Софт. COSMIC це чистий Rust і чистий Wayland без спадку X11, лягає в збірку з джерела краще за GTK чи Qt-стек. Стіл це не ядро цінності, лише профіль зверху, цінність у моделі збірки і прозорому ланцюгу. Офіс буде OnlyOffice, за сумісністю з форматами MS і self-hosted веб-моделлю, документи у браузері, правки в той самий файл

Архітектура. yvs115, архітектурно непривабливий що саме, збірка з джерела, content-addressed store, чистий Wayland чи менеджер на Python. Кожен вибір свідомий, назвіть вісь, розберемо. Локалізація ніколи не була пітчем, сучасні дистро локалізовані достатньо, це не аргумент за проєкт, згоден

Менеджер. Покоління це не пакет, а знімок усього профілю, набір символьних посилань на конкретні шляхи в store. Кожен пакет лежить незмінно у своєму шляху /promin/store/{hash}-{name}-{version}/ з усіма файлами, покоління це який набір шляхів активний, перемикання і відкат атомарні

На снап не схоже. Снап ізолює пісочницею, тут ізоляція адресою за вмістом, версії не конфліктують бо хешований шлях у кожної свій. Рантайм-пісочниці, що забороняла б писати деінде, немає, це не задача менеджера. Розділення за шляхом-хешем, а не за юзером, модель Nix, не Андроїда

Усі входи це все, що впливає на результат, вихідник і його хеш, версія, тіло рецепта, хеші залежностей, прапори компіляції теж, бо вони частина рецепта. Хешується канонічна форма рецепта, не сирий текст, тому косметичні правки перезбірку не тягнуть

Залежності зараз один-до-одного, точний піннінг за хешем, навмисно заради відтворюваності. Діапазон не старіша за дрейфує з часом і ламає біт-у-біт, тому міг би бути лише шаром зручності на резолві, який далі фіксується в точні хеші. Резолвер поки простий

Самохостинг. Кінцеві машини не збирають нічого, клієнт бінарний. Повний набір збирається на build-вузлі, зараз на звичайному Linux, не на Svitlo. Щоб система збирала себе сама, можливо згодом, поки ні

Embedded. Зараз тільки x86_64, ARM наступний таргет і головний ризик, після стабілізації ядра, RISC-V горизонт. Обмеження ресурсів крім RT це cgroups v2, ліміти CPU, пам'яті, IO дає ядро, загнати процес у N ГБ це конфіг, у embedded-профілі має йти вже налаштованим. Зовнішня графіка і headless це рівно вектор embedded-гілки, профіль без стола, тільки аппка, без сервера графіки, тонкий клієнт з віддаленим дисплеєм валідний. Профіль поки концепт

VR не мій таргет, фокус це індустрія, керування, телеметрія, кіоски. Розв'язані там контури з різними частотами цікаві, але заявляти підтримку VR, якої не будую, не стану. Чотири антени і завади блутус це рівень заліза, поза дистрибутивом

Навіщо. yvs115 правий, потрібна доцільність, а не гасло. Це не ще один десктоп для всіх, згоден. Сенс у двох речах, відтворюваний ланцюг з джерела під нішу, де це треба, embedded і supply-chain контроль, і легкий вбудовуваний рушій збірки без демона і без мови Nix. Плюс українська технологічна незалежність як практика. Спільнота і тривалість реальний ризик, не ховаю, почасти тому й пишу тут

Готовий заглиблюватись, найперше по менеджеру

[yvs115]

стабільність у конкретний момент може плавати. rsync з кодом 10 це обрив передачі при витягу з cache.

одна з спроб - система не поставилась з кодом Some(10), перед цим також зупинялось з мнемо-кодом "Some" але мабуть з іншими цифрами,
тобто неможливість проінсталити у всіх спробах закінчувалась з помилкою "Some"

git у базі поки немає, база мінімальна і бінарна

наскільки зрозумів по - немає базових утиліт - орієнтація мала б бути на офісне використання, хоча з іншої сторони - неможливість просетапити та жахливий вигляд протирічить і цоьму target (офіс)

Софт. COSMIC це чистий Rust і чистий Wayland без спадку X11,

- софт полуекспериментальний - для надання як опція можлива, тоді як безальтернативний варіант замість звичайних робочих десктопів - як намене ні
- чистий раст - (зновуж imho на сьогодення) то недолік - цілком можливо пиляти ще будуть довго в експериментальній стадії (судячи з навіть значно менших раст проектів у devel стадії)
- "без спадку X11" то опція, відносно x11/wayland опцій - у сучасних лінукс-дистро по дефолту сесія Wayland - тому здивувати Wayland'ом... еее.. важко

лягає в збірку з джерела краще за GTK чи Qt-стек

то трохи нетуди як-і-що лягає в якусь збірку (десь в стрічці було що і мейнстрим по бажанню збирають без x11 опції),
більше що цікавить то софт який використовує відповідний стек - тобто софт під gtk чи qt

Офіс буде OnlyOffice

і безальтернативно? як щось з'являється чи пропонується нове - перше що спадає на думку то загуглити.. загуглилась наступна
https://www.reddit.com/r/BuyFromEU/comments/1j7zlf2/onlyoffice_is_obfuscating_its_russian_ownership/

архітектурно непривабливий що саме, збірка з джерела, content-addressed store

По досвіду трохи з guix - такого типу менеджмент софта повііііільний та незручний.
Додам що тут ще невідома яка target по використанню у дистро - якщо це щоб зробити щось типу user-fiendly загалом і "не поламати пару кліками" - то це напрямок immutable oses (з атомарністю-снапшотами-etc в base system та sandbox store для userland), які вже є і напокрутити і напоюзати.
Якщо то для сусадминів та девелоперів, трохи менш за малоймовірно у використанні за відсутністю базового софта з base system.

Локалізація ніколи не була пітчем

то було ясно для тих хто працює з лінуксами, єдине що можна було прояснити - якби то була зроблена своя заміна для gettext підсистеми - тоді такий фокус на локалізації зрозумілий став би

[trimbler]

Установка. Якщо всі спроби падають на Some(N), це відтворюваний баг установника, не флуктуація мережі, тут ви праві, і сирий підкод замість людської помилки моя недоробка, скажіть який образ, полагоджу

Ціль десктопа. Офісний стіл для всіх це не пітч, тому суперечності з ним і немає, десктоп найсиріший і найменш важливий шар, цінність нижче. git і базові утиліти доставлю, вигляд у QEMU це софтверний рендер без GPU, але полірування там і так поки немає

COSMIC. По суті згоден. Wayland за замовчуванням давно не фіча, я ним не хизуюсь, зрілість Rust-стола реальний ризик, тому DE не несуча деталь, а змінний шар. Чистий Rust без GTK/Qt це лише про базу і сесію, прикладний софт під GTK чи Qt збирається пакетами як усе, тут ви точні

OnlyOffice. Праве питання. Власність відома, до серпня 2023 компанія була під російським власником, у РФ лишається форк R7. Self-hosted знімає витік даних, але ви підняли саме власність, а це окрема вісь, на українському проєкті я її не відмахую, тримаю на увазі

Ціль дистро. Не user-friendly immutable десктоп для всіх, там immutable ОС виграють, і не загальний стіл для адмінів чи девів, там справді бракує базового софту. Ціль третя, вузька, відтворюваний образ під нішу embedded і appliance та прозорий ланцюг збірки, цінність у моделі. Про guix, кінцева машина не компілює, promin binary-first, тягне готове за хешем, компіляція це турбота build-вузла

Локалізацію не пітчу, своєї заміни gettext немає, стандартний i18n, тому фокусу на ній і немає, згоден

По менеджеру готовий глибше, це найцікавіше

[yvs115]

неясності навіть більше ще стало

Ціль десктопа. Офісний стіл для всіх це не пітч, тому суперечності з ним і немає, десктоп найсиріший і найменш важливий шар

щодо DE вже висловлювався - у випадку надання полуекспериментального DE -безальтернативно- при наявності робочих мейнстрим

вигляд у QEMU це софтверний рендер без GPU, але полірування там і так поки немає

з таким рендерінгом можна зламати очі, я довго не витримав, і зовсім не думаю що то пов'язано з софтверним рендерінгом - бо в qemu запускаю купу дистро як з hardware acceleration так і software - такої жахливої відмальовки вже і не памятаю (а в цілому то без hardware acceleration вірогідність отримати глюки зазвичай навпаки - нижча)

Чистий Rust без GTK/Qt це лише про базу і сесію, прикладний софт під GTK чи Qt збирається пакетами як усе

у випадку використання gtk/qt софта логічно використовувати і відповідний десктоп який базується на відповідних лібах які вже і завантажені самим DE - тоді відпадає необхідність у додаткових лібах нерідного десктопа (як у цьому випадку) що дає виграш бо не потребує додаткових ресурсів (нп до пам'яті)

OnlyOffice

і безальтернативно, незрозуміло

Ціль дистро. ... вузька, відтворюваний образ під нішу embedded і appliance та прозорий ланцюг збірки, цінність у моделі.

тоді не зовсім зрозуміло відношення до ресурсів - ясно що альфабета версії і т.п., але... при запуску дистро він виїв практично всі ресурси проца (ті що йому видались віртуалкою), контейнери докери оверхед з лібами - одним словом як це має підходити для embedded з лімітованими ресурсами - зовсім тумано

[BeSiDa]

Готовий заглиблюватись, найперше по менеджеру
...
Рантайм-пісочниці, що забороняла б писати деінде, немає, це не задача менеджера.

Зрозуміло, що ви хочете обмежитися чимось, бо інакше то буде нескінчений процес створення.
Насправді менеджер та загальна ідея системи пов'язані.
От ви хочете неймспайсис та цгрупс в2. Серед них є неймспейси для файлової системи. Тобто кожен процес може мати свій особистий вигляд файлової системи (та наслідувати процесам нащадкам).
Тобто замість створювати одну єдину систему посилань "покоління" ви можете мати одразу декілька "поколінь" активних (кожне у своєму неймспейсі, а отже вони можуть бачити тільки ті встановлені пакети (хеші) які змаплені у саме їх неймспейс). Це не снап, але й не "просто менеджер".

Але є більш базові речі...
1) хто та де?
2) одно-мова чи мульти-мова?
3) одно-машина чи мульти-машина?

У вас є шанс змінити ці три вибори, якщо захочете. Це може вплинути на майбутнє індустрії та перетворити проект на принципово інший (а не "ще один дистр Лінукс). Але це потребує зміну мислення. Не всі можуть. Якщо будуть запитання, то можу детальніше перш ніж вирішувати чи потрібно то вам.

1... хто керує кожним з вузлів, та де він знаходиться (наприклад, у вас 100 кіосків, ним керує одна людина з однієї машини з офісу у онлайн (синхронно) або оффлайн (лише коли є зв'язок, як пошта, відправили команду, перевірили через день відповідь) форматах). Тобто існування "робочого місця керування та моніторингу систем" одразу з коробки (а не кожен сам собі). Тобто на кіоску може навіть не бути шеллу та входу по ссш.

2... українська передбачає використання різних мов як частини тексту українською мовою та програм і сайтів що одночасно можуть бути представлені різними мовами (приклад, кіоск, що має перемикач мови у інтерфейсі). Дистри що існують (та бібліотека С як база) передбачають лише вибір однієї єдиної мови (одночасно) для кожного процесу (локалізація та ін). Тобто наразі ніхто не робить дистр з мультимовами (приклад, одна програма кіоска показує інтерфейс декількома мовами). Юнікод це не "мова" і не "багато мов", це лише "вид літер" (стандарт зазначає, що вони не мають відношення до мов, а лише до "написання літер", а мова повинна бути вказана зовні, і відповідно шрифт може бути обраний під мову ("ш" українською, болгарською чи іншою може виглядати різним чином)).

3... більшість дистрів виходить з того що існує лише "одна єдина машина" (хоч і багато процесорів та відеопроцесор на ній). Може бути дистр, що з коробки вміє декілька машин перетворити на єдину систему (от наприклад, ви в шеллі однієї машини можете не тільки копіювати файли до інших, але й запускати програми на будь якій та робити пайпи з програми однієї машини в програму іншої без вказування мережевих адрес ніби то єдина машина).

І маленький додаток. Коли у вас є в планах АРМ, то можливо у назву каталогу встановленого пакета додати архітектуру та тип платформи? Також знадобиться коли раптом буде підтримуватися емулятор інших ос (запуск андроїд додатків чи віндовз додатків в лінукс через протон).

[BeSiDa]

неясності навіть більше ще стало

Та все зрозуміло, от тільки ви хочете щоб воно вже "все було готове", а воно що у розробці

[BeSiDa]

OnlyOffice. Праве питання. Власність відома, до серпня 2023 компанія була під російським власником, у РФ лишається форк R7. Self-hosted знімає витік даних, але ви підняли саме власність, а це окрема вісь, на українському проєкті я її не відмахую, тримаю на увазі

А ви не думали, що сама ідея "документу" то є зав'язка на "не свій технологічний стек технологій?
Це не дуже по дорозі з "Плюс українська технологічна незалежність як практика.".
Це про увесь стек стандартів та реалізацій від початкового кодування АНСІ символів 1-127 (що початково були створені як коди команд для управління принтером).
Якщо цікаво, то можу детальніше.
Коротко, система може обрати 1-байтне кодування яке буде не фіксованим, а лише містити ті символи та команди (як "новий рядок") які потрібні для застосування. Наприклад, без англійських символів, лише українські та додатково герби всіх областей як символи з кодами у 1-255 діапазоні. Відповідно змінюється вся технологія обробки "тексту" та "документу" взагалі. Може бути схоже на формат МАЙМ (поштові дерева вкладення з альтернативними кодуваннями контенту, вказанням мови та кодування тексту частини контенту) чи на ХТТП (контент + заголовки).
Жодного сенсу тягнути увесь Юнікод навіть коли потрібно різні мови та різні типи літер та ієрогліфів (задля того щоб у С програмах обробка текстів була простим текст[і] та сортування української (чи іншої) було порівнянням коду літери).

[trimbler]

Думка цікава, і зерно правди є, документ і навіть кодування це успадковані стандарти, чужі за походженням. Але тут змішані дві осі

Незалежність у проєкті це контроль і прозорість стека, здатність зібрати, перевірити і не залежати від чужої закритої бази, яку відключать ззовні. Це не автаркія і не переписування відкритих стандартів. Unicode чи ODF відкриті й опубліковані, їх реалізує будь-хто і відключити не може ніхто, це якраз протилежність тієї залежності, про яку ви кажете. Чужа база, яку рубають, і відкритий стандарт це різні речі

Своє однобайтне кодування під українську і герби областей це не незалежність, а ізоляція. Система, що не обмінюється документом із рештою світу, вільна хіба на власній планеті. Фіксовані однобайтні кодпейджі це рівно те, що UTF-8 і поховав, зоопарк KOI8 проти CP1251, повернення туди відроджує ту саму несумісність. Простота text у C локальна, а ціна за неї глобальна

Як експеримент думки цікаво, деталі колись послухаю, але це не та вісь, на якій стоїть проєкт, тож цією дорогою не піду