Re: On merging bin and sbin
A few thigns I have seen in this thread:
Fedora/Arch/Whomever: I don't think it matters who thought of what first. Sometimes, it's okay to be different. I have moved all of my systems away from Slackware and Fedora/RedHat/etc. TO Debian because I think Debian does it better. Please do not think that the "pull of RedHat" means anything. Even the larger industry is not necessarily "in love" with RedHat and its variants so much that the members of the Debian project should feel any "pull" from there, except perhaps that the reverse is also true. If they have a GOOD idea, maybe we should do that. But the idea isn't "good" or "bad" just because Fedora is doing it (or Arch or anyone else).
So regardless of who thought of these filesystem merges (no one will get "credit" anyway), the main question is whether or not it's a good idea in the first place.
The original split between /bin and /sbin was decades ago. It was done for good reasons, and as far as I can tell, those reasons have not changed. There are still binaries (both CLI-invoked and fully automated) that non-admins have little or no business having in their PATHs.
Also, there have been numerous occasions in my many years when I thought that merging two collections seemed "simpler," only to find that the result was so large that it became a new problem. While obviously a separate directory for each file (the other extreme) would be silly, there is no danger of that here. Having a single directory with all executables in it sounds messy and dangerous to me, and reminds me of how MS-DOS would do things.
(Side note: Be wary of discussions that assume that daemons are never executed by hand. Postfix, dhcpd, httpd, syslog-ng, and many others have "syntax check" functions built into the daemon binaries that are often executed manually. Version checks are often "daemon --version" or similar. Don't get caught in the assumption that "no one runs httpd by hand." Yes. They do.)
I would also suggest that what Marco said is perhaps the most important:
> I think that the benefits from doing this are tiny, and just adding /usr/sbin/ to the $PATH would solve almost everything.
Not only is this the most important point (effort vs. value), but if people believe that a directory merger would be beneficial, adding the /sbin directories to users' PATHs is not only the FASTER way to accomplish that, but it is EASILY REVERSED. Far easier to make a change to /etc/profile than to change how dozens of packages' build parameters are set.
Last thing: The idea of detecting cases where multiple binaries have the same name is a verey good one. It should also be possible to automate this effort in a number of ways. I would be happy to help with this, if it's just a matter of someone putting in the effort. A number of "crude by effective" methods have already come to mind, some of which only require access to the repos to accomplish. (The laziest method involves having a test machine with EVERY package installed... but I'm not sure if that is practical.)
Let me know if I can help.
--J
> On Feb 28, 2024, at 05:52, Marco d'Itri <md@Linux.IT> wrote:
>
> On Feb 28, Helmut Grohne <helmut@subdivi.de> wrote:
>
>> Please allow me to push back on this one as well by raising a few
>> concerns.
> Also, I think that the benefits from doing this are tiny, and just
> adding /usr/sbin/ to the $PATH would solve almost everything.
>
> --
> ciao,
> Marco
Reply to: