zlacker

[return to "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]
1. EdScho+Oa[view] [source] 2022-05-11 07:57:55
>>taubek+(OP)
I once sent out a proposal on the FreeBSD lists to merge /sbin with /bin, and /usr/sbin with /usr/bin. People were concerned that this would slow down the system, due to PATH lookups taking longer. Even when I demonstrated the opposite was true (it being faster due to fewer directories needing to be scanned), I wasn't able to get consensus. What a shame.
◧◩
2. Maursa+De[view] [source] 2022-05-11 08:33:24
>>EdScho+Oa
> 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.

◧◩◪
3. spijda+8g[view] [source] 2022-05-11 08:48:02
>>Maursa+De
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.
◧◩◪◨
4. Maursa+6l1[view] [source] 2022-05-11 15:38:19
>>spijda+8g
> 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 /.

[go to top]