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: 5,557

Re: Understanding the /usr/sbin merge


Sakura:-
Mobo: ASUS P8Z77-V PRO // Processor: Intel Core i7-3770K 3.4GHz // GFX: nVidia GeForce GTX 970 Ti // RAM: 32GB (4x 8GB) Corsair DDR3 (@ 2133MHz) // Storage: 1x 3TB Seagate SATAII 5x 1TB Samsung SATAII, 2x 120GB Corsair SSD

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
Forum Moderator
From: .vic.au
Registered: 2007-09-28
Posts: 5,304
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: 4,541

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
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 14,217
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.


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Offline

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

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

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
Forum Moderator
From: .vic.au
Registered: 2007-09-28
Posts: 5,304
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: Seattle, Washington (USA)
Registered: 2008-08-06
Posts: 182

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,412

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
Developer
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,436
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: 6,856

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,841

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: 5,557

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: ASUS P8Z77-V PRO // Processor: Intel Core i7-3770K 3.4GHz // GFX: nVidia GeForce GTX 970 Ti // RAM: 32GB (4x 8GB) Corsair DDR3 (@ 2133MHz) // Storage: 1x 3TB Seagate SATAII 5x 1TB Samsung SATAII, 2x 120GB Corsair SSD

Offline

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

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

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,412

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
Member
From: Twin Cities, MN
Registered: 2012-06-22
Posts: 1,486
Website

Re: Understanding the /usr/sbin merge

WW, all official packages have been updated and rebuilt.

All the best,

-HG


"All errors are ᴘᴇʙᴋᴀᴄ errors—It's just a matter of narrowing down which keyboard and chair." -Trilby
\ldots

Online

Board footer

Powered by FluxBB