Re: [arch-general] Merge /bin to /usr/bin?
On Tue, 31 Jan 2012 17:40:48 + 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.
[arch-general] GHC 7.4.1 or HP 2011.4.0.0??
It's been out for a day now... this would be a good time to decide whether ArchLinux should be bold and move to a haskell-platform-free state, or trudge on with HP and the ache it causes. If we're moving to 7.4.1 there's a lot of work with getting ArchHaskell in shape for it, so the longer notice the better :) If we're to trudge on with HP then we really ought to move to 2011.4.0.0, which also means a new version of GHC and a lot of work on ArchHaskell, so the longer notice the better :) Please, please, please, can we move on this soon? I'm available to help out with [extra][community] packages if need be, updating PKGBUILDs, building, verifying other's changes, etc. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus
Re: [arch-general] GHC 7.4.1 or HP 2011.4.0.0??
My personal opinion as a user is that it would be nice to abandon the Haskell Platform in favor of keeping more Haskell packages up-to-date with the upstream. That seems more in line with the general Arch philosophy of staying as current as possible. Also, GHC 7.4 has some cool features that I would love to be able to use... My understanding of the implications of this kind of decision is fairly limited, though, so I take my own opinion with a rather large grain of salt. :) Also, if there's anything a normal user can do to contribute to the upgrade effort, I'd be glad to offer my help. pgpJSQTVfZyh8.pgp Description: PGP signature
Re: [arch-general] change in mount behaviour?
On 28-01-12 17:29, Heiko Baums wrote: Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersent...@jklm.no: Apologies for the late reply, but the length of the thread kept me off for a while. [...] The different usecases of /media and /mnt are explained in the FHS link you provided. I don't see any difference there. Optical media contain a filesystem and harddisks contain filesystems. Both are usually mounted temporarily. So what's the difference? There is actually a *HUGE* difference, but there is also some history involved in this. I don't have links handy, but i'm sure google can help you out here. Also, this is just my understanding of it, so YMMV. First: harddisk were considered fixed. If they were there when the system started up, one could mostly assume they would stay there. Besides those always there blockdevices, there were also CD-ROMs with their removable media. Since the *device* would probably stay where it was, it was easy to create an entry in /etc/fstab for those so users could use them and rely on where they would show up. Some distro's chose to use /mnt as a mountpoint for CD-Roms, some others created subdirectories below /mnt. Despite these small differences, the general behavior was well understood and workable. Then came USB (and other removable) storage and the trouble began. Now there were *devices* that would appear and disappear while the system was still running. I think that there were a couple of solutions to handle this situation, but no real standard. I'm not sure how the standardization went, but it ended up with the current /media hierarchy. No more fixed entries in /etc/fstab to allow users to mount and use those devices, but dynamically created mountpoints and possibly also auto-mounting. This way the system doesn't need any info on possible storage media beforehand, but everything is created on the fly, when needed. Quite a nice and elegant solution, if you ask me. With this in mind, the FHS decisions seem fairly logical: - /mnt is used in different ways, so it's best to steer away from it - /media is where we mount removable storage. It has not (much) tradition behind it, so it's easy to create a new standard with it. Hope that helps. mvg, Guus
