The case for the /usr merge
The case for the /usr merge
Posted Jan 27, 2012 21:32 UTC (Fri) by nix (subscriber, #2304)In reply to: The case for the /usr merge by gb
Parent article: The case for the /usr merge
initramfs: without it, a *lot* is impossible. No heavily modular kernels. No rootfs on LVM. No rootfs on md/RAID. No rootfs on any other filesystem requiring userspace involvement to mount. No rootfs over the network (sounds silly for most machines until you have a disk failure and can revive the system, temporarily mounting everything over the network, with a one-line change). The list goes on and on. And the cost of the initramfs? These days, nearly nil.
dbus: we didn't have a decent RPC mechanism on Linux before now. SunRPC is dead and a security nightmare to boot. The service invocation stuff is nice too, no longer do we need scads of always-running daemons for rarely-needed jobs. The XML configuration file swarm is a horror, I wish they'd picked something, *anything* else. But we can't have everything.
network-manager: useless-verging-on-destructive on machines with wired networks doing lots of persistent network connections to other machines (e.g. remote filesystems). Bloody useful in dynamic situations, e.g. laptops with wifi. Which is these days a pretty common case.
KMS: video drivers in userspace were a nightmare to keep working, and there are lots of things they simply cannot do: a lot of the jobs necessary to keep modern video cards happy requires privileged support, some of it requires interrupt handlers (which is a kernel-only thing), much of it requires a full-blown memory manager to manage memory on the card, which will only work if the video driver is shared between X instances, which means the kernel again or some sort of cross-user, cross-X-instance daemon. Drivers for hardware in userspace sometimes work OK, but normally only if driving the hardware is simple (e.g. USB, and even there the job of driving the actual USB hardware is down to the kernel). Video cards are by some distance the most complex hardware on the system: driving them from userspace was always backwards, and was dragging X down.
gconf: well, OK, I'm a KDE man and prefer the ini-files-and-ksycoca thing. gconf *is* horrible and has no right to exist: there are better ways to provide performance as good as binary deserialization without needing all your configuration to spend all its time living in a binary lump.
pulseaudio: as long as we have to have a software mixer -- and we do, modern sound cards don't do hardware mixing -- we may as well make it a nice capable one. When you do that it turns out that nothing it has to do requires kernel-side operation, and for the non-pro-audio use-case of pulseaudio millisecond latencies are not required, so you might as well implement it in userspace. I note that you cannot simultaneously damn pulseaudio for being in userspace and KMS for being in kernelspace while remaining consistent.
The reason why a lot of these are RH ideas is because RH does so much of the work to keep Linux infrastructure going.
