LINUX.ORG.RU

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

 , ,


0

2

Хотелось бы найти такой дистрибутив, в котором:

  1. все файлы для программ хранятся в одной папке
  2. все файлы для для системы в другой папке
  3. можно устанавливать разные версии программ
  4. можно собирать сторонние пакеты из AUR, например
  5. система полностью работоспособна без пользовательских программ (например, загружена из оперативки или с внешнего носителя, а весь пользовательский мусор подключается как отдельный диск или раздел )
  6. в системе минимум пакетов.

Одна из частичных реализаций подобной схемы - переносные программы, но меня не прикалывает, что они создают свои «временные» папки и файлы непонятно где. Да-да, я нубик и искренне не понимаю, где искать те же файлы и папки от эмулятора PS3, когда программа запущена. Нужно куда то в дебри /tmp лезть, а не открывать одну папку рядом с бинарником, в которой бы лежал весь мусор.

К слову, винда тоже не святая, размазывает по всему диску любой софт, даже портабельный. АРРРХ!

Ответ на: комментарий от t184256

Скорей физическая, ибо я ленивый пингвинус, мне искренне в лом искать конфигурационные файлы, ярлыки, бинарники, временные файлы в разных местах непонятно зачем, ещё и количество пакетов всегда переваливает за сотку, а пользуюсь я от силы 10))

Reptile
() автор топика
Ответ на: комментарий от Reptile

Зная название пакета, можно из любого пакетного менеджера достать полный список файлов, которые в него входят. Что касается временных файлов, то это вообще не под контролем дистрибутива — программы куда хотят, туда и пишут (если права есть). Патчить каждую стороннюю программу, чтобы она писала «куда положено», никто не станет. Единственный более-менее рабочий способ это обойти — делать для каждой программы сэндбокс со своей изолированной файловой системой, на манер Apple и Android. Но это уже может выбесить пользователей:)

annulen ★★★★★
()

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

Подход здорового человека (скажем так инженера) - библиотеки являются частью. системы, а прикладные программы собираются так чтобы пользоваться библиотеками из состава системы. Таким образом создается технически эффективная программная среда работающая быстро и эффективно.

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

Подход здорового человека (скажем так инженера) - библиотеки являются частью. системы, а прикладные программы собираются так чтобы пользоваться библиотеками из состава системы. Таким образом создается технически эффективная программная среда работающая быстро и эффективно.

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

Kolins ★★★★★
()
Последнее исправление: Kolins (всего исправлений: 1)
Ответ на: комментарий от Qui-Gon

Подход здорового человека (скажем так инженера) - библиотеки являются частью. системы, а прикладные программы собираются так чтобы пользоваться библиотеками из состава системы. Таким образом создается технически эффективная программная среда работающая быстро и эффективно.

Может такой подход и быстр, и эффективен, но диск засирает он не менее быстро и эффективно.

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

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

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

Reptile
() автор топика
Ответ на: комментарий от Kolins

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

зачем?

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

Ностальгия? Ну собери статически.

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

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Reptile

Может такой подход и быстр, и эффективен, но диск засирает он не менее быстро и эффективно.

Вообще не засирает. Есть ровно то что нужно и ни одной лишней либы

Ну так пусть инженеры нормальные возьмутся, а не капиталистические: вс

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

А то сейчас в парадигме первого подхода среднестатистический пользователь словно крот.

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

Неправильное разделение. В Solaris как раз намеренное разделили системные зависимости от пользовательских чтобы пользовательские могли быть скажем новее системных, не влияя на стабильность системы. В линуксе все взаимосвязано, но это может быть проблемой. А статическая сборка в один большой пакет это вариант, который работает даже с линуксом принудительно втаскивая вариант со статическим линкованием туда где это не приветствуется, но опять же для работы программы могут быть нужны конкретные версии библиотек ввиду особых заморочек. Этого ада можно было бы избежать если бы существовало разделение системных библиотек и пользовательских. А подход с винды он как раз такой - взять все свое и притащить большой горой. Занимает много места, но хотя бы работает. То что этот бред творится и жрет непомерно места на твердотельниках конечно же раздражает, но у контор могут быть свои причины. Steam вообще не рекомендовал ставить приложение из всяких там сборочек так как это приводит к проблемам, но имеем то что имеем так как не все дистрибутивы сподобились опакетить все приложения. Часть конечно же доступна только в виде метаговнопакета. И желание новичка конечно понять можно. Раньше такого не было. Но то чего он хочет было давно еще до создания подключаемые библиотек когда система была стройная и просто работала.

anonymous
()

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

ещё см. весь список.

  • nanolinux протух (2014), хотя в виртуалке всё ещё работает. он интересен в первую очередь минимализмом – тем, что там Dillo вместо браузера и Nano-X (Microwindows) вместо иксов.

ещё видел похожую прям на него сборку под FreeDOS – Dillo, Microwindows, браузер и какой-то минималистичный недоексель под FLTK – под DOS.

кажется, nanolinux, netrider, и эта сборка под FreeDOS это продукт/поделие одного и того же автора: интарвью

XFDOS – вот та сборка с Microwindows, Dillo, FLTK и прочим софтом под FreeDOS

Netrider – минималистичный браузер на Webkit под FLTK.

  • TinyCore Linux – дистрибутив типа «сделай сам свой дистрибутив» на основе Busybox. вроде активно развивается.

там как раз именно то, что ты хочешь:

  • дефолтно – LiveCD без установки, грузится из RAM

  • или можно поставить с OnBoot пакетами как обычно на HDD или можно поставить совмещённый образ OnDemand – с симлинками из RAM на HDD на прочие

  • есть минипакетный менеджер

  • пересобрать (remaster) свой образ со своими тёплыми ламповыми пакетами тоже не сложно.

  • пакеты *.tcz – это Squashfs образ. по умолчанию в установленном на HDD только две директории: {/boot,/tce}.

остальное можно скачать через пакетный менеджер, пакеты бинарные, можно качать только разницу (zdelta, zsync).

всё остальное можно пересобрать руками и добавть в образ. как – описано в документации corebook.pdf

образ довольно минималистичный – есть текстово-консольный или Xvesa.

ещё есть dCore с пакетной базой от Debian.

Busybox, где-то писали что ранние версии на основе uclibc но судя по дистровотч – среди пакетов есть обычный glibc 2.40

в общем, всё довольно минималистично.

в документации расписано как пересобирать пакеты (extensions) и образ (remaster) и/или делать отдельные образы для приставки типа контейнеров: httpd веб-сервер (+1Мб), firefox kiosk-mode и прочее.

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

подобавлять пересобранное руками.

и сделать из него нечто LFS-подобное.

база довольно минималистична – минималистичнее уже некуда (только LFS).

anonymous
()
Ответ на: комментарий от Qui-Gon

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

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

Какие-нибудь яблоки с их слоганом «дядя знает лучше, что тебе надо» и их фанбазой, которая восхищается интерфейсом - могут идти лесом.

С другой стороны - искать косяки для запуска калькулятора - тоже не прельщает.

Здесь есть какой-то парадокс: иногда на лине сверхзаумные вещи делаются одной командой, тогда как сверхпростые - эмулятор в эмуляторе, который эмулирует эмулятор, с целью эмуляции эмулятора.

В винде наоборот, или вообще не едет велосипед.

Reptile
() автор топика
Последнее исправление: Reptile (всего исправлений: 1)
Ответ на: комментарий от Kolins

и вот тут начинаются пляски с: … контейнерами

А в чем проблема? Суешь всё говно в контейнер, а основная система остаётся чистой и нетронутой. Именно это и продвигают иммутабельные системы.

rupert ★★★★★
()
Ответ на: комментарий от anonymous

ну то есть, нужно как в православных BSD или там Plan9:

  • есть базовая система (base) – не только ядро, но и некоторые минималистичные команды, утилиты

  • и программы – всё остальное через пакетный менеджер

  • и возможность переустановить через пакетный менеджер бинарное или пересобрать из сорцов через порты

  • и «воспроизводимость бинарных сборок»

а то ты такой сделаешь export PATH=/opt/my-gcc/gcc-14.15.54648787/bin/cl.exe и оно тебе пересоберёт непонятно что непонятно как (см. например в firefox: cl.py на питоне враппер к gcc будто он cl.exe, вот же костыли!)

а потом выяснится, что reflection of trusting trust и бинарник уже по MD5 отличается.

а потом выяснится, что окружение сборки нечистое и в 100500 строчках ./configure.sh автолулзы ещё что-то там подхватили.

а потом выяснится что нужна всё-таки минималистичная базовая система и воспроизводимость сборок – как в NixOS nix pkg manager на своём диалекте недохаскеля для ебилдов, или как в Guix на православном G-monads с обычной scheme, или как в hermes/janet *.hpkg на недолиспе janet пакетный менеджер hermes типа такой упрощённый guix который только собирает и копирует/запускает собранное в нужном окружении (зато есть defsrc и прочие макросы лиспа в «ебилдах»)

в общем, нужно взять тот же TinyCore linux и hermes/janet или там guix и сделать из него MidnightBSD какой-нибудь.

или Plan9 православный типа 9ants с контейнерами и POSIX APE окружение.

anonymous
()
Ответ на: комментарий от Kolins

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

shell-script ★★★★★
()
Ответ на: комментарий от ya-betmen

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

ад зависимостей победить можно, но сложно.
сейчас проще его «обскакать на кобыле»

pfg ★★★★★
()
Ответ на: комментарий от Reptile

но диск засирает он не менее быстро и эффективно.

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

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

P.S. Особенно информативно вставлять ссылки на ютуб в околотехническом обсуждении. Очень, прям, полезно, да.

shell-script ★★★★★
()
Ответ на: комментарий от Reptile

Венда и макос - это монокультура. У тебя есть один вендор и одна система - - ну плюс-минус пара релизов которые живые (а в остальных никто не гарантирует) , плюс жесткое правило беречь API (гномосеков с их «ломай API в каждой минорщине» что в M$ что а огрыке уволили бы с волчьим билетом на второй день работы. При первом сломе).

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от anonymous

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

чтобы понять почему всё так тупо – попробуй пересобрать LFS строго по книжке.

и осознай, зачем там как и в Gentoo пересобирают gcc по три раза.

и заодно про MES mescc из Guix прочитай, почему там этого не нужно.

gcc зачем-то переписали на C++ (хотя он там и не нужен вовсе).

в результате:

  1. пересобираем недоgcc без ++ и прочий минималистичный сконфигурированный в c only.

  2. им пересобираем мини-0 базовую систему, достаточную чтобы пересобрать остальное.

  3. пересобираем gcc с g++, первый раз.

  4. второй и третий – кросскомпиляция и/или, gcc test для проверки что все тесты воспроизводятся из старого в новом.

  5. пересобираем мини-1 базовую систему на C++, этим свежесобранным g++.

  6. пересобираем остальное – остальную базу

  7. и остальные порты

  8. и бинарники из пакетного менеджера.

то есть: сам процесс сборки – дурацкий из-за того что есть циклические ссылки между пакетами. конфигурация gcc в 2,5,6,7,8 может отличаться – поэтому пересобираем по несколько раз

ибо с первого раза – не доходит. чтобы конпелировалось понадёжнее и поглобальнее, лол.

потом ещё разбираем например косяки в конфигурации USE-флагов если Gentoo и/или USE-флагов и профилей если Funtoo.

и циклические зависимости между ебилдами с неожиданными комбинациями USE-флагов.

и замаскирываем/размаскирываем, пересобирая по кругу в 10500 раз.

нет бы сразу guix или hermes/janet православный поставить.

нет, LFS нужно непременно ставить руками.

пересобирая по кругу в 1005000 раз из-за циклических ссылок в самих пакетов.

чтобы лучше отложились эти боль и страдания.

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

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

он же бохъ. от него сияние исходит (c)

а пересобрать слакбилды или там поставить минималистичную базу и собирать в чистой среде как в nixos, guix или hermes/janet — могут не только лишь все.

вот что линуксоиды учинили, лишь бы базовую систему как в BSD обыкновенной не делать.

напутали циклическими ссылками рецепты сборки LFS – ибо не только лишь все могут пересобрать 1000 страниц по священным писаниям.

это же секретная нанотехнология, утерянная предками – как собирать и пересобирать правильно.

как полигональная кладка аннунахов с нановомбатоми, не иначе :)))

а ещё можно поставить Plan9 православный с нормальными mk-файлами и конфигами через переменные или ту же BSD, почти любую.

и удивиться – а как же там всё пересобирается легко и просто и без циклических зависимостей :))

anonymous
()
Ответ на: комментарий от ya-betmen

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

с попенсорсным ПО попрощее, но устаревшие прог тож навалом «работает - не трогай»

сейчас вона, обновления типа A/B пробивает себе дорогу :) там вообще всё дублировано - зато устойчиво.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от Qui-Gon

В линуксе нет монокультуры - есть куча дистров со своей базой системынх пакетов

которые уже засрали виндоподобными монолитными зависимостями всего и вся в духе systemd и wayland и dbus (kdbus с зависимостью на версию ядра на systemd, вы серьёзно? а зачем там systemd-boot, DNS, бинарные логи, отменили nohup и впилили свой вебсервер и прочее?)

а зачем там в этой недоделанной поделке wayland зависимость от systemd ??

так что Embrace, Extend, Extinguish успешно зохавывает и всю эту кучу дистрибутивов :)))

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

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

чтобы обеспечивать бинарную несовместимость.

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

:))

anonymous
()
Ответ на: комментарий от shell-script

Вообще обсуждали уже всю эту мутотень и пришли к выводу, что линукс так «экономит» не от хорошей жизни, а как раз 1) из-за зоопарка, из-за которого централизация невозможна, 2) дичайшей инертности и косности мышления выливающейся в применении концепции из 1995 в 2020+.

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

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

Ты лично видимо просто элитист который находит отдушину в самоутверждении за счёт использования типа сложного ПО (поэтому такая риторика про «тупых пользователей»).

Exmor_RS ★★★
()
Ответ на: комментарий от ya-betmen

Я больше имел в вмду библиотеки разных версий и старый софт. Зачем? Чтоб таки запустить новый софт, который требует старые библиотеки или программы, собранные определённым образом.

Reptile
() автор топика
Ответ на: комментарий от shell-script

Хорошо, раз речь тут идет о пересборке… Как пересобрать D-Bus c rdynamic? Как установить старую версию питона на арч?)

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

Reptile
() автор топика
Ответ на: комментарий от Exmor_RS

Я не вижу ничего сложного в известных мне пакетных менеджерах. Они очень удобны в работе и как раз облегчают управление софтом на компе. Я вспоминаю ад с ручными обновлениями каждой утилитке в оффтопике, с разгребанием тонн vc++distributable (или как там оно называлось) десятка разных версий, которые вроде бы как должны быть каждая со своей программой, но в итоге они конфликтовали. И я не представляю, как в 2020+ можно работать без apt-get install programmname(emerge/dnf).

Заходы про элитарность и сложность мне тоже непонятны. Что может быть проще, чем dpkg -L/dpkg -S или там qfile/equery для того, чтобы разобраться с принадлежностью файлов к программе? Это настолько обыденные и удобные в использовании вещи, что называть это адом зависимостей и какой-то сложностью как-то странно. Именно для 99% процентов обычных пользователей оно работает идеально. А если нужно что-то нестандартное, то это вне зависимости от ОС потребует более глубоких знаний. И я лично не вижу проблемы с установкой в любом дистрибутиве любых версий софта. Способов много и выбирать можно любой под каждую конкретную задачу.

shell-script ★★★★★
()
Ответ на: комментарий от Reptile

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

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

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

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

Я не против систематизации, но зачем она именно так устроена: сильно мазать по дискам файлы? Где ж тут эффективность??? Это и винды касается, вообще говоря.

Reptile
() автор топика
Ответ на: комментарий от shell-script

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

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

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

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

И да, для буйно-помешанных и отравленных линуксом (типа меня и тебя) на винде/маке давно есть ворох пакетных менеджеров, который при этом ещё действительно позволяет ставить разные версии ПО легко и просто (без компиляции, переусложнённых цепочек команд и подбора метода под задачу).

Скорее всего твоя убеждённость строится на том что когда-нибудь линукс будет доминировать благодаря этой странной модели — не будет, именно эта модель и сдерживет распространение.

Exmor_RS ★★★
()
Ответ на: комментарий от Reptile

но зачем она именно так устроена

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

И эта идея зацементировалась в том же дебиане настолько, что пусть там апт и позволяет иметь несколько версий программ в репах — их там не будет для экономии места.

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

Exmor_RS ★★★
()
Ответ на: комментарий от pfg

Я к тому, что подобная потребность возникает в очень специфичеких кейсах и касается двух-трех программ. И какой смысл делать так чтобы это работало и для остальных 99,9%? Тем более что обычно если нужно версия старее/новее её всё равно можно воткнуть рядом.

ya-betmen ★★★★★
()
Ответ на: комментарий от Exmor_RS

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

Не проще, у него просто обычно выбора нет.

Это линь людей расхолаживает и начинается, хочу так, а так не хочу, а ещё вот так нужно...

ya-betmen ★★★★★
()
Ответ на: комментарий от Reptile

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

Суть в том что есть некоторые функции давно реализованные. ну скажем скопировать строку. Или открыть jpg картинку. Или заархивировать даннные в zip, прочитать xml. Если каждый автор прикладного софта будет это реализовывать с нуля - то программы будут писаться годами. И работать через зад. И этими функциями пользуется тонна софта.

Соответственно они реализованы в библиотеках типа libjpeg, libxml, ffmpeg и прочее. Их используют чуть меньше чем все твои программы. Куда это класть ? В каждой программе делать свою инсталляцию libjpeg? Если да - то кушаем флэтпак. Не забывая только что libjpeg -это частный случай, а по большому счету половина если не больше кода опирается на общие библиотеки.

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

Впрочем для этого у юниксов и было придумано удивительное решение - в отличии от венды где каждая прога имеет свой каталог для своих файлов в юниксе (и линуксе) все бинарники летят в /usr/bin, а билиотеки - в /usr/lib. Что в общем случае обеспечивает что ты не сможешь 100 раз туда записать одну и ту же libjpeg.

Qui-Gon ★★★★★
()
Ответ на: комментарий от ya-betmen

А вот и нет, гораздо проще.

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

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

Exmor_RS ★★★
()