Hacker News Reader

Comment by elric | Hacker News Reader

When I first started packaging software for $employer, we adhered to the FHS. Then we started shipping software to corporate customers, who have Policies and Rules and Expectations which are diametrically opposed to the FHS. They don't want logs in /var/log, nor binaries in /usr/[local]/bin, because then someone with root access has to be involved in the installation process. They don't even want an RPM if they can help it, for the same reason. In the end we revamped the whole shebang and everything lives in our own folder structure whose root can be anywhere, where everything can be owned by arbitrary users, because customers are afraid of root.

They don't care that this makes their installation less secure, because they are convinced that it makes things more secure. shrug

View on HN

Isn't that what /opt/{provider or package}/ is for?

* https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLIC...

* https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#op...

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

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

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.

What do you think about something like Nix/NixOS?

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

The XDG specification is more sensible, in my opinion - configurable user-specific directories for things like executables and libraries, with a sane default prefix of "$HOME/.local".

Nah, they want rpm so they can rpm lint it. Even if they are deploying containers because their security processes still require rpm.

And so you have to make just about everything in the package relocatable. Good fun.

I do think that the practices that evolved in early unix, and which are, after a modest amount of evolution, codified in the FHS, are not a good fit to modern systems, where software comes in packages, and you want to be able to deal with packages differently according to whether they come from the system package manager, vendors, internal developers, etc.

I wonder if we could have a rework of the classic layout where we have /usr/share, /usr/<arch>/bin, /usr/<arch>/lib, /etc, /var/lib, /var/cache, and /tmp, but then inside those, enforce a rule that everything is in a subdirectory named after its package. So you would have dropped your stuff into /usr/x86-64/bin/elricsapp/elricsapp, /etc/elricsapp/elricsapp.conf, etc. Then the customer sysadmins could have simply created those directory, chown'd them to a new elricsapp user, and installed your software as a normal user.

You'd either have an astoundingly long-winded PATH and LIBPATH, or have some procedure for collecting symlinks to everything in /usr/bin.

Just put "elericsapp" in a subdirectory under /opt or /usr/local and keep it simple. Why spread it all over the place?

Fair. The only reason to split it up is to make it easier to do things like putting the read-only bits on a read-only filesystem, backing up all the config in one go, etc.

Reply on news.ycombinator.com