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

Сливается с ней все в кучу, а не как в винде в отдельном каталоге все в кучу.

«Это другое, понимать надо!» (ТМ)

:D Я когда первый раз на кишки дистрибутивов смотрел то думал «А нахрена тут всё размазано, всё в кашу по всей системе, бред какой то что за даун так придумал делать шизики, в икспи всё понятно вот програм файлес, вот папка с программой и всё» =) Потом частично прозрел, а потом проникся помойкой что утраивают nodejs/python и иже с ними. По итогу сейчас как по мне всё говно, попытки сделать красиво это никс, но красиво в конфигах, а внутри параша. Это как обёртывать в фантики. Хотя подход разделяй и властвуй по UNIX старинке всё же более менее по итогу лучшее из того что есть, но лишние дробления из за того что специализированные каталоги и подкаталорги появлялись по мере надобности, а не разово спроектированны (может тут я ошибаюсь) Короче до сих пор у меня разрозненное мнение на счёт всего этого.

Файловая ирархия как программный интерфейс. В этом вся суть.

Единственное, чего не хватает, – разделения по доменам и зонам ответственности. Все эти попытки изобрести колесо с флатпаками и прочим – они в основном про это.

Ну и дедупликации (хардлинки на файлы же есть, реализовать не сложно), чтобы сделать версионирование, роллбэки, вот это всё.

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

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

«Это другое, понимать надо!» (ТМ)

«FHS написан кровью!» :) (шутка)

GoboLinux и NixOS не следуют стандартам FHS.

«FHS написан кровью!» :) (шутка)

Кровью из глаз :)

я в /opt предпочитаю устанавливать

Владимир.

Владимир - мерзкий проприетарщик

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

всё имеет смысл если ты его понимаешь :)
минибекап из архива /etc /home у меня на сервачке весит 89 мб и то ~76 мб из них это несклько валяющихся в хомяке zipчиков с бинарями програмки, которые какбы надо пристрелить, ибо они есть в тырнетике, но пока влом вдруг пригодятся.
и для сравнения архив / без разделов с файловым бардаком весит 5 гб. если выкинуть логи и прочий var и бекапить только прикладные данные, то получится 2,5 гб. но все равно размеры отличаются, сам понимашь, на порядки.
удобство разделения fhs по типу «разделяй и властвуй» начинаешь ценить, когда в него вляпываешься :)

кстати даже микрософтеры начали понимать, что разделять бардак по полочкам имеет смысл, так давным-давно появились «Document and Settings» потом преобразовались в Users. из \Users\All Users появилась ProgramData. так глядишь и окультурятся обезъянки.

кстати кроме FHS есть еще варианты разделения файлов по мамкам, вот только наименование системы забыл :)
а вот будучи уже на андроиде, я сильно жалел, что в нем нет выделенной системной папки /cache, внутри которой все программки бы держали кеш файлов и который бы можно было удалять одной просто системной командой.
и т.д. и т.п.

dpkg -L/rpm -qf $package_name

++

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

В андроиде есть Dalvik/ART - удаляй

В /nix/store

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

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

чтобы сделать версионирование, роллбэки, вот это всё.

Псс... Эй, парень! Не хочешь немного WinSxS?

Не, такого добра нам не надо…

Очередной в гугле забаненный с тупым вопросом, который уже 100500 раз везде задавали.

Хочу!

Потому что после этого не нужно будет думать за библиотеки и прочие несовместимости.

бираные сборки можно в /opt

• echo $PATH
• /usr/local/bin:~/.local/bin:/opt/bin

В правильном линуксе — в /nix/store, в остальных — куда попало.

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

сейчас ты рассовываешь свои файлы в шесть тысяч папок, и это ничуть не проще ))

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

но возразить на это тебе нечего, вот ты и переходишь на личности )))

Файловая ирархия как программный интерфейс. В этом вся суть.

Это больше похоже на баг дизайна ОС, чем не на нечно полезное.

Отсюда, кстати, абсолютно неудобная необходимость привязывать к файловой системе объекты, живущие в памяти и не нуждающиеся в файловой системе (напр, fifo)

сейчас ты рассовываешь свои файлы в шесть тысяч папок, и это ничуть не проще ))

Я?! Нет, я этим не занимаюсь. Этим занимается система сборки и пакетный менеджер.

Если ты пытаешься вручную делать тупую работу машины, ты с самого начала всё делаешь неправильно. Машина тупая, но быстрая. От этого и пляшем.

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

Всё верно. Такое API называется файловая иерархия. Если программа реализует интерфейс «меню приложений», она смотрит в /usr/share/applications. Если программа предоставляет интерфейс «элемент меню приложений», она соответственно регистрирует себя в /usr/share/applications.

Всё устроено предельно логично.

но возразить на это тебе нечего, вот ты и переходишь на личности )))

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

Отсюда, кстати, абсолютно неудобная необходимость привязывать к файловой системе объекты, живущие в памяти и не нуждающиеся в файловой системе (напр, fifo)

Если что-то должно быть доступно по имени, оно регистрируется в ФС. Если тебя смущает термин «файловая система», мысленно переименуй его в «иерархия имён». Тем более, что /tmp и /run ни в какие файлы на носителе не отображаются.

мясо в морозильник

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

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

вашу идею я понял

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

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

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

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

Всё верно. Такое API называется файловая иерархия

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

И зачем изобретать кривое API дублирующее функции существующего?

Система оптимизирована под типовой профиль использования, а не под маргинальный: отвечать на вопрос «какие есть элементы для этого интерфейса» системе приходится крайне часто, а на вопрос «из какого пакета это имя» — практически никогда. Второе нужно только для операций установки, удаления, обновления. Для этого случая в системе есть база данных.

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

Зачод!

игры например в /usr/games/

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

при установке любого пакета список его файлов сохраняется в /var/lib/dpkg/info/%package%.list плюс там же рядом лежит куча другой информации об установленных пакетах необходимой для адекватного управления ими.
ручные влезания в ентое дело в системах с пакетным менеджером крайне нерекомендованы и что-то не представлю ситуации, кроме появления крупного песца всей системы, когда понадобилось бы ручное влезание вглубь системы.
пакетный менеджер все-таки не наколенная поделка погромиста 3 курса, вещчъ весьма продуманная и допиленная и отлаженная.
после бардака винды конечно в это не верится но так оно и есть.

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

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

врач достанет список продуктов, заверенный подписями и печатями, из сейфа под названием /var/lib/dpkg :)

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

Зачем и кому это нужно? Как часто Маша ссорится со всеми или травится? А класть/доставать продукты нужно каждый день.

Напомню ещё раз, что симлинки не бесплатны в плане ресурсов. Симлинк занимает место в списке файлов (т.ё. жрёт дисковое пространство), открытие файла по симлинку в два раза медленнее, чем напрямую. Запускать программы и читать/писать их файлы нужно каждый день, а удалять раз в сто лет. Твоя схема замедляет каждодневную работу в обмен на возможность удаления программы удалением одной папки (и 100500 симлинков)

я смотрю куда устанавливается либо в программе synaptic либо через apt-file find .

при установке любого пакета список его файлов сохраняется в /var/lib/dpkg/info/%package%.list

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

что-то не представлю ситуации

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

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

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

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

мой вопрос был зачем вообще раскладывать по папкам? какой в этом профит?

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

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

Есть ещё всякие Nix, которые тоже решают проблему бардака.

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

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

У нас тут на форуме есть товарищ с мясокомбината. Уточняй у него.

не кушаешь ты свежезабойное

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

Читал статью что программы устанавливаются в корневой раздел «/» но потом нашел другую информацию что устанавливаются в «/home» в линукс сообществе в вк, так куда?

куда хотят, туда и устанавливаются.

товарищ с мясокомбината

крупный рогатый скот на лоре?