Linus Torvalds has done a great job maintaining the Linux Kernel and pushing out one version after another. This Sunday, the Linux Kernel saw another version upgrade, and stands at version 3.4 currently. Linus Torvalds calls the 3.4 release a “calm” one, as there were lesser roadblocks in this transition. After the delay in the release of Linux Kernel 3.3, this timely release makes Linus happy as he says,
I just pushed out the 3.4 release.
Nothing really exciting happened since -rc7, although the workaround for a linker bug on x86 is larger than I’d have liked at this stage, and sticks out like a sore thumb in the diffstat. That said, it’s not like even that patch was really all that scary.
In fact, I think the 3.4 release cycle as a whole has been fairly calm. Sure, I always wish for the -rc’s to calm down more quickly than they ever seem to do, but I think on the whole we didn’t have any big disruptive events, which is just how I like it. Let’s hope the 3.5 merge window is a calm one too.
This latest release of the Linux kernel focuses mainly on the Btrfs file system and includes data recovery tools, better error handling and vast performance improvements. On the GPU side of the story, support for many new Intel, NVidia GeForce and ATI Radeon HD graphics cards were added to the latest kernel. Other than these, the latest Linux kernel also improves memory management and virtualization performance.
The next version of Linux Kernel, version 3.5 will focus primarily on the growing hardware world, and thus improve graphics performance. Additionally, it will also include support for the 22nm Haswell architecture, slated for release in early 2013.
The Linux Kernel has reached version 3.3 recently. The latest release of the Linux kernel includes multiple feature improvements and some major changes. The most awaited change in this new kernel is the inclusion of Android kernel code in the Linux kernel. The inclusion of Android kernel marks the first step towards a unified Android and Linux kernel, making it possible for future devices to run a mix of both. While the inclusion of Android kernel code made big news, there were other equally remarkable behind the scene changes in this release.
Like every time, Linux Torvalds announced the availability of the latest kernel release on LKML.org. The release was pushed ahead by a week because of the surprise RC7 release last week. The RC7 was an unplanned release and Linus explained it, saying
I had been hoping that -rc6 would be the last -RC, but no such luck. Things just haven’t calmed down sufficiently for me to feel comfy doing a final 3.3 release without another -rc, so here we are: 3.3-rc7 is out.
With the latest version of Linux kernel, things are finally looking good for the btrfs file system. In addition, GCC has been updated to include the TI C6 architecture and as always, there are new drivers and bug fixes.
The next version 3.4 of the Linux kernel will sport better power management for the Android code in kernel, which is a mess right now. Moreover, it will also improve upon Sandy Bridge performance.
When the Linux kernel came out for the first time in September 1991, it had only 10,000 lines of code. It was elegant and was a revolutionary idea. Slowly, as it grew in popularity, the lines of code increased to 176,250 by March 1994. From there, The Linux kernel has been growing alarmingly. It reached 2.4 million lines of code in 2001, 10 million lines of code in 2008, and it will have over 15 million lines of code by its next stable release. Is this normal? Should we be worried?
This is definitely not normal growth. A large part of the Linux kernel carries code for legacy hardware. Besides that, drivers, file-systems and architecture-specific functionalities use three-fourth of the code. Documentation comments and blank lines fill more spaces. Perhaps it is the monolithic-kernel architecture of Linux, which is the reason for this bloat. It is time to revisit the Tanenbaum-Torvalds debate again.
There are some parts in the Linux Kernel that very few people understand really well.
The only relieving news right now is that the Linux kernel version 3.0 will be a long-term release, with at least 2 years of support. Currently, this status is enjoyed by the kernel version 2.6.32 because of its use across long-term support versions of major distros.
Just in case you didn’t know, Android is built atop the Linux kernel. A few patches here, a few branches there, pepper in some code, and Android was created. Unfortunately a lot of the patches were never sent upstream, this means some of the hard work done by the engineers at Google never made it out of the phones and into desktop or server hardware. The Android Mainlining Project aims to solve this.
Greg Kroah-Hartman, head of the Linux Driver Project, has created a new project with 3 major goals in mind.
To allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel.
To make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code.
To reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers.
This means all the Android-specific code that was purposely left out of kernel releases, will now be easier to implement and merge with the development branch of the 3.3 kernel. Systems like Android’s logging, low memory kills and wakelock power management will be branched-in, allowing for more hardware access to third party boards and systems with memory or power restraints.
In an e-mail to the Embedded Linux Kernel mailing-list, Tim Bird, Architecture Group Chair, CE Workgroup of the Linux Foundation, states that the project was born after discussion and re-evaluation code from Android. With a current stable kernel of 3.19, mainline at 3.2-rc7, there are only a few dot-releases before the project aims to be completed.
Numerous volunteers have signed up for the project, and many have started to contribute patches and code for smooth integration. Without support from Google and AOSP, it’s highly unlikely that both kernels will ever reach parity, but this is quite an excellent start in order to bridge the gap and create a unified kernel that will benefit all users.
Linux.fm is broadcasting the Linux Kernel to the world through online radio. It uses the open source text-to-speech engine eSpeak to translate the latest stable version of the Linux Kernel into voice.
The website loads a random file from the code each time you load it and reads out its source. A note at the end of the website says it is dedicated to the supernerd of the modern age, Dr. Sheldon Cooper who is the prime attraction in the popular BBC CBS sitcom- The Big Bang Theory.
The frontpage of the website says,
There are currently 111011 (base 2) tunes in our database and we are working to add more. A new source file is selected randomly each time you load this page : remember, if you can’t get enough, you can always open Linux Radio in two or more different browser tabs… Use the Source, Luke!
The voice on the software is extremely robotic and annoying and the project is just a time-waster. Have fun.
The Linux kernel has received a significant update to its kernel that has reduced the latency by a factor of around ten. The patch is around 230 LOC and is extremely effective in increasing system responsiveness under heavy load conditions.
The code achieves this by grouping together task under the same TTY (terminal type) to increase interactivity. Mike Galbraith has written the code, which is already in its third version, while Linus Torvalds himself inspired the idea.
Mike Galbraith carried out some tests to see that the latency in average conditions dropped around 60 times and around 10 times in maximum load conditions. Linus writes in an email response saying,
It’s an improvement for things like smooth scrolling around, but what I found more interesting was how it seems to really make web pages load a lot faster. Maybe it shouldn’t have been surprising, but I always associated that with network performance. But there’s clearly enough of a CPU load when loading a new web page that if you have a load average of 50+ at the same time, you _will_ be starved for CPU in the loading process, and probably won’t get all the http requests out quickly enough.
So I think this is firmly one of those “real improvement” patches. Good job. Group scheduling goes from “useful for some specific server loads” to “that’s a killer feature”.