zlacker

> What a shame.

I think this is a pretty dangerous attitude, and it is really the only thing wrong with Linux, and probably leads to replacement of simple structure and functionality with a complex software suite that is merely more convenient, like systemd. "Let's change this thing because we want to, because it will improve performance 0.0024%"

Feature creep is what happens when restraint was not exercised.

IMO, since it really doesn't matter what the filesystem looks like, leave it be for standards and compatibility. Seriously, it takes, idk, maybe, a lack of humility to want to change fundamental characteristics of UNIX when the reasons for doing so are a little capricious.

I'm not really talking about the parent, fwiw. I'm talking about the crowd and ochlocracy.

>>Maursa+(OP)
To be clear, GP's stated intention was to simplify a complex structure into a "simple structure", about which the stated concern was a loss of performance, to which GP's rebuttal was it actually improved performance. The main motivator for flattening the filesystem hierarchy isn't really performance, it's simplifying the organization, and (arguably) bringing it more in like with "pure UNIX", vs the quagmire of commercial SysV derivatives with a few dozen different bin directories in PATH, with esoteric justification.

>>Maursa+(OP)
It's also dangerous and tiring the opposite attitude in the Linux world: don't dare change something that has been there for 30 years. Like this very article, there were plenty saying "the /usr split is there for a reason!". No, it's just an historical quirk.

There's plenty greybeards that for them "Linux" is a full screen terminal running emacs on decade-old hardware. "I don't use antialiased fonts, why the hell should I care about decent HiDPI support?" And then protest every time some working group tries to modernise and improve the Linux desktop. You see them every time on this forum.

I'm a greybeard, I've used Linux full time on the desktop for 20 years. I don't get this conservative, "we don't need it" attitude.

>>sph+R1
You hit the nail on the head there, I would add that today it's more the KISS crowd throwing a fit.

Can't imagine the frustration deva must have.

>>sph+R1
> "the /usr split is there for a reason!". No, it's just an historical quirk.

It's a historical quirk on linux, where there is no clear separation between "base OS packages" and "3rd party packages".

On FreeBSD the split is very real, anything in /bin/ ships with my OS and is maintained and updated by the FreeBSD team. Anything in /usr/bin/ comes from ports and is thus a 3rd party package I installed and can be safely nuked and I need to maintain/update it.

>>merijn+l4
Please have an upvote for this clarity. I prefer the FreeBSD approach personally.

>>sph+R1
This is maybe why I gravitate towards NixOS now. It is already in its inception such a departure from tradition that the conservative crowd will probably not even attempt to use it, which in turn will make innovation more likely.

>>merijn+l4
I think you've confused /usr/bin with /usr/local/bin. I'm pretty sure a default FreeBSD install has plenty if stuff in /usr/bin.

>>merijn+l4
A much better separation is achieved in a few Linux distributions where every package is installed in a separate directory.

All the files that might be expected by others to be in certain standard locations are sym-linked to those locations, e.g. the executables to /usr/bin,/usr/sbin,/bin or /sbin, in order to appear in PATH.

In this case you no longer need any kind of database to know which files may be safely nuked to delete any package.

Moreover, in FreeBSD there is no such separation between the "base OS packages" and "3rd party packages", implemented as a difference between root and /usr. You might have misremembered /usr/local, which is indeed a place for "3rd party packages" in all UNIX-derived operating systems.

There are many "base OS packages" that are installed in /usr/bin or in /usr/sbin.

In any FreeBSD system, you can see their source files in /usr/src/usr.bin and in /usr/src/usr.sbin.

I have been using FreeBSD for a quarter of century, since FreeBSD 2.0, and there has never been such a separation between root and /usr.

The separation between /bin and /usr/bin and the other similar pairs was made only to allow /usr to be unmounted, when it is on another device than the root device, but still have in the root file system the minimal set of tools needed for diagnosing and repairing any broken file system or network connection.

In ancient FreeBSD installations it was always recommended to have a separate small root partition, e.g. of a few hundred megabytes, and some large partitions for usr and var.

This original use has become completely obsolete, because now, for diagnosing and repairing problems, it is preferable to boot from an USB stick or from the network (using a ramdisk as root file system), and then run diagnostics or repair programs without touching even the root file system unless modifying it is intentional.

In FreBSD it might still be possible to put /usr on a different partition or device and then unmount /usr, but in many Linux distributions this traditional usage is broken, because some of the programs installed in the root directories need components installed in /usr, so when /usr is unmounted they stop working.

>>merijn+l4
The split is even stronger on NetBSD, where /usr is the base OS and /usr/pkg what's installed by the user through pkgin (binary packages) or pkgsrc (ports).

Likewise, the system configuration goes to /etc while the userland configuration goes to /usr/pkg/etc.

All it takes to factory reset a NetBSD system is an rm -Rf /usr/pkg.

>>merijn+l4
This is wrong (and dangerously so too).

On FreeBSD 3rd party packages go into /usr/local and not /usr

You absolutely will get base packages in /usr/bin (eg `env`) so nuking /usr/bin will break your FreeBSD install.

There's a good write up here: https://unix.stackexchange.com/questions/332764/role-of-the-...

>>merijn+l4
> It's a historical quirk on linux, where there is no clear separation between "base OS packages" and "3rd party packages".

It was a historical quirk to start with. At Bell Labs, back in the early 1970s, Unix was being developed on PDP-11s with RK05 hard disks (with removable disk packs), which had an amazingly generous capacity of 2.5MB each. The Unix operating system had grown too big to fit on a single RK05 disk volume so they had to split it across two. Other operating systems of the period faced similar issues, but dealt with them in (arguably) more elegant ways – on IBM mainframes, OS/360 maintained a database ("catalog") mapping file paths (dataset names, to use the proper terminology) to volume names, so you could move a file to another disk without changing its path. True to Unix's penchant for simplicity, its authors decided instead to just split the OS into / and /usr. And the split survived long after they'd upgraded to more spacious disks.

Any other explanation for the split is essentially a retcon. Some of those retcons (even if, as other commenters have pointed out, not your own) may actually have become true – some of them may have been approximately true to begin with, and they influenced people's decisions, thereby making themselves more true over time. But its ultimate origins will forever remain this quirk of computing history.

>>skissa+t9
Funny aside: yours is an excellent comment, and yet proof that you didn't read the article, as the first part is almost word-for-word identical to the post.

I don't mean to shame you, I sometimes comment without reading TFA, and in your case you add a few more details that were not present in the article. I just found it interesting.

>>adrian+47
GNU Stow provides this facility to all unices. I use it as a secondary package manager to keep /usr/local under control with self-compiled programs.

>>sph+R1
> Like this very article, there were plenty saying "the /usr split is there for a reason!". No, it's just an historical quirk.

For those of us who ran small-disk NFS workstations back in the day having the split and a common /usr was no quirk and very useful. (There were also diskless (Sun, OpenFirmware netbooting) workstations: common /bin, /usr, but per-machine /var on the NFS server.)

The article states:

> Cheap retail hard drives passed the 100 megabyte mark around 1990, and partition resizing software showed up somewhere around there (partition magic 3.0 shipped in 1997).

Yeah, except if you have a fleet of several hundred or thousand workstations to provision. "Cheap" is relative, especially if you're an academic institution.

>>spijda+v1
> To be clear, GP's stated intention was

> to merge /sbin with /bin, and /usr/sbin with /usr/bin

It's a bit more drastic than you make it out to be. This would give two valid $PATHS to the same commands. It would make tab-completion slow. It would likely break all kinds of compatibility across the SUS. And it is incredibly arbitrary, no better or worse than eliminating system hierarchy entirely and putting everything in /.

>>sph+R1
> It's also dangerous and tiring the opposite attitude in the Linux world

You're literally saying that not arbitrarily changing the file structure of linux is dangerous. I don't think that's what you meant.

It's not about "because it's been that way for 30 years," even though it's been 50 years, but never mind that, it's about consistency and standards. It just does not matter one way or the other what the structure of the file system is, so any agenda to change something that doesn't matter is itself a specious agenda. Changing fundamental design introduces complexity for no good reason. As soon as you do it, you've create a special case that doesn't work anywhere else and jeapardizes compatibility.

>>throw0+fh
Even if a split was pragmatically warranted, the fact that the user directory was chosen is without a doubt a quirk, an accident of circumstance that has since been perpetuated out of tradition (or less charitably: cargo cult mentality.)

>>0dayz+E3
Well, if you have an argument against KISS, we'd all love to hear it. The opposite of KISS is KICKME (Keep It Complicated Keep Me Employed). Life is a pretty good example of successful complexity. But we didn't design life, and we do not maintain it (understatement). Simplicity for simplicity's sake is self-evidently advantageous. Complexity for the sake of complexity is not.

>>mongol+N6
Folding this back onto the question at hand:

  $ find /{usr,bin,sbin}
  /usr
  /usr/bin
  /usr/bin/env
  /bin
  /bin/sh
  find: '/sbin': No such file or directory

>>Maursa+E71
I agree there'd be quite a bit of compatibility breakage and churn associated with trying to change these at this point.

That said, I think one of the better reasons (and ways) to weigh the value of changing some long-term practice is to focus on the anticipated costs of the change on one side of the ledger, and the ongoing (easy to ignore) unbounded costs of the status quo on the other (and appropriately weight them by who pays and how often). To shoot from the hip:

- If it's only a modest improvement that still supports a bit of misunderstanding, folksonomizing, and arguing about where things belong--it'll just waste time and energy better spent elsewhere. Any time would probably be better spent on writing and promoting/propagating a really good canonical reference to the status quo that can help drive out confusion and enable devs/admins answer practical questions (even if inefficiently).

- If (utopia warning) someone is able to significantly improve how accurately and quickly humans can make real dev/admin decisions from a clear mental model _and_ get enough buy-in to do it across all of the major Unix-alikes, it's probably worth some medium-term pain.

FWIW, the ongoing progress of NixOS, which doesn't really have any of these paths (beyond /usr/bin/env and /bin/sh), demonstrates that this pain is surmountable with enough eyes and hands.

>>Maursa+Gx1
I don't thinkit has to be that black and white, KISS in Linux world from my experience has been to see any software that isn't "simple" as bloat, while their software is like a car you only turn left with.