Quotes of the week

[Posted March 9, 2011 by corbet]

If we broke every piece of code that was broken we'd have very little working code.

I love you all dearly, but I also love GNOME. I feel that it's juvenile to beat down on other free software projects' hard work. It really breaks my heart to see this going on. Don't you think that there are more constructive and less personal ways to voice your feedback, concerns, and critiques?

If you would like to participate in ~~juvenile~~ critically-important activities for the fun of it, might I suggest a more worthy cause: promoting the glorious and miraculous hot dog that will surely be the 'weiner' of the Fedora 16 naming contest?

-- Máirín Duffy

All I can say, Jesse, is that I am very, very glad that I don't have to go running off to CPAN just to get Unicode work done in Perl, as apparently I must in order to get OO work done in Perl. At least this shows we do recognize where our core competency and true focus are, and it's not in OO.

-- Tom Christiansen

You can of course say: I don't need 3G, no Audio, D-Bus is evil anyway, and I don't want to print, and plug'n'play isn't for me anyway, and I just want my 80's style Unix back. Then, sure, a separate /usr will work fine for you. But if that's really you then you probably are not running a shiny new systemd installation, but rather Slackware 1.0. So why are you reading this anyway?

-- Lennart Poettering

Quotes of the week

Posted Mar 10, 2011 13:35 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

You can of course say: I don't need 3G, no Audio, D-Bus is evil anyway, and I don't want to print, and plug'n'play isn't for me anyway, and I just want my 80's style Unix back. Then, sure, a separate /usr will work fine for you.

Actually, all that is currently broken by separate /usr is placing the vendor name of soundcards in PulseAudio properties, localization in very early boot, and some obscure stuff on some Dell laptop. Watch me not care. (Admittedly I suspect I'd care more if I didn't speak English).

(However, this is a situation which will likely grow worse with time, not better: Lennart is right there. I suspect I should rejig my initramfs to mount /usr as well as /. Separate /usr isn't necessarily broken: /usr *that is not mounted when init starts* may be broken, and that has nothing necessarily to do with fs layout, so the benefits of split-off /usr can continue.)

Quotes of the week

Posted Mar 11, 2011 3:49 UTC (Fri) by nicooo (guest, #69134) [Link] (3 responses)

Or you could install udev in / instead of /usr. At least on my system it looks like only libudev and the documentation are installed in /usr.

Quotes of the week

Posted Mar 11, 2011 12:47 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

Really? If you install upstream udev it puts libudev in /lib (sensibly).

The problem is some of the udev extras: a couple rely on glib (which is in /usr, or used to be); some rely on the PCI and USB databases, which have standard locations under /usr/share; and the whole lot relies on localization if you want error messages in early boot to be readable to a non-English-speaker.

Quotes of the week

Posted Mar 11, 2011 15:08 UTC (Fri) by nicooo (guest, #69134) [Link] (1 responses)

I see. I don't have the extras installed and it looks like libudev is only a symlink:
lrwxrwxrwx 1 root root 26 Sep 24 14:13 /usr/lib/libudev.so -> ../../lib/libudev.so.0.6.1*

Quotes of the week

Posted Mar 14, 2011 13:51 UTC (Mon) by nix (subscriber, #2304) [Link]

libudev.so is always going to be only a symlink: that's the way versioned shared libraries have always worked in ELF-land. It's the location of libudev.so.0.6.1 that matters, and you can see from that symlink that on your system it is in /lib. I'd be willing to bet any amount you like that libudev.so.0 (which is what the dynamic linker open()s) is also in /lib.

Quotes of the week

Posted Mar 11, 2011 20:43 UTC (Fri) by daglwn (guest, #65432) [Link] (9 responses)

The traditional reasons for splitting off /usr do not apply these days anymore.

FALSE. What can't Lennart and others get a clue about this? I would like to keep /usr separate so the bootability of my system is not compromised when random bits in /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/SOME_OBSURE_PERL_MODULE start wearing out.

The fact that disks are so big today is a stronger motivator for a separate /usr, not a reason to get rid of it.

Quotes of the week

Posted Mar 12, 2011 5:19 UTC (Sat) by foom (subscriber, #14868) [Link]

I don't think you can actually localize "worn-out-bits" on drives the way you seem to think you can...

Quotes of the week

Posted Mar 14, 2011 13:55 UTC (Mon) by nix (subscriber, #2304) [Link] (6 responses)

Quite. One site I help administer just had a pile of FS corruption due to a power flicker at the wrong time. /usr was largely toasted, but it was all recoverable because / was intact, so there was enough machinery working to get /usr back.

FS-wide corruption is rare, but still does happen: splitting a small critical core in / from a massive pile of not-so-critical parts helps recover from that. We can call the non-critical parts '/usr'.

Quotes of the week

Posted Mar 14, 2011 18:08 UTC (Mon) by BenHutchings (subscriber, #37955) [Link] (5 responses)

The initramfs is now the minimal recovery partition.

Quotes of the week

Posted Mar 15, 2011 12:34 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

You need an awfully large initramfs for that. I don't know about you but I'd rather not have a 60Mb kernel image :)

Quotes of the week

Posted Mar 15, 2011 13:17 UTC (Tue) by foom (subscriber, #14868) [Link] (1 responses)

The default debian initrd has all *sorts* of useful tools in it. There's certainly enough there to do basic troubleshooting and recovery (including vi!). It's 28MB as an unpacked directory tree, and 8.8MB in initrd form. That doesn't seem like a real issue...

/bin:
busybox cat chroot cpio dd dmesg false fstype gunzip gzip halt insmod ipconfig kill ln losetup ls minips mkdir mkfifo mknod mount nfsmount nuke pivot_root poweroff readlink reboot resume run-init sh sh.shared sleep sync true umount uname

/sbin:
blkid dmsetup modprobe rmmod udevadm udevd

Commands included in /bin/busybox:
[, [[, adjtimex, arping, ash, awk, basename, blockdev, brctl, bunzip2, bzcat, bzip2, cal, cat, chgrp, chmod, chown, chroot, chvt, clear, cmp, cp, cpio, cut, date, dc, dd, deallocvt, df, dirname, dmesg, dnsdomainname, dos2unix, du, dumpkmap, dumpleases, echo, egrep, env, expr, false, fgrep, find, fold, free, ftpget, ftpput, getopt, grep, gunzip, gzip, head, hexdump, hostid, hostname, httpd, id, ifconfig, ionice, ip, ipcalc, kill, killall, klogd, last, length, ln, loadfont, loadkmap, logger, logname, logread, losetup, ls, lzcat, lzma, md5sum, mkdir, mkfifo, mknod, mktemp, more, mount, mt, mv, nameif, nc, netstat, nslookup, od, openvt, patch, pidof, ping, ping6, printf, ps, pwd, rdate, readlink, realpath, renice, reset, rev, rm, rmdir, route, rpm, rpm2cpio, run-parts, sed, setkeycodes, sh, sha1sum, sha256sum, sha512sum, sleep, sort, start-stop-daemon, strings, stty, swapoff, swapon, sync, sysctl, syslogd, tac, tail, tar, tee, telnet, test, tftp, time, top, touch, tr, traceroute, traceroute6, true, tty, udhcpc, udhcpd, umount, uname, uncompress, uniq, unix2dos, unlzma, unxz, unzip, uptime, usleep, uudecode, uuencode, vi, watch, watchdog, wc, wget, which, who, whoami, xargs, xz, xzcat, yes, zcat

Quotes of the week

Posted Mar 20, 2011 0:24 UTC (Sun) by daglwn (guest, #65432) [Link]

And none of it has documentation and --help is useless in busybox. An emergency is exactly when I need that stuff.

Quotes of the week

Posted Mar 15, 2011 15:07 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Another point: unless the initramfs has /etc on it, it's not a good solution, because one advantage of a separate /usr (and /var) is that its relatively higher frequency of corruption is relatively harmless because all the systemwide configuration state in /etc is unaffected.

initramfses don't help there. (Sure, backups help, but restoring from backup is annoying.)

This is all fairly pettifogging, true, but anything that leads to /etc being lost less often is a good thing as far as I'm concerned. I suppose it would be possible to put /etc on a filesystem of its own, in a loopback filesystem stored in the root directory, and mount it at the very start of the boot scripts: that would let you have a single unified / and /usr while minimizing the probability that a severely-damaged rootfs would lose you access to /etc. (It wouldn't lower it as far as putting /etc on a different filesystem, but it's hard to get access to a different filesystem without /etc. You could have a skeleton /etc which is just enough to give you access to the real /etc, and is mount --moved out of the way and then overmounted by the real /etc early in the boot process: that combined with an initramfs nicely populated with recovery tools would fix all my concerns, I think, but at the cost of a very unusual mount tree.)

(and I am definitely overthinking this.)

Quotes of the week

Posted Mar 15, 2011 16:12 UTC (Tue) by nix (subscriber, #2304) [Link]

For the record, the total number of times having a separate / has saved me from /etc corruption is three, in thirteen years. That includes quite a bit of risky stuff like sudden power-cut tests and hibernation and so on, so a unified / and /usr are not the most terrible things in the world. However, for existing systems it is *very* annoying to transition to such a layout, to such a degree that it is almost certain I won't, and will merely curse anyone who decides to rely on too much in /usr in early boot and live with any breakage.

works for me

Posted Mar 17, 2011 20:35 UTC (Thu) by gvy (guest, #11981) [Link]

I second that, and while my servers have long moved to "just /" (with a gigabyte-size bare HN root and no separate /usr for containers either) following notebooks (where first space was more scarce and then there was no real reason given the battery), my workstation runs with /var and /usr on separate spindles while / and /home are mirrored partitions on these drives. And I see no good reason to change this.

"It's broken elsewhere already" is no excuse for further breakage, hope this mindset doesn't get viral.