Существует ли дистрибутив без ада зависимостей?

несколько программ порезанных на миллион пакетов

Вот она, вся суть проблемы. Принудительная кастрация ПО! Браузер орёт во всю глотку: «Не дамся, гады, двести мегабайтов будут моими даже если я лишусь полужопия!».

Это обязательно нужно заюзать на сеге, она оценит. Или PS3? Раз там памяти больше - должна справится? Уверен, это та самая оптимизация, при которой всё обязательно запустится и будет работать, как часы. Да здравствует современная оптимизация!

очевидно

apt-get install all-hell

недавно запускал оригинальную первокваку на 12 дебиане - на удивление оно работает…

xnview из прошлого века на современном линуксе тоже работает…

может дело не в линуксе?

Как ново, ведь это же никогда не обсуждали!

Я вдруг понял, что поучаствовать в этом холиваре про самодостаточные пакеты интересно раза два-три. А дальше всё это очень скучно. Одни и те же стандартные аргументы. Одна и та же подмена тезиса «самодостаточные пакеты удобнее ада зависимостей» на тезис «качать с оффсайта исполнимый установщик удобнее, чем выбирать пакет из меню магазина приложений».

все файлы для программ хранятся в одной папке

Просто ставишь программы через Flatpak.

система полностью работоспособна без пользовательских программ (например, загружена из оперативки или с внешнего носителя, а весь пользовательский мусор подключается как отдельный диск или раздел )

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

это как у зумеров смотришь скрины рабочего стола: миллион папок, включая с экзешниками, диски не разбиты, ищут что-то только поиском. он может тоже ставит все подряд и забивает.

Мода на засранный рабочий стол была еще где-то в 2008.

Unixson, что там с тем самым линуксом здорового человека?

И да, ТС, я от себя добавлю, что поставить программы вместе с зависимостями есть несколько вариантов, но в них во всех интерфейс будет страшным. И вот это уже я не знаю, как побороть.

Дебиан делает бэкпорты.

хыхы, вредны зависимости пакетов. ну ок. скатертью дорожка :)
пойми простую вещчъ, зависмости это не дизигнерский плюшечка на обоях рабочего стола, которая может быть плохой, хорошей, в тсиле сальвадора дали или пикасо…
это техническая потребность програмного обеспечения - использование кучи своих и системных библиотек, от которых она зависит. ну никуда ты от них не отвертишься :) даже в контейнерах приложений лежат те же зависимости.

Нет, их можно положить вместе с программой.

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

какие камни возникают в этом случает можно почитать по снап- флат- апп- и прочим срачам :) там опытались не утыкаться в терминальный вариант и сделать чтото среднее. но посидет ьна двух стульях не получилось.

Stable API спасет отца русской демократии.

Скажите, а чем вас не устраивает опакечивание в стиле cargo?

Причем тут контейнеризация? Она не является обязательным условием отсутствия пердолинга.

Там ничего не попытались сделать. А AppImage получился нормально. Он работает. Единственная проблема - никто их не выпускает. Ну и стили он ломает, хотя я думаю это можно было бы обойти.

назови пакетизация, один фих.
обязательным условием отсутствия пердолинга с зависимостями пакета является наличие всех зависимостей внутре самого пакета :) или не ??
это в случае полностью свободного дистра.

или вариант полностью закрытого дистра, в котором используются пакеты только из самого дистра, и мейнтейнеры все такие хорошие и активные… :)

если аппимеджи никто не выпускает значит кому-то оне не нравятся :) твое взгляд не центр вселенной :)

FishHook, ржавина ?? не юзал. а что в них особенного ??

а что в них особенного

они решают сабсевую проблему, ваш КО

чоткое и конкретное заявление !! одобряю :)

Stable API спасет отца русской демократии.

Добро пожаловать в мир OpenSSL и libpng.

На лоре отираются адепты гайки. Возможно, это то, что вам надо.

Как установить старую версию питона на арч?)

Stable API и сертификация совместимого ПО.

man guix.

Кстати говоря, есть такое https://opennet.ru/tips/3100_gnu_guix_heritage.shtml, так что иксы будут жить вечно. Ave guix!

черт знает у меня 10 версий фаерфокса из /opt живут и не дерутся…

Так опт не опровергает моей точке зрения, а только подтверждает её.

практика подтверждает что домохозяйки свалили на планшеты и смартфоны,

И да, и нет.

а компутер с виндой

Живёт и здравствует. Народ всё также и ноуты и десктопы покупает — как только упирается в минусы плашметов.

Монитор, клавиатуру и мышку всё равно не заменить — они слишком хороши.

При чём тут сега-пёс3 для меня осталось загадкой. Смеркалось…

Вы хотели сказать «в 1998»?

это техническая потребность програмного обеспечения

Нет.

даже в контейнерах приложений лежат те же зависимости

Да, и тем не менее в целом контейнеры дублируют ПО — так как по итогу обеспечить применение только одной библиотеки всем консумерам оказалось невозможно фактически.

ну никуда ты от них не отвертишься

На мобильных ОС давно решено леерами-сдк и отсечением устаревших API/ABI.

Но тут десктопный линукс созданный по стандратной модели к несчастью никак не сможет предложить что-то новое — т.к. по сути нужна централизация или проработка очень сложного стандарта.

лучше ада чем раст или питон

вот недавно как раз наткнулся на чудесныя нанотехнологии: NanoLinux и предка его Tinycore

идея хорошая, но почему их разработчики по умолчанию ставят такой тонюсенький и мелкий шрифт, тексты на котором надо читать под лупой? во времена элт-мониторов с низким разрешением такое годилось, но с современными мониторами об такой текст только глаза ломать! и даже настроек dpi/шрифтов на видном месте нет

Если есть gcc, то есть и ada.

Flatpak подходит почти под все требования

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

Нубикам вообще не нужно этим всем страдать

Андроид.

Там никогда не было задачи стандартизировать и патчить разномастный софт с открытым кодом. Все зависимости идут вместе с apk по 200-300Мб и не пугают пользователя своим присутствием. Временные папки стандартизированы. Пакетов минимум, одно приложение один пакет. Разве что сторонних пакетов из aur нет.

чё только не придумают, лишь бы не портировать плагин под новую версию

Там портировали, но версия плагина под новую версию говно. Проще использовать старую, там все стабильно работает и есть не просит.

у меня все знакомые «не айтишники» и кто дома не работает с компа уже не не завязаны на компьютеры, хотя раньше, когда компьютер был центром развлечений, у все были и все активно использовали…

клавиатуру и мышку … они слишком хороши

для создания контента, а потреблять отлично можно на умном тельавизоре (алиса покажи сериал/мультики), планшете и смартфоне…

ах, да… у кого дели-школьники - там тоже есть компутер с виндой «для учебы» - мама в поверпоинте делает презентацию в школу, папа в ворде набирает реферат к уроку, сын играет :)

Проблема явно психологическая

Размазывание софта по всей файловой системе тонким слоем - это вполне объективный недостаток юникс-подобных систем. Увы - так «исторически сложилось» :(

В качестве костыля - помогает тщательное изучение используемого в дистрибутиве пакетного менеджера и приложение дополнительных усилий по поддержанию в корректном состоянии его базы данных об установленном софте. Увы - иногда усилия для этого требуются существенно больше чем чтобы просто собрать и запустить экстренно потребовавшийся софт. Например на днях мне внезапно потребовался софт для железячного программатора,называется IMSProg. https://github.com/bigbigmdm/IMSProg По уму надо было бы не просто его собрать и make install сделать,а заморочиться созданием правильного дебиановского пакета. Но на такой подвиг я был явно не готов,особенно учитывая что софт потребовался вот прямо срочно и пары часов на возню с пакетированием просто небыло. Теперь придется вычищать его из системы вручную. Благо он совсем немного «намусорил».

Главная проблема зависимостей - это динамически подключаемые библиотеки. И тут могут быть два подхода.

Скорее - две крайности. И та и другая - плохо. Истина как всегда где-то посередине. На мой взгляд логично иметь в качестве общесистемных такие базовые вещи как например libc. И даже наверно всякие широко используемые библиотеки типа QT. А вот всякую довольно редко применяемую экзотику - статически линковать в бинарник прикладной программы. А также и те библиотеки,о которых заведомо известна плохая совместимость между разными версиями.

каждая вонючая hello world программка в таком раскладе весит как полный дистрибут полноценной нормальной ОС , и столько же жрет

Насчет весит в смысле места на диске - да,согласен. Но дисковое место теперь дешевое в отличие от тех времен когда идею разделямых библиотек придумали и активно продвигали.

А вот насчет жрет - не факт. Во-первых в память грузится только используемый программой код. Во-вторых в линуксе существует возможность дедупликации одинаковых страниц ОЗУ,хотя насколько я знаю в популярных дистрибутивах она не включена по умолчанию. Всё хочу погуглить эту тему но всё руки не доходят.

это все хрошо пока не возникает необходимости:

установить что-то древнее

Всё совершенно верно сказано. Причем по мере распространения и внедрения компьютеризации - «древнее» будет встречаться всё чаще и чаще. Потому что компы периодически бывают в составе всяких программно-аппаратных комплексов где собственно комп лишь очень малая часть в цене этого комплекса. И производители склонны забивать на поддержку «старого» железа. Или просто банкротиться и исчезать.

установить что-то новое (в лучшем случае предложит обновить все зависимые библиотеки

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

зачем?

Затем,что в крупных сложных пакетах нередко в одной версии не работает(или криво работает) одно,а в другой это одно работает но не работает что-то другое. Глюк еще и может не/проявляться в зависимости от обрабатываемых данных.

Ностальгия?

Нет,совместимость и преемственность. Особенно актуально в всяких промышленных применениях вычислительной техники. Статическая сборка в этом случае помогает,но противоречит идее всеобщей динамической линковки,активно продвигаемой ее адептами.

Опять же зачем? Либо собери прогу с имеющейся у тебя версией

Вынуждает возиться с пересборкой вместо использования готового пакета с оттестированным бинарником.

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

Естественно мы тут говорим про экспертную область и про технически грамотных людей,а не про «обычных пользователей»,чье применение компов ограничивается игрушками и сидением в соцсетях. Но всё равно специалисты вынуждены тратить дополнительное время на решение этих проблем,вызванных злоупотреблением динамической линковкой. А рабочее время специалистов вообще-то стоит дорого.

Информации вагон и телега но разбираться лень

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

пользователь выходит с запросом куплю говно

Так любую готовую работающую вещь можно обозвать говном потому что неидеальности конструкции есть во всём и всегда. Тем не менее люди в большинстве случаев предпочитают купить готовое,а не заниматься самостоятельной сборкой. Просто потому что собирать всё самостоятельно - жизни не хватит. Вон даже gentoo с какого-то момента стали выкладывать собранные бинарники для особо тяжелых долго собираемых программ. Или вот пару десятков лет назад пересборка ядра была типичной операцией. Но потом ядро в составе дистрибутивов стали поставлять в таком виде чтобы пересборка в большинстве случаев не требовалась.

сейчас все это красиво делается через контейнеры.

А красиво ли? Можно ли например использовать общесистемную libc но что-то специфическое своё притащить в контейнере? По-моему нет. В результате перерасход ОЗУ из-за двух загруженных туда libc(одна общесистемная,вторая «контейнерная»).

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

Это как раз плохо и неправильно. Тупых вообще не надо бы допускать к компьютерам. Также как тупых водителей не допускают на дороги общего пользования. Но так как экзамены на компьютерную грамотность не реальны но неплохо было бы обеспечить чисто технический достаточно высокий порог входа. А не ориентироваться на самых неквалифицированных и не желающих обучаться пользователей(воинствующее невежество и есть признак тупости). Благо что большинство таких уже свалили на смартфоны и планшеты.

дистрибутив без ада зависимостей

Тема ада недостаточно раскрыта. В чем именно проявляется ад для условной убунту к примеру?

это восприятие новичков по поводу разорванности частей программы по всему диску

Новички тут никаким боком. Это объективный но исторически сложившийся недостаток.

зачем она именно так устроена: сильно мазать по дискам файлы?

На то когда-то десятки лет назад были объективные причины,связанные с ограниченностью емкости дисковых накопителей. Тех технических ограничений уже давно нет, однако /bin и /usr/bin совместили лишь недавно. А /bin и /sbin всё еще остались отдельными каталогами. Хотя исторически смысл /sbin был в static binary,то есть в бинарниках которые можно было запустить при не смонтированном /usr/lib. Так собирались всякие вещи типа fsck и прочего что нужно при починке сломавшейся системы. Всё это наследие тянется со времен СМ-1600 на которой я впервые познакомился с юникс-подобной ОС. Переделывать это сейчас ничуть не проще чем например устранить зоопарк единиц измерения - такое же махровое legacy. Вон систему СИ сколько внедряли,а футы с милями так никуда и не делись - наша авиация недавно на них перешла с метров и километров.

И я не представляю, как в 2020+ можно работать без apt-get install programmname(emerge/dnf).

Ты предпочитаешь убегать от реальности в которой миллиарды пользователей ПК так и живут.

Да, я тоже предпочитаю убегать от их реальности в мне более удобную. Если им там нравится - пусть живут,но меня не заставляют без пакетного менеджера обходиться.

Скорее всего твоя убеждённость строится на том что когда-нибудь линукс будет доминировать

Не надо линуксу доминировать. Пусть он остается системой для квалифицированных пользователей и для всяких там операторов(тоже кстати квалифицированных в своей области) которым мы будем настраивать и конфигурировать эргономичные рабочие места. А для тех кто не хочет обучаться эффективным методам работы - есть другие ОС.

это частая потребность сравнить, откатить неудачный апдейт.

Кстати да - как минимум дебиановский пакетный менеджер не имеет простого способа откатить неудачный апдейт.

Вот например заметка на эту тему: http://avari-unwilling.blogspot.com/2012/01/debian.html

У тебя много таких програм?

Обычно программ,версия которых критична - немного. Но это как раз те с которыми пользователь активно работает и поэтому знает зачем ему именно эта версия а не та. Например поставить последний KiCAD в Debian 11. Возни столько,что проще сидеть на том который в этом дистрибутиве предлагается по умолчанию. Благо без нововведений прожить можно.

Что это за 2-3 программы которые обязательно нужно ставить рядом в разных версиях?

У каждого продвинутого пользователя они свои. И как раз те,которыми он активно пользуется. Уж как минимум хотелось бы потыкать в новую версию прежде чем затирать работающую старую. А то ведь нередко бывает что увлекшись добавлением новых фич разработчики ломают что-нибудь нужное.