[BlinkenBlinken]

Current state of the UNIX file hierarchy is a mess. Many incarnations of GNU/Linux systems didn't contribute to a more elegant yet simplified directory structure. Just pick the one you like the most and serves the purpose of your desires.

As for merged /usr, recently using Arch Linux for desktop use. Works decent enough to getting things done.

[tenebrisalietum]

Elaborate. I don't find the UNIX file hierarchy complicated, but there are some historical quirks and artifacts (like `/var/lib`). The difference between `/usr/X` and `/X` is about the worst of it IMHO.

Everything important is usually at most 3 levels deep and the short names are very convenient (versus "C:\Users\xxx\Documents and Settings").

Compare to things like Windows: c:\windows\system32 that has 64 bit stuff in it, the whole c:\windows\syswow64 b.s., c:\Program Files (x86) and c:\Program Files, the hierarchy in the Windows registry which has "Windows", "Windows NT", "Microsoft Windows" (probably), etc.

[jeroenhd]

All file system hierarchies contain complicated rules and systems that have been built in by the people who designed them decades ago.

I still don't know what I'm supposed to do with /usr/local, what the difference is between /usr/share and /usr/local/share, what the point of /opt is if programs install their files and dependencies in /usr(/local?)/lib anyway and why I have /usr/lib, /usr/lib32 and /usr/lib64 when only two directories and the right environment variables should suffice.

There are subfolders in /dev that feel like they don't need to be subfolders. There's /tmp and three other places that contain temporary files that should get cleaned on boot. PID files appear strwen across /var/run and /tmp/<magic directory name>.

/var can contain just about everything. Most of /var feels like it should actually be inside /var/spool but you're not going to see much in there except for a mail queue to nowhere on desktop Linux machines.

Then we come to the XDG standard everybody just blatantly ignores that tries to bring order to the chaos that is program-generated files in the home directory.

And then there's also snap. Snap looks at any directory convention, laughs, spits in your face for good measure, and creates a folder called "snap" wherever the fuck it wants to. I'd purge it from my system if the snap people hadn't convinced some tools I use to support it as the main distribution method.

I'm sure there are guides out there that explain every directory and their purpose. I've read one of those guides, noticed that at least a third of the common programs I use clearly haven't read it, and forgotten the details already. The file hierarchy of a fully-fledged desktop Linux is kind of a mess, and that's just what you get when your core system is formed by combining the work of hundreds or thousands of volunteer projects.

[Arnavion]

>I still don't know what I'm supposed to do with /usr/local, what the difference is between /usr/share and /usr/local/share, what the point of /opt is if programs install their files and dependencies in /usr(/local?)/lib anyway [...]

/opt - You put everything related to program foo under /opt/foo . Binaries, libraries, configs, it doesn't matter; all go under /opt/foo. Everything specific to foo should be under /opt/foo, such that deleting /opt/foo also wipes all traces of foo from your system.

/usr/local - Equivalent to /opt/jeroenhd, with a substructure mirroring /usr, ie top-level bin, lib, share directories. If jeroenhd compiles multiple things foo and bar and they all end up under /usr/local, removing them after the fact is hard due to the difficulty of determining what files are foo's and what are bar's.

You say "if programs install their files and dependencies in /usr(/local?)/lib anyway" as if you don't have a choice, but that's up to the programs. Eg anything with a configure script should let you configure the prefix to /opt/foo so that it installs there instead of /usr/local

>[...] and why I have /usr/lib, /usr/lib32 and /usr/lib64 when only two directories and the right environment variables should suffice.

/usr/lib - Architecture-independent libraries

/usr/lib32 - 32-bit libraries

/usr/lib64 - 64-bit libraries

(For the Debian family the arch-specific libraries are mostly in subdirectories of /usr/lib named for the triple, eg /usr/lib/x86_64-linux-gnu)

Not sure which of these you'd excise to be left with only two, or what env vars would have to do with anything.

[throwaway48375]

One of my personal favorites is C:\Windows\System32\Drivers\etc\hosts.

[BlinkenBlinken]

I like to point out that I'm in favor of standardization of directories. Also understand the legacy argument since a lot of software, by default uses it's file location.

Directories like var, opt, usr need some rethinking. Hence the UsrMerge I presume?

This is what the current filesystem looks like: """ lrwxrwxrwx 1 root root 7 Apr 6 15:21 bin -> usr/bin drwxr-xr-x 3 root root 4096 Apr 6 15:30 boot drwxr-xr-x 17 root root 3400 Apr 6 15:31 dev drwxr-xr-x 67 root root 4096 Apr 6 15:32 etc drwxr-xr-x 3 root root 4096 Apr 6 15:30 home lrwxrwxrwx 1 root root 31 Apr 6 15:24 initrd.img -> boot/initrd.img-5.10.0-13-amd64 lrwxrwxrwx 1 root root 31 Apr 6 15:24 initrd.img.old -> boot/initrd.img-5.10.0-13-amd64 lrwxrwxrwx 1 root root 7 Apr 6 15:21 lib -> usr/lib lrwxrwxrwx 1 root root 9 Apr 6 15:21 lib32 -> usr/lib32 lrwxrwxrwx 1 root root 9 Apr 6 15:21 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 10 Apr 6 15:21 libx32 -> usr/libx32 drwx------ 2 root root 16384 Apr 6 15:20 lost+found drwxr-xr-x 3 root root 4096 Apr 6 15:21 media drwxr-xr-x 2 root root 4096 Apr 6 15:21 mnt drwxr-xr-x 2 root root 4096 Apr 6 15:21 opt dr-xr-xr-x 173 root root 0 Apr 6 15:31 proc drwx------ 2 root root 4096 Apr 6 15:32 root drwxr-xr-x 17 root root 520 Apr 6 15:34 run lrwxrwxrwx 1 root root 8 Apr 6 15:21 sbin -> usr/sbin drwxr-xr-x 2 root root 4096 Apr 6 15:21 srv dr-xr-xr-x 13 root root 0 Apr 6 15:31 sys drwxrwxrwt 9 root root 4096 Apr 6 15:32 tmp drwxr-xr-x 14 root root 4096 Apr 6 15:21 usr drwxr-xr-x 11 root root 4096 Apr 6 15:21 var lrwxrwxrwx 1 root root 28 Apr 6 15:24 vmlinuz -> boot/vmlinuz-5.10.0-13-amd64 lrwxrwxrwx 1 root root 28 Apr 6 15:24 vmlinuz.old -> boot/vmlinuz-5.10.0-13-amd64 """

What goes where. I have been a sysop for a long time. Came from a time that computers where simple by comparison to now. Limited in functionality, but just worked. Seen many changes. I the past there were less directories. Though time we added a couple. E.g. opt, srv, media. Or the dev, proc and sys. What happens when something new popup? Create a new directory? Possible. Maybe now is the time to consolidate and rethink certain directories? Better names? E.g. system instead of usr. Location where put libraries, maybe consolidate into one? Location for data (stores)? Etc.

Off cause current hierarchy isn't complicated. But it's not intuitive and can be confusing. Even the windows directories are better readable? I think naming must be more intuitive. Especially with regards to new or inexperienced user. Just an idea. Make unix accessible to everyone is a good goal.

Starts with readability in my opinion.

Oh, didn't mention software development. Which is an entire different ballgame with respect to device files, magic files etc. Ugly to boot. The mantra everything is a file is also not true.

It's just my opinion.