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."

Re:There is balls-to-the-wall competition right no

[elfprince13]

Not really. Mavericks did some really cool stuff under the hood. Timer-coalescing, "App Nap", and compressed memory are all pretty big. Take a look at the relevant sections of the Ars review to see what I mean.

RAM Doubler

[tepples]

I had compressed memory on a Mac nearly two decades ago in the 7.5.x days with Connectix RAM Doubler. Did OS X just get native compressed memory after Connectix's patents ran out?

Compcache/ZRAM

[Jody Bruchon]

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:My how things change

[fisted]

From TFLKML:

Onto a totally different topic: we're getting to release numbers where I have to take off my socks to count that high again. I'm ok with 3., but I don't want us to get to the kinds of crazy numbers we had in the 2.x series, so at some point we're going to cut over from 3.x to 4.x, just to keep the numbers small and easy to remember. We're not there yet, but I would actually prefer to not go into the twenties, so I can see it happening in a year or so, and we'll have 4.0 follow 3.19 or something like that.

Not sure how that reminds you of rapid-release firefox-style...

Re:Sigh

[aardvarkjoe]

I'm still pissed that Linus moved away from the traditional development model: Even number x.Y releases were stable branch and odd releases were testing/development.

Linux moved away from that model because of the problems that it caused. There were very long (compared to today) cycles where the current "stable" kernel series was basically in maintenance, and the development kernel was diverging further and further from the stable kernel. So if you wanted to use a kernel with new features, you were stuck using the development branch -- and if you waited until there was a new stable series, then there was a big jump from the kernel you were on up to the new one.

Once Linus decided to change the development model, there was no point in keeping the old format for the version number. The version numbers should be determined based on the development policy, not the other way around.

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:Yes, it is needed.

[smash]

Often, it's the "minor" bugs which are a warning of a more serious underlying problem that will bite you in the arse later in a more serious manner.

True... but not entirely

[SmallFurryCreature]

OSX is indeed a real Unix... but the user world has moved on to Linux where things don't just work but are also easy to setup and control.

If you are used to a Linux install, going to OSX will be a shock. For one, there is no native package system, you will have to install one of several on your own. They are not nearly as reliable as say the debian system. It is do-able but for young people it pays to remind yourself that there is a reason UNIX never took off. That BSD never took off. Linux (the whole eco-system) did far more then make a Unix compatible system, it made Unix usable for the average geek. The "real" unixes were bastards to work on with each system just totally different enough to not make them at all compatible. Not like the way you can google a red hat fix and apply it to ubuntu or the way a arch-linux wiki page is useful to a gentoo user.

OSX made Unix usuable for the average hipster but crossing from geek Linux to once touched a girl OSX will be a shock, just how many things are different and just how much of OSX overrides the Unix way of doing things.

You can run FOSS software but it is NOT as easy as with a debian system. Before you buy a OSX machine to replace your ubuntu install, get an OSX user to show case their FOSS capabilities. Let them show you how they install an apache upgrade not yet released by Apple. Then go and hug your Ubuntu box and swear you will never ever look at an other system again.

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

[semi-extrinsic]

It's not a UNIX if it doesn't ship with a C compiler. End of story. I mean, you can take a motorcycle and add a roof and some gyro-stabilizing stuff and have it certified by the NTSB/whatever as a car, but it doesn't meet people's expectation of what a car is, and that's the only definition that matters in the real world.

Add in the mess that is ports and the hours you have to spend to get a decent environment for almost any programming language, and it's pretty far off fitting my definition of a UNIX at least. Let's see, on my computer, the time it takes to install python 3, including downloading and me answering "yes, I want to install it":

# time pacman -S python
...
pacman -S python 2.19s user 0.16s system 51% cpu 4.539 total


Come back when your "UNIX" does that.

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

[Clsid]

I think you really should read the article http://en.wikipedia.org/wiki/Single_UNIX_Specification [wikipedia.org]

I think it will clear your doubts about the subject at hand.

Re:How can compressed mem improve power consumptio

[smash]

Essentially it means that the OS can keep from using swap. Spinning the drive up and remaining awake to page in and out takes a lot longer (and thus the CPU, disk, etc. must be powered up and in an active state for far longer) than compressing the memory and staying off swap. The compressed memory isn't the only power saving feature Mavericks has obviously, but it does contribute to keeping parts of the system asleep as much as possible to save power.

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

[epyT-R]

I've run into this before, and I've gotten modern (late 2.6) kernels running on systems with 8MB of ram. I have not tried with 3.x, and it's difficult to get the kernel size under 3 or 4MB these days. In processor type and features, try disabling the 'build a relocatable kernel' option, and setting CONFIG_PHYSICAL_START (shown in menuconfig as "physical address where the kernel is loaded") to a value less than the default 0x1000000 (16MB). This is a worked-for-me status solution.

Re:I didn't have to read far to find the garbage

[Jody Bruchon]

You do realize that there are lots of "switches" that turn on simply by virtue of the option "CONFIG_X86=y" right? The DS booting (an older 2.6 uClinux kernel) with 4MB and an ARM chip is irrelevant. I am aware that Linux can boot on MIPS and ARM routers with 8MB of RAM, but the relevance is nil when compared to x86. In fact, I dare you: compile an x86 kernel with almost nothing in it but console drivers and whatnot (I've build gzip-compressed kernels at ~800K compressed), make a minimalist BusyBox+uClibc initramfs, fire up QEMU/KVM with the "-m 16" option and boot your kernel. It won't work. Someone here suggested changing an advanced setting I didn't try yet, so that might make a difference, but it doesn't change the fact that ARM and x86 are two different worlds and a lot is forced in x86 that is optional in ARM.

Also, perhaps you should consider being less of an asshole when you fire off a knee-jerk response like this one. You are capable of questioning information without being condescending.