Hacker News new | ask | show | jobs
by pizza234 1954 days ago
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.

1 comments

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.