Quora argues about Windows registry
-
40. (fuck you Discourse!)
Looking at the list, it's only the ones that make sense to have a global default (file manager, window manager, menus). Other applications will create their default configs in user's directory on first run.
I'm not sure what the defined behaviour is for creating per-user configs if something already exists in
/etc/xdgthough. Again, I let the toolkit I use handle that stuff so I never poked around it manually.
-
What is the point? Even in Windows registry each application is free to do
HKLM/appname/versionorHKLM/appname/snowflakeorHKCU/appname/asshole. Windows registry is/etc+/sysmounted on a shitty filesystem, there is nothing special about it and does not provide any standard.
-
I'm not sure what the defined behaviour is for creating per-user configs if something already exists in /etc/xdg though.
If there is per-user config it takes precedence. First the system setting is sourced then user setting, so first Fedora's
bashrcthen my~/bashrcare sourced.
-
No, I mean if there's a config file in
/etc/xdg, should you just make a copy of that for the user, or just generate your own defaults regardless? The first makes more sense to me, but I won't claim it's what the standard says.
-
What is the point? Even in Windows registry each application is free to do HKLM/appname/version or HKLM/appname/snowflake or HKCU/appname/asshole. Windows registry is /etc + /sys mounted on a shitty filesystem, there is nothing special about it and does not provide any standard.
OH NOES I will commit ritual seppuku immediately!!!!!
Yes, you're right, but you have to go out of your way to do it wrong, since all the normal "hey save this setting k? thx" functions use the correct paths.
If people are really really dedicated to doing it wrong, there's basically nothing you can do to stop them short of making computers no-longer-general-purpose.
-
If there is per-user config it takes precedence. First the system setting is sourced then user setting, so first Fedora's bashrc then my ~/bashrc are sourced.
But that's still the whole file at a time, right?
You can't do the whole systemwide vs. user thing in Windows where your user file only contains the settings the user has specifically changed, and the rest are served from the global config until such a time the user touches them. (aka: the correct way to implement this)
-
Oh Lunix machines, how do you tell the OS that a bit of configuration data is system-wide and not user-only?
One setting file in a system-wide settings location (owned by root), another setting file in user's home folder. Then the app loads both files and merges the keys manually.
Or doesn't. No way to tell in general.
How do you handle race conditions if the same app is running under multiple users, and both want to change a system-wide configuration?
App needs to handle it manually. Probably using some kind of locking mechanism (lock file or advisory locks).
Basically, it's up to the app, OS makes no guarantees there.
-
You can't do the whole systemwide vs. user thing in Windows where your user file only contains the settings the user has specifically changed, and the rest are served from the global config until such a time the user touches them. (aka: the correct way to implement this)
It is actually the common use-case, usually there are tones of settings set in system setting file e.g. this in
/etc/appname:SETTING_ONE=true SETTING_TWO=falsenow if you also have this in ~/.appname
SETTING_ONE=falsethen only that setting will be overridden.
-
NeXTStep / OpenStep (what OS/X derive from) went a step further, viz, in order of increasing priority:
/System/Library/…
/Network/Library/…
/Library/…
~/Library/…Bearing in mind that the /Network tree would be an NFS mount point. All your configuration shit goes into one of those directories (or subdirectories, for example fonts go into *Library/Fonts, system fonts in /System/Library/Fonts, organisation or section specific fonts in /Network/Library/Fonts, Aftermarket fonts for this machine only in Library/Fonts, and so on.
In a network environment, ~ is usually a mount point as well, so you can flit from machine to machine without worry. This still holds for OSX, although it's rarely used. But it's what a real networking OS looks like.
-
usually
I don't like usually.
Why doesn't this OS take care of this, so that's GUARANTEED to be the behavior?
Trusting Linux application developers (a.k.a. the guys who can't even get NetBeans to render the correct font size) to get details like this right is a disaster in the making. Because those rampaging monkeys have NO sense of detail and NO particular desire to make quality software.
-
Yes, you're right, but you have to go out of your way to do it wrong, since all the normal "hey save this setting k? thx" functions use the correct paths.
Yes but that is a framework that provides
hey save this setting k?not the OSIf people are really really dedicated to doing it wrong, there's basically nothing you can do to stop them short of making computers no-longer-general-purpose.
Same for conforming apps in an other OS. Qt has
QtSettingsthat uses the standard location, so as long as I do not reinvent the wheel everything is great on all Windows, Linux and OSX.
-
I don't like usually.
How many times do you have to decide what app to use? By using an app, any app, you are trusting the app develoers. If you spend time installing and using any non-trivial app, you better read the manual.
Why doesn't this OS take care of this, so that's GUARANTEED to be the behavior?
Only smart phones can do that (because they are very closed), any generic purpose OS cannot guarantee this. This is the trade-off between liberty and comfort.Trusting Linux application developers (a.k.a. the guys who can't even get NetBeans to render the correct font size) to get details like this right is a disaster in the making. Because those rampaging monkeys have NO sense of detail and NO particular desire to make quality software.
Do not use shitty applications, I do not waste my time on them. Those applications I do use are either trivial, or I will have to also spend time and read their manual/documentation. It also means if documentation is bad, it is shitty, do not use it.
-
Yes but that is a framework that provides hey save this setting k? not the OS
I'm 99% sure the OS' own API functions for dealing with the Registry shove stuff in the correct paths by default but I'm too lazy to look.
By using an app, any app, you are trusting the app develoers.
That's why I try to avoid open source apps.
Only smart phones can do that (because they are very closed), any generic purpose OS cannot guarantee this.
Well duh, but you can at least make the right thing easy and the wrong thing difficult.
-
Well duh, but you can at least make the right thing easy and the wrong thing difficult.
How many Windows applications still try to install to
C:\? Or store settings in the wrong place? It's just about as much trouble as it is on Linux to do these things wrong. You can't forbidfopenandfwriteequivalents. Which means you're fucked by definition, because some assholes will try to save shit on their own in"C:\Documents and Settings\" + username.toString() + "\ShittyApp\settings.lolbinary".How many times did we see those around here? And how many times it was demonstrated that doing it properly is actually easy, but that didn't stop the dumbasses in question to do it wrong.
Just for reference, for
QSettingsmentioned above, you give it company name and application name on init and just chuck stuff in. It worries about whether it should be a text file, a registry setting or whatever the hell else. So proper way is not hard.
-
Well duh, but you can at least make the right thing easy and the wrong thing difficult.
When was the last time you directly programmed anything in
Win32I did that a very long time ago? Most likely you use.netframework or MFC or Qt (well, perhaps not you because you hate opensource).
Same is also true for any application in Linux. If application writers stick to proper frameworks (Qtis the best, but there are others) you will not need to worry about where to stuff your configurations.
-
How many Windows applications still try to install to C:? Or store settings in the wrong place?
Windows is bad THEREFORE IT IS OK IF LINUX IS ALSO-BAD!
Brilliant logic, you are super genius man, I bow before you.
-
That's exactly the way it's done in Linux.
Like you said :
@blakeyrat said:aka: the correct way to implement this
-
Where did I claim that? You asked about how Linux stores settings, I answered. You then went on about how people do it wrong on Linux. People do stuff wrong every chance they get. There is a standard easy way and a harder shitty way. Other than implementing an equivalent of iOS store you can't stop them from fucking shit up.
Semi-relatedly, the first (alphabetically) settings directory that's in the wrong place on my system?
.adobe. The more things change the more they stay the same...
-
Well, the first question is where are you going to keep this files? If your system doesn't specify a centralized location to keep all settings files, you're gonna have trouble.
So given that you're keeping all your settings in the same place, the question is whether you keep them in text files or some kind of database. Text files are good for settings that are written by users and read in on program startup, but for data that is changed programmatically at runtime, a database provides far better performance and stability. Pretty sure <span title="
both Linux DEs keep their settings in a registry by now. So if you're gonna be keeping settings in a central location, and you're gonna be using a registry, what exactly is the advantage of splitting that up into hundreds of little files, again?
-
with no way to back it up
?
log
Tracking changes in Windows registry
Is there a way to track changes in Windows registry? I'd like to see what changes in the registry are made during installation of various programs.
How to Track and Audit Registry Changes - MorganTechSpace
This is a step-by-step guide on how to track registry changes by native windows auditing. Also, report who changed, removed, added a registry key or value.
no consistency constraints, you can put anything anywhere with any value with no quibbles from the registry.
?
I mean, granted it's basically all stringly typed, but still...
And since it's separate and hidden from the file-system
Seperate, no, hidden, yes...
it doesn't get backed up most of the time
WTF kind of failure backup solution doesn't backup hidden files?
Granted there are... troubling... things about the registry, but honestly, it does its job pretty damn well for what it is.
-
Linux application developers
!=
guys who can't even get NetBeans to render the correct font size
Therefore
rampaging monkeys have NO sense of detail and NO particular desire to make quality software
Is an unsupported, ad hominem generalization. The implication that the cause for quality control problems is that they're Linux application developers is uncalled for
-
for data that is changed programmatically at runtime, a database provides far better performance and stability.
Performance of reading or writing settings should not be an issue. Ever.
-
Was Windows 95 even on floppy disks?
I bought it new on 3.5″ disks with a 486/100 PC in or around September 1995 — there were 13 of them in the package.
-
Do not use shitty applications
If that wasn’t easier said than done, I wonder if TDWTF would even exist.
-
if I need to edit a bit of configuration that applies to all users (say: the location of a network printer), but I also need the individual user to be able to override this information selectively, how do you accomplish that?
Typically that's done using a hierarchy of config. The way it generally works is: if an applicable command line option has been supplied, use that; otherwise, if there's an applicable environment variable, use that; otherwise, if there's an applicable user config file entry, use that; otherwise, if there's an applicable system config file entry, use that; otherwise use a compiled-in default.
On Windows it works almost exactly the same way, except that HKLM and HKCU registry keys are typically used instead of system-wide and user-specific config files respectively.
There's a standard Unix convention where the user's own home folder can be referred to with the name
~. User-specific config files are always inside the home folder tree, so they can be consistently referred to using names like~/.config/vlc/vlc-qt-interface.conf.The equivalent on Windows is the aliasing of
HKEY_CURRENT_USERtoHKEY_USERS\<sid>.1) Individual settings can be locked-down once set via the permissions system (Unix can only lock down entire files)
Not actually true. Only registry keys (analogous to config files and/or directories) have access control permissions; registry values (analogous to individual settings inside a config file) do not.
-
Windows registry is /etc + /sys mounted on a shitty filesystem, there is nothing special about it and does not provide any standard.
It does herd the cats a little more effectively by restricting the API fairly severely compared to what you'd get with a general purpose filesystem. The major downside of that, of course, being that there's no reasonable way to incorporate documentation inside the registry keys to explain what the values do.
-
If people are really really dedicated to doing it wrong, there's basically nothing you can do to stop them short of making computers no-longer-general-purpose.
To the extent that the registry does discourage people from using it wrong, it does that exactly by implementing a filesystem that is less than general-purpose.
-
You can't do the whole systemwide vs. user thing in Windows where your user file only contains the settings the user has specifically changed, and the rest are served from the global config until such a time the user touches them.
Yes you can, and this is in fact completely typical. Normally the only settings you'll find inside a user's own config files are those that the user has set specifically.
-
I'm 99% sure the OS' own API functions for dealing with the Registry shove stuff in the correct paths by default but I'm too lazy to look.
Generally not, as far as I can tell. Any application can hammer any Registry key it wants. You usually need to be running elevated to make changes under HKLM; running something like Sysinternals' Process Monitor will quite often show you an attempt at altering a key under HKLM that fails, followed by another one altering the same key relative to HKCU that succeeds.
Very few Unix applications ever even try to make config changes under /etc; that's traditionally been the system administrator's job.
-
It's an obscure binary format that can only be manually edited with regedit
I have programmatically made changes to the registry many times without once invoking regedit.
-
Why don't *NIX/BSD systems have a registry?
*NIX/BSD systems don't have COM. Easy enough. Oh wait, we're going to swerve left into configuration convention vs centralization? Where's my
?
-
Are we pretending Win3.1 didn't have a thing called the Registry for OLE object handling?
-
I don't think we have to, no. In fact, I think it kind of improves the argument, since we can spend half our time confused about whether we're talking about the Registry or the Registry.
-
Perhaps we need this?
-
Since Win 95 != Win 3.1...no? I mean Win 95 was more or
lessyes Win 3.1 + bikeshed but...I thought OLE didn't take off until Win98+?
-
I was using it win Win 3.1 apps...
-
Well damn, I checked and OLE came out in 1990. I blame my brain-damage on working on a VB.NET app and/or trying to learn how a MUMPS application works.
-
trying to learn how a MUMPS application works.
Yeah, not a good idea. On the bright side, the doctors say that those memories have faded enough that they might be able to remove the restraints soon.
Filed under: and maybe even let you have a fork. No knives yet, though.
-
To the extent that the registry does discourage people from using it wrong, it does that exactly by implementing a filesystem that is less than general-purpose.
It certainly used to have key ways it Did It Wrong: it let you do atomic updates (good) but didn't let you update multiple values in a single atomic update. Interrupting a series of changes part way through would hose you anyway. I don't know if they ever fixed that.
The thing I never liked though was the proliferation of GUIDs. I can see why on one level, but I still think it made everything really opaque when it was never really necessary.
-
Normally the only settings you'll find inside a user's own config files are those that the user has set specifically.
Except that it's fairly common for programs to create a default or template user config file the first time they're run, or in the case of .profile/.login/.bashrc/.cshrc, for the user creation script to create them. These may have a few commonly-used settings enabled, and a bunch of others commented-out, so that all the user needs to do is uncomment them, if desired.
-
didn't let you update multiple values in a single atomic update
With a general purpose filesystem, you'd do that by building the new value set inside a config file with a different name, then rename it over the old one; filesystems generally guarantee atomic semantics for rename operations.
If I recall correctly, the Registry has no rename primitive.
-
These may have a few commonly-used settings enabled, and a bunch of others commented-out, so that all the user needs to do is uncomment them, if desired.
There are users who insist on setting every option available to them, no matter how obscure or detrimental to their experience. Thankfully, they're a fairly small minority, but they're very annoying as their proclivities make things worse for themselves and nothing you say will persuade them to let the program auto-configure anything. This sort of people are also just as inclined to edit the registry as a config file.
The only sane fix is to include an
id.10tproperty in there, commented out, that if uncommented disables the rest of the file's settings.
-
If I recall correctly, the Registry has no rename primitive.
It wouldn't have mattered if they'd implemented a multi-operation commit semantics. Then you could have done everything required to make an equivalent of a rename or atomic compound update within a single all-or-nothing action, the way any half-decent RDBMS does it. That would have been a quite acceptable alternative. AFAIK, they never really decided if they were doing a filesystem or a database and so missed the plot with both.
I suppose you could hack around it by creating a new GUID key with the values attached to it and then atomically putting the GUID into place in the redirection point somewhere else so that you get effective atomicity that way, but that would waste the old entry (no garbage collection, of course!) and in any case, ewwww!
-
This thread has taught me:
- configuration is not a trivial thing
- every OS provides their own optional/recommended solution
- you should use a cross-platform library that does it the right way for you
