Hacker News Reader

Comment by schmuckonwheels | Hacker News Reader

This post gets some of the details wrong. /usr/local is for site-local software - e.g. things you compile yourself, i.e in the case of the BSDs the ports collection - things outside the base system. (They may be compiled for you).

Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux.

/opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software. You're putting your $500k EDA software under /opt.

View on HN

I normally wouldn’t be this pedantic, but given that this is a conversation about pedantry it only seems right: you’re using i.e. and e.g. backwards.

My mnemonic is “In Essence” and “for EGsample”

I just remember the actual words:

* e.g. exempli gratia (or, in Spanish, ejemplo gratis)

* i.e. id est (literally means "that is")

"example given" is what I've found easiest to remember.

I like: "In Ether words" and "Example Given"

> Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux.

The Linux base system is managed by the package manager, leaving local for the sysadmin to `make install` into

> The Linux base system

There is no such thing as a Linux base system.

Separate components, separate people.

Hence the term Ganoo plus Leenox...

Well, no, my exact argument is that there is a base system, even if it is composed of assorted components. If you install Debian (or whatever) on a machine, the software installed by the package manager ships as a unified release that has been adapted to work together. I think it's reasonable to call that the base OS. And then, separate from that base system that is managed by the package manager, the local admin my install things into /usr/local.

If you can remove GNU coreutils and replace them with something else (like that Rust garbage) then you don't have a base system. You have a loose collection of packages around a kernel.

Replaces the GNU Coreutils with the Rusty ones on BSD

Which BSD ships GNU Coreutils?

Every occasion I’ve seen GNU coreutils installed on BSD, it’s been outside of the base and thus installed outside of /bin. Eg /usr/local or /opt/homebrew

BSD has its own coreutils, in fact they even predate GNU.

They're talking about Linux, the kernel. The kernel has no concept of a base system. There is initramfs and init.

Okay, that's true but other than the slight semantic point of "Linux" vs a "Linux distro" or "GNU/Linux" I don't think it matters. Whatever words you use to describe it, there is a base OS which is composed of a variety of components from different sources but which ultimately amounts to a single thing.

> there is a base OS

In most distributions yes, there is Linux and then there is userspace on top of it. What you call "base system" is actually part of userspace, which has nothing to do with Linux itself.

No, what I call the "base system" is the result of running debootstrap, and encompasses all the packages that make a complete operating system. The kernel is just one part of the OS.

> Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it

Good grief. How does this end up as the top comment on HN of all places? I'll bet anything that this author also thinks that systemd is way too opinionated and unified and that the system needs a less coupled set of init code.

Edit to be at least a tiny bit more productive: the Linux Filesystem Hierarchy Standard is about to pop the cork on its thirty second birthday. It's likely older than most of the people upvoting the post I responded to. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

To wit: that's outrageous nonsense, and anyone who know anything about how a Linux distro is put together (which I thought would have included most of the readers here, but alas) would know that.

> /opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software

Steam says hi.

On Windows, a common Steam library exists in Program Files directory, therefore not user specific. On Linux, each user has a separate Steam installation and library. I'm not sure why there isn't a common Steam library on Linux, but /opt would be a good place for it.

By default, Program Files is not writable by non-Administrators. This is likely done by some background service. Or they loosened the default file permissions (which would be dumb).

No reason this can't be done on Linux but since NT's security model is more flexible it's a lot easier to do so on Windows. You'd need to add dedicated users. (Running a Steam daemon as root would probably cause an uproar.)

They loosen the permissions on the steam folder on windows. I would have expected just the library folder but apparently it's the whole thing.

Oof. The correct location for this is C:\ProgramData

Developers who knowingly reduce or disable default Windows security settings should be censured. Because in 99% of cases it is due to ignorance or plain laziness.

Well ProgramData didn't exist when they designed it, and the crime of putting their folder in the wrong place is a pretty minor one. They don't change the permissions of anything outside Steam.

It doesn't "reduce or disable default Windows security settings" in a meaningful way if you say to yourself "that folder effectively is in ProgramData, but spelled wrong".

CSIDL_COMMON_APPDATA is the API call to get this special folder which has been around since <checks notes> Windows 2000, 26 years ago.

You should never hardcode the path since it can and has moved around, though MS has implemented hard links to legacy paths because most developers are stupid and against persistent better advice do it anyway. I've seen multi-million dollar software packages whose vendor requires it to be writable by "Everyone".

Steam was first released in 2003, three years later.

For 80% of grievances about Windows, there is likely a solution in place that no one knows about because they didn't read the documentation.

Back when it was actually AppData in the user documents folder, that doesn't seem like the right place to install many gigabytes of games.

And it's the same permissions either way. This isn't about permissions, it's about where they put the folder.

And steam was originally released to be compatible with Windows 98. windows 2000 wasn't widely used as a consumer installed OS.

> windows 2000 wasn't widely used as a consumer installed OS

But Windows XP, which came out in 2001, inherited everything from Windows 2000 and more, and was used extensively for gaming.

Absolutely and first iterations of steam hardware survey showed mostly XP users, but still 5-7% win 98 install base, which they maintained compatibility with for quite a while, that's just to say that I can see why they might not have used those specific windows APIs at the start.

Steam's original system requirements in the 2002 beta included Windows 98. [1]

They didn't stop advertising Win98 support until sometime in early 2007.

Granted, Steam back then was a different creature than Steam now.

[1] https://web.archive.org/web/20020605222619/http://www.steamp...

So you're saying they've had 18+ years to remove legacy cruft put in there to support a nearly 28 year old legacy OS that had no real multi-user support and basically zero security?

Moving away from Program Files would cost far more than it's worth - it'd cause lots of issue for a massive amount of users and be of very little value for others, when the only practical issue with the Steam folder being in Program Files right now is people going "oh I didn't expect that directory to be writable I guess" which is not something worth spending a bunch of time orchestrating a massive transition over.

It's literally in the name: PROGRAM files. It was never meant to store variable data.

It's also assumed that its contents can be safely restored from original sources, so Program Files is often not backed up - because it's wasteful and not needed.

Rogue developers thinking they know better than the people who actually designed the system and ignoring the rules put in place is the source of an untold number of problems in the software world. It's absolutely stupid and I have no empathy for the problems caused as a result of their laziness. This attitude is why modern Linux is a complete clusterfuck, a free-for-all with components duct taped together every which way. Do it right or don't do it at all.

How are the games not programs?

The save files don't go in the steam folder, they go into per-user Documents or AppData.

There is something oddly satisyfing that in 2026, there are people out there complaining that Steam installs programs into Program Files.

Really? Programs installed by non-administrators should go in ProgramData?

The actual solution, which remains both compatible and consistent with the security model, is that you should have to be administrator and pass UAC to install a game, just like you do to install anything else.

I seem to recall Solaris put packages in /opt. Each package got its own prefix under /opt.

Now I get what the folks using FreeBSD typically like to point to as a reason why they prefer FreeBSD over Linux because there is a clear distinction between the base system and userland.

Linux has more of a clear distinction between kernel and userspace. But the base system in *BSD includes a lot of userspace, so the API boundary is more the libc and some core libraries (TLS) instead of the kernel ABI.

FreeBSD is moving to a scheme where the base system is managed with pkg. In the release notes for last month's 15.0 release, they suggest that this will be mandatory in 16.0.

The ports tree will still be very different from base, but I feel this may erode some of the difference between FreeBSD and a typical Linux distro in terms of user experience, with respect to base vs ports. You'll update both with pkg.

The problems with what you say are that:

1. The history of /usr subdirectories is a lot more complex than that. There was a /usr/lbin once, for example.

1. /usr/local is not where third party softwares from packages/ports go on "the BSDs". On NetBSD, they go in /usr/pkg instead, again exemplifying that this is quite complex through history and across operating systems.

While practically useless in reality /usr/local is `site-local software`, E.G. software that if you nfs mounted /usr, would be local to the `site` not the machine.

The BSD ports explanation is a bit revisionist I hate to say, this all predates ports.

It was a location in a second stage mount you knew the upstream wouldn’t overwrite with tar or cpio. Later ports used it to avoid the same conflict.

So, in Debian, where should I be placing a Firefox tarball I download from Mozilla’s site?

It is open-source, and I can get source files, but it’s precompiled…

Anywhere in your `$PATH` that isn't managed by `apt`/`dpkg`. E.g. add `~/bin` to your `$PATH`, and install it in there. No risk of overwriting files the system package manager manages & having manually-installed software break next time it updates them.

I understand /usr/local to be for anything not managed by your distribution but following the standard system layout (e.g. Python that you compiled yourself) while /opt is used for things that are (relatively) self-contained and don't integrate with the system, similar to Program Files on Windows (e.g. a lot of Java software).

Regarding "that's a Linux-ism" - well yeah? Linux is the main OS this is about. FreeBSD can do what it wants, too.

> anything not managed by your distribution

That's a Linux-ism. Other *nix there is a lot more in /usr/local.

In reality /usr is similar to Windows' System32 directory on most Unicies.

/opt is really the only good place for Java and where I've been putting it for decades (old habits die hard).

> /usr/local is for site-local software - e.g. things you compile yourself

See, you assume here that /usr/local/ makes any sense.

I use a versioned appdir prefix approach similar to GoboLinux. So for me, /usr/local never ever made any sense at all. Why should I adhere to it? I have ruby under e. g. /Programs/Ruby/4.0.0/. It would not matter in the slightest WHO would compile it, but IF I were to need to store that information, I would put that information under that directory too, perhaps in a file such as environment.md or some other file; and perhaps additionally into a global database if it were important to distinguish (but it is not). The problem here is that you do not challenge the notion whether /usr/local/ would make any sense to begin with.

> /opt is generally for software distros for which you don't have source; only binaries.

Makes no sense. It seems to be about as logical as the FHS "standard". Why would I need to use /opt/? If I install libreoffice or google chrome there under /opt, I can as well install it under e. g. /Programs/ or whatever hierarchy I use for versioned appdirs. Which I actually do. So why would I need /opt/ again?

> See, you assume here that /usr/local/ makes any sense.

You’re presenting your comment as a rebuttal but you’re actually arguing something completely different to the OP.

They’re talking about UNIX convention from a historic perspective. Whereas you’re talking about your own opinions about what would make sense if we were to design the file system hierarchy today.

I don’t disagree with your general points, but it also doesn’t mean that the OP is incorrect either.

> This post gets some of the details wrong

"some" is an understatement.

You've entirely missed the point of the article.

Reply on news.ycombinator.com