You are not logged in.

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

kantras
Member
Registered: 2013-06-04
Posts: 12

Understanding the /usr/sbin merge

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.

Offline

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

MilenKid
Member
Registered: 2013-04-21
Posts: 86

Re: Understanding the /usr/sbin merge

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 smile

Offline

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

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,787
Website

Re: Understanding the /usr/sbin merge


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

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

chord
Member
Registered: 2012-11-07
Posts: 121

Re: Understanding the /usr/sbin merge

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)

Offline

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

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,217
Website

Re: Understanding the /usr/sbin merge

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.

Offline

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

Awebb
Member
Registered: 2010-05-06
Posts: 6,275

Re: Understanding the /usr/sbin merge

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)

Offline

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

kantras
Member
Registered: 2013-06-04
Posts: 12

Re: Understanding the /usr/sbin merge

@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.

Offline

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

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: Understanding the /usr/sbin merge

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.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

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

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: Understanding the /usr/sbin merge

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

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

Offline

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

kantras
Member
Registered: 2013-06-04
Posts: 12

Re: Understanding the /usr/sbin merge

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

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

Offline

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

fukawi2
Ex-Administratorino
From: .vic.au
Registered: 2007-09-28
Posts: 6,217
Website

Re: Understanding the /usr/sbin merge

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

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

Offline

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

deltaecho
Member
From: Georgia (USA)
Registered: 2008-08-06
Posts: 185

Re: Understanding the /usr/sbin merge

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)


Dylon

Offline

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

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Understanding the /usr/sbin merge

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.

Offline

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

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: Understanding the /usr/sbin merge

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...

Offline

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

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: Understanding the /usr/sbin merge

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.


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

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

chord
Member
Registered: 2012-11-07
Posts: 121

Re: Understanding the /usr/sbin merge

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.

Offline

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

skanky
Member
From: WAIS
Registered: 2009-10-23
Posts: 1,847

Re: Understanding the /usr/sbin merge

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?


"...one cannot be angry when one looks at a penguin."  - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle

Offline

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

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,787
Website

Re: Understanding the /usr/sbin merge

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)


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

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

skanky
Member
From: WAIS
Registered: 2009-10-23
Posts: 1,847

Re: Understanding the /usr/sbin merge

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.


"...one cannot be angry when one looks at a penguin."  - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle

Offline

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

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: Understanding the /usr/sbin merge

@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.

Offline

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

HalosGhost
Forum Moderator
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 2,089
Website

Re: Understanding the /usr/sbin merge

WW, all official packages have been updated and rebuilt.

All the best,

-HG

Offline

Board footer

Powered by FluxBB