[AnIdiotOnTheNet]

> It'd be nice if Windows had as nice of a filesystem organization story as any linux distro.

...are you serious? There's a lot of words to describe the Linux filesystem organization and 'nice' is definitely not one of them. Windows file hierarchy has some problems to be sure, but at least it doesn't scatter every application's files all over the hierarchy and require a specialized tool and database to track which ones belong to which applications.

[pizza234]

What do you refer, specifically?

Based on "application's files all over the hierarchy" it seems you talk about configuration files (data files can be spread all over, in any operating system; binaries in Linux reside in a few directories (/opt and /usr)).

If you refer to gconf/dconf, AFAIK they require a specialized tool but they're not scattered (you interact through the tool, after all, so they're centralized).

Possibly you refer to the Freedesktop configuration files. Those are definitely scattered, and some concepts are very obscure (the defaults system is indeed terrible, as it's scattered, and it has different concepts of default). However, they don't require specialized tools - in my experience, they're always text files.

[jcelerier]

> binaries in Linux reside in a few directories (/opt and /usr)).

and .local/bin and $HOME/bin and $that_path_where_python_and_ruby_put_stuff and let's not forget that one executable which is in /usr/lib/name_of_the_app for some reason...

[pizza234]

There's no limit to where applications can put their files, and this applies to any operating system, so complaining about, say, version managers has nothing to do with a given operating system.

If you take Windows, you're going to have %USERPROFILE%.pyenv for example, when it comes to Python (pyenv).

It's unlikely, but not impossible, that a binary ends under /usr/lib, since it wouldn't be in $PATH. If it's there, it's likely invoked via a script somewhere, and this is not good practice, and again, not inherently Linux.

$HOME/.local/bin is not good practice, for the same reason (not being in the standard $PATH).

$HOME/bin seems actually a good place for placing user-specific binaries, since there must be one place for them, and I think it's a proper place.

[AnIdiotOnTheNet]

I mean literally the application and its files. A package for something like KeePassXC[0] places its assets, "shared" libraries, and binaries in disparate directories mixed with other applications binaries, assets, and libraries.

[0] https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist

Configuration files are a whole 'nother garbage fire mess, but that's true in Windows too so whatever.

[pizza234]

ok, you're referring to package management.

if you talk about configuration files, well behaved packages will differentiate removal and purge; the latter will remove configurations and data.

> [0] https://packages.ubuntu.com/groovy/amd64/keepassxc/filelist

what's wrong specifically with that? based on the list of files, the package is well-behaved, as it's placing the files in the expected locations (I personally didn't know about /usr/share/metainfo, but seems correct). also, it's not clear why the quotes in "shared" libraries; .so is a shared library extension, and it's proper design to make it available.

apt takes care of those files, so there's no problem. how it handles the data files should be described in the scripts, but this is up to the package maintainer.

Windows, for comparison, is hell, since applications install files pretty much where they want, and that's why Windows, in the long term, gets more polluted than Linux (worst offender - leftover DLL, which impact the system).

OS X could be the good reference for your isolation standards, but keep in mind that that level of isolation prevents reuse, and indeed, the open source package management reference is Brew, which has its own rules.

[AnIdiotOnTheNet]

As I said, what's wrong is that organizing files in this way is that it necessitates something like a package manager to keep track of which files are associated with which applications. This is not a "nice" way to organize things, it's a needlessly complicated one as evidenced by the operating systems, both current and historical, that don't do that and don't need a package manager.

> Windows, for comparison, is hell, since applications install files pretty much where they want, and that's why Windows, in the long term, gets more polluted than Linux (worst offender - leftover DLL, which impact the system).

Applications rarely install files (other than configuration files) outside of their own 'Program Files' directory. What you are saying was true until about XP, IIRC, but generally isn't today.

In my opinion RiscOS, NeXT, the original MacOS and current MacOS have the right idea with their single-object applications. It prevents reuse, yes, but the majority of "shared" libraries are used by exactly one application anyway, and the continued interest in container technology are evidence of all the problems caused by trying to share everything anyway.

[cycloptic]

I don't see how the current MacOS is any different from Linux there. For end-user applications you can have the user download an app bundle (equivalent to AppImage) or get it off the app store (equivalent to flatpak/snap). For random open source libraries and utilities, you still would want to use Brew or Macports, which are package managers.

[AnIdiotOnTheNet]

It's been a while since I've used a current (post-MacOS9) Mac. It used to be the case that the vast majority of applications were Application Bundles.

[pjmlp]

I do just fine with macOS UNIX userspace.

[cycloptic]

It's popular for Linux distributions to have a scattered hierarchy with a package manager, but it certainly isn't a requirement. Take a look at AppImages.

[AnIdiotOnTheNet]

AppImages are pretty great, when they actually exist for your applications. It is exceptionally disingenuous, however, to suggest that the existence of some AppImages invalidates the file hierarchy organization problems of any distro.

You might have been better to point out the existence of GoboLinux, but that is but one not very popular distro among many.

[cycloptic]

Please do not baselessly accuse me of being "disingenuous," I'm trying to help you. If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem. If you're saying you want all other distributions to be like GoboLinux, I doubt that would happen because that comes with its own set of other problems. Edit: You can do some pretty interesting things here with Nix/Guix too although that still requires a package manager. The reason I said AppImages is because that's currently the best method that doesn't require any package manager at all.

[AnIdiotOnTheNet]

> Please do not baselessly accuse me of being "disingenuous," I'm trying to help you.

Help me with what exactly? Am I in need of saving for my denial of The One True UNIX Way?

> If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem.

There are lots of reasons I don't use GoboLinux, not the least of which is that I don't think compiling applications from source is a reasonable application distribution method in 2021. As for asking application developers to make AppImages: why do you assume that I don't?

Regardless, the point is that the "Linux filesystem organization story" referred to by the parent is neither GoboLinux nor a bunch of AppImages and you are being disingenuous to pretend otherwise. It's a tired old Linux Desktop evangelism tactic roughly equivalent to "well, Linux is just a kernel...", which is to say that the argument is that what Linux Desktop (and by extension its filesystem organization) is is so ill defined that it can be whatever you want it to be -- provided you write most of it yourself, from the kernel up, like Android.

However there is a clear "way things are done" for the vast, vast majority of Linux distros and that is obviously what's being talked about here.

[cycloptic]

I haven't "pretended otherwise" or evangelized anything, please don't make these accusations at me. I can only offer you suggestions on what to do, I'm not going to argue about what the "right" way to do is as that's simply not interesting to me. The vast majority of Linux distributions may not do things the "right" way but they also support AppImages, so use that to your advantage. If you had no success in getting upstream to make AppImages then you'll have to make them yourself. It seems that's what a lot of flatpak and snap packagers ended up doing, just my observation.

To put this another way: We can sit here making the same complaints about Ubuntu and RHEL that have been made for decades, but what's the point? Let's do something about it. And if that doing something means we turn the whole system into AppImages, then... what else would you really want? It sounds like your problem would then be solved.

[AnIdiotOnTheNet]

> I can only offer you suggestions on what to do,

Why are you doing that? I clearly neither asked for, nor want your suggestions! That's why you come off as an evangelist.

[teh_klev]

Can I refer you to:

https://news.ycombinator.com/newsguidelines.html

Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

I have no idea how you got the idea that cycloptic was being disingenuous, evangelising or trying to save you "for my denial of The One True UNIX Way".

> I clearly neither asked for, nor want your suggestions! (from below)

On HN most people like to chip in what they think might be suggestions. Either say thanks, but no thanks, or just say nothing instead of being rather rude.

[AnIdiotOnTheNet]

> I have no idea how you got the idea that cycloptic was being disingenuous, evangelising or trying to save you "for my denial of The One True UNIX Way".

I have no other way to explain the sequence of events that occurred. I expressed doubt that anyone could think the Linux file hierarchy organization was "nice", they responded that it isn't "required" and that AppImage exists. What are they trying to convince me of? What "help" did my post suggest that I needed?

I'm sorry, I'm trying to be reasonable here, but no one has yet explained to me how else I could possibly have interpreted that post.