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

[trimbler]

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

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

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

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

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

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

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

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

Неймспейси і покоління. Тут ви праві, і це сильно. Mount namespace дає процесу свій вигляд store, тож кілька поколінь можуть бути активні одночасно, кожне бачить лише свої хеші. Для content-addressed store це природно, надбудова оркестрації, не переписування. Зараз нема, але напрям валідний, беру на замітку

Хто і де. Лягає прямо в embedded. Парк кіосків з однієї точки, онлайн чи офлайн, вузол без шелу і ссш, це операційний шар, який embedded і потребує. Консоль керування з коробки це рівень продукту в роадмапі, вісь правильна

Одна чи багато мов. Технічно праві, POSIX-локаль це одна мова на процес. Але одночасна багатомовність в інтерфейсі це рівень тулкіта і шрифтів, не бази, сучасний рендер уже змішує писемності в рядку. Обмеження локалі реальне для CLI, не для GUI, тож це не вісь дистро

Одна чи багато машин. Це мрія Plan 9, красива і давня, але окрема ОС на роки, ортогональна до збірки з джерела і поза соло-стадією. Цією дорогою не піду

АРМ і шлях. Частково вже так, арка це вхід збірки, різні арки дають різний хеш і не колідують. Зробити арку видимою в імені шляху розумно /promin/store/{хеш}-{назва}-{версія}-{арка}

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

[BeSiDa]

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

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

Загалом ви кличете в принципово інший розподілений OS.

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

[BeSiDa]

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

Навіть три.
Сучасним розвитком ідеї "документ" є "ресурс" (той, на який вказівником є УРЛ (універсальний вказівник ресурсів), що може бути не тільки хттп сервером і не тільки глобальною назвою серверу, а на кожній машині свій окремий файл:///... чи ньюз:...).
Ідея "документ" у тому, що це "дані що самі по собі (без редактора) не змінюються", а отже їх можна роздрукувати на папері та поставити підпис.
А от "ресурс" може бути різним. Може містити динамічний ку-р-код, що новий кожної хвилини чи іншим чином змінюватися динамічно, але прогнозовано. Ще схожим на це є "цифровий контракт" або ... "скомпільована програма" (різні дані на виході залежно від даних на вході). ХТМЛ це теж більше "програма", бо на десктопі, тв, папері та смартфоні може виглядати різним чином, хоч там буде той самий хтмл, цсс та малюнки.
Тобто я про те що вже і так є десятки років, лише не змінилося наше ставлення до того.

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

Вірно кажете.
Але є ще одна частина. Хто саме має право змінити стандарт?
От захотіли ви додати до Юнікоду писанку (до смайликів) чи новий математичний символ (для розвитку математики) але не можете, бо очікуєте на зміни стандарту кимось зовні.
Тобто залежність настає не через існування стандарту, а через ваш особистий вибір відмовитися реалізовувати щось на додаток до стандартів (от, наприклад, свою кодову сторінку разом з іншими).

Прикладом є реалізація проміня. Ви захотіли щось нестандартне (не ті менеджери що вже є) і зробили.

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

Свобода є лише тоді, коли ви знаєте що міститься в тому, що ви використовуєте. Юнікод це сотні документів. Майже ніхто їх не читав усі разом. Ви погодилися на те, про що майже нічого не знаєте, а також на всі наступні зміни, про які не знаєте.
Мова не про відмову від Юнікод (не тільки УТФ-8, 16, 32 ...), а про додавання хоч одного кодування яке ви можете вмістити в одній голові (та права інших обрати інше кодування для їх голови та їх задач, комусь буде зручно однобайтне, комусь двобайтне але не змінної довжини).

Ви знали, що УТФ-8 народився у План9?
План9 по всьому світу, але лише ... маленькими частинками.

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

Розширив ваше сприйняття Вибір ваш.

[BeSiDa]

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

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

От вам ще варіанти. Чи оберете, чи відкладете, чи ні то як захочете.

Поки ви єдиний розробник, то модель жорстких залежностей у менеджері є ідеальною. Коли з'явиться більше людей (не тільки розробників дистру, а й користувачів які є розробниками своїх застосувань), то можуть знадобитися інші види залежностей. Але коли всі користувачі самі збирають всю систему з джерел як схочуть, тоді те не знадобиться.

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

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

Це вже більше про "робочі процеси використання" ніж про те, що вважають зазвичай "пакетним менеджером".

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

[trimbler]

Невелике оголошення. Найближчими днями переношу проєкт на новий сервер, тому сайт і завантаження образів можуть бути тимчасово недоступні кілька днів. Це планове перенесення, не зупинка проєкту. Вихідний код і рецепти на GitHub лишаються доступні весь час. Щойно закінчу, усе повернеться, дякую за розуміння

[BeSiDa]

Найближчими днями переношу проєкт на новий сервер, тому сайт і завантаження образів можуть бути тимчасово недоступні кілька днів.

Гарний приклад задачі міграції. Чи можлива міграція атомарно при таких переїздах (та реалізація в дистрі ос).

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

[trimbler]

Найближчими днями переношу проєкт на новий сервер, тому сайт і завантаження образів можуть бути тимчасово недоступні кілька днів.

Гарний приклад задачі міграції. Чи можлива міграція атомарно при таких переїздах (та реалізація в дистрі ос).

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

Оновлення по проєкту. Перенесення на новий сервер завершено, сайт і завантаження образів знову доступні. Окрема подяка тим, хто допоміг з міграцією, без цього вийшло б довше і болючіше. Зараз іде збірка нової версії. Щойно закінчу, викладу і напишу окремо

[trimbler]

Найближчими днями переношу проєкт на новий сервер, тому сайт і завантаження образів можуть бути тимчасово недоступні кілька днів.

Гарний приклад задачі міграції. Чи можлива міграція атомарно при таких переїздах (та реалізація в дистрі ос).

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

Оновлення по проєкту. Перенесення на новий сервер завершено, сайт і завантаження образів знову доступні. Окрема подяка тим, хто допоміг з міграцією, без цього вийшло б довше і болючіше. Зараз іде збірка нової версії. Щойно закінчу, викладу і напишу окремо

Дякую за розбір, кілька речей коротко.

Атомарність тут двох різних сенсів. Перемикання поколінь усередині системи справді атомарне, покоління це набір символьних посилань,
відкат миттєвий. А переїзд сервісу роздачі між серверами це вже не властивість store, а питання деплою (DNS, blue-green). Цього разу я
робив штатно, з коротким вікном недоступності, тому й попереджав.
Build-машина без графіки це саме той напрямок, який тримаю окремим профілем. Основа вже є, бо build-хост і так відокремлений від клієнта,
збірка живе на стороні інфраструктури. Черга задач і роздача по кількох воркерах для паралельного перезбирання валідні і лягають в архітектуру,
але поки це концепт, не готовий стан.
Одна поправка на користь підходу. Щоб гарантувати невплив попередньої збірки на наступну, машину чистити не треба. Вхід збірки це фіксований
набір хешів залежностей, а не поточний стан системи, тож ізоляція досягається самою моделлю. Ваша мета закрита без очищення машини, і це
одна з причин, чому я взяв цю модель.

[BeSiDa]

А переїзд сервісу роздачі між серверами це вже не властивість store, а питання деплою (DNS, blue-green).

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

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

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

[ps]

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

Дякую.

[BeSiDa]

яка саме у вас мотивація

Ви не зрозумієте. Бо використали слово "мотивація". З імперського це слово перекладається "слабка точка" (коли її знищити, дії зупиняться). Не для всіх людей є "слабка-точка-мотивація" для дій.
А коли без окремих слів, а по темі запитання загалом, то все написане в першому пості. І про бету, і про вільний час, і про ембед, і про білд процес, і про запит щодо коментарів з яких випливають всі відповіді на ваш пост окрім однієї... не написано "як знищити"
Але головне... як жити разом без знищення Бо всім є частина.

[ps]

З імперського це слово перекладається "слабка точка"

з не імперського це слово перекладається як "the reason of motion" - хто в який бік дивиться.
btw, я так розумію ви тут головний троль всія русі через що схоже топікстартер пішов з теми.

[BeSiDa]

А от на "як жити разом без знищення " не відповіли. Хоча це цікавіше. Жити не змінюючи вас. Бо всі важливі як є.

з не імперського це слово перекладається як "the reason of motion" - хто в який бік дивиться.

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

[trimbler]

яка саме у вас мотивація

Ви не зрозумієте. Бо використали слово "мотивація". З імперського це слово перекладається "слабка точка" (коли її знищити, дії зупиняться). Не для всіх людей є "слабка-точка-мотивація" для дій.
А коли без окремих слів, а по темі запитання загалом, то все написане в першому пості. І про бету, і про вільний час, і про ембед, і про білд процес, і про запит щодо коментарів з яких випливають всі відповіді на ваш пост окрім однієї... не написано "як знищити"
Але головне... як жити разом без знищення Бо всім є частина.

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

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

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

[BeSiDa]

спонсорів та інвесторів

Ви ж розумієте, що слово "інвестиція" є однаковим з "продаж компанії"?
Коли ви продали 10% будівлі, то інша людина матиме ключі від входу до 100% будівлі (або створюйте дві окремі юр.особи та обирайте правила їх взаємодії).
Після "інвестиції" ви більше не є власником, а замість вас власником є нова віртуальна сутність "збір акціонерів" (інвестор має частку акцій та права). І цей збір обирає "раду директорів" яка може вас виштовхати нафіг з проекту. І це можливо навіть коли у вас 90% акцій (серед інвесторів є люди, які все своє життя вивчали як забирати бізнеси в інших людей, наприклад вмовити вас взяти кредит, а потім нахрін вигнати всіх клієнтів і дочекатися коли ви самі все віддасте "за борги").
Як ви ставитеся до того, що проект більше не буде вашим? За мільйон або за безцінь?

Як ні, то або "донат" або "пілотний проект" (невеличкий старт з одним клієнтом, який згоден експериментувати). Бачив декілька запусків компаній "з нуля" через "пілотні проекти".

Або ще є "публічний шлях", але там свої особливості. Наприклад, одразу треба 3-5 прикладів різної теми, щоб не запам'ятали як "єдине можливе застосування" інструменту.

Тож якщо тема цікава з боку інвестицій чи партнерства, я відкритий до розмови

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