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 :)
So much for accusing Microsoft of shipping buggy software!
(Troll not intended, but observation of sad fact that there are major bugs in supposedly stable 2.2.x)
Oh, try accessing an NFS mounted CDROM with a 2.2. Timeouts, retries, failures, and other bugs. Don't even try to export NFS under 2.2 NFS under 2.2 is broken, please fix it in 2.4.
And why does PPP require the novj flag?
And then there was the general rush to publishing a 2.2 release. The new releases have so many bugs, misconfigurations, and other general quality control problems that Win95 seems a downright sane choice.
But other than that, I just luuuuuuuuuv 2.2. Not. Sticking with 2.0 at work, thank you belly much.
And why can't /. auto translate a carriage return?
I've been using Suse 6.1 with a 2.2.5 kernel for nearly 3 months now. I use NFS to mount home directories on all networked workstations and they work fine. I've also used NFS on 2.2.5 to mount CD's and ZIP's etc.
If NFS didn't work on 2.2.5, I'd be shut down. Really cool things when you get finished with it all is the fact that I can logon to any workstation in the network (using NIS & NFS) and that workstation looks exactly like my personal one.
I'm hoping for improved NFS performance, better locking capabilities, and some load balancing/distribution services. (Self I've looked at CODA, but sheesh! What an ordeal. Anybody know of some better stuff?
This is a dual processor compute and file server with 45 GB disk space (IDE and SCSI mixed). 1 AIX and 3 Irix compute servers are saving data to its disks over NFS. At the same time, there are now 5 simulations running and the average number of running jobs are never less than three. This machine is doing its job *very* well. Version 2.0.36 kernel could not handle this. Do I need to say more? well, I do not care. 2.2 works much better for us.
Is there any reason to not fix a known bug? The patch changes only 9 lines of "real" code. (comments + version number not counted)
BTW. Linus appeared LIVE on CNN International here in Europe tonight in the Q&A show. Everybody missed?
Umm.. do a diff on two versions, and you'll see exactly what was changed. If you are on kernel announce mailing list, announcement email lists every file that was changed, and how many lines added/removed. As far as I remember (I only glanced over that email for 3 seconds), there were only a couple tiny changes in a couple of files. Don't even try to compare this to Microsoft, where you get 700k .exe installer and have no clue what dlls are being replaced, much less what exactly was changed.
Debian-stable, for example, still uses the 2.0.x kernel series. Provided the Debian developers aren't convinced of the 2.2 and above series' stability, we'll be using it in the next release of Debian.
2.0.x is rock solid. It doesn't have some of the features that 2.2.x does, but it has uptimes measured in years. 2.4.x looks interesting enough (journalling FS, USB) that it's worth sacrificing some reliability for the new series. I wouldn't be surprised if Debian simply skipped over 2.2.x altogether.
I would have to agree. Actually, I HOPE that Debian skips 2.2.x. I am running 1.2.13 and 2.0.36 and I like the fact that the machines are as likely to just fall over as my fridge or Dodge Cummins. They just run, like a toaster or a blender or a big electric drill or a good air conditioning unit. This is the way it should be, folks. The boxes are always on, always working on something (GIMPS, for instance), and they have been up for more than 18 and 9 months, respectively. When the newer revisions are there, I would love to use them -- I have seen them on similar boxes and they are nice and quick. But they aren't there yet. Debian is all about being all there.
I don't know exactly which release they were introduced in, but /dev/ttyS* has been present in the 2.0.x tree for quite some time (with /dev/cua* being listed as depreciated). It was hardly a sudden, unannounced, recklessly incompatible change.
"It's been deprecated" is not a very useful justification for dropping a feature that is required by many widely used packages. That phrase is usually a sign of egos in motion.
As you might guess, I am no Linux guru, and now that I will probably get flamed for this question, but I thought you linux guys were up to the 2.2 kernel. Are the older kernels still being updated because they are more stable than your newer ones or something? Seems it would be better to spend the time fixing the newer kernels, but what do I know ......
[ b r a p ]
I'm making the general argument for greater compatibility between kernel releases. As the typical user profile of Linux changes there are going to be more people wanting upgrades based on binary rpms which do not break their existing installed software. This trend will make it harder for kernels with incompatibilities to be widely adopted.
This is an example of a general tendency in Linux kernel development towards pedantically changing interfaces even if they are harmless and widely used like /dev/cua*. This particular incompatibility was a matter of taste but it was not a technical necessity.
"you can only be backwards compatible for so long and then you have to cut off the stragglers." This doesn't apply to /dev/cua* because the old serial interface could have been retained indefinitely. You seem to have misunderstood the point made earlier that the decision to drop /dev/cua* from 2.2 was made on grounds of taste not of technical necessity. My main argument is that as the typical user profile of Linux changes, it will get harder for kernels with incompatibilities to be widely adopted. Many Linux users in future won't understand how to recompile packages that get broken by kernel incompatibilities.
Someone else already pointed this out here.
I positively love the way RedHat (and I'm sure, other linux distributors, too) continue releasing errata fixes built for the old versions. It makes me feel very comfortable, when I install a system, that it'll be supported in the long term.
Instead of flocking imeediately to the latest and greatest release, some people are more mindful of software lifecycles and take version numbers seriously. As a result, they realize a few things when compairing 2.2.20 to 2.0.38. First, they can guess that 2.0.38 is going to be less likely to break their existing install than 2.2.20. Second, they can guess that 2.0.38 is likely to be more mature than 2.2.20.
It's a pity you seem intent on being so melodramatic while still misunderstanding the general point I am making. Quoting from an earlier comment: as the typical user profile of Linux changes there are going to be more people wanting upgrades based on binary rpms which do not break their existing installed software. This trend will make it harder for kernels with incompatible changes to be widely adopted. "Do it yourself" is cruelly irrelevant to these users and a disservice to Linux.
2.2.11 is absolutly horrible! Several hours after "upgrading" I noticed the memory was completely full and the machine was swapping like crazy. I found and applied the tcp memory leak patch and rebooted only to come back the next day and find "out of memory" messages plastered all over the console and most daemons killed. The machine was responding to pings and Apache was accepting connections, but not serving files. I rebooted one more time and it happened AGAIN!
The moral of the story: 2.2.x is not a stable kernel but rather a public beta test like 2.3.x. If you need a stable production quality system, use 2.0.x or go with another OS where they really mean stable.
P.S.
The machine in question is a heavily loaded web server and has been running fine for weeks before and days after with 2.2.10. (It needs the SMP support so it has to have 2.2.x.)
Too funny...that has to be about the oldest trick ever.
:)
So what have we learned here today?
1. Linux has bugs, contrary to the FUD often spread here on slashdot.
2. It sometimes takes a long time to fix them, once again contrary to the FUD.
3. No one really seems to care about points 1 and 2.
btw...If it wasn't for ACs slashdot would just be preaching to the pulpit...what would be the point? A typical discussion would be something along the lines of:
---------------
Linux Rules!
Ditto!
Yeah...me too!
I agree, but Linus is God too!
Oh yeah, forgot to mention that!
You also forgot Windows Sucks!
You're right it does!
Hey you're pretty cool!
Yeah, so are you!
---------------
And of course this thread would be moderated up and marked as "Insightful", because no matter how many times someon writes "Linux Rules" or "Windows Sucks" it's insightful.
...and unlike NT you don't pay for the privilege of being a beta tester (snicker ;-)
Well, they're more alpha testers to me.
But like NT (or 98) you are beta tester even if you want to run production quality.
Here's how it works:
You can't moderate on an article to which you've already posted. It is possible for a friend to do so, but normally this sort of abuse gets corrected right away by the other moderators. Since I don't see any "5, Troll" posts right now, I assume this has already occurred.
By the way, looking at one of the replies below, I've often wondered how people manage to reply to the wrong posting and often even the wrong article. How hard is it? You click "Reply", you type, you Submit. Too complicated for some, I guess.
[*] If you were paying attention, you may have noticed that the moderation only goes up to +5. So I don't know how you would get to "5, Troll". Theoretically, "4, Troll" is the best you could do.
Let me just make a comment on the previous post about Linux/Windows with bugs, first of all anyone that has ever developed software knows that all software has got some kind of bugs in it, regardless of how much testing and fixing you do, the more lines of code the more potential for bugs. The difference between bugs beings fixed in Linux and Windows is that with every new service patch release in windows to fix bugs, about a few dozen new bugs are created. I am being 100% serious about this. I am a free lance programmer and have a few inside friends within microsoft. You would be amazed what kind of new problems arize when trying to fix previous problems. With linux, you find a bug, you fix it, and life moves on. It is surprising how many developers at microsoft come home to their linux machine at night, Microsoft does pay them good money, but unfortunatley their product just isnt what it could have been. Dont expect alot from windows 2000 either, great ideas for the OS, but ......... well you get the point.
[ b r a p ]
I've been having very weird problems with 2.2.x kernels. 2.0.35 and even 2.1.110 and 2.1.112 are very stable on the system but 2.2.4 and 2.2.10 and 2.2.11 seems to have random problems with SMP that either lockup the system or cause mysterious reboots. It's getting kind of frustrating.
In my case 2.0.x was well along by the time I moved off of 1.2.x, so I've not even upgraded my 2.0.x kernel that many times (upgraded the distribution just about as often). What can I say, after a while the continuous upgrading starts to get on you, used to be I'd jump on every new release that would come out back in the 0.9x days. Ever since the last SLS distro was released I've been fairly slow to upgrade.
Personally I'm thinking of skipping 2.2.x all together and just going to 2.4.x when it comes out.
Or, let me log in to Slashdot, either. I sure as hell wish I could log in twice consistently, but, I guess these guys are too busy to tend shop now that they're public. ===================== I dnloaded and searched the tcp.c and net/Changes but found no clearly visible reference to what this Nasty TCP fix fixes. If anyone knows (the chnage log hasn't been published, yet), could someone send me mail at van-biteme-@21ccs.com? I still have one relic 2.0.X kernel laying around, and want to know if I have to deal w/ it, yet. The server's too stable to upgrade if I don't need to. Thanks, Van
Didn't see a post for the release notes, but I found them here: http://www.linux.org.uk/VERSION/relnotes.2212.html
Because it's actually not a very important bug. The fact is, TCP can always be spoofed if you have access to the network. This bug made it a little easier to do so even if you weren't controlling the routers, but it's not a big deal-- you're still insecure if you are relying upon TCP to keep your data safe.
Only a secure, encrypted protocol like SSL can guarantee that network data isn't tampered with.
(If this bug was a remote crash, _then_ 3 months would be a big deal)
It's easy for you, me, and perhaps many other knowledgeable Slashdot readers too, to be arrogant by saying that a particular new kernel incompatibility is easy to fix at the command-line e.g. by making a link, and it is thus not a real incompatibility. My point is the typical user profile for Linux is changing to include more people who do not necessarily know or have the time to learn about command lines. This demographic trend will make it harder for new Linux kernels with incompatible changes to be widely adopted. Upgrading your Linux distribution is not a guaranteed solution for new users and upgrading a distribution does not fix incompatibility problems in third-party software packages a user may have installed, or, more likely, had installed by someone else. There are too many third-party Linux applications which do not get upgraded promptly by their maintainers every time new kernel incompatibilities arise.
Upgrading a Linux distribution is not a guaranteed solution for new users and upgrading a distribution does not fix incompatibility problems in third-party software packages -- from outside a distribution -- which a user may have installed, or, more likely, had installed by someone else. There are too many third-party Linux applications which do not get upgraded promptly by their maintainers every time new kernel incompatibilities arise. It would be undesirable if the perception grows among Linux's new "non-technical" users that new distributions/kernels tend break their existing software packages. My suggestion is to place a little more emphasis on retaining compatibility between future kernel releases for the sake of the new "non-technical" users.
Your example illustrates one of the limitations of making user-space file locking mechanisms based on symbolic links act as device locks. One could deprecate /dev/ttyS0 because /dev/cua* was in Unix first.
Yes, /dev/ttySx can be used instead of /dev/cuax but this fact is unlikely to be obvious, or even meaningful, to Linux's new "non-technical" users who, unlike knowledgeable users like you, me and others on Slashdot, do not know about or have time to learn the device names and command line usage in Linux.
Linux's new "non-technical" users may not even know what recompilation is. There are plenty of useful ready-packaged applications available on the Internet for Linux that are not provided within Linux distributions and which don't get updated promptly by their current maintainers, if any, when a new kernel release breaks something. In such cases, upgrading the Linux distribution won't help a non-technical user.
A reference to the full information you seek has already been posted in another comment in this thread. If you go back and read the rest of this thread, you will find a reference to BugTraq.
Yes, creating a soft or hard symbolic link would make broken software work again but this fact is unlikely to be obvious, or even meaningful, to Linux's new "non-technical" users who, unlike knowledgeable Linux users like you, me and others on Slashdot, do not know and do not have time to learn the device names and command line usage in Linux.
With a few more people as humble and helpful as you, it might be possible afterall that Windows users could be completely put off using Linux. Remember, calling other people stupid in public makes you look clever!
Don't laugh too hard because your "insightful" detritus completely missed my main point. BTW, I do know how to fix the silly problem of the /dev/cua* disappearance. My main point was the typical user profile for Linux is changing to include more people who do not know or necessarily have the time to learn about command lines. There are several incompatibilities introduced in Linux 2.2 which could be problematic for Linux's new "non-technical" users -- serial device naming is one of them. My suggestion is to have a bit more emphasis on retaining compatibility between future kernel releases for the sake of the new "non-technical" users. A little history lesson: /dev/cua* existed before /dev/ttyS* and there was no technical requirement to remove /dev/cua*, only concern about a few bytes of kernel bloat.
What is a "desp a rate" point please?
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)
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?
Oh come on people! He typed this in the subject line:
Linux blows (Score:5, Insightful)
He's not a moderator, he wasn't moderated up. The post's score as I write this is 0, and should be bumped down to -1.
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 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!
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
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?
FreeBSD? Even though it is NOT commercial, it is reliable and well-engineered.
Ricardo da Silva Lima
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?
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?