Ubuntu 12.04: Initrds, Qt 5, DKMS & More

[phoronix]

Phoronix: Ubuntu 12.04: Initrds, Qt 5, DKMS & More

Here's some more of what was discussed Tuesday at the Ubuntu Developer Summit for Ubuntu 12.04 LTS "Precise Pangolin" in Orlando, Florida...

http://www.phoronix.com/vr.php?view=MTAxMDI

[birdie]

"ProcFS support is likely to be removed" - sounds like a bad joke, are you sure about it, Michael?

/proc is essential for a lot of Linux utitilies like top, ps, ifconfig, uptime, alsa related utils and applications.

[FireBurn]

I've been using an initrd free system for years, the only modules I have are for my PS3's USB DVB dongle (as I hardly ever use it)

My whole kernel is about 2.5MB when compressed with xz

I should really make some boot graphs some time

[thefirstm]

I too run initramfs-less kernels on both my laptop and my server. My laptop has only the "nvidia" module loaded, and my server has no modules whatsoever!

[FireBurn]

I too run initramfs-less kernels on both my laptop and my server. My laptop has only the "nvidia" module loaded, and my server has no modules whatsoever!

It's great when you find a bug and need to bisect as there's a whole lot less to build each time

[curaga]

Supporting initrd-less boot out of the box - good, the initrd part can be 1/4 - 1/5 of the boot on ARM.

Removing proc - did they pass out free mushrooms at the event?

[BlackStar]

Yes, the kernel developers like mushrooms and decided to remove /proc. Not so sure about the mushrooms but I'm sure it's Ubuntu's fault, somehow.

[curaga]

I'm quite aware this is an Ubuntu issue, no idea where you pulled upstream kernel devs in.

[liam]

My disk isn't exactly speedy (laptop, and not a solid state drive but it is 7200rpm), and initrd isn't taking that much time to load. systemd is reporting it as taking about 4.2 sec. What really needs to be fixed is user space, especially getting to a usable desktop fast. Gnome should've fixed this somewhat with their read-optimized settings file dconf, but it hasn't fixed it enough, IMHO. The lighter desktops won't have this problem, of course, but their solutions won't work for KDE/Gnome.
Of course, this is all assuming fast boots are significent enough that they warrant the engineering effort (I am, of course, not talking about embedded market).
Something that might be interesting to purse when btrfs matures enough is to actually rearrange the file layout after every boot (or, after X many boots, or when boots start taking too long, or whatever). As much a possible, the files needed to get to a fully functioning desktop are arranged in a linear manner starting from the earliest possible sector. Obviously the goal would be a continuous read, so it should max out the disk. Now, this wouldn't work in SSD (since they completely mask the physical layout, IIRC), but it would also not matter as much since they already provide very fast boots.
This wouldn't obviate the need to provide some tweaks in userspace.