Slashdot Mirror
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."
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.
Sig Battery depleted. Reverting to safe mode.
It could be very useful to have the code stabilize for a bit, put it through regression tests, do some auditing, maximize use of static code checkers, and fix the problems. I hope they seriously consider it.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
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.
//TODO: Think of witty sig statement
We could even have two branches, one with an even minor number for bugfixes and one with an odd minor number for new features.
Develop Linux like Intel develops CPUs: first you make a new shiny, then you do an entire release on improving that shiny. Rinse and repeat ad infinitum. Even better if you have two competing teams working on it. Whichever team comes up with the better product by launch time gets the nod.
-- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
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!
That ended 10 years ago. Long time to be mad.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
You are Steve Ballmer, and I claim my five pounds.
Will my mouse work with Linux 4.0?
The Linux Colonel stayed in the 2.x numbers for many years. I even remember a post by Linux Torvalds on the mailing list saying that there would never ever be a version 3.0. At the time I thought that was pretty weird. I mean, things are going to get a little strange when you get to version 2.99.99.99.99.99.
So,obviously he changed his mind and not only went to 3.0 but apparently he is bored with 3.x and wants to jump from 3.19 directly to 4.0.
Maybe he's jealous of Firefox and Chrome and is trying to catch up to them.
Maybe it indicates a promotion to general.
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?
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.
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.
I hope that they fix the kernel bug that obviously stripped all of the paragraphs out of your comment. It was a kernel bug that did it, right?
Are you for real? Who do you think the kernel devs are, JavaScripters? Ruby-on-Railers?
No, I think they are human. Humans developing and maintaining a very large code base, and all that implies.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
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...
CLI paste? paste.pr0.tips!
Linus's stated reason for not wanting numbers to go too high is seemingly based on a feeling or personal dislike of high numbers.
Two questions.
1. What happens when there are major changes in the Linux kernel? How are they now represented in selection of version number?
2. What happens when the major digit begins to resemble Firefox / Chromes out of control version madness? How many years before Linux 19.4?
It used to be version numbers actually meant something and conveyed some useful hint of scope or amount of change between versions.
I'm not sure dumping this concept for the sake of political games and or OCD pedantry are worth opportunity cost to the user when contrasted with structured predictable scheme based on commonly agreed and understood guidelines.
Win 7 isn't too bad but if I had to choose between Vista and MS-DOS..........
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.
Please no General. Windows didn't really endear many users by theirs that went by the name of "Protection Fault".
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Why the hell does that sound familiar...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
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.
And it will continue to be so long as every ARM device is its own unique thing. There might be forward progress with AArch64.
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.
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 does need to change, however that something is not in the kernel.
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
Well, when I was naive I was pissed off a lot too. When I had about 10 years of code under my belt all Major version numbers in my codebases indicated a complete re-write / major design overhaul and API breakage as far as the eye can see. That same reasoning was what Linus was going by when he said there'd never be a 3.x.x release -- v3 would mean he when insane and wrote the whole thing in a message passing version of VB; I'm paraphrasing.
What's interesting is that I follow the Unix Way(tm): "Do one thing and do it well"; So my "Applications" are actually just that: Application of multiple smaller modules each with their own names / codenames and version numbers. The Editor application "Sledge 0.4.x" is a UI layer stack provided by Core v3.0.x leveraging Sterling v1.6.x for rendering, Vaporworks v1.13.x for a scripting VM, CFG9000 v5.2.x for INI/.conf persistence, etc. Git submodules makes building other programs that target disparate points in the independent module versions simple. Eg: A server for providing HTTP interface to other game-engines/servers via remote console utilizes Core, Vaporworks, and CFG9k. My code editor, audio assemblers, etc. use a different group of modules, but the same common codebase. So, the major application version of an application may not change even if I use a different subsystem or rewrite a module (eg: to get my rendering engine using Wayland natively); Major module version changes translate to minor Application version changes.
Each of the modules is like a library with its own test suite, but provides a small set of associated (terminal) tools (eg: My "Core" library provides a platform abstraction layer and provides a virtual file/network system where local / remote / archived paths can be mounted and mapped to the installed system, allowing me to "cd", "cp", "mv" across the network and OS barriers; Vaporworks provides a scripting environment, but also provides a compiler / bytecode translator and debugger / profiler tools. For these individual modules and their smaller tools the "Major version change = Rewrite" method makes sense.
However with larger applications (say, a distributed versioned 3D game development environment), or a browser, or a Monolithic Kernel: Full / Majority code rewrites aren't occurring. So after having created some sprawling and immense applications I came around to the idea that it doesn't make sense to require the same level of change for a major version number in the application as the module -- Why even have a major version number if it never changes? The game dev studio always has the same interface: It must always interface at the human / machine level. Eg: There's a few ways to create a multi-threaded event pump, but the API for them all will be the same. There's different ways to handle pointer input (esp. on Win32 vs X11 vs Wayland to reduce input latency), but the pointer API is not going to change (it did have to change years ago to support multiple pointers / multi-touch, and that was a major version bump in Core.UI, and in apps that use it). It's not like I scrapped pointers for eye tracking, context awareness and vocalizations or gestures... yet, but that was a substantial addition to the system.
The Linux Kernel is in the same boat. It's to the point now that it's got to provide largely the same interface to its users i.e. programs; ergo: ABI stability; There's not going to be a full rewrite because that would be death -- It wouldn't be "Linux" anymore. Nothing that depends on it would be able to function, and all the dependent applications / modules / systems -- A huge chunk of the ecosystem -- would have to be rewritten given the level of change that warrants a rewrite. Especially if we actually want to improve on operating systems -- Say, eschew POSIX in favor of Agent oriented operating environment with byte-code program modules linkable into machine code at install time, or runnable via VM if untrusted (sandboxing that actually works
even if just to fix some "bugs" that don't even exist,
Let's see, Linus thinks there are bugs needing to be fixed, and some random AC says they don't exist.
Decisions, decisions.
Sig Battery depleted. Reverting to safe mode.
If you end up there then I doubt the "I know what I am doing" bit. If you're building your own kernel, the best ways to do it are either make oldconfig if you have a known good one or make modconfig if you're using a pre-built kernel and want to use only what's loaded. I'm not sure how you end up in "dependency hell" when building the kernel because it will autocorrect missing dependencies.
Nonsensical how?
Overall, it speaks to the simple fact that, if the agenda is to improve things vs make money, improvements are the things that make money in the long run.
FYI: I run a bunch of different OSs: Apple, Linux - 4 or 5 distros, Win 8x, 7x, Vista, 2003 (server)
It's been a long, long time since I've had Linux crash or become unconfigurable - whether I upgrade from a previous version or do a clean install. Way to go, Linus!!
*** Don't be dull.***
2. What happens when the major digit begins to resemble Firefox / Chromes out of control version madness? How many years before Linux 19.4?
3.0 was released on 21 Jul 2011. Given the expected timeframe for 4.0 (if he decides to go through with this proposal, of course), then that's roughly 3.25 years per major version. So the answer to your question would be sometime in 2061.
It used to be version numbers actually meant something and conveyed some useful hint of scope or amount of change between versions.
With this proposal, it does mean something. It means that a 4.0 release is the result of focused testing and bugfixing of the changes and features added in the 3.x series. If the model seems to work, then 5.0 would probably be the culmination of the work put into the 4.x series. Sure, the meaning is different than is used for most projects, but that doesn't make it worse.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
You're not kidding - things I've found wrong with it so far (less than 5 hours of use):
- Takes 1-2 hours to install [facepalm]
- Corrupts some Win8 Xbox game saves
- Adds UEFI watermark which can only be removed by installing an update (requires reboot too)
- Changes your folder/theme settings without permission
- Changes the folders setup in Windows Explorer to promote Skydrive (ya right!) and buries everything useful at the bottom
- Re-installs all the garbage you've spent hours uninstalling (bing/news/finance/etc)
- Doesn't restore the start button, just adds a button to bring up the full screen start
- Creates interface lag/"hiccuping" across all programs
- Removes the lease offensive drop corner\
- Enabled touchpad clicking on my mouse, despite the ELAN options showing it as disabled
- Forces powder blue backgrounds on tiles which make reading difficult (no personalization option to change it)
- Pins IE to the taskbar
Everything in Win8/8.1 is counter to productivity and just makes me want to switch to a new OS...
http://slashdot.org/comments.pl?sid=4407441&cid=45322021
"I've got more toys than Teruhisa Kitahara."
Correction, that should be make localmodconfig. The build system will then prompt you for any missing/new options.
Now it's not that I bump up against many bugs but this is a very smart move. So many times you see feature upon feature added, maybe crash a bit blah blah. But sometimes you just have to stop, take a deep breath and just fix what is there rather than pile on new stuff. A brave decision but essential for the OS itself which must be rock solid above all else.
Bitter and proud of it.
No. Mavericks has a huge number of improvements with the VM subsystem (compressed memory to avoid swap at all costs for better performance and power consumption), timer coalescing, etc. I am seeing a "no bullshit" battery life improvement of 15-20 percent on my 2011 MacBook Pro 15" - and improved performance.
Mavericks is the biggest improvement in OS X performance since Snow Leopard.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Just compile drivers/extra features as loadable modules, and get on with your life? The whole obsession with recompiling the kernel and stripping things (rather than just building as loadable modules) is (for 99% of users) just making work for yourself when you discover that "oh, crap this software i'm trying to use needs the frumble-mumbo kernel feature".
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
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.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
userland desktop UI development has little to nothing to do with the kernel. What do you expect the kernel devs to do to make up for gnome? Where is the kernel deficient on modern hardware? BTRFS is meant for large multi disk arrays, hardly something you see on typical user desktops.
The reason you were downmodded is because you don't know what you're talking about.
It's still a shitbox. Windows 7 wasn't much different from vista, but it magically got rave reviews. It makes me wonder about the validity of a lot of these review sites. Were they paid off, or did they just hop on the bandwagon to get hits?
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.
Why the insecurity with Linux? No one is attacking Linux. People are pointing out that OS X Maverick is more than a bug fix release.
I'd thought the fact that Mavericks introduced a couple of new bugs to the mix would be proof enough that it was not a "bug fix" release.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
You mean General Failure. The same guy who reads your drive A. I hate that guy.
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.
I've got 16GB and don't bother with a swap file/partition at all so everything is cached in ram anyhow. I/O bound apps don't take any longer to load then before and once loaded, the relevent section tends to remain cached instead of written out to swap anyhow - speeds things up quite nicely.
Normal loads only see a total of 8GB in actual use (4GB active - 4GB Cached) with the remainder of the ram free for what ever.
Mod me up/Mod me down: I wont frown as I've no crown
Mavericks introduced some "really cool" bugs, like graphics redrawing issues.
I now regularly have all sorts of static, black borders, and other artifacts around various screen elements. I'm not alone, if you google around.
Please help metamoderate.
You're complaining that it's not easy to compile your own kernel? I am simultaneously both kind of sympathetic, and not. What is the use case that the average-to-slightly-power-user needs to compile their own kernel for, anyway? (I am actually curious. Hardware support?) And if you're a legit power-user, shouldn't you already know more or less how to do it?
On the other hand, documentation always sucks. ALWAYS. Which is NOT to say that we shouldn't try to make it better.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
I'm no stranger to compiling kernels, and my complaints are not that it's "not easy." I build Linux kernel/initramfs combinations that we use in-house, and one of the experimental projects we're working on would require distribution of the smallest possible combination of those two (primarily due to serving customers with crappy rural DSL connections). We still have customers with Celeron machines in the three-digit MHz ranges and much smaller caches than the CPU in a new $300 laptop, so decreasing the kernel's size is helpful, especially with some of the disk-intensive stuff we may run on top of it. Features bring bloat and the work to remove that bloat is not "fun," so developers don't want to do it (and who could blame them?)
Another use case where a tighter kernel may be helpful is one running in a virtualized environment. Since kernel-mode code (even with KVM acceleration) will frequently trigger fallbacks into the hypervisor, we theoretically can minimize these expensive triggers by "running a tighter ship." VMs tend to amplify cache line evictions since two or more kernels are often running on the same physical chip with at least a shared L2 cache between them, and less code in the VM means less cache line evictions.
Follow-up to the minimum RAM aspect:
After changing CONFIG_PHYSICAL_START and its respective alignment parameter from 16MB to 1MB, I can boot a reasonably capable kernel (1975KB gzip, 5MB vmlinux.o) with a BusyBox + uClibc initramfs in QEMU with RAM limited to 13MB. 12MB locks up silently (likely a fault of my initramfs scripts) and 8MB panics due to running out of memory, though I could likely hit 12MB if I just dropped more drivers like CIFS and ethernet controllers. "free" shows 8MB used once the system's up and running from tmpfs, so there's room for most of my shell scripts to get some work done.
It's still nowhere near running in 4MB, and never will be. I do understand that it's not relevant to the vast majority of x86 users, and the main reason I want this capability is so I can play around with (and maybe even USE) an old Compaq Contura Aero 4/25. Fortunately, that was upgraded by the original owner to 12MB of RAM, and if I boot from floppies and don't use initramfs, it'll probably work fine. There's something to be said for an OS in 2013 that can still be used on 1994 hardware! Maybe I can interface the RS-232 port to the SPI-to-ethernet interface I bought a few weeks ago. Hmmmm...