Hacker News Reader

Comment by pizza234 | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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.

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.

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.

I do just fine with macOS UNIX userspace.

Reply on news.ycombinator.com