PDA

View Full Version : Fedora considers moving all binaries to /usr/bin.



xang
November 2nd, 2011, 02:58 PM
Interesting concept with /usr being conceptually shared between multiple systems/VMs. Also proposed is the elimination of the distinction between /usr/bin /usr/sbin and /bin /sbin.

Original article:

http://www.h-online.com/open/news/item/Fedora-considers-moving-all-binaries-to-usr-bin-1369642.html

1clue
November 2nd, 2011, 03:12 PM
My first response was "Hell no!" but now that I think about it, permissions and/or access control lists could handle every security concern if they take the time to get it right.

The only real concern I have at this point is that my usual installation has a relatively microscopic / partition and I mount everything else as a separate filesystem. I would have to think that through for awhile.

crdlb
November 2nd, 2011, 05:12 PM
The only real concern I have at this point is that my usual installation has a relatively microscopic / partition and I mount everything else as a separate filesystem. I would have to think that through for awhile.

So you let the initramfs mount /usr.

juancarlospaco
November 2nd, 2011, 07:07 PM
I think Debian its planning a /run on future...

kvvv
November 2nd, 2011, 08:13 PM
I like it. Having /usr/bin and /bin can indeed be confusing, and seems redundant especially for newbs like me.

Another thing I wonder about is the difference between /usr/local and /opt. From what I have seen they are both used to store system wide programs that are not inherently part of the distros package manager.

C!oud
November 2nd, 2011, 08:26 PM
I think Debian its planning a /run on future...

Several distro already have since systemd is using it and udev switched to using it by default too


I like it. Having /usr/bin and /bin can indeed be confusing, and seems redundant especially for newbs like me.
/bin is traditionally used for critical binaries needed for booting such as 'init' thus allowing /usr to be on a seperate partition that's mounted after root.


Another thing I wonder about is the difference between /usr/local and /opt. From what I have seen they are both used to store system wide programs that are not inherently part of the distros package manager.

/opt is generally for additional packages outside your package manager i.e. proprietary binary applications. /usr/local is for local data and is usually for programs you've compiled yourself through a simple 'make install'

Lars Noodén
November 2nd, 2011, 08:58 PM
I like it. Having /usr/bin and /bin can indeed be confusing, and seems redundant especially for newbs like me.

You can find the official descriptions in hier (http://manpages.ubuntu.com/manpages/oneiric/en/man7/hier.7.html). When working with servers or embedded devices it is often useful that /bin and /usr/bin are separate.

It's an interesting goal to be able to mount the partition read-only but it needs more thinking through. How are they going to get these changes into the Linux standard base (http://www.linuxfoundation.org/collaborate/workgroups/lsb) first? Or will they go against the standard?

crdlb
November 3rd, 2011, 12:24 AM
You can find the official descriptions in hier (http://manpages.ubuntu.com/manpages/oneiric/en/man7/hier.7.html). When working with servers or embedded devices it is often useful that /bin and /usr/bin are separate.
Why is it useful? Can an initramfs not be used for the same purpose?

It's an interesting goal to be able to mount the partition read-only but it needs more thinking through. How are they going to get these changes into the Linux standard base (http://www.linuxfoundation.org/collaborate/workgroups/lsb) first? Or will they go against the standard?

The FHS explicitly allows the toplevel directories to be symlinks, so I don't think there is a problem here.

1clue
November 3rd, 2011, 09:00 PM
Why is it useful? Can an initramfs not be used for the same purpose?


The FHS explicitly allows the toplevel directories to be symlinks, so I don't think there is a problem here.

FWIW I don't think it's useful anymore.

It used to be that /sbin, /usr/sbin, /bin and /usr/bin all had distinct purposes. It made sense back then (I was there) but not so much now. Over the years, distros I've had exposure to seem to bend their ideas of where things should go and the definitions have blurred somewhat. As "me" I generally want everything to be on the PATH, even if I can't execute it as my regular user.

It used to be that booting off floppies (before CDROM was commonplace) was a huge PITA, and if something went wrong you wanted to rescue the system rather than just pull your junk off and reformat. Now, you can boot off a rescue CD, pull your data off and start over. So isolating directories by putting each on a separate partition no longer makes much sense.

I've rescued a couple systems in the last few years, but in every case I thought about it for awhile and then scraped it off and started over with a fresh install. I just don't trust a system that has broken or been broken into. It's no longer difficult to install a new system, it's no longer cost prohibitive or time prohibitive, and it's just plain better all around.

The only thing that bugs me is that /usr changes fairly frequently with software updates and such, and I would rather have my / be inviolate and relatively static. But thinking on it, most of my arguments are "old school" and I would definitely be open to a change.

Lars Noodén
November 4th, 2011, 10:04 AM
The idea behind /bin and /sbin is to have the binaries needed to bring up the system in the same partition as the system (/)

Putting everything into /usr sounds tidy but it means then that essential programs and utilities are no longer available during the initial phases of start up or if mounting goes awry.

It's already possible to mount / read only if there /home and /var and /tmp are separate or at least symlinked to a separate partition.

szymon_g
November 4th, 2011, 12:17 PM
@Lars Nooden
initframs is used for "rescue mode".