Комментарии 339
Автора возмущает, что при наличии стандарта, разработчики этот стандарт игнорируют или не знают о нём. В итоге имеем неконтролируемый беспорядок в домашней директории, так как порой пути к конфигам жёстко прописаны в исходниках.
Если зависимость выкачивается куда положено, а не создаёт (условно) в корневой директории поддиректорию, куда сваливает всё подряд, то всё в порядке.
Мне кажется, что если человек аж спать не может, зная, что у него там в подпапке, куда ему и заходить-то незачем, целый мегабайт занят ненужными (в конкретно его случае, потому что у кого-то в системе этих библиотек может и не быть) файлами, то это уже из разряда психических отклонений.
Смысл в возмущении есть, если файлы пишутся не в системные каталоги, а в каталог пользователя. И мне бардак в моем каталоге тоже не нравится. Не нравятся эти идиотские папки snap, например, которые еще и не всегда удалить можно.
Во-первых, я хочу, чтобы мухи были отдельно, а котлеты отдельно. Не надо мне системных библиотек и так далее в моем домашнем каталоге.
Во-вторых, я хочу, чтобы всякие временные файлы и кэш лежали в четко отведенном месте. Хотя бы для того, чтобы легко можно было исключить их из резервных копий (экономия на месте под бэкапы и время их выполнения, особенно если копирование по сети, особенно, если трафик платный).
А то раньше, мы смеялись над пользователями Windows, с непрозрачным бардаком и бинарной registry, а в итоге пришли почти к тому же самому. Каша из непонятных файлов, которые еще и лежат где бог на душу положит.
Вообще любые (не входящие в систему стандартно) приложения которые требуют установки вызывают зубную боль — потому что установка должна быть эквивалентна распаковке архива, со всем чем нужно внутри, не зависящее от системных библиотек (кроме настолько стандартных, что они с гарантий 101% везде есть и совместимы, разумеется). Такой способ установки удобен ещё и тем что достаточно просто удалить каталог — и вуаля, приложение снесено, без бубна для поиска его остатков в системе (/usr/lib/*, /usr/share/*, /var/lib/* etc, причем не факт что использованные каталоги называются как само приложение).
Что касается yarn/npm etc (о которых говорится в статье) — мне кажется как раз логично что всё что имеет отношение к проекту хранится в его директории, а не хз где по другим «стандартным» местам (опять-таки, кроме временных данных и кэша) — мне не нравится наличие $HOME/.npm, к примеру, я не хочу его общий для всех проектов (да, у меня резиновый диск, могу себе позволить).
Разумеется, у других могут быть другие предпочтения или требования, так что в идеале, каждое приложение должно давать пользователю выбор — использовать установочный каталог как относительный корень для всего (это важно — без абсолютных путей) или «стандартные места», определенные в переменных среды.
Пользователь, как владелец ресурсов, вправе самостоятельно определять где (каталоги), что (данные, код, кэш) и как (файловая система) должно храниться, в то время как для разработчика это всего несколько лишних строк кода.
Кроме того, в первом случае вам не надо заботиться о переменной PATH и её значение выглядит вменяемо. Во втором же случае PATH превращается в непотребство и вам надо менять её при каждой установке/удалении программы.
Я бы хотел, чтобы у больших приложений файлы лежали сгруппированными по приложению, а не так, что каждое ставило по 40 файлов в bin и по 150 в lib, после чего нереально понять, какой файл поставился с каким приложением.
40 файлов в bin — это 40 приложений*, и каждое из них "состоит из одного файла". 150 файлов в lib — это 150 библиотек. Чтобы узнать с каким пакетом поставилось какой-то приложение или библиотека надо подать соответствующую команду менеджеру пакетов.
*Бывают исполняемые файлы, не являющиеся приложениями, но они ставятся не в bin, а в libexec или вроде того.
Насчёт засорения PATH. Я думаю, можно делать симлинки в bin, но это должен делать сам пользователь, понимая, хочет ли он получить эту программу доступной без указания полного пути, или согласен каждый раз набирать полный путь к исполняемому файлу (во втором случае он имеет возможность параллельно поставить несколько версий и явно указывать, какую запускать).
Вот, например, IntelliJIDEA — все прекрасно лежит в отдельном каталоге типа /opt/idea. И я не хочу, чтобы это попадало в системные папки. Unix-style программы, которые часто нужны, и состоят только из одного бинарника — ну, ок, пускай едут в /usr/local/{bin, sbin}, а не в общесистемные каталоги
Никак. (А следовательно, это ненужная и вредная операция.)
Менеджер пакетов может выдавать информацию, что установленная библиотека больше никем не используется и предлагать почистить лишнее.
В винде тоже самое, куча игрушек предлагает поставить DirectX, или .dot фреймворк поновее, причем там еще и проблемы с версиями. Но место под directX никто не считает частью игрушки, и это нормально.
DirectX — такая ностальгия. По-моему, последний отдельный дистрибутив выходил в 2009 г. (и его включают некоторые игры для совместимости с Windows 7), а дальше версии DX уже входят в поставку Windows и отдельно не устанавливаются.
С другой стороны, библиотеки — по современным меркам не такие уж большие.
Мне какая-то программа недавно заказала DX и отказалась ставиться. Win7 или 10 — не помню.
Это неважно. Есть много программистов которые не соблюдают стандарты и рекомендации. Есть много программ, которые были написаны еще для 9x линейки и до Vista/win7. Ваш единичный случай просто исключение, которые будут всегда.
Но в Линукс просто нет единых рекомендаций и стандартов, вдобавок этих единых рекомендаций в ближайшее время не ожидается, потому что дистрибутивов много, шанс что они все договорятся — минимальный
ls /usr/bin/ | wc -l
916
1000 файлов в одном каталоге (это всего лишь Raspberry) — вполне себе достаточно злая помойка. Какая разница, как они разложены (в одну папку или в 500), если без менеджера пакетов я не могу ни удалить ни один из этих файлов, ни переместить в другое место? И даже о их роли в системе можно только догадываться.
Заботиться о переменной PATH? Пусть о ней заботится тот, кто устанавливает файлы (менеджер пакетов же).
На всякий случай я подчеркну ещё раз (а то может показаться, что вы пытаетесь меня в чём-то убедить). Я не исхожу из рациональных соображений. Я иррационально считаю, что делать по-Unix-овски — это хорошо, а отступление от Unix несёт в себе зло. Поэтому попытки меня переубедить, используя рациональные аргументы, заведомо бесполезны.
А теперь более подробно.
В идеальном мире, если бы существовал только один менеджер пакетов и один репозиторий для всех существующих в мире программ и библиотек, в котором хранились бы как самые актуальные (стабильные) версии так и все предшествующие, если бы при установке я мог выбирать что куда класть (конфигурации, данные, кэш 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 и прочих анахронизмах, по крайней мере в случаях когда это не цельный проект, зависящий от них.
Надеюсь, я достаточно аргументировал свою позицию?
если бы существовал только один менеджер пакетов и один репозиторий для всех существующих в мире программ и библиотек, в котором хранились бы как самые актуальные (стабильные) версии так и все предшествующие
Он существует — pacman, ArchLinux. У него есть архив старых пакетов. Если вдруг из-за новизны системы старый пакет уже не работает — пересобрать пакетом же старый под систему с обновленными либами очень легко.
но сейчас можно себе позволить не думать о shared libs и прочих анахронизмах
Shared libs нужны не для экономии места. В первую очередь они уверенность, что используется именно то, что нужно. К примеру я знаю, что версия 1.2.3 имеет эксплоит. И я, установив 1.2.4 с исправлением этого эксплоита уверен, что моя система защищена. А если у меня по системе либ версии 1.2.3 раскидано с разным софтом с десяток, уверенности у меня никакой нет.
невозможность использования менеджера пакетов обычным пользователем
Так а зачем, зачем использовать его без sudo? Сложно дописать sudo к команде что ли?
сюда входит также возможность полной переустановки системы (или её апгрейда)
Нормальную систему не надо переустанавливать. В общем попробуйте rolling release дистрибутив, например Arch, избавитесь от многих описанных проблем. Я даже с 32 на 64 без переустановки переходил (сами вспоминайте, сколько ж это лет назад вообще было), а уж нынче я вообще не представляю, зачем что-то переустанавливать на десктопе. А серверы все равно через ansible катятся и там все вышеописанные проблемы отсутствуют или решаются иначе, нежели на десктопах.
Впрочем нет, это тоже не решит все проблемы — не все пакеты в ArchLinux есть, не все есть нужных версий (последняя — не всегда нужная), и не все собраны с нужными опциями или дефолтами. Плюс приходится «вручную» думать что можно а что нельзя обновить чтобы ничего не разрушить (такова иногда цена за самые свежии версии в репах, однако).
К примеру я знаю, что версия 1.2.3 имеет эксплоит. И я, установив 1.2.4 с исправлением этого эксплоита уверен, что моя система защищена.
Это в лучшем случае. А если нужной либы вообще в системе (дистрибутиве) нет? Искать репо где есть и долго думать, доверять ли тому кто её поддерживает? Собирать самому и иметь головную боль по её поддерживания стопятсот лет?
Но всё же, зачем все эти сложности, если «всё в одном каталоге» решает все проблемы без перехода на что-либо? В конце концов, docker создавался для примерно таких же целей, а «всё в одном» это своего рода «docker для бедных» (конечно, чуть менее докер, минус ряд вещей, но всё же идея такая же).
Даже для серверных приложений это иногда очень удобно, в частности, это фишка DotNet Core — «просто скопируй это» — и всё работает.
Попробуйте этот же номер провернуть с чем-то построенном на ruby (например, Discourse) — придётся ставить докер как минимум, чтобы оно гарантированно работало, потому что попытавшись поставить всё вручную вы либо сломаете систему, либо получите неработающее приложение. А ведь как просто было бы просто скачать и распаковать — без бубна и заклинаний.
Так что пожалуйста, создавая какое-либо приложение для масс, подумайте о той части масс которые не хотят сложностей с системой и менеджерами пакетов — это не так уж и сложно, на самом деле, и такое отношение к вопросу тоже имеет право быть.
и не все собраны с нужными опциями или дефолтами
Ну эта проблема может быть всегда, «не нравится чужое — компилируй сам».
решает все проблемы
Не решает это проблемы наличия небезопасных версий библиотек в комплекте. Потому что отслеживать их все руками. Если посмотреть на работу инфрраструктурой контейнеров — там вот проверка их всех на наличие известных уязвимостей достаточно острая тема. Сначала все бросились делать контейнеры, а теперь вот наконец задумались об уязвимостях либ.
подумайте о той части масс которые не хотят сложностей с системой и менеджерами пакетов
С менеджерами пакетов сложностей нет. Те, кто не хотят сложностей с системой — используют менеджеры пакетов. А вы как раз идете по достаточно сложному пути, с телодвижениями, которых можно избегать.
Осталось убедить моих клиентов
А в чем проблема? Если вы понимаете преимущества — вы их и клиентам объясните. А если не понимаете… ну тогда или поймите, или живите как привыкли.
через smb что-ли бекапили?
в Linux в корень перестали срать гораздо раньше
скорее C:\users\username. А автор как раз ратует за то чтоб пользовались appdata.)
Да, вместо десятков файлов и папок, оно будет лежать в одной подпапке. Подпапке хомяка.
C:\Users\username\AppData
Причём в последнее время к ним добавились ещё и кроссплатформенные программы от самих Microsoft…
Эта статья должна занять первое место в зале бессмысленности гугл-транслейта.
Такое впечатления, что западные авторы (не в значении «авторы учебников», а в значении «кому не лень написать рефлексию») чаще задают себе вопрос "а почему оно так?" Русскоязычная публика (ок, ex-USSR-users), как кажется, более привычна к «сказано делать так — так и будем».
P.S. Следствие, кстати — это когда мудрый админ насаждает среди юзеров «так делать правильно», но почему правильно — сказать не может. Привык он, понимаешь! Потом получаются почтовые ящики вида ivanov_ve@mx.company.ru, и веб-сайты, которые отзываются только на www.company.ru (т.е. без www не откроешь).
Оно же и субдомен для типового MX-сервера.
— у вас есть ваша организация, и все, что в ней, вы считаете «своим», «вашим доменом». Под это дело выделяем домен, скажем, 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, зато надежно же!
Меня вообще, работать в /home/username/ в принципе не устраивает. И так как на мои компьютеры работаю только я, то делаю так — выделяю два раздела по 50ГБ под ОС (так могу экспериментировать с разными дистрибутивами), а все остальное пространство диска выделяю под раздел который монтирую как /work
И так как Linux вообще не знает о нем, то и никогда туда ничего не пишет. Дополнительный плюс это то, что файлы доступные одновременно в двух ОС (дот файлы не позволяют монтировать этот раздел как /home/username). Ну, и мигрировать на новый компьютер/диск легче.
Меня вообще, работать в /home/username/ в принципе не устраивает.
А что за работа такая «в /home/username/» и что именно не устраивает?
Ну, и мигрировать на новый компьютер/диск легче.
Легче, чем что? У меня home отдельным разделом монтируется. Если решил поменять систему — форматнул / и накатил новую, Подцепил home и, как будто, ничего и не происходило. Все настройки на месте. Правда проблему срача в home это не решает :(
И весь мусор тоже там будет. И заметьте в новой ОС, программы эти может и не быть, а то что они оставили в /home/ останется и отделить нужное от ненужного, невозможно в принципе. Бардак с времени будет только увеличиваться, но никак не уменьшатся. Именно поэтому я так не делаю.
Просто тут только 2 варианта, либо разбирать/чистить, либо терять все настройки. Но второе по мне — не всегда удобно. Например профили браузера терять неприятно.
Конечно всегда можно почистить вручную, но в моей /home 75000 файлов, которые не я там записал, а система/программы. А в /work около миллиона файлов, которые записал там я и которые более или менее мне нужны. Понимаете, что сортировать все это вручную просто нереально.
Да, в вашем случае явно требуются особые меры. Кстати 1М файлов система вообще нормально держит? Тем же даже открытие файлов уже подлагивать может. Или используется какая-нибудь серверная фс?
20? Этого не может быть. Все конфиги и кеши браузера будут намного больше. Попробуйте так:
find ~ -type f | wc -lНо если считать все файлы вообще, то да, там один профиль фоксы потянет… хз, но прилично потянет. Ради интереса вечером гляну.
Если кратко, то home это место где юзеру соблаговолили доступ на запись и место, где он повседневно должен работать (если пользователь так же является администратором, то он тоже должен сидеть в хомяке, используя root, только для администрирования.)
В реально многопользовательском Linux папка home — единственное место, где пользователь может хранить файлы.
А ещё эти два пути имеют одно принципиально различие, из-за которого первый (/tmp) адекватно рамить, а второй (/var/tmp) — нет
Созданные файлы и каталоги в /tmp может удалить только владелец благодаря флагу sticky bit на /tmp
но вот внутри подкаталогов — зависит от umask
Сталкивался со реальным спамом файлами .serverauth.##### в home.
>Потому что она в 99% случаев лежит на том же разделе
Ну да. Одно дело — личные компьютеры, но мне попадалось удивительно мало систем во всяческих конторах и даже компаниях, которые бы выбивались из этих 99%…
Потому что она в 99% случаев лежит на том же разделе, что и система, и при переустановке всё может уничтожиться?
Потому что до висты она называлась "C:\Documents and Settings\<user>\Мои документы", и из-за русских буков в названии половина программ отказывалась с ней работать. Это если не вспоминать о пробелах в названии, с которыми не может работать каждый первый батник...
является ли получившийся граф ациклическим.Нет, потому что
C:\Users\Name\AppData\Local\Application Data → C:\Users\Name\AppData\Local
Но спасает, что длина пути не более MAX_PATH=260 знаков (если не использовать префикс \\?\), поэтому рекурсивный поиск не зацикливается, а останавливается на некоторой глубине.
Именно потому что директория нестандартная. Так как Linux ничего не знает про нее, есть гарантия что никакая программа не будет просто так писать туда, потому что так захотелось программистам. И вообще, все современные ОС считают что файловая система принадлежит им и пользователь должен сидеть в углу и не рыпаться. Всякие программы тоже так думают и работают.
А мне нравится наоборот — пусть ОС сидит там где ее поставили, а все остальное мне. :D
Только, если так, то Линукс будет знать что это моя "домашняя директория" и здравствуйте дот файлы, кеши, теща и вся родня. :P
Спасибо за пример решения! Очень интересное.
По такому же принципу использую отдельный диск, который доступен и на винде тоже.
Занимаюсь монтажом видео в свободное время и, когда есть вдохновение, так что, нужна винда :)
Директория $HOME используется, как мусорка по причине, описанной в статье.
Нет, "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, /"
cd ~
ls -a
Кстати, ради прикола посмотрел сейчас в QSettings — уж казалось бы, вот они, best practices в полный рост. А присмотришься — они тоже по умолчанию пишут в $HOME/.config/что-то-там, даже если задана переменная XDG_CONFIG_DIRS. Вот если переменная задана, и нужные подкаталоги и файлики уже присутствуют — тогда QSettings будет использовать их. А без этого — нагадит в $HOME.
Рекомендации — о-о-о, их есть много всяких разных, включая запись конфигов в xml или вообще в аналог реестра в бинарном формате. Не факт, что попадется правильная.
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Отлично. Но путей для настройкопомойки тоже нет, я бы даже не подумал разбираться с ними
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/.
Поэтому все эти переменные с путями и не определены обычно.
NETBUG-MBP
Так у вас наверно ~/Library/Application\ Support для этого есть? :-)
Надеюсь, когда-нибудь кто-нибудь из тех, кто бездумно кидается использовать любую новую фичу, будет для начала думать о том, как внедрить её красиво и чего это будет стоить.
Эта проблема, увы, не только разработчика, в NodeJS вот так. 300MB — это еще хорошо. В кровавом энтерпрайзе и 1.5GB+ видели...
проект, весом в пару мегабайт от силы, который грузит для своей работы 300 метров в папку node_modules
Напоминает выпуск Ералаша про умные часы.
https://www.npmjs.com/package/isarray 19.5kk загрузок в неделю.
А тут дело не в качестве, а в количестве, теперь представьте, что этот пакет подтягивается как зависимость разных ваших зависимостей несколько раз.
Решили вы заюзать express, там 30 зависимостей, но в сумме будет загружено свыше 100 пакетов, учитывая зависимости зависимостей. И это без dev зависимостей.
Как правило у вас не одна зависимость. Вот так и получается, что количество пакетов растет экспоненциально. Причем абсолютная часть того, что вы загрузите — это просто занятые inode, не более того.
Пример с isarray я привел для того, что бы показать то, что пакеты довольно часто очень маленькие, а многие из авторов вместо того, что бы написать у себя функцию на этих же 5 строк предпочитают загрузить пакет. NPM и left-pad: мы разучились программировать?
… Но вебпак включит его в сборку единственный раз.
И причем тут webpack? Речь про node_modules.
… И если каждый напишет самостоятельно, то эта функция будет в финальной сборке повторяться столько раз, сколько раз её написали.
Собсно и чо?)) Да, будут повторяться, причем для каждого случая это будет заточенная функция под конкретный случай. Если для вас N зависомостей предпочтительней, чем N функций — это печально.
почти все зависимости установились плоско
Круть, только это стечение обстоятельств. Общий размер 2.4 мб
Собсно потом не кричите, что у вас скрипты в браузере раздуты.
Вы сейчас сравниваете мягкое и зеленое. Webpack что научился вычленять только используемую функциональность из подтягиваемых пакетов? Например если требуется пара функций из underscore — тянуть пакет более затратно, чем написать эти несчастные пару функции.
Например если требуется пара функций из underscore — тянуть пакет более затратно, чем написать эти несчастные пару функции.
… и именно по этой причине существует куча пакетов, состоящих из одной-единственной функции. Именно для того, чтобы даже самый глупый webpack не затянул в бандл ничего лишнего.
Именно для того, чтобы даже самый глупый webpack не затянул в бандл ничего лишнего.
Вам не кажется, что овчинка вычинки не стоит?
Доп. зависимость — это:
- потенациальная уязвимость, особенно учитывая последние фейлы npm
- куча мета данных, описывающих сам пакет, которые просто будут раздувать node_modules
- код другого вендора, который может в принципе забить на ошибки, или наплевать на обратную совместимость, или еще чего.
Если для вас важнее размер того, что напакует webpack — ну что ж, могу вам только удачи пожелать.
Это не стечение обстоятельств, а оптимизация.
Если одна из зависимостей требует одну версию, а другая — другую — то у вас загрузится таки 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 разрабатывался, но это мои влажные фантазии.
Итак, что же мы имеем по ущербу
Имеем то, что чем больше у вас зависимостей других вендоров — тем более вероятны проблемы с безопасностью / работоспособностью.
В любом случае, метаданные весят незначительно относительно кода библиотек.
Неа, я ж сбросил пример пакета, доп данных в нем, по сравнению с рабочим кодом больше на порядок. У меня складывалось впечатление, что вы как раз такое и отстаиваете.
Если размещать каждую из зависимостей отдельно, то упадёт скорость загрузки.
HTTP2 уже ж придумали.
CDN сильно снижает скорость доставки контента и создаёт лишнюю точку отказа.
Видимо не умеете готовить.
Насколько я понимаю устройство ноды, фактически под требование подходит любой проект, который по тем или иным причинам не использует run build. Хз как такое нагуглить. Мне лично вообще этот подход претит, плюс я не большой знаток ноды.
Просто констатирую общую тенденцию. Честно говоря, я до последнего времени даже не думал, что это общепринятая практика, считал, что так конкретным разработчикам было проще проект настраивать.
И в данном случае сложно разделить на фронт\бэк. В описываемой концепции за роутинг отвечает нода, она же генерит для клиента весь код «фронта» и выплёвывает его браузеру единым куском. Я затрудняюсь сказать, где тут фронт заканчивается, где бэк начинается.
К примеру, в проекте с которым я сейчас работаю, для MVP проекта UX-дизайнерами отрисовано больше двух сотен экранов.
В том-то и абсудр, что подобное делается по концепции SPA.
И да, пользователю нода, конечно, не грузится. Но некоторые модули вполне могут — тут всё зависит от проекта и фич, которые захотел использовать разработчик.
Webpack, babel… Ок, к ним вопросов нет, допустим.
Вопросы есть к паре десятков других модулей, которые тянутся в зависимостях.
Как вам, например, две версии Bootstrap, потому что одну из них требует один из используемых компонентов (datepicker), а зависимость указана строго, а вторая используется в проекте для сетки. Я молчу уж про то, что меня от самого бутстрапа воротит (там полная шизофрения в стилях), но неужели сетку-то нельзя было руками прописать?
Ну и в таком духе.
Тут диллема такая, что если ты используешь подобную концепцию в разработке — то ты либо обрекаешь себя на кучу дополнительной работы по вычищению кода (которую большинство, очевидно не делает), либо генерируешь тонны мусора, помимо полезного контента.
А так то такие «проблемы» у каждого нормального пакетного менеджера. Он должен хранить модули только для одного проекта, ведь в другом будут и версии библиотек другие и вообще всё другое.
берёте reg.exe и делаете почти тоже самое, что и через grep
после выгрузки в .reg файлы вы можете с ними делать всё то же самое, что и с .cfg и прочими "текстовыми" конфигами, вплоть до инкрементального бекапа
Fix (убрал курсив):
после выгрузки в *.reg файлы вы можете с ними делать всё то же самое, что и с .cfg и прочими "текстовыми" конфигами, вплоть до инкрементального бекапа
Хотя единственный существенный недостаток — реестр в VSC вроде как не помещается. А так… скрипты из малвари давным-давно научились легко и непринужденно править реестр.
нет рабочего стола или какого-то десктопа.
Зачем в таком случае ставить Steam?
Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock
Такое ощущение, что автор статьи просто запускает команды, которые он не понимает, потом удивляется.
У меня в каталоге тысяч сто файлов в разного рода директориях, начинающихся с точки. Их можно контролировать, как хочет автор, но зачем?
«Делайте что-то одно, но делайте это хорошо». Кто же виноват, что с каждым днем задачи усложняются, количество информации увеличивается, количество софта и утилит тоже, все в соответствии с принципами.
Это не отменяет рукожопость многих разработчиков, но в целом все выглядит куда лучше, чем сто тысяч хрен пойми каких dll в другой операционной системе.
Или просто запускать стим в своём x-server без графического менеджера, который окошки таскать мышкой позволяет.
Есть графическая среда, есть и десктоп. Ярлыки можно там не создавать, десктопом он разве перестанет быть?
Если пользоваться вашим определением, то десктоп у меня конечно есть. Правда, я его никогда не вижу, ибо тайловый менеджер всегда закрывает его окнами. Но «ярлыки» он отображать не умеет в принципе.
Зачем в таком случае ставить Steam?
Чтобы запустить выделенный сервер какой-нибудь игрушки?
Только весь прикол стима в другом немного, а оно не заработает без полноценного десктопа. Ну да ладно, может сейчас и по-другому, давно не играл.
В маке разве не ~/Library/My App, ~/Library/Caches/My App/, ~/Library/Preferences/com.example.myapp.plist по гайдлайнам/документации?
но это не переменные из статьи.
А в Windows свои пути, про которые тоже надо знать
но стандарт говорит про "если переменных нет, то используйте вот такие пути", которые совершенно не такие для Windows и MacOS.
Вот если бы стандарт говорил, что эти переменные обязаны быть в ОС, сродни, как сейчас известно, что есть $HOME и $TMPDIR и их получение присутствует практически во всех нормальных языках, то имело бы смысл наезжать на разработчиков прикладного ПО, что они их не используют.
И этих каталогов даже не только в стандарте FHS 3.0 нет, но и в её dev-версии. Но зато там есть описание как раз про создание dot-каталогов в хомяке
да, но это уже порождает в коде конструкции типа
if(os == "Mac") {
// что-то
} else if(os == "Windows") {
// еще что-то
} else {
// и еще
}а это уже выглядит не так удобно, как прочесть нужный путь из переменной.
на самом деле, не сказать чтобы сильно усложняло.
На этапе инициализации приложения инициируете пути до каталогов на основе ОС в которой запустились. А потом уже используете инициированные переменные в коде. Ведь вряд ли ОС поменяется в процессе работы приложения, а значит и пути "внезапно" не изменятся.
но при этом, они реализовали возможность переместить каталог в другое место: https://github.com/tmux/tmux/issues/142#issuecomment-330558015
т.е. всё что осталось — запрограммировать вычисление этой переменной на этапе запуска. Это OpenSource — каждый может пойти и сделать Pull Request на эту реализацию
когда пишешь кроссплатформенное приложение, то у тебя есть два пути:
1) не мудрствовать и везде брать "$HOME/.myAppDir"
2) смотреть как в каждой ОС реализовано хранение данных и реализовывать отдельный код сугубо под эту ОС. Необходимо как минимум 3 способа — для MacOS, *nix и для Windows. Более того — ещё учесть, что в каждой ОС есть или нет разделение на "конфиги", "кеши" и т.п., что ещё больше усложняет программу в этом куске
Скажите, какой путь скорее всего выберут "на старте" разработки?
Каталоги с точкой вначале потому и делают, чтобы вам они не мешали в обычном режиме "не показывать скрытые файлы".
А в остальном — какая разница где лежит файловая помойка — как отдельный "скрытый" каталог в $HOME или как несколько каталогов в разных местах?
И да, что проще почистить при удалении программы — 1 каталог или кучку?
disclaimer: я не ратую за реализацию каталогов в хомяке, но лишь показываю почему это делают чаще чем хотелось бы.
Скажите, какой путь скорее всего выберут «на старте» разработки?
Многие программы с чего-то начинали, но пора из колыбели вылезти.
tmux с 2007 года пилится, а он всё равно конфиг только в $HOME/.tmux видит без костылей
Tmux OpenSource — можно пойти и исправить это.
Тем более, что поправить параметр в настройках вроде как не такой уж большой костыль.
1) не мудрствовать и везде брать "$HOME/.myAppDir"
Всё бы хорошо, но на Windows файлы, начинающиеся с точки, скрытыми не считаются
3) найти язык или библиотеку, которая все пути определит сама. Казалось бы, фреймворков для написания кросс-платформенных программ развелось немеряно — вот бы туда что-нибудь добавить уже...
(достаёт попкорн)
А куда в Windows писать? %userprofile%\\.appdir? %appdata%\\appdir? Некоторые гадят еще и в %userprofile%\\documents
Ну, или для классических Win32-приложений, ShGetKnownFolderPath
allusersprofile
userprofile
appdata
programdata
commonprogramfiles
programfiles
public
И любимый C:\Documents and Settings\
А внутри выбираем уже по своему вкусу.
You need to sign in to see this page.
(кидает палку в огород линукс-пользователей с криком: «Вы изговняли мне винду. Хады!»)
Так они вроде универсально создаются, разве нет? Именуются с точкой и ставится флаг "hidden" для тех, кто точку не понимает.
Вот та штука, которая эмулирует POSIX, могла бы и выставлять флаг Hidden при создании файлов и папок начинающихся с точки.
Файлы в POSIX не скрытые, а «не пользовательские», поэтому умышленно их никто не скрывает. В то время как если их скрыть, то еще непонятно, как себя может повести различный софт.
Например вдруг какой-нить виндовый backup по дефолту не будет бэкапить скрытые файлы?
Или наоборот, в линуксе в некоторых случаях wildcard может пропускать dotfiles, а в windows не будет.
Поэтому зачем брать на себя ответственность интерпретации чего-либо в другой системе, если стандарты напрямую не сравниваются?
Так речь и не про линукс.
а почему бы не — программе можно не более чем пользователю?
Не существует «злых программистов», потому что без «злых программистов» у пользователя будет коробочка, которая даже вентилятор сама включить не может, не то, чтобы помигать курсором на экране.
в android есть некоторые приватные каталоги программы это меня радует.
ЗЫ
Не существует «злых программистов», потому что без «злых программистов» у пользователя будет коробочка, которая даже вентилятор сама включить не может, не то, чтобы помигать курсором на экране.
я реально в шоке от подобного выверта логики. можно я тоже попробую: мошенников не существует потому что есть банковская система!
UPD: В мире свободного ПО. Что там винда принудительно ставит — это я уже не знаю.
практика показывает что программы действуют от программиста. :(
а почему бы не — программе можно не более чем пользователю?
Потому что для вас пользователь и программист — это слова в русском языке.
А для системы — это UID, и с этой точке зрения программе уже можно не более чем пользователю.
Когда контейнер завершит работу — удаляем. Или запускаем снова. При этом конфигурационные файлы не будут видны на хосте.
Под линуксом запускал и десктопные приложения в таком виде когда боролся с проблемами совместимостей библиотек. На винде тоже можно, но не пробовал.
Ваша спецификация — гвн (с) самизнаетекто.
От того, что все дерьмо из $HOME/.* раcкидают по другим директориям, оно не перестает быть дерьмом. Особенно примечательно, когда пакет/программа удаляется, а ее отложенные личинки еще по всему дереву собирать приходится. К тому же давно пора проапдейтить package manager, чтобы при удалении подчищал за собой.
… Можно ещё подумать о том, что должно стать с репозиториями при удалении git'а.
Данные — это результат моей работы, и я хочу:
- точно знать где и что лежит, а не шариться по диску, ища кто, что и где сохраняет
- указать где их надо создавать, хотя бы при первом запуске программы
- держать независимо от основной программы
- делать бекапы и прочее
Все остальное, включая конфиги программы, кеши и индексы — это мусор, который всегда можно преспокойно снести, либо для особо одаренных предложить опцию.
Что мы имеем, благодаря данному "стандарту" — это очередной набор помоек, куда каждый будет сваливать что хочет. В моем .local/share сейчас 63 директории, включая data/LibreCad, ibus-table, xorg, gegl-0.2, gegl-0.3, и прочая херь, которая бесполезна и остается после сноса программы, и рядом с которой я не хочу держать действительно важные для меня данные.
sudo apt-get purge --autoremove my-app ?
.bash, .inputrc, .git, .gitignore, .XXX все идут в $HOME. Бардак в том, что нет системы .app/package.name/.myfiles.
а они не GUI приложения — почему они должны как-то смотреть на стандарты для GUI?
Кстати, на линуксах эти файлы меньше режут глаз, т.к. обычно скрыты (и обычно игнорируются glob'ом).
не есть правильно, что консольное ПО будет использовать константы от GUI. F префикс "XDG_" — это про GUI
тогда уж логичнее завести константы USER_CONFIG_HOME, USER_DATA_HOME и USER_CACHE_HOME и пользовать их
Вы можете легко перенести существующие программы на использование этого стандарта. Для этого при создании новых файлов начните использовать стандарт, но продолжайте проверять старое расположение файлов при их чтении. Это позволит выполнить миграцию, не нарушая работу программы для пользователей с файлами конфигурации или данными, созданными предыдущей версией программы.
Неужели "монстры" не осилят?
Ну представьте себе перенос ~/.ssh/authorized_keys в ~/.config/ssh/authorized_keys. Взорвётся пол-интернета из-за сломавшихся систем деплоя и аудита.
Ну так а симлинки никуда же не денуться. Главное разумно их задепрекейтить в дистрибутивах — сначала даем симлинки, затем переписывает тот софт, что дистрибутив мейнтейнит, затем отменяет симлинки, с возможностью поставить переходные пакеты, их возвращающие
Я вижу другую проблему: симлинки — такой же мусор, и с такими же недостатками.
Только временный для возможности миграции. В следующем LTS его, конечно же, нужно выпилить
При смене местоположения можно же и симлинк переназначитьИ как это нас приближает к новому стандарту? К примеру, пользователь переместил настройки в другое место и соответственно изменил переменную окружения. Все симлинки превратились в тыкву, софт потерял настройки.
Не так сложно представляем этот перенос. Во многих дистрибутивах уже отказались, например, от /bin в пользу /usr/bin, а /bin теперь — симлинк
Git давно поддерживает XDG. Вместо ~/.gitconfig можно использовать ~/.congig/git/config
поддерживают, но он вторичен: https://git-scm.com/docs/git-config#git-config-XDGCONFIGHOMEgitconfig
и чтобы конфигурация записалась именно в него, его надо сперва создать явно: https://git-scm.com/docs/git-config#git-config---global
а почему бы не — программе можно не более чем пользователю?
Учитывая, что пользователь это тоже программа, нужно переделать всю модель безопасности.
Возможно, это и определяет количество .files, они не-десктопными приложениями приносятся. Мне кажется, это архитектурная ошибка, и тяжёлое легаси, которое очень трудно исправить (т.к. софта много, и он очень сильно старый с мощной userbase, так что причин меняться нет).
у этих переменных "есть" значения по-умолчанию.
Но согласен с janatem — получается, что графические софтины должны учитывать эти переменные, а консольные нет. Но идёт дальше — а если у софтины есть и GUI и CLI версия, то как ей быть? Приоритет на CLI? А если я поставил только GUI вариант, а CLI нет, то всё равно должна учитываться только CLI особенность? Не удобнее ли просто сразу смотреть только в одном место без учёта — иксы это или нет?
А какой ад творится в Android. Там каждое второе приложение считает необходимым создать свою директорию в $HOME
Даже Vk, WatsApp, Telegram, Сбербанк и куча других… Просто берут и создают папку в корне флешки, которая никогда не удалится при удалении приложения.
Зачем нужны папки Environment.getExternalStoragePublicDirectory() и context.getExternalFilesDir(), которые специально предназначены для хранения файлов приложения на внешней памяти, они видимо не знают…
Или это я просто не понимаю, зачем так делать.
А для остальных папок нужно просто добавить разрешение в манифест, запросить его и определить файлпровайдер с доступом к каталогу, в котором нужно читать или писать (хоть к корню флешки).
Реализуется совсем не сложно и описано в официальных гайдлайнах.
Или здесь какая то другая магия с доступами к external storage?
Хотя обычно, если данные имеют большой объем но эти данные другим приложениям либо малополезны либо вообще бесполезны — хватает возможности выбрать просто — внутренние хранилище/флешка.
С fileprovider'ами надо работать отдельно и появились они «недавно» (вот в этом году уже пришлось фиксить в приложении(клиент одного аппаратного девайса, поставщик еще и за подписку просит) логику что если надо делать и обрезать фотографию — то надо таки все через fileprovider'ы делать, до меня это вообще почему то не было сделано).
Уважаемый автор. Ежели программа кросплатформенна, то какую переменную среды она должна использовать, чтобы работало в т.ч. и под вендой и под макосью и т.п. Жду ответа, засим откланиваюсь.
Ок, а если не венда?
Вчера вот пробовал Sublime под себя настроить… Откровенно утомило бегать по директориям (ещё и пэкэджи куда-то надо распаковать). Хоть третью панель в коммандере открывай.
Прочитав первые строки уже хотел начать ругаться на автора что мол видали мы эти ваши бинарные реестры и прочие гномовендовые монструозности.
Но автор чуть более чем полностью прав. Особенную боль не следование freedesktop стандартам доставляет тем, кто хочет легко переключать конфигурации и окружения без контейнеризации и прочих решений в стиле "из пушки по воробьям".
Но я больше боюсь что в тех файлах не служебная информация…
За нами следят!
1. описание проблемы
2. предложение решения
Все бы так.
для себя вывел следующую практику:
1. в ~/ (home) пишу все что хочу, разный мусор, тесты и т.п., всеравно кроме меня там куча разных дот-папок и файлов к созданию которых отношения не имею, короче в хоме у меня срач… и вообще — хом на том же диске\разделе что основная ОС, короче там то что не страшно удалить.
2. то что важно сохранить — в отдельных местах, обычно это отдельно смонтированные диски типо:
— /media/240-ssd
-/media/1tb
-/media/2tb
там то уже порядок и никакой софт к текущей ОС туда не ставиться… так и живем
PS: оно действительно, при листинге ~ все в 1 экран не вмещается, причем а моих папок то всего штуки 3…
Ну, ок, будет помойка не в /home/username, а в /home/username/.local
Или что там предлагает автор статьи.
Вариант универсального файла конфигурации в виде БД (а-ля реестр виндовс) — тоже не идеален, т.к. хоть и локализует помойку в одном месте ФС, но тащит за собой другие проблемы.
На самом деле основная проблема в совместимости конфигов между разными версиями одного приложения. Неясно как ее указанные подходы планируют устранять. Может это… Все на nixos?
Ну и справедливости ради стоит упомянуть что все же есть какие-никакие альтернативы стандартному подходу хранения необходимых зависимостей в каталогах, например, npm-tink или yarn-pnp, но есть ряд условностей: первый является еще одной, пусть и независимой от npm, но все же зависимостью, а последний загружает модули из общего кеша пакетного менеджера (что по сути, все еще не отменяет хранение зависимостей в каталоге, хотя является, имхо, весьма достойной альтернативой).
Уверен, и в случае использования других пакетных менеджеров (нет) можно найти готовые решения, или написать свое, вопрос только в целесообразности их написания и костылей, необходимых для этого (с учетом всего вышесказанного).
Куда там мусорить в $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?
Я вообще за дополнительное разделение еще и на VENDOR/PROGRAM внутри .config/.cache
Хотя ихний же SSMS всегда писал в один и тот же каталог SQL Server Management Studio и не парился.
у Jetbrains несколько иное — они пихают по каталогам конфиги от IDE. Версия меняется — новый каталог, чтобы была возможность откатиться к предыдущей версии. При новой версии конфиг может быть "с нуля", мигрирован с изменениями и прочее. И потом, могут стоять сразу 2-3 версии одной IDE, т.к. где-то плагин не докатился ещё, а где-то наоборот что-то сломалось/изменилось и удобнее в предыдущей версии делать
Documents\Visual Studio 2005
Documents\Visual Studio 2008
Documents\Visual Studio 2010…
если уж так необходимо, делать
Document\Visual Studio\ и в нём делать каталоги 2005, 2008, 2010…
При этом вся эта идея разделения настроек по каталогам сохраняется. Почему в одном случае делают разбивку \Vendor\Product\Version, а в другом случае лепят в один каталог?
Безумие дотфайлов