Комментарии 184
Странный вывод. Как из этого
чем более очевидный выбор стоит перед человеком— тем быстрее (мгновенно, инстинктивно) он принимает решение. Если же встаёт выбор между похожими (одинаковыми) вариантами, то люди надолго впадают в ступор, вместо того, чтобы безразлично выбрать любой вариант случайным образом.
вы получили это?
больше всего времени тратится на бесполезные размышления над ничего не значащими вариантами. При этом большие, важные решения принимаются практически бездумно
Чаще всего похожие варианты не одинаковые, а именно, что отличаются нюансами, которые как раз и важно учесть. А если что-то очевидно, почему это большое и важное решение?
[del]
Попробую побыть адвокатом дьявола (как я эту неудачную фразу понял):
Рационально тратить на обдумывание время пропорционально риску = "вероятность ошибки" * "тяжесть последствий".
Исследование показало, что люди тратят время пропорционально только 1-му компоненту.
А что происходит для "двух похожих реализаций" первый компонент растёт, а второй снижается (в среднем) - это значит, что в такой ситуации время на обдумывание распределено нерационально.
Тоесть «вероятность ошибки» для них китайская грамота. Да блин, даже большинство закончивших мат.факультет не оценивают.
Зачастую в своих решениях мы ориентируемся скорее на инстинкты и
моральные установки, а не на рациональные правила для вычисления
оптимума. Соответственно, и последствия таких действий трудно
предсказуемы.
Так вроде всё правильно написано же в исходной статье (за исключением корявости формулировок). Человек не является рациональным агентом, и у него в мозгу эволюцией заложено множестов особенностей поведения (кому "баг" кому "фича").
Без ковыряния в Registry нельзя даже перенести рабочие файлы приложения в другое место, поскольку реестр не синхронизируется с файловой системой, что между прочим является нарушением принципа DRY.
А при чём тут DRY вообще?
Ну типа абсолютные пути к файлам и директориям в реестре дублируются по разным причинам.
Но с чего реестру вдруг синхронизироваться с файловой системой? Переименование любой папки должно предваряться автосканированием всего реестра с поиском абсолютных и относительных путей к этой папке? Странная идея. А что, .ini/.conf-файлы как-то синхронизируются с файловой системой?
А DRY - это относится к разработчику, повторяющему себя. Здесь у реестра и у программы разные разработчики.
пути к файлам и директориям в реестре дублируются по разным причинам
можете привести пример?
А что, .ini/.conf-файлы как-то синхронизируются с файловой системой?
Они могут лежать в папке с приложением
В папке с приложением не должны лежать файлы, которые могут быть модифицированы во время работы это программы
Есть общие рекомендации, где хранить настройки. Почитайте на досуге. А чтоб редактировать программе файлы рядом с собой, при учёте, что программа установлена по правилам (в Program Files), нужны права администратора. Только чтоб она могла сохранять свои настройки. Вы уверены, что Sublime Text постоянно нужны права администратора? Или браузеру?
Так то нет проблем на каждый файл в папке прописать отдельные права. Проблема будет потом отличать, где прав достаточно, где недостаточно, где избыточно. И ленивые админы будут просто разрешать запись в %PROGAMFILES%.
// общие рекомендации, где хранить настройки
Общие - значит ничьи. Я в Советском Союзе рос и учился, помню, что значит "общие рекомендации" растиражированные на все условия
Дайте конкретную ссылку
..и в них прописан путь? Зачем? Но если уж прописан, то придётся точно так же менять
Обычно в таких случаях прописывается относительный путь.
тогда все равно, где он прописан - в файле или в реестре
В файле прописывается путь относительно самого файла. В реестре - относительно чего?
В файле прописывается путь относительно самого файла.Что мешает прописать в файле путь относительно чего угодно?
В реестре — относительно чего?Например, относительно исполняемого файла программы, или домашней папки пользователя, или текущего рабочего каталога. Как программист напишет так и будет.
В файле прописывается путь относительно самого файла
С чего бы вдруг? Если путь прописывается там изначально, то да - он там скорее всего будет относительный. Только не пойму, зачем мне, как разработчику, этот путь нужно выносить в файл?
Если этот путь появляется в результате установки и уж тем более после выбора пользователем - относительный он точно не будет, даже если находится в той же папке. никто не будет заморачиваться созданием относительных путей, да и работать это будет сильно хуже
Ну и первый попавшийся пример не из винды
cat /etc/opt/remi/php81/php.ini
.....
[opcache]
; see /etc/opt/remi/php81/php.d/10-opcache.ini
Так в том и суть DRY, если у чего-то разные причины изменения, то нет нарушения DRY. Простое дублирование функционала нормально в моменте. Есть у вас две функции делают на текущий момент одинаковые вещи, это вовсе не значит, что вы нарушаете DRY, потому что завтра одна из функций может начать делать немного отличающиеся вещи, и это как бы уже не одна функция.Так что да - при чем тут DRY не понятно.
странная статья == перевод из нескольких других + попытка своих мыслей ?
Я лет 20 назад писал для себя несколько программ, которые сохраняют свои настройки в ini файлах (этим их функционал не ограничивается). Так вот, они прошли уже несколько ОС и множество переустановок системы, но достаточно просто скопировать папку в систему и всё работает. Когда настройки в папке с программой - это удобно. Да, с реестром очень неудобно.
Кстати, мне нравится решение разработчиков wine - работа с реестром сохранена, но файл имеет текстовый формат, как обычный REG файл.
Когда настройки рядом с программой, возникают вопросы к правам доступа.
Бинарники можно положить в readonly (как для всей системы, так и для конкретного пользователя).
У нескольких пользователей могут быть разные настройки.
Если у вас существует необходимость ограничить пользователя от модификации приложений, кошерным выходом является использование замкнутой программной среды (запрет на использование неподписанных приложений). А права доступа к каталогам – костыль.
Полвека назад человечество выдумало хранить код приложений в /usr/local, а их настройки – в /etc (или как в macOS, Applications и Preferences, неважно).
Полвека назад человечество выдумало хранить код приложений в /usr/local, а их настройки – в /etc
И что, у вас authorized_keys или .bashrc лежат в /etc/ ?
Они не являются настройками приложений, это параметры учётной записи пользователя. Башу для работы они не нужны.
Это конфиг-файлы конкретных приложений. Еще у меня есть, например, Skype, Firefox, Wine, несколько VPN-клиентов и еще несколько десятков приложений, которые запускаются именно для пользователя. Он хранятся в отдельной папке пользователя, да.
И я могу не захотеть делиться настройками VPN с другими пользователями этого компьютера, не так ли? И даже не хочу разрешать читать эти файлы.
А права доступа к каталогам – костыль.
В то же время, у меня есть серверные сертификаты для nginx, которые лежат в /etc, однако мне тоже не очень хочется чтобы доступ к ним был у всех запущенных приложений. Не очень понятно, все-таки, что вы предлагаете взамен решения, которое вы называете "костыль".
А мне не очень понятно, что вы подразумеваете под “доступом у запущенных приложений”. Субъектом доступа в наиболее часто используемых моделях безопасности является пользователь.
В целом, с точки зрения именно безопасности мандатные метки (и их безопастностный суррогат в виде средств контейнеризации и виртуализации) не имеют реальной работающей альтернативы. А то, что вы говорите про bash, Skype и Firefox – это средства персонализации, а не обеспечения безопасности.
И я могу не захотеть делиться настройками VPN с другими пользователями этого компьютера, не так ли? И даже не хочу разрешать читать эти файлы.
А с рутом хотите делиться? Когда дело касается безопасности, мысли надо думать до конца.
Но мы разговор-то вообще начинали не о безопасности, а об удобстве сопровождения системы.
Мы с вами находимся в треде, где автор верхнего комментария предлагает хранить настройки как файл в папке с приложением.
Вы начали отвечать другому комментатору, который указал что настройки могут быть разными для разных пользователей и нужно придумывать как их разделять и изолировать. Кстати, root - это тоже пользователь. И, кстати, статья, в первую очередь про Windows, несмотря на то что мы с вами, судя по всему, предпочитаем другие ОС.
Я считаю, что в macOS в этом отношении сделано очень понятно и близко к идеальному. Код приложения – в /Applications/приложение.app, общие настройки (кому нужны) – в /Library/Preferences/приложение.plist, индивидуальные настройки (кому нужны) – в ~/Library/Preferences/приложение.plist. При этом общепринятым хорошим тоном является возможность запускаться без настроек, создавая их по умолчанию.
Хотя, как и везде, мир не без странных людей. Находятся и такие, которые хранят настройки внутри приложения .app.
Это в том самом macOS, который хочет в каждую папку положить файл .DS_Store ? Даже на примонтированных сетевых дисках и чужих флэшках?
И которая простой файл с картинкой размажет по нескольким скрытым местам в файловой системе (возможно, это только на айфонах с HEIF-файлами)?
В Windows я тоже помню "Thumbs.db", но, вроде, ее уже убрали в последних версиях.
А где бы вы предложили хранить параметры отображения каталогов на флешке?
Отображения где? На Windows-компьютере близорукой бабушки с огромными иконками на десктопе или на ноуте ее внука (тоже Windows, предпочитает List-style для папок и показывать скрытые файлы).
Или на вашем macOS? Или на моем ноуте с убунтой? Каждый должен свой файл создать на этой флэшке?
Ну отсутствие стандартизации – это не проблема macOS, согласитесь?
Для меня вот важно файлы цветными пометками выделять. Потом сортировать по этим пометкам.
А это хранится в том самом .DS_Store? Ну вот у вас есть, скажем, общий сетевой диск на работе. И вам нравится одни файлы выделять красным, а другому коллеге - зеленым. А если таких коллег 20 человек?
Разве логично что хранить это нужно в этой самой папке?
В общем сетевом диске именно все пользователи и выделяют цветом, чтобы было понятно друг другу, какие файлы наиболее важные.
И что, правда что на Windows я увижу какой вы цвет у себя поставили этому файлу в macOS?
У нас не используется Windows в рабочем процессе. Фронтенд под macOS, бекенд под Linux.
Я пытаюсь вам указать на то что параметры отображения файлов в папках - это не свойства папки, а предпочтения конкретного пользователя (и на конкретном компьютере). И хранить их в общей папке нет смысла. Поэтому ваше изначальное замечание про идеальность macOS достаточно спорно.
Я лично предпочитаю белый шрифт на темно-зеленом фоне для списка файлов (это правда так). Но если я попытаюсь это сделать для папки с общим доступом - вряд ли я найду поддержку.
Я не говорил, что macOS вообще во всём идеальна, а привёл пример конкретно с настройками программ.
И я не говорил про общую идеальность, а продолжил именно эту же тему - программа Finder, входящая в состав macOS свои настройки упорно пихает во все папки, совсем ей не принадлежащие. И в последних версиях они решили эту проблему:
Очень просто и надежно
Starting at macOS 10.12 16A238m, Finder will not display
.DS_Storefiles (even withcom.apple.finder AppleShowAllFiles YESset).
То, что конкретно файндер пишет в .DS_Store – может быть хорошо или плохо, но никак не связано с общим принципом хранения настроек программ в plist'ах, описанным выше.
Хотя конкретно в данном случае всякое централизованное хранилище, в том числе и plist, невероятно разбухло бы от огромного количества данных о неактуальных уже каталогах, поэтому разумной альтернативы не видно.
Всегда можно найти пример, когда настройки программ в X это хорошо и удобно. И антипример тоже ;)
И к этому тоже есть вопросы.
хранить код приложений в /usr/local, а их настройки – в /et
а потом придумало контейнеры, чтобы с этим как-то справляться ))
// У нескольких пользователей могут быть разные настройки.
Когда все это начиналось - казалось, это классная идея - несколько юзеров на одной машине.
Я прожил 30 лет с персональными компьютерами и за все эти годы на всех моих машинах был один пользователь.
Пора честно встать и признать - из-за химеры "удобство для нескольких пользователей" мы соорудили кучу неудобных практик для одного основного пользователя.
Несколько пользователей на компьютере - это химера. Компьютер - это персональная машина.
Даже если в 80% случаев (цифра из головы) на персональном домашенем компьютере с запущенной ОС всего один основной пользователь, то в оставшихся случаях это не так.
Допустим, вы разработчик какой-то более-менее популярной программы. Вы проигнорируете возможность запуска вашей программы для разных пользователей?
Даже если пользователь один - процессов много, и доступы очень желательно ограничивать.
Несколько пользователей на сервере - это реальность.
Мощный компьютер - это не персональная машина, потому что это было бы слишком дорого для каждого.
И это не только про линукс. У виндоуза есть версии server с удалёнными рабочими столами.
Я прожил 30 лет с персональными компьютерами и за все эти годы на всех моих машинах был один пользователь.
Это только кажется. На всех ваших машинах куча служб запускается от имени разных пользователей
Кроме того, я предполагаю, что 30 лет вы пользуетесь не только персональным но и корпоративным компьютером.
Я прожил 30 лет с персональными компьютерами и за все эти годы на всех моих машинах был один пользователь
Это — ваш опытт. А я, имея опыт системного администратора, могу сказать что есть, например, такое явление как «ПК коллективного пользования». Это востребовано в подразделениях типа отделов продаж (например — маклерских в агентствах недвижимости), где значительная часть сотрудников работает «в полях», без ПК, но иногда им ПК становится нужным — документ там составить, в базу данных посмотреть… Таким сотрудникам нет смысла выделять каждому по ПК, значительно лучше иметь несколько ПК на отдел, за любым из которых работает тот, кому это сейчас нужно. Вот им как раз и надо, чтобы были их настройки, причем — чтобы они переходили вместе с ними на разные ПК.
Это я все к тому, что сценарии использования ПК могут быть очень разные.
PS А в банках любят использовать терминальные решения, когда ПК на рабочем месте где-нибудь в филиале по факту является терминалом для доступа к серверу — считается, что так лучше обеспечивается безопасность.
А что мешает дать права записи в конфигурационный файл? Не удаления, не создания и не переименования, а только чтения и записи содержимого.
Я не специалист, поэтому задам, вероятно, дурацкий вопрос: а в чем именно дыра в безопасности? Речь будет идти только об использовании домашнего ПК, не рабочего.
Я начинал свой путь в Win98. И, конечно, начинал с игр. И игры того времени хранили свои сохранения в папке с игрой. Что, на мой субъективный взгляд, очень логично и удобно для пользователя - я всегда знаю где сейвы к данной конкретной игре. Переустановка системы никак не затронет моего персонажа в Diablo 2 и Fallout 2. Если я захочу удалить игру, то папку save могу удалить или сохранить - я ведь точно знаю где она лежит. И точно удаление дьяблы не повредит фаллоуту. И наоборот. И даже я могу хранить и использовать несколько версий одной игры (актуально для мододелов, например), так, чтобы они друг другу не мешали. Это же применимо и к программам, хотя тут у каждого вида софта есть свои заморочки. Если программа ворочает большими файлами (видео там), то их неудобно хранить рядом с ней. Так большинство подобных программ позволяет сохранить результаты работы вообще куда угодно по запросу пользователя. Лишь бы ему прав хватило.
В то же время современные игры сохраняют игру в одно из множества мест: appdata (там еще возможны варианты куда именно), мои документы, мои игры или еще куда-нибудь. Чтобы найти папку проще залезть в гугл и спросить, потому как папка с сейвами будет в лучшем случае лежать в папке с названием разработчика, которая лежит в папке с именем издателя (обычному игроку эта информация не нужна и не всегда известна). А может лежать в папке с именем в виде аббревиатуры, тогда шансы ее найти самостоятельно стремятся к нулю.
Поэтому когда где-то пишут, что хранение сейвов и настроек вне папки программы это "для удобства пользователя" у меня возникает некоторый диссонанс. Мне вот, как пользователю, неудобно. И я до сих пор не могу переучиться, хотя и принимаю новое.
Единственную дыру (с моей точки зрения дилетанта), которую я вижу - это заполнить полностью диск, на котором игра/программа лежит. Но у меня the Witcher 1 точно также забивает насмерть SSD, на котором установлена система, т.к. сохраняет свои сейвы по 10-20мб (в зависимости от стадии игры) и не перезаписывая их. В итоге после пары часов игры папка на системном диске весит пару тройку гигабайт. Что в итоге куда опаснее, чем переполнение диска д - потому как там вообще ничего важного нет и быть не должно (это мой субъективный опыт работы с виндовс, возможно неправильный).
Вторая дыру, что я вижу - это генерация вредоносного кода и сохранение в папку с программой. Но что мешает программе сгенерировать такой код на системный диск в папку с настройками (возможно она оттуда ничего выполнить не сможет или там еще какая защита. я не знаю)?
В итоге после пары часов игры папка на системном диске весит пару тройку гигабайт.
2*1024/20 = 102 сохранения в час минимум
Бывает))
Это после двух игровых сессий. Да я часто сохраняюсь. Особенно в играх, склонных к вылетам. Я чищу папку довольно часто. Насчет объема сейвов, я, как видите, приуменьшил. Но первые сейвы из начала игры точно были порядка 10мб.
К слову, я нашел папку с сейвами таки с третьей попыки. Папка the witcher есть и в AppData\Local и в документах.
А потом оказывается, что каждой из ваших игр нужен доступ к Steam, и где-то надо хранить пароль (токенов нет). В каждой папке будете хранить копию?
Я никак не разбираюсь в устройстве стима. Не могли бы вы пояснить, что имеете в виду? Какой пароль должен храниться в какой папке? Стим хранит все игры в папке steamlibrary. Ничто не мешает ему рядом хранить какие-то свои данные (про безопасность их хранения в зашифрованном виде я не могу судить). С сохранениями все сложнее - там тоже кто во что горазд. Пример с ведьмаком - как раз стим версия. Сейвы хранятся в "мои документы", игра в steamlibrary. Что еще об этой игре стим хранит в steamlibrary (там много папок, я как-то не вникал) мне неизвестно.
Это просто абстрактный пример того, что бывают настройки, которые общие для нескольких приложений. Где их хранить?
Хреновый пример.
Потому что стимовские игры используют steam api.
А стим свои настройки хранит сам, один.
В данном случае это настроки стима - поэтому пример я и не понял.
Если честно сходу не могу вспомнить никакого ПО, которое бы обладало общими настройками. Всегда есть или "главная" программа, к которой обращаются остальные или программы объединяет только производитель. Можете привести более конкретный пример?
Но даже без него настройки программ, как правило, измеряются десятками килобайт. Не вижу проблемы хранить их в каждой из связанных программ. Допустим совершенно бредовую ситуацию: я взял свою коллекцию игр стим и установил (700+ штук - я коллекционер). И каждая хранит по 100 кб общих настроек. С винчестером, способным выдержать 700 игр, в среднем весящих 5 гб (от 100мб до 120Гб), я замечу это или нет?
Если же брать более реальную ситуацию, где количество установленных на ПК приложений болтается около 100. То даже если половина программ будет с общими настройками - это заметно не скажется ни на объеме винчестера, ни на быстродействии программ.
Хотя если те же 100кб настроек на каждую программу запихнуть в реестр, который часто просматривается разными приложениями и самой ос - тогда будет "ОЙ", конечно.
В случае с играми и стимом еще можно придумать какие-то схемы чтобы не использовать реестр.
Но, например, у вас есть драйвер. Например, принтера. Он устанавливается в систему и может быть доступен нескольким пользователям и совершенно разным приложениям - от офиса до блокнота или какому-нибудь Bluetooth-сканеру (у которого свой драйвер еще есть).
И каждый пользователь хочет иметь свои настройки принтера (любимая ориентация, размер бумаги, цвета). А так же офис может захотеть запоминать какие-то настройки от предыдущей печати или шрифты.
А еще по сети принтер можно расшарить когда ни один пользователь вообще не залогинен.
А драйвер (не обязательно принтер) - это такая штука, которая может состоять из нескольких компонентов или слоев, когда часть кода выполняется чуть ли не в ядре ОС, а часть загружается динамически из какой-то DCOM-библиотеки, которая вообще не в курсе конфиг-файлов. И эти DCOM-библиотеки связаны между собой через отдельно зарегистрированные в системе компоненты с уникальным guid. Который отличается для каждой установки ОС.
В итоге получается что проще иметь какое-то универсальное API для хранения настроек, специфичных для конкретной установки ОС на именно этом компьютере. И лучше бинарного для оптимизации доступа (и чтобы не лазили кому не надо руками).
В целом, идея реестра сама по себе не так уж плоха. Понятно что за 30 лет много чего поменялось и не все принятые ранее решения сейчас выглядят правильными.
вот насчет нескольких пользователей одного ПК я как-то не подумал. В играх(более менее современных) это решается через профили. В каждом профиле уже свои сейвы/настройки/персонажи. И хранить их можно было бы в папке с программой.
В случае с принтером это не сработает, там нужен механизм вроде папки users или реестра.
В каждом профиле уже свои сейвы/настройки/персонажи. И хранить их можно было бы в папке с программой.
Ок, давайте я попробую продолжить с вашим примером, хотя это будет посложнее..
Допустим, у вас есть брат, с которым вы вместе по очереди играете в какую-то игру, соревнуясь кто больше очков наберет. И, купив какой-то редкий меч в своей игре, через день вы обнаруживаете, что, оказывается, вы его продали в таверне за копейки. Брат хихикает и молчит. Вы понимаете что он загрузил ваш профиль из вашего файла и что-то поменял пока вас не было.
Да, можно в программе предусмотреть ввод пароля и им шифровать каждый профиль, но зачем это делать в каждой программе, если в ОС вы один раз входите под своим именем и имеете доступ только к своим уникальным настройкам, которые ОС сама же и защищает известным способом (в отличие от разработчиков игры, которые хз какой алгоритм решили выбрать для шифрования).
Это понятная проблема, я о ней, конечно, подумал и сам. Просто такую проблему с братом обычно решают в реальности :) . И профили нужны не для ограничения несанкционированного доступа, а именно для того, чтобы случайно не затереть чужой сейв.
Но ваша версия лучше, чем незащищенный профиль, это само собой. С другой стороны, если уж "брат" так хочет схитрить - у него для этого море других возможностей. Начиная от артмани, заканчивая входом в мою учетку в ОС, подсмотрев пароль.
Работу нескольких пользователей за одним ПК я действительно не предусматривал, когда писал посты выше. Потому что банально почти не сталкивался с таким в домашнем использовании. А там, где все-таки сталкивался у нас был один профиль ОС, где мы просто руководствовались простыми правилами вроде "не гадить там, где ешь". И проблем ни с сейвами, ни с документами не возникало.
Другой вопрос с рабочими ПК, где это должно жестко регулироваться и защищаться. Там без разделения не обойтись.
Ну, благодаря этой ветке я хотя бы понял зачем были перенесены настройки и сохранения в папки юзеров. Потому как раньше меня это просто раздражало.
Окей, вот есть игровой джойстик, у него есть маппинг кнопок, который вы не хотите настраивать каждый раз заново для новой игры. Где хранить эти настройки?
Если я захочу удалить игру, то папку save могу удалить или сохранить - я ведь точно знаю где она лежит.
Это не относится к обычному среднестатистическому пользователю.
Вдобавок есть системные функции автоматического бэкапа профайла пользователя и эта системная функция никак не сможет догадаться какой .ini файл из папки самой программы нужно сохранять. Проще и логичнее бэкапить то, что лежит в users/
Если брать не винду, то в /etc, например, юзеру тоже нечего делать. Вот и MS пошли по пути стандартизации. Просто вместо индивидуальных ???/bin ???/etc, они предложили хранить или в реестре или в users/
Насколько я вижу, основная проблема не в системе, а в программистах, которые либо стандарты не учитывают, либо соблюдают их формально, вообще не задумываясь об удобстве, и тогда бывает
c:/programfiles/COMPANYNAME/GAMENAME
c:/users/MyUser/Documents/ALTERNATIVEGAMENAME/saves
вместо нормальной унификации.
Если я захочу удалить игру, то папку save могу удалить или сохранить - я ведь точно знаю где она лежит.
> Это не относится к обычному среднестатистическому пользователю.
Тогда что же относится к среднестатистическому пользователю?
В моем видении пользователь использует различные программы на своем компьютере. Если ему нужно решить новую задачу (убить баала) - он устанавливает новую программу (диабло 2) и пользуется ей. Когда задача решена пользователь может или удалить программу или оставить ее на диске (в зависимости от кучи параметров).
При этом он волен сохранить или не сохранять свой прогресс. Может он удаляет программу временно, потому что нет места для другой программы, которая решает другую задачу (убить азмодана, например).
Если для установки/удаления программ звать сисадмина, то так можно дойти до курьезных законов некоторых стран, где без образования электрика нельзя заменить лампочку, а без сертифицированного специалиста фермер не может масляный фильтр в тракторе поменять.
> Вдобавок есть системные функции автоматического бэкапа профайла пользователя и эта системная функция никак не сможет догадаться какой .ini файл из папки самой программы нужно сохранять. Проще и логичнее бэкапить то, что лежит в users/
Ни разу не пользовался этой функцией. Я - плохой образчик как простого пользователя, так и среднестастического. Но из моих знакомых (просты юзеры, никаких сисадминов, но каждый способен сам переустановить винду ничего не сломав) также никто не пользовался ни разу этой функцией (и даже не знают про нее). Но тут мы переходим к:
> Насколько я вижу, основная проблема не в системе, а в программистах, которые либо стандарты не учитывают, либо соблюдают их формально, вообще не задумываясь об удобстве
И это верно. Потому как я ведь перед переустановкой могу или средствами системы или руками взять и сохранить папку users. Но есть пара проблем: большинство настроек, которые там хранятся после переустановки системы пойдут коту под хвост. Большая часть появится там самостоятельно в процессе установки необходимых программ. Но еще большая куча там будет от старых программ, которые уже не нужны, но программы не озаботились удалением мусора за собой.
Насколько я вижу из комментов, в т.ч. других веток: этот бардак с настройками в основном мешает сисадминам. Простым пользователям он до фонаря, пока можно форматнуть диск C и переустановить винду раз в год. Никакой ccleaner не сравнится с такой уборкой мусора. Читатели/авторы хабра, как правило, более чем опытные пользователи пк, многие линуксоиды/маководы. Поэтому проблемы простого пользователя виндовс многие просто забыли/не замечают. Так же как пользователь не заметит боли во взгляде сисадмина, когда зайдет без пароля в админскую учетку и удалит папку с программой, не воспользовавшись uninstall.exe
Тогда что же относится к среднестатистическому пользователю?
В моем видении пользователь использует различные программы на своем компьютере. Если ему нужно решить новую задачу (убить баала) - он устанавливает новую программу (диабло 2) и пользуется ей. Когда задача решена пользователь может или удалить программу или оставить ее на диске (в зависимости от кучи параметров).
Пользователь может зайти в игру, сохранить, загрузить состояние.
Но далеко не всегда среднестатистический пользователь может найти сохранение игры в виде файла в какой-то директории.
Таким образом, если он хочет удалить игру, то он не знает как при этом сохранить сейвы игры. Если разработчик сохранил их в documents, то они сохранятся. Правда не факт, что пользователь будет в курсе. Так и будут там лежать годами.
Поскольку крайне редко отдельные файлы имеют другой доступ.
И нет, «средний» пользователь не знает вообще ничего про файловую систему, у него какой-то совсем странный набор абстракций в котором в лучшем случае есть слово «папка».
Неистово плюсую.
Последние 15 лет периодически собираюсь с друзьями в третьем варкрафте. Раньше он аккуратно хранил кастомки в папке Maps/ и никто горя не знал. С выходом рефоржа - я уже и не знаю, куда эти кастомки перенеслись. Скачать и добавить кастомку стало приключением почище самой кастомки. Как работать с теми, которые работали на версии 1.29, но перестали работать на 1.31? Может, размер диска - уже не особенно актуальный вопрос, но 20 гб карт - можно было бы и на диске D хранить. Не знаю, что там за проблемы с несколькими пользователями одного пк, но имхо, такие вопросы должны решаться на уровне пользователей, а не уровне системы.
Дырень в безопасности – это исполнение модифицированного кода, а не права записи в папку.
Для многопользовательских, соглашусь, не подходит такое решение, но...
В Linux системах это сделано удобно - есть глобальные настройки, а есть пользовательские, которые хранятся в профиле пользователя. И всё это в текстовом формате. В большинстве случаев. Зависит от самой программы. Причём, удалив эти файлы или, даже, всю папку с пользовательскими настройками, систему не сломаешь - просто настройки "сбросятся на значения по умолчанию".
Если что, то реестр - это тоже разделенная система. Реестр юзера и реестр системы разделён на несколько файлов. И реестр юзера хранится в каталоге пользователя.
Только вот удалять этот файл (NTUSER.DAT) не рекомендуется.
В Линуксе все проблемы типа "переноса не в ту папку" решаются нормальными симлинками, в отличие от Винды.
В Linux системах это сделано удобно — есть глобальные настройки, а есть пользовательские, которые хранятся в профиле пользователя.
Что самое интересное, это есть и в реестре Windows, в стандартных солашениях о хранении конфигурационной информации приложений: раздел Software, предназначеный для этого, есть и в общесистемном корневом разделе (HKEY_LOCAL_MACHINE, куда обычный пользователь, зачастую не имеет даже разрешения что-либо писать)Ю и в пользовательском (HKEY_CURRENT_USER, с полным доступом для пользователя: это, на самом деле — символическая ссылка, своя для каждого пользователя, на один из разделов под ключом HKEY_USERS). Причем пользовательский раздел физически хранится совершенно отдельно об общесистеммного, в файле ntuser.dat внутри профиля пользователя. И предлагается общесистемные настройки и значения по умолчанию хранить в HKEY_LOCAL_MACHINE, а специфичные для конкретного пользователя — в HKEY_CURRENT_USER
Но тут, как всегда встает вопрос с дисциплиной — нужно, чтобы разработчики программ следовали этому соглашению, а они — особенно разработчики кросс-платформеннных программ — делают это, мягко говоря, не всегда.
В Linux системах это сделано удобно
Нет, это просто под Линукс конкретные разработчики так пишут. Никто не мешает разработчикам под MS тоже писать все в профайл пользователя. И многие нормальные девелоперы так и делают.
Просто на
gzipоказалось завязано слишком много внутренних подсистем, всё работало по накатанной. Проклятие легаси во всей красе.
"Всё работало" - это же благословение, а не проклятие )
Прошу прощения, но чем абсолютный путь в ini файле лучше абсолютного пути в реестре? Разве ini файл кто-то "синхронизирует" при переименовании какой-то папки?
Автор же пишет: "Иногда хочется вернуть те самые файлы .INI, чтобы настройки приложения хранились в одной папке с ним. Кажется, что так было гораздо логичнее и проще. ".
Ты можешь и в реестре не писать полные пути. Полностью использовать как ini. Ни какой разницы нет.
Речь же не про полные пути, а про настройки. Недавно сталкивался с ситуацией, в которой нужно было запустить копию программы с другими настройками. Копию папки с программой сделал, все запускается, но оказалось, что настройки хранятся в реестре и едины для всех копий - облом. Автор прав, хранить в реестре все подряд не самый правильный подход, но и обновлять ini (или другие файлы настроек) в Program Files с правами юзера не получится, и тут уже захламляются другие доступные для пользователя папки изначально не задуманные для хранения приложений.
Вы не совсем правы, AppData именно для этого создана. Там можно легально хранить настройки, только вот суть в том, что опять этот файл будет одинаков для всех копий.
Копию программы с другими настройками можно запустить только если файл настроек хранится именно рядом с ехе. А это противоречит правилам написания программ.
Если вы о правиле не давать пользователю доступ на запись в папках где есть разрешение на запуск, то это хорошее правило. Правда в реальности, если сделать поиск экзешников в AppData можно предположить что, именно для них она и создана, т.к. с завидным упорством туда прописывают исполняемые файлы все кому не лень. Или о том, что не гоже одному пользователю устанавливать настройки для программы, которые повлияют на всех пользователей? Тоже хорошее правило, но не всегда есть эти "другие" пользователи и популярность portable версий программ говорит, что не все правила так категорично важны. Если речь о других правилах, то я прошу вас озвучить, навскидку не приходит в голову каких-либо еще идей, а понять хотелось бы. В .Net тот же app.exe.config хорошо себя чувствует в одной папке с app.exe, чем не инишник? )
Файл будет одинаков для всех копий… А что если использовать здесь ту же идею, что и в Git? Переключился на другую ветку/другой коммит - получил другой файл настроек/другую копию..,
Конкретно мне был нужен одновременный запуск программы с разными настройками (подключением к БД), тут особо выхода не найти. Но нет особой проблемы написать скрипт, меняющий соответствующие параметры в реестре на нужные при старте (для нескольких программ так и сделал), но это уже не уровень пользователя и костыльно.
Если программист не предусмотрел работу программы в вот такой позе как вам хочется - тут только костыли. Виртуализация, например.
Почему бы просто не запустить под разными пользователями? Хоть windows хоть linux так позволяет сделать. Тогда с настройками привязанными к пользователю вы и получите два экземпляра на разных настройках. Зачем доводить аж до виртуализации то
del
В случае *.ini файла у вас есть закрытый список настроек.
Поправили 3 или 33 пути - всё работа сделана.
В случае реестра - вы только опытным пунём можете понять все ли настройки вы поправили или нет.
А какое отношение к статье имеет часть заголовка "Выученная беспомощность" ?
Таких примеров и в реальности навалом, например пластиковая упаковка из бионеразлагаемых материалов by design будет приводить к накоплению её в среде и в виде многотысячетонных свалок.
Человечество оно такое, краткосрочные выгоды у нас в приоритете по эволюционным причинам.
Если же встаёт выбор между похожими (одинаковыми) вариантами, то люди надолго впадают в ступор
Я сыграл около 10-ти тысяч шахматных партий онлайн. Из них около 5 тысяч в блиц (3-5 мин на партию для каждого игрока). Проанализировав партии в блиц, я увидел интересную корреляцию с временем на обдумывание хода и его качеством.
Кажется, чем больше думаешь - тем сильнее ход. А на практике - нет.
В большинстве случаев, когда в блице идёт задержка - это означает, что я не знаю, что делать. Потом долго думаю над ходом а потом с большой вероятностью совершаю плохой ход. Чуть реже встречаются моменты, когда для меня есть много хороших ходов (как правило, в крепко выигранных позициях), но среди них есть сильнейший. Чтобы вычислить сильнейший я засчитываю варианты глубже обычного (в т. ч. из-за того, что их легче считать: много вынужденных ходов у противника). Тут да, ошибок меньше)
Автор безграмотен, все его 4 пункта - полная лажа. Статью в помойку.
Вы забыли сказать «мамой клянусь». Когда высказываешься без малейшего признака доказательства, это нужно добавлять в конце.
Автор очень уверен в мифе, что "реестр - это помойка". 🤔 И автор даже не попытался предположить, а что, если это не так? А даже полностью наоборот - тысячи файлов конфигураций по всем дискам и папкам - вот настоящая помойка! А что если необходимо перемещать все настройки программ вместе не с программой, а с пользователем? На регулярной основе. А что если нужно иметь профиль настроек программ предопределённый или заданный по умолчанию? А что если необходимо единообразно управлять настройками по сети на тысячах машин? А что если нужны механизмы изменения и отслеживания изменения конкретных настроек в реальном времени и не из программы-хозяина?
Да и работать с Git надо учиться специально.
Ну, а на вопрос про знание Git так и хочется ответить вопросом: а какие знания Git более общие — знание porcelain или знания plumbing?
PS Возможно, что на базе git plumbing можно сделать и систему хранения профилей настроек — штука-то универсальная. Но сомневаюсь, что этим кто-нибудь заморочится.
Для того, чтобы достаточно эффективно пользоваться гитом для хранения и синхронизации настроек, достаточно выучить ровно три команды.
А можно не учить? А то у меня всегда под рукой если Visual Studio, то Git GUI точно, а там вместо этих команд можно на кнопочки понажимать.
Что мне тут предлагает реестр? Как он отвечает на «а что если» исходного комментатора?
Например, тем что хранит все настройки пользователя из реестра (HKEY_CURRENT_USER) в одном файле ntuser.dat
Не, я не спорю — эти самые настройки можно было бы и в XML засунуть, и в JSON — лишь бы программы, которые их используют, читали бы их оттуда. Но почему-то довольно многие программы в Windows хотят видеть свои настройки в реестре.
И как, легко это будет синхронизировать между разными машинами?
Для корпоративной сети уже есть стандартное решение — перемещаемые профили пользователя. Ну да, мне лично оно не сильно нравится (и намучался с ним тоже), но в корпоративной сети, если задача есть, то лучше решать ее стандартными средствами, а не своим велосипедом. А вот дома, когда от тебя толпа пользователей не зависит — возможны варианты.
И да, в перемещаемых профилях есть и неперемещаемая часть. Та, которая Local. Впрочем, реестра там, кажется нет.
Начнём с того что первая VCS появилась аж в начале 70-х, а к 95-му году уже CVS вовсю цвёл и пах! А для простых сценариев и учиться не надо (git add / git commit) У меня, при помощи etckeeper они срабатывают вообще автоматически -- по крону или если какой-то софт обновился с новыми версиями конфигов.
сейвы и настройки от игрушек тоже в git хранишь и легко синхронизируешь?
Удобно в гит добавлять сейвы от разного софта из разных каталогов?
Настройки и конфигурации - это далеко не сохранения игрового процесса. Сохранения процесса, как правило, хранятся как раз в виде файлов в папке с игрой.
Удобно в гит добавлять сейвы от разного софта из разных каталогов?
Храню настройки (вима, zsh, гита, эмулятора терминала, и так далее) в гите. Изменил что-то серьёзное — коммит, и откатиться легко. Синхронизация тоже простая.
А как автоматически добавить в гит все-все-все симлинки на конфиги от разного софта?
Можно предположить, что можно взять все .* из $HOME, но ведь не весь софт там хранит.
Я пытаюсь акцентировать внимание всех на том, что нет единой рекомендации ни для Линукс ни для Windows, которой бы придерживались все разработчики, чтобы можно было легко сделать автоматический инструмент.
Везде бардак - чуть больше или чуть меньше
Ну а бардак в реестре винды - следствие того же самого процесса, а не архитектуры реестра.
Это ответ типа "зачем нужны базы данных если все можно хранить в текстовых файлах".
И да, ответ - можно - экспорт в текст (нужной ветви) и в гит.
а кто мешает в файле конфигураций записать пользователя и подгружать относящиеся к конкретному юзеру? Ну, будет не один файл настройки, а сотня user-specified? с отдельным реестром для каждой программы, например? Вариант ничем не хуже общего реестра винды. ИМХО
Все представленные вами проблемы (кроме читабельности без спец. инструментов) имеются и в ini файлах. Мы тоже можем поместить "бинарные" данные в ini файл и прочитав его потом особым образом выполнить код.
Представим, что за автозагрузку у нас отвечает конкретный ini-файл. Он позволяет указать пути к исполняемым файлам и указать аргументы.
Мы также можем в ini файл поместить под каким-то ключом бинарные данные (например в base64 формате). При загрузке у нас выполняется командная строка в параметрах которой чтение этого же ini-файла, чтение ключа с base64 и исполнение.
Вот буквально сегодня совершенно по другому поводу написал такое:
Но вообще пока я не готов сказать, что есть что-то оптимальное, работает почти всё, плюсы и минусы есть везде, огрести странных и неочевидных проблем тоже можно везде. Всегда рулит понимание разработчиками того, что они выбрали и не пытаться всё переписать каждые 3 месяца. Вообще идея, что можно понять и принять то, что, тебе кажется, ты мог бы построить лучше очень важна и сильна. К сожалению в разработческой среде сейчас очень модно "улучшать" всё вокруг себя, по факту наводя кучу суеты. Иногда нужно просто выполнить задачу. Хорошей прививкой от этого становится просмотр реальных проектов с историей 10+ лет, желательно с экскурсией опытного в этом проекте разработчика. Один из любимейших моих примеров возлагания титанического МПХ на паттерны проектирования ради 15% производительности, это вот этот файл https://github.com/microsoft/TypeScript/blob/main/src/compiler/checker.ts и да, я рефакторил его, и это привело к падению производительности https://github.com/microsoft/TypeScript/issues/17861 поэтому он до сих пор такой. Особенно в играх ты очень часто сделаешь что угодно, ради 15% производительности.
с играми проще :) игроман скорей купит железо помощней, потому, ИМХО, с производительностью там не сильно заморачиваются, разве что когда речь идет о заплатках и исправлениях.
а про улучшение каждые 3 месяца - необходимость в этом есть. эксплуатация постоянно ставит новые задачи, а изначально развитие закладывают не все.
Например, в апреле мне поставили задачу автоматизировать один-единственный ручной процесс (т.е. простая примочка уровня копипаст), к июлю он вырос в целый тул, а к ноябрю грозит вырасти в полноценную WMS с контролем сроков годности и синхронизацией с транспортными и ERP-системами компании. Но самый первый код до сих пор так и остался примочкой, и в целом проект состоит из этих примочек, и так как уже толпа людей эксплуатирует его, переписать все так, как надо по-уму, уже не получается по времени. а даже если удастся, то внедрить без бардака тоже не получится. Потому процесс внедрения, получается, будет каждые три месяца. Учитывая, что пользователь не сильно далекий, то внедрение и обновление превращается в вечный процесс.
Вопрос от человека незнкомого с ТС. А этот чекер мог бы быть написан на С++ каком-нибудь? Чего ж ради 15% не сделать?
Ну строго говоря да, но это ещё более многократно увеличило бы сложность разработки и последующей эксплуатации. То, что компилятор написан на js позволяет очень легко использовать его кроссплатформенно. Сделать это на влюсах и встроить находится за границами разумного. А что самое интересное, что ой не факт что будет прирост призводительности.
Кросс-платформенная компиляция довольно широко распространена. Сторонних зависимостей вроде не наблюдается, что сильно упрощает компиляцию. Если у этого файла мало точек входа, то вообще отлично.
Производительность - нужно профайлить. Судя по обсуждению все затыкается в производительность интерпитатора, которому становится сильно сложнее использовать обьектные конструкции. С++ все же намного лучше справляется с этим ввиду отсутствия шага интерпритации. Но возможно я совсем не правильно понимаю, что там творится.
Но переписывтаь это все на С++ конечно сложно. Нужен автоматический транслятор что-ли.
Если кто-то не умеет работать с информацией в реестре - тут есть 2 пути. Либо почитать где-то про импорт-экспорт-миграцию данных.. Либо пожаловаться как всё слоожнооо..
;)
Хотелось бы уточнить про zstd vs gzip. gzip -- он одновременно и хреново и медленно сжимает. А вот zstd может или сжимать примерно так же -- но на порядок быстрее, либо сжимать примерно так же медленно -- но с сильно лучшим коэффициентом сжатия. Жду, когда zstd просочится, например, в png :)
Например, после простой переустановки Windows большинство установленных игр и рабочих программ перестают работать просто потому, что их рабочие пути были прописаны в реестре, а по другим путям они не запускаются.
Вот тут я бы поспорил. Как раз с играми, что со старыми, что с новыми проблем зачастую нет. Некоторые - да, перестают работать. Но большая часть нет. Стим вообще решает эту проблему - возможно сам следит за реестром, но игры из стима отлично работают после чего угодно. Хоть после переустановки, хоть после переброса в папку. Правда сам стим скорее всего придется переустановить (тут ИМХО, ибо не пробовал запускать ранее установленный стим после переустановки системы).
Да и программ хватает (да хоть бы и блендер или godot engine), которые умеют работать без переустановки, но, как правило, это небольшие утилиты не связанные с взаимодействием с системой. Хотя я видал и фотошоп portable version.
А одна из немногих игр, которая у меня не пережила перенос в другую папку это Fallout 2 (не уверен от какого флибустьера та версия). И кстати не пережила именно из-за хранения абсолютный путей в ini файле :) . Стоило открыть инишник и поправить путь, как игра снова заработала.
стим не убиваем как таракан, можно удалить все кроме главного бинарника и он просто докачает нужное)
в целом в Винде бывают удивительные вещи. В 1999 году одна подруга установила ломаную версию Adobe PageMaker 6.5 на Win95. Потом были 98-й, Миллениум, 2000, и все, дистрибутив перестал устанавливаться на версии выше. Но сама программа запускалась, и, что самое интересное, просто летала по сравнению с более новыми версиями PageMaker'а, глючить не глючила, а для нужд верстки учебных пособий инструмента хватало за глаза. Я четко был уверен, что это не должно запуститься в десятке, но подруга переустановила на десятку, и программа все равно работала, при запуске выдавала ругательные окна, но по их закрытии выдавала основной доступный функционал, по крайней мере, функциями. которые могли вызвать сбой, она не пользовалась. До сих пор она раздает своим студентам методички сверстанные в программе, которая должна была прекратить работать в 2002 году.
Тут надо уточнить, что многие старые игры, которые всегда требовали инсталлятора, плохо переносили перенос в другую папку или переустановку системы. Примеры за давностью лет я не приведу :( .
Но сейчас игры качаются лаунчером (ну или торентом). Инсталлятор в них если и есть, то ради сжатия данных и проверок, что директХ и всякие там .netфрэймворки установлены в системе. Ну и порекламировать другие игры (привет ГОГ). Со времен вин7 большинство игр спокойно относится к перемещениям (по моему субъективному опыту, обильно сдобренному ностальгией).
Ну вот прям C:\Games я встречал только один раз. И это было уже в нулевых (не помню что). Но вот "нельзя кириллицу" и "нельзя пробелы" в пути к папке - этого хватает, да. Но достаточно назвать папку X:\Games, чтобы избежать 99% этих проблем :) .
Совсем старые игры могут еще 8 символов на имя папки требовать. Но это уже для любителей, а они знают что такое DosBox и как им пользоваться. Так что их такие проблемы не пугают.
Я помню момент, когда в Windows появилось registry (массово - при переходе на Windows 95) и у меня были ровно те же мысли тогда: параллельная файловая система, при этом сложноредактируемый общий бинарник - хаос увеличится, дополнительная возня, легко сломать соседей и вообще зачем?
Я думаю объяснение может быть вот в чем: в то время менеджмент Микрософта хвалился тем, что берут студентов сразу после университета и обучают их программировать продукты сами. Типа что студентов не портят другие компании и их сразу учат как надо. Реально, работящие люди без длительного индустриального опыта изобретают вот такое.
Я также видел микрософтовский API того времени (1995) для распознавания речи с помощью грамматик и для меня было очевидно, что человек, которому это поручили, никогда не видел других проектов, а просто с нуля изобрел велосипед и на него накрутил. Другие проекты (там был целый консорциум компаний на тему, в который входил и Creative Labs, в котором я работал в тот момент) сразу бросили заниматься своими разработками, так как тогда была распостранена идея, что если микрософт зашел в вашу область, нужно просто смириться и ползти на кладбище.
Реестр уже был ранее в Win3.1 и OS/2
Интересно, если всё дело в Windows, Microsoft и низкой квалификации программистов, самой популярной ОС в мире, то почему, например, в Linux продолжаются изобретения аналога реестра по сей день? (/proc, /sys, GConf, Elektra).
Реально, работящие люди без длительного индустриального опыта изобретают вот такое.
Все было совсем не так.
У реестра Windows — довольно сложная история. Как и у Windows вообще. Windows в начале 90-х было две — просто Windows (3.x, потом она стала 9x/ME и благополучно на этом померла) и Windows NT (она родоначальник всех соввременных Windows, начиная с Win2K.
Так вот, в Windows 3.0 изначально реестра не было, общесистемные настройки хранились в файлах win.ini и system.ini, имевших одноуровневую структуру разделов, а потому работать с ними было крайне неудобно. Реестр появился в Win3.1 как вспомогательный компонент для поддержки передовой тогдашней технологии OLE. Эта технология — предшественник нынешней COM — имела много интересных возможностей, (кстати, не все из них дожили до наших дней), но в основе ее было связывание друг с другом документов (в том числе — хранящихся в одном файле-контейнере), сделанных в разных программах. Поэтому для полноценной работы OLE система должна была уметь находить эти разные программы. А потому и потребовалось общесистемное иерархическое хранилище информации, об этих программах которым и был реестр. Ну, а в Win95 в реестр были перенесены и многие настройки из win.ini/system.ini — и это было шагом вперед, все-таки формат реестра был удобнее, чем одноуровневые ini-файлы.
В NT же реестр изначально использовался как общесистемное иерархическое хранилище конфигурационной информации ОС, причем — хранилище, независимое от файловой системы. В том числе, реестр использовался на ранних стадиях загрузки ОС, когда полноценная файловая система ещё не была доступна. Изобрели этот реестр, естественно, люди из команды разработки NT (ядро этой команды было родом из DEC), у которых как раз с индустриальным опытом все было нормально. Так что студенты без опыта тут были не при делах.
Работа с реестром была изначально сделана через специальный API, редактировать его в «сыром» бинарном виде и не предполагалось.
Нет, можно было, наверное, не устраивать централизованное хранилище, а хранить всю конфигурационную информацию в фаловой системе (как в Unix), но у этого подхода был свой недостаток: в разных версиях ОС эта информация оказывалась в самых разных местах. В результате, например, программные пакеты от GNU, чтобы ими можно было пользоваться в разных *nix, имели в своем составе специальный скрипт ./Configure который проверял все эти закоулки файловых систем и записывал реально используемые в данной установке ОС пути в переменные окружения, на основе которых потом ставился в систему пакет.
Короче, резоны делать реестр в том виде, в котором он был сделан, были.
Ну, а дальше была долгая история о том, как обойти ограничения реестра. Например, очень интересно выглядело хранение конфигурации программ на .NET Framework, большая часть там зранилась как раз в конфигурационных файлах в папке с приложением, но это была уже другая история.
Полностью с вами согласен, но хотелось бы особо выделить тонкий момент.
реестр изначально использовался как общесистемное иерархическое хранилище конфигурационной информации ОС
Особо следует подчеркнуть: реестр изначально хранил в себе конфигурационную информацию самой ОС. Никто не призывал хранить в реестре конфиг сторонних приложений. Где-то же надо хранить условному приложению Калькулятор координаты положения своего окна и включенный режим работы перед его закрытием. А от того, что сторонние приложения гадят в реестр своими конфигами, процесс чтения реестра занимает больше времени. В запущенных случаях ОС вообще не может выполнять базовые операции, ожидая каждого ответа реестра по несколько секунд.
Про OLE я хорошо помню - книжка про OLE 2 была топ-бестселлером 1995 года в магазине Computer Literacy Bookstore в Silicon Valley, а люди, у которых стояло в резюме OLE 2 - были самыми горячими специалистами на рынке и требовали баснословные по тем временам зарплаты. Тогда возникла движуха с идеей "в будущем никаких отдельных приложений не будет, а все программы будут plug-in-ами Микрософт Ворда". Но такого будущего не случилось, а вот редактировать попорченное registry несколько раз мне пришлось (правда уже забыл детали).
Вообще с OLE и registry получилось "гладко было на бумаге, да забыли про овраги". Пока чисто микрософтовские программы обменивались информацией друг с другом - все было более-менее, хотя эти OLE объекты делали все медленно и это раздражало. Но когда куча программистов из других компаний, которым лень все подчищать после каждого апдейта и некоторые из которых делают на отцепись, чтобы прошли тесты - когда они все начали это использовать, и потом оно крэшилось и происходило registry corruption - вот тогда туши свет бросай гранату.
Тогда возникла движуха с идеей «в будущем никаких отдельных приложений не будет, а все программы будут plug-in-ами Микрософт Ворда».
ЕМНИП, немного не так — идея была в том, чтобы центральным элементом в работе пользователя с компьютером была не программа (не важно, Word там иди что), а документ. OLE 2 мыслился как основа для этого документоцентричного мира. Замах был большим: например, OLE 2, в принципе, давала возможность редактировать вставку в основной документ (например Word) сделанную другой программмой, прямо по месту в окне основной программы. И программы из MS Office это умели (пользовался). И все нужные для этого интерфейсы были вполне описаны, так, чтобы эту возможность могли использовать и сторонние программы. Но в реальности все это было зверски сложно в реализации, наверное, поэтому и не взлетело.
PS Вообще-то программы для OLE 2 в реестр лазили только при установке и только через API, так что не они были основными виновниками повреждения реестра. Скорее уж тут больше постарались всяческие программы-ускорители Windows.
А вот составные документы-контейнеры, поддерживавшие OLE 2 были, мне помнится, действительно слабым местом.
практически все таки случилось, все программы- плагины браузера....
*** В NT же реестр изначально использовался как общесистемное иерархическое хранилище конфигурационной информации ОС ***
Согласен с мнением выше. Для использованием внутри ядра ОС в Windows NT registry наверное было оправдано. Я не сомневаюсь в квалификации команды из DEC. А вот потом наверное решили натянуть сову на глобус силами волюнтаристских менеджеров и студентов, и для Windows 95 сделать это для всех приложений (или кусками даже для Win 3.1 for Workgroups).
Короче, тяжкие времена были.
Ну, тихий ужас был не в множестве файлов (более другие системы не просто прекрасно себя чувствуют с /etc, но еще и заводят conf.d и прочие инклюды), а в отсутствии систематизации этого всего (того самого /etc).
Проблему решили радикально, отрубив хвост по самый череп.
Я успел поработать даже с Windows 2.1 и далее с Win 3.0, для которого написал графический редакторик в 1990 году в Москве в совместном предприятии АС, которое потом стало Steepler и распостраняло Windows в СССР. У меня был даже емейл в домене .su :-)
> хаос увеличится, дополнительная возня, легко сломать соседей и вообще зачем?
насколько помню они в то далекое время слегка двинулись на object oriented development (OLE и пр.), причем эту лабуду (registry win3.x) также сделали на NT, имея в виду в одном файле иметь всю иерархию системных объектов и связей между ними т.е. системную конфигурацию как это тогда понимали, конечно это сразу вызывало вопросы, но на словах выглядело достаточно научно и пр.
Да, лично если такой выбор возможен предпочитают именно ini . Программа работает прекрасно после переустановки Windows и т.д.
Но в больших проектах как правило без правки реестра всё равно не обойтись.
Программы должны хранить свои настройки — там где сейчас большинство и хранит — в AppData. И — да, делить на Local и Roaming. И винде стоит заиметь кнопочку «Подготовить бандл для переустановки» — которая сохранит все из AppData/Roaming и отдаст юзеру. И после реинсталла его накатит обратно. И программы сразу найдут свои настроечки. А то я заманался вручную профили Лисы таскать
Игры — ну им логично хранить сейвы в Documents, как сейчас. Потому что при переустановке — я понесу «Документы» за собой.
На счет реестра не знаю, но вот Universal Windows Platform (UWP) это вообще какая-то жесть. Мало того, что она создает папки на диске, в которые без танцев с бубном не залезешь, так еще и иногда "теряет" их. И они либо впустую место на диске занимают, либо вообще винда не может переустановить программу, пока саму винду не переустановишь.
Тогда программу можно было бы переносить простым копированием.
Вы удивитесь, но всё это уже есть в реестре много лет: и права доступа на ключи, и виртуализация ini-файлов при помощи реестра, и подключение собственных файлов реестра, которые могут быть где угодно, хоть на другой машине.
Если автор программы позаботиться, то программу можно будет легко переносить. Все механизмы для этого есть в наличии.
Если приложение может писать в 100500 веток реестра без чёткой семантики названий (придумывая свои а не следуя общим правилам), то потом искать это замучаешься.
На мой взгляд, проблема в том, что микрософт постеснялась в своё время «всех построить» и решила, что всё само собо организуется. В результате все пошли кто в лес кто по дрова.
внутрь файла .REG можно встроить исполняемый файл (бинарник) с функцией автоматического выполнения
Я давно уже взял за правило: прежде чем .reg запускать на добавление - открывать его редактором и одним глазом проглядывать. А то мало ли что в крякнутые программы свободно распространяемое ПО насуют...
Тезисы и выводы в статье притянуты за уши.
Майки давно рекомендуют не хранить в реестре ничего из локальных настроек.
Реестр решает несколько другие проблемы.
Грубо говоря с помощью реестра Windows знает где и какие программы лежат, что они умеют, какие файлы могут обработать, и как могут взаимодействовать между собой.
Ну и плюс свои настройки там хранит - позволяет управлять ими через доменные политики.
Есть куча статьей, гайдлайнов и бестпрактис как, где, что может и должна делать программа написанная под винду.
Другое дело что "программист не читатель, программист писатель" - все ложат большой и толстый на документацию и делают как захочется левой пятке менеджера после дождика в четверг.
Пожалуй единственный способ надавить на программистов - это сертификация. Но если слишком закрутить гайки, на нее все дружно забьют. Поэтому даже сертификация очень лайтовая. Собственно можете сами почитать. Там реестр почти не упоминается. Только секция автозапуска. Потому все разрабы и чудят с реестром как хотят.
Мне нравится реестр тем, что почти вся винда настраивается одним кликом и перезагрузкой.
Всё.
Притом, некоторые конфиги кочуют еще с XP (Да здравствует win совместимость)
К слову, это касается и любой проги, пишущей конфиги в реестр.
Чего у винды не отнять — это того, что практически всё в ней можно сэмулировать. Пишет программа себе спокойно так в реестр и не знает, что в системе тихо жужжит мумулятор, и на деле всё пишется в ini-файлы.
А миллиарды пользователей — каждый бог на своей машине — тогда даже не подразумевалися еще.
Странный автор. Пользоваться реестром толком не научился, психанул и вылил всё на бумагу, отсылая к *nix системам пытаясь совместить несовместимое.
Реестр windows отличнейшее решение. Да, не без минусов, но уж получше бардака в *nix системах. Изврат, вроде докеров и кубернетес (которые работают на 30 % менее производительнее чем могли бы при прямой работе с железом), мог родится только на никсах, так как бардачный бардак под названием "зависимости" - это ад для любого разработчика.
Реестр - упорядоченный хаос, у которого есть хорошая документация. На *nix системах никогда не будет чего-то подобного, а уж про документацию я вообще умолчу. Если коммерческие системы обязаны предоставлять документацию, то написание документации на свободное ПО - это лишь каприз разработчика, захочет - напишет, не захочет - его никто не сможет обязать.
Да, не без минусов, но уж получше бардака в *nix системах.
К сожалению, бардак есть везде. В частности, в конце 90-х про Windows было популярно выражение «DLL Hell» — связанное с тем что программам часто требовались свои версии DLL, которые нерадивые разработчики, не мало не беспокоясь о других, ставили в системные папки, перезаписывали существующие версиии и т.д.
Вообще-то для Windows изначально существовали правила, как нужно обращаться с такими общими DLL — но далеко не все разработчики им следовали. А так как это были независимые фирмы и фирмочки, то у MS было крайне мало возможностей призвать их к порядку.
Фундаментальной проблемой реестра стала его открытость внешнему миру
Ничего подобного. Никакой сторонний софт не срет в реестр так тупо и обильно, как сама винда.
Примеры кошмарного программирования вокруг нас. Выученная беспомощность