5 ms·
Wasn't Windows Registry a (failed) attempt at unifying this stuff? Now, hear me out. The problem is not the location of configuration. The problem is the cri
by crabbone 3y ago
Wasn't Windows Registry a (failed) attempt at unifying this stuff?
Now, hear me out. The problem is not the location of configuration. The problem is the crippled and anemic way UNIX (and the likes) programs take configuration. These can only predictably take environment variables and command-line arguments. Both ways are crippled due to size limit (especially the command-line arguments) and structure (you cannot even have lists / arrays in environment variables). This is the reason why every application author believes they must write their own configuration, with their own (crippled) configuration format and logic for locating their configuration.
On the bright side, I think, systemd is moving towards making this mess more uniform. On the not so bright side, systemd doesn't appreciate the difficulties associated with the problem and doesn't seem to have any sort of plan moving forward. So, unit files are kind of configuration, but because the format is so crippled and anemic, they immediately added a way to source random external files for process environment etc.
Finally, systemd, even if they understood the problem well and put a good effort towards solving it are still powerless against the format in which system supplies input to processes. What really needs to change is all the family of execve, execlp and so on. This was always a stop-gap / bad idea, but it was OK for a while, before programs started to require more complex input. It should've died in the 80s... but today it is so deeply entrenched that removing it will take a very long time.
Another problem here is the approach that "everything is a file". So, the only way to provide configuration beyond command-line arguments and environment variables is a file... But, imagine an alternative reality in which OS is capable of providing basic data-structures, which can also be persisted and queried? Kind of like you do it with a relational database? I think this idea is so much not novel that it's older than most people commenting in this thread... And, even though this would make it so much easier for so many application authors to provide consistent and easy to inspect, better tested interface to their programs... nobody's doing that :) Because files are good enough.
- Roark66 3y agoHaving spent many years in the windows land I definitely get where you're coming from. However, I find the Unix way where everything is a file, much simpler to work with. Just take a simple task of copying a subset of some system's configuration to another one. On Unix it's just a matter of copying some files. On Windows (and our imaginary is that provides object storage) we would need to find the relevant objects, then write a script to export/import it (or mess with export/import tools for a while). Personally I see "everything is a file" as strength not weakness. In addition to my personal preference having a centralised configuration system not only restricts in many ways, presents a potential performance bottleneck, but also is an extra point of failure. Additionally, I think most Unix software uses a fairly simple text format for config files. There really is little reason for using anything else. If you need complex data structures use YAML. I've found many more proprietary binary config file formats on Windows (despite registry) than on Unix. So if the os would make something like this available there would still be no guarantee all apps use it. It would just be an extra thing to deal with for little benefit IMO.
- genman 3y agoActually, why not both? Why not have files and an database like interface for them? Even better, databases normally provide a query plan explanation, quite like what is demanded here.
- indymike 3y agoI once thought the same, but there is not a universal answer on how to store data that delivers the combination of performance, reliability for every use case. Files are the lcd and leave room for optimization - and end up being a nice abstraction to hide the inner workings of decades of different storage devices and apis.
- tqwhite 3y agoThough I use .ini, myself. I often think about changing to sqlite. It is insanely stable and provides all the goodness of a database. Since I speak SQL like a native, it would be easy for me to manage. But, I stick with .ini still because, 1) I have a great access module that I would have to rewrite and, 2) there's always a text editor and sometimes I'd have to add a sqlite UI. Sounds like work to me.
- _dain_ 3y ago>If you need complex data structures use YAML. Please god no. JSON or TOML at most. YAML is too complicated.
- Spivak 3y agoFor who? Yaml gives you all the standard containers, tools to avoid repeating yourself, lord of ways to format strings so they stay readable and arbitrary object serialization. Yaml only gets weird if you want to use complex objects as dict keys but that complexity is on you then.
- _dain_ 3y ago>Yaml gives you all the standard containers So do JSON and TOML. If you think you need more than what they provide, something has gone very wrong. >tools to avoid repeating yourself, Bad. Config is not code. Settings should be explicit. DRY is not helpful. Because of the lack of anchors/aliasing/variables etc, JSON has the nice property that you can parse it with exactly one upfront memory allocation: N bytes of JSON requires at most N words of memory. >lord of ways to format strings so they stay readable Bad. Too many ways: https://stackoverflow.com/a/21699210/6107981 https://stackoverflow.com/a/21699210/6107981 No normal human being can remember all the rules for how a string gets parsed. Therefore it isn't actually human-readable or human-writeable, despite masquerading as such. >arbitrary object serialization You can write out the fields as a JSON object. If this isn't enough, then what you're trying to serialize doesn't belong in a human-readable text config file. >Yaml only gets weird if you want to use complex objects as dict keys but that complexity is on you then. This assumes the guy who wrote the config schema is the same as the guy who has to later use and edit it, which is seldom the case. When people do needlessly complicated config like this, they're taking an enormous stinking shit on my lawn for me to clean up.
- jeroenhd 3y agoI significantly prefer using DConf over brute forcing some new configuration file format. It works like the Windows registry, but now the fields also have native support for a description that tells you what the settings do.
- Joe_Boogz 3y agoSo like Windows Group Policy?
- Dalewyn 3y ago>Wasn't Windows Registry a (failed) attempt at unifying this stuff? The way I see it, Windows Registry "failed" for no reason other than a handful of CLI neckbeards refusing to let go of individual .ini and other such plain text config files written however and scattered wherever they damn well please. The Registry is really well designed, it's a central repository of settings for everything that exists in that Windows installation including Windows itself. It can hold data besides plain text. It can be manipulated both by the CLI and GUI and is easily accessed, either individual keys or in batches. It can accomodate multi-user environments independently of the file system. The Registry still exists and is still used by most Windows programs, though unfortunately even Windows is starting to disregard the Registry with its newer developments. The Registry for me is a reminder that the programming industry is, in many ways, one of the most regressive industries ever.
- offices 3y agoIt's funny that editing the registry is considered black-magic in Windows world while elsewhere we often edit untyped unchecked text files.