Представлен релиз дистрибутива GoboLinux 017.01, в котором вместо традиционной для Unix-систем иерархии файлов используется стековая организация дерева каталогов, при которой каждая программа устанавливается в отдельный каталог. Размер установочного образа с поддержкой загрузки в Live-режиме - 2.3 ГБ (x86_64)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63000
давно пора порядок навести
А то я всё время забываю где у меня что установленно, то ли в /usr/bin, то ли в /usr/local/bin, то ли в /opt. Это какой-то ёпт.
Есть такая команда, which. Не благодари.
я думаю, что то был сарказм )))
неа
which устарела уже три года как (см. https://salsa.debian.org/debian/debianutils/-/blob/5aeca1e3b... )
Используйте 'type -p' или 'command -v'.)
Это где она устарела, в Демьяне? А то в Gentoo имеется.
> Это где она устарела, в Демьяне? А то в Gentoo имеется.И в дебиане имеется, включая тестируемый 13-ый, но помечено как устаревшее, будет удалено в будущем.
PS: Хотя походу это только их дебиановская версия устарела, в убунте дебиановская, но в других дистрах может быть другая.
Кстати, type -p не всё находит:
which nano
/bin/nanotype -p nano
Обломинго, не нашёл.
> type -p nanoОбломинго, не нашёл.
В LMDE6 (debian 12) находит!
Да не удалят команду, симлинкнут полюбому
Хотя походу это только их дебиановская версия устарела, в убунте дебиановская, но в других дистрах может быть другая.
А еще whereis, locate, find и та дэ - все, с-ка разные и все не то, чтобы прям хорошо задачу решающие - впрочем, ничего нового.
А ты не матерись, просто выбери утилиту по сердцу. И что чтож они разные. В разнообразии кроется сила Линукса.
> А ты не матерись, просто выбери утилиту по сердцу. И что чтож
> они разные. В разнообразии кроется сила Линукса.Ага. Можно ещё вот самому написать, да. Зе павер оф опенсортц!
А ты не глупи - представляешь, если бы у тебя в авто было 5 рулей и каждый бы работал немного по-другом чем другой, но со своей "изминкой" - была бы веселуха, как говорится - все столбы твои.
Просто мейнтейнеры ещё не нашли достойный клон на раст
Использовать команду, чтобы банально узнать что где лежит, какая прога установлена - Вам не кажется это малось, эммм... сломанным?
А тут ребята сделали нормально. Вообще лично всегда считал каталоги линукса бредом. Это же из юникса пошло? Хз кому такому умному пришла эта идея в голову.
Вполне соответствует современному подходу огранизации данных: свалить всё в кучу и ориентроваться, делая выборки по разным критериям.
Тут 2 стороны. С текущими каталогами линукса - нет дубля программ и библиотек, значит весит мало и строгая версионность (у программистов же правило - не должно быть дублирования кода. А писали Линукс программисты), а с виндовым подходом - каждая программа использует своё окружение (платные программисты писали для домохозяек). В обоих случаях свои плюсы и минусы.
Раньше, такой подход был оправдан, так как жесткие диски были маленькие и место надо было экономит. В нынешние времена смысла экономить место на диске в угоду хаосу просто нет, я был бы прям рад, если такая же система с каталогами была в Debian. По поводу того, что это раздуло бы систему в 10 раз... какое мне дело, когда там под копотом терабайт или два?
> Есть такая команда, which. Не благодари.ntfs@b450:~$ which php
ntfs@b450:~$ /system/php/bin/php -v
PHP 8.2.26 (cli) (built: Feb 15 2025 17:10:34) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.26, Copyright (c) Zend Technologies
ntfs@b450:~$За что тебя благодарить, за неработающую команду, или за то что ты ниасилил как ее можно использовать?
А что уж не всем привычную то:
\PerfLogs
\Program Files
\ProgramData
\Users
\Linux
\System
\System32
Да, переизобрели Program Files
И обязательно сохранить регистр и пробел, чтобы уки страдали!!1!
/
C:/
/System Volume Information/
/$RECYCLE.BIN/
...
D:/
/System Volume Information/
/$RECYCLE.BIN/
...
Не выкупил, в чем отличие от:lost+found
.Trash-1000
.local/share/Trash?
Меня больше напрягает куча овна в корне хомяка, вместо ".config". Хотя и в ".config" овна хватает, ибо зачем складывать конфиги в одну папку? Да разработчики Krita? Ну или 24 пункта "Krita" подряд, в "Open With". Прям кайфую каждый раз скролить, нужно еще минимум столько же!
> Меня больше напрягает куча овна в корне хомяка, вместо ".config"Меня тоже в своё время это напрягло. Выход придумал такой: создал в домашней директории ещё одну папку Home, перенёс туда из домашней папки всё кроме конфигов, а потом просто отредактировал файлик user-dirs.dirs. В принципе можно было бы ещё с названием и расположением домашнего каталога (реального) поиграться, но пока и так всё устраивает.50674
Почему нет? Swap файл в стиле Windows вместо отдельного swap раздела неплохо прижился в Ubuntu (начиная с версии 17.10), и все довольны. Нужно обмениваться лучшими идеями.
а чем не зашел своп-раздел?
чем он так плох? фиксированным размером? ))
внезапно, дачтобы изменить размер свопа (или вообще его убрать и использовать zram) с свопразделом приходится или перетасовывать все остальные разделы, или городить конструкции с LVM
> чтобы изменить размер свопаЗачем? Вернее, а зачем _сейчас_ нужен своп?
Хинто 1: бины/либы - это уже "своп" - они свопятся из своих файлов.
Хинто 2: если программе не хватает рамы для данных - надо добавить рамы, а не тормозить дисками.
Сейчас такие диски быстрые, что последние андроиды позволяют расширить раму за счет ссд.
>> чтобы изменить размер свопа
> Зачем? Вернее, а зачем _сейчас_ нужен своп?
> Хинто 1: бины/либы - это уже "своп" - они свопятся из своих
> файлов.
> Хинто 2: если программе не хватает рамы для данных - надо добавить
> рамы, а не тормозить дисками.Ну, эта... есть вот такая штука - "гибернацией" называется. Ну, т.е. в нормальных системах есть, нам-то, конечно - "не нужно!" - так вот для неё этот самый swap некоторым образом эээ... используется, да. Т.е. опять таки в нормальных системах - нет, но вот конкретно у нас - "да" :).
Для гибернации используется другой файл размером с оперативную память
> Для гибернации используется другой файл размером с оперативную памятьНу вот в ей, поганой - да, а так, чтобы в "моей прелесссти" - неа, не видел. Впрочем, оно там вообще не работае... ой, "ненужно!" конечно же - так что особо и не искал.
Так сделай своп не фиксированного размера, в чём проблема?
> Так сделай своп не фиксированного размера, в чём проблема?ну так вот и сделали. своп как обычный файл, а не как устройство
слишком быстро работал
>а чем не зашел своп-раздел?чем он так плох? фиксированным размером? ))
SSD мрёт, хотя бы zram-swap.
> SSD мрётСказки венского леса.
диску лет пять, рабочий ком 24/7, своп на разделе, проблем с диском нет
Ноуту 15 лет, проц i3, диск HDD - даже и не думаю, что что-то из них может умереть (скорее петли дисплея отвалятся)
> SSD мрёт, хотя бы zram-swapОднажды у меня бомбануло от подобных заявлений и мне захотелось проверить сколько же в действительности данных своп пишет на диск. Запустил на неделю btrace и получил такие цифры: за неделю довольно активного пользования системой (Дебиан 12, 16 ГБ оперативы) на основной раздел было записано 2787 GiB, тогда как на своп-раздел за это же время было записано всего 3057 MiB, т.е. почти в тысячу раз меньше. При таком соотношении очевидно, что своп на износ ssd никакого сколь-нибудь значимого влияния оказать просто не в состоянии.
С какого перепугу ты решил что файл-подкачки как в Виндовсе это лучшая идея? ты совсем того. Ну выбрали убунтоиды вантузный путь, это их проблемы.
> что файл-подкачки
> вантузный путь
> как в ВиндовсеА если как в макоси? То есть так же, но без упоминания винды, чтобы не провоцировать фанатиков.
Могу представить проблемы на жёстком диске при свопе переменного размера (->фрагментация) и на ZFS (->ха-ха, дедлоки[1] из-за неотключаемого CoW). Но это специальный поиск проблем на свою голову, где реальные недостатки? Вижу только увеличение гибкости, а то можно вообще на каждый файл по разделу выделять (назовём это lvmthinfs).
> [1] https://github.com/openzfs/zfs/issues/7734
> ZFS Version 0.7.9-3~bpo9+1Подревнее ничего не нашёл?
> С какого перепугу ты решил что файл-подкачки как в Виндовсе это лучшая
> идея? ты совсем того. Ну выбрали убунтоиды вантузный путь, это их
> проблемы.Не, ну диски конечно по объему изрядно выросли - но отдавать 32 гига на случай гибернации того-этого... жаба душит. Опять же - управлять уот этим уот несколько более напряжно - докинул ты в нотик еще одну плашку (Тут конечно производитель постарался, чтоб такой проблемы у тебя не возникло - но вдруг?) - и начинается танец-с-саблями-на-граблях...
При гибернации пишется не вся оперативка, а только используемая. Зачем туда писать незанятую память и кеш? В моём опыте при 32 гигах оперативки файл гибернации получается около 8 гигов всего - естественно никто гибернацию при активно работающих программах не делает.
> При гибернации пишется не вся оперативка, а только используемая. Зачем туда писать
> незанятую память и кеш? В моём опыте при 32 гигах оперативки
> файл гибернации получается около 8 гигов всего - естественно никто гибернацию
> при активно работающих программах не делает.Ну фиг его знает - вон, в оффтопике 6 VM'ок в hyper-v вполне себе гибернацию переживают - но место хорошо так за 20 гигов уходит. Можно, конечно, сделать раздел подкачки 8 гиг и надеяться, что этого хватит - но право же, "не наш выбор"
зачем все эти полумеры? ))) надо экономить место на диске ))
\P (Program)
\D (data)
\U (users)
\L (linux)
\C (config)
\K (kernel)
\L (libs)
Вот, тогда бы GoboLinux на Винду был больше похож, чем Zorin OS.
Это привычно не всем, а только тем кого бох обделил.
Давно пора сделать иерархию как в Windows! Даешь диск C:\!
Ставили FreeBSD хоть раз? Как вам первые сообщения типа "системный диск c:" и т.п.?
Фряху ставил, системный диск не помню честно говоря.
И не только во фряхе, но и в остальных бздях тоже диск ц.
Перепись ни разу фряху не видевших, но мнение имеющих - продолжается! Проходим, не стесняемся ! :)))))
емнип, это еёшный загрузчик такой, сама фря юникс
Ну так структура файлов что в этом вашем линуксе, что во фряже идентична, плюс минус, т.к. повторяет UNIX.
> емнип, это еёшный загрузчик такой, сама фря юниксЕМНИП, это просто фантазии местных.
Это особенность fdisk (disklabel, если точнее). Там кажется c: - это весь диск (аналог /dev/sda). В других ОС тоже подобное бывает, не всегда 3-й раздел по списку, где-то он был аж девятый по счёту из примерно пятнадцати.
Предлагаю начать с А:
Ого, оно еще живое. Вроде как один из источников вдохновения для Nix.
Нет, они вышли в одно время, может с разницей в полгода. Никс на PhD базируется
Хы. Вот смотрю я вот на вот этих вот "нитаких как фсе", спрашиваю постоянно - почему бы не сделать виртуальную ФС с "попапочкам" НАД стандартной, проверенной временем иерархией - внятно ничего ответить не могут. Даже ответить на "зачем городить огород, каккие киллерные фишки у такой иерархии?" внятно - тоже.> Разные версии софта + проприентарь
1) Контейнеры, если надо не просто разложить по каталогам, но и дать минимальную защиту программе и от программы
2) Схема с /opt/LipreOffice_14.99/ и /opt/LipreOffice_13.88/ уже существуют с незапамятных времен. Заодно понятно, что если что-то лежит в опте, то следует на это обратить повышенное внимание.
> Хы. Вот смотрю я вот на вот этих вот "нитаких как фсе", спрашиваю постоянно - почему бы не сделать виртуальную ФС с "попапочкам" НАД стандартной, проверенной временем иерархией - внятно ничего ответить не могут.затем, чтобы, например, libpng.so в /program/my-prog1, юзало версию 1, /program/my-prog2, юзило libpng.so версии 2, и они, никак бы не конфликтовали.
Понятно, что в случае с libpng ещё можно было бы символическими ссылками разрулить, но если у прог/либ РАЗНЫЕ конфиги, например, или разная структура в /var/... то уже так не разрулишь.
> Контейнеры, если надо не просто разложить по каталогам, но и дать минимальную защиту программе и от программы
Контейнеры - это для бедных, как раз мега-костыль для отсутвия нормальной изоляции (в т.ч. либ).
> 2) Схема с /opt/LipreOffice_14.99/ и /opt/LipreOffice_13.88/ уже существуют с незапамятных времен.
Только живут в /opt собственно сами проги, БЕЗ зависимостей.
> затем, чтобы, например, libpng.so в /program/my-prog1, юзало версию 1, /program/my-prog2, юзило libpng.so версии 2, и они, никак бы не конфликтовали....что херит всю идею *разделяемых* библиотек. А если прямо так важно, чтобы юзалась версия 0.1.2.3 - для этого есть такое понятие как *статическая линковка*. Ну и да, симлинки.
> разрулить, но если у прог/либ РАЗНЫЕ конфиги, например, или разная структура в /var/... то уже так не разрулишь.
То ставишь в контейнере, если софт настолько униКАЛьниый (от снежинки с половиной карги: 90% который - лефтпады) или откровенно тяжёлый.
> Контейнеры - это для бедных, как раз мега-костыль для отсутвия нормальной изоляции (в т.ч. либ).
Неа, как раз доведенная до ума идея "приложение + зависимости + минимальное окружение в одном образе" с атомарным обновлением образа контейнера безо всяких "а теперь у нас тут новая, абсолютно несовместимая иерархия с ядерным модулем-маскировщиком для 100% софта".
Кстати, как там с доверием к этому модулю? Он точно даёт прямой доступ к файлам и точно не скрывает что-нибудь несущественное, типа логов доступа тебя к файлам на ПК?
> Только живут в /opt собственно сами проги, БЕЗ зависимостей.
so'шники, которые распакованы рядом с бинарью и ресурсами - это сбой матрицы и показываются только избранным?
И все равно все скатывается к
> Разные версии + проприентарьи снова невнятно. Не убедил, нет прямо такой киллерности, ради которой стоило бы так менять структуру каталогов.
> Контейнеры - это для бедныхА вот не надо ля-ля. Я лично наоборот жду когда же уже наконец завезут прозрачную интерграцию контейнеров с системой. Чтоб можно было одним щелчком мыши создавать изолированные оркружения и так же легко их удалять. Или можно контейнеры сразу с пакетным менеджером объединить. Например устанавливаешь кучу программ, и вместо "apt install program1 program2 program3" пишешь что-нибудь типа этого: "apt install -in mycontainer program1 program2 program3". А когда их нужно удалить, то просто удаляешь контейнер вместе со всеми программами, зависимостями и конфигами, и все дела. По-моему это было бы удобно.
Да, удобно особенно для билд систем. У меня уже пермоментно бомбит от того кошмарного ужаса, когда чтоб сбилдить прогу приходится тащить гору зависимостей, из которых больше половины - только определенной версии и только ей, проге, нужные. Лучше бы конечно объяснять разработчикам что не нужно плрдить абстракций и библиотек, но имеем что имеем.
А что мешает LXD или Incus использовать для этого?
Команда lxc позволяет алиасы создавать.
Не устраивает то, что всё это нужно настраивать с бубном. К удобству пользования тоже есть вопросы.
>При этом, указанные каталоги по умолчанию не видны пользователю, благодаря применению модуля ядра GoboHide. Указанный модуль скрывает некоторые каталоги при переборе содержимого, но допускает прямое обращение к файлам.Руткитам и вирусам это должно понравится.
> Руткитам и вирусам это должно понравится.И не только им. ЦРУ просто хлопает в ладоши - не надо сильно заморачиваться с закладками, можно нанять канадского PhD, который хоть троянского слона (зашифрованная виртуалка, в которой интерпретатор питона, в котором FORENSIC-скрипты крутятся) напишет, а модуль спрячет
Руткиту хватит и LD_PRELOAD.
LD_PRELOAD не даёт сокрытия файлов и процессов. Его хватит только, чтоб к существующей проге прикрутить бекдор.
> LD_PRELOAD не даёт сокрытия файлов и процессов.Ну если не уметь накодить нужное в .so, то конечно не даёт.
> Его хватит только, чтоб к
> существующей проге прикрутить бекдор.Советую, прежде чем выдавать вот такую экспертизу, почитать хотя бы книжку Хоглунда. Ну и подумать, что оттуда возможно перенести в Linux. При этом всякий раз вывод "невозможно" следует заменять на "я не знаю".
Советую не навязывать мне, как мне следует выражать свои мысли. Скажи ещё "Я знаю, что ничего не знаю".
В таком случае, что бы я мог отличать тебя от прочих, пишущих глупости, тебе придётся подписываться отлично от Аноним.
Очень хорошо, что хватит. Значит можно статически слинковаться и видеть всё скрытое
> /Programs/LibreOffice/25.2Кстати, удобно иметь разные версии одного и того же. Вчера, например, упало LO 25.2 (поставлено из тестового репозитория) под Ubuntu 22.04 - сподвигло наконец-то поставить 24.04 с LO 24.2.7 из стандартного репозитория и не наступать на очередные грабли с тестовыми версиями. Ну их.
Норм дистр, мне нравится. Использую лет пять уже. Кушать не просит, всем устраивает.
Именно то, что нужно было сделать ещё 20 лет назад. Вместо этого они нагородили тонны велосипедов в виде контейнеров, флэтпаков, снапов и прочего маразма - лишь бы не выкидывать замшелый кусок копролита из 60х годов под названием FHS.
Мощь СПО и GNU/Linux именно в том, что есть возможность сделать в принципе что угодно. Хоть FHS выкинуть, хоть API ядра поменять. На что хватит ресурсов^Wсил и желания.
Сообщество СПО тебе ничего не должно было 20 лет назад, не должно и сейчас. Люди делают то, что хотят, или за что им платят.>тонны велосипедов в виде контейнеров, флэтпаков, снапов и прочего маразма
Контейнеры для деплоя серверных приложений, флатпаки и снапы - для дистрибуции прикладного софта на РАБочие станции. Оба направления востребованы корпорациями.
Бла-бла-бла. Не имеет значения, что там ими движет: отсутствие корпоративного заказа или религиозный запрет.>Контейнеры для деплоя серверных приложений, флатпаки и снапы - для дистрибуции прикладного софта на РАБочие станции.
И всё это является нелепыми костылями для обхода убогой архитектуры системы, которая была сварганена в 60е годы прошлого столетия буквально на коленке с оглядкой исключительно на аппаратные ограничения, наложенные на разработчиков - смех да и только.
Ох, ну конечно! Весь мир так глуп что неспособен заметить такие явные изъяны. А вот ВЫ то с высоты своих интеллекта и экспертизы сразу все оценили. Что же вы не поделитесь своим высоким видением с разработчиками систем? Или даже не создадите свою систему?И приемеры конкурирующих систем без оных недостатков соизволите привести?
>Весь мир так глупНе слишком ли громко для небольшой кучки держателей акций IBM?
>Что же вы не поделитесь своим высоким видением с разработчиками систем? Или даже не создадите свою систему?
Тебе сколько лет, что ты несёшь подобный бред?
>И приемеры конкурирующих систем без оных недостатков соизволите привести?
Никакой конкуренции не существует. Это точно такая же фикция, как демократия, например. Все рынки поделены и принадлежат одним и тем же хозяевам. Можешь сам чекнуть акционеров, интересующих тебя, корпораций. Ты увидишь там +- одни и те же фамилии, банки и фонды.
> Никакой конкуренции не существует.Ну почему же? Существует. Иногда даже до драки доходит.. И даже выполняет ту функцию, которую ей приписывают - регулирует рынок. Правда, с, обычно забываемым, уточнением - в интересах небольшой группы лиц. Но сообразительные давно догадались. Принцип "разделяй и властвуй" известен человеку с древнейших времен.
Но без контейнеров и виртуалок не было бы процветания хостинга.
> Минус подобного подхода - необходимость хранить данные (например, логи, файлы конфигурации) рядом с системными файламиНикаких минусов в этом нет. Всё лежит в одном месте. Директорию со всем содержимым удалил и никакого мусора в системе не осталось. Пожалуй за исключением ярлыков в меню, но это можно автоматизировать.
Что касается лог файла, то не вижу проблемы. Например системд, не полемики для нужно/ненужно, а примера ради, умеет в такие случаи. Указываете путь до лог файла и читаете через journalctl. Опять же этот процесс можно автоматизировать.
Как по мне данный дистрибутив логичное развитие Linux, жаль не взлетел.
Удачи тебе с ACL в системе выше по уровню "однопользовательский лолкалхост"
Иа вас умоляю, кто использует linux сколько-нибудь отличным от этого сценарием? Уот тебе сервер - на ём бэдэ, уот другой - на ём аппликуха, уот третий - там контейнер, уан штюк. А так чтобы всю LAMPаду на одну машину - так лет уже *цать не носят, как из коротких-штанишек-шаредных-хостингов выросли - так и не.
Зачем тут ACL?При первичном запуске приложения с помощью sudo/sticky bit/capabilities создаётся директория (имя $username или uid или uuid) с правами u+rwx,go-rwx внутри /Programs/AppName_<n>/config/. Владелец директории так же устанавливается при первичном запуске.
При последующих запусках приложения пользовательские конфиги берутся из соответствующей директории, с корректными правами. Если в директории выше есть глобальный конфиг, то его, очевидно, редактируют с использованием рут прав, как во всех мейнстримовых дистрибутивах сегодня.
> Директорию со всем содержимым удалил и никакого мусора в системе не осталось.Это и сейчас можно сделать. Испортил случайно пакет (например, упомянутый выше LO), соответствующую папку конфигурации удалил, запустил снова и опять получил чистую установку.
Спасибо, что ответили, но я в курсе. Маленький нюанс, конфиги приложения могут лежать где угодно. В ~/.config/, в /etc, в /usr/local/bin… опять же, вы строите свой пример с позиции, когда вы точно знаете, где располагаются конфиги.Чем это лучше, чем структура каталогов следующего вида?
/Programs/AppName_1.0/config/
/Programs/AppName_2.0/config/С точки зрения пользователя/администратора мнемоника: программы лежат в /Programs/, внутри каталогов приложений содержатся поддиректории логи, конфиги и т.п. легка и понятна. Не тратите время на то, чтобы установить местоположение оных, унификация.
Брррр. Было в ХР и ниже. По итогу любое приложение так или иначе требовало себе админа, чтобы просто писать рядом с собой в конфиг, а не в профиль пользователя. После чего имело практически полный доступ к кудахтеру, то-то вирусине было раздолье. Переучили кое как только к выходу вин11, да и то, легаси все равно надо запускать "от админа", не спасает даже "виртуализация профиля".> С точки зрения пользователя/администратора мнемоника: программы лежат в /Programs/, внутри каталогов приложений содержатся поддиректории логи, конфиги и т.п. легка и понятна
/Programs/AppName_1.0/config/Vasyan
/Programs/AppName_1.0/config/Petyan
/Programs/AppName_2.0/config/Abyrvalg
/Programs/AppName_2.0/config/Vasyanхм...
/Users/Vasyan/config/AppName_1.0/conf
/Users/Vasyan/config/AppName_2.0/conf
/Users/Abyrvalg/config/AppName_2.0/conf
/Users/Petyan/config/AppName_1.0/conf> С точки зрения пользователя/эникея мнемоника:
> любое приложение так или иначе требовало себе админа, чтобы просто писать рядом с собой в конфиг, а не в профиль пользователя. После чего имело практически полный доступ к кудахтеруОписанное справедливо и для мейнстримовых дистрибутивов linux. sudo эквивалент «запустить от администратора».
> Брррр. Было в ХР и ниже. По итогу любое приложение так или иначе требовало себе админа, чтобы просто писать рядом с собой в конфиг, а не в профиль пользователя.В таких случаях проги ставились в C:\Prog\, который не требовал админских прав, и все были счастливы. До сих пор так делаю, когда вижу винду.
> Маленький нюанс, конфиги приложения могут лежать где угодно. В ~/.config/, в /etc, в /usr/local/bin…В /etc лежат конфиги системные. Пользователь не имеет прав их менять.
В ~/.config пользовательские.Какие конфиги лежат в /usr/local/bin ??
Минус в том, что приходится разрешать запись в каталог. Ещё не всегда можно взять и скопировать каталог на соседнюю машину, требуется чистить настройки-логи.Но это похоже на недоделку из-за нехватки ресурсов. Если развивать дальше их драйвер с оглядкой на пакеты в Haiku (BeOS), можно решить.
> Директорию со всем содержимым удалил и никакого мусора в системе не осталось.1. Почему лог о том, что в системе был пакет X и потом он удален -- это мусор?
2. Где хранить настройки приложения между установками?
Настройки можно хранить в "реестре" или специальном отдельном каталоге. Это решается драйвером-редиректором, либо даже "дубово" на уровне glibc (поскольку всё линкуется с ней).
> Настройки можно хранить в "реестре" или специальном отдельном каталоге. Это решается драйвером-редиректором,И получаем приложение, завязанное на этот реестр. Никогда не приходилось ставить гномовское или кдешное приложение в неродной среде? Они тянут огромное кол-во зависимостей.
>> Настройки можно хранить в "реестре" или специальном отдельном каталоге. Это решается драйвером-редиректором,
> И получаем приложение, завязанное на этот реестр. Никогда не приходилось ставить гномовское
> или кдешное приложение в неродной среде? Они тянут огромное кол-во зависимостей.Приложение видит обычные файлы, для него ничего не меняется. Драйвер ловит обращения к определённым путям и перенаправляет их в другое место, в каталог с именем Реестр, например.
По первому пункту: - это задача пакетного менеджера, если устанавливаем пакет из репы или собственноручно собраный пакет. Как быть с AppImage и иже с ним не знаю. Вероятно писать брокер с применением Dbus, который будет отслеживать и добавлять мету в кэш пакетного менеджера.По второму пункту: мне откровенно говоря сложно представить сценарий, при котором необходимо держать конфиги для удалённого приложения.
Заведите git или какую-то систему для ведения документации confluence или что-то попроще и храните там. Я использую CherryTree для хранения личных заметок, в том числе конфиг файлы.
> По второму пункту: мне откровенно говоря сложно представить сценарий, при котором необходимо держать конфиги для удалённого приложения.Linux многопользовательская ОС. Приложение может удалить пользователь с повышенными полномочиями, а конфиги для него у конретного пользователя зачем удалять?
Если говорить про локалхост с одним пользователем, то конфиги могут пригодиться, если приложение будет установлено заново. Даже apt по умолчанию (без --purge) системные конфиги не удаляет.
в nixos это лучше сделано :)
В принципе все это нехорошо - сделать такое в рамках одного дистрибутива. При разработке я предполагаю, что некая стандартная (как минимум общепринятая) структура каталогов все-таки существует. А такой подход ведет к фрагментации экосистемы, и ни к чему более.
зато проблемы зависимостей нет. Не надо мозг ломать.
nix в принципе на любой дистрибутив поставить можно, даже на macOS, так что nix сам по себе считай и есть стандарт для разработки
> при которой каждая программа устанавливается в отдельный каталога в остальных вот прям рандомно ))
Именно так и есть. Программы буквально размазываются по всей файловой системе, включая конфигурационные файлы. Всё это порождает целый ворох проблем: от трудностей в настройке до поломки системы по причине бардака зависимостей.
Давно пора было отделить либы прог от системных, в конечном итоге все эти флэтхабы к этому и пришли, правда через одно место. Кажется правильнее было аппимэйдж развивать. А ребята забабахали прямо из коробки, такой подход это правильный шаг к гармоничной системе, еще конечно нужно все причесывать, но все равно очень интересно, молодцы!
Так глядишь и через лет 15 дойдут до инсталлеров с Next, Next, Next :)
Этак еще немного и дойдут до "базовой системы" и /usr/local, как самизнаетегде :)
В Караганде, вестимо.
> В Караганде, вестимо.Ачосразутам-то?! Куеда, Барда, Салда, Тавда, Ревда - тоже хорошие города!
> Давно пора было отделить либы прог от системных, в конечном итоге все эти флэтхабы к этому и пришли, правда через одно место. Кажется правильнее было аппимэйдж развивать. А ребята забабахали прямо из коробки, такой подход это правильный шаг к гармоничной системе, еще конечно нужно все причесывать, но все равно очень интересно, молодцы!В отличие от Винды, здесь хз, что системное, а что проги и как их различать.
lxpanel например - это прога, или системное?
А mc - это прога, или системное?
Тут не так все просто.
Для тех, кто тут контейнеры поминает:GoboLinux Initial release 2003; 22 years ago
AppImage Initial release 2004; 21 years ago
Flatpak Initial release September 2015; 9 years ago
> AppImage Initial release 2004; 21 years agoФункциональный [почти] аналог неплохо применяется в macOS. Когда разбирался с упаковкой дистрибутивов, обратил внимание, как же они похожи.
> Функциональный [почти] аналог неплохо применяется в macOS. Когда разбирался с упаковкой дистрибутивов, обратил внимание, как же они похожи.На самом деле он и в Линусах применяется неплохо, просто маковская ЦА радуется что это круто и удобно, а линуксовая ЦА злится, что лишний гигабайт занят и 1% ЦПУ.
Это давнее.
Пора сделать нормально.
Есть желающие?
Лучше иерархии придумать сложно. Пора пересмотреть взгляды на иерархию.
Получается какой-то гибрид мака и гайки.
В маке ВСЁ идеально. Честно признаюсь, что не имею денег на новый мак (б.у. не доверяю, там продают почти всегда технику со скрытыми нюансами и подвохами) и вряд ли когда-то будут, но я каждый раз облизываюсь, когда вижу этот божественный (без преувеличения и сарказма) интерфейс.
Выскажусь в защиту интерфейса мака. Идея с кнопками File, Edit, Help находящимися всегда в одном месте и не отжирающими драгоценное пространство у окон приложений - по истине гениальная.
> В маке ВСЁ идеально. Честно признаюсь, что не имею денег на новый мак (б.у. не доверяю, там продают почти всегда технику со скрытыми нюансами и подвохами) и вряд ли когда-то будут, но я каждый раз облизываюсь, когда вижу этот божественный (без преувеличения и сарказма) интерфейс.Ну, это до тех пор пока не сядешь с этим поработать. Потом некоторые решения начинают жутко раздражать.
>Каталог каждого приложения включает все компоненты необходимые для его работыСразу ффтопку. Distr1 просто хранил разные пакеты в разных каталогах и объединял их в FHS через специальную файловую систему. Жаль, что автору надоело, другого сообщества не объявилось, и даже Дебиан не попробовал разработку к себе интегрировать.
Интереснее, если бы сделали систему файлов на основе тэгов.
Или в виде запросов к БД.
Индексирование и так прикручивают поверх.Иерархии путей/директорий для файлов можно создавать поверх тэгов.
Изменять иерархии не трогая сами файлы.
Ты далеко не первый мечтатель об этом сферическом коне. Увы, в реале это не работает - всё равно ФС надо учитывать характер носителя, операций и т.п. То, что ты увидел аналогию - это похвально (хотя скорее всего просто тупо у кого-то прочитал). Но по факту, абстрагирование от носителя при помощи СУБД тебе не очень много даст, зато полностью лишит тебя преимущества о знании носителя.
Крайне редки случаи, когда программе надо знать что-то кроме получения дескриптора файла.
Может быть 0.001% сервисных утилит. Но и так разберутся с ФС, без лишних абстракций.Тэги позволят передать дополнительные мета-данные файла, о его размещении на диске, либо о типе диска. На с случай, если очень надо.
Работая с тэгами сократятся безграничные портянки путей вида ////, и вывода логов. Текстовые интерфейсы это конечно база Linux, но не очень быстрые, и внимательность программистов страдает.
Преимуществ уйма.
> Интереснее, если бы сделали систему файлов на основе тэгов.Теговые ФС радуют Вас стабильным невзлетанием с 2003 года! Как минимум.
Не, эта идея мертва и провалилась уже слишком много раз. На уровне приложений идея работает, но в ФС ограничиваются симлинками, хардилинками, дедупом.
Проект интересный, но смысла не вижу. Я — наоборот, старательно собираю все конфиги в одну папку, чтобы её снапшотить. А это не так просто: многие "особо одарённые" приложения засирают корень хомяка своими конфигами. Решаю задачу с помощью MergerFS, полёт отличный.
Ну а как увидит смысл админ локалхоста?? Ты ещё не видел реальных конфигов, поэтому твоя "одна папочка" работает.В Gobo сделано всё по-уму, просто ещё не все дозрели до этого. То, что для одной узкой задачи тебе удобно иметь одну папку, ещё не означает, что в регулярной работе это удобно.
На серверах победили контейнеры и виртуалки, никакой gobo там не нужен. Вообще у твоего наезда смысла нет. Я рассуждал с точки зрения пользователя ПК, а не админа серверов.
> Я — наоборот, старательно собираю все конфиги в одну папку, чтобы её снапшотить. А это не так просто: многие "особо одарённые" приложения засирают корень хомяка своими конфигами. Решаю задачу с помощью MergerFS, полёт отличный.Почему просто не управлять .config и прочими конфигами в хомяке через git?
Мысль интересная. Но это что получается: каждый раз, когда я ставлю какое-то приложение, которое записывает свои конфиги, мне нужно их `git add`ить ручками? Либо: можно делать `git add ~`, но тогда всю остальную помойку из хомяка придётся прописывать в .gitignore, и, соответственно, поддерживать его? Нет уж, я лучше чез MergerFS, там всё работает само и кушать не просит :)
> стековая организация дерева каталоговШТА?! Ахинею не неси! Там самая обычная древовидная форма, просто МУСОРА значительно меньше! Вся эта пурга с /bin, /sbin, /usr/sbin упразднена (и слава небу!).
> (например, /System/Index/lib/libgtk.so ссылается на /Programs/GTK/4.18/lib/libgtk-4.18.so)А почему на 4.18, а не 4.17, если главной фишкой заявлена возможность установить больше версий одновременно? И кстати чем это принципиально отличается от /usr/lib/libx.so.1, .so.2 итд?
Принципиально — наверное ничем. Просто навели порядок и выкинули FHS на свалку истории.
Стандартизированную FHS заменили на свой скрепный вариант, никому кроме майнтенеров дистра не известный. Где тут свалка истории, вопрос открытый.
Не с "собственной", а единственно верной.