Linux 3.12 Released, Linus Proposes Bug Fix-Only 4.0

An anonymous reader writes "Linus Torvalds announced the Linux 3.12 kernel release with a large number of improvements through many subsystems including new EXT4 file-system features, AMD Berlin APU support, a major CPUfreq governor improvement yielding impressive performance boosts for certain hardware/workloads, new drivers, and continued bug-fixing. Linus also took the opportunity to share possible plans for Linux 4.0. He's thinking of tagging Linux 4.0 following the Linux 3.19 release in about one year and is also considering the idea of Linux 4.0 being a release cycle with nothing but bug-fixes. Does Linux really need an entire two-month release cycle with nothing but bug-fixing? It's still to be decided by the kernel developers."

Comments

Bugfix Pause always welcome

[icebike]

There have been so many fast and furious features added over the last couple releases, not only to the kernel but also the various and sundry major components (like systemd) that taking a breather isn't going to hurt anything. There is nothing huge waiting in the wings that everyone needs next week.

Take the time to fix everything you can find.

Yes, it is needed.

[Frobnicator]

The kernel's bug database shows almost 2500 open bugs right now.

All projects slowly accumulate those hard-to-fix bugs, or the "maybe later" bugs, or the "not interesting right now", bugs. Periodically every project needs to have that cruft cleaned up.

Spending two months fixing those bugs might be a minor annoyance to some of the kernel maintainers but would be a godsend to people who have been waiting a very long time for low priority and low interest kernel bug fixes.

Re:yes please

[Anonymous Coward]

We could even have two branches, one with an even minor number for bugfixes and one with an odd minor number for new features.

There is balls-to-the-wall competition right now!

[Anonymous Coward]

I don't know how you can honestly say that there's "nothing huge waiting in the wings that everyone needs next week." You must not understand the current operating system market.

THERE IS BALLS TO THE WALL COMPETITION RIGHT NOW!

The moment the Linux community rests on its laurels, even if just to fix some "bugs" that don't even exist, the competition from Windows and OS X will intensify to an extent that we haven't seen in ages.

Look, Windows 8.1 was just released, and it's a game-changer. It makes the Windows 8 stream a viable option for businesses and home users alike. Windows 8.0 was like Vista was; Windows 8.1 is like Windows 7. Windows 8.0 tried some things out, and some of those were mistakes. Windows 8.1 remedies these, and the result is a powerful, usable operating system.

OS X 10.9 Mavericks was just released recently, too. It took what was perhaps the most popular and widely used Unix-like system and made it even more efficient and powerful.

Then there's Linux. There are major changes underway as we speak. The Ubuntu and GNOME 3 communities, which were once among the largest and most appreciated, shat upon the faces of their users, causing them to seek refuge in other distributions and desktop environments. Now we have Wayland on the way, and it's going to bring so much disruption that there may in fact be a civil war of sorts within the Linux community. X is not going to die easily! And then there's LLVM and Clang, which are kicking the living shit out of GCC. In fact, this is a revolution that we haven't seen the likes of in years.

With so much turmoil in the userland software, it's now up to the kernel to pick up the slack. We're going to need to see the kernel team at least double their efforts to make up for the stupidity of the GNOME crew, for example. We're going to need to see a kernel that offers greater power efficiency on modern systems. We need to see a kernel that'll offer even better process and thread scheduling. We'll need to see a kernel that can scale from the smallest cell phones to the largest clusters. We need to see the completion of Btrfs.

Never forget that when it comes to operating systems, the BALLS ARE TO THE WALL!. This is more true today than ever before. The competition is fierce, and prisoners will not be taken. When there is BALLS TO THE WALL competition, everybody involved needs to bring their best. This includes the Linux kernel developers. They need to be the best they've ever been. This is no ordinary situation; this is a BALLS TO THE WALL situation. And don't you ever forget that!

There are quite a few things I'd like to see fixed

[nctritech]

One of the most frustrating things for me is that the frenzy over the past six or seven years has led to some serious annoyances with the kernel's behavior: 1. Linux kernels for i386/x86 can't boot in less than roughly 28MB of RAM. I have tried to make it happen, but the features added along the way don't allow it. Perhaps it's the change to ELF? I'm not sure. 2. Linux x86 can't have the perf subsystem removed. It's sort of pointless for a Turion 64 X2 or a Core i3, but for systems with weaker processors (netbooks, embedded, etc.) every single evicted cache line counts. 3. Some parts of the kernel seem to be dependent on other parts almost arbitrarily. I once embarked on a quest to see what it took to discard the entire cryptographic subsystem. Long story short: good luck. I was surprised at how many different hashing and crypto algorithms were required to make use of common hardware and filesystems and network protocols. Are all of these interdependencies really necessary? 4. The help text for lots of kernel configuration options are in SEVERE need of updating and clarification. Most of the network drivers still say roughly the exact same thing, and some of the help text sounds pretty silly at this point. 5. Speaking of help text, why doesn't the kernel show me what options are forcing the mandatory selection of a particular option? For some, it's simple, but try hitting the question mark on CRC32c and you get a disastrous and impossible to read list of things that force the selection of that option. The help screen should show an option dependency tree that explains how the option in question was forced. 6. ARM is still a disaster. I have a Motorola Triumph I don't use anymore, but I wanted to build a custom system for. It uses a Snapdragon SoC and the only kernel I can use with it is a 2.6 series kernel from Motorola (or derivatives based on that code base) with lots of nasty deviations from the mainline kernel tree that will never make it into said mainline tree. I have a WonderMedia WM8650-based netbook that originally came with an Android 2.3 port and I can't build anything but the WonderMedia GPL compliance kernel release if I want to use most of the hardware in the netbook, even though general WM8650 support exists in mainline. Something needs to change to make it easier for vendors to bring their drivers and SoC specifics to mainline so that ARM devices aren't permanently stuck with the kernel version that they originally shipped with. I'm still using a VIA C7-M netbook which suffers heavily due to the tiny on-chip caches. I also have a Fujitsu P2110 with a Transmeta TM5800 CPU that makes my VIA look like an i7. I also own Phenom II servers, AMD A8 laptops, MIPS routers, a Raspberry Pi, and many Android devices I've collected over the years. What I've seen is that the mad rush to develop for every new thing and every new idea results in old hardware being tossed by the wayside and ignored, especially when that hardware isn't based on an x86 processor. Even then, I'm sure that this frenetic, rapid development process has resulted in a lot of unnecessary bloat and a pile of little unnoticed security holes. It may be time to step back and stop adding new features. I would like to see the existing mainline kernel become much more heavily optimized and cleaned up, and then see the inclusion of support for at least some of the embedded platforms that never managed to make it back into mainline. I know that this is an unrealistically broad set of "wants," but I also know that these are the big nasty unspoken problems in the Linux world that there are no easy answers for.

Compcache/ZRAM

[nctritech]

Linux has had compressed memory for quite some time, originally as Compcache and now as ZRAM. I have managed to use it on low-memory systems even today to get more work done faster. I'm not saying this to attack OS X, but rather to point out that equivalents already do exist. Also, I remember when a company (Quarterdeck?) offered a product for DOS/Windows called "RAM Doubler" that did the same kind of thing.

Re:Take some lessons from Intel

[Anonymous Coward]

Seeing as how Linus is new to this whole Linux kernel thing, I'm sure he appreciates the input of someone so knowleadgeable in kernel development.

Re:There are quite a few things I'd like to see fi

[Microlith]

I once embarked on a quest to see what it took to discard the entire cryptographic subsystem. Long story short: good luck. I was surprised at how many different hashing and crypto algorithms were required to make use of common hardware and filesystems and network protocols. Are all of these interdependencies really necessary?

Rather than just asking if they are necessary, the better question to ask is what are they using the cryptographic subsystem for? For example, BTRFS does checksumming and offers compression. EXT4 uses CRC32 as well. And that use isn't arbitrary, they use it to protect data integrity and, in the case of BTRFS, maximize use of disk space. The TCP/IP stack offers encryption. These requirements aren't arbitrary, they pull it in to accomplish a specific goal and avoid duplicating code.

ARM is still a disaster.

And it will continue to be so long as every ARM device is its own unique thing. There might be forward progress with AArch64.

I have a Motorola Triumph I don't use anymore, but I wanted to build a custom system for. It uses a Snapdragon SoC and the only kernel I can use with it is a 2.6 series kernel from Motorola (or derivatives based on that code base) with lots of nasty deviations from the mainline kernel tree that will never make it into said mainline tree.

Probably lots of board specific details (the board support package) that have no relevance in the kernel. x86(-64) and other architectures have the advantage that once processor support is added, support for every motherboard that CPU gets plugged into is virtually guaranteed. x86 would have the same problem as ARM if not for the use of things like ACPI, PCI, and the various hardware reporting formats supplied by legacy bios/UEFI.

I have a WonderMedia WM8650-based netbook that originally came with an Android 2.3 port and I can't build anything but the WonderMedia GPL compliance kernel release if I want to use most of the hardware in the netbook, even though general WM8650 support exists in mainline.

You'll have to blame WonderMedia. Barnes and Noble, Amazon, etc. all do the same thing: baseline GPL compliance release. Chip vendors will do the same thing, releasing only what is necessary and not bothering to integrate upstream. This is no small part of why vendors abandon Android devices so rapidly.

Something needs to change to make it easier for vendors to bring their drivers and SoC specifics to mainline so that ARM devices aren't permanently stuck with the kernel version that they originally shipped with.

Something does need to change, however that something is not in the kernel.

I also have a Fujitsu P2110 with a Transmeta TM5800 CPU that makes my VIA look like an i7. I also own Phenom II servers, AMD A8 laptops, MIPS routers, a Raspberry Pi, and many Android devices I've collected over the years. What I've seen is that the mad rush to develop for every new thing and every new idea results in old hardware being tossed by the wayside and ignored, especially when that hardware isn't based on an x86 processor.

And virtually all of that is still supported, with the ARM caveat noted above. Even the Transmeta CPU is still supported. What ends up happening is that the world moves on, and older hardware passes into history and receives less attention.

Mos

Re:Don't confuse iOS (hipster) with OSX (UNIX)

[FireFury03]

iPhone's are for hipsters. OSX is certified UNIX running on rock solid, high performance hardware. Don't confuse the two.

I used Linux exclusively for fifteen years. I've contributed to many open source projects, including the Linux kernel, and I'm the maintainer of Linux::LVM and other projects. In other words, I'm a fan of Linux. From one fan of Linux to another, don't dismiss OSX just because the same company makes overpriced toys as well. It's a solid UNIX which will run all of your favorite FOSS software, and do it well.

TBH the biggest problem I'm seeing in the wild with the latest software from Apple, Microsoft and Google is the lack of sensible exception handling.

In the old days, if something broke you got an error message telling you that something broke and giving you enough information to figure out what (hell, even if it was just "Error 2312 happened" you could at least look it up). Then they (primarilly Apple it seems, but the others are not blameless) decided that telling people what broke isn't user friendly so you got totally unhelpful "something broke" error messages with no indication as to what - many times I've have to trawl through a tcpdump capture to figure out what went wrong, and often it's that the remote server returned an error message - giving the user an easy way to see that error message would be really good!

Now, increasingly I'm seeing new software simply not producing any error messages at all - it just sits there looking like its waiting on a remote server or something when in fact it's doing nothing because the remote server threw an error back. Added to that the fact that a lot of software is now becoming an asynchronous background service means you don't even know *when* its trying and failing, all you know is it just isn't working (stuff like iCloud - all you know is that your calendars / files / whatever aren't syncing, no indication as to why or when it failed).

I get that the majority of people aren't going to *personally* find debugging information useful, but when they take it to a professional to figure out why it isn't working it would be damned helpful for the professional to be able to get at some information about what's going on - if you want to keep the error dialogue boxes tidy, just hide the debugging information in an "advanced" button.

Re:Don't confuse iOS (hipster) with OSX (UNIX)

[FireFury03]

It's a disgrace. I also can't believe that Microsoft still haven't given us a way to at copy and paste error messages from dialog boxes when they do bother to produce an error message.

My favorite is something along the lines of "An error occurred, please contact your system administrator" and I'm left thinking "ok, I am my system administrator and I have *no clue* what the error is".