On Mon, 30 Jan 2012 19:32:50 +0100 Tom Gundersen wrote:

On Mon, Jan 30, 2012 at 7:23 PM, Stephen E. Baker 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.h...

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 Tue, 31 Jan 2012 06:01:11 +1000 Allan McRae 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

Am Mon, 30 Jan 2012 19:32:50 +0100 schrieb Tom Gundersen :

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 Mon, 30 Jan 2012 19:28:27 +0000 schrieb Clive Cooper :

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

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

On Tue, Jan 31, 2012 at 6:50 AM, Tom Gundersen 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, Jan 31, 2012 at 5:25 PM, Kevin Chadwick 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: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, Jan 31, 2012 at 7:17 PM, Leonid Isaev 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