Fedora 40 Plans To Unify /usr/bin & /usr/sbin

[Mitch]

Just put everything inside C:\

Jokes aside:


No, usr is not "user", it means Universal System Resources, learn that already people.

I never thought about it, but that's conceptually opposite of a user folder when you think about it

[Mitch]

I have never once in my long career seen a server with a more complicated partition layout than a home computer. It is at most 3 partitions: EFI (boot), root, swap or maybe even 4 if you're slapping in some extra drives for whatever role the server is performing e.g. /var/lib/whatever for db server. Before EFI, it was common to see just 2 partitions. It doesn't make sense anymore. Red Hat knows this and knows their customer requirements, and having 4 separate places for binaries which should be exec'd by CLI just isn't it for 99.99999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999 9999999999999% people.

I hate it when we as a society deprioritize the use cases of 10^-49 percent of people just to benefit the use cases of the rest.

[cj.wijtmans]

The right way to do this would be to explain what my logical claim was and how it was an oversimplification. Bonus points would accrue on presentation of an alternate claim.

Your logical claim? I quoted it first post. I called it out as a fallacy. You incorrectly called it a strawman. There really is nothing to discuss. Lookup what oversimplification is and be done with this.

[elml]

... I doubt that any new servers which are provisioned do anything fancy with the partition layout.

In the new world of lazy clicking and easy cheap VMs and Containers, indeed so. That was supposedly the motivation behind creating systemd. (NB: Careful use of the word 'creating' as opposed to Developing... But that's a whole another story.)

...because doing that forces you to allocate some amount of disk space to different directories which cannot be changed without completely decommissioning the host for some amount of time with no gains that couldn't be had with bind mounting or similar...

Why ever switch off, or otherwise reboot, a perfectly good running system that is handling lots of live traffic, for the sake of swapping physical disks around? Or for the sake of recovering from disk failures? With a lot of traffic comes great disruption from switching off a lot of connections and people... Not good for happiness...

Hence instead, we have long had hot-swapping, along with for flexibility and live upgrading the disk storage, we have long had the evolution of:

• mdraid
• lvm
• btrfs
• nfs
• ceph
• hadoop

With the magic of bind, you can even do a brain transplant on a live running server without any disruption!

Since then, we've got the lazy scary tricks of moving live VMs around hardware. Even so, you still suffer a penalty of a brief service interruption whilst that VM is frozen to synchronise the last few blocks. (Better is to do the load balancing in flight via the proxies/routers, but "people are lazy...".)


All a game of whether you dumb the system down to point 'n' prey Containers, or whether you actually pay someone who actually understands how the systems work.

Meanwhile, datacentres and 'outsourcing' are cheap... And they are a good excuse for the Management to blame someone else...


Happy crunchin'!
Martin

[anarki2]

Good. Access controls should be done by access controls (permissions, ACLs, whatever), not by random path choices.

[aviallon]

Huh you cant think of anything? What about a command that works for root only. Sure a command should not work if its root only but why should it be visible to a non root user? /usr/bin is fine for user interactive programs like bash while /bin is fine for the lower operating system. Personally i just made a script for /usr/local/sbin. It has no place in to be in /usr/local/bin because non root user will never interact with it.

Actually, I found a good use.
It allows mounting /usr/bin as nosuid

[Tomin]

Actually, I found a good use.
It allows mounting /usr/bin as nosuid

I think it's the opposite though. Suid bit is for running apps as another user. If you are root (and thus had access to /usr/sbin by default), why would you need suid programs?