Сайт здох

[BeSiDa]

створити репозиторій пакетів кроссплатформенний, ядрі лінукс немає avr-gcc, kicad, все що потрібно користувачу, він потім ставить, або збирає

Вже існує. Кросплатформенний. На базі контейнерів. Одразу готовий до запуску. Називається снап-сторе або флетпак.

Код: [Вибрати]

kicad    9.0.6             sethh     -         Electronic schematic and PCB design software
uconfig  v0.4-60-g59a3e34  ppd       -         Datasheet pinout extractor from PDF and library Stylizer for KiCad


[BeSiDa]

Не згоден з іншою частиною про "користувачу потрібні програми"

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

Не згоден з вашим визначенням користувача.
Ви чомусь обираєте лише частину з усіх користувачів і кажете "користувачу потрібні" замість "_частині_ з користувачей потрібні".
Дехто з них є програмістами чи адмінами.
Декому з них досить шелл скриптів та системних інструментів (налаштувати свій роутер, наприклад).
Дехто Пайтон програміст.
У системі дофіга всього в базовій його формі (особливо Лів дістр).
Але тій частині, якій "пофіг" потрібні не програми, а "виконати свою задачу" і пофіг "програмою" чи ні.

[BeSiDa]

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

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

Є імутабельні дістри, що існують без "пакетів". Там є "базова система" та "флетпак" контейнери з "файловой системою" яка монтується "як є" а не "розпаковується" з "пакетів".

Автори ГІМП та інших викладають "архів з сорцами", а не "пакет". І тільки "під окремий дистр" можуть робити "пакет дистрибуції". А можуть не робити.

[res2500]

Ви помиляєтеся.
"пакет" є не всюди. Це лише один і не обов'язковий механізм дистрибуції.

це зробили в лінукс ще для тих 2000-х років, коли інтернет мало того що був повільний, так щей не всюди він був, тому і були дистрибутиви які йшли з купою програм, OpenOffice, IDE, python, perl відповідних версій, та інші програми, був свідком коли людина ставила на ПК три дистрибутиви, бо на одному був офіс який працював, на другому ICQ клієнт, третій автоматом підключався через мобільний інтернет, бо ті два інші відмовлялись, навіть в 2009 році ще не всі розуміли що таке пакет і як їх ставити, репозиторій, та з таким інтернетом, в той час не всі могли собі дозволити таке щастя, ставити пакети з репозиторію, там вихід в інтернет, уже вважався супер.
 Великим мінусом було, дистрибутив був з старими версіями пакетів, які йшли по замовчуванню, що в 2012 це вже було дикістью, робити дистрибутиви по тематиці, типу для графічних потреб, для відео та звуко редакторів, для безпеки, ще до Kali linux, був DEFT linux,

Можете компілювати програми чи копіювати бінарники без пакетів.

подумайте що ви написали, пакет це як програма вихідна з своїм форматом elf, exe ... Компілювати  бінарники, навіщо, якщо вони вже зкомпільовані, навіть якщо завантажується tgz, чи  tar.gz формат, то там не обовязкова має бути бінарні пакети, а може бути і код бібліотеки чи пакету, версії кодів пакету ще розміщають на серверах, бо якщо щось не буде працювати, запасний варіант є, але це вже залежить від того хто портує пакет.
 Якщо пакетний менеджер просто копіює у вказані папки пакети, це поганий пакетний менеджер, а pkg зараз це все передбачає, конфлікти версій, сумісність з версіями, саме тому відмовились від утиліт типу pkg_*.
 

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

Ви володієте старими даними, десятилітньої давності, коли вийшла в 2012 році pkgng, вона тестувалась і був вибір, користуватись pkg чи стандартними утилітами pkg_*, попереджали що буде перехід, в 2014 році утиліта стала по замовчуванню, і лише коли була нова версія, то обновлялась версія pkg, де в терміналі все писалось, після того ніякого скачування, а це вже пройшло 12 років, як не актуально.

Є імутабельні дістри, що існують без "пакетів". Там є "базова система" та "флетпак" контейнери з "файловой системою" яка монтується "як є" а не "розпаковується" з "пакетів".

який за контейнерів і своєю особливістю займає багато місця та повільно працює https://discussion.fedoraproject.org/t/flathub-fastly-cdn-have-slow-connection-in-pl/170415
 

Це триває вже більше року, відколи я почав гратися з Linux для робочого столу, на всіх дистрибутивах, які я пробував: Flatpak жахливо працює, аж до неможливості користуватися.
 RPM, APT, що завгодно… все працює, я можу встановити Krita з RPM за лічені секунди. Встановлення невеликої утиліти з Flathub може зайняти 10-20 хвилин. Вона завантажується зі швидкістю десятки КІЛОБАЙТІВ за секунду. Щоразу, коли я встановлюю нову Linux, мені хочеться кричати від люті.
 Я знову застряг… Роблю чисту установку F43, і я не можу встановити жодного Flatpak протягом останньої години чи близько того. Вони просто падають до одного кілобайта і зрештою зависають.
 Є багато подібних скарг на інших форумах, на Reddit, на Github і жодної відповіді. Чому ця система така жахлива? Чому вона досі існує, якщо не працює? Якщо Flatpak — це майбутнє Linux, то це справді погано.
 Я б хотів просто цього уникнути, але не можу, оскільки багато програм доступні лише у вигляді Fatpaks, що дуже прикро.
 Іноді він випадково підвищується, я короткочасно бачу кілька МБ на секунду. В інший час він повзає.

отже бачимо, всюди є проблеми, flatpack їх не вирішує, контейнери теж жруть ресурси і пам'ять

Автори ГІМП та інших викладають "архів з сорцами", а не "пакет".

https://www.gimp.org/downloads/

Код: [Вибрати]

Current Stable Version
The current stable release of GIMP is 3.0.6 (2025-10-05).
Show downloads for GNU/Linux | macOS | Microsoft Windows | Allі на сторінці знизу якщо треба код Source for version 3.0 (Stable) в appimage коду немає, готові пакети для запуску, думаю для flatpack. Я і не здивований, що навіть ізоляція в лінукс не допомогла
 

[BeSiDa]

Дані нові, 2025.
Якщо хочете, можете перечитати те що я написав з урахуванням що це 2025го року дані, а отже ... у вас інше розуміння того ще є

[res2500]

Дані нові, 2025.

які у вас там свіжі дані
https://wiki.freebsd.org/pkgng/CharterAndRoadMap

Код: [Вибрати]

30 April 2014          EoL 8.3-RELEASE        Earliest date for final removal of pkg_installякщо ви завантажили старий дистрибутив і володієте такими даними, це не проблема pkgng

[yvs115]

Іноді він випадково підвищується, я короткочасно бачу кілька МБ на секунду. В інший час він повзає.

отже бачимо, всюди є проблеми, flatpack їх не вирішує, контейнери теж жруть ресурси і пам'ять

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

flatpak/snap головна мета - надати гарантований runtime/environment (причина відома чому то так актуально стало), контейнери природньо що потребують додаткові ресурси у порівнянні з софтом з стд пакетів, але більш оптимально у плані ресурсоємності якщо порівнювати з docker чи з electron рішеннями

[res2500]

але більш оптимально у плані ресурсоємності якщо порівнювати з docker чи з electron рішеннями

якщо по замовчуванню дивитись, docker чи інша система ніби бере більше, а з сторони flatpak/snap, це прожирає ресурси, кожна програма завантажується з всіма so i elf, завантажте Appimage і гляните, мати декілька версій програми, це мати декілька більше місця, в мега байтах чи гігабайтах, це залежить від пакету. Окрема віртуалізація, не вирішує проблем, це улюблена тема сисадмінів,впало, в docker запустити

[yvs115]

але більш оптимально у плані ресурсоємності якщо порівнювати з docker чи з electron рішеннями

якщо по замовчуванню дивитись, docker чи інша система ніби бере більше, а з сторони flatpak/snap, це прожирає ресурси, кожна програма завантажується з всіма so i elf

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

завантажте Appimage і гляните

до чогото тут appimage - про нього і не згадувалося (було відносно snap/flatpak)

Окрема віртуалізація, не вирішує проблем, це улюблена тема сисадмінів,впало, в docker запустити

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

[res2500]

а до чогото тут appimage

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

Якби нічого не вирішувало - то не використовували би зовсім.

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

[yvs115]

а до чогото тут appimage

це загальний формат пакунка для лінукс

якщо мова є про використання сумісно якихось частин і розгляд у такому ракурсі flatpak/snap - то appimage це кудись не туди
 

Якби нічого не вирішувало - то не використовували би зовсім.

вже стараються менше використовувати, наприклад той же doker

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

[res2500]

якщо мова є про використання сумісно якихось частин - то appimage це кудись не туди

це що б глянули, наприклад, скільки в папці usr/bin, usr/lib/, а в  usr/share щей залежності типу QT5, python і це на кожну програму

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

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

Якщо Flatpak — це майбутнє Linux, то це справді погано.

[yvs115]

якщо мова є про використання сумісно якихось частин - то appimage це кудись не туди

це що б глянули, наприклад, скільки в папці usr/bin, usr/lib/

Використовуєте нп gtk - під то відповідної версії snap нп, який використовується іншими пакетами також.
І чи треба то порівнювати з all-in-one підхід від appimage (і ракурсі сумісного використання на кожну прогу)?

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

чи витримає користувач, це інше питання, вище я викладав посилання на  дискусію flatpack

Не інше, якщо мета надати ос-дистрибуцію софта для загального користувача (не адміна і не програмера) - то це все пов'язано. Шлях immutable база + контейнеризований софт зі store - то шлях яким вже пройшли інші, та концепт такого типу починають також використовувати і в деяких лінуксах дистро.

Якщо Flatpak — це майбутнє Linux, то це справді погано.

Це називають різноманіття - будуть дистро з доволі різними пакетизаціями-контейнерізаціями-etc під різні потреби. Однієї універсальної опції для всіх на всі випадки не існує, спроба загнати всіх нп чи тільки в контейнери чи тільки в стд пакети чи тільки в електрони - ото дійсно погано.

[res2500]

І чи треба то порівнювати з all-in-one підхід від appimage

для того щоб побачити скільки місця це займе

Це називають різноманіття - будуть дистро з доволі різними пакетизаціями-контейнерізаціями-etc під різні потреби.

прийде час, і зоопарк дистрибутивів визнають помилкою в роботі, крім сайтів і власних дистрибутивів лінукс, які робили в Україна, з 2000-х років, результат глобального переходу на лінукс не бачив, спроби людей освоїти були, але терпіння на довго не вистачало

[yvs115]

І чи треба то порівнювати з all-in-one підхід від appimage

для того щоб побачити скільки місця це займе

розглядаючи використання чогонебудь сумісно з flatpak/snap і при тому оцінювати з all-in-one підходом не має особливого сенсу. Роглядаючи flatpak/snap - логічно дивитися рішення з ними, чи принаймні аналогічними підходами (до яких allinone appimage не відноситься).

Це називають різноманіття - будуть дистро з доволі різними пакетизаціями-контейнерізаціями-etc під різні потреби.

прийде час, і зоопарк дистрибутивів визнають помилкою в роботі, крім сайтів і власних дистрибутивів лінукс, які робили в Україна, з 2000-х років, результат глобального переходу на лінукс не бачив, спроби людей освоїти були, але терпіння на довго не вистачало

Різноманіття надає можливість природнім чином еволіціонувати те у чому є потреба, тобто дистро якісь відійдуть якісь більш популярні стануть, то цілком природньо. А рішення коли все з одним наскількиби-правильним-чи-неправильним-небув-він підходом призводять до тихого затухання (як нп gap між bsd та linux як збільшувався, так і (imho) буде надалі збільшуватися).