Linux Kernel 2.6.32 Released 195
diegocg writes "Linus Torvalds has officially released the version 2.6.32 of the Linux kernel. New features include virtualization memory de-duplication, a rewrite of the writeback code faster and more scalable, many important Btrfs improvements and speedups, ATI R600/R700 3D and KMS support and other graphic improvements, a CFQ low latency mode, tracing improvements including a 'perf timechart' tool that tries to be a better bootchart, soft limits in the memory controller, support for the S+Core architecture, support for Intel Moorestown and its new firmware interface, run-time power management support, and many other improvements and new drivers. See the full changelog for more details."
Llacking in terminology. (Score:4, Informative)
I'm not perfectly happy with the term "virtualization memory de-duplication". Linux 2.6.32 introduces what is called "KSM", an acronym that is not to be confused with "KMS (Kernel Mode Setting)" and expands to "Kernel Samepage Merging" (though other possibilities with similar meaning have already emerged). It does not target virtualization or hypervisors in general (and QEMU/KVM in particular) alone. KSM can help save memory for all workloads where many processes share a great lot of data in memory, as with KSM, you can just mark a region of memory as (potentially) shared between processes, and have redundant parts of that region collapse into a single one. KSM automagically branches out a distinct, exclusively modified copy if one of the processes sharing those pages decides to modify a certain part of the data on its own. From what I've seen until now, all that's needed to have an app benefit from KSM is a call to madvise(2) with some special magic, and you're good to go.
I really like how Linux is evolving in the 2.6 line. Now if LVM snapshot merging really makes it into 2.6.33, I'll be an even more happy gnu-penguin a few months down the road!
Re: (Score:3, Informative)
I'm not perfectly happy with the term "virtualization memory de-duplication".
The term is a little nonspecific. However KSM is truly wonderful and I look forward to saving a ton of physical memory over my KVM machines when the kvm/qemu userland tools catch up.
This is already in redhat's virtualization stuff.
Re:Llacking in terminology. (Score:5, Interesting)
I have a system running a 2.6.32-rc6 kernel with KSM and the latest kvm (which includes support for this, but its turned off by default)... Because i run a number of virtual images that boot the same kernel and system libs (different apps ofcourse), it saved me over 1gb of memory on the host.
Re: (Score:2)
Of course, every byte is precious as long as it doesn't affect performance, but it would be interesting to know how much more images one can expect to run on one computer.
Re: (Score:2)
kvm (which includes support for this,
Does each application need to support KSM? I can't just run two instances of the same arbitrary application and let the kernel figure out what to do?
Re: (Score:2)
It's worse than you think - the Windows official version is 6.1.7600; Linux is only at 2.6.32.
Re: (Score:2)
Remember that Linus is European? The period is thousand place mark. The Linux kernel number system is actually shorthand for 2,600,320.
KSM (Score:2, Funny)
Linux 2.6.32 introduces what is called "KSM"
WHAT!? I know Linux users are pretty militant (myself among them), but to implement terrorism [wikipedia.org] in the kernel?
Please tell me it's at least built as a *module* by default!
Re: (Score:2)
That sounds interesting. Wouldn't this also resolve the negative effect of static libraries to a large part (having multiple copies of the same code in memory)?
Re: (Score:2, Interesting)
But that wasn't enough, so I had my balls cut off.
Laugh all you want, but I know an AIX kernel hacker who did just that.
-l
Re: (Score:2)
At least one M$ lover has gone the distance - http://en.wikipedia.org/wiki/Ina_Fried [wikipedia.org]
ATI chipsets (Score:2)
2.6.32's KMS and R600/700 improvements are expected to give a huge 3D performance boost to the open source ATI drivers - can't wait to test this!
Re: (Score:2)
I'm excited about the ATI improvements making it into the kernel too. Wonder if Ubuntu Karmic will pick up the new kernel after some testing?
Re: (Score:2)
No, you'll have to wait for Lucid Lynx (Ubuntu 10.04) for these changes.
Re: (Score:2, Informative)
No, as Ubuntu Releases are version-stable, and backport security fixes only (Firefox being the exception of that rule). You may install the kernel from the mainline kernel PPA though: http://kernel.ubuntu.com/~kernel-ppa/mainline/ [ubuntu.com] .deb that fits your architecture, and install it via `sudo dpkg -i /path/to/your/downloaded/archive.deb`.
Just fetch the
Re: (Score:2)
2.6.32's KMS and R600/700 improvements are expected to give a huge 3D performance boost to the open source ATI drivers - can't wait to test this!
This is indeed excellent although it needs to be backed up by support from the X driver. Currently I am running Ubuntu Karmic on a Radeon HD 3600 series card (RV635, which counts as an R600 series - quite confusing) and 3D support sucks. Both the "radeon" and "radeonhd" drivers only have basic support for these chips - desktop effects don't really work.
I was using the fglrx driver on Jaunty, which worked OK, but it seems to be getting worse with every release. In Karmic it was so broken I just gave up on it
Re: (Score:3, Informative)
The Fedora team has backported the KMS and R600/700 improvements to FC12, which I've been running for a few weeks now. While it's better than nothing, 3d performance still has a way to go. The performance of my old Heretic II game is still unacceptably slow.
The ATI drivers usually took the sacrifice of a goat to get them to work, but their performance was far superior. Too bad ATI won't support recent releases of Fedora.
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
Re: (Score:2)
"In Internet slang, a troll is someone who posts controversial, inflammatory, extraneous, or off-topic messages in an online community, such as an online discussion forum, chat room or blog, with the primary intent of provoking other users into an emotional response[1] or of otherwise disrupting normal on-topic discussion."
Karma butchery aside, everyone who modded this post troll is an idiot. Since when was expression of opinion and description of personal experience in any way inflammatory or e
Does it Fix XKCD 619? (Score:5, Funny)
Re:Does it Fix XKCD 619? (Score:4, Funny)
http://imgur.com/73EAu [imgur.com] - RESOLVED, FIXED quite a while now!
Re: (Score:2, Redundant)
Yep, it's fixed.
See here: http://imgur.com/73EAu [imgur.com]
People work on the "easy" problems (Score:5, Interesting)
Like the strip, and it raises a valid point. The bottom line is that kernel development advances more quickly than user interface and applications for the same reason that physics advanced more quickly than say ... psychology. That is, because developing a faster kernel is a much easier problem than developing a fun, usable desktop environment. It's easier to write, easier to test, and easier to debug. People tend to gravitate towards problems that they think they can solve--and ignore the problems they don't understand or don't want to deal with.
Personally, I think that the best way forward for Linux on the desktop would be to take GNUstep to the next level. There's a LOT of code there already written, and with a bit more work you might be able to have source-level compatibility with Mac OS X--which would give you access to a bunch of commercial apps. And, most importantly, the ability of the OpenStep API to produce a world class desktop--best in the world in fact--is proven. After 10 years, I don't think that either KDE or GNOME have really done all that much for Linux on the desktop... it's time to try a different approach.
Of course, I'm just kibbitzing, not bringing code. So what right do I have to say anything?
Re: (Score:2, Insightful)
Re: (Score:2, Insightful)
You are confusing tough (challenging) with tough (laborious).
Re:People work on the "easy" problems (Score:4, Insightful)
Making a good desktop environment is extremely challenging, as shown by the fact that no one has made one yet.
Re: (Score:2, Insightful)
People tend to gravitate towards problems that they think they can solve--and ignore the problems they don't understand or don't want to deal with.
I think that should have read
Engineers tend to gravitate towards problems that they think they can solve--and ignore the problems they don't understand or don't want to deal with.
Re: (Score:3, Insightful)
Purely technical solutions to marketing and promotional problems rarely work, so its unsurprising that GNOME and KDE have done much for Linux on the desktop, since their marketing and promotional efforts are pretty minor. Of course, switch technical approaches to focus on GNUste
Re:People work on the "easy" problems (Score:4, Insightful)
That is, because developing a faster kernel is a much easier problem than developing a fun, usable desktop environment.
I disagree, it's not an easier problem. It is, however, a much more interesting problem to solve, especially to skilled hackers.
One other aspect here is that the target audience is bigger for the kernel. Desktop uptake is still very low, but kernel is used by any device that runs Linux, whether it's a router, a smartphone, a server, or a netbook. This has a side effect of kernel hacking being better financed than desktop development, as there are more commercial players interested specifically in the kernel, who couldn't care less about KDE or Gnome.
Re: (Score:2)
Very true. Desktop Linux is a bit player when compared to the overall use of Linux, and it's truly a hobbyist's domain.
Re: (Score:3, Interesting)
Desktop uptake is still very low, but kernel is used by any device that runs Linux, whether it's a router, a smartphone, a server, or a netbook. This has a side effect of kernel hacking being better financed than desktop development, as there are more commercial players interested specifically in the kernel, who couldn't care less about KDE or Gnome.
If I hadn't already replied in this article, I probably would have modded you up. This point is hard for many to understand, but it's quite possible that the to
Re: (Score:2)
Whether or not its an easier problem to solve, overall, its an easier problem for the kind of people who actually write code to define concretely, and validate solutions to, since the skill set needed to do that with that problem is closely related to the skill set of programmers. This is important, because to successfully solve a problem (or, in the case of problems that progres c
Re: (Score:2)
While I agree with tulcod's response -- kernel development is usually much harder than desktop development. However, there is one important difference. A faster kernel is a measurable goal. While you might be able to make a "fun, usable desktop environment" for a single person, and maybe even for a good percentage of the population, you will never, ever satisfy everybody. Half the people want more op
Re: (Score:3, Interesting)
Well, GNOME and KDE ( I prefer one of them but it is not relevant to this post ) have done lots for Linux on the desktop. I have been running it for a number of years because I find it more pleasant to use than Windows. And I am not alone.
And the millions of people using it are doing so against active attacks from a number of organizations. Mainly closed software companies, and also (mainly in the past) political organizations and governments.
Re:People work on the "easy" problems (Score:4, Informative)
Re: (Score:2)
Re: (Score:2, Insightful)
what do you propose? to rewrite the kernel in python? sorry, but something needs to run on the hw itself eventually, nevermind that the language used has little to do with your complaints. User mode graphics are ok for basic desktop use, but forget it if you want decent performance for 3d.
do you know any skyOS or haiku users? I don't.
Re: (Score:2)
I agree with you about the monstrosoties. The kernel is full of classes and virtual functions. C++ provides exactly those features without the syntactic overhead and assosciated bugs. Because they are a built in feature, everyone does them the same way. Not only that but it uses less memory (kinder on the cache) because it stores only one copy of each vtable. It also provides *exactly* the same features as C for when they are really needed.
But people keep complaining about the "complexity" of C++ while happ
Re: (Score:2)
"I'm tired of the Linux kernel; it's really not that great."
Linux has always been more or less the entire FLOSS pool. Nothing in it is meant for one goal. You get all these different goals. Yes it's far from elegant in that respect.
But... It's an ecosystem where people throw in stuff. It's like evolution. You start with crap. Make countless modifications. The distro's then choose what's important. Everything that sucks dies. Everything is better than the version before sticks.
Linux was a bunch of crap realy
Re: (Score:2, Insightful)
I'm tired of the Linux kernel; it's really not that great. Everyone seems obsessed with C, going as far as to spawn these kind of monstrosities [wikipedia.org] just to force modern features into a traditional platform.
What, has GObject made it into the kernel?..
Ahh, IHBT.
Re: (Score:2)
No it would not. You are looking for ABI compatible, not source-level compatible (or even API compatible). And who the hell would want to duplicate the nightmare in OS X programming where Apple couldn't even decide if they were going to go with Carbon or Cacoa for 6t4-bit? Then of course, they axed one in-spite of what they were saying previously.
http://labs.trolltech.com/blogs/2008/03/03/qtmac-cocoa-port-alpha-released/ [trolltech.com]
It was not a this or that decision, Carbon is a legacy API that got left at 32-bit, and Cocoa was always the one to use going forward. In the end it forced developers like Trolltech to port to Cocoa which is A Good Thing TM.
Re: (Score:2)
There is nothing the kernel developers can do about this. On my machine which is a dual 2218 opteron with Dual nvidia 8800gts video cards running 4 monitors just playing flash a single screen will bring one cpu core to its knees. Normal sized flash videos will bring one cpu core to its knees and will sometimes drop frames. The same video if saved to a local file and played with xine/mplayer etc will use up 1-2% cpu power at the lowest cpu freq (1 ghz).
Linux is perfectly capable of smooth video playback at l
Re: (Score:2)
It makes one wonder, with Microsoft encroaching on Adobe's turf like this, shouldn't they at least try to cover their ass and give great support on non-MS platforms? I really don't get what's going on as far as their strategy goes... Or maybe there just isn't any strategic planning.
Btrfs: kill off ext# please! (Score:2, Interesting)
I'm glad to see Btrfs improving so rapidly. I hope popular distros start including support for it, but more importantly, start using it as the default filesystem.
It's time for the ext-based filesystems to die. They are a technology that was obsolete a decade ago.
ReiserFS was set to kill them off, but unfortunately found another victim first... JFS and XFS only work well in certain high-end niches. But Btrfs is much better as an all-around filesystem, which is why it has a chance to finally put an end to ext
Re: (Score:3, Insightful)
Too soon!
Re: (Score:2)
How does Btrfs compare to ZFS? I've been using ZFS-on-FUSE, and absolutely love the incredible data integrity and volume management features that it provides. The new support for deduplication will also be wonderful once implemented.
Of course, the performance and the idea of trusting my data to FUSE leave much to be desired.
(On the downside, I'm peeved that Btrfs is GPL licensed, which will prevent it from becoming "the one true filesystem" from here on out. Windows users will be stuck with NTFS, Linux
Re: (Score:3, Insightful)
What prevents other, non-GPL operating systems from using Btrfs?
Writing drivers for a filesystem is not a "derivative work" is it?
Re: (Score:2)
Re: (Score:3, Insightful)
Nevermind that, I think that the whole objection to a BSD license in this case would be that such a license could not prevent MS (or Oracle, or Apple) from "embracing and extending" the whole filesystem so that the "standard that everybody uses" is no longer free
Re: (Score:3, Interesting)
I think he was referring to the parent. The whole point of the BSD license is to not give a rat's a** about who does what with the code.
One could easily add an extra clause to the standard BSD license that states that any derivative work must be fully compatible with the reference Btrfs implementation in order to bear the Btrfs name. Many projects include such naming clauses.
This sidesteps the "extend and embrace" problem completely.
Re: (Score:3, Insightful)
But even assuming ms would use an open filesystem, they would want to alter it to make it incompatible with everyone else's implementation... And they can't do that very well if people are able to download the source.
Re: (Score:2)
What prevents other, non-GPL operating systems from using Btrfs?
Writing drivers for a filesystem is not a "derivative work" is it?
How good, accurate and up-to-date is the specification of btrfs?
If only real, accurate "specification" is the source code, then it's damn hard to create a compatible and reliable new implementation from scratch. File systems are complex, concurrent (meaning many files being accessed simultaneously) and performance-critical as well as reliability-critical. Getting it right is hard, while getting it wrong is bad, so there needs to be really good reasons to even try to do it, instead of using something that al
Re: (Score:2)
I think I have a (theoretical) solution to that.
Lets say that the copyright owners of btrfs create the windows/osx/solaris/aix drivers?
Or more realistically, if the copyright owners of btrfs grant an interested third party a special license to create a lgpl'd btrfs driver?
Re: (Score:2)
I think I have a (theoretical) solution to that.
Lets say that the copyright owners of btrfs create the windows/osx/solaris/aix drivers?
Or more realistically, if the copyright owners of btrfs grant an interested third party a special license to create a lgpl'd btrfs driver?
There can't be a "special license" to do LGPL version. Once such version is out, well, it's out. So they could as well make the whole thing LGPL (which IMHO would be a good idea).
But if there are a lot of developers, getting everybody to agree (or even to reach everybody) is a lot of work. Replacing=rewriting the code of those who don't agree might be on option, depending on how much of it there is.
But I'm pretty sure they actually thought about it and chose GPL over LGPL because they wanted to, so they're
Re: (Score:2)
There can't be a "special license" to do LGPL version. Once such version is out, well, it's out.
Why not? If the copyright owner* grants a license to do a LGPL driver for a non-Linux OS, it doesn't necessarily mean the entire project has to be cross-licensed to LGPL, does it?
And yes, for the record, cross-licensing the entire thing as GPL/LGPL might be a good idea too.
* This is assuming "the copyright owner" is just one person or a small group of people who agree on doing such a thing.
One file system to rule them all (Score:3, Interesting)
On the downside, I'm peeved that Btrfs is GPL licensed, which will prevent it from becoming "the one true filesystem" from here on out.
Well, ZFS itself has a GPL-non-compatible license, but that doesn't prevent it from being usable in Linux as an independent user-space process through FUSE.
The same approach could be imagined under non-GPL-compatible OS: have the GPL implementation as a standalone userspace daemon.
(Which is not a bad idea - give more freedom to upgrade)
Windows users will be stuck with NTFS
No matter what. Even if some kernel guru released a tri licensed LGPL/BSD/Proprietary perfect file system, Microsoft will still be using NTFS and promising WinFS soon for wha
Re: (Score:3, Informative)
Getting slightly off-topic, but after the FAT patent-trolling recently this interests me.
I went and dug up the sadly-neglected udftools package and installed it. Sure enough, the following command (found with a bit of Googling) seems to produce a filesystem on my SD card that can be read from and written to just fine by Linux, Mac OSX (Leopar
Re: (Score:2)
Re: (Score:2)
MS will never support a filesystem they don't control unless forced to, and certainly won't make it the default...
BSD, Solaris and OSX all support UFS, as does Linux.... Linux also supports the hfs+ filesystem currently used by OSX, not sure if bsd/solaris do but there are bsd licensed drivers for it so no reason not to.
Re: (Score:2)
BSD, Solaris and OSX all support UFS, as does Linux.... Linux also supports the hfs+ filesystem currently used by OSX, not sure if bsd/solaris do but there are bsd licensed drivers for it so no reason not to.
Linux only sort-of, depends on flavor. I can't reliably mount a CF card r/w from pfSense (FreeBSD) under linux.
multiplement implementations (Score:2)
If Btrfs's design proves to be good, there is not a reason why there can't be both GPL and non-GPL implementations written for it. I think one of the things for universal filesystem to be successful is to have something that has more than one implementation.
FAT32 will have to die in the market when people get sick of files over 2gb getting truncated. The end is near for FAT.
Re: (Score:3, Insightful)
I've been using ZFS-on-FUSE
Are you insane? You probably just cut the performance of your drives by 90%.
Of course, the performance and the idea of trusting my data to FUSE leave much to be desired.
Oh sorry you're informed AND insane. :P
Re: (Score:2)
Re: (Score:2)
You may as well stop holding your breath now. Microsoft will never support a general purpose filesys
Re: (Score:3, Insightful)
I would prefer to use EXT2 on small sdcards, so as to support filesystem permissions...
Or how about something like jffs2 - a filesystem actually designed for flash media.
FAT32 is a pretty garbage filesystem, and it's patent encumbered, an open filesystem without the weaknesses of fat32 and which is supported everywhere would be extremely useful. It won't happen tho so long as MS have sufficient market share to bury any open filesystem, they want people locked in to their proprietary patented filesystems and
Wrong about JFFS2 (Score:2)
See this Maemo development thread: http://www.gossamer-threads.com/lists/maemo/developers/36921 [gossamer-threads.com]
Re: (Score:2)
It's time for the ext-based filesystems to die. They are a technology that was obsolete a decade ago.
ReiserFS was set to kill them off, but unfortunately found another victim first... JFS and XFS only work well in certain high-end niches.
In my experience, JFS offers most of the benefits of ReiserFS, while being lighter on CPU. So it is definitely not just for the high end. It has also turned out more stable than Reiser, though in the recent years this has evened out.
On some of my machines there have been consistent problems with using JFS on the root partition, but this may be due to the init scripts. No data has been lost, though, and on non-root partitions JFS has consistently been rock solid for me. This includes a number of x86, Powe
Re: (Score:2)
If you look at the filesystem benchmarks, JFS is often not the fastest, but scores best in term of CPU usage. I've found that on a netbook which has a very fast disk (ie flash) and not much CPU, JFS is actually the best option. YMMV of course, and I came to this conclusion before ext4 was released, and I haven't trried the pre-release ones like btrfs.
Re: (Score:2)
Re: (Score:2)
Unless I am out of date, there's only really ext2 in windows via ext2fsd, which will mount ext3, but sans journaling, and will only mount ext4 if you disable extents, which is one of the major features.
Re: (Score:2)
And what about Reiser4?
She's dead, Jim.
Re: (Score:2, Interesting)
Reiser4 info here as of Nov 10 2009 (Score:2)
http://www.phoronix.com/scan.php?page=news_item&px=NzY4OQ [phoronix.com]
Big speedups for media workstations.. (Score:5, Informative)
Is this a hoax, or what? (Score:5, Funny)
rewrite of the writeback code
So you didn't de-lace the interace or uncabulate the turboencabulator? I'm now about 85% convinced that the open source movement is just making shit up.
Re: (Score:2)
Re: (Score:2)
So you didn't de-lace the interace or uncabulate the turboencabulator?
Dude, don't be ridiculous, of course they uncabulated the turboencabulator, how else could they contraplectify the apoplectifier?
does KSM mean the death of Xen? (Score:2)
Re:does KSM mean the death of Xen? (Score:5, Informative)
If KSM puts the KVM module on par with Xen in terms of performance then I think the writing is on the wall for Xen's demise.
No. Not at all. KSM saves memory but hurts performance. It shares memory across virtual machines to save memory.
Xen can't share memory across virtual machines, it's just not put together like that.
Performance is about identical for KVM and XEN.
Re: (Score:2)
Being somewhat ignorant of the inner workings of XEN, VMWare, KVM and the like the very idea that VM's would share memory at all seems rather risky in terms of them being sandboxed from each other. Beside a hypervisor being able to allow many VM's to run basically any OS, it would also seem that there is a security element involved eg: running Windows in a VM and Linux in another and NetWare in yet another the three would not have the ability to know the other were there and therefor be safe from being hac
Re:does KSM mean the death of Xen? (Score:4, Informative)
Instead of storing multiple copies of the same data in memory, it stores a single read-only copy and points the others to it. If you try to write to it, it traps, creates a new read/write instance which is exclusive to you and then points you at it...
Shared libraries work in much the same way. Shared libraries been implemented pretty securely for many years now.
Re: (Score:2)
I grock the lib concept, each program gets it's own data segment and the code is run in a single image ( if you will ) and that conserves memory. Each data area is private to the program unless they explicitly share it through some IPC mechanism.
This is interesting as it seems like a way to write malware. If I wanted to deliberately run the machine into the ground I could just look for those data area's and keep attempting to write to them and force the OS to keep duplicating them over and over again. Now
Re: (Score:2)
Re: (Score:2)
KSM saves memory but hurts performance.
If I have plenty of memory, can I easily disable KSM?
Re: (Score:2)
KSM saves memory but hurts performance.
If I have plenty of memory, can I easily disable KSM?
Disabling or enabling this should be no harder than one command line option to qemu.
Disabling it is the right thing to do if you don't need the memory saving benefit. It will waste CPU and throw your stuff out of data caches. I think most people will be more concerned with saving memory though, I know I am.
KMS (Score:4, Informative)
Kernel Mode Switching is great except for the fact that all 3 major video card vendors decided to nix VGA console support.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Yes.
However, ATI, NVidia, and Intel have all three decided to deprecate the VGA text console if used with KMS enabled.
So if you use KMS with one of those cards, kiss text mode goodbye becasue the powers that be refuse to support it.
Re: (Score:2)
Re: (Score:2)
kiss text mode goodbye becasue the powers that be refuse to support it.
The ATI/Radeon driver, at least, provides its own hi-res console mode (all in the kernel, not dependent on Xorg, works with fbcon to act as a framebuffer driver), so why would you want the old VGA (low-res, low-refresh) mode anyway?
For special/embedded systems, they can always leave out that specific driver (ATI/NV/Intel) that does KMS, and keep the old VGA console code, its still in the kernel & available as an option.
You haven't lost anything, you just can't use both at the same time now, e.g. you can
Re: (Score:2)
Loading fbcon has a couple of ugly side effects
1. Since we're pushing pixels instead of cells, things slow down an order of magnitude or two
2. Once the console drivers have bound onto fbcon and off of vgacon, there's no way to get vgacon back without rebooting.
Re: (Score:2)
fbcon sucks
time saving makefile (Score:5, Interesting)
Re:time saving makefile (Score:4, Interesting)
Re: (Score:3, Informative)
There's also a "make localyesconfig" that will be even more useful for me, particularly for removing the need for initrd. I can now do a "make localyesconfig", and not have to try to guess what particular combination of compiled-in options is required for the computer to start up, then add in the additional things as modules.
Re:ATI support (Score:5, Informative)
The 2D specs were released in September 2007. The 3D specs were released in January 2009. Drivers do not write themselves immediately just because the specs are out, it still takes some time. But it's getting there, and they won't go away like the closed drivers will, the moment the manufacturer feels it's no longer profitable to maintain them.
Re: (Score:2)
I don't think they've been following that convention for like, oh, 6 years or something. You're right that once upon a time that was the way it worked, but afaik, not any more.