Originally posted by cj.wijtmans
View Post
Fedora 40 Plans To Unify /usr/bin & /usr/sbin
Collapse
X
-
Originally posted by sharpjs View PostI'm all for simplifying this. We aren't running on PDP-11s anymore where we need to split the filesystem over some RL02s and a cavern full of RP07s.
Comment
-
-
Originally posted by ireri View PostJNo, usr is not "user", it means Universal System Resources, learn that already people.
it’s a fairy tale, stop repeating it as if it’s true.Last edited by bumblebritches57; 31 December 2023, 01:09 AM.
Comment
-
-
Originally posted by cjcox View Post
10 years from now. Fedora finally removes last Linux library so that everyone can use Windows.
Comment
-
-
Originally posted by cj.wijtmans View Post
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.
* What is "lower operatin system"? The parts needed for booting the system so for example /usr can be mounted, or do you have a better definition? Then what use does it have beside what already resides in a standard initramfs which on most systems are generated to contain what is needed to mount the filesystems and not much more?
* Why should those commands not be visible to others then root? What difference does that make? As well as related question: how should you place commands like ip, apt/dnf, and other programs that has some functions that do not need root normally? How do you handle things like assigned roles on servers where a user might have some elevated rights but not full root, should you as an admin move the commands they should be using from sbin to bin (and break packages) to match your use case? How about for example applications like "minicom" that needs root unless you give the user access to the /dev/tty*|/dev/modem or what other they are supposed to connect to?
No, I say that /bin, /sbin as well as their counterparts in /usr are based on outdated axioms that due to things like bigger faster drives, initramfs, more complex booting (not only mount, but dmraid/mdadm, lvm, cryptsetup, and what else can be needed to get a working root). And with the death of "two role systems" (that is systems with only root and standard users), and the rise of many levels of role and permission management (selinux, apparmour, other RBACs), it relly does not make sense to try to figure out if a command is supposed to be in sbin or bin, because that is so up to the user/admins use case of the system and really not something the packages can try to guess.
And to make stuff even more problematic, if you make the wrong choice, and others have started to hardcode scripts and others depending on it, then you are stuck with your bad choice.
Say you develop a command that you only see is usable as root. You stick it in sbin. Then someone comes and say "hey, it would be pretty neat if those things you program do also could be read-only listed by a normal user". You agree- But you need to make a big refactoration so you can have a "user" version of the command in bin, a root version of the command in sbin, breaking out the common code to a lib, and escalating the complexity to use your application because all of a sudden the users need to run totally different command to "show" and to "change". Unless you also keep the "show" commands in the root version, making your application even more complex because you essentially have to sync code between the clients when you update a "show" command and so on...... And you cannot move it without breaking users....
.....or you could just dump the command in /usr/bin from the beginning and do not care.
Comment
-
Comment