Дистрибутив для розробника?

[Володимир Лісівка]

Та почалося то ще раніше... коли "розділ користувача" (usr від слова user) відібрали в "користувача" і зробили ... системним. А потім знову відібрали... і знову...

Так, це наступний крок у еволюції дистрибутивів. Якщо раніше /usr був як зараз /usr/local чи /opt тоді як основа системи була в /bin та /lib, то тепер це частина системи, в яку розробники дистрибутивів не хочуть пускати сторонніх, тому що це значно збільшує витрати часу на підтримку дистрибутива, зокрема через потребу зворотньої сумісності. Коду стає більше з кожним випуском, а мейнтейнерів не стає більше. Можливо ШІ вирішить цю проблему.

[BeSiDa]

Якщо раніше /usr був як зараз /usr/local чи /opt тоді як основа системи була в /bin та /lib, то тепер це частина системи, в яку розробники дистрибутивів не хочуть пускати сторонніх, тому що це значно збільшує витрати часу на підтримку дистрибутива, зокрема через потребу зворотньої сумісності. Коду стає більше з кожним випуском, а мейнтейнерів не стає більше. Можливо ШІ вирішить цю проблему.

"
Та я про ще раніше... коли usr це був "домашній розділ користувачів" (ще до home і до "дистрибутив", може 80ті чи й ще раніше). Так потім usr/local (коли людина стала не тільки local, а ще й network)...
Навіщо стільки коду, коли більшість тільки бравзер юзає? ))
(хоча в них стільки депенденсі...)
І про сумісність з бравзером можна забути
А от "перекладати свої проблеми на ..." то таке... Вже краще мріяти як стати "кіборгом" та все самому повирішувати...

[Володимир Лісівка]

/usr як домашній каталог користувача був у першій (1969) редакції UNIX, а вже у третій редакції (1973) зʼявився каталог /usr/bin (як зараз /home/bin чи /usr/local/bin). Linux зʼявився у 1991-му, тому його це не стосується.

[yvs115]

> У атомарному дистрибутиві вся система оновлюється за один раз і є незмінною

не юзер частина дистрибутиву (sys part):
незмінною під час runtime - звідси immutable,
зазвичай одним з atomic updates всього sys образу - звідси атомарність

> користувачі мають встановлювати своє ПЗ через Flatpack-и (або змінювати базову ОС)

user part:
в якості системи пакетизації - flatpak чи snap (note: пз настількиж "своє" як і у випадку rpm чи deb), "базову ОС" - юзери не змінюють (додаткові restriction у вигляді uefi+sign як опція)

p.s. якщо "своє" - принаймні для development є можливість зібрати свій софт на target immutable дистро (і поставити в ~/.local)
pps. це все на практиці перевіряється - зараз як раз такого типу immutable дистрос в активній розробці, хоча є інші підходи (нп легкі на базі busybox)

[yvs115]

Та я про ще раніше... коли usr це був "домашній розділ користувачів" (ще до home і до "дистрибутив", може 80ті чи й ще раніше). Так потім usr/local (коли людина стала не тільки local, а ще й network)...

з immutable дистрибутивами - ідея схожа що була в bsd - sys_soft+other_soft:
системна частина дистрибутиву (ядро плюс весь базовий софт) та весь інший софт (те що йшло з pkgsrc ports ...)

Ідея розбивки на дві частини залишилася, але все решта по іншому - syspart стала immutable (під час runtime), userpart - стала повністю user (ставиться в $HOME)
В принципі root user як такий практично викреслюється - syspart image готується і атомарно заливається від виробника дистро, юзер софт ставиться контейнеризованим щоб юзер нічого не наставив і не поламав. Для функціоналу root-а не дуже вже є і місце і необхідність в таких дистро.
Все разом це виглядає як рух в напрямку подальшої комерциалізації як в популярних рішеннях для телефонів планшетів теліків і т.п.

Навіщо стільки коду, коли більшість тільки бравзер юзає? ))

браузерні рішення аля electron app - це швидка розробка яка з точки зору оптимальності та ефективного використання ресурсів - виглядає так собі...
Хоча неможливо не помітити що швидкість розробки корисна, що і підтверджує розповсюдженість і запит на вебпрограмування.

хоча в них стільки депенденсі...

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

[BeSiDa]

браузерні рішення аля electron app - це швидка розробка яка з точки зору оптимальності та ефективного використання ресурсів - виглядає так собі...
Хоча неможливо не помітити що швидкість розробки корисна, що і підтверджує розповсюдженість і запит на вебпрограмування.

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

Так от контейнери з сокетами це трохи ближче до того.

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

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

pps. це все на практиці перевіряється - зараз як раз такого типу immutable дистрос в активній розробці, хоча є інші підходи (нп легкі на базі busybox)

А що за дистрос?

[yvs115]

браузерні рішення аля electron app

не електрон апп, а в браузері апп

браузер app - окремий electron(chrome+node) чи не окремий - не принципово

Він змінює сприйняття середовища

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

А в бсд було що софт сам компілюєш як користувачу хочется (і кернел також, як базова фіча)

майже те саме і в лінуксах було - але вже зараз в лінуксах ядра самі майже ніхто не компілює, як і в bsd зараз ставлять бінарні пакети так само як і бінарно syspart включно з ядром. Хоча по ідеї збирати ніщо не заважає (якщо то не firmware bin blobs) що в лінукс що в бсд, а нп в gentoo (linux якщо шо) - наскільки пам'ятаю і досі прийнято збирати софт на терміналах користувача.

А що до телефонів і т.п. там мова не про те що "рут не потрібен", а про те що взагалі "ти не є користувачем і не власник пристрою"

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

А що за дистрос?

нп gnomeos і tinycore - на двух протилежних immutable полюсах ресурсоємкості-зручності

[BeSiDa]

браузер app - окремий electron(chrome+node) чи не окремий - не принципово

Мабуть у вас погляд розробника. Тоді для вас не принципово. А от з точки зору розвитку "взаємодії" різниця значно більша ніж ООП (де програму з середини розділили на окремі нібито "приватні" контейнери (класи) чи то "процеси" (де пам'ять комп'ютера розділили на нібито "приватні" частини для кожного інстанса завантаження (у пам'ять) програми)).
Різниця... "яке саме API" єдине можливе в програмі (а через нього створення уявної "приватності").

От до прикладу ви знайомі з API X11? Виконували колись одну програму на одному компі яка б відкрила 10 вікон на 10 різних X11 серверах? (в кожному вікна не "приватні", а "публичні" (будь яка програма може читати та змінювати будь що в інших вікнах)).

як і в bsd зараз ставлять бінарні пакети

Там все ще є "порти" (файли де скачати джерела та бсд патчі до тих джерел) і в бінарних лише мала частина всього що є в портах.

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

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

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

[yvs115]

Мабуть у вас погляд розробника. Тоді для вас не принципово. А от з точки зору розвитку "взаємодії" різниця значно більша ніж ООП (де програму з середини розділили на окремі нібито "приватні" контейнери (класи) чи то "процеси" (де пам'ять комп'ютера розділили на нібито "приватні" частини для кожного інстанса завантаження (у пам'ять) програми)).
Різниця... "яке саме API" єдине можливе в програмі (а через нього створення уявної "приватності").

З моєї точки зору - основною метою загортання в браузер (чи в окремий браузер чи в браузер+webpage) - є швидка_веброзробка+кросплатформа_по_дефолту, бо базовий функціонал (у вигляді контейнеризація+гарантований_рантайм+іноді_кросплатформа) доступний іншими способами також (нп більш легкі невеб рішення з snap/flatpak).

От до прикладу ви знайомі з API X11?

На рівні програмування спершу з xlib, потім з xcb, - було трохи, але це все колись. Зараз вже з використанням фреймворків (нп gtk, qt) практично не думаю що там під капотом - xorg xwayland чи wayland.

Там все ще є "порти" (файли де скачати джерела та бсд патчі до тих джерел)

- і в бсд (нп freebsd ports, netbsd pkgsrc, etc.) і в лінукс є можливість збирати з sources (в дебіанах нп буває збираю з 'apt-get -b source' чи 'dpkg-buildpackage' - коли щось поправити чи подивитись треба, але то рідкість з сирців)
- і в бсд (нп freebsd pkg, netbsd pkgin, etc.) і в лінукс (нп debian apt, etc.) є можливість роботи з бінарниками без втрати часу і розгортання dev середовища з/для сирців.

На сьогодні чи хтось ставить пакети з сирців в linux чи bsd? Думаю буває таке, але рідко. Наскільки мені відомо - в основному працюють (і я не виключення) з пакадж-менеджерами і відповідно готовими бінарниками.

в бінарних лише мала частина всього що є в портах.

тут напевно щось з misunderstanding - що саме є в ports чи pkgsrc - і немає вже зібраного і доступного через cli пакадж-менеджер?

От "нічого не поламає системного" це і є визначення "не власник"

З визначеннями та термінологією в цих пунктах я пас. Було тільки відносно чому - модель софта з immutable дистрибутивами та розбивкою на дві частини - зручна у відповідному ракурсі.

[res2500]

я робив, в WSL2 з pkgsrc, але поставив його в режимі що можна робити від користувача, добавляв свої пакети з даними, створював свої, приклад тут :
https://chiselapp.com/user/res2500/repository/pkgsrc/index

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

[Володимир Лісівка]

На сьогодні чи хтось ставить пакети з сирців в linux чи bsd? Думаю буває таке, але рідко. Наскільки мені відомо - в основному працюють (і я не виключення) з пакадж-менеджерами і відповідно готовими бінарниками.

Розробники дуже часто ставлять пакети з сирців (на купі різних мов програмування). Драйвери деякі поставляються і компілюються з сирців (через akmod). Деякі дистрибутиви для розробників поставляються тільки в сирцях.

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

[yvs115]

> Розробники дуже часто ставлять пакети з сирців
>
  окремі - можливо, всі - ні (якщо linux - навіть в gentoo не все в source)

p.s. основний point був що в bsd не з бінарниками працюють (що зазвичай не так)
 

[yvs115]

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

так, але... поза netbsd не дуже часто використовується (і cli пакадж-менеджер для пакетів зібраних з pkgsrc: pkgin)

я робив, в WSL2 з pkgsrc, але поставив його в режимі що можна робити від користувача, добавляв свої пакети з даними, створював свої, приклад тут :
https://chiselapp.com/user/res2500/repository/pkgsrc/index

В wsl мабуть debian - якщо так то зручніше булоб з його рідним deb форматом працювати (як і з його репозиторіями).
Якщо всеж в linux з pkgsrc - то системне першоджерело 'pkgsrc.org' і користувацьке work-in-progress 'wip.pkgsrc.org' (wip і для тестування і звичайних користувачів, і можна як зазвичай з git під своїм аккаунтом).

[res2500]

так, але... поза netbsd не дуже часто використовується (і cli пакадж-менеджер для пакетів зібраних з pkgsrc: pkgin)

як пишуть в документації

other supported platforms
Code exists in pkgsrc to support 20+ Unix-like operating systems and 15+ CPU architectures.

Operating systems that receive occasional testing include FreeBSD, OpenBSD, DragonFlyBSD, MINIX 3, SCO OpenServer/UnixWare, HP-UX. See the various platform-specific README files in bootstrap/ for more information.

питання стоїть чи пакет є на потрібну архітектуру

В wsl мабуть debian - якщо так то зручніше булоб з його рідним deb форматом працювати (як і з його репозитор...

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

[yvs115]

як пишуть в документації
    other supported platforms

не думаю що база тестування поза netbsd суттєва. Доречі якось бачив спроби підбору пакаджінг для linux дистро який пакування не мав - там трохи прижився deb (хоча були і спроби з pkgsrc). При повній відсутності свого системного пакетування - як на мене то bsd-make та pkgsrc також зручні (бо знайомі достатньо).

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

Документація скрізь по ідеї має бути відкрита. Якщо брати взагалі - то зазвичай пакетування на нову пакадж-систем відбувається на базі прикладів, якщо того недостатньо - потім дока, ще недостатньо - форуми і чати. Якщо порівнювати по легкості використання (якщо чогось специфічного чи продвинутого не треба) - то напевно найлегшими зі старту юзати (з тих які зустрічалися) то був формат APKBUILD(alpine)/PKGBUILD(arch). Pkgsrc як і ports - не самі важкі та не самі легкі для використання.
Одним словом (зрідка займаючись пакетуванням для себе в доволі різних системах) - використання рідної системи пакетування для того чи іншого дистро/os це найзручніша опція (і по часу і щоб не втрачати час на адаптацію нерідної системи пакетування зразу, як і потім на несумісність яка десь та пробивається), незважаючи що інші системи пакетування можуть бути легшими в різних ракурсах.

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