A Proposed Change for Fedora 40: Unify /usr/bin With /usr/sbin (phoronix.com)
81
"This is a proposed Change for Fedora Linux..." emphasizes its page on the Fedora project Wiki. "As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee."
But Phoronix reports that "One of the latest change proposals filed for Fedora 40 is to unify their /usr/bin and /usr/sbin locations." The change proposal explains:
"The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to /usr/bin and /usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH."
Fedora years ago merged /bin and /usr/bin and as the last step they want to unify /usr/bin and /usr/sbin.
The change proposal argues that with this change, "Fedora becomes more compatible with other distributions."
- We have /sbin/ip while Debian has /bin/ip
- We have /bin/chmem and /bin/isosize, but Debian has /sbin/chmem and /sbin/isosize
- We also have /sbin/{addpart,delpart,lnstat,nstat,partx,ping,rdma,resizepart,ss,udevadm,update-alternatives}, while Debian has those in under /bin, etc.
- Fedora becomes more compatible with Arch, which did the merge a few years ago.
The proposal on the Fedora project Wiki offers this summary: The split between /bin and /sbin is not useful, and also unused. The original split was to have "important" binaries statically linked in /sbin which could then be used for emergency and rescue operations. Obviously, we don't do static linking anymore. Later, the split was repurposed to isolate "important" binaries that would only be used by the administrator. While this seems attractive in theory, in practice it's very hard to categorize programs like this, and normal users routinely invoke programs from /sbin. Most programs that require root privileges for certain operations are also used when operating without privileges. And even when privileges are required, often those are acquired dynamically, e.g. using polkit. Since many years, the default $PATH set for users includes both directories. With the advent of systemd this has become more systematic: systemd sets $PATH with both directories for all users and services. So in general, all users and programs would find both sets of binaries...
Since generally all user sessions and services have both directories in $PATH, this split actually isn't used for anything. Its main effect is confusion when people need to use the absolute path and guess the directory wrong. Other distributions put some binaries in the other directory, so the absolute path is often not portable. Also, it is very easy for a user to end up with /sbin before /bin in $PATH, and for an administrator to end up with /bin before /sbin in $PATH, causing confusion. If this feature is dropped, the system became a little bit simpler, which is useful especially for new users, who are not aware of the history of the split.
But Phoronix reports that "One of the latest change proposals filed for Fedora 40 is to unify their /usr/bin and /usr/sbin locations." The change proposal explains:
"The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to /usr/bin and /usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH."
Fedora years ago merged /bin and /usr/bin and as the last step they want to unify /usr/bin and /usr/sbin.
The change proposal argues that with this change, "Fedora becomes more compatible with other distributions."
- We have /sbin/ip while Debian has /bin/ip
- We have /bin/chmem and /bin/isosize, but Debian has /sbin/chmem and /sbin/isosize
- We also have /sbin/{addpart,delpart,lnstat,nstat,partx,ping,rdma,resizepart,ss,udevadm,update-alternatives}, while Debian has those in under /bin, etc.
- Fedora becomes more compatible with Arch, which did the merge a few years ago.
The proposal on the Fedora project Wiki offers this summary: The split between /bin and /sbin is not useful, and also unused. The original split was to have "important" binaries statically linked in /sbin which could then be used for emergency and rescue operations. Obviously, we don't do static linking anymore. Later, the split was repurposed to isolate "important" binaries that would only be used by the administrator. While this seems attractive in theory, in practice it's very hard to categorize programs like this, and normal users routinely invoke programs from /sbin. Most programs that require root privileges for certain operations are also used when operating without privileges. And even when privileges are required, often those are acquired dynamically, e.g. using polkit. Since many years, the default $PATH set for users includes both directories. With the advent of systemd this has become more systematic: systemd sets $PATH with both directories for all users and services. So in general, all users and programs would find both sets of binaries...
Since generally all user sessions and services have both directories in $PATH, this split actually isn't used for anything. Its main effect is confusion when people need to use the absolute path and guess the directory wrong. Other distributions put some binaries in the other directory, so the absolute path is often not portable. Also, it is very easy for a user to end up with /sbin before /bin in $PATH, and for an administrator to end up with /bin before /sbin in $PATH, causing confusion. If this feature is dropped, the system became a little bit simpler, which is useful especially for new users, who are not aware of the history of the split.
Debian Compatible (Score:5, Interesting)
Makes sense.
Most 3rd party software doesn't package for Redhat and with the recent wildly racist IBMHat leaks many businesses will be migrating to SuSE or a Debian-fanily distro.
Any closer parallel with Debian is adventageous.
It"s a shame what happened to Redhat (starting six years ago from my experience) but as of Debian 12 (including firmware) I don't know of any reason to prefer Fedora anymore.
Not to mention Debian's continued strong support for the GPL, including the "no further restrictions clause".
Re: (Score:2)
Re: (Score:1)
Poor Katie just did all her commits on someone else's computer... :)
Re: (Score:2)
Jews have always been acceptable targets. We get a small break every so often and it becomes a bit less fashionable, but it's always there. And the whole using criticisms of Israel as a segue into anti-Semitism is old news. Been popular for years.
Re: (Score:2)
I have been using openSuse for around 25 years now, the machine I'm writing this on was a fresh install in early 2018 but it runs the current level of the distribution (and with a new processor as of a year ago). This background is because /bin, /sbin, /usr/bin, usr/sbin are all directories - no symlinks involved. The only top level symlink is /tmp. If Fedora has changed /bin to be a symlink to /usr/bin that has either not made it to openSuse or they don't change that as part of the update process when m
Why? (Score:1)
>"The change proposal argues that with this change, "Fedora becomes more compatible with other distributions."
Just an FYI, but on this Mint 21.2 system: /bin -> /usr/bin /sbin -> /usr/sbin
In /usr, they are each real and separate directories.
As for /bin vs /usr/bin, or /sbin vs /usr/sbin, I can see why that is not needed (it is an old concept about mounting order that really isn't needed anymore and symlinking them is fine). But separation of bin and sbin has a very good and logical reason- to show
Re:Why? (Score:4, Funny)
"The split between /bin and /sbin is not useful"
Debatable. Just like it is debatable that every kernel function should be moved into systemd.
In future news: "Fedora Moves "/bin" into systemd" :-)
Re: (Score:2)
Ancient history that most don't worry about now; you could mount just the / file system, with /usr on a different disk, and so /bin and /sbin would have just enough tools to do maintenance, and to create/validate/repair other drives. But today you can stick a terabyte in your pocket so such styles aren't so important. /bin vs /sbin I suspect was to prevent accidentally trying to run a system binary by normal users. It's not really security, just to stop some typo on the command line by a student.
Re: (Score:2)
Why?
Re: (Score:3)
Interactive shells for normal users don't need to autocomplete commands with executables from /use/sbin.
There are probably some other reasons, but that seems like the main one.
Re: (Score:2)
Re: (Score:2)
More history (Score:5, Informative)
The split between /bin and /sbin is not useful, and also unused. The original split was to have "important" binaries statically linked in /sbin which could then be used for emergency and rescue operations. Obviously, we don't do static linking anymore. Later, the split was repurposed to isolate "important" binaries that would only be used by the administrator.
It was also used to support diskless clients, as on SunOS/Solaris, so they could all share a common (usually read-only) NFS mounted "/usr" with each client having its own NFS mounted (read/write) "/". I had a diskless SunOS workstation on my desk, and also administered many other SunOS (later Solaris) servers/clients, *way* back when I was at NASA LaRC -- along with several DEC Ultrix, Convex and Cray (2, YMP) systems.
Re: (Score:2)
I read that it was a carry over from the days of 5Mb RL01 disk packs. Not enough space to fit all the user space on a single disk.
Re: (Score:2)
Re: (Score:2)
>"I use /usr/sbin for scripts. I know that wasn't the original purpose. It is however a nice tidy place to put them and I've been doing it that way for thirty years."
I wouldn't do that, since it is kinda "polluting" a system directory. I put all my scripts somewhere else, something like /opt/bin, /opt/sbin, and /opt/cronbin.... separating out user scripts, root-only scripts, and scripts run by cron. Yes, it does mean changing $PATH for users, but small price to pay and is an easy, one-file change. For
Re: (Score:2)
Another tip, completely unrelated, but if I change ANY system configuration file, I first cp -a FILE FILE.org. That way I can search the system very quickly and know what things I touched. And, of course, I comment the changes in the file and include my name so I know WHY I changed it. Has saved me so many countless times.
If you are using that workflow a better option would be to use RCS. Replace your `cp -a ..` with a co / ci (check in checkout) combo and you can get way better metadata for what you have done.
You can progress up the revision control chain through cvs/svn -> git (or others) but they can be quite complex.
For manageing simple files under something like /etc on a single host though ... RCS is great
Re: (Score:2)
>" a better option would be to use RCS"
You are right, of course. :)
And one of my employees does just that
Re: (Score:2)
if I change ANY system configuration file, I first cp -a FILE FILE.org
Assuming the config file is under /etc/ why not just use etckeeper [tecmint.com] and use an industrial-strength tool like git to manage config file changes?
Re: (Score:2)
Another tip, completely unrelated, but if I change ANY system configuration file, I first cp -a FILE FILE.org.
You might want to check out the package "etckeeper" ...
- https://etckeeper.branchable.c... [branchable.com] ...)
- https://ubuntu.com/server/docs... [ubuntu.com]
(and other references
Re:More history (Score:4, Insightful)
I use /usr/sbin for scripts. I know that wasn't the original purpose. It is however a nice tidy place to put them and I've been doing it that way for thirty years.
I'd recommend "/usr/local/bin" and/or "/usr/local/sbin" for stuff like that and add those to your PATH ...
Re: (Score:2)
My $PATH is one of /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin /home/$USER/bin:/usr/local/bin:/usr/bin:/bin
or
The second one also applies if I enter "sudo echo $PATH" and that is a definite irritant, I'd love to see /sbin point to /bin and /usr/sbin point to /usr/bin.
This is under the current level of "openSuse Leap" (rather than Tumbleweed, the "rolling release" version), on a system which has all new levels applied as Updates.
Re: More history (Score:2)
Re: (Score:3)
Just to add a bit of context. Before I quit as a Debian developer, I implemented mounting of /usr in the initramfs so that it was always pre-mounted for use by both sysvinit/initscripts or by systemd same as done for the rootfs. That was over a decade ago, for Debian wheezy if I recall correctly.
The sequencing of what can be done before and after the /usr mount was always a bit convoluted and fragile, and having a fully-working set of local mounts before init starts is quite valuable. This is independent
Re: (Score:1)
There are other issues linked to throwing away old standards / wisdom / ways of doing things. For exemple, 30 years of experience and knowledge about linux and unix systems went out the window with systemd. Everyone had to relearn different ways of doing it all again and for most admins, for minimal gain I date say.
Re: (Score:2)
That was the origin of /var, but not related to sbin.
"Obviously, we don't do static linking anymore"
Why is that obvious? And why don't we?
The idea was to have a few critical things in / for the booting and repair processes that could run before /usr was mounted or if it was damaged.
Huge news (Score:2)
Glad I didn't miss this one.
Not a problem I have to worry about. (Score:2)
Static linking (Score:2)
Just why isn't static linking used anymore? Is it because the idea is old and containers are the new hotness?
Re:Static linking (Score:4, Informative)
Probably. Although I wouldn't say it isn't used anymore, some of it morphed into just including libraries...
Static binaries were very useful. And simple as well. Sure, they use more memory, but it is a small price to pay when it just has to work. Lots of commercial software is/was either statically linked, or includes libraries and then a launcher script that calls the binary with a LD_LIBRARY_PATH set.
Re:Static linking (Score:5, Informative)
Nope. It's because of changes in how we can boot systems. Back in the day, booting from anything other than the primary storage device was a non-trivial operation. You not only needed boot media, you needed a boot ROM installed that supported booting from the type of device you had media for. It could get as bad as having to manually enter the boot ROM code by hand on the console. Boot media itself was non-trivial too, think a disk pack big enough to need a drive the size of a washing machine to hold it. If you had a system with a console floppy drive it topped out at 1.2Mb, not enough to hold a reasonable system. With those constraints, being able to boot a recovery system off your normal root volume was a necessity.
These days though, you just plug in a USB drive with a recovery image on it, mount the root volume and start repairs. The smallest drives can hold several gigabytes, space isn't an issue. So why waste space on the root volume with copies of the utilities you have on your recovery boot media?
Re: (Score:2)
Because it's a good idea until you really understand the implications.
It means that all software that uses libFOO needs to be updated on every libFOO security update. Meanwhile, using a shared libFOO means updating that single shared instance updates everything that dynamically links to it.
On a system that only uses distro-created packages, no big difference apart from a pure waste of bandwidth and update time. But can you guarantee that a 3rd-party repo linking its pr
Re: (Score:2)
But can you guarantee that a 3rd-party repo linking its programs with a static libFOO will update its software in a timely fashion?
No one can guarantee that, not even the distro with it's own repos. What passes for a modern Linux distro today is really just a hodgepodge mess of random libraries and software that was coded by throwing shit at a dart board and shipping what stuck.
I.e. There's no proper API versioning / support made by the software's developers, and no real care about the quality of the software that gets dumped into the repos by the distro's maintainers. Until you fix that mess, you cannot guarantee anything about upd
Re: (Score:2)
We used to not expect to have /usr available during boot on most Unix systems; now on Linux we have neither /bin nor /usr and instead just bundle everything we need during boot into a ramdisk because our memory goes on forever compared to olden times, we change the root when we're done with it (when the required system volumes are mounted, mostly) so that we can unmount it and free the ram again. And many systems now only have a boot and a root.
Re: (Score:2)
Well, golang is static by default...
There's only one question to ask (Score:2, Funny)
What would Slackware do?
Re: (Score:2)
Slackware does everything right but package management. I hear theyve improved there too though.
Re: (Score:2)
Almost correct, Slackware's package management is good, you are asking about dependency resolution. 90% of the time there is no issues, plus once you install Soackware from the Install Media, you have everything you need. Internet Connection not needed.
But yes, Slackware still follows LSB in all cases where it does not break things. The only issue is RedHat forced Slackware to mount removal drives under /media as opposed to /mnt were I believe it should be :)
Re: There's only one question to ask (Score:2)
Package dependency is not exactly an issue, unless you expect it to be automatic as of other distros. Slackware allows you to "break" your system, if you want, it also allows usage of supporting tools such as slackpkg file-search lib/libxyz and slackpkg install xyz to sort out your missing dependencies.
Plus, you have a running Slackware server using almost as low disk space as of traditional BSD system, which is impressive compared with any other Linux distribution out there and their bloatware.
Why /sbin ? (Score:2)
Back in the PDP-11 days I remember that there was a /bin and /sbin. This was long before dynamic linking was developed, the PDP-11 is a 16 bit machine. What was in /sbin were programs for System admin or the Super user.
sbin (Score:5, Insightful)
Oh man having a bunch of important binaries statically linked for emergencies. What a silly and useless idea better do away with it.
Used to be once you climbed the steep learning curve and finally wrapped your head around Unix you could do anything, fix anything, from any totally trashed state.
Redhat and then connonical have taken turns shitting on this. First brining in welcome ease of use and quality of life improvements and then fundamental changes that force everything to do it the new way. Always easy to take off and run with but you’ll never ever know how it works. :(
Re: (Score:1)
Nothing has changed in this regard. You can still recover a modern system just like an ancient one. All the more pointing to the fact that they are right in this regard, the statically linked binaries are useless.
initramfs (Score:2)
Re: sbin (Score:2)
I have another proposal (Score:1, Troll)
Do away with /bin and /sbin and move all those binaries inside systemd, ala busybox,
I mean we're halfway there already. Might as well go all the way...
Re: (Score:1)
Do away with /bin and /sbin and move all those binaries inside systemd, ala busybox,
I mean we're halfway there already. Might as well go all the way...
Why not roll the kernel and GUI into systemd as well?
Popular and Simple is Better (Score:2)
Vandalism. (Score:1)
They're not this stupid. This is a clearly stupid move, but they have to know that. This is vandalism disguised as incompetence disguised as competence.
Re: (Score:2)
Looks like it. I wonder why they are doing it though.
Re: (Score:1)
My guess is they think that if they can scare away all the independent Linux experts then they can rule over the rubble that's left.
Re: (Score:2)
Red Hat? Yes, probably. These fuckers think they own Linux.
Re: (Score:1)
Red Hat? Yes, probably. These fuckers think they own Linux.
Well, they effectively do. Look at the source code to the stuff you use and love. Most of the time you'll see it came from RedHat. Used to love how debian/ubuntu people would crow about how great something was only to find out - RedHat made that. It would shut them up fast. Debian/ubuntu ported it over after the heavy lifting was done. They should be using Fedora/RHEL, not debian.
What runs the world? It's not debian. It's RHEL or a derivation such as Oracle Linux.
Good old days. Not happy so much with IBM ru
Re: (Score:1)
I sure hope you don't think network-manager or pulseaudio are vindications of this behavior, because they're both atrocious as well.
Re: (Score:1)
Network Manager just takes getting used to like many other things. To me it's no big deal. Same with puleaudio. I still love ifconfig, route and so on. However, NetworkManager does a great job at managing and re-establishing things when they screw up. As long as it's configured correctly. It's easy to complain about things.
Setting up X11 (You used to have to set a prototype for the screen with timing, and so on), Setting up your wifi, all of the work on clustering, the work on SE Linux, and so on and so for
Why (Score:5, Informative)
The original split was to have "important" binaries statically linked in /sbin which could then be used for emergency and rescue operations.
Not exactly.
Originally, sbin held programs only root would use while bin held programs any user would use. So, "ip" which configures networking on the machine would be in sbin while "ls" which lists a directory would be in bin. sbin would only be present in root's path variable, so regular users wouldn't lose cycles while the shell searched sbin for the program they wanted to run.
In addition, /bin and /sbin held programs needed to boot the system and perform basic diagnostics while all the daemons and user-level stuff would live in /usr. This allowed /usr to be on a different filesystem than the root, mounted after /sbin/init had already been invoked. And possibly living on a different physical hard disk.
These points are largely moot in modern systems. Nobody makes /usr a distinct filesystem any more, hard disks are too big to bother. And the combination of effective disk caching and indexed directories makes it more efficient for the path variable to have a few directories with many programs instead of many directories with few programs.
Re: (Score:2)
Also, the initrd kind of replaced the root filesystem as the place containing the boot-critical programs.
Re: (Score:2)
I have a system I originally set up in 2010 as dual-boot with Windows 7, it is now dual-boot with Windows 10. At some point the Linux root directory became too full and I created a seperate /usr partition. A recent Microsoft change means that if I make a major hardware update (and repartitioning would definitely count) the key becomes invalid. I'm not about to buy a new key for a system that old, and I'm not about to buy a
Re: (Score:1)
I have a system I originally set up in 2010 as dual-boot with Windows 7, it is now dual-boot with Windows 10. At some point the Linux root directory became too full and I created a seperate /usr partition. A recent Microsoft change means that if I make a major hardware update (and repartitioning would definitely count) the key becomes invalid. I'm not about to buy a new key for a system that old, and I'm not about to buy a replacement machine for an OS I hardly ever use.
I wouldn't say nobody. Load up a RHEL system with a security profile. Such as CIS or Stigs. I did it one time. I had a separate filesystem for a whole bunch of directories. IMHO, it was overkill. Yet some poor souls have to run their systems like that. People used to be critical of me for just having it all in one big fricken filesystem. Then my systems would run fine and their systems would crash because /var or something would run out of disk. You can have your cake and eat it too, it'll cost a lot of mon
Monolithic practices (Score:4, Insightful)
If it ain't broken, don't fix it.
No, it's not broken. In fact, I'll argue that the differences here make distros more resilient. If everything was done the same way under all distros, then we'll see a surge in malware, (successful) exploits/script kiddie shit, etc..
Let's not morph into one giant glob of shit. That's why I moved away from Windows and M$ products.
It's different, yes.. Different is good.
Re: (Score:2)
No, it's not broken. In fact, I'll argue that the differences here make distros more resilient. If everything was done the same way under all distros, then we'll see a surge in malware, (successful) exploits/script kiddie shit, etc..
The differences between distros in fact break scripts that need to refer to these tools by their absolute paths, which includes anything called from cron where the value of PATH can be anything and systemd services, or any script where use of relative paths is risky for security reasons, exactly to avoid malware in /home/user/.local/bin, for example.
So for all sense and purposes, the current state is broken. Your suggestion that will foil script kiddies, while in theory plausible and potentially having occu
Re: (Score:2)
If it ain't broken, don't fix it.
That's a regressive statement that stops all progress and improvement. Why buy a car? The hose wasn't broken. The reality is times have changed, systems have changed, the fundamental reasons things were done the way they were done 30 years ago have in fact changed.
In fact, I'll argue that the differences here make distros more resilient. If everything was done the same way under all distros, then we'll see a surge in malware, (successful) exploits/script kiddie shit, etc..
Calm yourself man. Nothing and I really mean *NOTHING* is changing here from a malware / resilience perspective. As it it from the end user (i.e. malware) perspective the functionality is already identical between systems. The only thing changing
Re: (Score:2)
Different paths make life hard for everyone, not just for the malware. The same differences cause trouble to all developers.
Did you say unify? (Score:4, Funny)
Just put it all under /OS2Warp/ and you are all set. /s
50 years (Score:2)
Amazing that this layout and nomenclature has persisted essentially unchanged for 50 years.
Why have directories at all? (Score:2)