[arch-general] Merge /bin to /usr/bin?
A few days ago it was announced that Fedora 17 will be merging several root directories into their /usr equivalents and using symlinks for compatibility. The announcement can be found here: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/158708 There are several good reasons for the change, outlined at: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge I wondered if this was something Arch was considering as well. Stephen E. Baker
On Mon, Jan 30, 2012 at 7:23 PM, Stephen E. Baker <baker.stephen.e@gmail.com> wrote:
There are several good reasons for the change, outlined at: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge I wondered if this was something Arch was considering as well.
It is being discussed (vaguely related: [0]). While the end goal is very nice (and KISS), the big concern is with the transition, which would be a real PITA. If we can get the transition right I'd personally be in favor, but it would require lots of planning and testing. I'm not at all a fan of the way Fedora is going to do the move btw... [0]: <http://mailman.archlinux.org/pipermail/arch-dev-public/2012-January/022463.html>
On Mon, 30 Jan 2012 19:32:50 +0100 Tom Gundersen <teg@jklm.no> wrote:
On Mon, Jan 30, 2012 at 7:23 PM, Stephen E. Baker <baker.stephen.e@gmail.com> wrote:
There are several good reasons for the change, outlined at: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge I wondered if this was something Arch was considering as well.
It is being discussed (vaguely related: [0]). While the end goal is very nice (and KISS), the big concern is with the transition, which would be a real PITA.
If we can get the transition right I'd personally be in favor, but it would require lots of planning and testing. I'm not at all a fan of the way Fedora is going to do the move btw...
[0]: <http://mailman.archlinux.org/pipermail/arch-dev-public/2012-January/022463.html>
As long as this question popped up... is there a real need these days for /usr/lib64? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 31/01/12 04:49, Leonid Isaev wrote:
As long as this question popped up... is there a real need these days for /usr/lib64?
Binary blobs expect the linker there.
On Tue, 31 Jan 2012 06:01:11 +1000 Allan McRae <allan@archlinux.org> wrote:
On 31/01/12 04:49, Leonid Isaev wrote:
As long as this question popped up... is there a real need these days for /usr/lib64?
Binary blobs expect the linker there.
I see, thanks. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 31/01/12 06:08, Leonid Isaev wrote:
On Tue, 31 Jan 2012 06:01:11 +1000 Allan McRae <allan@archlinux.org> wrote:
On 31/01/12 04:49, Leonid Isaev wrote:
As long as this question popped up... is there a real need these days for /usr/lib64?
Binary blobs expect the linker there.
I see, thanks.
I should point out there is nothing stopping /lib64 being a symlink to /lib (or /usr/lib...) given all it contains is symlinks to files there. Allan
Am Mon, 30 Jan 2012 19:32:50 +0100 schrieb Tom Gundersen <teg@jklm.no>:
I'm not at all a fan of the way Fedora is going to do the move btw...
Maybe the way of going over a committee is the better way after all? ;-) I just say: FHS and the chaos and the imcompatibilities because every distro goes its own way. Maybe it is better to follow a standard and first rewrite this standard. Well, I didn't say anything. Heiko
Am I the only person that has ever had a problem with the /usr directory in the past (through my own stupidity or whatever) and been damn glad that things like chown etc. etc. are in the /bin directory? Just asking. Clive
Am Mon, 30 Jan 2012 19:28:27 +0000 schrieb Clive Cooper <clive@winpe.com>:
Am I the only person that has ever had a problem with the /usr directory in the past (through my own stupidity or whatever) and been damn glad that things like chown etc. etc. are in the /bin directory? Just asking.
Clive
IMHO it is not the worst thing to separate /bin and /usr/bin ;-) https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755...
IMHO it is not the worst thing to separate /bin and /usr/bin ;-) https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755...
It is a little bit like keeping the tools for your car in the trailer. When the trailer comes off then there goes your tools. A symbolic link to your trailer is not quite as useful as the toolbox itself. Clive
On Mon, 30 Jan 2012 20:54:08 +0000 Clive Cooper wrote:
IMHO it is not the worst thing to separate /bin and /usr/bin ;-) https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755...
Ah good a public thread, my message to the dev list got bounced. As a new user to Arch. I was shocked to find binaries like firefox in library directories? Should /bin and /sbin contain all the statically built execs to increase the reliability of single user mode. I often have other problems when trying to partition on Linux, Arch is one of the only distros to suggest partitioning by default, nice one. I'm not a fan of /opt and other new partitions coming along as it causes headaches for partitioning like how much space but I see how it may (unlikely but possible) prevent third party programs damaging the system. I see udev creating directories in /media as a problem for the goal of read only systems, unless it is on it's own partition. Personally I use udev rules to mount to /mnt/usb0, /mnt/usb1 etc. making it consistent and logical to human users and sudoers, not to mention the problem of stupidly long named directories on occasion making escaping required or copying on the commandline. Anyway here's some food for thought you might find interesting about FHS compared to the OpenBSD way of doing things. The thread has some other useful thoughts too. "http://marc.info/?l=openbsd-tech&m=130503366832069&w=2" -- Kc
Hi Kevin, On Tue, Jan 31, 2012 at 2:02 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
Should /bin and /sbin contain all the statically built execs to increase the reliability of single user mode.
Nah, we don't really build static binaries, and /usr must be available even in single user mode. IMHO /bin and /sbin are no longer useful.
I see udev creating directories in /media as a problem for the goal of read only systems, unless it is on it's own partition. Personally I use udev rules to mount to /mnt/usb0, /mnt/usb1 etc. making it consistent and logical to human users and sudoers, not to mention the problem of stupidly long named directories on occasion making escaping required or copying on the commandline.
Two comments: This can be solved by making /media a tmpfs and require its subdirs to be recreated on demand (as systemd does). udev should never, ever mount stuff itself. This is dangerous and explicitly not supported. Consider using systemd, udisks or another daemon for this purpose. For more info about this, see the recent discussion on the linux-hotplug mailinglist.
Anyway here's some food for thought you might find interesting about FHS compared to the OpenBSD way of doing things. The thread has some other useful thoughts too.
Thanks, that's an interesting read. Notice how a majority of his concerns would go away if /bin, /sbin, /usr/sbin all pointed to /usr/bin. That whole thread very clearly illustrates the challenges the FHS faces. -t
On Tue, Jan 31, 2012 at 6:50 AM, Tom Gundersen <teg@jklm.no> wrote:
Two comments:
This can be solved by making /media a tmpfs and require its subdirs to be recreated on demand (as systemd does).
udev should never, ever mount stuff itself. This is dangerous and explicitly not supported. Consider using systemd, udisks or another daemon for this purpose. For more info about this, see the recent discussion on the linux-hotplug mailinglist.
Interesting read indeed! http://www.spinics.net/lists/hotplug/msg05325.html Cheers, Sander
On Tue, 31 Jan 2012 13:50:27 +0100 Tom Gundersen wrote:
udev should never, ever mount stuff itself. This is dangerous and explicitly not supported. Consider using systemd, udisks or another daemon for this purpose. For more info about this, see the recent discussion on the linux-hotplug mailinglist.
Are you referencing the 30 second timeout that Sanders link pointed to? It su's to a normal user and runs a script which uses sudo and only applies to usb ports. I'm fairly sure but not certain that that wouldn't hold up udev? Interestingly I can't imagine a device taking 30 seconds to mount. Atleast if it was a usb I'd pull it out and try again after 15 seconds. -- Kc
On Tue, Jan 31, 2012 at 5:25 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
On Tue, 31 Jan 2012 13:50:27 +0100 Tom Gundersen wrote:
udev should never, ever mount stuff itself. This is dangerous and explicitly not supported. Consider using systemd, udisks or another daemon for this purpose. For more info about this, see the recent discussion on the linux-hotplug mailinglist.
Are you referencing the 30 second timeout that Sanders link pointed to?
It su's to a normal user and runs a script which uses sudo and only applies to usb ports. I'm fairly sure but not certain that that wouldn't hold up udev? Interestingly I can't imagine a device taking 30 seconds to mount. Atleast if it was a usb I'd pull it out and try again after 15 seconds.
The time it takes to mount depends on a lot of factors, but that's not really the problem. A solw mount will not affect udev, the problem is that udev is not meant to manage disks. E.g. who is making sure the disk is unmounted before it is unplugged (yanking it out whilst mounting/fsck'ing does not sound like a good idea btw)? udisks is designed for this purpose, so I suggest using that. It uses udev to get events about plugged in devices (which is what udev is meant for) but does the mounting/monitoring/unmounting itself. I guess the udev page on our wiki should be "pruned" a bit so we don't give people bad advice (on my TODO). -t
On Tue, 31 Jan 2012 17:43:37 +0100 Tom Gundersen wrote:
E.g. who is making sure the disk is unmounted before it is unplugged (yanking it out whilst mounting/fsck'ing does not sound like a good idea btw)?
Yeah, I found this out, of course nothing is psychic and can prepare for that but you do normally get a safely remove option (I haven't mainly because I couldn't be bothered to dig any deeper into udev. It would be easier to create just that part from scratch, I think). I am using flush etc. but haven't fully tested it on all the filesystem types I may use yet. I do prefer it showing me how long it takes to copy rather than saying it's done ages before it has like on my standard udev boxes. It may even be that users are more likely to yank out prematurely (bar completed) with the standard setup atleast the first time with the corrupt or missing file teaching them to get an OK first. -- Kc
On Tue, 31 Jan 2012 17:40:48 +0000 Kevin Chadwick wrote:
E.g. who is making sure the disk is unmounted before it is unplugged (yanking it out whilst mounting/fsck'ing does not sound like a good idea btw)?
Yeah, I found this out, of course nothing is psychic and can prepare for that but you do normally get a safely remove option (I haven't mainly because I couldn't be bothered to dig any deeper into udev.
It seems mounting to /media rather than /mnt that my OpenBSD users are used to (I'll create links) means you get the safely remove option.
It would be easier to create just that part from scratch, I think). I am using flush etc. but haven't fully tested it on all the filesystem types I may use yet. I do prefer it showing me how long it takes to copy rather than saying it's done ages before it has like on my standard udev boxes. It may even be that users are more likely to yank out prematurely (bar completed) with the standard setup atleast the first time with the corrupt or missing file teaching them to get an OK first.
Okay so it worked, however using sync is extremely slow and for ntfs-3g uses a rediculous amount of cpu, now I think I recall a document saying you nee a particular filesystem to run qmail well on Linux (with sync for highly reliable Maildir). I guess I'll just have to make sure my users use safely remove. I believe there is a major issue which is hidden by usb-2.0 as it copies so fast but may affect some slow micro sds, which is a small file looks like it is copied immediately. On OpenBSD it does buffer but also flushes very often so that the user knows when it is actually completed, though the copy rate drops to 0 every so often. I guess it just reduces the window but works brilliantly. It's not just about premature removal it's also annoying when you stop what your doing thinking a hrd drive has finished only to find it's still emptying the cache.
On Tue, 31 Jan 2012 13:50:27 +0100 Tom Gundersen <teg@jklm.no> wrote:
Hi Kevin,
On Tue, Jan 31, 2012 at 2:02 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
Should /bin and /sbin contain all the statically built execs to increase the reliability of single user mode.
Nah, we don't really build static binaries, and /usr must be available even in single user mode. IMHO /bin and /sbin are no longer useful.
I see udev creating directories in /media as a problem for the goal of read only systems, unless it is on it's own partition. Personally I use udev rules to mount to /mnt/usb0, /mnt/usb1 etc. making it consistent and logical to human users and sudoers, not to mention the problem of stupidly long named directories on occasion making escaping required or copying on the commandline.
Two comments:
This can be solved by making /media a tmpfs and require its subdirs to be recreated on demand (as systemd does).
Or a bind-mount from /var/media or such... I wonder though shouldn't it be implemented in initscripts similar to /tmp? Because currently enabling read-only / will require adding a /media stanza to fstab.
udev should never, ever mount stuff itself. This is dangerous and explicitly not supported. Consider using systemd, udisks or another daemon for this purpose. For more info about this, see the recent discussion on the linux-hotplug mailinglist.
Anyway here's some food for thought you might find interesting about FHS compared to the OpenBSD way of doing things. The thread has some other useful thoughts too.
Thanks, that's an interesting read. Notice how a majority of his concerns would go away if /bin, /sbin, /usr/sbin all pointed to /usr/bin. That whole thread very clearly illustrates the challenges the FHS faces.
-t
-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Tue, Jan 31, 2012 at 7:17 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
Or a bind-mount from /var/media or such... I wonder though shouldn't it be implemented in initscripts similar to /tmp? Because currently enabling read-only / will require adding a /media stanza to fstab.
It would be a reasonable thing to do, sure (mounting a tmpfs). If you post a patch to arch-projects we can discuss it :-) It should be noted that initscripts does not mount anything to /tmp by default, so an fstab entry is needed for this too if you want ro root. -t
On Tue, 31 Jan 2012 19:36:58 +0100 Tom Gundersen <teg@jklm.no> wrote:
On Tue, Jan 31, 2012 at 7:17 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
Or a bind-mount from /var/media or such... I wonder though shouldn't it be implemented in initscripts similar to /tmp? Because currently enabling read-only / will require adding a /media stanza to fstab.
It would be a reasonable thing to do, sure (mounting a tmpfs). If you post a patch to arch-projects we can discuss it :-)
It should be noted that initscripts does not mount anything to /tmp by default, so an fstab entry is needed for this too if you want ro root.
-t
Grr... sorry, I meant "filesystem" not "initscripts" (probably because I was playing with the latter ATM). I don't think it's the initscripts' (or systemd's for that matter) job to deal with these kinds of mounts. So I've put a request to bugtracker (FS#28205). -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Mon, Jan 30, 2012 at 7:23 PM, Stephen E. Baker <baker.stephen.e@gmail.com> wrote:
A few days ago it was announced that Fedora 17 will be merging several root directories into their /usr equivalents and using symlinks for compatibility. The announcement can be found here: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/158708
There are several good reasons for the change, outlined at: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge I wondered if this was something Arch was considering as well.
Stephen E. Baker
Thread on the forums with link to the ML discussion: https://bbs.archlinux.org/viewtopic.php?pid=1049889#p1049889
participants (10)
-
Allan McRae
-
Benjamin Hase
-
Clive Cooper
-
Heiko Baums
-
Karol Blazewicz
-
Kevin Chadwick
-
Leonid Isaev
-
Sander Jansen
-
Stephen E. Baker
-
Tom Gundersen