> 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.
