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

отписался мейнтейнеру он перевел библиотеку из депеденси в рекомендации.но это повезло

Это не просто повезло, это вообще уникальный случай. Чтобы мейнтейнер не только не проигнорировал письмо,а еще и пошевелился и что-то сделал. У меня тоже такой случай был. Один. За 27 лет пользования линуксом.

Зачем заходить в отдельный каталог на диске, например, /etc? Потому что там конфиги. Зачем они там? Потому что это «удобно». (Нет, не прикалывает

Справедливости ради - и в линуксе наметилось движение в сторону отдельных каталогов для конфигов именно пользовательских программ. Я имею в виду /home/username/.config/programname Соответственно,в общесистемном /etc лежат конфиги системы и системного софта,а какой-нибудь kicad или gimp держат свои конфиги в отдельном подкаталоге домашнего каталога пользователя.

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

Кстати да! Держу xnview версии 1.70 из 2005 года ради только одного реализованного там фильтра gammasat от Terry Vantreese, замену которому за два десятка лет так и не нашел. Как и реализацию в свободном софте который можно было бы собрать под современный линукс. Однако та древняя версия продолжает работать. Надо только запускать сразу с аргументом командной строки в виде имени открываемого файла. Если запустить без то открыть файл уже не получится - меню File-Open почему-то в этом случае не вызывается. А вот если с файлом - то потом работает как обычно,можно и другой открыть.

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

Только те кто действительно упирается. И таких меньше чем тех кому хватает планшетов. Рынок ПК сокращается если верить статистике.

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

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

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

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

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

А теперь представь дистр построенный на аппимиджах. Что у тебя каждая сраная программка запускается в среде собственных динамических библиотек. Броузер, почтовик, каждый редактор, какие-то графические приблуды.

Таким образом создается технически эффективная программная среда работающая быстро и эффективно

Только в том случае, если прикладные программы тоже пишут грамотные инженеры. Пример: julia тащит свой llvm, а не использует системный, иначе возникают проблемы.

Пользуясь случаем напишу такое короткое эссе на эту тему.

До меня дошло, почему в Linux нет самодостаточных пакетов, почему нельзя обстарять программы, бэкапить программы и их настройки, ставить несколько версий одной программы. Почему нет специализированного софта с маленькой аудиторией, а оставшийся софт всегда несвежий. Почему надо конпелять.

Есть такое понятие «программный продукт». Не любая программа для ЭВМ является программным продуктом. Это то, что понятно как использовать. Это может быть что угодно - ОС, приложение, библиотека, утилита ... К этому есть инструкция, как это установить, запустить, удалить. Есть какой-то предполагаемый сценарий использования. Если это какая-то библиотека или другой полуфабрикат для производства софта, то тоже написано, как ее подключить, как собрать и т. д.. Написано, для какого железа этот продукт, с какими другими продуктами его можно или нельзя использовать. Как бы то ни было, у пользователя есть некая граница ответственности, ему что-то нужно знать, но кроме этого ему ничего знать не нужно. Программным продуктом например является исполнимый установщик для Windows с инструкцией, как нажать «Далее» N раз, или приложение для Android в Google Play.

Так вот большинство прикладных программных продуктов бывают для каких-то платформ. Есть такая дихотомия «платформа-приложение». Android - apkшка для Android (в маркете или на стороннем сайте), Windows - программа для Windows, PlayStation - диск для PlayStation, Famicom - картридж для Famicom ...

А в GNU/Linux нет платформы и приложений. Тут есть дистрибутив - единая, неделимая, монолитная программа-мультутул, черный ящик. Это ОС со встроенными приложениями, причем у них у всех полно разделяемых файлов. Программа не бывает для Ubuntu, Debian, Slackware, Alt, Fedora, она бывает в составе чего-то из этого. Если требуемой программы нет в составе вашего дистрибутива, то всё, печаль беда. Не предполагается, что пользователь будет пытаться ее туда как-то прикрутить.

Если это понять, то отпадают все вопросы. Мы не требуем от одной версии Сони Вегаса, чтобы там работали DLLки от другой, или вовсе чтобы там работали плагины от другого продукта. Тут продуктом является дистрибутив, а не программа. Разработчики не выпускают программы для Linux за редкими исключениями. Они выпускают программы для Windows и исходники для всего. В принципе в мире опенсорса исходники тоже рассматриваются как продукт, но это полуфабрикат, это не готовый продукт.

Что остается пользователю? Да ничего. Или конпелять и тогда Linux будет соответствовать стереотипам о себе. Или пользоваться дистрибутивом как мультитулом. Тогда дистрибутив надо выбирать по принципу, чтобы в его составе были все нужные программы и они работали без багов. Да, такого теперь обычно не бывает.

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

для версии 1.14 я устанавливал древние шрифты 75dpi - в репах дистрибутивов они есть, но по понятным причинам по дефолту обычно не установлены. А так есть набор 75dpi и 100dpi - мне хватило только первого

xfonts* или fonts-bitmap* или около того…

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

для Ubuntu, Debian, Slackware, Alt, Fedora

беру бинарный фаерйокс, оно работает на всех этих дистрибутивах…

кто делает не так?

я?

фаерфокс?

или все же ты написал какую-то хрень ? :)))

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

Зачастую им требуются разные версии библиотек, причём бывает так, что нельзя новую версию использовать вместо старой. То есть, тут получается «всё своё ношу с собой», что увеличивает занимаемые объёмы как оперативной памяти, так и hdd/ssd, замедляет время, как минимум загрузки и т.п.

Ну а так тогда смотреть на дистрибутивы с каким-нибудь flatpak. Такая вот ещё штука есть, но я не пользовался: http://magos-linux.ru/

беру бинарный фаерйокс

damix9 пишет:

Разработчики не выпускают программы для Linux за редкими исключениями.

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

я устанавливал древние шрифты 75dpi - в репах дистрибутивов они есть, но по понятным причинам по дефолту обычно не установлены.

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

у нас

У кого у вас?

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

ну попробуй 100dpi :)

Никто в снапах и флэтпках с аппимиджами ничего статически не линкует.

А я про них и не говорил. Я говорил о том,что экзотические редко используемые библиотеки а также те у которых известна проблема несовместимости версий надо статически линковать в программу. Понятно что в нее не надо линковать libc.

Кстати,при статической линковке в бинарник попадают только те объектные модули из .a файла-библиотеки которые реально используются. Если же линковка динамическая то программе потребуется притащить весь .so файл с собой даже если из него используется одна функция. И загрузчику придется при запуске заниматься настройкой адресов всего этого .so файла что увеличит время запуска.

А теперь представь дистр построенный на аппимиджах.

Это тоже крайность и это плохо как и любая крайность.

И все это месиво не будет иметь никаких преимуществ статической линковки а будет тупо жрать твой ресурс.

За дисковое место и за оперативную память я уже один раз заплатил и они у меня есть. Причем вот прямо сейчас на этом компе вижу что используется 42% ОЗУ и 51% диска. Сейчас главный ресурс потребление которого необходимо оптимизировать - это моё время. Потому что я не могу его купить. Если я буду иметь возможность экономить время на разбирательстве с зависимостями за счет большего расхода памяти - это будет совсем даже не плохо. И мне таки не хватает в Дебиане простого способа поставить новую версию программы рядом с заведомо рабочей и активно используемой старой вместо того чтобы старую сразу затереть а потом мучительно откатывать все внесенные при апгрейде изменения если новая версия окажется глючнее и/или неудобнее старой.

зависимостями за счет большего расхода памяти

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

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

Как работает снап я точно не знаю. У флатпака же есть своя концепция рантаймов, куда оно втаскивает зависимости сразу пачками. Много приложений — и всего несколько рантаймов.

На деле, конечно, оказывается, что такая стратегия даёт выигрыш только если у тебя этих флатпаков в системе выше крыши…

А из-за того, что флатпаком иногда пользоваться просто невозможно больно, критическая масса не набирается.

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

Мне кажется, проблему можно в большой степени разрешить, если на этапе сборки контейнера strip’ать все неиспользумые символы в динамически линкуемых библиотеках. Пакеты должны довольно сильно сжаться.

Это всё ещё никак не спасает от сошек, линкуемых в рантайме через libdl — но это уже не так страшно, учитывая, что обычно через него линкуют только всякого рода плагины — а там уже и стрипать нечего.

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

Ну, это я фантазирую. Не уверен, будет ли оно так хорошо работать на практике. =)

За дисковое место и за оперативную память я уже один раз заплатил и они у меня есть.

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

И мне таки не хватает в Дебиане простого способа поставить новую версию программы

В генту это проще - программы болеющие такой версионностью идут в слоты.

при динамической линковке библиотека грузится в память полностью вне зависимости от того какая часть её используется

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

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

Примером такой библиотеки может быть libc. Вот ее выгодно иметь в виде динамической.

В генту это проще - программы болеющие такой версионностью идут в слоты.

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

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

Хочешь флэтпачить - еще неоднократно заплатишь.

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

И примеры разумного подхода к линковке существуют. Выше там уже упоминалось xnview,так вот у меня версия 1.70 от 2005 года работает в Дебиан 11. Динамически в ней слинкованы следующие библиотеки:

ldd xnview
        linux-gate.so.1 (0xb7fc8000)
        libXt.so.6 => /lib/i386-linux-gnu/libXt.so.6 (0xb7f34000)
        libX11.so.6 => /lib/i386-linux-gnu/libX11.so.6 (0xb7de2000)
        libXext.so.6 => /lib/i386-linux-gnu/libXext.so.6 (0xb7dcc000)
        libXp.so.6 => /lib/i386-linux-gnu/libXp.so.6 (0xb7db6000)
        libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xb7beb000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7ae7000)
        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7ac8000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb78e0000)
        libSM.so.6 => /lib/i386-linux-gnu/libSM.so.6 (0xb78d5000)
        libICE.so.6 => /lib/i386-linux-gnu/libICE.so.6 (0xb78b8000)
        libxcb.so.1 => /lib/i386-linux-gnu/libxcb.so.1 (0xb7888000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7882000)
        /lib/ld-linux.so.2 (0xb7fca000)
        libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb7878000)
        libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xb7860000)
        libXau.so.6 => /lib/i386-linux-gnu/libXau.so.6 (0xb785b000)
        libXdmcp.so.6 => /lib/i386-linux-gnu/libXdmcp.so.6 (0xb7854000)
        libmd.so.0 => /lib/i386-linux-gnu/libmd.so.0 (0xb7845000)

Что слинковано статически - так просто не определить. Но главное что программа работает уже два десятка лет и переносится в новую систему простым копированием. Вот могут же сделать когда хотят…

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

LibreOffice, Gimp, Inkscape, Blender, тысячи их.

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

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

Примером такой библиотеки может быть libc.

Или libX11. Но сейчас что-то свои костыли пилят, вместо того чтобы мыслить рационально. Или как вариант тулкит для графики, если весь графический софт в системе будет на одном тулките.

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

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

https://en.wikipedia.org/wiki/GoboLinux

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

Я таки нашел! Называется GoboLinux. Вот что про него пишут: https://ru.wikipedia.org/wiki/GoboLinux К сожалению, нет сборки для 32-битной архитектуры:(

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

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

у wandrien спроси, если праивльно ошибаюсь

на рабочей винде ничего подобного нет от слова пи-ец сафсем.

есть куча сторонних программных продуктов (за бабки), которые дают возможность «следить» за актуальными версиями, установленным программ. Тот же касперский, причём там есть возможность следить только за обновлениями безопасности или за всеми новыми версиями. Это я к тому, что в винде своя идеология, и подходить к ней с мерками linux, тоже самое что подходить к linux с мерками вынды.

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

Как раз таки в debian прыгать по версиям программ очень просто. Был бы deb пакет, а все остальные команды +- простые.

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

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

пока есть более важные дела так скажем 😞

Да полно софта на линукс. Вскод, идея, жлинк это то чем я пользуюсь. 100500 игор. Ну не винда, конечно, вроде никто и не спорит. Но софт есть. Как правило распространяемый тарболлом.

А концепция дистрибутива это ошибка. Но такое время, пока так.

PC-BSD когда-то была такой.

Если соблюсти всё это, то будет уже не Unix-like. Нужные версии софта компилируют из сорцов, просто не делай make install.