Linux Kernel 2.6.6 Released
maradong writes "The new Linux Kernel 2.6.6 has been released just 2 hours ago. The Patch from version 2.6.5 to 2.6.6, which can be downloaded on kernel.org measures 2.4MiB and the Changelog can be found at the known place."
Wow, this is the first time I see a Slashdot news using the right unit, i.e. MiB = Mebibytes = 2^20 bytes = 1 048 576 bytes, as opposed to MB = Megabytes = 10^6 bytes = 1 000 000 bytes.
Congrats !
theefer
Note that this breaks the loading of Nvidia modules.
Rather annoying since Nvidia knew this issue was coming.
The fix is to back a patch out, but it's a bad idea.
Stay at 2.6.5 if you use Nvidias drivers, for now.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
KernelTrap has more information about the 2.6.6 release. Looks like lots of good stuff was merged! Laptop mode, CFQ, ...
Check out the now merged laptop mode. Allows you to really save that battery. It is also good on my home server that uses hostap - there is not too much to write on disk, so I'll set the timeout to something like once a week...
A definite must for laptop users that want a little more operating hours from their batteries.
This is not as much bugfixing as it is improving the kernel.
Like writing better code, better memoryhandling, adding new features, improved hardwaresupport and the like.
And unlike Windows Update, you don't have to update the kernel if you don't want to. Very little software do require specific kernel-versions, as opposed to Microsoft where almost everything seems to have kernel tie-ins.
Hope this answers your question.
Not Buzzword 2.0 compliant. Please speak english.
Every piece of software gets updates as bugs get squashed and new features added. The gripe with windows is that the updates don't come as often and they often break other things, so your system can be vulnerable for long periods of time. Also, Microsoft has been known to ignore critical errors, while linux problems generally get fixed very quickly.
The big difference is in the development process, so you can see what exactly is changing, you can fix things that break your system (for example, the nvidia problem somebody mentioned already) and you can choose between different kernels (more feature-rich, more stable, or more performance-oriented) maintained by different people. You don't get this freedom with closed-source software.
The difference is that when a bug is found in the Linux kernel, its usually patched within a couple of weeks or so.
When a bug is found in Windows, it can take months for a patch to be released...if ever.
Anybody with an intelligence level higher than a rock will tell you there is no such thing as a bug-free OS. The difference is in how fast those bugs are fixed.
I want a new quote. One that won't spill. One that don't cost too much. Or come in a pill.
Long story:
... whatever
:-)
this is just the kernel + drivers/modules, distributions (RH/Suse/Mandrake/Debian) use this as part of there distribution just like any other piece of software (GIMP/KDE/whatever).
So if they bring out a new version of there distribution, you could compare that with an update/upgrade from Microsoft (they all package it for the 'end-user').
the Linux kernel is not for most end-users, only for developers (who might need something specific) or system-administrators that need more control over exactly what driver-version they want to use or something.
You can best compare it with, if you can go in to Microsoft's own SourceSafe (or whatever they use) archive and take out there very latest version (because in Linux this is all open) to make your own
Well, I hope this is a clear description.
New things are always on the horizon
If you're a new user or an end user, you shouldn't concern yourself with vanilla kernel updates. Your distro should provide hot patches like MS Update on some kind of a regular basis. As for how different that MS Update that is, it's not, a code fix is a code fix, regardless of your platform. There's nothing really wrong with this since MS Update is actually a decent patching facility.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
Can't help you on the build time, but this will save you time on the download, seeing as you already have the 2.6.5 source;
http://kernel.org/pub/linux/kernel/v2.6/
patch-2.6.6.bz2 09-May-2004 20:18 2.4M
Hrm, according to this MiB and its bastard relatives have made it into valid SI units.
Why are we letting vendors of hard disks re-scale the units of measurement so that their products appear larger by having bigger numbers on the box, its madness.
Personally I think we should redefine an inch as half a centimeter so we can all go out and score bigtime tonite.
It'll only break if you choose the new CONFIG_4KSTACKS option (use 4Kb for kernel stacks instead of 8Kb under the Kernel hacking menu of menuconfig). Leave that option unchecked and it should work just fine (I'm using 2.6.6-rc3-mm1 right now with NVIDIA's driver).
Last week someone from nVidia finally stepped up to the plate on lkml and told us all the real problem with the apic hangs. They'd told the BIOS writers long ago, but from what I can tell, only Shuttle had done anything about it. So they finally released the same info to the Linux community.
Hours after the information was released, the first patch followed. A little feedback and tweaking, and it's into the mainline kernel in less than a week. Kudos to Ross Dickson, et al, for all the work they'd done trying to fix this problem, prior to the official informatino release.
Does anyone know if the patch for either forceDeth or the 3com 2nd adapter on some nForce2 boards is in the mainline kernel, yet?
The living have better things to do than to continue hating the dead.
Aha, mine also stopped working in 2.6.6-rcX.
/dev/input/mouse0 and hit the wheel, maybe you're missing some modules. Check you have: ohci_hcd, ehci_hcd, uhci_hcd, usbmouse and usbhid.
I had to set the type as ExplorerPS/2 in XF86Config (was IMPS/2 before).
Although, you should see something when you cat
You should read you own links:
It is important to recognize that the new prefixes for binary multiples are not part of the International System of Units (SI), the modern metric system.
...
Faced with this reality, the IEEE Standards Board decided that IEEE standards will use the conventional, internationally adopted, definitions of the SI prefixes. Mega will mean 1 000 000, except that the base-two definition may be used (if such usage is explicitly pointed out on a case-by-case basis) until such time that prefixes for binary multiples are adopted by an appropriate standards body.
Hopefully, it will remain that no "appropriate standards body" adopts this ridiculous notation!
kernel.org seems slashdotted from here. Good job direct-linking to it in the story.
Mirror to the rescue!
http://wuarchive.wustl.edu/pub/linux/kernel/v2.6
Errrm, the kernel numbering scheme doesn't work on a "Oh crap, we hit x.y.9, next rev is x.y+1.0!" scheme. The third number has no ceiling; theoretically, we could see 2.6.159, if there was any reason to continue the 2.6.x kernel out that far.
2.4 is hovering in the low 20's as far as minor rev. number at this point.
I wish I had a kryptonite cross, because then you could keep Dracula and Superman away.
Is it just me or is the pace of kernel releases accelerating dramatically. Just a quick look at the number, 2.6.6 seems to indicate that we are now 3/5 through the lifespan of the 2.6 kernel.
.17 or .18).
Version numbers are not usually decimal, they're usually a sequence of arbitrary dot-separated integers - don't think of decimal fractions, think of books with chapter 1, section 1.2, subsection 1.2.34, paragraph 1.2.34.5 (this scheme is common in maths and computer science textbooks).
Linux 2.4 is up to 2.4.26, 2.2 is up to 2.2.20ish, and I'm sure 2.6 will go well into the 20s too. (Updates are also more frequent in the early stages of a release kernel - I seem to remember 2.4 settled down to infrequent, minor updates somewhere around
Perl version numbers used to be written in decimal (for a long time the current version was 5.00503), but have moved to a more conventional numbering scheme where that would be written as 5.5.3.
As for the frequency of updates: the line I've heard is that the dev kernels (2.odd.x) are alpha versions for developer use, and the "stable" kernels (2.even.x) are beta versions for public testing. If you want something that's "release quality", pick a reliable and non-bleeding-edge distribution and use their release kernels instead (I believe Debian stable currently runs heavily security-patched versions of either 2.4.17, 2.4.18 or 2.2.20, depending on CPU architecture - any of these are fine, as long as they support your hardware).
I have found that KernelTrap often discusses things in language I can understand, and then it should be quite accessible to many more than kernel hackers... :-)
Employee of Inrupt, Project Release Manager and Community Manager for Solid
In telecommunications, it is standard practice to use 10-based prefixes. 10Mbps means 10^6 bits per second, and 56 kb/s means 56000 bits per second. In serial communications, it is normal to use a startbit and a stopbit ber byte, so you use effectively 10 bits to transmit one byte.
BTW, I've seen 56kbps modems working at 44 and even 48 kbps. The speed you get depends on the quality of the phone line. Also remember that those modems work assymetrically: the 56 kbps is only downstream. Upstream is the same speed as a 33k modem.
This sig under construction. Please check back later.
I wouldn't go that far. Not entirely.
I'd say you had a point saying that noone wants these changes. I certinaly don't want or particularly like them. But I can see that if they aren't needed, it's not for much longer.
They aren't "more correct" and they aren't "better". But what they are is clearer. And, like it or not, it's getting to a point where that clarity is needed.
Firstly there's the two types of manufacturer. For whatever reason the HDD manufacturers prefer to use the 10^n meanings. Maybe it's so that they can swipe more money on misleading advertising. Maybe it's some sort of tradition. Maybe it's both - a tradition that just so happens to benefit them. But they're not going to chance.
For memory-manufacturers the reason is clear. When dealing in binary (and unless something happened overnight, memory is still working on digital signals) then you can only really work to the power of two. So they're going to continue using the 2^10n notation.
Secondly you get everyone else. Whether professionals in other disciplines, or merely Joe Average taught in school (or whatever) that kilofoo is always 1000 foo, and megafoo is always 1000000 foo, they're going to have assumptions about what the prefix means that in any other context would be right but in this case would (or may... - damn HDD labels) be wrong.
And even then, if you need to refer to "one thousand bytes" then how else could you shorten it?
Back when computers where still specialist then it wasn't too much of a problem. But now computers are so prevalent that the potential for confusion is too high.
I'd love to get everyone else to change. To me "one megabyte" is "1024 x 1024 bytes" and always will be. But getting every other SI prefix to change to make way for one is unlikely.
Personally I don't "read" KiB/MiB/whatever any differently. My brain still "hears" it as kilo-/mega- or whatever. Probably always will - those "bibibibibi" bits trip me up. But when I see it (or even write it) I know with 100% certainty that the 2^10n is meant (often mentally interpreting it as "binary megabytes" or whatever...). If it's not there, I always wonder. On products it oftenleaves me always searching for the small print to be totally certain of what is meant.
Like it or not, the confusion is there. And something has to be done to reduce it. And, unfortunately, we're the ones in the minority side of the prefix-usage.
Tell that to the hard-drive manufacturers.
TiggsThey don't accept it, or use in in the industry. They may be wrong, but unfortunately they're not exactly helping things any. It means it's a part of the ocmputing industry that's muddying up the waters internally.
Tiggs
"120 chars should be enough for everyone..."
less /proc/config.gz | grep 4KSTACKS
CONFIG_4KSTACKS=y
glxinfo | grep direct
direct rendering: Yes
direct rendering: Yes
Working just dandy here. Using the nVidia 5336 drivers.
Blech. Bad formatting/sentence structure. Let me try that again, without HTML formatting.
> Just out of curiosity, what's it going to take to get to kernel version 3.0? Honestly, what changes, additions, etc have to be incorporated until they call it Kernel 3.0?
An ABI change.
The main argument against the numbering of the 2.6 kernel as 3.0 as I understand it was that, while the change from major version 1 (1.x) to major version 2 (2.x) of the Linux kernel involved a change in the ABI (Linux 1.x used A.OUT binaries, 2.x uses ELF binaries), the transition between 2.4 and 2.6 did not.
Since 2.4.x and the new kernel version were binary-compatible, they decided not to name it 3.x despite the major architectural changes and improvements that had been made.
You can just download the 2.6.5->2.6.6 patch and apply only those parts that you want. Or, better, you can find the interesting bits in the Changelog, and use bitkeeper to get the relevant changesets.
Although some frames get skipped from time to time (under heavy load), my bt848 is doing fine since the early 2.6.0-testX series...
I think they should make a short version of the change log with a summery of what changed. Does anybody know of such a thing?
KernelTrap.org is fairly close to what you're asking.
Treehugger? Treehugger... Treehugger!
Look it's very simple. Bytes are measured in base-2 units, everything else is base-10.
It's bits (small 'b'), so it's 100 x 10^6 bits per second. Which is also 12.5 Million bytes per second, or roughly 11.9MBps.
It's bytes (capital 'B'), so that's 100 x 2^10 bytes per second.
Getting a little silly now. That's 1 x 10^9 Hz (cycles per second).
Ah, this is where all the supposed controversy comes from. The hard drive manufacturers want to use base-10 units so that their drives sound larger than they really are. Everywhere else, base-2 units are used for measurements of bytes (including your file browser).
The only two problems I can see is hard disk manufacturers wanting their drives to sound larger, and marketroids getting the capitalization wrong (bits/Bytes, milli/Mega, ...). None of that is the fault of the units/suffixes, the people who made them, or the people using them. Get over it.