Hacker News Reader

Comment by IshKebab | Hacker News Reader

> because customers are afraid of root

You mean because that's obviously way more sane than spewing the installation of every piece of software all over the system.

There's a reason it's basically only Unix that works like that. Slightly disappointing that you were directly confronted with the problems of the FHS but still think it's better... because customers are idiots or something.

View on HN

> You mean because that's obviously way more sane than spewing the installation of every piece of software all over the system.

> There's a reason it's basically only Unix that works like that.

I think you're underestimating how common it is for software on both Windows and macOS (the former more than the latter) to spew its bits all over the system. In the case of Windows especially, this includes things like the Registry and events sent to Event Viewer.

With a proper package manager that keeps track of the installed files and a proper permission system, it doesn't matter where the files are.

As long as you don't move them around without notifying the proper package manager: which one, by the way? There is dpkg, and apt, and npm, and pip3, and...

If you install into the root hierarchy then you must use the one that your OS is using. Creating such a package for your application can be a nuisance but it really is not rocket science.

You can only use language specific packager managers like npm and pip3 if you install into a specific sub directory outside of OS file hierarchy conventions.

Disappointing? Sorry to read I've disappointed you, dear internet user. I've administered a lot of systems over the years, and they often contain tools I don't really know and didn't install. It's always much easier to look for things in the usual places, like logs in /var/log, instead of having to figure out where each random application decided dump its stuff.

I'm quite fond of the path of least surprises.

Splitting an installation across multiple locations has additional benefits. It's a good thing that the application user can't modify the binaries (which is pretty much enforced when the binaries live in /usr). You can achieve the same thing when dumping everything in /opt/$foo, but that's pretty much the worst of both worlds imo.

What do you think about something like Nix/NixOS?

not a *nix fan but professional computer science here; my limited understanding was that the Debian people took on their own methods of breaking things up and re-ordering them; there is no *nix standard despite multiple efforts at standards, only de-facto practices; powerful and arrogant people along with hurried and clueless people, repeatedly build setups that do not follow standards, as detailed in the post.

> It's a good thing that the application user can't modify the binaries

Why?

To prevent damage from malware running with user privileges. If the user really needs to modify the binaries, they can reach out for sudo or ask the sysadmin. It's such a rare and risky use case that it warrants a barrier normally being in place.

Malware running with user privileges on Unix can pretty much do whatever it wants already.

> It's such a rare and risky use case that it warrants a barrier normally being in place.

Users installing software is a rare use case? Ok.

As far as I know, iOS is the only OS that is _not_ like this.

macOS has /Applications, /Library, their equivalents under the user's home directory, applications that ignore macOS conventions and use XDG ones...

Windows has AppData in three variations, Program Files, Documents...

Android has /Android/data, apps that stick stuff in /storage/emulated

None of those are like what Unix does though. I'm not saying you shouldn't store configuration data in some other location to the app itself. That's quite reasonable.

What Unix does is mix up the contents of all the apps themselves. All app binaries are in `/usr/bin`. All libraries are in `/usr/lib`. All their data is in `/usr/share`. No other OS does that as far as I am aware.

When I built my own packages, back in the old days, I would never adhere to this standard. I found spreading different pieces and parts of the same app all over the filesystem to be a bit bizarre. If I built Apache, it was built with a prefix of /usr/local/apache_VERSION, with a link from /usr/local/apache. This made it easy to upgrade: I'd build a new version (with a new prefix), migrate the configs (if needed), change the symlink (which was really just for each of tracking the current version), then blow away the old version. This was back in the "servers as pets" days.

>it's basically only Unix that works like that

How are others systems doing it?

They keep all of the installation in one place. Config and cache data can be in different places but the program itself is in one place.

On Mac this is the app bundle. On Android it's the unzipped APK. I think NixOS does this too but I'm not too familiar with it.

Even Windows more or less does this - all the data is in c:/Program Files/The App. Well at least in theory. Windows is pretty messy.

Reply on news.ycombinator.com