There are basically two ways to organize a file system, by subject and by purpose. Linux prefers by-purpose organization, so executables go in /bin (or at leas

There are basically two ways to organize a file system, by subject and by purpose. Linux prefers by-purpose organization, so executables go in /bin (or at least something ending in /bin), configuration goes into /etc, libraries go into /lib and so on. This simplifies discovery and cross-application data management, the answer to "how do I find a library" is just "search those 5 directories, if it's not there then it's missing", but it complicates package management and makes it too easy for garbage to accumulate. It's also better for GUI apps, it's far easier to make a music app that lets you think of artists, albums and playlists, not directories, if all your music is in one place. Mac and Windows (mostly) prefer by-package organization, where everything related to a single application is contained inside that application's folder. This makes discovery harder, as now e.g. finding all applications that can open a particular file format requires you to check every single one. However, it makes package maintenance easier, removing an app just removes all its files. This approach complicates GUI applications and makes it impossible to escape the directory hierarchy, you can no longer make a nice music app if music files are strewn all around. No system clearly falls in one bucket or the other, the Windows registry is partially organized by purpose, so are parts of Mac OS's Library folders, while Linux has package managers like Nix, which organize by package. Ideally, we'd do by-package organization, and have some sort of per-user / per-process "union directories" (a bit like the /bin in Plan9) that would provide easy lookups for downstream applications.