<p><pre><code> > The primary commercial Unix implementation is nowadays Oracle Solaris.
</code></pre>
Surely it's macOS? The total install base of Solaris must be a rounding error compared to the number of Macbooks sold daily.
> 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.<p>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.
On OpenBSD the split is nicely described in <a href="https://man.openbsd.org/man7/hier.7" rel="nofollow">https://man.openbsd.org/man7/hier.7</a><p>The main difference is about static linking.<p>> /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.<p>> /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.<p>It was discussed a few month ago: <a href="https://news.ycombinator.com/item?id=31336396" rel="nofollow">https://news.ycombinator.com/item?id=31336396</a>
(2013)<p>Though I responded in 2012, so it may be older (the log on the site says 2013 though).<p>FWIW, my response, as FHS editor:<p><a href="https://rusty.ozlabs.org/?p=236" rel="nofollow">https://rusty.ozlabs.org/?p=236</a>
> 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<p>I don't know what this guy is smoking, but this has never been a problem.
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.
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.<p>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.
The reasons:<p>> Improved compatibility with other Unixes/Linuxes in behavior:<p>Well, some of them.<p>> Improved compatibility with other Unixes (in particular Solaris) in appearance:<p>I guess, but if you supported Linux you already supported Solaris, so if you think of Solaris as second class then nothing gained.<p>Also: Solaris is (to me) clearly on its way out. Not worth a migration to converge with it.<p>> Improved compatibility with GNU build systems:<p>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)<p>So your build system <i>still</i> needs to support non-merged.<p>Except now you're going to bake in Linux-specific merge assumptions into your build system, so that they'll be even more broken.<p>> Improved compatibility with current upstream development:<p>This seems more like tech debt to me, in the name of expedience.<p>I'm here not saying it shouldn't be done. I'm saying these are terrible reasons.
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.<p>I think even /usr/share can get its own directory, why not?
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 <i>still</i> 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.
LWN has a nice write up of some of the issues resulting from the merge that Debian did:<p><a href="https://lwn.net/Articles/773342/" rel="nofollow">https://lwn.net/Articles/773342/</a><p>tl;dr: Do the merge or don't but don't support both.
"By making the same change in Linux we minimize the difference towards the primary Unix implementation, thus easing portability from Solaris"<p>Since when are you so concerned about Unix compatibility as you push systemd?
Some thoughts:<p>- 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, <i>will</i> cause logic bugs.<p>- 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 <i>guaranteed</i> that this will break compatibility with some applications/systems. They still they make no attempt whatsoever to estimate this.<p>- It can't be stated enough that this is a Fedora / RedHat / Lennart Poettering thing. Quite frankly, <i>anything</i> 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.<p>- 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. <i>"Oh no! In what directory will I find 'pkill' ?! It's so difficult!"</i> 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.