I think I'm in a similar boat, great criticism of the user dirs. The directory structure seems too wishy-washy. Users can tweak where the actual directories are, and there are descriptions for what each env-var or directory should have, but the divisions made between types of file are not semantic enough, imo. And, agreed wrt temp files or cache files. There's /var/tmp or /tmp already, /usr/local/tmp, /usr/local, and so on. Permissions 'being weird' on most distros is something that can be addressed or fixed; no different than pushing people to change to XDG. In fact, it might be more beneficial to more projects if we get better-standardized "scratch space"s.
But then we'd be running into another cobbled together standard, with an even uglier history: The Linux Standard Base hierarchy. Which I just learned died a few years back. Huh. Turns out the filesystem is not something easily wrangled... System paths are something I've thought would benefit more from being configurable with env-vars (maybe even in the kernel argument list on boot, or via grub?). The major differences between distro filesystems would be abstracted away to their boot settings.
/boot/grub/linux-dirs.conf when?
I see some benefit in abstracting utility directories behind an interface so application developers don't have to worry about it, but the way it's gone about seems backwards and highly dependent on your environment containing the right variables. It probably needs to be handled below the user/application layer.
That would definitely be the way to go, sadly I think the linux desktop has to much inertia and it can only solved in a different OS, called a different way with its own directory structure. Where package maintainers are instructed to not package or patch any app that do not follow sane standards, where a flatpak equivalent would not put stuff into the same directory as the user's files, where a rootless container or a vm hypervisor would not put its stuff in the same directory tree
While it is not dead, Gobolinux failed probably because it was still advertised as linux, so people expect linux to follow some standards. I have no idea how redox, haiku and serenityos are handling that stuff, I hope they have been smarter.
Serenity is basically the same. Haiku is too close for comfort, but it's simpler because it's essentially single-user at present.
You want a radical idea? May I try to explode your brain?
We have persistent memory now. You can put a few terabytes of nonvolatile storage in your DIMM slots, and it's cheaper than RAM.
If your computer's memory map is entirely directly-addressible storage, every byte of every file is right there in the address space, all the time...
Then you don't need indirectly-addressed storage any more. No drives of any kind. No files of any kind. It's all in RAM all the time. You can dispense with filesystems completely and just manage it via an in-memory database or something.
No more folders. No more 2-dimensional tree. Every block of data can be found in 26 different indices if you want. Individual blocks of data can be in multiple programs, or documents, at once.
All that '70s hard disk stuff can just go away now.
But we're too scared. All we know how to do are disk drives and files in folders.
I am intrigued by this. I have an SSD that I cannot use due to the lack of an M2 slot in my desktop. How is this accomplished? Do you need an adapter for M.2 to DIMM?
Memory corruption could be more disastrous due to its persistence, but given the RAM bus is faster than SATA... This might work!
Thanks a lot (belatedly..) for the links! I have something new to consider in my next build. I really like this idea, it allows for a ton of freedom and you could do some weird wizardry with it. Also a lot of data corruption, haha.
But then we'd be running into another cobbled together standard, with an even uglier history: The Linux Standard Base hierarchy. Which I just learned died a few years back. Huh. Turns out the filesystem is not something easily wrangled... System paths are something I've thought would benefit more from being configurable with env-vars (maybe even in the kernel argument list on boot, or via grub?). The major differences between distro filesystems would be abstracted away to their boot settings.
/boot/grub/linux-dirs.conf when?
I see some benefit in abstracting utility directories behind an interface so application developers don't have to worry about it, but the way it's gone about seems backwards and highly dependent on your environment containing the right variables. It probably needs to be handled below the user/application layer.