Мы больше не контролируем свои домашние каталоги.В моём собственном 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 и подобных системах эта библиотека наверняка будет использовать Спецификацию на расположение базовых каталогов.
Комментарии (324)
alex_fort
17.02.2019 23:56+7Эта статья должна занять первое место в зале бессмысленности гугл-транслейта.
achekalin
18.02.2019 16:50+1Я-то уж думал, что кто-то связный вопль написал по-русски, а не просто перевел… Потом смотрю — ан, нет, это я просто значка «перевод» не заметил.
Такое впечатления, что западные авторы (не в значении «авторы учебников», а в значении «кому не лень написать рефлексию») чаще задают себе вопрос "а почему оно так?" Русскоязычная публика (ок, ex-USSR-users), как кажется, более привычна к «сказано делать так — так и будем».
P.S. Следствие, кстати — это когда мудрый админ насаждает среди юзеров «так делать правильно», но почему правильно — сказать не может. Привык он, понимаешь! Потом получаются почтовые ящики вида ivanov_ve@mx.company.ru, и веб-сайты, которые отзываются только на www.company.ru (т.е. без www не откроешь).
bano-notit
18.02.2019 22:16+1А можно спросить, что за mx? Это тоже была какая-то мода на разделение сервисов по доменам?
gecube
18.02.2019 22:26Ну, типа запись доменная MX — должна указывать на Mail eXchange.
Оно же и субдомен для типового MX-сервера.
achekalin
19.02.2019 11:08Есть такой (довольно логичный) подход:
— у вас есть ваша организация, и все, что в ней, вы считаете «своим», «вашим доменом». Под это дело выделяем домен, скажем, 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, зато надежно же!
qark
18.02.2019 00:07+4Больше десяти лет назад что-то подобное уже было. GNOME целую кампанию провёл для наведения порядка. Вот только остальные не всегда следуют стандарту.
batyrmastyr
18.02.2019 13:38Видимо нужно в свежей версии ОС запретить писать.хрень в домашний каталог, за исключением путей из XDG, глядишь тогда прочитают документацию.
Kozel-007
18.02.2019 15:10+1Если б можно было определить на уровне ОС, где конфиги, а где файлы пользователя.
johnfound
18.02.2019 03:52Меня вообще, работать в /home/username/ в принципе не устраивает. И так как на мои компьютеры работаю только я, то делаю так — выделяю два раздела по 50ГБ под ОС (так могу экспериментировать с разными дистрибутивами), а все остальное пространство диска выделяю под раздел который монтирую как /work
И так как Linux вообще не знает о нем, то и никогда туда ничего не пишет. Дополнительный плюс это то, что файлы доступные одновременно в двух ОС (дот файлы не позволяют монтировать этот раздел как /home/username). Ну, и мигрировать на новый компьютер/диск легче.
9660
18.02.2019 07:28+1Меня вообще, работать в /home/username/ в принципе не устраивает.
А что за работа такая «в /home/username/» и что именно не устраивает?johnfound
18.02.2019 09:01Мой русский не так чтобы очень, так что может и глупость сморозил. :)
Я имею ввиду место, в которое сохраняю все мои файлы – над которыми работаю или просто смотрю. Ну там, проекты всякие, картинки, фильмы, музыка и т.д.
9660
18.02.2019 09:11Так понятнее. Хоум и правда не лучшее место для медиа. Думаю у большинства, как у вас, для этого отдельный диск или сервер.
DrZlodberg
18.02.2019 08:52+1Ну, и мигрировать на новый компьютер/диск легче.
Легче, чем что? У меня home отдельным разделом монтируется. Если решил поменять систему — форматнул / и накатил новую, Подцепил home и, как будто, ничего и не происходило. Все настройки на месте. Правда проблему срача в home это не решает :(johnfound
18.02.2019 09:07И весь мусор тоже там будет. И заметьте в новой ОС, программы эти может и не быть, а то что они оставили в /home/ останется и отделить нужное от ненужного, невозможно в принципе. Бардак с времени будет только увеличиваться, но никак не уменьшатся. Именно поэтому я так не делаю.
DrZlodberg
18.02.2019 09:18На самом деле отделить до определённой степени можно (по крайней мере у меня по названию чаще всего можно определить хозяина, хотя судя по статье — так бывает не всегда). Ну можно просто грохнуть все файлы с непонятным владельцем, или вообще все дот-файлы.
Просто тут только 2 варианта, либо разбирать/чистить, либо терять все настройки. Но второе по мне — не всегда удобно. Например профили браузера терять неприятно.johnfound
18.02.2019 09:29Конечно всегда можно почистить вручную, но в моей /home 75000 файлов, которые не я там записал, а система/программы. А в /work около миллиона файлов, которые записал там я и которые более или менее мне нужны. Понимаете, что сортировать все это вручную просто нереально.
DrZlodberg
18.02.2019 09:4175к? О_О У меня штук 20 всего. Это сколько же программ нужно, чтобы столько накидать?
Да, в вашем случае явно требуются особые меры. Кстати 1М файлов система вообще нормально держит? Тем же даже открытие файлов уже подлагивать может. Или используется какая-нибудь серверная фс?johnfound
18.02.2019 10:3520? Этого не может быть. Все конфиги и кеши браузера будут намного больше. Попробуйте так:
find ~ -type f | wc -lDrZlodberg
18.02.2019 10:49Все конфиги и кэши у фоксы живут в одном каталоге. Я учитываю срач только в юзере, что там в подкаталогах уже пофиг. Во первых глаза не мозолит и искать нужное не мешает (к чему у меня основная претензия), а во вторых прибивается в один клик.
Но если считать все файлы вообще, то да, там один профиль фоксы потянет… хз, но прилично потянет. Ради интереса вечером гляну.
DoctorMoriarty
18.02.2019 12:58Если я всё правильно понимаю, с позиции моего скромного опыта линуксоюзера, то home в Linux по факту выполняет примерно те же функции, что Documents и AppData в Windows. Под Windows здравомыслящий пользователь не станет хранить в Documents рабочие проекты и личные файлы, соответственно — и в Linux разумно поступать так же, оставляя за home только его служебные функции раздела, хранящего пользовательские настройки софта.
MechanicZelenyy
18.02.2019 13:36Нет, не правильно понимаете.
Если кратко, то home это место где юзеру соблаговолили доступ на запись и место, где он повседневно должен работать (если пользователь так же является администратором, то он тоже должен сидеть в хомяке, используя root, только для администрирования.)DoctorMoriarty
18.02.2019 14:56>доступ на запись и место, где он повседневно должен работать
Ну, с включенным UAC в Windows 10 примерно то же с попытками что-то записать в системные папки, и Документы вроде бы как предполагаются местом работы… Аналогия с Linux, конечно, грубая и поверхностная, но имхо не совсем уж ложная.
Kozel-007
18.02.2019 15:15+1В реально многопользовательском Linux папка home — единственное место, где пользователь может хранить файлы. И если раньше мусор был хотя бы скрытым, то папка snap — это уже совсем зашквар. Когда делать нефиг, удаляю её и пишу разрабам багрепорт, что всё сломалось. С логами, но без указания причины.
0xd34df00d
18.02.2019 18:29+1А чего не пуллреквест с фиксом?
Сорян, но тратить jff-ресурсы на развлечение таких козелов — зашквар куда больший, чем папка snap.Kozel-007
18.02.2019 18:54+1А вы переписку разрабов про эту папку почитайте — там больше санта-барбары чем в Санта-Барбаре. А пулл-реквеста с исправлением теперь никогда не будет — путь к папке захардкожен в куче разных мест, и во всех местах его надо изменить одновременно, иначе сломается. А это значит, надо одновременно принять изменения в разные подпроекты, разными людьми. А они до сих пор собачатся по этому вопросу в стиле «так не доставайся же ты никому!».
0xd34df00d
18.02.2019 19:32А где переписка-то?
Если путь захардкожен в куче разных мест, то сначала надо отрефакторить эти места и вынести это всё в отдельную функцию/модуль/что у вас там, которая бы использовалась в остальных местах (и это можно делать без необходимости синхронизации разных подпроектов). А там уже и менять можно.
maxzhurkin
18.02.2019 20:06В /tmp и /var/tmp любой пользователь de facto может создавать любые файлы и каталоги (они автоматически создаются принадлежащими ему самому и доступными только ему на запись) если они уже не созданы
sumanai
18.02.2019 20:09Не уверен, что темпы являются адекватным местом для хранения чего бы то ни было долговременного. А то может они у меня в рамдиск смонтированы (на винде у меня так и есть).
maxzhurkin
18.02.2019 20:13А где я говорил, что это адекватные места? Это был не более чем контрпример для утверждения
В реально многопользовательском Linux папка home — единственное место, где пользователь может хранить файлы.
А ещё эти два пути имеют одно принципиально различие, из-за которого первый (/tmp) адекватно рамить, а второй (/var/tmp) — нет
saboteur_kiev
19.02.2019 01:56Не совсем так.
Созданные файлы и каталоги в /tmp может удалить только владелец благодаря флагу sticky bit на /tmp
но вот внутри подкаталогов — зависит от umask
staticlab
18.02.2019 15:44+1home— это аналог директорииUsers. РольDocumentsвыполняет/home/<user>/Documents, а рольAppDataдолжна выполнять/home/<user>/.config, однако многие приложения пренебрегают этим, что и является причиной написания данной статьи.
Под Windows здравомыслящий пользователь не станет хранить в Documents рабочие проекты и личные файлы
Потому что она в 99% случаев лежит на том же разделе, что и система, и при переустановке всё может уничтожиться?
DoctorMoriarty
18.02.2019 16:17>многие приложения пренебрегают этим
Сталкивался со реальным спамом файлами .serverauth.##### в home.
>Потому что она в 99% случаев лежит на том же разделе
Ну да. Одно дело — личные компьютеры, но мне попадалось удивительно мало систем во всяческих конторах и даже компаниях, которые бы выбивались из этих 99%…staticlab
18.02.2019 16:19+1Потому что в винде перенастроить Users на другой раздел не тривиально и чревато багами. Линукс при установке предложит сделать отдельный раздел для home, что в сообществе разумно считается best practice.
Arty_Fact
18.02.2019 18:59Странно, конечно. Я первым делом после переустановки системы все пользовательские папки (документы, музыку, фильмы и т. п.) переношу на D:. Этими папками очень удобно пользоваться в винде — хорошо интегрированы в интерфейс.
mayorovp
18.02.2019 17:14Потому что она в 99% случаев лежит на том же разделе, что и система, и при переустановке всё может уничтожиться?
Потому что до висты она называлась "C:\Documents and Settings\<user>\Мои документы", и из-за русских буков в названии половина программ отказывалась с ней работать. Это если не вспоминать о пробелах в названии, с которыми не может работать каждый первый батник...
sumanai
18.02.2019 18:53+1В итоге вместо фикса программ наворотили непроходимую чащу точек соединения и симлинков на системном диске. И я даже не уверен, не является ли получившийся граф ациклическим.
qw1
18.02.2019 20:27+1является ли получившийся граф ациклическим.
Нет, потому что
C:\Users\Name\AppData\Local\Application Data > C:\Users\Name\AppData\Local
Но спасает, что длина пути не более MAX_PATH=260 знаков (если не использовать префикс \\?\), поэтому рекурсивный поиск не зацикливается, а останавливается на некоторой глубине.
mikechips
18.02.2019 18:36Каталог "Мои документы" изначально предназначался для документов, ровно так же, как Рисунки для картинок, Музыка (внезапно) для музыки и так дальше. Просто некоторые интеллектуалы решили, что Documents = AppData, и началось...
Всегда бесился с игр на Unreal Engine, которые добавляли конфиги в Documents/My Games, будь они здоровы. Пришлось смириться, что первобытный смысл дефолтных каталогов умер, кто что хочет то и воротит
qw1
18.02.2019 20:31В старых версиях Windows не было папок под пользовательскую музыку и рисунки, была только папка «Документы». Поэтому что должны были использовать по умолчанию авторы аудио/фото-редакторов?
sumanai
18.02.2019 21:20Насколько старых? В XP всё было, а это, на минуточку, 18 лет назад, эпохи прошли с тех времён.
qw1
18.02.2019 21:30+1Как минимум, в WinXP не было Saved Games (т.е. сохраняшки некуда класть, кроме документов), а папки My Music, My Pictures, My Videos находились внутри Documents. Поэтому авторы, которые
добавляли конфиги в Documents/My Games
просто следовали системным соглашениям.
saboteur_kiev
18.02.2019 14:43А почему /work, а не /opt, не /usr/local, не /var?
johnfound
18.02.2019 16:02Именно потому что директория нестандартная. Так как Linux ничего не знает про нее, есть гарантия что никакая программа не будет просто так писать туда, потому что так захотелось программистам. И вообще, все современные ОС считают что файловая система принадлежит им и пользователь должен сидеть в углу и не рыпаться. Всякие программы тоже так думают и работают.
А мне нравится наоборот — пусть ОС сидит там где ее поставили, а все остальное мне. :D
saboteur_kiev
18.02.2019 17:12/home/user/mywork — туда никто не полезет. Это вообще может быть ссылка на другой раздел.
qw1
18.02.2019 20:33-2Грубо говоря, какой-нибудь шифровальщик может испортить весь /home, а утилита кражи данных стащить все doc-файлы из home. С корня же никто не ищет, т.к. можно нарваться на всякие /dev /proc
saboteur_kiev
19.02.2019 19:35+1Известные мне шифровальщики ищут везде по расширению, а не по /home.
И кстати именно с корня. И уже про /dev /proc авторы догадываются.
emerald_isle
18.02.2019 15:39Вы же можете как угодно переопределить этот каталог при создании пользователя. Или даже поменять. Можете сделать просто /username или сразу /work сделать своим домашним каталогом. Не говоря уже о символьных ссылках…
johnfound
18.02.2019 16:04Только, если так, то Линукс будет знать что это моя "домашняя директория" и здравствуйте дот файлы, кеши, теща и вся родня. :P
emerald_isle
18.02.2019 20:07Да, от этого не спасает, именно об этом и статья. От «произвола программистов» не спасут никакие соглашения, если их не соблюдать…
kalashnikovisme
18.02.2019 17:08Спасибо за пример решения! Очень интересное.
По такому же принципу использую отдельный диск, который доступен и на винде тоже.
Занимаюсь монтажом видео в свободное время и, когда есть вдохновение, так что, нужна винда :)
Директория $HOME используется, как мусорка по причине, описанной в статье.
boblenin
19.02.2019 22:10lifehack. Если каталог называть не «work», а «do» то печатать меньше, а смысл все-равно остается :) Каждый раз когда нужно сделать cd, каждый конфиг, каждый абсолютный путь. Для миграции можно использовать симлинк.
qw1
19.02.2019 23:24+2Почему do? Если имя каталога сделать из одной буквы или цифры, печатать ещё меньше.
johnfound
20.02.2019 15:48Нет, "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, /"
boblenin
20.02.2019 16:44При печатании do TAB не экономит нажатия (так и так одна клавиша). Но собственно мое дело предложить — ваше отказаться, я не настаиваю.
wolandtel
18.02.2019 06:18Вот интересно, а откуда я должен был узнать от этом стандарте, если ты не эта статья?
knstqq
18.02.2019 09:03+1Это черта хорошего разработчика: посмотреть на готовые решения, стандарты, рекомендации, требования и best-practices — прежде чем велосипед свой велосипедить.
berez
18.02.2019 09:52Готовые решения — это как раз процентов на 90 программы, пишущие свои конфиги в $HOME/.*.
Кстати, ради прикола посмотрел сейчас в QSettings — уж казалось бы, вот они, best practices в полный рост. А присмотришься — они тоже по умолчанию пишут в $HOME/.config/что-то-там, даже если задана переменная XDG_CONFIG_DIRS. Вот если переменная задана, и нужные подкаталоги и файлики уже присутствуют — тогда QSettings будет использовать их. А без этого — нагадит в $HOME.
Рекомендации — о-о-о, их есть много всяких разных, включая запись конфигов в xml или вообще в аналог реестра в бинарном формате. Не факт, что попадется правильная.
mwambanatanga
18.02.2019 11:19Вот интересно, а откуда я должен был узнать от этом стандарте, если бы не эта статья?
Та же мысль пришла в голову. Множество программ создают свои файлы и директории прямо в $HOME, а тех, которые поступают по стандарту, сразу и не заметишь. Вот и получается…
NetBUG
18.02.2019 12:19+1Ещё интереснее. Я человек любопытный, ОС у меня 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
Отлично. Но путей для настройкопомойки тоже нет, я бы даже не подумал разбираться с нимиlorc
18.02.2019 16:00% 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/.
Поэтому все эти переменные с путями и не определены обычно.
farcaller
18.02.2019 17:11NETBUG-MBP
Так у вас наверно ~/Library/Application\ Support для этого есть? :-)
Psychosynthesis
18.02.2019 07:18Как по мне, так многие проекты, в частности на NodeJS, даже учитывая что они гадят исключительно в своём же каталоге, являют собой натуральный бардак. Я всё понимаю, на счёт зависимостей, но проект, весом в пару мегабайт от силы, который грузит для своей работы 300 метров в папку node_modules (и я нисколько не преувеличиваю, если проект крупный то даже больше) выглядит как явный признак шизофрении его создателя.
Надеюсь, когда-нибудь кто-нибудь из тех, кто бездумно кидается использовать любую новую фичу, будет для начала думать о том, как внедрить её красиво и чего это будет стоить.vpiskunov
18.02.2019 07:57Эта проблема, увы, не только разработчика, в NodeJS вот так. 300MB — это еще хорошо. В кровавом энтерпрайзе и 1.5GB+ видели...
NetBUG
18.02.2019 12:20Года с 2016 ходят слухи, что запилят центральное хранилище модулей для пользователя с симлинками из нужных мест и счётчиком ссылок, чтобы удалять модули, для которых установлены обновления.
staticlab
18.02.2019 16:02Оно? https://pnpm.js.org/
pnpm uses hard links and symlinks to save one version of a module only ever once on a disk.
Mingun
18.02.2019 17:45Так современный
npmуже так и делает. На счет удаления не знаю, но модули хранит в одном месте, а дальше симлинками
vxdv
18.02.2019 08:11К сожалению тенденцию наблюдаем прямо противоположную. Софт становится все более громоздким и все меньше людей способны охватить какую-то любо систему целиком. Вот так и появляются куча зависимостей. Может кому-то и захочется переписать всю библиотеку с нуля сделав ее более легкой, но а как же совместимость с кучей уже написанного софта? Вот так и катимся непонятно куда.
sumanai
18.02.2019 18:56Может кому-то и захочется переписать всю библиотеку с нуля сделав ее более легкой, но а как же совместимость с кучей уже написанного софта?
Как будто нельзя переписать, сохранив публичный API.
Rive
18.02.2019 09:22проект, весом в пару мегабайт от силы, который грузит для своей работы 300 метров в папку node_modules
Напоминает выпуск Ералаша про умные часы.Psychosynthesis
18.02.2019 12:51Увы, это реалии современной веб-разработки. Вы не представляете как я был разочарован, когда начал плотно этим заниматься.
staticlab
18.02.2019 16:01Но это же в основном средства разработки, которые пользователю не попадут.
Psychosynthesis
18.02.2019 18:14+1Далеко не всегда, к сожалению.
staticlab
18.02.2019 22:04А подскажете конкретный пример?
index0h
18.02.2019 22:29https://www.npmjs.com/package/isarray 19.5kk загрузок в неделю.
staticlab
18.02.2019 22:40Это же не сотни мегабайт.
index0h
19.02.2019 04:10А тут дело не в качестве, а в количестве, теперь представьте, что этот пакет подтягивается как зависимость разных ваших зависимостей несколько раз.
Решили вы заюзать express, там 30 зависимостей, но в сумме будет загружено свыше 100 пакетов, учитывая зависимости зависимостей. И это без dev зависимостей.
Как правило у вас не одна зависимость. Вот так и получается, что количество пакетов растет экспоненциально. Причем абсолютная часть того, что вы загрузите — это просто занятые inode, не более того.
Пример с isarray я привел для того, что бы показать то, что пакеты довольно часто очень маленькие, а многие из авторов вместо того, что бы написать у себя функцию на этих же 5 строк предпочитают загрузить пакет. NPM и left-pad: мы разучились программировать?
staticlab
19.02.2019 07:57+1теперь представьте, что этот пакет подтягивается как зависимость разных ваших зависимостей несколько раз.
… Но вебпак включит его в сборку единственный раз.
а многие из авторов вместо того, что бы написать у себя функцию на этих же 5 строк предпочитают загрузить пакет
… И если каждый напишет самостоятельно, то эта функция будет в финальной сборке повторяться столько раз, сколько раз её написали.
index0h
19.02.2019 09:39… Но вебпак включит его в сборку единственный раз.
И причем тут webpack? Речь про node_modules.
… И если каждый напишет самостоятельно, то эта функция будет в финальной сборке повторяться столько раз, сколько раз её написали.
Собсно и чо?)) Да, будут повторяться, причем для каждого случая это будет заточенная функция под конкретный случай. Если для вас N зависомостей предпочтительней, чем N функций — это печально.
staticlab
19.02.2019 09:57+1И причем тут webpack? Речь про node_modules.
Ок, хорошо, возьмём серверный express: 49 зависимостей, включая целых 2 внутренних зависимости зависимостей (почти все зависимости установились плоско). Общий размер — 1,5 МБ.
Собсно и чо?))
Собсно потом не кричите, что у вас скрипты в браузере раздуты.
index0h
19.02.2019 10:49почти все зависимости установились плоско
Круть, только это стечение обстоятельств. Общий размер 2.4 мб
Собсно потом не кричите, что у вас скрипты в браузере раздуты.
Вы сейчас сравниваете мягкое и зеленое. Webpack что научился вычленять только используемую функциональность из подтягиваемых пакетов? Например если требуется пара функций из underscore — тянуть пакет более затратно, чем написать эти несчастные пару функции.
mayorovp
19.02.2019 10:56Например если требуется пара функций из underscore — тянуть пакет более затратно, чем написать эти несчастные пару функции.
… и именно по этой причине существует куча пакетов, состоящих из одной-единственной функции. Именно для того, чтобы даже самый глупый webpack не затянул в бандл ничего лишнего.
index0h
19.02.2019 11:11Именно для того, чтобы даже самый глупый webpack не затянул в бандл ничего лишнего.
Вам не кажется, что овчинка вычинки не стоит?
Доп. зависимость — это:
- потенациальная уязвимость, особенно учитывая последние фейлы npm
- куча мета данных, описывающих сам пакет, которые просто будут раздувать node_modules
- код другого вендора, который может в принципе забить на ошибки, или наплевать на обратную совместимость, или еще чего.
Если для вас важнее размер того, что напакует webpack — ну что ж, могу вам только удачи пожелать.
staticlab
19.02.2019 11:26+1Круть, только это стечение обстоятельств. Общий размер 2.4 мб
Это не стечение обстоятельств, а оптимизация. Если ваш установщик пакетов не разворачивает дерево зависимостей — обновите его.
потенациальная уязвимость, особенно учитывая последние фейлы npm
И какой же ущерб нанесли эти уязвимости? В том же go и php вообще зависимости чуть ли не напрямую с гитхаба вытягиваются, или я ошибаюсь?
куча мета данных, описывающих сам пакет, которые просто будут раздувать node_modules
Эта куча метаданных остаётся на компьютере разработчика. И всё равно это удобнее, чем в той же джаве, где maven старается выкачивать все метаданные всех пакетов из репозитория. А ещё тонну пакетов выкачивает gradle при сборке.
Если для вас важнее размер того, что напакует webpack
На фронтенде это очень важно, а в современном вебпаке есть tree shaking, который хоть и не идеально, но старается оставить в бандле только те функции из пакета, которые нужны. Вы же не хотите, чтобы фронтенд разрабатывался на основе огромного блоба-фреймворка, в котором есть вообще всё что нужно и не нужно, но зато в нём одном? Или другая крайность — писать все функции самостоятельно. В современной экосистеме ноды довольно сильно уже доработали пакеты под возможность оптимизации.
index0h
19.02.2019 12:07Это не стечение обстоятельств, а оптимизация.
Если одна из зависимостей требует одну версию, а другая — другую — то у вас загрузится таки 2 версии пакета. То, что в данном случае одна версия пакета подходит для нескольких зависимостей — это только стечение обстоятельств.
И какой же ущерб нанесли эти уязвимости?
- https://www.opennet.ru/opennews/art.shtml?num=49665
- https://www.opennet.ru/opennews/art.shtml?num=48960
- https://www.opennet.ru/opennews/art.shtml?num=48544
- https://www.opennet.ru/opennews/art.shtml?num=46768
В том же go и php вообще зависимости чуть ли не напрямую с гитхаба вытягиваются
Ага, при этом код с гитхаба соотвествует тому, что будет загружено. NPM пакет — это полностью отдельная штука, которая не зависит от кода в репозитории.
Эта куча метаданных остаётся на компьютере разработчика.
Эта куча метаданных остается на каждом окружении в котором запускается проект, а не только у разработчика.
Вы же не хотите, чтобы фронтенд разрабатывался на основе огромного блоба-фреймворка, в котором есть вообще всё что нужно и не нужно, но зато в нём одном? Или другая крайность — писать все функции самостоятельно.
Здравый смысл превыше всего. Писать по пакету на тривиальную функцию — это против здравого смысла. Аргументацию я приводил выше. Ваши доводы базируются на объеме результирующей сборки. Проблема доставки объемной сборки решается иначе: кэширование + ленивая загрузка + версионирование + cdn.
Если честно, я не хочу что бы фронтент на экостистеме js разрабатывался, но это мои влажные фантазии.
staticlab
19.02.2019 12:25Итак, что же мы имеем по ущербу:
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 сильно снижает скорость доставки контента и создаёт лишнюю точку отказа.
index0h
19.02.2019 14:05Итак, что же мы имеем по ущербу
Имеем то, что чем больше у вас зависимостей других вендоров — тем более вероятны проблемы с безопасностью / работоспособностью.
В любом случае, метаданные весят незначительно относительно кода библиотек.
Неа, я ж сбросил пример пакета, доп данных в нем, по сравнению с рабочим кодом больше на порядок. У меня складывалось впечатление, что вы как раз такое и отстаиваете.
Если размещать каждую из зависимостей отдельно, то упадёт скорость загрузки.
HTTP2 уже ж придумали.
CDN сильно снижает скорость доставки контента и создаёт лишнюю точку отказа.
Видимо не умеете готовить.
staticlab
19.02.2019 14:19+1Неа, я ж сбросил пример пакета, доп данных в нем, по сравнению с рабочим кодом больше на порядок.
Допустим. У вас в проекте исключительно такие библиотеки используются?
HTTP2 уже ж придумали.
А пушить зависимости бэкенд будет?
index0h
19.02.2019 14:41-1У вас в проекте исключительно такие библиотеки используются?
Нет конечно же, это хреновая практика.
А пушить зависимости бэкенд будет?
Nginx / CDN
staticlab
19.02.2019 15:02Ну вот и замечательно. Не так уж и много накладных расходов. Если же хотите совсем от них избавиться — собирайте серверный бандл на CI. Тогда метаданные останутся исключительно у разработчиков и на CI-сервере.
Что касается пуша с сервера — у вас, видимо, очень маленький фронтенд, который не сильно дробится на множество файлов исходников.
sumanai
19.02.2019 22:01HTTP2 уже ж придумали
Видимо не умеете готовить.
Противоречие. Самый лучший способ использовтаь HTTP2 — отказаться от CDN в пользу своего единого адреса.
Psychosynthesis
18.02.2019 22:42Извините, я по специфике деятельности работаю с закрытыми репозиториями.
Насколько я понимаю устройство ноды, фактически под требование подходит любой проект, который по тем или иным причинам не использует run build. Хз как такое нагуглить. Мне лично вообще этот подход претит, плюс я не большой знаток ноды.
Просто констатирую общую тенденцию. Честно говоря, я до последнего времени даже не думал, что это общепринятая практика, считал, что так конкретным разработчикам было проще проект настраивать.staticlab
18.02.2019 22:48Так это фронтендный проект или серверный?
Psychosynthesis
19.02.2019 01:39Это не один проект. Я же говорю, подобное видел у нескольких разных разработчиков.
И в данном случае сложно разделить на фронт\бэк. В описываемой концепции за роутинг отвечает нода, она же генерит для клиента весь код «фронта» и выплёвывает его браузеру единым куском. Я затрудняюсь сказать, где тут фронт заканчивается, где бэк начинается.staticlab
19.02.2019 01:47Обычный SPA. Как правило они тоже прекомпилируются. Впрочем даже без этого они действительно могут достаточно большими, потому что содержат серверные библиотеки. Здесь же вы выдаёте это в таком свете, будто эти сотни мегабайт загружаются прямо пользователю. Толпа радостно подхватывает, ведь JS модно ненавидеть :)
Psychosynthesis
19.02.2019 01:57Нет же, вовсе даже не SPA, а очень даже объёмные системы.
К примеру, в проекте с которым я сейчас работаю, для MVP проекта UX-дизайнерами отрисовано больше двух сотен экранов.
В том-то и абсудр, что подобное делается по концепции SPA.
И да, пользователю нода, конечно, не грузится. Но некоторые модули вполне могут — тут всё зависит от проекта и фич, которые захотел использовать разработчик.staticlab
19.02.2019 08:02+1Нет же, вовсе даже не SPA, а очень даже объёмные системы.
И в чём тогда паника, что node_modules для такого проекта весят 300 мегабайт, большая часть из которых, скорее всего, — webpack, babel и т.п.?
Но некоторые модули вполне могут
Вот и нужно по конечному бандлу смотреть.
Psychosynthesis
19.02.2019 15:45Нет паники. Это скорее отвращение к профессиональной импотенции авторов подобных проектов.
Webpack, babel… Ок, к ним вопросов нет, допустим.
Вопросы есть к паре десятков других модулей, которые тянутся в зависимостях.
Как вам, например, две версии Bootstrap, потому что одну из них требует один из используемых компонентов (datepicker), а зависимость указана строго, а вторая используется в проекте для сетки. Я молчу уж про то, что меня от самого бутстрапа воротит (там полная шизофрения в стилях), но неужели сетку-то нельзя было руками прописать?
Ну и в таком духе.
Тут диллема такая, что если ты используешь подобную концепцию в разработке — то ты либо обрекаешь себя на кучу дополнительной работы по вычищению кода (которую большинство, очевидно не делает), либо генерируешь тонны мусора, помимо полезного контента.
bano-notit
18.02.2019 23:24Ну знаете ли, с нодой ещё не всё так плохо, там можно устанавливать пакеты глобально, и они будут работать во всех проектах. А вот в питоне это в принципе проблема не стоит и модули могут быть ТОЛЬКО глобальными. И там костыли ещё веселее — создаётся свой собственный питон для проекта и в него закидываются свои собственные интерпретатор, куча библиотек и другие увеселительные файлы, ведь один проект должен работать со старой джангой, а другой с новой. И только потом на всё это намазываются уже зависимости самого проекта…
А так то такие «проблемы» у каждого нормального пакетного менеджера. Он должен хранить модули только для одного проекта, ведь в другом будут и версии библиотек другие и вообще всё другое.Psychosynthesis
19.02.2019 02:03Нет, что вы. Я не конкретно в ноду ткнуть хотел, а в принципе указать на слабое место концепции.
Так-то, сама нода мне в качестве домашнего сервера даже больше нравится чем апач, например.
Eldhenn
18.02.2019 08:00А ещё мы больше не контролируем свои компьютеры. Хуже того, мы даже не всегда контролируем освещение в своём дома. Паника!
farcaller
18.02.2019 17:15У меня тут на днях духовка начала апдейт ставить когда я хотел утку запечь, а вы говорите "освещение" (в ней OpenBSD внезапно — в духовке).
D01
18.02.2019 09:20+1Согласен на 100%,
Но кстати, node_modules просто так никогда не создается, кто-то (вероятно вы?) при установке модуля забыл перейти в каталог программы, либо думал что делает глобальную установку и забыл флаг -g
rgs350
18.02.2019 10:15+3«Реестр Windows — дерьмо», — говорили они. :)
Nalivai
18.02.2019 13:09+1Даже такой бардак все еще лучше реестра. По крайней мере это файлы.
tyomitch
18.02.2019 16:49И чем это лучше?
Nalivai
18.02.2019 17:03По файлам можно грепать, файлы можно инкрементно бэкапить, редактировать любимым редактором, хранить в репах и легко и непринужденно жонглировать ими скриптами.
Borz
18.02.2019 17:11берёте
reg.exeи делаете почти тоже самое, что и через greplegolegs
18.02.2019 20:58И инкрементный бекап?
Borz
19.02.2019 01:02после выгрузки в .reg файлы вы можете с ними делать всё то же самое, что и с .cfg и прочими "текстовыми" конфигами, вплоть до инкрементального бекапа
Borz
19.02.2019 08:53Fix (убрал курсив):
после выгрузки в
*.regфайлы вы можете с ними делать всё то же самое, что и с.cfgи прочими "текстовыми" конфигами, вплоть до инкрементального бекапа
vlivyur
19.02.2019 11:10+1Вроде не получится — если удалили ветвь, то в бэкапе её просто не будет, и если на старый реестр накатывать новый, то удалённая ветвь просто останется. Для этого её нужно будет явно удалить.
iig
19.02.2019 11:45+1Ага, и комменты писать в реестре не принято. В отличие от.
Хотя единственный существенный недостаток — реестр в VSC вроде как не помещается. А так… скрипты из малвари давным-давно научились легко и непринужденно править реестр.
sn00p
18.02.2019 11:19нет рабочего стола или какого-то десктопа.
Зачем в таком случае ставить Steam?
Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock
Такое ощущение, что автор статьи просто запускает команды, которые он не понимает, потом удивляется.
У меня в каталоге тысяч сто файлов в разного рода директориях, начинающихся с точки. Их можно контролировать, как хочет автор, но зачем?
«Делайте что-то одно, но делайте это хорошо». Кто же виноват, что с каждым днем задачи усложняются, количество информации увеличивается, количество софта и утилит тоже, все в соответствии с принципами.
Это не отменяет рукожопость многих разработчиков, но в целом все выглядит куда лучше, чем сто тысяч хрен пойми каких dll в другой операционной системе.knstqq
18.02.2019 11:58+2тайловый графический менеджер без десктопа (десктоп, или в переводе рабочий стол — это такая штука с ярлыками и всё). Даже KDE позволяет сделать кучу виджетов, панель задач, а виджет рабочего стола — удалить.
Или просто запускать стим в своём x-server без графического менеджера, который окошки таскать мышкой позволяет.sn00p
18.02.2019 15:02Да с чего вдруг это «штука с ярлыками»? Это основное окно графической среды пользователя вместе с элементами, добавляемыми в него этой средой. Это прям в википедии написано.
Есть графическая среда, есть и десктоп. Ярлыки можно там не создавать, десктопом он разве перестанет быть?lorc
18.02.2019 16:04В $HOME/Desktop как раз «ярлыки» и хранятся. Для тех оболочек, которые умеют их показывать.
Если пользоваться вашим определением, то десктоп у меня конечно есть. Правда, я его никогда не вижу, ибо тайловый менеджер всегда закрывает его окнами. Но «ярлыки» он отображать не умеет в принципе.
agmtr
18.02.2019 17:37Десктоп — это специальное окно развернутое на весь экран, даже в винде можно убить проводник, но при этом открывать новые окна и управлять ими не имея рабочего стола, т.к. за это отвечает оконный менеджер. В linux же, люди которые с ним на ты, часто
mayorovp
18.02.2019 17:42В винде есть два значения у термина «рабочий стол». Первое — окно на заднем фоне, создаваемое Проводником. Второе — область в которой создаются окна, и именно в этом значении термин используется в winapi.
agmtr
18.02.2019 18:17В linux же, люди которые с ним на ты, часто пользуются только оконным менеджером
mayorovp
18.02.2019 17:20Зачем в таком случае ставить Steam?
Чтобы запустить выделенный сервер какой-нибудь игрушки?
sn00p
18.02.2019 23:09Точно!
Только весь прикол стима в другом немного, а оно не заработает без полноценного десктопа. Ну да ладно, может сейчас и по-другому, давно не играл.mayorovp
19.02.2019 08:54Весь прикол Стима в данном случае — в том, что он для игрушек является одновременно средством доставки, системной аутентификации и DRM. Если игрушка просит Стим — вам придётся использовать Стим, даже для выделенного сервера в фоне.
vlivyur
19.02.2019 11:17Стиму нужны только X11, а всё остальное он сам рисует, если пользователь его каким-то образом запустит. А X11 это ещё не десктоп.
sn00p
19.02.2019 15:43Вон выше определение десктопа из википедии.
Это основное окно графической среды пользователя вместе с элементами, добавляемыми в него этой средой.
у Х11 нет разве основного окна?vlivyur
19.02.2019 17:30Насколько я помню только оно и есть. Претензия к «полноценному десктопу», в таком режиме он больше напоминает vim. Полноценный десктоп это уже KDE, Gnome или fluxbox.
justboris
18.02.2019 11:25Хорошая статья и спецификация полезная, но работает только под Linux. Поэтому, большинство разработчиков, сидящих на Mac, о ней и не подозревают.
TonyLorencio
18.02.2019 11:32В маке разве не
~/Library/My App,~/Library/Caches/My App/,~/Library/Preferences/com.example.myapp.plistпо гайдлайнам/документации?Borz
18.02.2019 11:42но это не переменные из статьи.
А в Windows свои пути, про которые тоже надо знатьbano-notit
18.02.2019 23:30Так в этом-то и смысл, что их можно прописать в переменных среды в «настройках» ОС и оно будет работать точно так же! XDG придуман для всех систем, а не только для линуксоидов.
Borz
19.02.2019 01:20но стандарт говорит про "если переменных нет, то используйте вот такие пути", которые совершенно не такие для Windows и MacOS.
Вот если бы стандарт говорил, что эти переменные обязаны быть в ОС, сродни, как сейчас известно, что есть $HOME и $TMPDIR и их получение присутствует практически во всех нормальных языках, то имело бы смысл наезжать на разработчиков прикладного ПО, что они их не используют.
И этих каталогов даже не только в стандарте FHS 3.0 нет, но и в её dev-версии. Но зато там есть описание как раз про создание dot-каталогов в хомяке
justboris
18.02.2019 11:54+1да, но это уже порождает в коде конструкции типа
if(os == "Mac") { // что-то } else if(os == "Windows") { // еще что-то } else { // и еще }
а это уже выглядит не так удобно, как прочесть нужный путь из переменной.
Borz
18.02.2019 12:00+1на самом деле, не сказать чтобы сильно усложняло.
На этапе инициализации приложения инициируете пути до каталогов на основе ОС в которой запустились. А потом уже используете инициированные переменные в коде. Ведь вряд ли ОС поменяется в процессе работы приложения, а значит и пути "внезапно" не изменятся.justboris
18.02.2019 12:35Именно сложностью поддержки авторы tmux объясняют, почему они не хотят добавлять эту фичу: github.com/tmux/tmux/issues/142#issuecomment-222387251
Borz
18.02.2019 12:38но при этом, они реализовали возможность переместить каталог в другое место: https://github.com/tmux/tmux/issues/142#issuecomment-330558015
т.е. всё что осталось — запрограммировать вычисление этой переменной на этапе запуска. Это OpenSource — каждый может пойти и сделать Pull Request на эту реализацию
Ryppka
18.02.2019 11:36ДедЫ в $HOME писали, и нам надо! А те, кто мерзкие systemd или Freedesktop юзАют — в /dev/null того, адназначна!
Borz
18.02.2019 11:41когда пишешь кроссплатформенное приложение, то у тебя есть два пути:
1) не мудрствовать и везде брать "$HOME/.myAppDir"
2) смотреть как в каждой ОС реализовано хранение данных и реализовывать отдельный код сугубо под эту ОС. Необходимо как минимум 3 способа — для MacOS, *nix и для Windows. Более того — ещё учесть, что в каждой ОС есть или нет разделение на "конфиги", "кеши" и т.п., что ещё больше усложняет программу в этом куске
Скажите, какой путь скорее всего выберут "на старте" разработки?
Каталоги с точкой вначале потому и делают, чтобы вам они не мешали в обычном режиме "не показывать скрытые файлы".
А в остальном — какая разница где лежит файловая помойка — как отдельный "скрытый" каталог в $HOME или как несколько каталогов в разных местах?
И да, что проще почистить при удалении программы — 1 каталог или кучку?
disclaimer: я не ратую за реализацию каталогов в хомяке, но лишь показываю почему это делают чаще чем хотелось бы.
knstqq
18.02.2019 12:04Скажите, какой путь скорее всего выберут «на старте» разработки?
Многие программы с чего-то начинали, но пора из колыбели вылезти.
tmux с 2007 года пилится, а он всё равно конфиг только в $HOME/.tmux видит без костылей0xd34df00d
18.02.2019 18:42+3Многие программы с чего-то начинали, но пора из колыбели вылезти.
Вылезание из колыбели означает написание кода для миграции, обработку случаев, когда есть и старый, и новый путь, думы о том, как обеспечить возможность отката на предыдущую версию программы, которая ещё была в колыбели, и всё такое. При этом профит от всех этих манипуляций весьма неочевиден.
TonyLorencio
18.02.2019 12:071) не мудрствовать и везде брать "$HOME/.myAppDir"
Всё бы хорошо, но на Windows файлы, начинающиеся с точки, скрытыми не считаются
Borz
18.02.2019 12:10Как часто в Windows вы ходите в директорию хомяка? Вроде как давно уже до неё добраться не по одному щелчку мыши
ProVal
18.02.2019 14:45По двум щелчкам. Пуск и слева в пуске ссылки на юзерпапки (список в определённых пределах настраивается)
Скриншот
mayorovp
18.02.2019 17:253) найти язык или библиотеку, которая все пути определит сама. Казалось бы, фреймворков для написания кросс-платформенных программ развелось немеряно — вот бы туда что-нибудь добавить уже...
arthur_veber
18.02.2019 11:58-1переходите на windows
(достаёт попкорн)
domix32
18.02.2019 12:49А куда в Windows писать?
%userprofile%\\.appdir?%appdata%\\appdir? Некоторые гадят еще и в%userprofile%\\documents
vlivyur
18.02.2019 13:11Ага
allusersprofile
userprofile
appdata
programdata
commonprogramfiles
programfiles
public
И любимый C:\Documents and Settings\
А внутри выбираем уже по своему вкусу.
el_gato
18.02.2019 13:26Да, у меня на винде все норм в домашней папке
rgs350
18.02.2019 14:08И названия всех директорий начинаются с точки. Хм… Подозрительно.
(кидает палку в огород линукс-пользователей с криком: «Вы изговняли мне винду. Хады!»)
amarao
18.02.2019 14:41Файлы с точкой — скрытые файлы. В unix оно довольно консистентно, а винда пускай адаптируется.
extempl
18.02.2019 16:06Так они вроде универсально создаются, разве нет? Именуются с точкой и ставится флаг "hidden" для тех, кто точку не понимает.
saboteur_kiev
18.02.2019 17:20флаг хидден не нужен, ибо линуксовый софт его не видит в силу эмуляции POSIX прав, где такого флага нет.
mayorovp
18.02.2019 17:28Вот та штука, которая эмулирует POSIX, могла бы и выставлять флаг Hidden при создании файлов и папок начинающихся с точки.
saboteur_kiev
18.02.2019 17:35Потому что hidden это не синоним а отдаленный и не совсем верный аналог того, что в *nix начинается с точки.
Файлы в POSIX не скрытые, а «не пользовательские», поэтому умышленно их никто не скрывает. В то время как если их скрыть, то еще непонятно, как себя может повести различный софт.
Например вдруг какой-нить виндовый backup по дефолту не будет бэкапить скрытые файлы?
Или наоборот, в линуксе в некоторых случаях wildcard может пропускать dotfiles, а в windows не будет.
Поэтому зачем брать на себя ответственность интерпретации чего-либо в другой системе, если стандарты напрямую не сравниваются?mayorovp
18.02.2019 17:48А что бы вы сказали о линуксовом софте для бэкапов, который бы пропускал файлы, начинающиеся с точки?
0xf0a00
18.02.2019 16:07Винды больше, так что на пожелания линукс пользователей ей довольно консистентно.
amarao
18.02.2019 16:21Я то и вижу — у людей какие-то забавные .node, .yarn и прочие .viminfo. Неужели это софт под винду так писали? Или таки портировали под винду с линуксов?
el_gato
18.02.2019 16:50Как ни странно, но таки да, так пишут софт под винду, например Git клиент под винду создал мне .bash_history и пишет все туда. Вим у меня тоже есть.
eshirshov
18.02.2019 14:07а я всегда недоумевал почему ОС позволяют приложениям писать вообще куда угодно.
amarao
18.02.2019 14:40+2Модель безопасности ОС подразумевает, что программы действуют от пользователя. Что можно пользователю — можно и программе.
eshirshov
18.02.2019 14:46практика показывает что программы действуют от программиста. :(
а почему бы не — программе можно не более чем пользователю?amarao
18.02.2019 15:23+1Дело в том, что «пользователя» в системе нет. ОС взаимодействует с программами и только с ними (ну ещё с внешним миром в форме сети). Когда вы говорите «защитить пользователя от программы» вы на самом деле говорите «защитить данные одних программ от других». И в серверном мире решение давно есть — «запускайте от разных пользователей».
Не существует «злых программистов», потому что без «злых программистов» у пользователя будет коробочка, которая даже вентилятор сама включить не может, не то, чтобы помигать курсором на экране.
eshirshov
18.02.2019 18:42я бесконечно рад за серверный мир… и грущу за несерверный :( и прочее несовершенство мира :(
в android есть некоторые приватные каталоги программы это меня радует.
ЗЫ
Не существует «злых программистов», потому что без «злых программистов» у пользователя будет коробочка, которая даже вентилятор сама включить не может, не то, чтобы помигать курсором на экране.
я реально в шоке от подобного выверта логики. можно я тоже попробую: мошенников не существует потому что есть банковская система!amarao
18.02.2019 18:57+1За вычетом малвари, все программы на компьютере у человека этому человеку нужны. Т.е. то, что делал программист, который эту программу писал, ему нужно. А дальше человек очень недоволен, мол, я соблаговолил его программу использовать, а она пишет конфиг не в .config/foo, а в .foo.
UPD: В мире свободного ПО. Что там винда принудительно ставит — это я уже не знаю.iig
18.02.2019 20:30+1все программы на компьютере у человека этому человеку нужны.
Спорно. Готов поспорить, что на любом компе есть программы, использовавшиеся 0 раз.
saboteur_kiev
18.02.2019 17:31практика показывает что программы действуют от программиста. :(
а почему бы не — программе можно не более чем пользователю?
Потому что для вас пользователь и программист — это слова в русском языке.
А для системы — это UID, и с этой точке зрения программе уже можно не более чем пользователю.
bano-notit
18.02.2019 23:37SELinux посмотрите) Там достаточно красочно в конфигах описано, у какой конкретно
парашидвери какая программа должна сидеть. Проблема в том, что под какие-то заумные и не пользовательские программы таких конфигов нема.
akostrikov
18.02.2019 17:54-1Есть решение: контейнеры.
eshirshov
18.02.2019 18:54подробнее? любопытно
akostrikov
18.02.2019 19:03Например в докере запускаем приложение, которое конфигурационные файлы будет хранить в изолированном дисковом пространстве. При желании можно добавить локальные файлы через "-v local_dir:container_dir".
Когда контейнер завершит работу — удаляем. Или запускаем снова. При этом конфигурационные файлы не будут видны на хосте.
Под линуксом запускал и десктопные приложения в таком виде когда боролся с проблемами совместимостей библиотек. На винде тоже можно, но не пробовал.qw1
18.02.2019 21:03Не всегда это работает. Например, bash или git-клиент так не используешь (а они пишут в ~)
Throwable
18.02.2019 14:50+1Ваша спецификация — гвн (с) самизнаетекто.
От того, что все дерьмо из $HOME/.* раcкидают по другим директориям, оно не перестает быть дерьмом. Особенно примечательно, когда пакет/программа удаляется, а ее отложенные личинки еще по всему дереву собирать приходится. К тому же давно пора проапдейтить package manager, чтобы при удалении подчищал за собой.amarao
18.02.2019 15:24+2Конечно. Вы удаляете СУБД — и она за собой утаскивает базу данных. Удаляете почтовый клиент — и 20 лет переписки превращается в ничто.
… Можно ещё подумать о том, что должно стать с репозиториями при удалении git'а.0xf0a00
18.02.2019 16:09БД СУБД и БД почтовика это полезные файлы, даже без программы для работы с ними они представляют ценность. Конфиги же без программы ценности не представляют, так что тут очень легко провести границу.
roswell
18.02.2019 17:13Ну, почему же так сразу не предоставляют. Вот, например, innodb_file_per_table — опция в конфиге MySQL, от которой зависит, где именно будут располагаться данные — в системном пространстве (огромном ibd-файле), или в отдельных файликах. В версии 5.5 эта опция по умолчанию была выключена, а в 5.7 — включена.
Throwable
18.02.2019 20:51Данные — это результат моей работы, и я хочу:
- точно знать где и что лежит, а не шариться по диску, ища кто, что и где сохраняет
- указать где их надо создавать, хотя бы при первом запуске программы
- держать независимо от основной программы
- делать бекапы и прочее
Все остальное, включая конфиги программы, кеши и индексы — это мусор, который всегда можно преспокойно снести, либо для особо одаренных предложить опцию.
Что мы имеем, благодаря данному "стандарту" — это очередной набор помоек, куда каждый будет сваливать что хочет. В моем .local/share сейчас 63 директории, включая data/LibreCad, ibus-table, xorg, gegl-0.2, gegl-0.3, и прочая херь, которая бесполезна и остается после сноса программы, и рядом с которой я не хочу держать действительно важные для меня данные.
bano-notit
18.02.2019 23:39+1Вообще-то пакетные менеджеры при удалении подчищают за собой всё, что написано подчистить в манифесте пакета. Тут всё достаточно хорошо продуманно, вопрос в том, что авторы пакетов этим не пользуются.
vics001
18.02.2019 15:05-1Какая-то глупость, первый раз слышу об этом стандарте. Программистам надо хранить данные, если данные для глобальных сервисов они идут в /etc; если данные привязаны к конкретному пользователю идут в $HOME.
.bash, .inputrc, .git, .gitignore, .XXX все идут в $HOME. Бардак в том, что нет системы .app/package.name/.myfiles.amarao
18.02.2019 15:25+2А зря первый раз слышите. Он есть, и писать надо не в ~/.app/, а в ~/.config/app/
OYTIS
18.02.2019 16:41+2Если такие монстры, как bash, vim, ssh и т.п. его нарушают, то сложно убедить остальных, что это стандарт.
Borz
18.02.2019 16:44+1а они не GUI приложения — почему они должны как-то смотреть на стандарты для GUI?
amarao
18.02.2019 16:46Насколько я понял, это стандарт для GUI (вероятнее всего, X и Wayland), а консольный софт по-старинке пишет в ~/.*
OYTIS
18.02.2019 16:52+1TC, насколько я понял, предлагает использовать его везде. Например, он упоминает node_modules, которые тоже, очевидно, должны были бы переместиться под XDG_DATA_DIRS.
amarao
18.02.2019 17:02+2В целом это разумное предложение. Осталось убедить git, bash, node и множество других крупных проектов поменять поведение. 99%, что по причине обратной совместимости так не будут делать.
Кстати, на линуксах эти файлы меньше режут глаз, т.к. обычно скрыты (и обычно игнорируются glob'ом).Borz
18.02.2019 17:05не есть правильно, что консольное ПО будет использовать константы от GUI. F префикс "XDG_" — это про GUI
тогда уж логичнее завести константы USER_CONFIG_HOME, USER_DATA_HOME и USER_CACHE_HOME и пользовать ихamarao
18.02.2019 17:38Есть вариант, даже не гоняться за переменными, а просто писать не в ~, а в ~/.config и т.д.
Mingun
18.02.2019 18:01Вы можете легко перенести существующие программы на использование этого стандарта. Для этого при создании новых файлов начните использовать стандарт, но продолжайте проверять старое расположение файлов при их чтении. Это позволит выполнить миграцию, не нарушая работу программы для пользователей с файлами конфигурации или данными, созданными предыдущей версией программы.
Неужели "монстры" не осилят?
amarao
18.02.2019 18:54+2Не осилят. Причина не в том, откуда читать, а в том, где всё остальное ожидает их файлы, т.е. в интеграции с соседними приложениями. Например, у того же баша на положение .profile завязано такое количество софта (и, главное, самописных скриптов), что их трудно представить. Тому же гиту проще, потому что у них есть CLI для работы с конфигом (скрывающее положение конфига). Но в более старых мы точно хотим эти файлы точно в этом месте и нигде в другом.
Ну представьте себе перенос ~/.ssh/authorized_keys в ~/.config/ssh/authorized_keys. Взорвётся пол-интернета из-за сломавшихся систем деплоя и аудита.Mingun
18.02.2019 20:35Ну так а симлинки никуда же не денуться. Главное разумно их задепрекейтить в дистрибутивах — сначала даем симлинки, затем переписывает тот софт, что дистрибутив мейнтейнит, затем отменяет симлинки, с возможностью поставить переходные пакеты, их возвращающие
qw1
18.02.2019 21:02Симлинк может содержать переменную окружения?
mayorovp
18.02.2019 21:52А зачем? При смене местоположения можно же и симлинк переназначить.
Я вижу другую проблему: симлинки — такой же мусор, и с такими же недостатками.Mingun
18.02.2019 22:23Только временный для возможности миграции. В следующем LTS его, конечно же, нужно выпилить
qw1
18.02.2019 22:53При смене местоположения можно же и симлинк переназначить
И как это нас приближает к новому стандарту? К примеру, пользователь переместил настройки в другое место и соответственно изменил переменную окружения. Все симлинки превратились в тыкву, софт потерял настройки.
TonyLorencio
18.02.2019 22:50Не так сложно представляем этот перенос. Во многих дистрибутивах уже отказались, например, от /bin в пользу /usr/bin, а /bin теперь — симлинк
bano-notit
18.02.2019 23:42+1Я вам открою маленький секретик, vim, ssh и bash — программы пользовательские. Все свои настройки они хранят где-то далеко в глубинах папок конфигов, а вот пользовательские конфиги, которые как бы являются документами пользователя, хранятся у пользователя. (во всяком случае я считаю, что мои ssh-ключи и моя цветовая палитра для vim и bash являются моими файлами, а не файлами для работы этих программ)
OYTIS
18.02.2019 16:37.git в ${HOME} — это гениальная идея, кстати.
Cerberuser
18.02.2019 16:50Храните конфиги в репозитории и делайте `revert` при удалении программы, породившей их?
mikechips
18.02.2019 19:08А что, неплохо же. Особенно если каждый коммит будет привязан только к бардаку одной конкретной программы, без каких-либо объединений.
mikechips
18.02.2019 18:57Страшно представить вес индексов, историю коммитов и прочих файлов Git'а при этом...
berez
19.02.2019 07:58Ничего страшного. Конфиги меняются не так уж часто, как кажется.
Помнится, в одном не очень маленьком банке конфигурацию на сервера выкатывали именно так — через систему контроля версий. Правда, там был не гит, а svn, но не суть. Всем все нравилось и неплохо работало.
iig
18.02.2019 15:06а почему бы не — программе можно не более чем пользователю?
Учитывая, что пользователь это тоже программа, нужно переделать всю модель безопасности.
janatem
18.02.2019 15:30+1Выглядит красиво, но почему XDG? А как же консольные приложения, которые про иксы могут ничего не знать, они тоже должны смотреть XDG-переменные?
amarao
18.02.2019 16:25Насчёт переменных вопрос открытый. У меня на линуксовм десктопе большинства переменных из топика нет. Но большая часть софта пишет таки в ~/.config/, а не в ~/.appfoobar
janatem
18.02.2019 16:39Тут дело не столько в переменных (должны быть, помимо них, стандартизованные умолчания), сколько в том, как должны вести себя неиксовые приложения. Есть ли про них аналогичный стандарт?
amarao
18.02.2019 16:44Сложно сказать. Тот же git пишет в ~/.gitconfig, а не в ~/.config/git. Я посмотрел на сервер с конфигами — у меня ~/.config вообще отсутствует, зато есть ~/.cache.
Возможно, это и определяет количество .files, они не-десктопными приложениями приносятся. Мне кажется, это архитектурная ошибка, и тяжёлое легаси, которое очень трудно исправить (т.к. софта много, и он очень сильно старый с мощной userbase, так что причин меняться нет).
Borz
18.02.2019 16:43у этих переменных "есть" значения по-умолчанию.
Но согласен с janatem — получается, что графические софтины должны учитывать эти переменные, а консольные нет. Но идёт дальше — а если у софтины есть и GUI и CLI версия, то как ей быть? Приоритет на CLI? А если я поставил только GUI вариант, а CLI нет, то всё равно должна учитываться только CLI особенность? Не удобнее ли просто сразу смотреть только в одном место без учёта — иксы это или нет?
brooth
18.02.2019 15:37А какой ад творится в Android. Там каждое второе приложение считает необходимым создать свою директорию в $HOME
wilerat
18.02.2019 16:17+1Согласен.
Даже Vk, WatsApp, Telegram, Сбербанк и куча других… Просто берут и создают папку в корне флешки, которая никогда не удалится при удалении приложения.
Зачем нужны папки Environment.getExternalStoragePublicDirectory() и context.getExternalFilesDir(), которые специально предназначены для хранения файлов приложения на внешней памяти, они видимо не знают…
Или это я просто не понимаю, зачем так делать.
lostmsu
18.02.2019 19:12+2Чтобы получить пермишен читать из external storage.
wilerat
18.02.2019 23:03Но для для каталога getExternalFilesDir запрос разрешения вообще не нужен, достаточно в манифесте прописать, и то при maxSdkVersion=«18».
А для остальных папок нужно просто добавить разрешение в манифест, запросить его и определить файлпровайдер с доступом к каталогу, в котором нужно читать или писать (хоть к корню флешки).
Реализуется совсем не сложно и описано в официальных гайдлайнах.
Или здесь какая то другая магия с доступами к external storage?vikarti
19.02.2019 07:28Потому что иногда данные с которыми работает приложение, нужны и другим приложениям и желательно чтобы пользователь мог и руками указать где они лежат.
Хотя обычно, если данные имеют большой объем но эти данные другим приложениям либо малополезны либо вообще бесполезны — хватает возможности выбрать просто — внутренние хранилище/флешка.
С fileprovider'ами надо работать отдельно и появились они «недавно» (вот в этом году уже пришлось фиксить в приложении(клиент одного аппаратного девайса, поставщик еще и за подписку просит) логику что если надо делать и обрезать фотографию — то надо таки все через fileprovider'ы делать, до меня это вообще почему то не было сделано).
lostmsu
20.02.2019 05:00+2Я не имел ввиду, что им нужно это разрешение на самом деле.
Я имел ввиду, что они хотят читать пользовательские данные по-максимуму, и потому просят этот пермишн.
А это — просто прикрытие.
akurilov
18.02.2019 15:43Уважаемый автор. Ежели программа кросплатформенна, то какую переменную среды она должна использовать, чтобы работало в т.ч. и под вендой и под макосью и т.п. Жду ответа, засим откланиваюсь.
mikechips
18.02.2019 19:02+2Какое окружение — такую пусть и использует. Как-то так:
if(os == "windows") { path = "%APPDATA%\MyApp"; } else ...
Выше уже такое предлагали. И дабы не творить помойку в коде — определять путь лишь где-то возле входной точки, а в остальном коде ссылаться на него.
saveSomeConfig(path, "MyVar", val);
codemafia
18.02.2019 16:00Чего то не понимаю, или $HOME как раз таки и должна содержать пользовательский бардак с персональными настройками?
extempl
18.02.2019 16:10Ну Home ещё содержит просто пользовательские директории, documents, pictures там всякие. Потому, насколько я понимаю, основное возмущение в сторону самоуправства (некоторые ещё и не скрытые директории создают), когда есть определённый стандарт.
Spaceoddity
18.02.2019 17:25Я в Винде папку Users давно уже расцениваю исключительно как аналог Корзины. Потому что загажено там всё. Причём многие софтины прописывают и прямо в корень Users, и в AppData/Local, и в AppData/Roaming. И в ProgramFiles могут свои конфиги хранить (ещё угадай в каком — х64 или х86). И что больше всего раздражает — при деинсталляции выпиливаются из ProgramFiles, но свой мусор так и оставляют в Users (хотя и специально галку ставишь «при удалении забирай всё своё барахло»). И со временем каталог Users становится тем ещё квестом по навигации.
Вчера вот пробовал Sublime под себя настроить… Откровенно утомило бегать по директориям (ещё и пэкэджи куда-то надо распаковать). Хоть третью панель в коммандере открывай.
maydjin
18.02.2019 17:48+2Прочитав первые строки уже хотел начать ругаться на автора что мол видали мы эти ваши бинарные реестры и прочие гномовендовые монструозности.
Но автор чуть более чем полностью прав. Особенную боль не следование freedesktop стандартам доставляет тем, кто хочет легко переключать конфигурации и окружения без контейнеризации и прочих решений в стиле "из пушки по воробьям".
max_myr
18.02.2019 19:16-1Шеф все пропало!!!
Но я больше боюсь что в тех файлах не служебная информация…
За нами следят!
glowingsword
18.02.2019 19:24+1Спасибо за этот перевод. Очень важную тему в нём подняли. Может он сподвигнет разработчиков следовать рекомендациям XDG. А то надоело уже, что в хомяке полно файлов и каталогов с дот в начале имени файла, и даже не всегда ясно чей именно это файл или каталог.
Вроде уже давно определились, что так делать не хорошо, но полно софта до сих пор мусорит прямо в хомяке пользователя. И ведь среди приложух что так делают есть такие популярные приложения и средства разработчиков как atom, electron, skype, firefox, thunderbird, gimp, dosbox, nodejs, shutter, mono и подделия на нём, nodejs и npm, go, vim и множество других. Я молчу про игры — они все, как сговорившись, мусорят в хомяк.
KirEv
18.02.2019 20:37Отличная статья:
1. описание проблемы
2. предложение решения
Все бы так.
для себя вывел следующую практику:
1. в ~/ (home) пишу все что хочу, разный мусор, тесты и т.п., всеравно кроме меня там куча разных дот-папок и файлов к созданию которых отношения не имею, короче в хоме у меня срач… и вообще — хом на том же диске\разделе что основная ОС, короче там то что не страшно удалить.
2. то что важно сохранить — в отдельных местах, обычно это отдельно смонтированные диски типо:
— /media/240-ssd
-/media/1tb
-/media/2tb
там то уже порядок и никакой софт к текущей ОС туда не ставиться… так и живем
PS: оно действительно, при листинге ~ все в 1 экран не вмещается, причем а моих папок то всего штуки 3…
gecube
18.02.2019 21:16Ну, ок, будет помойка не в /home/username, а в /home/username/.local
Или что там предлагает автор статьи.
Вариант универсального файла конфигурации в виде БД (а-ля реестр виндовс) — тоже не идеален, т.к. хоть и локализует помойку в одном месте ФС, но тащит за собой другие проблемы.
На самом деле основная проблема в совместимости конфигов между разными версиями одного приложения. Неясно как ее указанные подходы планируют устранять. Может это… Все на nixos?
storm_r1der
18.02.2019 22:25Вопрос распределения модулей / зависимостей по каталогам — вечен, и подход у каждого индивидуальный, все это конечно хорошо, но для стандартизации нужна инициатива не только сообщества, но и непосредственно разработчиков ОС, при чем только последние, увы, могут поставить жирную точку, иначе будут продолжать рождаться бесчисленные туториалы, в которых, например (неожиданно) — Github = Git (рекомендую к просмотру, отлично поднимает настроение. У автора, кстати, есть и платные курсы, которые хорошо продаются). По сути дела решения, предложенные автором, имхо, просто перенесут свалку из одного места в другое.
Ну и справедливости ради стоит упомянуть что все же есть какие-никакие альтернативы стандартному подходу хранения необходимых зависимостей в каталогах, например, npm-tink или yarn-pnp, но есть ряд условностей: первый является еще одной, пусть и независимой от npm, но все же зависимостью, а последний загружает модули из общего кеша пакетного менеджера (что по сути, все еще не отменяет хранение зависимостей в каталоге, хотя является, имхо, весьма достойной альтернативой).
Уверен, и в случае использования других пакетных менеджеров (нет) можно найти готовые решения, или написать свое, вопрос только в целесообразности их написания и костылей, необходимых для этого (с учетом всего вышесказанного).
technic93
18.02.2019 23:41Куда там мусорить в $HOME разницы нету. Надо бы уже вводить жесткое разделение прав для приложений.
Каждое приложение запускается в своей песочнице со своим uid/cgroups и видит три папки:
- /app (r-o) библиотеки и ресурсы поставляемые вместе с приложением.
- /system (r-o) системные библиотеки, утилиты и сокеты с которыми разрешено взаимодействовать приложению.
- /config (r-w) то что можно по желанию сохранить после удаления приложения.
- /cache (r-w) то что можно удалить в любой момент для экономии места.
Далее система должна предоставлять возможность добавлять доступ к пользовательским папкам типа ~/Documents ~/Pictures и так далее c выбором прав r-o или r-w. А не как в андроиде сразу весь Storage.
При удалении приложения менеджер пакетов должен вычищать соответствующий cache.
Вроде в серверном Линуксе похожие практики используются, а на десктопе уже не как на заре unix, кроме vi, awk и sed развелось ещё миллион больших приложений сомнительного качества. Умеет ли в такое snap/flatpack?math_coder
19.02.2019 01:03Всё же не стоит сбрасывать со счетов и другой способ решения этой проблемы: выкинуть этот «миллион больших приложений сомнительного качества» и оставить vi, awk и sed.
POPSuL
20.02.2019 08:19Ладно если создают папку на приложение, я уже более-менее смирился с этим. Но вот JetBrains прям поражает! На каждый релиз отдельная папка в хомяке…
Я вообще за дополнительное разделение еще и на VENDOR/PROGRAM внутри .config/.cachevlivyur
20.02.2019 16:31+1Так это Visual Studio виноват. VS только недавно догадалась что можно все мои проекты пихать в один каталог (source), а не создавать Visual Studio 2005, Visual Studio 2008, Visual Studio 2010, Visual Studio 2013, Visual Studio 2015 (хоть и внутри одного каталога, но зато какого — Documents). Но каталог Visual Studio 2017 всё равно есть, теперь там только часть настроек, но без Projects, зато с их бэкапами.
Хотя ихний же SSMS всегда писал в один и тот же каталог SQL Server Management Studio и не парился.Borz
20.02.2019 18:52у Jetbrains несколько иное — они пихают по каталогам конфиги от IDE. Версия меняется — новый каталог, чтобы была возможность откатиться к предыдущей версии. При новой версии конфиг может быть "с нуля", мигрирован с изменениями и прочее. И потом, могут стоять сразу 2-3 версии одной IDE, т.к. где-то плагин не докатился ещё, а где-то наоборот что-то сломалось/изменилось и удобнее в предыдущей версии делать
ebragim
Какой-то истеричкинг. Автора не возмущает, что какие-то программы могут выкачать зависимость и поставить её? Или тоже попытается удалить?
masai
Автора возмущает, что при наличии стандарта, разработчики этот стандарт игнорируют или не знают о нём. В итоге имеем неконтролируемый беспорядок в домашней директории, так как порой пути к конфигам жёстко прописаны в исходниках.
Если зависимость выкачивается куда положено, а не создаёт (условно) в корневой директории поддиректорию, куда сваливает всё подряд, то всё в порядке.
iig
Когда-то давным-давно програмистам было привычно писать в %SYSTEM% — тогда куча софта с антикварными корнями не могла жить без прав администратора.
Теперь вот это…
allter
Когда появился этот "стандарт", а когда — приложения, использующие $HOME для дотфайлов?
Не нравится — не пользуйтесь этими программами.
dartraiden
Встречал людей, которые возмущались «ах, зачем вы в подкаталог /Libs в каталоге вашей программы добавили целых 10 dll Visual Studio Redistributable суммарным объёмом в целый мегабайт? Ведь у меня эти библиотеки и так установлены в системе!».
Мне кажется, что если человек аж спать не может, зная, что у него там в подпапке, куда ему и заходить-то незачем, целый мегабайт занят ненужными (в конкретно его случае, потому что у кого-то в системе этих библиотек может и не быть) файлами, то это уже из разряда психических отклонений.
immaculate
Смысл в возмущении есть, если файлы пишутся не в системные каталоги, а в каталог пользователя. И мне бардак в моем каталоге тоже не нравится. Не нравятся эти идиотские папки
snap, например, которые еще и не всегда удалить можно.Во-первых, я хочу, чтобы мухи были отдельно, а котлеты отдельно. Не надо мне системных библиотек и так далее в моем домашнем каталоге.
Во-вторых, я хочу, чтобы всякие временные файлы и кэш лежали в четко отведенном месте. Хотя бы для того, чтобы легко можно было исключить их из резервных копий (экономия на месте под бэкапы и время их выполнения, особенно если копирование по сети, особенно, если трафик платный).
А то раньше, мы смеялись над пользователями Windows, с непрозрачным бардаком и бинарной registry, а в итоге пришли почти к тому же самому. Каша из непонятных файлов, которые еще и лежат где бог на душу положит.
Tangeman
Это вопрос задач и личных предпочтений, как мне кажется. К примеру, я предпочитаю переносимые приложения (и на Linux и на Windows), где код, библиотеки и все данные (кроме временных и кэшей, которые можно смело сносить, и соответственно, можно использовать $TEMP) находятся в каталоге самого приложения, чтобы простым копирование можно было сохранить или перенести всё, не рыская по куче разных мест с данными, библиотеками и всем остальным, и не зависеть от неожиданных рантаймов.
Вообще любые (не входящие в систему стандартно) приложения которые требуют установки вызывают зубную боль — потому что установка должна быть эквивалентна распаковке архива, со всем чем нужно внутри, не зависящее от системных библиотек (кроме настолько стандартных, что они с гарантий 101% везде есть и совместимы, разумеется). Такой способ установки удобен ещё и тем что достаточно просто удалить каталог — и вуаля, приложение снесено, без бубна для поиска его остатков в системе (/usr/lib/*, /usr/share/*, /var/lib/* etc, причем не факт что использованные каталоги называются как само приложение).
Что касается yarn/npm etc (о которых говорится в статье) — мне кажется как раз логично что всё что имеет отношение к проекту хранится в его директории, а не хз где по другим «стандартным» местам (опять-таки, кроме временных данных и кэша) — мне не нравится наличие $HOME/.npm, к примеру, я не хочу его общий для всех проектов (да, у меня резиновый диск, могу себе позволить).
Разумеется, у других могут быть другие предпочтения или требования, так что в идеале, каждое приложение должно давать пользователю выбор — использовать установочный каталог как относительный корень для всего (это важно — без абсолютных путей) или «стандартные места», определенные в переменных среды.
math_coder
Моё предпочтение — и даже требование — чтобы предложенного вами выбора не было. Так что ваш «идеал» идеалом, устраивающим всех, заведомо не является.
Tangeman
Было бы интересно узнать, почему вы считаете что выбор — это плохо (при наличии адекватных дефолтов), и особенно почему мой «идеал» может кого-то не устраивать (для них ведь ничего не меняется, если они не делают лишних телодвижений).
Пользователь, как владелец ресурсов, вправе самостоятельно определять где (каталоги), что (данные, код, кэш) и как (файловая система) должно храниться, в то время как для разработчика это всего несколько лишних строк кода.
math_coder
Unix — это добро, не Unix — это зло. В Unix программы ставятся определённым образом (бинарный файл — в /usr/bin или /usr/local/bin, конфиги — в /etc или /usr/local/etc и т. д.). Значит, если где-то происходит не так и программы ставятся каждая в свой каталог — это увеличивает общее количество зла, и нет разницы где рождается зло — на моём компьютере или на компьютере соседа: это всё равно зло.
iig
То есть помойка вида /usr/local/bin/$program_bin добрее, чем /opt/$program_name/$program_bin?
math_coder
То есть в первом случае помойка сильно меньше, и вы выбрали очень удачную запись, при которой это бросается в глаза: в первом случае доллар только один, а во-втором — уже два (а на самом деле их там может быть и больше). Количество нефиксированных элементов пути = величина помойки.
Кроме того, в первом случае вам не надо заботиться о переменной PATH и её значение выглядит вменяемо. Во втором же случае PATH превращается в непотребство и вам надо менять её при каждой установке/удалении программы.
qw1
Думаю, стоит различать программы в стиле unix (netcat, gzip и т.п., состоящие из одного исполняемого файла) и приложения (Adobe Photoshop, Corel Draw и т.п.), у которых десятки, если не сотни исполняемых файлов и библиотек.
Я бы хотел, чтобы у больших приложений файлы лежали сгруппированными по приложению, а не так, что каждое ставило по 40 файлов в bin и по 150 в lib, после чего нереально понять, какой файл поставился с каким приложением.
math_coder
40 файлов в bin — это 40 приложений*, и каждое из них "состоит из одного файла". 150 файлов в lib — это 150 библиотек. Чтобы узнать с каким пакетом поставилось какой-то приложение или библиотека надо подать соответствующую команду менеджеру пакетов.
*Бывают исполняемые файлы, не являющиеся приложениями, но они ставятся не в bin, а в libexec или вроде того.
qw1
Таким образом, приложение оказыватся размазанным по файловой системе — большой файл в bin, много файлов в libexec, где-то ещё может набор файлов с данными/ресурсами, где-то help. А как быстро определить размер, занимаемый приложением на диске?
Насчёт засорения PATH. Я думаю, можно делать симлинки в bin, но это должен делать сам пользователь, понимая, хочет ли он получить эту программу доступной без указания полного пути, или согласен каждый раз набирать полный путь к исполняемому файлу (во втором случае он имеет возможность параллельно поставить несколько версий и явно указывать, какую запускать).
gecube
а еще бывают jarники…
Вот, например, IntelliJIDEA — все прекрасно лежит в отдельном каталоге типа /opt/idea. И я не хочу, чтобы это попадало в системные папки. Unix-style программы, которые часто нужны, и состоят только из одного бинарника — ну, ок, пускай едут в /usr/local/{bin, sbin}, а не в общесистемные каталоги
math_coder
> А как быстро определить размер, занимаемый приложением на диске?
Никак. (А следовательно, это ненужная и вредная операция.)
saboteur_kiev
Многие требуемые библиотеки могут относиться к системным (то есть уже быть), или просто использоваться различными многочисленными пакетами. Поэтому некорректно такие библиотеки считаьт исключительно в это приложение.
Менеджер пакетов может выдавать информацию, что установленная библиотека больше никем не используется и предлагать почистить лишнее.
В винде тоже самое, куча игрушек предлагает поставить DirectX, или .dot фреймворк поновее, причем там еще и проблемы с версиями. Но место под directX никто не считает частью игрушки, и это нормально.
qw1
Тут вопрос — сколько можно освободить места, удалив ту или иную программу. Если все файлы программы в отдельном каталоге, то это гарантированный размер, который станет доступен при удалении каталога.
DirectX — такая ностальгия. По-моему, последний отдельный дистрибутив выходил в 2009 г. (и его включают некоторые игры для совместимости с Windows 7), а дальше версии DX уже входят в поставку Windows и отдельно не устанавливаются.
saboteur_kiev
Ну а в Линуксе до сих пор нет штатной графической либы для всех. Каждый GUI может свой винегрет за собой таскать.
С другой стороны, библиотеки — по современным меркам не такие уж большие.
iig
1000 файлов в одном каталоге (это всего лишь Raspberry) — вполне себе достаточно злая помойка. Какая разница, как они разложены (в одну папку или в 500), если без менеджера пакетов я не могу ни удалить ни один из этих файлов, ни переместить в другое место? И даже о их роли в системе можно только догадываться.
Заботиться о переменной PATH? Пусть о ней заботится тот, кто устанавливает файлы (менеджер пакетов же).
math_coder
На всякий случай я подчеркну ещё раз (а то может показаться, что вы пытаетесь меня в чём-то убедить). Я не исхожу из рациональных соображений. Я иррационально считаю, что делать по-Unix-овски — это хорошо, а отступление от Unix несёт в себе зло. Поэтому попытки меня переубедить, используя рациональные аргументы, заведомо бесполезны.
iig
Я намекаю, что делать по Unix-овски — это тоже плохо.
man hier, который нам диды завещали, не помогает ни место, занятое программой посчитать, ни найти ее данные или конфиги… А раз есть пакетный менеджер — какая тогда разница, где находятся файлы?
ProFfeSsoRr
Вы не умеете пользоваться менеджерами пакетов в линуксе? Иначе непонятно, откуда такое желание вручную что-то переносить и удалять. «Менеджеры пакетов конкретного языка» типа npm ужасны как раз тем, что делают примерно как вам нравится — «давайте засунем и код, и модули в одну папку», и плевать, что потом у юзера домашний каталог на 10% занят его файлами, и на 90% непонятно чем.
Tangeman
Хочу подчеркнуть, я не навязываю никому свою точку зрения — я всего лишь хочу чтобы у пользователей был выбор, в зависимости от их целей, задач и личных предпочтений, а не жёстко установленные кем-то извне (разработчиками, мейнтейнерами систем и пакетов) требования где и что должно находится.
А теперь более подробно.
В идеальном мире, если бы существовал только один менеджер пакетов и один репозиторий для всех существующих в мире программ и библиотек, в котором хранились бы как самые актуальные (стабильные) версии так и все предшествующие, если бы при установке я мог выбирать что куда класть (конфигурации, данные, кэш 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 и прочих анахронизмах, по крайней мере в случаях когда это не цельный проект, зависящий от них.
Надеюсь, я достаточно аргументировал свою позицию?
ProFfeSsoRr
Он существует — pacman, ArchLinux. У него есть архив старых пакетов. Если вдруг из-за новизны системы старый пакет уже не работает — пересобрать пакетом же старый под систему с обновленными либами очень легко.
Shared libs нужны не для экономии места. В первую очередь они уверенность, что используется именно то, что нужно. К примеру я знаю, что версия 1.2.3 имеет эксплоит. И я, установив 1.2.4 с исправлением этого эксплоита уверен, что моя система защищена. А если у меня по системе либ версии 1.2.3 раскидано с разным софтом с десяток, уверенности у меня никакой нет.
Так а зачем, зачем использовать его без sudo? Сложно дописать sudo к команде что ли?
Нормальную систему не надо переустанавливать. В общем попробуйте rolling release дистрибутив, например Arch, избавитесь от многих описанных проблем. Я даже с 32 на 64 без переустановки переходил (сами вспоминайте, сколько ж это лет назад вообще было), а уж нынче я вообще не представляю, зачем что-то переустанавливать на десктопе. А серверы все равно через ansible катятся и там все вышеописанные проблемы отсутствуют или решаются иначе, нежели на десктопах.
Tangeman
Ваше предложение — это как раз уже упомянутый мной «идеальный мир» (отчасти). Осталось убедить моих клиентов (и большинство других) перейти с CentOS/Ubuntu на ArchLinux, и проблема будет решена — как всё просто, оказывается. А ведь именно из-за них мне приходится держать у себя весь этот зоопарк систем.
Впрочем нет, это тоже не решит все проблемы — не все пакеты в ArchLinux есть, не все есть нужных версий (последняя — не всегда нужная), и не все собраны с нужными опциями или дефолтами. Плюс приходится «вручную» думать что можно а что нельзя обновить чтобы ничего не разрушить (такова иногда цена за самые свежии версии в репах, однако).
Это в лучшем случае. А если нужной либы вообще в системе (дистрибутиве) нет? Искать репо где есть и долго думать, доверять ли тому кто её поддерживает? Собирать самому и иметь головную боль по её поддерживания стопятсот лет?
Но всё же, зачем все эти сложности, если «всё в одном каталоге» решает все проблемы без перехода на что-либо? В конце концов, docker создавался для примерно таких же целей, а «всё в одном» это своего рода «docker для бедных» (конечно, чуть менее докер, минус ряд вещей, но всё же идея такая же).
Даже для серверных приложений это иногда очень удобно, в частности, это фишка DotNet Core — «просто скопируй это» — и всё работает.
Попробуйте этот же номер провернуть с чем-то построенном на ruby (например, Discourse) — придётся ставить докер как минимум, чтобы оно гарантированно работало, потому что попытавшись поставить всё вручную вы либо сломаете систему, либо получите неработающее приложение. А ведь как просто было бы просто скачать и распаковать — без бубна и заклинаний.
Так что пожалуйста, создавая какое-либо приложение для масс, подумайте о той части масс которые не хотят сложностей с системой и менеджерами пакетов — это не так уж и сложно, на самом деле, и такое отношение к вопросу тоже имеет право быть.
engine9
Я как-то пытался весь home забэкапить, просто переписав на другой диск. Несколько часов переписывалось и ругалось на кривые имена. Хотя там моих файлов было немного, мегабайт тридцать. Не подозревал СКОЛЬКО там барахла валяется от программ.
Borz
через smb что-ли бекапили?
engine9
Просто копи-паста стандартными средствами.
saboteur_kiev
Стандартные средства, это хотя бы tar, который упростит ситуацию с именами файлов и уменьшит место даже без сжатия. А со сжатием еще и скорость увеличится.
sn00p
dotfiles.github.io вот тут можно поискать вменяемое решение
demitel
Когда-то давно встречал программу под винду, которая хранила свой конфиг на рабочем столе. А если таких «программистов» будет много, представили? Вот что-то подобное автор и описывает.
holomen
Для порядка аналогии — не на рабочем столе, а в Documents. Впрочем, нынче так и делается. Еще и с точкой в начале — для совместимости, наверное…
batyrmastyr
Автора бесит, что на винде с идиотами засирающими корень диска C: уже давно справились, а в линуксе они серют и серют.
Borz
в Linux в корень перестали срать гораздо раньше
Areso
Э не, тут скорее аналог AppData (между прочим, тоже находящемся в папке пользователя)
Evengard
скорее C:\users\username. А автор как раз ратует за то чтоб пользовались appdata.)
fesst
Ну, я в своём c:\users\ никогда не знал, что происходит, честно говоря. А файлы тоже раскиданы: что-то падает в %userprofile%/Downloads, что-то в %userprofile%/Documents, так что тоже тот ещё бардак. Было бы удобнее наоборот — корень мой, а всё системное — в соседней папке.
Areso
Толку, если она все равно будет в хомяке?
Да, вместо десятков файлов и папок, оно будет лежать в одной подпапке. Подпапке хомяка.
C:\Users\username\AppData
sumanai
Так ровно тоже самое предлагает инициатива из топика, только там чуть больше директорий от корня хомяка.
vlivyur
А давно ли Oracle перестал это делать?
werewol
А перестал? Оо
vlivyur
Я года три их не трогал, так что не в курсе.
mayorovp
На винде была и остаётся проблема с засиранием профиля пользователя. Причем главные «засиратели» — портированные с линукса программы, которые не в курсе про подкаталоги AppData\Local и AppData\Roaming
Причём в последнее время к ним добавились ещё и кроссплатформенные программы от самих Microsoft…
sumanai
Больше всего там бесят исполняемые файлы. Настраиваешь себе SRP, настраиваешь, а какой-нибудь uTorrent так и норовит в профиль залезть.
sumanai
Эх…
Al_Azif
Из последнего — nVidia стала месяц назад создавать пустой «C:\NVIDIA Corporation\umdlogs». Накой хрен он мне на корне в C:\ — вопрос наверное к тем особым программистам, которые и инсталлеры в C:\ распаковывают…
vlivyur
C:\MSOCache туда же. И PerfLogs наверно тоже. Инсталляторы/обновляторы от MS тоже любят создать пару зубодробительных каталогов в корне диска и забыть удалить их.
sumanai
С инсталляторами от МС ещё весело, они они создают каталоги в корне самого свободного диска. А это далеко не всегда системный.
D01
Не только в Linux, но и в MacOS тоже…