281–290 of 310 posts
As a Debian user in a previous life, and a current NixOS user, this whole debacle amuses me greatly, as I no longer give a shit about paths like /usr/bin or /bin, beyond a handful of binaries needed to bootstrap my environment. I've even moved those paths into a read-only filesystem on some systems!
Earlier quoted context omitted.
Old Unix guy here: That is my understanding as well. But then the question becomes, why not get rid of /usr?
Having the "immutable" parts of UNIX reside in a single directory is often useful. It can be mounted read-only, for example.
Also, you could mount / as read-only, and mount the writable parts at different points, or using a UnionFS mount of / .
Earlier quoted context omitted.
Is that also where /usr/share got its name for application data? Data that's shared among the rest of the users, as opposed to in their respective homedirs?
share is for architecture-independent data (ie data which is “shared” by all architectures). Executable binaries are not shared, but things like man pages are.
Thus why the (per-machine, read-write) /var became standardized. Earlier /usr contained a mix of writable things (like /usr/log). Now it was important to make /usr something that could be NFS mounted read-only by a bunch of NFS clients.
There were also UNIXes that ran on multiple architectures, like SunOS on 68k and SPARC. In theory, you could have them both use the same read-only /usr/share mount and save some resources on the server.
I say "in theory" because I don't know how many sites ever implemented this in practice. There were definitely places that supported mixed-architecture diskless fleets, but I'm unsure how many of them were committed to keeping the OS version pinned between them... or how many then went through the extra work to make /usr/share a separate mountpoint. I'm sure some people did it, but it's not something I remember seeing personally.
Still, I feel it's somewhat useful to help humans understand what parts of a package are CPU-specific and which aren't. Probably good that it's lived on.
Earlier quoted context omitted.
Both /bin and /sbin are generally statically linked. So you're not wrong; but primarily sbin is intended to mean "executed by root" above all else.
Looking through my /bin and /sbin, none of the files are statically linked.
Earlier quoted context omitted.
> I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption. The tight coupling of systemD is a popular criticism of it.
And this is another fine case demonstrating how very very wrong that criticism is. All in all extremely few systemd subsystems require systemd. Systemd's pid1 requires only one subsystem, journald, which one can mostly disable/defang if they really dislike it. It's much more like a monorepo than monolith. There's standard practices & libraries between the projects- unit files, ability to ask for machine readible outp…
Earlier quoted context omitted.
Careful, you'll attract computing historians who will want to tell you that "usr" actually stands for "UNIX system resources"
Nice backronym, but /usr/ken (etc.) in v6 shows that /usr was originally a user disk. You could ask Ken Thompson (/usr/ken) himself to verify. ;-)
Earlier quoted context omitted.
And this is another fine case demonstrating how very very wrong that criticism is. All in all extremely few systemd subsystems require systemd. Systemd's pid1 requires only one subsystem, journald, which one can mostly disable/defang if they really dislike it. It's much more like a monorepo than monolith. There's standard practices & libraries between the projects- unit files, ability to ask for machine readible outp…
You say this, but systemd-udevd at one point would sigkill every process on the system if it was not started under systemd (or otherwise in its own cgroup).
Earlier quoted context omitted.
I wish two things happened... All OS's around the world implementing "#!python3" (or similar) as a shorthand to "#!/usr/bin/env python3", and in the meantime using #!/usr/bin/env to transition.
The reason that hasn't happened is because `#!` is a kernel level thing, but the `PATH` env is a userspace thing. I suspect even adding env parsing to the kernel would not be viewed as a favorable change…