Вообще-то нормально, жить можно, но если б все было в $HOME/.config жилось бы легче :)

>> клинический случай. была бы одна .config - а в ней всё остальное, без точек...

>Из-за этого идиотизма я не храню файлы в $HOME, чтобы не наблюдать их в мусорке конфигурационных файлов.

+1

>Админ не обязан ставить все приблуды, которые мне необходимы для работы.

если они таки для работы - то обязан.

>А вот зачем нужно на личной машине пихать что-то в /usr/local?

разные скрипты, специфичные для данного хоста.

>Во-первых, эта фенечка (пока) Linux only, во-вторых, с ней и в Linux геморроя хватает.

это фенечка утащена линуксом из план9.

>Может, таки ~/etc (или там ~/.etc)?

таки /etc. читайте пост, на который я отвесал.

по сабжу: мне пофиг, но могу представить ситуацию, когда это будет мешать.

> а на поверку многоуровневые сферические костыли

Plan9 (где подобное уже существует) уже стал костылем?

Костыли там оказываются нужны только для совместимости с текущим положением дел (типа прозрачного транслятора конфигов из new-style /etc/foo/* в «мнимый» old-style ~/.foo.conf)

> KISS.

Это и есть KISS. Когда вместо (собственного, уникального) парсера, читающего два файла (/etc/foorc и ~/.foorc с оверрайдами) у нас есть обычные системные вызовы открытия файла, блокировки, чтения, записи и закрытия. И программа, читающая конфиг из одного фиксированного места (условно говоря — ветки /etc/foo/), представление которого для каждого пользователя отличается.

Да, это не UNIX-way, разумеется. И ни этот вариант, ни UNIX-way не идеальны и близко. Но одно точно — попытка сказать что это — не KISS — ложь.

> dir c:/Documents and settiongs/phasma/.* dir: c:/Documents and settiongs/phasma/.*: No such file or directory

>$HOME/bin есть дебилизм чистой воды, за который надо отрывать йайца.

Легче на поворотах. Куда девать скрипты, которые пользователь пишет для облегчения своей жизни? Для /usr/local/bin они, как правило, плоховато документированы.

> > Админ не обязан ставить все приблуды, которые мне необходимы для работы.

> если они таки для работы - то обязан.

Нет, не обязан. Если хорошо попросить, может пойти навстречу и поставить софт,
который есть в дистре и не требует настройки. Но с просьбой "поставьте, пожалуйста,
libmpfr-svn20080318" заведомо пошлет лесом.

> > Во-первых, эта фенечка (пока) Linux only,

> это фенечка утащена линуксом из план9.

Да хоть из OS/2. Смысл в том, из *NIX'ов, существующих на данный момент, ее
поддерживает только Linux, да и то -- коряво.

Если сотруднику для работы необходима libmpfr-svn20080318, то админ найдет, сорберет, поставит и настроит.

А если админ начинает кочевряжиться, то за что этому умнику платят зарплату?

>переключать настройки волшебным export XDG_CONFIG_DIR.

А потом наш экспериментатор будет долго ломать голову, куда вдруг исчезли все настройки, сделаные пять минут назад, ибо переменная изменилась для _всех_ программ.. ;) Конечно можно XDG_CONFIG_DIR для отдельного приложения, но каждый раз вбивать перед командой запуска XDG_CONFIG_DIR="~/.etc#/"...

Лучше уж симлинки.

>Даже на личной машине -- а где гарантия, что программа с таким же именем случайно не окажется в /usr/bin?

which?

>И все, что ее использовало, не будет "приятно" удивлено

Если в $path /usr/bin задан ПЕРЕД /usr/local/bin, то не будет.

> Есть /etc. С системными конфигами. Когда пользователь логинится мы
> клоинруем его пространство имен и создаем ему свое представление для
> /, ну и для /etc тоже.
[skipped]

> и некоторые файлы из /etc не даем переопределять)

Вот и костыли пошли...

> Со своими точками монтирования (скажем нешительное нет архаизму
> «mount: only root can do that»!), своим блэкджеком и своими шлюхами.

И suid'ными бинарями впридачу.

> или созданием уникальных пространств имен не для пользователей, а даже
> для их приложений.

И посыпятся вопросы "Я скачал файл в ~/downloads, а его там нет. А ПОЧЕМУ?"

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

Эти проблемы еще хуже, чем помойка из .foorc. Простой вопрос -- я отредактировал
/etc/foo.conf из двух разных сессий (== пространств имен), какой вариант "выживет"
в итоге? И таких вопросов можно задать еще сто штук.

> При малом числе заинтересованных в том, чтобы все не просто работало, а было
> логически красиво

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

> > Даже на личной машине -- а где гарантия, что программа с таким же именем
> > случайно не окажется в /usr/bin?

> which?

И так каждый раз, когда я ставлю что-то из дистра? Нет уж, спасибо.

> Если в $path /usr/bin задан ПЕРЕД /usr/local/bin, то не будет.

KISS. Приблуды, которыми пользуюсь только я -- лежат в ~/bin. Все просто
и понятно.

> Если сотруднику для работы необходима libmpfr-svn20080318, то админ найдет,
> сорберет, поставит и настроит.

Еще раз повторяю -- во-первых, не входит это в его обязанности. Во-вторых,
ставилось оно б все равно не в /usr/local (кому-то еще захочется другую
версию -- и что делать?).

> А если админ начинает кочевряжиться, то за что этому умнику платят зарплату?

Может быть, за то, что он поддерживает кластер в работоспособном состоянии?

Для любителей ~/.etc:

export XDG_CONFIG_HOME=$HOME/.etc

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

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

>Для /usr/local/bin они, как правило, плоховато документированы.

А каким местом тут документация? Почему плохо документированые скрипты из ~/bin/ можно запускать, а из /usr/local/bin/ - нет?

>И так каждый раз, когда я ставлю что-то из дистра?

А что, так уж трудно набрать название скрипта, нажать tab и проверить, есть такая команда или нет? Да и придумать название, которого точно ни с чем не совпадёт, совсем не трудно. Не вижу проблемы.

>Приблуды, которыми пользуюсь только я -- лежат в ~/bin.

У меня всего один вопрос: ты эту диру добавляешь в $path или каждый раз набираешь ~/.bin/?

а в моем дистрибе ~/bin по умоланию в PATH

>была бы одна .config - а в ней всё остальное, без точек...

+1

>> и некоторые файлы из /etc не даем переопределять)

> Вот и костыли пошли...

Это не костыли ни разу. Это обычное наложение слоев, чуть более развитая unionfs (вроде AuFS такое умеет, но не помню точно). Оно чем-то сравнимо с, гхм, скажем, ООП с наследованием и final-методами, которые дальше переопределить нельзя — а это костыль? (лямбдафаги, молчать, лол)

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

> И посыпятся вопросы "Я скачал файл в ~/downloads, а его там нет. А ПОЧЕМУ?"

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

Ну и, это... Головой надо тоже думать при использовании, а то мы так до «а пачиму у меня в виндоус иконка интернета была синяя такая в правом углу а тут в правом углу никакого интернета нету? Говно этиваши люнепсы!!!1111» дойдем.

> Простой вопрос -- я отредактировал /etc/foo.conf из двух разных сессий (== пространств имен)

Прекратите мыслить единым / и поймете очевидное. Если эти неймспейсы содержат один и тот же файл — последнее сохраненное, разумеется. Если это разные неймспейсы — у каждого своя копия.

>Товарищ нам сейчас расскажет про современное, глобальное и надёжное решение для хранения конфигов.

Наверное, для него таковым является папка Program Files.

>А каким местом тут документация? Почему плохо документированые скрипты из ~/bin/ можно запускать, а из /usr/local/bin/ - нет?

Наверное потому, что в системе, о ужас, может быть второй пользователь?

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

А в своем дому что хочу, то и ворочу -- privacy, мать её!

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

.config не нужен

~/.documents_&_settings - true!

Поясняю для особо одаренных...

> А что, так уж трудно набрать название скрипта, нажать tab и проверить,
> есть такая команда или нет?

1. Зачем решать проблему, если можно ее не создавать?
2. Нажал tab, увидел, что таки нету. Потом поставил какую-нибудь программу,
и в ней оказался бинарник с тем же именем. И что теперь?

> Да и придумать название, которого точно ни с чем не совпадёт, совсем не трудно.

Вменяемое -- не так-то и легко. Вменяемое -- это

1. короткое (не более 3-x -- 5-ти букв),
2. однозначно поясняющее, что для чего поделка предназначена,
3. легко произносимое.

А чтоб не совпало с чем-то другим -- это еще труднее.

> Не вижу проблемы.

Это не значит, что ее нет.

> > Приблуды, которыми пользуюсь только я -- лежат в ~/bin.

> У меня всего один вопрос: ты эту диру добавляешь в $path или каждый раз
> набираешь ~/.bin/?

Я ее добавляю в _свой_ $PATH, а не в $PATH init-скриптов, демонов, и других
пользователей.

>Я ее добавляю в _свой_ $PATH

Т.е. в случае чего конфликт всё-равно будет?

Случаи бывают разные

> Если админу платят за поддержку серверов почты и веб в работоспособном
> состоянии,

Не только, и не столько (там и без того хватает геморроя).

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

Нету. Потому как заранее не известно, что может потребоваться. То есть,
toolchain, некий джентельменский набор библиотек, и прочие приятные мелочи,
конечно, установлены. А дальше -- "сделай сам".

> и заботится, в частности, о том, что-бы юзвери не имели возможности
> устанавливать что-либо сами.

Случаи бывают разные (C). В частности, на счетном кластере юзвери по
определению имеют возможность устанавливать нужную им софтину.

про костыли

> Оно чем-то сравнимо с, гхм, скажем, ООП с наследованием и final-методами,
> которые дальше переопределить нельзя — а это костыль?

Костыль, как и само ООП.

> (лямбдафаги, молчать, лол)

Ну ладно, молчу.

> > Я ее добавляю в _свой_ $PATH

> Т.е. в случае чего конфликт всё-равно будет?

Будет, но последствий от него будет гораздо меньше.

>Когда пользователь логинится мы клоинруем его пространство имен и создаем ему свое представление для /, ну и для /etc тоже. Которое будет суперпозицией (think unionfs, но чуть-чуть хитрее — мы еще учитываем xattrs и некоторые файлы из /etc не даем переопределять) между «глобальным» /etc и нашим /etc (физически валяющимся в каком-нибудь ~/etc).

в QNX Neutrino 6.21 было похожее, только не для конфигов, а для пакетов. Пакетный менеджер хранил пакеты в QPR-файлах, при установке пакета он монтировался в общую ФС, что-то вроде unionfs и т.п. Вроде в какой-то слаке-livecd есть похожий cloop. Настройки, ЕМНИП, хранились в обычной ФС, не unionfs.

Для этой задачи оно подходило плохо: при установке 1000-3000 пакетов этот unionfs ощутимо тормозил. Типа как поиск в PATH при большом числе каталогов.

Для конфигов -- идея интересная, да и можно наверно сделать так чтобы сильно не тормозило. Как в том же reiserfs с тегами и категориями, и подключать по нужному тегу когда юзер залогинился. и copy-on-write делать для ~/etc

s/QPR/QRP/

> Да, это не UNIX-way, разумеется. И ни этот вариант, ни UNIX-way не идеальны и близко. Но одно точно — попытка сказать что это — не KISS — ложь.

Значит придётся сказать прямо - ты наглый лгун. Попытка совместить _принципиально_ несовместимое, как, например, конфигурационные файлы .procmailrc, .forward, .less{,key}, .emacsrc, .muttrc, .joerc, .cvspass, .cvsrc, .zshrc, .ssh/* и тысячи прочих - это ни разу не KISS, а, как уже сказал, многоуровневые сферические костыли.

Если бы юниковские программы решили, что проще хранить всё в реесте, то давно бы уже появились реестры. (Может они и появились, но никак не в программах, которые использую я.) Также, даже если программа и позволяет иметь отдельно site-global так и user-specific конфигурации, то существуют разные констрейны а то и синтаксисы для них. Не говоря о том, что вовсе неспроста каждая программа использует свой собственный синтаксис (или несколько синтаксисов) для конфигураций. Твои многоуровневые "решения" для совмещения несовместимого настолько усложнят конфигурирование всего, что за попытку обозвать такое кисом тебя надо высечь на месте. :)

> Из-за этого идиотизма я не храню файлы в $HOME, чтобы не наблюдать их в мусорке конфигурационных файлов.

Аналогично. Слишком много конфигов. Бардак. Делаю отдельный раздел на диске, кидаю не него линк из $HOME и все файлы там храню. Быстрее бы ужн перешли на: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html может быть бы полегчало.

>Будет, но последствий от него будет гораздо меньше.

А что тогда мешает в _своём_ $path поставить /usl/local/bin в начало? Всё-равно в большинстве дистров он указан после всех или не указан вообще, так что системным службам ничего не будет.

>Аналогично. Слишком много конфигов. Бардак.

Ещё один, не осиливший отключить показ скрытых файлов? ;)

> Ещё один, не осиливший отключить показ скрытых файлов? ;)

Ага, вот мне болше делать нечего как постоянно включать выключать ЭТО. А Вам удачи в прокачке мышц на пальцах рук в процессе таких постоянных переключений.

> Ага, вот мне болше делать нечего как постоянно включать выключать ЭТО. А Вам удачи в прокачке мышц на пальцах рук в процессе таких постоянных переключений.

Не могу не удержаться от "+1".

По поводу ~/home/bin, неужели так сложно придумать для своего скрипта уникальное название? Если действительно сложно, то тут явно дело уже не в "/usr/local/bin супротив ~/home/bin".

>Ага, вот мне болше делать нечего как постоянно включать выключать ЭТО.

Вам так часто приходится включать-выключать ЭТО? Мои соболезнования..

>А Вам удачи в прокачке мышц на пальцах рук в процессе таких постоянных переключений.

К счастью, я не занимаюсь ежедневным редактированием .bashrc из гуи.. ;)

>> А Вам удачи в прокачке мышц на пальцах рук в процессе таких постоянных переключений.

> К счастью, я не занимаюсь ежедневным редактированием .bashrc из гуи.. ;)

Тогда почему бы тебе не убрать его в ~/.config/.bashrc вместе с остальным "мусором" ?

> > > А Вам удачи в прокачке мышц на пальцах рук в процессе таких постоянных переключений.

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

function dir() { ls --color=always -AFl "$@" | less -cE; }

И используйте себе "ls" или "dir" в зависимости от нужды (или, скажем, "ls -1a").

> > К счастью, я не занимаюсь ежедневным редактированием .bashrc из гуи.. ;)

> Тогда почему бы тебе не убрать его в ~/.config/.bashrc вместе с остальным "мусором" ?

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

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

Придется озвучить. А если у меня валяется временный(е) файл(ы) размером 100 мегабайт и начинающийся с точки ? Или кончающийся на тильдой созданный текстовым редактором временный бекап ? Мне радостно жить и не ведать куда место делось или прокачивать мышцы меняя настройки туда-сюда чтобы узнать - имени файла я заранее не знаю ?


Если бы все лежало в .config вам надо было бы выполнить 1 раз команду
# ln -s ~/ ~/.config
и наслаждатся этим бардаком дальше, а вот остальным стало бы легче.

P.S.
> И используйте себе "ls" или "dir" в зависимости от нужды
Я mc пользуюсь.

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

А если имя файла точно не известно? Можно долго точку нажимать. А если у меня Наутилуса нет, что делать? Это решение не универсальное. Если жить полностью в консоле то приведенный Вами пример скрипта вполне себе ничего, но Линукс для меня не цель администрирования, а в первую очередь десктоп система где я сижу 90% времени. Поэтому удобный UI - это очень важно. А всё администрирование я и так из консоли делаю, ну иногда совмещаю консоль с mc.

в топку липнус даешь фрибсд!!!

под .* попадает абсолютно все