What's always annoyed me with many operating systems is this need to organize based on function instead of domain. If I install an application named "Bob" then I want ALL of Bob's configuration to live within Bob. I don't want it split between different registry keys or /usr/local, /etc/, /var, /lib, etc.
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.
You are correct, from a user's perspective this seems like unnecessary complexity. But here on the system administration side of Chesterton's fence, these splits enable more secure, more robust and more reliable systems. Among others, this allows for improved backup and recovery, better storage efficiency, easier application of security patches and providing centralized configuration.
I think for all future development, the industry agrees with you. Chromeium, iOS, Android, and Windows Store apps all utilize packages and per-package storage.
We're just suffering from backwards compatibility for things made over 30-years ago.
That would be a directory called /bob right in the root dir, containing everything relating to tge bob app, including the firewall settings, both the distro defaults and the user layered, the executables, the image resources, the db libraries, the db store... never mind that the firewall is another package that needs those same settings...
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.
You're constructing an argument the person never made.
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!
> There's no need to duplicate dynamically linked system libraries in there.
> 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.
nixos symlinked world sounds about like sco open server.
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.
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.