I'm fine with there being conventions and categorizations, but I'd like to root node to be the application itself. Yes, I even want this for multiple users.
I know there are design arguments to / for the various different ways of organizing configurations, but IMO they are just inferior from at least this user's perspective.
We're just suffering from backyards compatibility for things made over 30-years ago.
No.
Or, if you really do want something so insane, well great news, you have snap and flatpak. If those are not complete enough examples of this shining vision, go ahead and show us how it's done.
The binary for my app could live in a hypothetical /apps/bob.
Its config could be in there too.
There's no need to duplicate dynamically linked system libraries in there.
If the app need a different version of a library than the one provided by the distro/os, it could vendor it (or link statically). Optionally it can vendor and still try to use OS version if they version is satisfied, but this is just a memory optimisation (disk isn't that expensive).
There's also no need to place firewall rules in there. I'm not sure where you got that from. Firewalls are beyond the scope of a single application?
As for making thing system-wide available, there's already a few solutions for this (symlinks being a very backwards compatible way of doing this on nixes).
For all its faults and poor UX execution (albeit, maybe things improved since I last used them) flat pack and snap have some good ideas!
> For all its faults and poor UX execution (albeit, maybe things improved since I last used them) flat pack and snap have some good ideas!
Hum, flatpak says hello.
Unlike the kernel, Linux userland is a not-backwards-compatible hell so the only way to make sure things don't blow up in a spectacular fashion is bundling the whole world that you need with your app, or hopefully that someone bundled the things that you need with a Flatpak Application Platform for you..
> There's also no need to place firewall rules in there.
> As for making thing system-wide available, there's already a few solutions for this (symlinks being a very backwards compatible way of doing this on nixes).
I'm pretty sure that if you're proposing a "app is a folder" specification, any application that has some system-wide rules it needs to install or suggests or toggle, need to live somewhere in the application folder. Icon customizations, firewall rules, mdns, upnp, those sorts of things.
If the application folder is the end-all, then it need to have some form of "$sysconfigdir overlay" folder if it wants to modify $sysconfigdir without actually being able to modify or spill over the actual $sysconfigdir (and therefore not being contained in the folder at all).
That is in fact how flatpak works: you're never supposed to write anything at the host /etc, you overlay things in your application folder XDG_CONFIG_DIRS and flatpak-aware applications read flatpak XDG_CONFIG_DIRS folders.
That is in fact how nix works: nix packages are supposed to be read-only self-contained folder in /nix/store/$hash-package-$version, and /etc happens to be a non-persistent cache thing that will be overridden sooner or later by a nix expression.
But that of course means that now you have several XDG_CONFIG_DIRS/$sysconfigdir lying around in your system.
I get that the actual ugly details are hidden away behind automation in the form of the special dsl and highly specified framework/structure, and maybe sane enough to use, and maybe adresses some pain point or two better than other arrangements.
Just remarking that I've seen 'everything is a symlink' before, and it's the exact opposite of a new idea.
Whether that means nix shares a bad idea with another bad system or this was one of the good ideas from an arguably successful system (for a time) I won't try to say.
It's still useful for a fleet of clients and servers in an enterprise environment though.
We might have differing opinions about that. (I've got experience for example in Windows kernel mode drivers and service development.)
Especially when there's some corporate "security" software in the loop. And that's the case you have to really code against.
Besides, registry is not a rocket even on a clean system.
Also note that performance isn't just speed either.
First... where are you getting this from? I just spent half an hour writing a an incredibly simple benchmark and all I see is SQLite being something like 20x slower than a registry query, seemingly caused by repeated locking & I/O system calls. This is on a trivial database with just 1 table with just 1 row, vs. a registry that's on a machine that's been running for years. If you have a benchmark that can disable the locking and get comparable performance, I'd love to see it. Not that it would mean anything though, given the next point.
Second, even if it were somehow faster... you'd be comparing apples to oranges. The registry has a bunch of things SQLite isn't designed for: security integration with the rest of the OS, a hierarchical structure, OS hooks for monitoring & interception, multithreaded access, etc. Have you tried doing these with SQLite before praising how fast it is?
> That said, on Windows you kinda have to use registry, especially on the kernel driver level.
Is it common for drivers to use SQLite to store configuration information in any OS? I dare say I've never seen this.
It's not. You're going to use your assigned registry hive for it.
I think it's silly to compare the two.
But they have to be well-written installers (many aren't). And anyways, lots of installers are written by companies which want to leave their footprint behind even if you do uninstall.
Finding orphaned registry entries is hard - it's not always clear what application put them there, and how to determine that the application is still installed.
nix solves this
The registry is almost never a good choice for storing...anything outside of the operating system itself, unless the data is somehow tightly coupled with a specific Windows install (e.g. an activation key). The idea of storing instance data in the registry is madness.
it gets around this issue by creating a gigantic systemwide or per user bucket of crap that inevitably ends up inconsistent.
since it is custom there is no good tooling for doing diffs and many developers treat it as quasi private so the config values are often not human readable.
there are management utilities that work ok, until they don't. then you have to start over because who knows, it's all just crap.
it's literally like a jerry seinfeld joke. you think configuration should be sensible, then everybody just sees this bucket and goes wooopty woopty woo and then it's just filled with crap.
bill gates probably sent emails about it. "i tried to look at the registry, but then it was just trashed."
that is the registry. a little shadow filesystem with a bizarre layout with weird and incomplete tools that is filled with crap.
It is also all in the spin. What if I told you over on this side of the OS table we too keep all our configs in this great single tree database, not only that, we keep our data in the same database, everything is accessed using the same simple unified interface, the api has about five calls, it is pretty great. It also has the amazing feature that physically separate devices can be merged into the same tree.
Preposterous! some would say. All in the same tree! Why you would get everything muddled up. you must have a separate tree for each device. and a special tree with it's own special access patterns just for configs.
But for real, people keep trying to reinvent the registry over in linux land. (cough) gnome (cough) and it is terrible.
It's a centralized, high-performance small key value store that's the alternative to writing a million config files in random places.
It's arguably much better in my experience. E.g. one of the never-ending headaches I always have on Linux is updating config files when a package updates. There's no automatic file merge in general (hence .pacnew and such) so you gotta do it by hand (and not everything is available with the foo.d/ hack). The registry already operates at the value granularity so it bypasses this kind of issue.
And as a developer you don't have to worry about some things you might not think about, like the trade-off between corrupting your config files with in-place updates vs. having to create a new file and replace the old one after every config change.