13 ms·

The Case for the /usr Merge (2012)

137 points by goranmoomin 4y ago

gladiatr72 4y ago
"... Improved compatibility with other Unixes (in particular Solaris)..." <snort>
- glandium 4y ago
  TIL /usr/ucb is no more! https://blogs.oracle.com/solaris/post/preparing-for-the-upcoming-removal-of-ucb-utilities-from-the-next-version-of-solaris https://blogs.oracle.com/solaris/post/preparing-for-the-upco... . I wonder if the same thing happened to /usr/xpg4. (I haven't touched Solaris in more than 10 years)
  - skissane 4y ago
    I’m confused about your link. It says “The long-anticipated demise of the /usr/ucb and /usr/ucblib directories is planned for the next major version of Solaris.” What does it mean by “next major version”? Solaris 12? Well, not long after this blog post was written, Solaris 12 was cancelled, so if that’s what it means, it is talking about something that’s never actually going to happen.
  - zaarn 4y ago
    XPG4 still exists and haunts my days as sysadmin. Gonna pop a whiskey on the day we get rid of the last Solaris machine in favor of Linux.
  - donio 4y ago
    It's forever etched into my "case $OSTYPE in ... solaris*)" $PATH along with /usr/openwin/bin and /usr/ccs/bin.
- ninefathom 4y ago
  Ditto. I laughed so hard on that one that I nearly choked. The Linux community as a whole hasn't been interested in compatibility with Solaris for nearly two decades, and pretending otherwise is nothing short of comedy.
  - loeg 4y ago
    The article is a full decade old, fwiw.
- DenseComet 4y ago
  The article seems to be from 2012, it makes more sense in that context.
hulitu 4y ago
> That means scripts/programs written for other Unixes or other Linuxes and ported to your distribution will no longer need fixing for the file system paths of the binaries called, which is otherwise a major source of frustration I don't know what this guy is smoking, but this has never been a problem.
- kazinator 4y ago
  What's been a problem is not being able to pass more than one argument through hash-bang. Fix that one, and you can use #!/usr/bin/env interpreter --arg --arg ... Problem solved; no need to mess with the file system divisions. For that matter ... the stupid hash bang mechanism itself should do PATH resolution, maybe, you know? #!/usr/bin/awk -f <-- find awk at that absolute path #!awk -f <-- Just use the darn PATH, dear hash-bang handling code in the kernel
  - nerdponx 4y ago
    It's a real problem with interpreted languages in general. PATH lookup is not always desirable. Not to mention library linking and looking for various other data files.
    - kazinator 4y ago
      The writer of the hash bang script retains the control not to have PATH lookup take place: they write an interpreter name which contains one or more slashes.
  - paranoidrobot 4y ago
    Nice, but PATH isn't always set right. I've run into this particular issue with stripped down containers. I run a script as part of the container's CMD/ENTRYPOINT, and it fails. Run it through an interactive shell, and hey-presto PATH is setup and script runs fine.
    - mbreese 4y ago
kazinator 4y ago
Why not go the other way? /usr/bin -> /bin One less path component to resolve.
- chris_wot 4y ago
  "Myth #11: Instead of merging / into /usr it would make a lot more sense to merge /usr into /. Fact: This would make the separation between vendor-supplied OS resources and machine-specific even worse, thus making OS snapshots and network/container sharing of it much harder and non-atomic, and clutter the root file system with a multitude of new directories."
  - icedchai 4y ago
    Call me skeptical. I haven’t seen a Linux system that put /usr on its own partition in at least 15 years.
    - rektide 4y ago
      I dont think that was quite the right argumentation. Or at least not clear enough. In general, the desire is to put the system image into /usr. A single partition, that holds literally everything you need to launch an os. If you can mount a /usr, everything else will populate. If you want to atomically swap system images, just swap /usr. Imagine the counter: what would happen if we just swapped /bin? Shit would be a mess. /lib and /usr/lib wouldnt get updated in sync. /include and /share wouldnt be in sync. The idea is that the Unified System Resources ought unifiedly be swapped out. And the system specific resources(/bin, /lib, /include, et ceteta) ought not exist, provide no real contemprary value, and making image swapping a much much harder to accomplish well.
      - icedchai 4y ago
        I can buy that argument, but I’ve never seen /usr get swapped out with any modern package manager. How would that work? Or is this more theoretical? FYI “usr” really means “user”. Somebody made up “unified system resources” as a backronym.
jmillikin 4y ago
> The primary commercial Unix implementation is nowadays Oracle Solaris. Surely it's macOS? The total install base of Solaris must be a rounding error compared to the number of Macbooks sold daily.
- 3np 4y ago
  Note that most of this text is from at least 2012 (check the wiki history, which starts in 2013 with an indication that this is an import of existing content). Previous recent discussion on that specific quote: https://news.ycombinator.com/item?id=30929464 https://news.ycombinator.com/item?id=30929464
- pdpi 4y ago
  Solaris is a SysV Unix, whereas macOS is a BSD, not sure they were thinking of that distinction. Anyhow, when you’re talking about mounting /usr from the network, it’s safe to assume server workloads where macOS is simply nonexistent.
  - jmillikin 4y ago
    System V and BSD are both considered "UNIX", in that they descend directly from the original AT&T UNIX (v6). In some senses macOS is more of a UNIX than Solaris is, as it is certified by The Open Group and Solaris is currently not: https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/
- stolen_biscuit 4y ago
  It would absolutely be MacOS but I don't think that's what they mean by commercial Unix implementation really
  - skissane 4y ago
    But what do they mean by that phrase then? I think a lot of people who think "macOS isn't Unix" (or similarly, "z/OS isn't Unix") aren't aware of the legal status of the term "Unix" – that it is a registered trademark owned by The Open Group, and legally a trademark means whatever the trademark owner says it means – and The Open Group is very clear that "Unix" means any system, irrespective of its marketing or heritage or other functions, which passes their test suites and whose vendor pays the licensing fee.
jasan_s 4y ago
dietrichepp 4y ago
> With the merged /usr directory we can offer a read-only export of the vendor supplied OS to the network, which will contain almost the entire operating system resources. Back in 2005 or 2006, I made a Linux that exported the filesystem this way, and it worked by mounting / as a network volume. This worked by doing a particular dance with "pivot_root" at the beginning and a union mount with a tmpfs volume. We used it to play LAN games in the computer lab. Because the network booting Linux didn't touch the local hard drive, you could clean up after yourself just by shutting down the machines. It was also nice and fast, because the machines all had gigabit ethernet and the file server was serving from cache most of the time. It ended up being noticeably better than running off local hard disk... this was the era before SSDs took over, obviously.
- colechristensen 4y ago
  Yeah mounting large amounts the filesystem read only over the network was a pretty common thing to do in large environments.
  - hinkley 4y ago
    I got a couple extensions on homework assignments in college on account of the entire computer lab being dead because Solaris and NFS getting into a cage match with each other. The admins had to restart things Apollo 13 style.
  - froh 4y ago
    it was.also used to share /usr in a large number of virtual guests. large as in thousands of guests, for example "your personal web server with root account and perl/php" running on a s390x mainframe.
throwaway892238 4y ago
Some thoughts: - If you have your own system, with very tightly controlled specifications, you can make any change you want, and its impact will be easy to manage. When you change the specifications of random people's systems, random things happen. Doesn't matter what the change is. A file showing up where it didn't exist before, or being a symbolic link rather than a regular file, or duplicate files, will cause logic bugs. - There isn't a single mention of any downside to this fundamental shift in the expectations of the filesystem of major distributions. Yet you can be guaranteed that this will break compatibility with some applications/systems. They still they make no attempt whatsoever to estimate this. - It can't be stated enough that this is a Fedora / RedHat / Lennart Poettering thing. Quite frankly, anything they suggest should ring giant alarm bells. This group is singly responsible for every incompatible, over-designed, pain-in-the-ass change to Linux distributions in the past 10+ years. If it causes problems, and it didn't come from a hardware vendor, it came from these people. - Who in the actual fuck cares about filesystem-level porting from Solaris?! If you're already dealing with all the rest of the portability issues, file paths are literally the very last and least-difficult consideration. "Oh no! In what directory will I find 'pkill' ?! It's so difficult!" Only a company obsessed with converting whales to their platform and want one more bullet point to add to their sales deck cares. I don't actually care if this goes through, but just the fact that RedHat is still shilling their unnecessary changes as if anyone else other than them wants it makes my skin scrawl.
- loeg 4y ago
  This feature / change dates to 2012.
knorker 4y ago
The reasons: > Improved compatibility with other Unixes/Linuxes in behavior: Well, some of them. > Improved compatibility with other Unixes (in particular Solaris) in appearance: I guess, but if you supported Linux you already supported Solaris, so if you think of Solaris as second class then nothing gained. Also: Solaris is (to me) clearly on its way out. Not worth a migration to converge with it. > Improved compatibility with GNU build systems: This one is pure hogwash. Either you need to support the systems that don't do this (e.g. OpenBSD), or you only care about Linux. (this is a bit simplified, but pretty true) So your build system still needs to support non-merged. Except now you're going to bake in Linux-specific merge assumptions into your build system, so that they'll be even more broken. > Improved compatibility with current upstream development: This seems more like tech debt to me, in the name of expedience. I'm here not saying it shouldn't be done. I'm saying these are terrible reasons.
- account42 4y ago
  > > Improved compatibility with GNU build systems: > This one is pure hogwash. Either you need to support the systems that don't do this (e.g. OpenBSD), or you only care about Linux. (this is a bit simplified, but pretty true) > So your build system still needs to support non-merged. > Except now you're going to bake in Linux-specific merge assumptions into your build system, so that they'll be even more broken. Well considering > Not implementing the /usr merge in your distribution will isolate it from upstream development. It will make porting of packages needlessly difficult, because packagers need to split up installed files into multiple directories and hard code different locations for tools; both will cause unnecessary incompatibilities. Several Linux distributions are agreeing with the benefits of the /usr merge and are already in the process to implement the /usr merge. This means that upstream projects will adapt quickly to the change, those making portability to your distribution harder. I think they intended this to play out like SystemD/logind - Red Had maintainers will only care about merged /usr and if you want to use anything they have their hands in you better adapt.
  - knorker 4y ago
    > I think they intended this to play out like SystemD/logind - Red Had maintainers will only care about merged /usr and if you want to use anything they have their hands in you better adapt. The argument this article seems to make is that you can essentially hard code the paths to binaries in your build system, because /lib is /usr/lib, /bin is /usr/bin (from build script point of view it doesn't matter which is symlink to which). It seems to be saying that your build systems no longer need to search for the libraries. But that's not true. You still do. And if you search for it then it doesn't really matter where it is. Clearly if you search for `bash` you'll search /bin and /usr/bin. For at least two reasons: 1) Maybe you're running a system that isn't merged. Then it could be in either place. Doesn't matter if RedHat is merged. 2) You'll need to check other locations anyway. Like /usr/local/bin/bash, to support some BSDs. Why does it matter if it's two, three, or $(echo $PATH | sed 's/[^:]//g' | wc -c) paths? And for libraries you may need to search in /opt, and run pkgconfig for any compile and link flags needed. Why does it matter that `pkg-config --libs foo` contains an -L flag? You still need to run it.
tdeck 4y ago
I wish we could just unify /usr/local/bin, /usr/bin, /usr/sbin, /bin, and /opt. I'm a Linux user for 15 years and I still don't know if there's a good modern reason to have so many different directory trees for binaries and what that reason is. It's all historical craft that makes it so hard to find things as far as I am concerned.
- protomyth 4y ago
  I'm more BSD, but I have come to like 'local' and wish it were further refined so we can mount usr & bin as read-only and be able to rebuild machines with a backup of local and I guess etc.
- pabs3 4y ago
  On Hurd you probably could, just mount a merge translator over /bin that merges all the directories you want. IIRC on Hurd translator namespaces are per-process in the libc and are inherited from parent to child process. So like containers/namespaces on Linux but implemented in the libc.
  - account42 4y ago
    Well when it comes to bin, other operating systems have that to. It's called $PATH.
    - pabs3 4y ago
      $PATH isn't quote the same, for eg you can't easily remove individual binaries from $PATH.
- jabl 4y ago
  The somewhat old and AFAIU no longer maintained FHS contains explanations https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html tl;dr: /usr/local - Place for the system administrator to put local stuff. That is, the package manager (apt/dnf/yum/whatever) won't touch anything there. /usr/bin - "Normal" binaries /usr/sbin - System binaries, that is, binaries that don't do anything useful when run without superuser privileges /bin - Well, nowadays just a symlink to /usr/bin. Read the article to understand the historical background why they were split. /opt - For packages that install everything under one directory instead of being spread out into the standard locations.
noobermin 4y ago
Why not go in reverse and have /bin and /lib directories again? Why merge into /usr? I feel like the suckless people and fellows like them will be happy. I think even /usr/share can get its own directory, why not?
- LeoPanthera 4y ago
  Because if you merge you can put the entire operating system in /usr, which allows you to mount it read-only, or from an NFS share, or various other options, easily.
- masklinn 4y ago
  > Why merge into /usr? Because then you can mount /usr from wherever, which is much harder to do with /. thus merging in /usr provides utility which are harder and less convenient to provide the other way around.
RustyRussell 4y ago
(2013) Though I responded in 2012, so it may be older (the log on the site says 2013 though). FWIW, my response, as FHS editor: https://rusty.ozlabs.org/?p=236 https://rusty.ozlabs.org/?p=236
- DangitBobby 4y ago
  The number of people unsure of whether your are serious is truly inspiring. It's like a 50/50 split.
  - RustyRussell 4y ago
    Yes, it was the moment I personally realized we were in eternal September :(
    - xani_ 4y ago
      I mean, as someone which job SystemD made noticeably easier (a lot of stuff it does is blessing for ops, and a lot of "simple" init scripts are actually subtly broken, despise how "easy" it is to write them) I still don't like his attitude and "it works on my laptop, clearly what the rest of the world needs" design decisions around stuff he touches. So I can kinda understand the blind hate
- ikiris 4y ago
  I got to the anti section and literally did a spit take with the water I was drinking. This is gold.
  - blueflow 4y ago
    GP was joking about it, but do you have confidence that Poettering knows what he is doing? There have been incidents[1]. [1] https://github.com/systemd/systemd/issues/5644#issuecomment-290345033 https://github.com/systemd/systemd/issues/5644#issuecomment-...
    - 4y ago
jabl 4y ago
I recall, with some amusement, the uproar this caused when proposed a decade ago. Luckily sanity prevailed over the kneejerkers in the end, and today our systems are a little bit simpler, and another tiny gratuitous portability issue is no more.
- p_l 4y ago
  Hmm, I end up dealing with differences caused by this all the time. I'd say the biggest issue is that the one benefit I'm finally reaping, and apparently mentioned (badly) at the time, is the one benefit that all the mentions of merging explicitly disavowed as impossible and that dinosaurs like me should go and Bury themselves. Namely, separate /usr partition made readonly. Serving readonly FS or shared FS for systems has been harder with unmerged /usr because of /etc (among others). However, the arguments for merging that I heard were "nobody does separate /usr anymore you dinosaur", "nobody wants to share filesystem between multiple system instances", and finally from the proposers themselves, "split / and /usr mean I have to keep track of where I'm putting files in RPM depending on whether they are early boot or not, boohoo". So recently I've been working on building a customised Gentoo, based on ChromeOS/CoreOS/Flatcar changes which tells emerge to use /usr as target... And for the first time in forever I have use for merged /usr and it's an use that was ridiculed when merged /usr was proposed (but use that was explicitly (ab)used by Solaris, btw)
Scootwilli90 4y ago
[dead]
midislack 4y ago
/sbin/ fits on a small root partition, historical precedent still applies
sour-taste 4y ago
LWN has a nice write up of some of the issues resulting from the merge that Debian did: https://lwn.net/Articles/773342/ https://lwn.net/Articles/773342/ tl;dr: Do the merge or don't but don't support both.
gjadi 4y ago
On OpenBSD the split is nicely described in https://man.openbsd.org/man7/hier.7 https://man.openbsd.org/man7/hier.7 The main difference is about static linking. > /bin/ User utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run. > /sbin/ System programs and administration utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run. It was discussed a few month ago: https://news.ycombinator.com/item?id=31336396 https://news.ycombinator.com/item?id=31336396
- mort96 4y ago
  That's a nice distinction, but it's not really practical on Linux. Statically linking glibc is explicitly not supported (and for arguably good reasons).
  - asymmetric 4y ago
    Curious, what are those reasons?
    - nousermane 4y ago
      Package management. It's nice to only have to upgrade one for a system-wide change.
      - mort96 4y ago
        That's the common argument against static linking in general, it's not glibc-specific (or honestly very interesting).
    - mort96 4y ago
      Here's a description of it: https://stackoverflow.com/a/57478728 https://stackoverflow.com/a/57478728 Basically, glibc uses dlopen to open certain shared libraries for things like nsswitch and locales. Using dlopen in a program that's statically linked to glibc causes all kinds of issues, as you'll likely end up with multiple copies of potentially different versions of glibc in the same process.
waynesonfire 4y ago
"By making the same change in Linux we minimize the difference towards the primary Unix implementation, thus easing portability from Solaris" Since when are you so concerned about Unix compatibility as you push systemd?
deleted 4y ago
[deleted]
elmacho39 4y ago
Its the wrong direction, /usr/bin should have to move to /bin make /usr home again.
foxdie99 4y ago
Hurray! Finally we slowly making progress towards c:/ !!! I can not wait until /etc also ceases to exit in turn for an SQL-LITE variant run by systemd. We are really living in the future. Monolithic central administration tools, fewer system folders... Yes this is it. I really hope everybody else is as happy as me. /etc /proc /sys /home /root /usr /bin /sbin /mnt /boot who needs all of these anyway? Am I right? Lets simplify stuff make it easy. Also just as an added note please kill the Man pages system its just make it so that I can click a link the automaticaly opens my browser to the documentation I need or known forums! Screw living in the terminal, make it all invisible and make sure I do not need to know how it actually works. That way I can just call RedHat support the same way we do with Microsoft support. The Unix way will prevail. I am happy the BSDs continue with the philosophy. Old does not mean outdated and tradition does not mean backwards. One thing only and do it well.

137 points by goranmoomin 4y ago

gladiatr72 4y ago

"... Improved compatibility with other Unixes (in particular Solaris)..." <snort>

glandium 4y ago
TIL /usr/ucb is no more! https://blogs.oracle.com/solaris/post/preparing-for-the-upcoming-removal-of-ucb-utilities-from-the-next-version-of-solaris https://blogs.oracle.com/solaris/post/preparing-for-the-upco... . I wonder if the same thing happened to /usr/xpg4. (I haven't touched Solaris in more than 10 years)
- skissane 4y ago
  I’m confused about your link. It says “The long-anticipated demise of the /usr/ucb and /usr/ucblib directories is planned for the next major version of Solaris.” What does it mean by “next major version”? Solaris 12? Well, not long after this blog post was written, Solaris 12 was cancelled, so if that’s what it means, it is talking about something that’s never actually going to happen.
- zaarn 4y ago
  XPG4 still exists and haunts my days as sysadmin. Gonna pop a whiskey on the day we get rid of the last Solaris machine in favor of Linux.
- donio 4y ago
  It's forever etched into my "case $OSTYPE in ... solaris*)" $PATH along with /usr/openwin/bin and /usr/ccs/bin.
ninefathom 4y ago
Ditto. I laughed so hard on that one that I nearly choked. The Linux community as a whole hasn't been interested in compatibility with Solaris for nearly two decades, and pretending otherwise is nothing short of comedy.
- loeg 4y ago
  The article is a full decade old, fwiw.
DenseComet 4y ago
The article seems to be from 2012, it makes more sense in that context.

hulitu 4y ago

> That means scripts/programs written for other Unixes or other Linuxes and ported to your distribution will no longer need fixing for the file system paths of the binaries called, which is otherwise a major source of frustration I don't know what this guy is smoking, but this has never been a problem.

kazinator 4y ago
What's been a problem is not being able to pass more than one argument through hash-bang. Fix that one, and you can use #!/usr/bin/env interpreter --arg --arg ... Problem solved; no need to mess with the file system divisions. For that matter ... the stupid hash bang mechanism itself should do PATH resolution, maybe, you know? #!/usr/bin/awk -f <-- find awk at that absolute path #!awk -f <-- Just use the darn PATH, dear hash-bang handling code in the kernel
- nerdponx 4y ago
  It's a real problem with interpreted languages in general. PATH lookup is not always desirable. Not to mention library linking and looking for various other data files.
  - kazinator 4y ago
    The writer of the hash bang script retains the control not to have PATH lookup take place: they write an interpreter name which contains one or more slashes.
- paranoidrobot 4y ago
  Nice, but PATH isn't always set right. I've run into this particular issue with stripped down containers. I run a script as part of the container's CMD/ENTRYPOINT, and it fails. Run it through an interactive shell, and hey-presto PATH is setup and script runs fine.
  - mbreese 4y ago

kazinator 4y ago

Why not go the other way? /usr/bin -> /bin One less path component to resolve.

chris_wot 4y ago
"Myth #11: Instead of merging / into /usr it would make a lot more sense to merge /usr into /. Fact: This would make the separation between vendor-supplied OS resources and machine-specific even worse, thus making OS snapshots and network/container sharing of it much harder and non-atomic, and clutter the root file system with a multitude of new directories."
- icedchai 4y ago
  Call me skeptical. I haven’t seen a Linux system that put /usr on its own partition in at least 15 years.
  - rektide 4y ago
    I dont think that was quite the right argumentation. Or at least not clear enough. In general, the desire is to put the system image into /usr. A single partition, that holds literally everything you need to launch an os. If you can mount a /usr, everything else will populate. If you want to atomically swap system images, just swap /usr. Imagine the counter: what would happen if we just swapped /bin? Shit would be a mess. /lib and /usr/lib wouldnt get updated in sync. /include and /share wouldnt be in sync. The idea is that the Unified System Resources ought unifiedly be swapped out. And the system specific resources(/bin, /lib, /include, et ceteta) ought not exist, provide no real contemprary value, and making image swapping a much much harder to accomplish well.
    - icedchai 4y ago
      I can buy that argument, but I’ve never seen /usr get swapped out with any modern package manager. How would that work? Or is this more theoretical? FYI “usr” really means “user”. Somebody made up “unified system resources” as a backronym.

jmillikin 4y ago

> The primary commercial Unix implementation is nowadays Oracle Solaris. Surely it's macOS? The total install base of Solaris must be a rounding error compared to the number of Macbooks sold daily.

3np 4y ago
Note that most of this text is from at least 2012 (check the wiki history, which starts in 2013 with an indication that this is an import of existing content). Previous recent discussion on that specific quote: https://news.ycombinator.com/item?id=30929464 https://news.ycombinator.com/item?id=30929464
pdpi 4y ago
Solaris is a SysV Unix, whereas macOS is a BSD, not sure they were thinking of that distinction. Anyhow, when you’re talking about mounting /usr from the network, it’s safe to assume server workloads where macOS is simply nonexistent.
- jmillikin 4y ago
  System V and BSD are both considered "UNIX", in that they descend directly from the original AT&T UNIX (v6). In some senses macOS is more of a UNIX than Solaris is, as it is certified by The Open Group and Solaris is currently not: https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/
stolen_biscuit 4y ago
It would absolutely be MacOS but I don't think that's what they mean by commercial Unix implementation really
- skissane 4y ago
  But what do they mean by that phrase then? I think a lot of people who think "macOS isn't Unix" (or similarly, "z/OS isn't Unix") aren't aware of the legal status of the term "Unix" – that it is a registered trademark owned by The Open Group, and legally a trademark means whatever the trademark owner says it means – and The Open Group is very clear that "Unix" means any system, irrespective of its marketing or heritage or other functions, which passes their test suites and whose vendor pays the licensing fee.

jasan_s 4y ago

dietrichepp 4y ago

> With the merged /usr directory we can offer a read-only export of the vendor supplied OS to the network, which will contain almost the entire operating system resources. Back in 2005 or 2006, I made a Linux that exported the filesystem this way, and it worked by mounting / as a network volume. This worked by doing a particular dance with "pivot_root" at the beginning and a union mount with a tmpfs volume. We used it to play LAN games in the computer lab. Because the network booting Linux didn't touch the local hard drive, you could clean up after yourself just by shutting down the machines. It was also nice and fast, because the machines all had gigabit ethernet and the file server was serving from cache most of the time. It ended up being noticeably better than running off local hard disk... this was the era before SSDs took over, obviously.

colechristensen 4y ago
Yeah mounting large amounts the filesystem read only over the network was a pretty common thing to do in large environments.
- hinkley 4y ago
  I got a couple extensions on homework assignments in college on account of the entire computer lab being dead because Solaris and NFS getting into a cage match with each other. The admins had to restart things Apollo 13 style.
- froh 4y ago
  it was.also used to share /usr in a large number of virtual guests. large as in thousands of guests, for example "your personal web server with root account and perl/php" running on a s390x mainframe.

throwaway892238 4y ago

Some thoughts: - If you have your own system, with very tightly controlled specifications, you can make any change you want, and its impact will be easy to manage. When you change the specifications of random people's systems, random things happen. Doesn't matter what the change is. A file showing up where it didn't exist before, or being a symbolic link rather than a regular file, or duplicate files, will cause logic bugs. - There isn't a single mention of any downside to this fundamental shift in the expectations of the filesystem of major distributions. Yet you can be guaranteed that this will break compatibility with some applications/systems. They still they make no attempt whatsoever to estimate this. - It can't be stated enough that this is a Fedora / RedHat / Lennart Poettering thing. Quite frankly, anything they suggest should ring giant alarm bells. This group is singly responsible for every incompatible, over-designed, pain-in-the-ass change to Linux distributions in the past 10+ years. If it causes problems, and it didn't come from a hardware vendor, it came from these people. - Who in the actual fuck cares about filesystem-level porting from Solaris?! If you're already dealing with all the rest of the portability issues, file paths are literally the very last and least-difficult consideration. "Oh no! In what directory will I find 'pkill' ?! It's so difficult!" Only a company obsessed with converting whales to their platform and want one more bullet point to add to their sales deck cares. I don't actually care if this goes through, but just the fact that RedHat is still shilling their unnecessary changes as if anyone else other than them wants it makes my skin scrawl.

loeg 4y ago
This feature / change dates to 2012.

knorker 4y ago

The reasons: > Improved compatibility with other Unixes/Linuxes in behavior: Well, some of them. > Improved compatibility with other Unixes (in particular Solaris) in appearance: I guess, but if you supported Linux you already supported Solaris, so if you think of Solaris as second class then nothing gained. Also: Solaris is (to me) clearly on its way out. Not worth a migration to converge with it. > Improved compatibility with GNU build systems: This one is pure hogwash. Either you need to support the systems that don't do this (e.g. OpenBSD), or you only care about Linux. (this is a bit simplified, but pretty true) So your build system still needs to support non-merged. Except now you're going to bake in Linux-specific merge assumptions into your build system, so that they'll be even more broken. > Improved compatibility with current upstream development: This seems more like tech debt to me, in the name of expedience. I'm here not saying it shouldn't be done. I'm saying these are terrible reasons.

account42 4y ago
> > Improved compatibility with GNU build systems: > This one is pure hogwash. Either you need to support the systems that don't do this (e.g. OpenBSD), or you only care about Linux. (this is a bit simplified, but pretty true) > So your build system still needs to support non-merged. > Except now you're going to bake in Linux-specific merge assumptions into your build system, so that they'll be even more broken. Well considering > Not implementing the /usr merge in your distribution will isolate it from upstream development. It will make porting of packages needlessly difficult, because packagers need to split up installed files into multiple directories and hard code different locations for tools; both will cause unnecessary incompatibilities. Several Linux distributions are agreeing with the benefits of the /usr merge and are already in the process to implement the /usr merge. This means that upstream projects will adapt quickly to the change, those making portability to your distribution harder. I think they intended this to play out like SystemD/logind - Red Had maintainers will only care about merged /usr and if you want to use anything they have their hands in you better adapt.
- knorker 4y ago
  > I think they intended this to play out like SystemD/logind - Red Had maintainers will only care about merged /usr and if you want to use anything they have their hands in you better adapt. The argument this article seems to make is that you can essentially hard code the paths to binaries in your build system, because /lib is /usr/lib, /bin is /usr/bin (from build script point of view it doesn't matter which is symlink to which). It seems to be saying that your build systems no longer need to search for the libraries. But that's not true. You still do. And if you search for it then it doesn't really matter where it is. Clearly if you search for `bash` you'll search /bin and /usr/bin. For at least two reasons: 1) Maybe you're running a system that isn't merged. Then it could be in either place. Doesn't matter if RedHat is merged. 2) You'll need to check other locations anyway. Like /usr/local/bin/bash, to support some BSDs. Why does it matter if it's two, three, or $(echo $PATH | sed 's/[^:]//g' | wc -c) paths? And for libraries you may need to search in /opt, and run pkgconfig for any compile and link flags needed. Why does it matter that `pkg-config --libs foo` contains an -L flag? You still need to run it.

tdeck 4y ago

I wish we could just unify /usr/local/bin, /usr/bin, /usr/sbin, /bin, and /opt. I'm a Linux user for 15 years and I still don't know if there's a good modern reason to have so many different directory trees for binaries and what that reason is. It's all historical craft that makes it so hard to find things as far as I am concerned.

protomyth 4y ago
I'm more BSD, but I have come to like 'local' and wish it were further refined so we can mount usr & bin as read-only and be able to rebuild machines with a backup of local and I guess etc.
pabs3 4y ago
On Hurd you probably could, just mount a merge translator over /bin that merges all the directories you want. IIRC on Hurd translator namespaces are per-process in the libc and are inherited from parent to child process. So like containers/namespaces on Linux but implemented in the libc.
- account42 4y ago
  Well when it comes to bin, other operating systems have that to. It's called $PATH.
  - pabs3 4y ago
    $PATH isn't quote the same, for eg you can't easily remove individual binaries from $PATH.
jabl 4y ago
The somewhat old and AFAIU no longer maintained FHS contains explanations https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html tl;dr: /usr/local - Place for the system administrator to put local stuff. That is, the package manager (apt/dnf/yum/whatever) won't touch anything there. /usr/bin - "Normal" binaries /usr/sbin - System binaries, that is, binaries that don't do anything useful when run without superuser privileges /bin - Well, nowadays just a symlink to /usr/bin. Read the article to understand the historical background why they were split. /opt - For packages that install everything under one directory instead of being spread out into the standard locations.

noobermin 4y ago

Why not go in reverse and have /bin and /lib directories again? Why merge into /usr? I feel like the suckless people and fellows like them will be happy. I think even /usr/share can get its own directory, why not?

LeoPanthera 4y ago
Because if you merge you can put the entire operating system in /usr, which allows you to mount it read-only, or from an NFS share, or various other options, easily.
masklinn 4y ago
> Why merge into /usr? Because then you can mount /usr from wherever, which is much harder to do with /. thus merging in /usr provides utility which are harder and less convenient to provide the other way around.

RustyRussell 4y ago

(2013) Though I responded in 2012, so it may be older (the log on the site says 2013 though). FWIW, my response, as FHS editor: https://rusty.ozlabs.org/?p=236 https://rusty.ozlabs.org/?p=236

DangitBobby 4y ago
The number of people unsure of whether your are serious is truly inspiring. It's like a 50/50 split.
- RustyRussell 4y ago
  Yes, it was the moment I personally realized we were in eternal September :(
  - xani_ 4y ago
    I mean, as someone which job SystemD made noticeably easier (a lot of stuff it does is blessing for ops, and a lot of "simple" init scripts are actually subtly broken, despise how "easy" it is to write them) I still don't like his attitude and "it works on my laptop, clearly what the rest of the world needs" design decisions around stuff he touches. So I can kinda understand the blind hate
ikiris 4y ago
I got to the anti section and literally did a spit take with the water I was drinking. This is gold.
- blueflow 4y ago
  GP was joking about it, but do you have confidence that Poettering knows what he is doing? There have been incidents[1]. [1] https://github.com/systemd/systemd/issues/5644#issuecomment-290345033 https://github.com/systemd/systemd/issues/5644#issuecomment-...
  - 4y ago

jabl 4y ago

I recall, with some amusement, the uproar this caused when proposed a decade ago. Luckily sanity prevailed over the kneejerkers in the end, and today our systems are a little bit simpler, and another tiny gratuitous portability issue is no more.

p_l 4y ago
Hmm, I end up dealing with differences caused by this all the time. I'd say the biggest issue is that the one benefit I'm finally reaping, and apparently mentioned (badly) at the time, is the one benefit that all the mentions of merging explicitly disavowed as impossible and that dinosaurs like me should go and Bury themselves. Namely, separate /usr partition made readonly. Serving readonly FS or shared FS for systems has been harder with unmerged /usr because of /etc (among others). However, the arguments for merging that I heard were "nobody does separate /usr anymore you dinosaur", "nobody wants to share filesystem between multiple system instances", and finally from the proposers themselves, "split / and /usr mean I have to keep track of where I'm putting files in RPM depending on whether they are early boot or not, boohoo". So recently I've been working on building a customised Gentoo, based on ChromeOS/CoreOS/Flatcar changes which tells emerge to use /usr as target... And for the first time in forever I have use for merged /usr and it's an use that was ridiculed when merged /usr was proposed (but use that was explicitly (ab)used by Solaris, btw)

Scootwilli90 4y ago

[dead]

midislack 4y ago

/sbin/ fits on a small root partition, historical precedent still applies

sour-taste 4y ago

LWN has a nice write up of some of the issues resulting from the merge that Debian did: https://lwn.net/Articles/773342/ https://lwn.net/Articles/773342/ tl;dr: Do the merge or don't but don't support both.

gjadi 4y ago

On OpenBSD the split is nicely described in https://man.openbsd.org/man7/hier.7 https://man.openbsd.org/man7/hier.7 The main difference is about static linking. > /bin/ User utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run. > /sbin/ System programs and administration utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run. It was discussed a few month ago: https://news.ycombinator.com/item?id=31336396 https://news.ycombinator.com/item?id=31336396

mort96 4y ago
That's a nice distinction, but it's not really practical on Linux. Statically linking glibc is explicitly not supported (and for arguably good reasons).
- asymmetric 4y ago
  Curious, what are those reasons?
  - nousermane 4y ago
    Package management. It's nice to only have to upgrade one for a system-wide change.
    - mort96 4y ago
      That's the common argument against static linking in general, it's not glibc-specific (or honestly very interesting).
  - mort96 4y ago
    Here's a description of it: https://stackoverflow.com/a/57478728 https://stackoverflow.com/a/57478728 Basically, glibc uses dlopen to open certain shared libraries for things like nsswitch and locales. Using dlopen in a program that's statically linked to glibc causes all kinds of issues, as you'll likely end up with multiple copies of potentially different versions of glibc in the same process.

waynesonfire 4y ago

"By making the same change in Linux we minimize the difference towards the primary Unix implementation, thus easing portability from Solaris" Since when are you so concerned about Unix compatibility as you push systemd?

deleted 4y ago

[deleted]

elmacho39 4y ago

Its the wrong direction, /usr/bin should have to move to /bin make /usr home again.

foxdie99 4y ago

Hurray! Finally we slowly making progress towards c:/ !!! I can not wait until /etc also ceases to exit in turn for an SQL-LITE variant run by systemd. We are really living in the future. Monolithic central administration tools, fewer system folders... Yes this is it. I really hope everybody else is as happy as me. /etc /proc /sys /home /root /usr /bin /sbin /mnt /boot who needs all of these anyway? Am I right? Lets simplify stuff make it easy. Also just as an added note please kill the Man pages system its just make it so that I can click a link the automaticaly opens my browser to the documentation I need or known forums! Screw living in the terminal, make it all invisible and make sure I do not need to know how it actually works. That way I can just call RedHat support the same way we do with Microsoft support. The Unix way will prevail. I am happy the BSDs continue with the philosophy. Old does not mean outdated and tradition does not mean backwards. One thing only and do it well.