Slashdot Mirror
Kernels Galore
Linus has blessed what could very well be the last kernel in the 2.0 series, 2.0.38. The small patch fixes a dangerous TCP/IP bug, and two other small bugs. Please use a local mirror (ftp.us.kernel.org for us folks in the US). Update: 08/26 07:25 by J : It seems that 2.2.12 and 2.3.15 have also been blessed by the holy penguin pee :)
What? Ya'll said the same thing about 2.0.37! That it would be the last. So I suppose we'll finally see the last one at 2.0.69 eh? ;-) By then we'll have 2.8.32 as well.
Read BugTraq's technical discussion.
Add BugTraq to your bookmarks:a ded=1
http://www.sec urityfocus.com/templates/archive.pike?list=1&thre
Alan Cox seems to be implying the bug was deliberately re-introduced (by him?) into 2.0.35 because the fix caused compatibility problems. It was fixed in earlier kernels.
Alan Cox wrote 6th August in the Linux kernel mailing list:
> So, the version of my patch for 2.0.34 didn't need to fix this any
> more. Of course, future updates of the patch I was making based on
> the latest one, and never bothered to check for this bug again.
>
> Now, after your post, I am looking at patch-2.0.35.gz:
>
> - return 0;
> + return 1;
>
> So, the "feature" got re-introduced in 2.0.35. I don't know of the
> reason for this. I can only guess that the other major TCP changes
It was put back into 2.0.35 because the "fix" caused interoperability
problems with many other stacks.
Alan
A good Torvalds quote is, "backward compatibility eventually goes away, while forward compatability does not."
This was kind of a humorous read. Before spouting off about /dev/cua*, read the history about it. a) notice of /dev/cua deprecation was given in several years ago, 2.0 listed it as deprecated. b) /dev/ttyS* has been around since point a. c) bloat is not acceptable, if you think it is, go back to m$ land. d) your kernel issued warnings about using /dev/cua* devices. why didn't you pay attention? e) get the real reason why things are changed in the kernel before ranting. Blu3
Perhaps greater priority could be given to retaining compatibility between kernel releases even if there are apparently wonderful reasons for someone wanting to write this or that new feature which breaks existing packages. I agree there will be benefits for many in adding new features to future kernels, but I do not accept the scale of incompatibility in 2.2 was strictly necessary. As the installed base of Linux grows and the typical user profile changes from the early Linux days, it will get harder and harder for kernels with incompatible changes to be widely adopted. Addition rather than substitution should be the developers' guideline even at the expense of bloat.
One example of the incompatibilities in 2.2 kernels with 2.0 kernels is the change in serial devices which dropped support for the long used /dev/cua* in 2.0 and all earlier kernels and enforced the new /dev/ttyS* introduced in 2.2. Needless to say this change breaks existing FAX and modem software requiring upgrades.
Linux users are lemmings collectively jumping off of the cliff of reliable, well-engineered commercial software.
2.2.12? where where? =))
---
If my business depended upon a machine that was already running a working kernel, why would I install a newer one? Your anecdote wouldn't convince me it was safe, even if I wanted to.
The latest often turns out not to be the greatest. It's best not to discover this first hand with something important.
Mind the Gap
From my memory of AC's diary, it was some sort of leak in the TCP stack which caused things to blow up after a little while.
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
I got confused and thought 2.2.12.pre*. Sorry.
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
Well, 2.0.x was, until recently, the current stable tree. It's arguable that it still is, although 2.2.x seems to have finally gotten decent.
(before you flame me, yes, I realize that the 2.2.x tree is labeled "stable," and is officially has been considered the latest stable tree ever since 2.2.0 was released, but that's because the "stable" label is somewhat of a misnomer. "Not as buggy as 2.1.x, but not stable either" is what i'd consider it. 2.0.x is still the stable tree. Perhaps around now i'd consider moving to 2.2.x, but not 6 months ago.)
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
For a bug that cmdrtaco considers dangerous, this isn't the type of fast patching I'd expect. I always hear bragging that Linux fixes bugs in a few days of their discovery.
According to the bugtraq post about the bug, the discoverer contacted kernel developers in May. That was three months ago. After receiving little response, he posted to Bugtraq on July 31. Now, nearly a month later, the bug finally gets fixed.
Three month turn-around times for important bugfixes doesn't seem like anything to brag about.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Linus has been a busy boy tonight, following the release of 2.0.38 with a large patch for 2.3.15 with lots of changes that managed to crash my machine the first time I tried to check my mail with it (back to 2.3.15-pre1 until I can test it :) and then a 2.2.12 release, which I haven't looked at yet.
Posted by Synsthe:
They truly are anonymous cowards.
This will get moderated down I'm almost positive, but somebody has to say it; anonymous posting is a big reason why slashdot is such a pavillion for flamers, lusers, and lamers, this particular news item being a classic example.
Who wants to bet the guy who got moderated a 5 for being a troll moderated himself up or had a luser buddy do it? Don't try and tell me he can't moderate himself up, if he posted anon than logged in, he very well could.
Who else wants to make a bet that half the lusers in here bashing Linux for no good reason (other than perhaps fear?) are probably mostly the same people just posting repeatedly as AC's?
Get over yourselves kids. Mommy and Daddy didn't give you access to the computer so you could practice being an immature brat, I'm pretty sure they hoped you would learn a thing or two.
Rant over, back to the topic at hand, atleast marginally.. =) The release of 2.0.38 doesn't affect anybody, so why the huge outcry? If you're using 2.2.x and happy with it, than good for you, but there are some who like to remain with kernel trees they've used for a length of time, and trust.
The argument remains that it's silly to shoot up to the latest, simply for the fact that it's the latest. This is a problem you have with Windows, you can't shop around and find something that's good for your system, you're given a release every year or few and that's that. You're stuck with it, no questions asked.
--
Mark Waterous (mark@projectlinux.org)
I haven't had a problem with it as a desktop or as an nfs client. As a server I haven't had crashes on 2 production servers and 1 development server under 2.2.5-22, redhat's last production patched kernel, I believe.
Also, if you read the choices next to the "preview" button when you submit a comment, you'll notice the "extrans" option. You'll like it.
== Just my opinion(s)
Well, alot changed 2.0>2.2, if I were running a production server, I likely would not have switched to 2.2 until about now, if that (given that 2.2.6-9 or so may have had some nasty bugs). People who need uptime tend to be very conservative, and for good reason.
Yes, if you needed some of the new features, sure, you might have upgraded, but not otherwise.
Plato seems wrong to me today
Suppose: /dev/cua0 and /dev/ttyS0 point to the same device. Your pppd uses /dev/cua0 and lock file /var/lock/LCK..cua0. You accidentally start minicom on /dev/ttyS0. Seeing no lock file /var/lock/LCK..ttyS0 in place, it happily trounces your ppp connetion.
This is why symbolic links such as /dev/modem are bad too. If a program doesn't test for a link then it will pick the incorrect lock file.
As was indicated previously, the 2.0 kernels are naturally going to be more stable (developmentally) than the 2.2 kernels. That much should be obvious... the 2.0 kernel is essentially considered "finished", and is only improved when major problems are discovered. This isn't happening very often, which is one large reason we're now at 2.2. What makes you think your 2.2.10 kernel isn't going to desperately need an upgrade day after tomorrow? Don't you think it's less likely that someone's 2.0.38 kernel will?
As Linus stated at a LinuxWorld, he actually suggests that if people have 2.0 running nicely, to stay with it. He said 2.2 is not needed to run a nice fast system.
--
Scott Miga
This is one of the strengths of Linux - unlike commercial Unices, in which products are marked as "End of Life" and abandoned, there is no reason to give up an older version of Linux if it still performs the required task.
--Gus
There are all sort of people running linux. You be amazed at the number of people running 1.2.x . 2.0.x has been around a long time. Nearly every bug in has been squashed. On a single proccessor machine it just works. SMP system have a few issues.
The 2.2.x line until just resently was mildly buggy. It work great for most things, and a majority of hardware. 2.2.5 and 2.2.7 were good if you had the right patches 2.2.8-10 had problems with file system corruption.
Then of course there is NFS. 2.0.x did a number of things wrong. 2.2.x fixed a number things and added features like file locking. Of course if your clients are broken the same matter as the server fixing the server can break everything.
The problem with any piece of software is that your users do thing you'd never every thought of. What works great for you is worthless for them. Early stable releases are just massive beta tests. Of course unlike NT you can get the problems fixed quickly.
IANALBIPOOGL (I am not a Lawyer, but I play one on GrokLaw.)
"No", the patches are not cumulative, "yes," you'll need to get and apply all the intermediate patches in order.
Berlin-- http://www.berlin-consortium.org
DNA just wants to be free...
go there.
And on that note, why isn't anyone working on 1.2 anymore? :-)
... and today's pet project has
Check out edge.kernelnotes.org for Myrdraal's kernel patch summaries (but it usually takes a couple of days for him to get the newest ones up). Otherwise, look through the source...
I guess this is as good a time as any to ask this question:
Are the patches cummulative? If I upgrade from 2.2.5 to 2.2.15 (or whatever the latest is), will I get all the fixes in-between?
In a related question, if they are not commulative, do I need to install all the patches in-between if I want a fix in 2.2.15 and I'm running 2.2.5?
Je ne parle pas francais.
"I want to use software that doesn't suck." - ESR
"All software that isn't free sucks." - RMS
I have heard that the mirrors are full. No wonder 2.2.12 should fix a few bugs. I'l look for the change log to appear, then wait to get it if I need it. So far 2.2.11 is working okay. Now if I can only get some of my other apps to behave as well.
Only 'flamers' flame!
Why not? I like to fix things! Plus, I keep the older working kernel for a few weeks just in case I have to revert... zat bad?
"And why does PPP require the novj flag?"
Not sure:
I'm using it because I upgraded to 2.2 when I got a new machine with a decent (56k) modem, and without "novj" I'd only get 2-3 kb/sec, but disabling vj gets me the proper 4-5 kb/sec.
I had however thought it was to do with the service provider I use, whose servers can't handle vj compression at the higher speeds (I know others at the same ISP who've had the same problem).
Thing is, I'd have thought the same problem exists with whatever kernel as it's not a problem on my side.
Funny really, with all the problems I heard about with 2.2.11 my linux box was happy as a little duckie in a pond, it did yoyo impersonations with 2.2.10. Just lucky I suppose :-)
Let's see what 2.2.12 does...
When 2.0.x was in the lower numbers I used to update every couple of kernel releases. On the 2.2.x tree, the "release often" principle seems to have got a bit too overwhelming, and from the rapidity of the changes I haven't been convinced of 2.2.x stability.
:-)
Moving from 2.0.x to 2.2.x seems to require changing a number of other products.
Both my machines are running 2.0.x (x=36) and to be quite honest I can't be bothered to fix something that isn't broken.
I may go up to 2.2.x soon, as the changes are starting to look a little less major/ catastrophic, but I think I'll keep at least one removeable HDD with 2.0.x for old times sake/emergencies
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
I personally have not had a problem using NFS
from, on, or between 2.2.* (2.2.1, 2.2.5, 2.2.10,
2.2.11) boxen. However, you might be right and
there might be a bug.
PLEASE PLEASE PLEASE
Do us a favor and submit a bug report to the
kernel developers (if it appears to be a kernel
bug), or to the NFS developers if it is strictly
a user-space problem.
It won't get fixed if they don't know about it,
and they might not read your post here. One of
the great things about open source is peer
review -- but implied in peer review is the
reporting of the bugs found.
TIA
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
So how different is that considering today's technically inept users?
Windows is hard enough to use (or the users ignorant enough) that I earn enough to pay my tuition working 15 hours a week doing lame windows installs.
Immagine the standard Windows 95 install. Anyone who can figure that out might as well be able to take 5 minutes to read a little bit of help documentation that tells them how to compile (or what buttons to push to have their distribution do it for them).
Got another desparate point to make?
I beg to differ. I cannot move to 2.2.x because specifically NFS Client Locking does not work against SCO Unix servers anymore. It is indeed broken. I have seen similar reports against DEC and Sun NFS servers. If I don't lock anything, it works GREAT! I use it for CD's and user directories. I tried it between 2 linux boxes and it did not work. One had 2.2.10 and the other 2.2.11... (I forget which one was the client and which the server, but you get the point)
I truly hope it gets fixed in the 2.4 series! I love Linux!
FreeBSD? Even though it is NOT commercial, it is reliable and well-engineered.
Ricardo da Silva Lima
>1. Linux has bugs, contrary to the FUD often >spread here on slashdot.
:(
:()
;)
/. or who play with it on occasion, etc.
Are you honestly claiming that previous to this article, you believed that Linux had no bugs? What _other_ project has millions of lines of code, and yet has no bugs. The software that control billion dollar space shuttles, military planes etc? No actually these have bugs too.
(Software problems caused a number of problems for the military, i.e. the smart bomb that self-destructed if it did a 180-degree turn, even if it had failed to depart the torpedo tube)
Open Source is quite good for somethings, but it does not perform *miricles*.
The only project this large which does not have any bugs is Windows NT, which even has a "Blue Screen Of Death" to prevent typist from suffering RSI.
I have found that, on the whole, Linux screws-up completely somewhat less often than Windows. If you have found NT reliable, then good for you.
Incidentally FUD means Fear-Uncertainty-Doubt. It does not mean 'Over-Optimism'.
> 2. It sometimes takes a long time >to fix them, once again contrary to the FUD.
I believe *sometimes* is the key word here.
If a bug only produces error on rare circumstances, it can be difficult to find, even assuming it exists. These bugs ofcourse are much less important.
A serious bug in Linux may be fixed in a couple of days. An equivalent bug might take a month in NT. NT has it's advantages, I don't see speed of bug-fixing as being one of them.
_Again_ FUD means Fear-Uncertainty-Doubt. It does not mean 'Over-Optimism'.
>3. No one really seems to care about points 1 and >2.
I don't care so much for my home computer, seeing as I never come across a bug in the Linux-kernel. 2.2.x is more than ok for my use (now if I could say the same for some of my linux apps
However on linux servers, people *do* care. Why do you think that Linus T. said that people should not upgrade unless that actually needed the new features in 2.2. He was pleased that many Linux users had resisted the temptation to upgrade!
Now I can just imagine Mr Gates. "As usual We have notified our customers that our new version of Windows may not be as stable as NT4. We are asking people not to pay for our new upgrade unless they really need our new features. We are looking forward to the lowest sales figures ever for Windows 2000."
I think that I can assure you that people who actually use Linux are more aware of the points 1,2 than your average Windows user, who mostly get their info from "Window XX makes every thing easier, faster, better" ads
N.B. I mean people who actually _USE_ linux, not just post about it on
(Sorry for this rambling post)
We use GNU/SunOS.
So when will 2.2.x have ISAKMP masquerading support? Then I'll upgrade...
[Or maybe it does already and I'm just too foolish to notice it.]
--- Where's my X.400 protocol decoder?
tcfs/cfs seem to help nfs..of course they slow things down some.
either kernel docs or the ppp howto said 2 or 3 years ago that support for /dev/cuaX was being phased out, and that you should use /dev/ttySX instead.
I hope he doesn't either. Then again, it'd be nice if we all didn't get hit by trucks, you know?
but, back _on_topic... I never got to know the 2.0 kernel tree.. I'm very much a newbie to Linux.. been familiar with it for about a year now. (tragic, that's for sure) I just assumed, as one of the other posters did, that onward movement in kernel development was concrete, i.e., no development was made on "past" kernel trees once newer, "stable" ones were established (i.e., the question someone posted as to why the 2.0 tree was important now that we have the 2.2 tree). apparently not, which is fine with me, and I see why now, having read some of the other comments. yay linux!
-my $0.0000000000001 worth-
Insert mind here.
heh. Me too... but 2.2 or 2.4(?) will be on my next machine. It will probably be my first SMP PC! I really should start saving money now for gobs of memory. ;)
Geeky modern art T-shirts
Really.
Will in Seattle
so you don't know what the bug is either.. does anyone know?
How we know is more important than what we know.
So like.. what's this fatal and dangerous TCP/IP bug that we found? How can I brag about how fast we fix stuff in the linux crowd compared to microsoft if they don't tell me what the bug is?
How we know is more important than what we know.
What reliable, well-engineered commercial software? NT?
--
Disinfect the GNU General Public Virus!
Yay, triple kernel trees are almost over.
-awc
Sorry for asking a (possibly) stupid question, but where can I read what has changed from 2.2.11 to 2.2.12?
-- DJ Kat is where it's at
Maybe I'm dumb, but I've looked all over the
web and I can't find any page which summarizes
fixed bugs and new features in kernel versions.
-
Alan Cox posted one for the 2.2.11 kernel on www.kernel.org.uk but is there no page which
does this for every new kernel. Is the only
way to subscribe to kerneldev mailing lists or
read the source code?