Linux 2.6.34 has been released. This version includes support for the Tilera architecture, a new filesystem notification interface called fanotify, a redesign of workqueues optimized for concurrency, CIFS local caching, support for Intel Intelligent Power Sharing in i3/5 systems, integration of the kernel debugger and KMS, inclusion of the AppArmor security system and several new drivers and small improvements. You can read the full changelog as well.
theres a typo…
“Linux 2.6.34 has been released. This version …”
of course it’s Linux 2.6.36
I just don’t know if I should download Linux or Ubuntu
it would be good to see somewhere in release notes something that looks like: boot time reduced by 30% or 50%.
Or is the responsibility of speed improvements not on the kernel?
Depends. The actual boot speed of the os isn’t primarily the kernel’s doing, but rather how services are initialized and in what order, and are they started one at a time or in parallel? That being said, the Linux kernel does take considerably longer to initialize than most, especially if using a generic kernel such as those provided with the major distros. This has to do with how Linux’s driver structure works and how hardware is probed mostly, at primary fault here is the fact that many drivers are in the kernel which probably should be loaded on demand. All that being said you can, if you wish of course, cut down on kernel boot times by making your own kernel, though it would be better for the distros to get a bit smarter about what actually needs to go in a kernel and what could go on the initrd and only be loaded if needed at boot or even later.
many drivers are in the kernel which probably should be loaded on demand.
Most distros compile most of the drivers as modules. But including a driver within the kernel doesn’t really makes booting slow. And these days many subsystem do asynchronous probing anyway…
What are you talking about? Most distro kernels are as modconfig as possible. Do you want them to take care to defer loading of things not essential for boot, or something? It would be a hard thing to figure out reliably.
If you want to test raw boot speed try changing init to /bin/sh and see what you get.
This isn’t 100% reliable of course but it will give you a pretty good idea of what kind of raw boot speed you have.
Just to add on, it’s more complicated than that if you wanted to make that a permanent setup, because init sends out TTY hooks so that the kernel knows to start virtual terminals. So, yes, changing to /bin/sh would get you raw boot speed, but you wouldn’t be able to get to shell. You’d be surprised how hard it is to turn Linux into a genuinely single user system (not just selecting single user mode at boot and running as root).
But I understood your comment, which was just talking about the benchmark usage. Point taken.
It’s even worse than that since udev came along. This will only give you an idea of how fast Linux initializes hardware and will not give you a system you can really use. Combined with a benchmark of your real boot it will give you an idea which parts are due to Linux and which are your init system and services (just subtract).
Another useful technique: install a minimal system, such as debian-netinst, and uninstall all daemons that are not actually essential. This still involves some benchmarking of init and so forth but will give you a usable system (albeit with nothing much running).
Those of you who are interested in seeing faster booting times might get a pleasant surprise in the next release cycle of your favorite distro. The big project currently underway to deliver more speed is called “systemD” and Fedora, at least, hopes to deliver it by April 2011:
http://fedoraproject.org/wiki/Features/systemd
I’m not a Fedora user myself (currently using Lubuntu), but I think all the big distros will implement systemD as soon as possible.