Безумие дотфайлов

Автор оригинала: Filip Borkiewicz
  • Перевод
Мы больше не контролируем свои домашние каталоги.

В моём собственном 25 обычных файлов и 144 скрытых. В дотфайлах хранятся данные, которые не принадлежат мне: они принадлежат программистам, чьи программы решили захватить моё пространство, предназначенное для хранения моих личных файлов.

Я не могу убрать эти файлы в другое место. Если я попытаюсь их удалить, они появятся снова. Всё, что я могу сделать — это сидеть и знать, что в темноте, за кулисами, они есть. Ожидание в тишине. Некоторые из этих программистов решили дополнительно разместить здесь несколько обычных файлов и каталогов. Они хорошо видны каждый раз, когда я выполняю ls. Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock (я никогда сознательно даже не ставил yarn!), какие-то два странных лог-файла от какой-то Java-программы, явно использующей СУБД H2, и папка Desktop. Последнюю создал Steam, что довольно неудачно, поскольку на моей машине просто нет рабочего стола или какого-то десктопа. Боюсь того дня, когда услышу громкий стук в дверь — и один из этих программистов ворвётся и сообщит, что собирается хранить часть своей мебели посреди моей гостиной, если я не возражаю.

Для тех из вас, кто это читает: умоляю вас. Не создавайте файлы или папки любого типа в пользовательском каталоге $HOME, чтобы хранить свои конфиги или данные. Такая практика по меньшей мере странная, и пришло время её прекратить. Мне жаль говорить, что многие, если не большинство программ виновны в этом, в то время как есть значительно лучшие места для хранения данных каждого пользователя.

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

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

Переменные среды пользователя


$XDG_DATA_HOME


$XDG_DATA_HOME определяет базовый каталог, в котором должны храниться файлы данных пользователя. Если $XDG_DATA_HOME не определена или содержит пустое значение, то по умолчанию должно использоваться значение равное $HOME/.local/share.

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

$XDG_CONFIG_HOME


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

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

$XDG_CACHE_HOME


$XDG_CACHE_HOME определяет базовый каталог, в котором должны храниться несущественные (кэшированные) данные пользователя. Если $XDG_CACHE_HOME не определена или содержит пустое значение, то по умолчанию должно использоваться значение равное $HOME/.cache.

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

$XDG_RUNTIME_DIR


$XDG_RUNTIME_DIR определяет каталог, в котором должны храниться несущественные файлы среды выполнения и другие объекты (например, сокеты, именованные каналы...).

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

Системные переменные


$XDG_CONFIG_DIRS


$XDG_CONFIG_DIRS определяет порядок предпочтений для базовых каталогов, в которых будет произведён поиск конфигурационных файлов, в дополнение к $XDG_CONFIG_HOME. Каталоги в переменной $XDG_CONFIG_DIRS должны быть разделены двоеточием.

Если $XDG_CONFIG_DIRS не определена или содержит пустое значение, то по умолчанию должно использоваться значение равное /etc/xdg.

Этот каталог следует использовать для файлов конфигурации системного уровня. Эту конфигурацию могут переопределить пользовательские файлы конфигурации. Скорее всего, этот каталог используется в процессе установки.

$XDG_DATA_DIRS


$XDG_DATA_DIRS определяет порядок предпочтений для базовых каталогов, в которых будет произведен поиск файлов с данными, в дополнение к $XDG_DATA_HOME. Каталоги в переменной $XDG_DATA_DIRS должны быть разделены двоеточием.

Если $XDG_DATA_DIRS не определена или содержит пустое значение, то по умолчанию должно использоваться значение равное /usr/local/share/:/usr/share/.

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

Как это работает на практике?


Использовать стандарт очень просто. Прочитайте соответствующую переменную, а если она отсутствует, то используйте дефолтные пути, определённые стандартом. Там создайте каталог для программы и храните свои данные.

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

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

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

Комментарии 339

    –53
    Какой-то истеричкинг. Автора не возмущает, что какие-то программы могут выкачать зависимость и поставить её? Или тоже попытается удалить?
      +58

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

        +6
        Когда-то давным-давно програмистам было привычно писать в %SYSTEM% — тогда куча софта с антикварными корнями не могла жить без прав администратора.
        Теперь вот это…
          –5

          Когда появился этот "стандарт", а когда — приложения, использующие $HOME для дотфайлов?


          Не нравится — не пользуйтесь этими программами.

          –35
          Встречал людей, которые возмущались «ах, зачем вы в подкаталог /Libs в каталоге вашей программы добавили целых 10 dll Visual Studio Redistributable суммарным объёмом в целый мегабайт? Ведь у меня эти библиотеки и так установлены в системе!».

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

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


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


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


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

              +4
              Это вопрос задач и личных предпочтений, как мне кажется. К примеру, я предпочитаю переносимые приложения (и на Linux и на Windows), где код, библиотеки и все данные (кроме временных и кэшей, которые можно смело сносить, и соответственно, можно использовать $TEMP) находятся в каталоге самого приложения, чтобы простым копирование можно было сохранить или перенести всё, не рыская по куче разных мест с данными, библиотеками и всем остальным, и не зависеть от неожиданных рантаймов.

              Вообще любые (не входящие в систему стандартно) приложения которые требуют установки вызывают зубную боль — потому что установка должна быть эквивалентна распаковке архива, со всем чем нужно внутри, не зависящее от системных библиотек (кроме настолько стандартных, что они с гарантий 101% везде есть и совместимы, разумеется). Такой способ установки удобен ещё и тем что достаточно просто удалить каталог — и вуаля, приложение снесено, без бубна для поиска его остатков в системе (/usr/lib/*, /usr/share/*, /var/lib/* etc, причем не факт что использованные каталоги называются как само приложение).

              Что касается yarn/npm etc (о которых говорится в статье) — мне кажется как раз логично что всё что имеет отношение к проекту хранится в его директории, а не хз где по другим «стандартным» местам (опять-таки, кроме временных данных и кэша) — мне не нравится наличие $HOME/.npm, к примеру, я не хочу его общий для всех проектов (да, у меня резиновый диск, могу себе позволить).

              Разумеется, у других могут быть другие предпочтения или требования, так что в идеале, каждое приложение должно давать пользователю выбор — использовать установочный каталог как относительный корень для всего (это важно — без абсолютных путей) или «стандартные места», определенные в переменных среды.
                +1
                Моё предпочтение — и даже требование — чтобы предложенного вами выбора не было. Так что ваш «идеал» идеалом, устраивающим всех, заведомо не является.
                  0
                  Было бы интересно узнать, почему вы считаете что выбор — это плохо (при наличии адекватных дефолтов), и особенно почему мой «идеал» может кого-то не устраивать (для них ведь ничего не меняется, если они не делают лишних телодвижений).

                  Пользователь, как владелец ресурсов, вправе самостоятельно определять где (каталоги), что (данные, код, кэш) и как (файловая система) должно храниться, в то время как для разработчика это всего несколько лишних строк кода.
                    –1
                    Unix — это добро, не Unix — это зло. В Unix программы ставятся определённым образом (бинарный файл — в /usr/bin или /usr/local/bin, конфиги — в /etc или /usr/local/etc и т. д.). Значит, если где-то происходит не так и программы ставятся каждая в свой каталог — это увеличивает общее количество зла, и нет разницы где рождается зло — на моём компьютере или на компьютере соседа: это всё равно зло.
                      0
                      То есть помойка вида /usr/local/bin/$program_bin добрее, чем /opt/$program_name/$program_bin?
                        –1
                        То есть в первом случае помойка сильно меньше, и вы выбрали очень удачную запись, при которой это бросается в глаза: в первом случае доллар только один, а во-втором — уже два (а на самом деле их там может быть и больше). Количество нефиксированных элементов пути = величина помойки.

                        Кроме того, в первом случае вам не надо заботиться о переменной PATH и её значение выглядит вменяемо. Во втором же случае PATH превращается в непотребство и вам надо менять её при каждой установке/удалении программы.
                          +3
                          Думаю, стоит различать программы в стиле unix (netcat, gzip и т.п., состоящие из одного исполняемого файла) и приложения (Adobe Photoshop, Corel Draw и т.п.), у которых десятки, если не сотни исполняемых файлов и библиотек.

                          Я бы хотел, чтобы у больших приложений файлы лежали сгруппированными по приложению, а не так, что каждое ставило по 40 файлов в bin и по 150 в lib, после чего нереально понять, какой файл поставился с каким приложением.
                            0

                            40 файлов в bin — это 40 приложений*, и каждое из них "состоит из одного файла". 150 файлов в lib — это 150 библиотек. Чтобы узнать с каким пакетом поставилось какой-то приложение или библиотека надо подать соответствующую команду менеджеру пакетов.


                            *Бывают исполняемые файлы, не являющиеся приложениями, но они ставятся не в bin, а в libexec или вроде того.

                              +1
                              Таким образом, приложение оказыватся размазанным по файловой системе — большой файл в bin, много файлов в libexec, где-то ещё может набор файлов с данными/ресурсами, где-то help. А как быстро определить размер, занимаемый приложением на диске?

                              Насчёт засорения PATH. Я думаю, можно делать симлинки в bin, но это должен делать сам пользователь, понимая, хочет ли он получить эту программу доступной без указания полного пути, или согласен каждый раз набирать полный путь к исполняемому файлу (во втором случае он имеет возможность параллельно поставить несколько версий и явно указывать, какую запускать).
                                0
                                а еще бывают jarники…

                                Вот, например, IntelliJIDEA — все прекрасно лежит в отдельном каталоге типа /opt/idea. И я не хочу, чтобы это попадало в системные папки. Unix-style программы, которые часто нужны, и состоят только из одного бинарника — ну, ок, пускай едут в /usr/local/{bin, sbin}, а не в общесистемные каталоги
                                  0
                                  > А как быстро определить размер, занимаемый приложением на диске?

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

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

                                    В винде тоже самое, куча игрушек предлагает поставить DirectX, или .dot фреймворк поновее, причем там еще и проблемы с версиями. Но место под directX никто не считает частью игрушки, и это нормально.
                                      +1
                                      Тут вопрос — сколько можно освободить места, удалив ту или иную программу. Если все файлы программы в отдельном каталоге, то это гарантированный размер, который станет доступен при удалении каталога.

                                      DirectX — такая ностальгия. По-моему, последний отдельный дистрибутив выходил в 2009 г. (и его включают некоторые игры для совместимости с Windows 7), а дальше версии DX уже входят в поставку Windows и отдельно не устанавливаются.
                                        0
                                        Ну а в Линуксе до сих пор нет штатной графической либы для всех. Каждый GUI может свой винегрет за собой таскать.
                                        С другой стороны, библиотеки — по современным меркам не такие уж большие.
                                          0
                                          Мне какая-то программа недавно заказала DX и отказалась ставиться. Win7 или 10 — не помню.
                                            +1
                                            Мне какая-то программа недавно заказала DX и отказалась ставиться. Win7 или 10 — не помню.

                                            Это неважно. Есть много программистов которые не соблюдают стандарты и рекомендации. Есть много программ, которые были написаны еще для 9x линейки и до Vista/win7. Ваш единичный случай просто исключение, которые будут всегда.

                                            Но в Линукс просто нет единых рекомендаций и стандартов, вдобавок этих единых рекомендаций в ближайшее время не ожидается, потому что дистрибутивов много, шанс что они все договорятся — минимальный
                                  0
                                  ls /usr/bin/ | wc -l
                                  916
                                  


                                  1000 файлов в одном каталоге (это всего лишь Raspberry) — вполне себе достаточно злая помойка. Какая разница, как они разложены (в одну папку или в 500), если без менеджера пакетов я не могу ни удалить ни один из этих файлов, ни переместить в другое место? И даже о их роли в системе можно только догадываться.
                                  Заботиться о переменной PATH? Пусть о ней заботится тот, кто устанавливает файлы (менеджер пакетов же).
                                    –2

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

                                      +2
                                      Я намекаю, что делать по Unix-овски — это тоже плохо.
                                      man hier, который нам диды завещали, не помогает ни место, занятое программой посчитать, ни найти ее данные или конфиги… А раз есть пакетный менеджер — какая тогда разница, где находятся файлы?
                          0
                          Вы не умеете пользоваться менеджерами пакетов в линуксе? Иначе непонятно, откуда такое желание вручную что-то переносить и удалять. «Менеджеры пакетов конкретного языка» типа npm ужасны как раз тем, что делают примерно как вам нравится — «давайте засунем и код, и модули в одну папку», и плевать, что потом у юзера домашний каталог на 10% занят его файлами, и на 90% непонятно чем.
                            0
                            Хочу подчеркнуть, я не навязываю никому свою точку зрения — я всего лишь хочу чтобы у пользователей был выбор, в зависимости от их целей, задач и личных предпочтений, а не жёстко установленные кем-то извне (разработчиками, мейнтейнерами систем и пакетов) требования где и что должно находится.

                            А теперь более подробно.

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

                            В реальном же мире мы имеем зоопарк дистрибутивов, менеджеров пакетов, репозиториев, причем те кто всё это поддерживает не могут договориться даже об именовании пакетов (lib*-dev в ubuntu/debian, *-devel в centos/fedora), адекватном именовании и расположении конфигурации (postgres/exim в debian/ubuntu и centos/fedora яркие тому примеры), не говоря уже о том что в ряде случаев «официальные» репозитории сильно отстают от жизни по версиям.

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

                            Стоит также отметить что некоторым из нас приходится иметь дело с несколькими версиями приложения одновременно, которые никак не поставить «стандартными» менеджерами пакетов.

                            Так что да, для банальных вещей типа sed/bash/mtr/ping/traceroute/gcc/make/etc я воспользуюсь менеджером, но для чего-то отсутствующего в репозиториях (вообще или нужной версии) — уж извините, лучше я всё буду держать в $HOME (в конце концов, это моё личное пространство — поэтому позвольте уж мне решать что туда «пихать»).

                            Мне также удобно сделать rsync с одной машины на другую (даже если одна debian, другая centos) и быть уверенным что всё осталось на своих местах и работает (в $HOME), чем плясать с бубном для синхронизации пакетов на обеих.

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

                            Когда-то очень давно, когда дисковое пространство было сильно ограничено, а сами накопители были медленными, всё было несколько иначе, но сейчас можно себе позволить не думать о shared libs и прочих анахронизмах, по крайней мере в случаях когда это не цельный проект, зависящий от них.

                            Надеюсь, я достаточно аргументировал свою позицию?

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

                              Он существует — pacman, ArchLinux. У него есть архив старых пакетов. Если вдруг из-за новизны системы старый пакет уже не работает — пересобрать пакетом же старый под систему с обновленными либами очень легко.
                              но сейчас можно себе позволить не думать о shared libs и прочих анахронизмах

                              Shared libs нужны не для экономии места. В первую очередь они уверенность, что используется именно то, что нужно. К примеру я знаю, что версия 1.2.3 имеет эксплоит. И я, установив 1.2.4 с исправлением этого эксплоита уверен, что моя система защищена. А если у меня по системе либ версии 1.2.3 раскидано с разным софтом с десяток, уверенности у меня никакой нет.
                              невозможность использования менеджера пакетов обычным пользователем

                              Так а зачем, зачем использовать его без sudo? Сложно дописать sudo к команде что ли?
                              сюда входит также возможность полной переустановки системы (или её апгрейда)

                              Нормальную систему не надо переустанавливать. В общем попробуйте rolling release дистрибутив, например Arch, избавитесь от многих описанных проблем. Я даже с 32 на 64 без переустановки переходил (сами вспоминайте, сколько ж это лет назад вообще было), а уж нынче я вообще не представляю, зачем что-то переустанавливать на десктопе. А серверы все равно через ansible катятся и там все вышеописанные проблемы отсутствуют или решаются иначе, нежели на десктопах.
                                +1
                                Ваше предложение — это как раз уже упомянутый мной «идеальный мир» (отчасти). Осталось убедить моих клиентов (и большинство других) перейти с CentOS/Ubuntu на ArchLinux, и проблема будет решена — как всё просто, оказывается. А ведь именно из-за них мне приходится держать у себя весь этот зоопарк систем.

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

                                К примеру я знаю, что версия 1.2.3 имеет эксплоит. И я, установив 1.2.4 с исправлением этого эксплоита уверен, что моя система защищена.

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

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

                                Даже для серверных приложений это иногда очень удобно, в частности, это фишка DotNet Core — «просто скопируй это» — и всё работает.

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

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

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

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

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

                                  А в чем проблема? Если вы понимаете преимущества — вы их и клиентам объясните. А если не понимаете… ну тогда или поймите, или живите как привыкли.
                          0
                          Я как-то пытался весь home забэкапить, просто переписав на другой диск. Несколько часов переписывалось и ругалось на кривые имена. Хотя там моих файлов было немного, мегабайт тридцать. Не подозревал СКОЛЬКО там барахла валяется от программ.
                            0

                            через smb что-ли бекапили?

                              0
                              Просто копи-паста стандартными средствами.
                                0
                                Стандартные средства, это хотя бы tar, который упростит ситуацию с именами файлов и уменьшит место даже без сжатия. А со сжатием еще и скорость увеличится.
                              +1
                              dotfiles.github.io вот тут можно поискать вменяемое решение
                            +3
                            Когда-то давно встречал программу под винду, которая хранила свой конфиг на рабочем столе. А если таких «программистов» будет много, представили? Вот что-то подобное автор и описывает.
                              0
                              Для порядка аналогии — не на рабочем столе, а в Documents. Впрочем, нынче так и делается. Еще и с точкой в начале — для совместимости, наверное…
                            +3
                            Автора бесит, что на винде с идиотами засирающими корень диска C: уже давно справились, а в линуксе они серют и серют.
                              +10

                              в Linux в корень перестали срать гораздо раньше

                                +3
                                Э не, тут скорее аналог AppData (между прочим, тоже находящемся в папке пользователя)
                                  +7

                                  скорее C:\users\username. А автор как раз ратует за то чтоб пользовались appdata.)

                                    +2
                                    Ну, я в своём c:\users\ никогда не знал, что происходит, честно говоря. А файлы тоже раскиданы: что-то падает в %userprofile%/Downloads, что-то в %userprofile%/Documents, так что тоже тот ещё бардак. Было бы удобнее наоборот — корень мой, а всё системное — в соседней папке.
                                      0
                                      Толку, если она все равно будет в хомяке?
                                      Да, вместо десятков файлов и папок, оно будет лежать в одной подпапке. Подпапке хомяка.
                                      C:\Users\username\AppData
                                        +1
                                        Так ровно тоже самое предлагает инициатива из топика, только там чуть больше директорий от корня хомяка.
                                    +1
                                    А давно ли Oracle перестал это делать?
                                      +1
                                      А перестал? Оо
                                        0
                                        Я года три их не трогал, так что не в курсе.
                                      +10
                                      На винде была и остаётся проблема с засиранием профиля пользователя. Причем главные «засиратели» — портированные с линукса программы, которые не в курсе про подкаталоги AppData\Local и AppData\Roaming

                                      Причём в последнее время к ним добавились ещё и кроссплатформенные программы от самих Microsoft…
                                        +2
                                        Больше всего там бесят исполняемые файлы. Настраиваешь себе SRP, настраиваешь, а какой-нибудь uTorrent так и норовит в профиль залезть.
                                        +8
                                        что на винде с идиотами засирающими корень диска C: уже давно справились

                                        C:\Intel\Logs

                                        Эх…
                                          +2
                                          Из последнего — nVidia стала месяц назад создавать пустой «C:\NVIDIA Corporation\umdlogs». Накой хрен он мне на корне в C:\ — вопрос наверное к тем особым программистам, которые и инсталлеры в C:\ распаковывают…
                                            +1
                                            Установщики тоже в C:\NVIDIA распаковываются. А еще она не удаляет старые версии драйверов, так что через какое-то время папка NVIDIA Corporation может начать ставить рекорды.
                                            0
                                            C:\MSOCache туда же. И PerfLogs наверно тоже. Инсталляторы/обновляторы от MS тоже любят создать пару зубодробительных каталогов в корне диска и забыть удалить их.
                                              +1
                                              С инсталляторами от МС ещё весело, они они создают каталоги в корне самого свободного диска. А это далеко не всегда системный.
                                            0
                                            Не только в Linux, но и в MacOS тоже…
                                          +3

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

                                            +1
                                            Я-то уж думал, что кто-то связный вопль написал по-русски, а не просто перевел… Потом смотрю — ан, нет, это я просто значка «перевод» не заметил.

                                            Такое впечатления, что западные авторы (не в значении «авторы учебников», а в значении «кому не лень написать рефлексию») чаще задают себе вопрос "а почему оно так?" Русскоязычная публика (ок, ex-USSR-users), как кажется, более привычна к «сказано делать так — так и будем».

                                            P.S. Следствие, кстати — это когда мудрый админ насаждает среди юзеров «так делать правильно», но почему правильно — сказать не может. Привык он, понимаешь! Потом получаются почтовые ящики вида ivanov_ve@mx.company.ru, и веб-сайты, которые отзываются только на www.company.ru (т.е. без www не откроешь).
                                              +1
                                              А можно спросить, что за mx? Это тоже была какая-то мода на разделение сервисов по доменам?
                                                0
                                                Ну, типа запись доменная MX — должна указывать на Mail eXchange.
                                                Оно же и субдомен для типового MX-сервера.
                                                  +3
                                                  Есть такой (довольно логичный) подход:
                                                  — у вас есть ваша организация, и все, что в ней, вы считаете «своим», «вашим доменом». Под это дело выделяем домен, скажем, company.org.
                                                  — хосты организации заводим внутри этого домена, это будут host01.company.org, pc05.company.org и пр.
                                                  — для того, чтобы проще было запомнить, за почту у нас будут отвечать машина с именем mail, или mail exchange (кратко — mx), т.е., соответственно, mail.company.org или mx.company.org, за веб-сайт — www.company.org. Получилось, что ящики стали заводить «на» (по-английски — «at», или "@") почтовом сервере, т.е. ящик стал писаться как логин-на-машина_в_домене, напр., john@mx.company.org. Просто и понятно, правильно?

                                                  Да, позже придумали MX-записи в ДНС, и это позволило указать почтовый сервер, который принимает почту для домена — т.е. ящики стало возможно заводить просто как имя-ящика@домен, но труЪ-админы считают этот подход подходящим «только для сосунков», и делают как раньше, надежно и кондово.

                                                  Точно так же, веб-сервер с именем www.company.org отдавал сайт компании, даже если к нему обратиться по IP на 80/tcp порт (номер порта — соглашение), но «с тех пор» появились и name-based vhosts, и юзерам стало лень писать www, так что один веб-сервер сегодня отдает порой тысячи сайтов, и «отзывается» обычно как на «www.домен», так и на просто «домен», но разве это для труЪ-парней?

                                                  Причем перемены эти подталкиваются общим изменением традиций. Как в русский язык вплетаются нерусские слова (да то же слово «тру»/«труЪ» *смайлик*), так и в традиции работы с ИТ добавляются порой странные вещи (напр., обсуждать деловые вещи в, свят-свят, мессанджерах, или им же заменять, безусловно, православные и труЪ, СМС-ки!).

                                                  А, да, забыл: видел труЪ-админа, который вместо указания хотя бы пары MX-ов для домена (что дает резервирование) имел настроенных почтовых серверов несколько, но имя (то, что после собачки в мыле у него было) mx.company.org переносил в ДНС на тот из них, который в этот момент был первичным, причем почта для юзеров у него была строго по pop3, так что, случись авария, терялось немного, только непринятая с бывшего (умершего) сервера почта. Опять же, это не HA, зато надежно же!
                                              +5
                                              Больше десяти лет назад что-то подобное уже было. GNOME целую кампанию провёл для наведения порядка. Вот только остальные не всегда следуют стандарту.
                                                0
                                                Видимо нужно в свежей версии ОС запретить писать.хрень в домашний каталог, за исключением путей из XDG, глядишь тогда прочитают документацию.
                                                  +4
                                                  Если б можно было определить на уровне ОС, где конфиги, а где файлы пользователя.
                                              +8

                                              Меня вообще, работать в /home/username/ в принципе не устраивает. И так как на мои компьютеры работаю только я, то делаю так — выделяю два раздела по 50ГБ под ОС (так могу экспериментировать с разными дистрибутивами), а все остальное пространство диска выделяю под раздел который монтирую как /work


                                              И так как Linux вообще не знает о нем, то и никогда туда ничего не пишет. Дополнительный плюс это то, что файлы доступные одновременно в двух ОС (дот файлы не позволяют монтировать этот раздел как /home/username). Ну, и мигрировать на новый компьютер/диск легче.

                                                +1
                                                Меня вообще, работать в /home/username/ в принципе не устраивает.

                                                А что за работа такая «в /home/username/» и что именно не устраивает?
                                                  +3

                                                  Мой русский не так чтобы очень, так что может и глупость сморозил. :)


                                                  Я имею ввиду место, в которое сохраняю все мои файлы – над которыми работаю или просто смотрю. Ну там, проекты всякие, картинки, фильмы, музыка и т.д.

                                                    +1
                                                    Так понятнее. Хоум и правда не лучшее место для медиа. Думаю у большинства, как у вас, для этого отдельный диск или сервер.
                                                  +5
                                                  Ну, и мигрировать на новый компьютер/диск легче.

                                                  Легче, чем что? У меня home отдельным разделом монтируется. Если решил поменять систему — форматнул / и накатил новую, Подцепил home и, как будто, ничего и не происходило. Все настройки на месте. Правда проблему срача в home это не решает :(
                                                    +3

                                                    И весь мусор тоже там будет. И заметьте в новой ОС, программы эти может и не быть, а то что они оставили в /home/ останется и отделить нужное от ненужного, невозможно в принципе. Бардак с времени будет только увеличиваться, но никак не уменьшатся. Именно поэтому я так не делаю.

                                                      0
                                                      На самом деле отделить до определённой степени можно (по крайней мере у меня по названию чаще всего можно определить хозяина, хотя судя по статье — так бывает не всегда). Ну можно просто грохнуть все файлы с непонятным владельцем, или вообще все дот-файлы.
                                                      Просто тут только 2 варианта, либо разбирать/чистить, либо терять все настройки. Но второе по мне — не всегда удобно. Например профили браузера терять неприятно.
                                                        +1

                                                        Конечно всегда можно почистить вручную, но в моей /home 75000 файлов, которые не я там записал, а система/программы. А в /work около миллиона файлов, которые записал там я и которые более или менее мне нужны. Понимаете, что сортировать все это вручную просто нереально.

                                                          0
                                                          75к? О_О У меня штук 20 всего. Это сколько же программ нужно, чтобы столько накидать?
                                                          Да, в вашем случае явно требуются особые меры. Кстати 1М файлов система вообще нормально держит? Тем же даже открытие файлов уже подлагивать может. Или используется какая-нибудь серверная фс?
                                                            0

                                                            20? Этого не может быть. Все конфиги и кеши браузера будут намного больше. Попробуйте так:


                                                            find ~ -type f | wc -l
                                                              0
                                                              Все конфиги и кэши у фоксы живут в одном каталоге. Я учитываю срач только в юзере, что там в подкаталогах уже пофиг. Во первых глаза не мозолит и искать нужное не мешает (к чему у меня основная претензия), а во вторых прибивается в один клик.
                                                              Но если считать все файлы вообще, то да, там один профиль фоксы потянет… хз, но прилично потянет. Ради интереса вечером гляну.
                                                                +1
                                                                искать нужное не мешает

                                                                Если find-ом, то очень даже мешает.
                                                                0
                                                                Суммарно 24к файлов на 3Гб. Как всё запущено! :(
                                                                  +1
                                                                  mike@mike:~$ find ~ -type f | wc -l
                                                                  324336

                                                                  Мне страшно спросить...

                                                            0
                                                            Если я всё правильно понимаю, с позиции моего скромного опыта линуксоюзера, то home в Linux по факту выполняет примерно те же функции, что Documents и AppData в Windows. Под Windows здравомыслящий пользователь не станет хранить в Documents рабочие проекты и личные файлы, соответственно — и в Linux разумно поступать так же, оставляя за home только его служебные функции раздела, хранящего пользовательские настройки софта.
                                                              +4
                                                              Нет, не правильно понимаете.

                                                              Если кратко, то home это место где юзеру соблаговолили доступ на запись и место, где он повседневно должен работать (если пользователь так же является администратором, то он тоже должен сидеть в хомяке, используя root, только для администрирования.)
                                                                +1
                                                                >доступ на запись и место, где он повседневно должен работать

                                                                Ну, с включенным UAC в Windows 10 примерно то же с попытками что-то записать в системные папки, и Документы вроде бы как предполагаются местом работы… Аналогия с Linux, конечно, грубая и поверхностная, но имхо не совсем уж ложная.
                                                                0
                                                                В реально многопользовательском Linux папка home — единственное место, где пользователь может хранить файлы. И если раньше мусор был хотя бы скрытым, то папка snap — это уже совсем зашквар. Когда делать нефиг, удаляю её и пишу разрабам багрепорт, что всё сломалось. С логами, но без указания причины.
                                                                  +1
                                                                  А чего не пуллреквест с фиксом?

                                                                  Сорян, но тратить jff-ресурсы на развлечение таких козелов — зашквар куда больший, чем папка snap.
                                                                    +1
                                                                    А вы переписку разрабов про эту папку почитайте — там больше санта-барбары чем в Санта-Барбаре. А пулл-реквеста с исправлением теперь никогда не будет — путь к папке захардкожен в куче разных мест, и во всех местах его надо изменить одновременно, иначе сломается. А это значит, надо одновременно принять изменения в разные подпроекты, разными людьми. А они до сих пор собачатся по этому вопросу в стиле «так не доставайся же ты никому!».
                                                                      0

                                                                      А где переписка-то?


                                                                      Если путь захардкожен в куче разных мест, то сначала надо отрефакторить эти места и вынести это всё в отдельную функцию/модуль/что у вас там, которая бы использовалась в остальных местах (и это можно делать без необходимости синхронизации разных подпроектов). А там уже и менять можно.

                                                                    0
                                                                    В /tmp и /var/tmp любой пользователь de facto может создавать любые файлы и каталоги (они автоматически создаются принадлежащими ему самому и доступными только ему на запись) если они уже не созданы
                                                                      0
                                                                      Не уверен, что темпы являются адекватным местом для хранения чего бы то ни было долговременного. А то может они у меня в рамдиск смонтированы (на винде у меня так и есть).
                                                                        0
                                                                        А где я говорил, что это адекватные места? Это был не более чем контрпример для утверждения
                                                                        В реально многопользовательском Linux папка home — единственное место, где пользователь может хранить файлы.

                                                                        А ещё эти два пути имеют одно принципиально различие, из-за которого первый (/tmp) адекватно рамить, а второй (/var/tmp) — нет
                                                                        0
                                                                        Не совсем так.
                                                                        Созданные файлы и каталоги в /tmp может удалить только владелец благодаря флагу sticky bit на /tmp
                                                                        но вот внутри подкаталогов — зависит от umask
                                                                      +1

                                                                      home — это аналог директории Users. Роль Documents выполняет /home/<user>/Documents, а роль AppData должна выполнять /home/<user>/.config, однако многие приложения пренебрегают этим, что и является причиной написания данной статьи.


                                                                      Под Windows здравомыслящий пользователь не станет хранить в Documents рабочие проекты и личные файлы

                                                                      Потому что она в 99% случаев лежит на том же разделе, что и система, и при переустановке всё может уничтожиться?

                                                                        0
                                                                        >многие приложения пренебрегают этим

                                                                        Сталкивался со реальным спамом файлами .serverauth.##### в home.

                                                                        >Потому что она в 99% случаев лежит на том же разделе

                                                                        Ну да. Одно дело — личные компьютеры, но мне попадалось удивительно мало систем во всяческих конторах и даже компаниях, которые бы выбивались из этих 99%…
                                                                          +2

                                                                          Потому что в винде перенастроить Users на другой раздел не тривиально и чревато багами. Линукс при установке предложит сделать отдельный раздел для home, что в сообществе разумно считается best practice.

                                                                            0
                                                                            Не нужно перенастраивать Users на другой раздел, достаточно линки Documents и пр. перенастроить.
                                                                            И наказать Oracle за создание .VirtualBox.
                                                                              +1
                                                                              И наказать Oracle за создание .VirtualBox.

                                                                              И Microsoft за .VSCode.
                                                                                0
                                                                                И .vs
                                                                                  0
                                                                                  А что не так с .vs? Оно же создаётся не в домашней директории, а в директории решения.
                                                                                    0
                                                                                    У меня в хомяке лежит. Там каталог Extensions с единственным файликом languages.cache
                                                                            0
                                                                            Странно, конечно. Я первым делом после переустановки системы все пользовательские папки (документы, музыку, фильмы и т. п.) переношу на D:. Этими папками очень удобно пользоваться в винде — хорошо интегрированы в интерфейс.
                                                                            +1
                                                                            Потому что она в 99% случаев лежит на том же разделе, что и система, и при переустановке всё может уничтожиться?

                                                                            Потому что до висты она называлась "C:\Documents and Settings\<user>\Мои документы", и из-за русских буков в названии половина программ отказывалась с ней работать. Это если не вспоминать о пробелах в названии, с которыми не может работать каждый первый батник...

                                                                              +2
                                                                              В итоге вместо фикса программ наворотили непроходимую чащу точек соединения и симлинков на системном диске. И я даже не уверен, не является ли получившийся граф ациклическим.
                                                                                +1
                                                                                является ли получившийся граф ациклическим.
                                                                                Нет, потому что
                                                                                C:\Users\Name\AppData\Local\Application Data → C:\Users\Name\AppData\Local

                                                                                Но спасает, что длина пути не более MAX_PATH=260 знаков (если не использовать префикс \\?\), поэтому рекурсивный поиск не зацикливается, а останавливается на некоторой глубине.
                                                                            +1

                                                                            Каталог "Мои документы" изначально предназначался для документов, ровно так же, как Рисунки для картинок, Музыка (внезапно) для музыки и так дальше. Просто некоторые интеллектуалы решили, что Documents = AppData, и началось...


                                                                            Всегда бесился с игр на Unreal Engine, которые добавляли конфиги в Documents/My Games, будь они здоровы. Пришлось смириться, что первобытный смысл дефолтных каталогов умер, кто что хочет то и воротит

                                                                              0
                                                                              В старых версиях Windows не было папок под пользовательскую музыку и рисунки, была только папка «Документы». Поэтому что должны были использовать по умолчанию авторы аудио/фото-редакторов?
                                                                                0
                                                                                Насколько старых? В XP всё было, а это, на минуточку, 18 лет назад, эпохи прошли с тех времён.
                                                                                  +1
                                                                                  Как минимум, в WinXP не было Saved Games (т.е. сохраняшки некуда класть, кроме документов), а папки My Music, My Pictures, My Videos находились внутри Documents. Поэтому авторы, которые
                                                                                  добавляли конфиги в Documents/My Games
                                                                                  просто следовали системным соглашениям.
                                                                                    0
                                                                                    Application Data была уже тогда )
                                                                                      +1
                                                                                      Да, но файлы сохранений — это пользовательские файлы, их нельзя хранить в Application Data.
                                                                        0
                                                                        Я делаю /username/work, но ваш вариант еще прикольней, да
                                                                          0
                                                                          А почему /work, а не /opt, не /usr/local, не /var?
                                                                            +2

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


                                                                            А мне нравится наоборот — пусть ОС сидит там где ее поставили, а все остальное мне. :D

                                                                              0
                                                                              /home/user/mywork — туда никто не полезет. Это вообще может быть ссылка на другой раздел.
                                                                                –1
                                                                                Грубо говоря, какой-нибудь шифровальщик может испортить весь /home, а утилита кражи данных стащить все doc-файлы из home. С корня же никто не ищет, т.к. можно нарваться на всякие /dev /proc
                                                                                  +1
                                                                                  Известные мне шифровальщики ищут везде по расширению, а не по /home.
                                                                                  И кстати именно с корня. И уже про /dev /proc авторы догадываются.
                                                                            0
                                                                            Вы же можете как угодно переопределить этот каталог при создании пользователя. Или даже поменять. Можете сделать просто /username или сразу /work сделать своим домашним каталогом. Не говоря уже о символьных ссылках…
                                                                              +4

                                                                              Только, если так, то Линукс будет знать что это моя "домашняя директория" и здравствуйте дот файлы, кеши, теща и вся родня. :P

                                                                                0
                                                                                Да, от этого не спасает, именно об этом и статья. От «произвола программистов» не спасут никакие соглашения, если их не соблюдать…
                                                                                  0
                                                                                  Если про тёщу и всю родню — не болгарская идиома, то вам надо писать художественные произведения. :)
                                                                                    0

                                                                                    Грамматика у меня хромает… а так, словарь хороший… совершенно несбалансированный билд. :D

                                                                                0

                                                                                Спасибо за пример решения! Очень интересное.


                                                                                По такому же принципу использую отдельный диск, который доступен и на винде тоже.
                                                                                Занимаюсь монтажом видео в свободное время и, когда есть вдохновение, так что, нужна винда :)
                                                                                Директория $HOME используется, как мусорка по причине, описанной в статье.

                                                                                  0
                                                                                  lifehack. Если каталог называть не «work», а «do» то печатать меньше, а смысл все-равно остается :) Каждый раз когда нужно сделать cd, каждый конфиг, каждый абсолютный путь. Для миграции можно использовать симлинк.
                                                                                    +2
                                                                                    Почему do? Если имя каталога сделать из одной буквы или цифры, печатать ещё меньше.
                                                                                      0
                                                                                      Из одной буквы — имя не будет осмысленным.
                                                                                        0
                                                                                        Зачем осмысленное для всех имя? Лично для себя это быстро запомнится, также можно придумать любую запоминающуюся расшифровку этой букве/цифре.
                                                                                      0

                                                                                      Нет, "do" не подходит. Потому что конфликтирует с "dev" при автозавершение (tab) в конзоль. "Запрещенные" буквы: "b, d, e, h, l, m, o, p, r, s, t, u, v".


                                                                                      Вот как пишется например: "cd /work/": "C, D, SPC, /, W, TAB", Что то же самое как "C, D, SPC, /, W, /".


                                                                                      А "cd /do/" на одно нажимание больше: "C, D, SPC, /, D, O, /"

                                                                                        0
                                                                                        При печатании do TAB не экономит нажатия (так и так одна клавиша). Но собственно мое дело предложить — ваше отказаться, я не настаиваю.
                                                                                          0
                                                                                          У вас есть uppercase и алиасы
                                                                                          0
                                                                                          Лучше уж bash alias тогда делать.
                                                                                            0

                                                                                            ещё лучше — в хомяковом bin каталоге писать скрипты вместо алиасов — тогда не только в bash будут видны, но и в других оболочках

                                                                                        +8
                                                                                        Вот интересно, а откуда я должен был узнать от этом стандарте, если ты не эта статья?
                                                                                          +10
                                                                                          Это черта хорошего разработчика: посмотреть на готовые решения, стандарты, рекомендации, требования и best-practices — прежде чем велосипед свой велосипедить.
                                                                                            +14
                                                                                            Ну так они и смотрят на готовые решения и не делают велосипедов:
                                                                                            cd ~
                                                                                            ls -a
                                                                                              0
                                                                                              Тильда здесь избыточна.
                                                                                              +1
                                                                                              Готовые решения — это как раз процентов на 90 программы, пишущие свои конфиги в $HOME/.*.
                                                                                              Кстати, ради прикола посмотрел сейчас в QSettings — уж казалось бы, вот они, best practices в полный рост. А присмотришься — они тоже по умолчанию пишут в $HOME/.config/что-то-там, даже если задана переменная XDG_CONFIG_DIRS. Вот если переменная задана, и нужные подкаталоги и файлики уже присутствуют — тогда QSettings будет использовать их. А без этого — нагадит в $HOME.

                                                                                              Рекомендации — о-о-о, их есть много всяких разных, включая запись конфигов в xml или вообще в аналог реестра в бинарном формате. Не факт, что попадется правильная.
                                                                                              +2
                                                                                              Вот интересно, а откуда я должен был узнать от этом стандарте, если бы не эта статья?
                                                                                              Та же мысль пришла в голову. Множество программ создают свои файлы и директории прямо в $HOME, а тех, которые поступают по стандарту, сразу и не заметишь. Вот и получается…
                                                                                                +2
                                                                                                Ещё интереснее. Я человек любопытный, ОС у меня POSIX-совместимая и довольно свежая, однако
                                                                                                netbug@NETBUG-MBP:~$ env | grep XDG
                                                                                                netbug@NETBUG-MBP:~$


                                                                                                Как узнать про их работу, если ОС не выставила их?
                                                                                                Окей, идём на сервер с Ещё Более Правильной ОС.
                                                                                                netbug@srv_ci:~$ env | grep XDG
                                                                                                XDG_SESSION_ID=12996
                                                                                                XDG_RUNTIME_DIR=/run/user/1000

                                                                                                Отлично. Но путей для настройкопомойки тоже нет, я бы даже не подумал разбираться с ними
                                                                                                  0
                                                                                                  % env | grep XDG
                                                                                                  XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
                                                                                                  XDG_VTNR=7
                                                                                                  XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/lorc
                                                                                                  XDG_SESSION_ID=2
                                                                                                  XDG_SESSION_DESKTOP=i3
                                                                                                  XDG_SESSION_TYPE=x11
                                                                                                  XDG_CURRENT_DESKTOP=i3
                                                                                                  XDG_SEAT=seat0
                                                                                                  XDG_RUNTIME_DIR=/run/user/1000
                                                                                                  XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0

                                                                                                  У меня еще чуть более свежая ОС, судя по всему.

                                                                                                  А вообще стандарт говорит, что если та же XDG_CONFIG_HOME не определена, то нужно использовать $HOME/.config/.
                                                                                                  Поэтому все эти переменные с путями и не определены обычно.

                                                                                                    +1
                                                                                                    NETBUG-MBP

                                                                                                    Так у вас наверно ~/Library/Application\ Support для этого есть? :-)

                                                                                                +3
                                                                                                Как по мне, так многие проекты, в частности на NodeJS, даже учитывая что они гадят исключительно в своём же каталоге, являют собой натуральный бардак. Я всё понимаю, на счёт зависимостей, но проект, весом в пару мегабайт от силы, который грузит для своей работы 300 метров в папку node_modules (и я нисколько не преувеличиваю, если проект крупный то даже больше) выглядит как явный признак шизофрении его создателя.

                                                                                                Надеюсь, когда-нибудь кто-нибудь из тех, кто бездумно кидается использовать любую новую фичу, будет для начала думать о том, как внедрить её красиво и чего это будет стоить.
                                                                                                  +1

                                                                                                  Эта проблема, увы, не только разработчика, в NodeJS вот так. 300MB — это еще хорошо. В кровавом энтерпрайзе и 1.5GB+ видели...

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

                                                                                                      Оно? https://pnpm.js.org/


                                                                                                      pnpm uses hard links and symlinks to save one version of a module only ever once on a disk.
                                                                                                        0

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

                                                                                                      +1
                                                                                                      К сожалению тенденцию наблюдаем прямо противоположную. Софт становится все более громоздким и все меньше людей способны охватить какую-то любо систему целиком. Вот так и появляются куча зависимостей. Может кому-то и захочется переписать всю библиотеку с нуля сделав ее более легкой, но а как же совместимость с кучей уже написанного софта? Вот так и катимся непонятно куда.
                                                                                                        0
                                                                                                        Может кому-то и захочется переписать всю библиотеку с нуля сделав ее более легкой, но а как же совместимость с кучей уже написанного софта?

                                                                                                        Как будто нельзя переписать, сохранив публичный API.
                                                                                                          0
                                                                                                          И точно такую же логику работы и особенности поведения? Очень вряд ли.
                                                                                                        +1
                                                                                                        проект, весом в пару мегабайт от силы, который грузит для своей работы 300 метров в папку node_modules


                                                                                                        Напоминает выпуск Ералаша про умные часы.
                                                                                                          +3
                                                                                                          Увы, это реалии современной веб-разработки. Вы не представляете как я был разочарован, когда начал плотно этим заниматься.
                                                                                                            0

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

                                                                                                              +2
                                                                                                              Далеко не всегда, к сожалению.
                                                                                                                0

                                                                                                                А подскажете конкретный пример?

                                                                                                                  +1

                                                                                                                  https://www.npmjs.com/package/isarray 19.5kk загрузок в неделю.

                                                                                                                    0

                                                                                                                    Это же не сотни мегабайт.

                                                                                                                      +1

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


                                                                                                                      Решили вы заюзать express, там 30 зависимостей, но в сумме будет загружено свыше 100 пакетов, учитывая зависимости зависимостей. И это без dev зависимостей.
                                                                                                                      Как правило у вас не одна зависимость. Вот так и получается, что количество пакетов растет экспоненциально. Причем абсолютная часть того, что вы загрузите — это просто занятые inode, не более того.


                                                                                                                      Пример с isarray я привел для того, что бы показать то, что пакеты довольно часто очень маленькие, а многие из авторов вместо того, что бы написать у себя функцию на этих же 5 строк предпочитают загрузить пакет. NPM и left-pad: мы разучились программировать?

                                                                                                                        +1
                                                                                                                        теперь представьте, что этот пакет подтягивается как зависимость разных ваших зависимостей несколько раз.

                                                                                                                        … Но вебпак включит его в сборку единственный раз.


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

                                                                                                                        … И если каждый напишет самостоятельно, то эта функция будет в финальной сборке повторяться столько раз, сколько раз её написали.

                                                                                                                          0
                                                                                                                          … Но вебпак включит его в сборку единственный раз.

                                                                                                                          И причем тут webpack? Речь про node_modules.


                                                                                                                          … И если каждый напишет самостоятельно, то эта функция будет в финальной сборке повторяться столько раз, сколько раз её написали.

                                                                                                                          Собсно и чо?)) Да, будут повторяться, причем для каждого случая это будет заточенная функция под конкретный случай. Если для вас N зависомостей предпочтительней, чем N функций — это печально.

                                                                                                                            +1
                                                                                                                            И причем тут webpack? Речь про node_modules.

                                                                                                                            Ок, хорошо, возьмём серверный express: 49 зависимостей, включая целых 2 внутренних зависимости зависимостей (почти все зависимости установились плоско). Общий размер — 1,5 МБ.


                                                                                                                            Собсно и чо?))

                                                                                                                            Собсно потом не кричите, что у вас скрипты в браузере раздуты.

                                                                                                                              0
                                                                                                                              почти все зависимости установились плоско

                                                                                                                              Круть, только это стечение обстоятельств. Общий размер 2.4 мб


                                                                                                                              Собсно потом не кричите, что у вас скрипты в браузере раздуты.

                                                                                                                              Вы сейчас сравниваете мягкое и зеленое. Webpack что научился вычленять только используемую функциональность из подтягиваемых пакетов? Например если требуется пара функций из underscore — тянуть пакет более затратно, чем написать эти несчастные пару функции.

                                                                                                                                0
                                                                                                                                Например если требуется пара функций из underscore — тянуть пакет более затратно, чем написать эти несчастные пару функции.

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

                                                                                                                                  0
                                                                                                                                  Именно для того, чтобы даже самый глупый webpack не затянул в бандл ничего лишнего.

                                                                                                                                  Вам не кажется, что овчинка вычинки не стоит?
                                                                                                                                  Доп. зависимость — это:


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

                                                                                                                                  Если для вас важнее размер того, что напакует webpack — ну что ж, могу вам только удачи пожелать.

                                                                                                                                    +1
                                                                                                                                    Круть, только это стечение обстоятельств. Общий размер 2.4 мб

                                                                                                                                    Это не стечение обстоятельств, а оптимизация. Если ваш установщик пакетов не разворачивает дерево зависимостей — обновите его.


                                                                                                                                    потенациальная уязвимость, особенно учитывая последние фейлы npm

                                                                                                                                    И какой же ущерб нанесли эти уязвимости? В том же go и php вообще зависимости чуть ли не напрямую с гитхаба вытягиваются, или я ошибаюсь?


                                                                                                                                    куча мета данных, описывающих сам пакет, которые просто будут раздувать node_modules

                                                                                                                                    Эта куча метаданных остаётся на компьютере разработчика. И всё равно это удобнее, чем в той же джаве, где maven старается выкачивать все метаданные всех пакетов из репозитория. А ещё тонну пакетов выкачивает gradle при сборке.


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

                                                                                                                                    На фронтенде это очень важно, а в современном вебпаке есть tree shaking, который хоть и не идеально, но старается оставить в бандле только те функции из пакета, которые нужны. Вы же не хотите, чтобы фронтенд разрабатывался на основе огромного блоба-фреймворка, в котором есть вообще всё что нужно и не нужно, но зато в нём одном? Или другая крайность — писать все функции самостоятельно. В современной экосистеме ноды довольно сильно уже доработали пакеты под возможность оптимизации.

                                                                                                                                      0
                                                                                                                                      Это не стечение обстоятельств, а оптимизация.

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


                                                                                                                                      И какой же ущерб нанесли эти уязвимости?


                                                                                                                                      В том же go и php вообще зависимости чуть ли не напрямую с гитхаба вытягиваются

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


                                                                                                                                      Эта куча метаданных остаётся на компьютере разработчика.

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


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

                                                                                                                                      Здравый смысл превыше всего. Писать по пакету на тривиальную функцию — это против здравого смысла. Аргументацию я приводил выше. Ваши доводы базируются на объеме результирующей сборки. Проблема доставки объемной сборки решается иначе: кэширование + ленивая загрузка + версионирование + cdn.


                                                                                                                                      Если честно, я не хочу что бы фронтент на экостистеме js разрабатывался, но это мои влажные фантазии.

                                                                                                                                        0

                                                                                                                                        Итак, что же мы имеем по ущербу:


                                                                                                                                        https://www.opennet.ru/opennews/art.shtml?num=49665

                                                                                                                                        Атака была направлена на конкретный проект. Никого больше атака не затронула.


                                                                                                                                        https://www.opennet.ru/opennews/art.shtml?num=48960

                                                                                                                                        Утекли токены для npmjs.org. Воспользоваться ими хакеры, похоже, так и не успели.


                                                                                                                                        https://www.opennet.ru/opennews/art.shtml?num=48544

                                                                                                                                        Бэкдор так и не был активирован.


                                                                                                                                        https://www.opennet.ru/opennews/art.shtml?num=46768

                                                                                                                                        Подобрали слабые пароли к аккаунтам. Здесь ни NPM, ни JS не виноваты.


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

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


                                                                                                                                        Проблема доставки объемной сборки решается иначе: кэширование + ленивая загрузка + версионирование + cdn.

                                                                                                                                        Для ленивой загрузки нужно разбиение по модулям с учётом зависимостей. Его вебпак тоже успешно и эффективно проводит.


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


                                                                                                                                        CDN сильно снижает скорость доставки контента и создаёт лишнюю точку отказа.

                                                                                                                                          0
                                                                                                                                          Итак, что же мы имеем по ущербу

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


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

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


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

                                                                                                                                          HTTP2 уже ж придумали.


                                                                                                                                          CDN сильно снижает скорость доставки контента и создаёт лишнюю точку отказа.

                                                                                                                                          Видимо не умеете готовить.

                                                                                                                                            +1
                                                                                                                                            Неа, я ж сбросил пример пакета, доп данных в нем, по сравнению с рабочим кодом больше на порядок.

                                                                                                                                            Допустим. У вас в проекте исключительно такие библиотеки используются?


                                                                                                                                            HTTP2 уже ж придумали.

                                                                                                                                            А пушить зависимости бэкенд будет?

                                                                                                                                              –2
                                                                                                                                              У вас в проекте исключительно такие библиотеки используются?

                                                                                                                                              Нет конечно же, это хреновая практика.


                                                                                                                                              А пушить зависимости бэкенд будет?

                                                                                                                                              Nginx / CDN

                                                                                                                                                0

                                                                                                                                                Ну вот и замечательно. Не так уж и много накладных расходов. Если же хотите совсем от них избавиться — собирайте серверный бандл на CI. Тогда метаданные останутся исключительно у разработчиков и на CI-сервере.


                                                                                                                                                Что касается пуша с сервера — у вас, видимо, очень маленький фронтенд, который не сильно дробится на множество файлов исходников.

                                                                                                                                              0
                                                                                                                                              HTTP2 уже ж придумали

                                                                                                                                              Видимо не умеете готовить.

                                                                                                                                              Противоречие. Самый лучший способ использовтаь HTTP2 — отказаться от CDN в пользу своего единого адреса.
                                                                                                                      0
                                                                                                                      Извините, я по специфике деятельности работаю с закрытыми репозиториями.

                                                                                                                      Насколько я понимаю устройство ноды, фактически под требование подходит любой проект, который по тем или иным причинам не использует run build. Хз как такое нагуглить. Мне лично вообще этот подход претит, плюс я не большой знаток ноды.

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

                                                                                                                        Так это фронтендный проект или серверный?

                                                                                                                          0
                                                                                                                          Это не один проект. Я же говорю, подобное видел у нескольких разных разработчиков.

                                                                                                                          И в данном случае сложно разделить на фронт\бэк. В описываемой концепции за роутинг отвечает нода, она же генерит для клиента весь код «фронта» и выплёвывает его браузеру единым куском. Я затрудняюсь сказать, где тут фронт заканчивается, где бэк начинается.
                                                                                                                            0

                                                                                                                            Обычный SPA. Как правило они тоже прекомпилируются. Впрочем даже без этого они действительно могут достаточно большими, потому что содержат серверные библиотеки. Здесь же вы выдаёте это в таком свете, будто эти сотни мегабайт загружаются прямо пользователю. Толпа радостно подхватывает, ведь JS модно ненавидеть :)

                                                                                                                              0
                                                                                                                              Нет же, вовсе даже не SPA, а очень даже объёмные системы.

                                                                                                                              К примеру, в проекте с которым я сейчас работаю, для MVP проекта UX-дизайнерами отрисовано больше двух сотен экранов.

                                                                                                                              В том-то и абсудр, что подобное делается по концепции SPA.

                                                                                                                              И да, пользователю нода, конечно, не грузится. Но некоторые модули вполне могут — тут всё зависит от проекта и фич, которые захотел использовать разработчик.
                                                                                                                                +1
                                                                                                                                Нет же, вовсе даже не SPA, а очень даже объёмные системы.

                                                                                                                                И в чём тогда паника, что node_modules для такого проекта весят 300 мегабайт, большая часть из которых, скорее всего, — webpack, babel и т.п.?


                                                                                                                                Но некоторые модули вполне могут

                                                                                                                                Вот и нужно по конечному бандлу смотреть.

                                                                                                                                  0
                                                                                                                                  Нет паники. Это скорее отвращение к профессиональной импотенции авторов подобных проектов.

                                                                                                                                  Webpack, babel… Ок, к ним вопросов нет, допустим.

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

                                                                                                                                  Как вам, например, две версии Bootstrap, потому что одну из них требует один из используемых компонентов (datepicker), а зависимость указана строго, а вторая используется в проекте для сетки. Я молчу уж про то, что меня от самого бутстрапа воротит (там полная шизофрения в стилях), но неужели сетку-то нельзя было руками прописать?

                                                                                                                                  Ну и в таком духе.

                                                                                                                                  Тут диллема такая, что если ты используешь подобную концепцию в разработке — то ты либо обрекаешь себя на кучу дополнительной работы по вычищению кода (которую большинство, очевидно не делает), либо генерируешь тонны мусора, помимо полезного контента.
                                                                                                              0
                                                                                                              Ну знаете ли, с нодой ещё не всё так плохо, там можно устанавливать пакеты глобально, и они будут работать во всех проектах. А вот в питоне это в принципе проблема не стоит и модули могут быть ТОЛЬКО глобальными. И там костыли ещё веселее — создаётся свой собственный питон для проекта и в него закидываются свои собственные интерпретатор, куча библиотек и другие увеселительные файлы, ведь один проект должен работать со старой джангой, а другой с новой. И только потом на всё это намазываются уже зависимости самого проекта…

                                                                                                              А так то такие «проблемы» у каждого нормального пакетного менеджера. Он должен хранить модули только для одного проекта, ведь в другом будут и версии библиотек другие и вообще всё другое.
                                                                                                                0
                                                                                                                Нет, что вы. Я не конкретно в ноду ткнуть хотел, а в принципе указать на слабое место концепции.

                                                                                                                Так-то, сама нода мне в качестве домашнего сервера даже больше нравится чем апач, например.
                                                                                                                  0

                                                                                                                  Пока что вы не очень понятно объяснили, в чём именно слабое место.

                                                                                                              –5
                                                                                                              А ещё мы больше не контролируем свои компьютеры. Хуже того, мы даже не всегда контролируем освещение в своём дома. Паника!
                                                                                                                +2

                                                                                                                У меня тут на днях духовка начала апдейт ставить когда я хотел утку запечь, а вы говорите "освещение" (в ней OpenBSD внезапно — в духовке).

                                                                                                                +3
                                                                                                                Согласен на 100%,
                                                                                                                Но кстати, node_modules просто так никогда не создается, кто-то (вероятно вы?) при установке модуля забыл перейти в каталог программы, либо думал что делает глобальную установку и забыл флаг -g
                                                                                                                  +12
                                                                                                                  «Реестр Windows — дерьмо», — говорили они. :)
                                                                                                                    +1
                                                                                                                    Даже такой бардак все еще лучше реестра. По крайней мере это файлы.
                                                                                                                      +1
                                                                                                                      И чем это лучше?
                                                                                                                        0
                                                                                                                        По файлам можно грепать, файлы можно инкрементно бэкапить, редактировать любимым редактором, хранить в репах и легко и непринужденно жонглировать ими скриптами.
                                                                                                                          +2

                                                                                                                          берёте reg.exe и делаете почти тоже самое, что и через grep

                                                                                                                            0
                                                                                                                            И инкрементный бекап?
                                                                                                                              +2

                                                                                                                              после выгрузки в .reg файлы вы можете с ними делать всё то же самое, что и с .cfg и прочими "текстовыми" конфигами, вплоть до инкрементального бекапа

                                                                                                                                0

                                                                                                                                Fix (убрал курсив):


                                                                                                                                после выгрузки в *.reg файлы вы можете с ними делать всё то же самое, что и с .cfg и прочими "текстовыми" конфигами, вплоть до инкрементального бекапа

                                                                                                                                  +1
                                                                                                                                  Вроде не получится — если удалили ветвь, то в бэкапе её просто не будет, и если на старый реестр накатывать новый, то удалённая ветвь просто останется. Для этого её нужно будет явно удалить.
                                                                                                                              +1
                                                                                                                              Ага, и комменты писать в реестре не принято. В отличие от.
                                                                                                                              Хотя единственный существенный недостаток — реестр в VSC вроде как не помещается. А так… скрипты из малвари давным-давно научились легко и непринужденно править реестр.
                                                                                                                        –7
                                                                                                                        нет рабочего стола или какого-то десктопа.

                                                                                                                        Зачем в таком случае ставить Steam?

                                                                                                                        Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock

                                                                                                                        Такое ощущение, что автор статьи просто запускает команды, которые он не понимает, потом удивляется.

                                                                                                                        У меня в каталоге тысяч сто файлов в разного рода директориях, начинающихся с точки. Их можно контролировать, как хочет автор, но зачем?
                                                                                                                        «Делайте что-то одно, но делайте это хорошо». Кто же виноват, что с каждым днем задачи усложняются, количество информации увеличивается, количество софта и утилит тоже, все в соответствии с принципами.
                                                                                                                        Это не отменяет рукожопость многих разработчиков, но в целом все выглядит куда лучше, чем сто тысяч хрен пойми каких dll в другой операционной системе.
                                                                                                                          +5
                                                                                                                          тайловый графический менеджер без десктопа (десктоп, или в переводе рабочий стол — это такая штука с ярлыками и всё). Даже KDE позволяет сделать кучу виджетов, панель задач, а виджет рабочего стола — удалить.
                                                                                                                          Или просто запускать стим в своём x-server без графического менеджера, который окошки таскать мышкой позволяет.
                                                                                                                            +2
                                                                                                                            Да с чего вдруг это «штука с ярлыками»? Это основное окно графической среды пользователя вместе с элементами, добавляемыми в него этой средой. Это прям в википедии написано.
                                                                                                                            Есть графическая среда, есть и десктоп. Ярлыки можно там не создавать, десктопом он разве перестанет быть?
                                                                                                                              +3
                                                                                                                              В $HOME/Desktop как раз «ярлыки» и хранятся. Для тех оболочек, которые умеют их показывать.

                                                                                                                              Если пользоваться вашим определением, то десктоп у меня конечно есть. Правда, я его никогда не вижу, ибо тайловый менеджер всегда закрывает его окнами. Но «ярлыки» он отображать не умеет в принципе.
                                                                                                                                +1
                                                                                                                                Десктоп — это специальное окно развернутое на весь экран, даже в винде можно убить проводник, но при этом открывать новые окна и управлять ими не имея рабочего стола, т.к. за это отвечает оконный менеджер. В linux же, люди которые с ним на ты, часто
                                                                                                                                  +3
                                                                                                                                  В винде есть два значения у термина «рабочий стол». Первое — окно на заднем фоне, создаваемое Проводником. Второе — область в которой создаются окна, и именно в этом значении термин используется в winapi.
                                                                                                                                    0
                                                                                                                                    В linux же, люди которые с ним на ты, часто пользуются только оконным менеджером