Understanding the /usr/sbin merge

kantras · 2013-06-04 06:20:01

I can understand why merging the bin and sbin directories under /usr, but I don't understand why the need to merge /usr/sbin into /usr/bin. If you are looking at things where you may have a single user desktop scenario, then it can make sense as the user and the admin would be the same person. If, however, you are wanting to be running it as a multi-user, with clearly defined sets of users and superusers, then why complicate matters for normal users by throwing in a large number of binaries into their path that they won't be able to run anyway? The point could be made that 'they could access them anyway' and whilst that is true, the fact that they are in a seperate directory means you know these utilities require escalated privileges or are most likely used for system administration.

MilenKid · 2013-06-04 06:38:03

As I understand after reading around, the reason is here:

https://bbs.archlinux.org/viewtopic.php … 6#p1280786

Allan announced he was bored

this is so cool

WorMzy · 2013-06-04 07:38:06

From the news post: https://mailman.archlinux.org/pipermail … 22625.html

chord · 2013-06-04 07:45:41

Allan announced he was bored

Every time some of devs was bored, people get headaches. It looks like devs has nothing else to do.
Would be better if they fixed a few existing bugs, but do not produce new.

Last edited by chord (2013-06-04 07:46:17)

fukawi2 · 2013-06-04 08:07:04

https://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html wrote:

...whenever people add features to a "superuser only tool" so that it becomes useful to a regular user, it means it should be moved from sbin to bin. However, in practice this does not happen due to the paths being hardcoded. Instead we just put both sbin and bin in everyone's PATH and the distinction is essentially meaningless.

Awebb · 2013-06-04 09:35:50

Indeed, the number of tools, that will output absolutely nothing to a non-root user, is very small. It's not like putting a file in /sbin ever stopped a regular user from executing it, just because it is not in this user's $PATH.

EDIT:
In addition, the use of sbin as "superuser bin" isn't really correct either. sbin used to be the folder for statically linked binaries. So instead of two different concepts of sbin, we now have only one: legacy symlink.

Last edited by Awebb (2013-06-04 09:38:09)

kantras · 2013-06-04 16:41:03

@fukawi2 I had read the rules but this wasn't being asked as a bikeshed topic, rather wanted to understand the reasoning behind a decision which had been made, especially technical reasons that I might not be aware of. Most discussions I've read related to this topic had a lot of information on why the move from /bin was a good idea, but the only information I had really found on the /usr/sbin migration to /usr/bin seemed to be 'doubt its needed any more' Design decisions are important to keep in mind when working with any distribution, whether maintaining systems using it or packaging applications for it.

Trilby · 2013-06-04 16:44:23

Kantras, I think you read into fukawi's signature as if it was part of the post. The link to the forum rules (while always useful) was not directed specifically to you.

karol · 2013-06-04 16:45:15

Occam's razor seems a nice design decision to follow, it fits Arch philosophy.

Last edited by karol (2013-06-04 16:45:46)

kantras · 2013-06-04 16:54:06

@Trilby Thanks, you are right - the fact his response was quoted threw me off

The points made do make sense - it's just a slight shift in thinking. Off to help get the xen aur package updated.

fukawi2 · 2013-06-04 23:09:47

@Kantras Apologies for the confusion there; I will adjust my signature to avoid that

As far as the original question, the extract I quoted is the only reasoning I can find among the Arch dev's discussion behind merging sbin and bin

deltaecho · 2013-06-05 04:12:36

Out of curiosity, what do you find when you run the following grep through /usr/bin (/usr/sbin and /etc are good places to look, too)?

grep -rnE '[^a-zA-Z0-9_~-]\/s?bin\/[a-zA-Z0-9_-]+' /usr/bin

EDIT (2013-06-04): Tweaked the regex.

EDIT (2013-06-04): I had not finished updating filsystem yet, sorry. The bin directories are symlinked for backwards compatibility. I'm satisfied with this solution.

Last edited by deltaecho (2013-06-05 04:33:30)

WonderWoofy · 2013-06-05 04:21:47

chord wrote:

Allan announced he was bored
Every time some of devs was bored, people get headaches. It looks like devs has nothing else to do.
Would be better if they fixed a few existing bugs, but do not produce new.

I would think that as an Arch user, you might want to actually be on the bleeding edge. But if this scenereo is what you want, that is devs fixing bugs signifcantly more than they keep up with the new, I think that you would find a happy home with something like debian. Stability and relatively few bugs are what they are known for.

Allan · 2013-06-05 05:34:29

It is amazing that despite wantonly creating new bugs and ignoring the old ones, the number of bug reports in our bug tracker is quite stable over time...

ngoonee · 2013-06-05 05:57:43

Allan wrote:

It is amazing that despite wantonly creating new bugs and ignoring the old ones, the number of bug reports in our bug tracker is quite stable over time...

Only amazing if you fail to consider the number of complaining users who have mysteriously been "disappeared" by men in black vans.

chord · 2013-06-05 10:20:37

WonderWoofy wrote:

I think that you would find a happy home with something like debian. Stability and relatively few bugs are what they are known for.

I found a happy home with gentoo. A bit less 'at bleeding edge', but rock solid and much more stable than arch.
But I need arch for some temporary goals.

Allan wrote:

It is amazing that despite wantonly creating new bugs and ignoring the old ones, the number of bug reports in our bug tracker is quite stable over time...

I can explain this miracle: when something (package for example) was marked as 'irrelevant' and discarded from repo, all the bugs that relative to this package dropped as well. Instead of old bugs we getting a new 'bleeding edge' bugs. So the number of bugs remains approximately constant.

skanky · 2013-06-05 10:43:21

I just have one/two question/s about this change.

How much effort (if any*) should go into fixing paths in scripts, functions, etc.? Are the symlinks ever (as far as can be predicted) going to go away?
I did wonder about env. variables, eg SHELL, but that would require updating passwd. Is that likely to happen anyway?

* - would sticking with /bin be better for portability?

WorMzy · 2013-06-05 10:51:33

It's as good a time as any to switch to the '#!/usr/bin/env <shell>' shebang, but the symlinks won't ever go away. Allan has specifically said that "There is no way ever that /bin/bash will not work on an Arch system." (Unless the user breaks this themselves, of course)

skanky · 2013-06-05 10:55:53

WorMzy wrote:

It's as good a time as any to switch to the '#!/usr/bin/env <shell>' shebang, but the symlinks won't ever go away. Allan has specifically said that "There is no way ever that /bin/bash will not work on an Arch system." (Unless the user breaks this themselves, of course)

Thanks, I'd not seen that.

WonderWoofy · 2013-06-05 16:45:49

@skanky, it should be noted though that although for now pacman will install files along a path made of symlinks, this ability is probably going to be removed as of pacman 4.2. So I think that any necessary effort in order to put binaries into /usr/bin needs to be taken. Of course, this is referring to unofficial repositories and the AUR, as (hopefully) all the packages in the official repos have been updated in this way already.

HalosGhost · 2013-06-05 16:50:48

WW, all official packages have been updated and rebuilt.

All the best,

-HG

Arch Linux

#1 2013-06-04 06:20:01

Understanding the /usr/sbin merge

#2 2013-06-04 06:38:03

Re: Understanding the /usr/sbin merge

#3 2013-06-04 07:38:06

Re: Understanding the /usr/sbin merge

#4 2013-06-04 07:45:41

Re: Understanding the /usr/sbin merge

#5 2013-06-04 08:07:04

Re: Understanding the /usr/sbin merge

#6 2013-06-04 09:35:50

Re: Understanding the /usr/sbin merge

#7 2013-06-04 16:41:03

Re: Understanding the /usr/sbin merge

#8 2013-06-04 16:44:23

Re: Understanding the /usr/sbin merge

#9 2013-06-04 16:45:15

Re: Understanding the /usr/sbin merge

#10 2013-06-04 16:54:06

Re: Understanding the /usr/sbin merge

#11 2013-06-04 23:09:47

Re: Understanding the /usr/sbin merge

#12 2013-06-05 04:12:36

Re: Understanding the /usr/sbin merge

#13 2013-06-05 04:21:47

Re: Understanding the /usr/sbin merge

#14 2013-06-05 05:34:29

Re: Understanding the /usr/sbin merge

#15 2013-06-05 05:57:43

Re: Understanding the /usr/sbin merge

#16 2013-06-05 10:20:37

Re: Understanding the /usr/sbin merge

#17 2013-06-05 10:43:21

Re: Understanding the /usr/sbin merge

#18 2013-06-05 10:51:33

Re: Understanding the /usr/sbin merge

#19 2013-06-05 10:55:53

Re: Understanding the /usr/sbin merge

#20 2013-06-05 16:45:49

Re: Understanding the /usr/sbin merge

#21 2013-06-05 16:50:48

Re: Understanding the /usr/sbin merge

Board footer