Kernel 2.6.12 Released 291
Mad Merlin writes "Linux kernel 2.6.12 has been released! Kerneltrap has a brief summary on it. The changelog is only partial however: 'The full ChangeLog ended up missing, because I only have the history from 2.6.12-rc2 in my git archives, but if you want to, you can puzzle it together by taking the 2.6.12 changelog and merging it with the -rc1 and -rc2 logs in the testing directory. The file that says ChangeLog-2.6.12 only contains the stuff from -rc2 onward.' As always you can find the changelog and the source at kernel.org"
Just after ATI... (Score:4, Funny)
Let me start off the collective "ARRGGGHHH!"
Maybe? (Score:5, Interesting)
Re:Maybe? (Score:5, Insightful)
Re:Maybe? (Score:2, Informative)
Also worth mentioning is
Re:Maybe? (Score:3, Insightful)
Re:Maybe? (Score:3, Insightful)
Re:Maybe? (Score:2, Insightful)
Yeah, real big of nVidia to release closed, binary drivers that may or may not run on different configurations and most assuredly will not run on anything other than Linux/i386, and to make no mention whatsoever of hardware specifications or documentation. Really nice, how they've ensured that there will be no non-trivial open development of their drivers by providing a buggy, impractical, but "good enough" solution.
nVidia is ensuring that F/OSS graphics will continue to be criplled by establishing an ina
Re:Maybe? (Score:2)
I can't believe Slashdot would be so embarrased by their ugly HTML to actually ban the W3C validator...
Re:Maybe? (Score:3, Insightful)
No.
You don't need to release a new driver with every kernel release. ATI just has no idea what they're doing that's all.
A good example: When 2.6 first came out, the nvidia 2.4 kernel module could be made to compile with only minor modifications! I upgrade kernels with every release, and I've never had to go out and find a new driver release.
But to answer your question, the reason why most manufacturer
Re:Maybe? (Score:3, Insightful)
Reward nvidia for releasing *binary* drivers? Anybody with an interest in the long-term success of Linux should be *punishing* nvidia by NOT buying their hardware.
Reward the companies that produce open source drivers, or publish specs, or help the developers of open-source drivers. Don't reward companies who are destroying the core value of Linux.
Re:Maybe? (Score:5, Insightful)
Without a proper nvidia driver, Linux would be basically useless for any real modern desktop use, as all we'd have is driver support comparable to say that of any of the other open sourced ones, SiS, via, intel, matrox, the open source nvidia, or ATI drivers. Which by the way all tremendously suck. Sure basic 2d operations are supported, but that's it.
nvidia is under no obligation to release the internals of their product, and why would they in such a competetive market!
Punishing nvidia for running a good, smart business, and support free and alternative operating systems with quality products is an absolutely ridiculous thing to say.
Before you spout your mouth off like that, I'd like to see you create and maintain the number one graphics card company in the world, then release the source code to your driver which would give your competitors a HUGE leg up on understanding the internals of your product.
Don't be such an idealistic ass. It's people like YOU that destroy the core value of Linux.
Re:Maybe? (Score:2, Insightful)
With Linux, yes it is. If you don't care about open-source then use something else.
Idealism is not a dirty word. Idealism means seeing the bigger picture and foregoing fleeting fancies in the pursuit of long-term success. If you're too short-sighted to understand that then perhaps Linux is not for you.
Re:Maybe? (Score:2)
It's not as if I don't see how having an open source driver would be a really good thing. Of course I do!
In your case, idealism is a dirty word. Your idealistic views keep you from seeing the reality of the situation, which makes
Re:Maybe? (Score:2)
Re:Maybe? (Score:3, Insightful)
With Linux, open source *is* the real issue.
The core value of Linux is that it is open source.
Good. Linux will be better off without them if the mere mention of "open source" is enough to scare them away.
Re:Maybe? (Score:3, Insightful)
I agree. Unfortunately, the desktop video card market is largely binary (NVIDIA/ATI), and NVIDIA is clearly superior in their support for Linux. There are many theoretical and practical problems with binary drivers, but NVIDIA has gotten it mostly right. ATI's Linux drivers are awful, whic
Re:Maybe? (Score:2)
All the nvidia and ati cards have open source drivers. The open source drivers sometimes lack features, or don't perform as well, but they are open source. It is not correct to say that the "video card market is largely binary". That is a choice that the end-user makes.
Re:Maybe? (Score:3, Interesting)
If you want to play 3D games on Linux today, you need to use binary drivers. Another alternative is to use Windows for gaming, and Linux only for desktop applications. In that case, nvidia still has no incentive to release any specifications or open source drivers for Linux.
A third alternative is to forgo playing any 3D
Re:Maybe? (Score:3, Insightful)
>With Linux, yes it is. If you don't care about open-source then use something else.
What? I don't recall Linus Torvalds (the creator of Linux), saying that the whole point of Linux is to run entirely open source software. Perhaps you can find a quote, either from Torvalds or from the kernal copyright licence that says you're not supposed to use any non-open-source software on Linux.
The way I see it, Linux was created to be a decent Unix-alternative,
Re:Wrong word (Score:3, Insightful)
He did use the word zealot. It's very amusing because apparently a lot of you think "zealot" is an insult. I'm not insulted by that word at all. I'm proud to be a zealot.
I pity all of you people who are so jaded with life that you can only express yourself with anger and cynicism. It's so... teenager. Try being a zealot. It's much more fun.
Re:Maybe? (Score:2)
I'm sorry, I'm not savvy to the mechanics of writing drivers. I, and the VAST majority of people, are not going to fuck around under the hood of a video card driver to make it work, we will simply use a different card, or a different OS.
Re:Maybe? (Score:3, Insightful)
I didn't mean you have to change the driver itself. This would be impossible as it's a closed source binary only driver!
I just meant minor modifications to the system. And I was talking about a fringe case: the case where a whole new version of the kernel is released (not just a point release). If you think about this it speaks very well on nvidia's behalf.
Also, in their favor, they released a 2.6 version soon after the release of 2.6. (No modifications necessary
Re:Maybe? (Score:2)
Re:Maybe? (Score:2)
Because unlike every other remotely mainstream OS out there, Linux makes no attempt to preserve binary compatibility across kernel releases.
Re:Just after ATI... (Score:2)
But, does 2.6.12 really break the new ATI drivers? That`s kinda wacky...
Re:Just after ATI... (Score:5, Insightful)
As someone who specifically uses 2.4.x kernels due to certain support issues, I give you permission not to upgrade. Matter of fact to go further I give you this checklist to decide any and all software upgrades in the future:
Does your current software solve your needs?
Does the upgrade mess with something you care about?
Does the upgrade fix a vital security issue?
Are you a developer?
I would discuss the answers in an if.. then... else sort of way. But, if you can upgrade your kernel you should be able to figure it out. Oh, one more thing, if you do not know the answer to any of these questions, you shouldn't even think about upgrading. Do not run code simply because it has been written. Code is written to address needs, use the code that was wrtten for yours and be happy that there is code for other people to.
Re:Just after ATI... (Score:2)
i.e. a site that will tell me which versions are safe to use without worrying about backporting security fixes.
Re:Just after ATI... (Score:2, Funny)
I thought laziness was a good enough reason not to do anything....
Re:Just after ATI... (Score:2)
Now, there's the right message (Score:5, Insightful)
Nothing instills confidence in those who are not convinced that Linux is mature enough for their application like the messages: "I was too lazy to download these files to put together a changelog" and
"the changelog wasn't in our CMS."
Re:Now, there's the right message (Score:2)
Re:Now, there's the right message (Score:3, Funny)
There you have it.. Clearly he's in the right.
Re:Now, there's the right message (Score:2, Insightful)
Priorities (Score:3, Insightful)
This is the type of thing that happens when engineers manage projects rather than business people. That's not a criticism.
Re:Priorities (Score:5, Funny)
Yeah, I hate it when engineers manage the business people.
Some explaination in the changelog... (Score:5, Informative)
commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Author: Linus Torvalds
Date: Sat Apr 16 15:20:36 2005 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Re:Some explaination in the changelog... (Score:2)
Re:Now, there's the right message (Score:2)
Re:Now, there's the right message (Score:5, Insightful)
Re:Now, there's the right message (Score:2)
Re:Now, there's the right message (Score:3, Insightful)
Ironically, even ones who wouldn't have been concerned if it had never been mentioned at all.
Quite a few businesses put a greater value on the paper trail than the quality of the system.
Re:Now, there's the right message (Score:2, Interesting)
I'm a card-carrying member of the FSF, a Linux user, a supporter, and didn't mean to HURT anybody. I meant to make an obvservation, and hope that it perhaps HELPS somebody.
Re:Now, there's the right message (Score:2)
Re:Now, there's the right message (Score:2)
Don't mean to beat a dead horse here or anything (maybe I do actually)... But the decision to use Bitkeeper in the first place was a bad one. So was the decision to reinvent the wheel. SVN [popies.net] works fine.
Re:Now, there's the right message (Score:2)
SVN is designed to replace CVS, but Bitkeeper and git are entirely different software categories (just like Java and gcc are both programming tools). The system topology during execution of the CMS is completely different, because BK and git work without a connected network. For comparison, run subversion without any connection to the repository at all, and test how useful it is. And if that works, delete the repository and try again.
Re:Now, there's the right message (Score:2)
So git allows people to commit to and checkout from the repository with no access to it. That is indeed impressive technology. We need a web to git gateway then so I can cancel my ISP connection.
There's no reason you can't mirror an SVN repository locally, then generate a diff for submission later.
Re:Now, there's the right message (Score:2)
Re:Now, there's the right message (Score:3)
afaict the basic story goes as follows.
linus fought off version control and in doing so painted himself into a corner.
bitkeeper came along and exploited that corner to get linus to use it.
linus was forciblly stopped from using bitkeeper and made a crude but workable version control system that suited his way of working based on his experia
Re:Now, there's the right message (Score:2)
That was exactly the argument against using it in the first place. With proprietary closed source software that is the risk. It's unfortuate that one of the most respected GPL'd projects out there went down this path. On the other hand, it gives us something to point to the next time..
X11 Binary only video drivers are a similar situation. They seem okay now (to some people), but later when nVidia decides they aren't supporting older chipsets to get
Re:Now, there's the right message (Score:2)
You would think that if SVN did in fact work fine, that the SVN developers would be the first to be championing it.
Re:Now, there's the right message (Score:2)
Links? Linus got by with basically nothing but tar, gzip, diff, and patch for a long time. I think the fact that many of the developers do use SVN is proof that it can work.
Re:Now, there's the right message (Score:3, Informative)
http://subversion.tigris.org/subversion-linus.htm
Re:Now, there's the right message (Score:2)
Worse. I'm back in University finishing my degree. Thanks.
This quote from that page is more along the lines of what I would consider an ideal:
I've been using SVN myself for a while now, so please excuse me if I'm coming across as a Subversive zealot, I'm really not. I just think its wasteful to write git from scratch, while the current projects just need a bit of twe
One thing I'm a bit confused about... (Score:5, Interesting)
Making it stable... (Score:2, Insightful)
at least subsystem by subsystem,
for a couple of months and perform
a deep code review (ala OpenBSD)
for bug hunting and security analysis.
I can understand that some part of the kernel
still needs heavy development
(ReiserFS, VM, some specific broken drivers),
but other parts should be revised
and certified gold bug free.
At least that would give us a roadmap,
on what is to be fixed before
they jump to 2.7.x series.
I mean what's the point to break stuff
at every
Re:Making it stable... (Score:2)
For servers none of those should be an issue at all.
Re:Making it stable... (Score:2)
If that were true, I wouldn't have to have a Promise IDE card to be able to use my CD drive. It used to work... but now using the SATA and PATA ports at the same time is impossible with Linux.
Re:Making it stable... (Score:5, Funny)
for us to read and do not
try and write haikus.
Re:Making it stable... (Score:3, Interesting)
still needs heavy development
(ReiserFS, VM,
Speaking of VMs, I'm a little confused about the topic. Can anyone direct me to some good material that explains the differences between various VM systems? Specifically, I'm concerned about overcommitting memory and the OOM killer in linux. Do any other OSes have an OOM killer? Why or why not? If an OS overcommits memory, how can it not have an OOM killer? Does setting "vm.overcommit_memory = 2" disable the OOM k
Re:One thing I'm a bit confused about... (Score:3, Informative)
The downside is that 2.6 kernels are now a regression-fest that makes Windows look positively stable. They claim distros are able to stabalize their own kernels, which is a theory I have yet to see put into practice. The idea now is to find a kernel version that doesn't have any show-stopper regressions for your hardware.
Re:One thing I'm a bit confused about... (Score:3)
I for one think that it's all a good idea: instead of backporting features (from devel to stable, or stable to old stable), we're simply back-porting bugfixes applied to mainline to
Re:One thing I'm a bit confused about... (Score:2)
Correct me if I'm wrong, but I don't see the problem.
Re:One thing I'm a bit confused about... (Score:2, Troll)
Unfortunately you can't update to a new release to fix the bugs you have, because every new version is so riddled with regressions that it's just as bad as the last one. Bugs are replaced, not fixed.
Re:One thing I'm a bit confused about... (Score:3, Insightful)
Re:One thing I'm a bit confused about... (Score:2)
Re:One thing I'm a bit confused about... (Score:2)
I don't know when, but the reason was this: Instead of having a 2.6 and 2.7 branch, they wanted to be able to accelerate integration of new developments. So the 2.6 series is under heavier development, and sometimes requires very minor bugfixes and such. Those go in the fourth part of the version number. I personally like this strategy since it means you can still rely on stable versions when you need them, but you also get to use nifty new features without waiting years for the development branch to be
Re:One thing I'm a bit confused about... (Score:4, Interesting)
The central problem was that series progressed from unstable to stable to obsolescent to non-functioning. The solution is to always have a place for unstable features (the -mm series) and a place for stable features (the mainline series), and features move into the stable series as they become stable, rather than requiring a major upheaval and years of fussing. Then there needs to be something that corresponds to the period where mistakes in a release are fixed in a release that doesn't include anything else, even new features which are extensively tested; this is only useful until there are no known regressions in the next version with added features.
The reason that the numbering changed is that, were the numbering maintained, the recent releases would now be 2.16.11, 2.18.0, and 2.19.0 (assuming that the new system was adopted at 2.6.6, the old numbering would make what was 2.6.7 into 2.8.0, and so forth, replacing one point release with two minors, which would just be silly). Also, it would be confusing if 2.17.x included stuff that wasn't in 2.18.0, was in 2.19.0, and was in 2.20.0; this is what happens to anything that's still in testing when a release is made and then stabilizes. Since there's always stuff in testing, no stable release could ever be made without having the existance of features be confusingly non-continguous.
In any case, 2.6.x.y is now about as stable as 2.4.x was during the period before distros started moving to 2.6.
x86_64 ctl32 removed (Score:3, Informative)
Poor Linus (Score:5, Interesting)
Linus is our Family Tech Support Guy! (Score:5, Funny)
It seems today
that all we see
is Longhorn delayed
and OS X on PeeCees
but where's the free and open source
on which we used to rely?
Luckily there's our Family Tech Support Guy,
the guy who makes the kernel
that runs on all the hardware
we bought at Fry's.
He's
our
Family
Tech
Support
Guy!
Hmm. Sorry. I got carried away
Thanks Linus for all your hard work!
Re:Poor Linus (Score:2)
borked (Score:3, Interesting)
2.6.13 (Score:5, Informative)
In the meantime, there are a lot of valuable, interesting and worthwhile projects that aren't in ANY of the patchsets at this point in time. I e-mailed a few of the maintainers about that, and it appears that they're aware of the problem but want general users to pressure the patch maintainers to publish patches on the kernel mailing list AND that said patches should conform to the kernel programming style.
So, again, if you want updated drivers for RAID, or additional features you know damn well exist and are out there, lobby the maintainers until they publish the stuff in a way the core kernel maintainers like.
There is simply far too much good stuff out there that is not being seen and not being used. It has got to the point where I will be reviving my own FOLK patch series, to start documenting the patches that live out on the fringes of kernelspace. If we want a better Linux, all we have to do is ask in a way that will be heard.
Re:2.6.13 (Score:2)
For as long as people believe that what they see is all there is, there will be no pressure on anyone to change what they see.
Re:2.6.13 (Score:2)
What's wrong with that? Do you want it to become an even bigger mess?
Re:2.6.13 (Score:3, Insightful)
It sounds like a worse situation than it is: it can depend on your perspective. There are often patches that float around and never get integrated but usually there's a good reason for that (code quality sucks, minimal testing, breaks other stuff, not conforming to kernel coding style).
Speaking of Kernel Coding Style, are you claiming that this is unimportant? Do you understand the concept that once a piece of code makes it into Linux then it's supposed to be ma
Re:borked (Score:2)
Switch to Linux (Score:5, Funny)
We were negotiating with the Pentagon.
We had a blue screen of death.
That was the last straw.
When you're holding the moon for ransom, you value stability in an application.
Linux gives us the power we need to crush those who oppose us.
It's compatible with our orbiting brain lasers.
I've got a beowolf cluster of atomic supermen.
I have more friends now.
Genetically engineered cybergoats.
Henchmen with bad teeth.
Georgous fembots with a penchant for evil.
I mean Linux runs on anything.
I'm all about open source.
It's just changed my love life.
You have to uh.. config it.
Uh.. and then you have to write some shell scripts.
Update your RPMs.
You have to partition your drives... and patch your kernel.
Compile your binaries.
Check your version dependencies... probably do that once or twice.
It's just so easy and so simple, I don't see why most people don't run Linux.
Thank god they don't, because they'd all be super villans, wouldn't they?
Huh uh ha!
I'm Steve, and I'm a super villian.
Re:Switch to Linux (Score:4, Funny)
Uh.. and then you have to write some shell scripts.
Update your RPMs.
You have to partition your drives... and patch your kernel.
Compile your binaries.
Check your version dependencies... probably do that once or twice.
It's just so easy and so simple, I don't see why most people don't run Linux.
Thank god they don't, because they'd all be super villans, wouldn't they?
Huh uh ha!
I'm Steve, and I'm a super villian.
So, Ballmer, What's up?
Re:Switch to Linux (Score:2)
I am all for shell scripting and manual setup (I once built my own live CD from scratch as a way for studying for the LPIC-2) but these are optional these days....
.. and here's the original animation (Score:2)
Re:.. and here's the original animation (Score:2)
Somewhat OT but... (Score:2)
human readable summary (Score:2)
Re:human readable summary (Score:2)
That should be present on every major release.
Re:human readable summary (Score:2)
If you're bothering to compile your own kernels, etc - you should be on the kernel digest mailing list.
smash
I will be ready for dual kernel machine with my (Score:2)
Sincerfely, Rob
CPU-FREQ changes (Score:3, Informative)
* New governor 'Conservative' based on 'ondemand', except that it increases cpu freq step-by-step, instead of switching directly to the highest freq. This should improve battery time and address latency problems on amd64 systems.
* Improved support for PPC32 and ARM
* Support for dual-core opterons
One Change I Like (Score:3, Informative)
Xen (Score:2)
Reiser4 (Score:2, Interesting)
Re:Linux+OpenSolaris (Score:5, Interesting)
Short answer: No, and no.
Longer answer, while there are a few places Solaris still has an advantage, you can't just rip code out of one and stick it another. The structure of the code is quite different, so an implementation in one codebase just won't transfer to another cleanly.
And two, the CDDL, besides being horridly written, is clearly and intentionally not GPL compatible, so even if you could transplant code like that technically, it wouldn't work legally.
Re:Linux+OpenSolaris (Score:2)
If you're going to be a rude asshole, at least make sure that what you say is actually correct.
Re:Linux+OpenSolaris (Score:2)
otoh with say kernel code the kernels are often so different in structure that its not such a big issue as only the general ideas and not any of the details will be able t
Re:Linux+OpenSolaris (Score:2)
Re:Linux+OpenSolaris (Score:2)
On the first day of release, people who contribute to the Linux kernel start looking through the Solaris kernel. What the FUCK are they thinking?
Re:Wow! (Score:3, Funny)
Re:Wow! (Score:2)
Actually GNU HURD... (Score:2)
http://lists.debian.org/debian-hurd/2005/05/msg00
Re:You're Fired (Score:4, Interesting)
That being said, Linus *has* given a reason why there's no full changelog this *one* time (it's reproduced right above in this very Slashdot discussion, for example); if anyone has issues with that, I assume they're more than welcome to create a full one and post that. If noone does... well, then the itch probably wasn't worth scratching after all.
So there. If it really matters to you, then go and create a full changelog. If it's not worth your time and effort, why do you complain that Linus feels the same way?