Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Kernels Galore 122

Posted by justin++ from the hat-trick dept.
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 :)
This discussion has been archived. No new comments can be posted.

Linux 2.0.38 Released More

Linux 2.0.38 Released

Comments Filter:

  • Re:2.0.38? What happened to the 2.2 tree? (Score:1)

    by Anonymous Coward
    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.

  • Re:Don't tell us what the bug _IS_ (Score:1)

    by Anonymous Coward

    Read BugTraq's technical discussion [securityfocus.com].

    Add BugTraq to your bookmarks:
    http://www.sec urityfocus.com/templates/archive.pike?list=1&threa ded=1 [securityfocus.com]

  • Re:bugfix speed (Score:1)

    by Anonymous Coward

    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

  • Re:Kernel Usage will fork unless... (Score:1)

    by Anonymous Coward
    A good Torvalds quote is, "backward compatibility eventually goes away, while forward compatability does not."

  • Re:Kernel Usage will fork unless... (Score:1)

    by Anonymous Coward
    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

  • Kernel Usage will fork unless... (Score:2)

    by Anonymous Coward

    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.

  • (Score:2)

    by Anonymous Coward
    Linux users are lemmings collectively jumping off of the cliff of reliable, well-engineered commercial software.
  • 2.2.12? where where? =))

    ---
  • You say 2.2 is not stable enough for a server?

    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.

  • 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.
  • I got confused and thought 2.2.12.pre*. Sorry.
  • 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.)
  • 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 [securityfocus.com] 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.
  • Alan released 2.0.38-pre1 a _while_ back, saying that it was one security fix and he wanted to make sure there weren't others which needed to be rolled in so that 2.0.38 could be a "final" release for the 2.0.X series.

  • and 2.3.15 and 2.2.12 (Score:3)

    by Unknwn ( 646 ) on Wednesday August 25, 1999 @03:24PM (#1725257) Homepage
    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.
  • 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.
  • >This doesn't apply to /dev/cua* because the 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.

    What's the big deal? Instead of using /dev/cua* or /dev/ttyS* just use /dev/modem as the serial interface and create a symbolic link to either /dev/cua* or /dev/ttyS*. It's simple. When running the 2.0.x kernel I made sure I was running as root and typed ln -s /dev/cua1 /dev/modem. When I switched over to the 2.2.x kernels I just entered ln -s -f /dev/ttyS1 /dev/modem. That's it. No need to recompile anything. You Windows users really need to start reading the docs and manuals that come with software packages you use. Not doing so only makes you guys look stupid.

  • 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?
  • ln /dev/ttyS0 /dev/cua0

    Problem solved.

    (Read between the lines: No incompatibility. Make another argument, or drive through. Thank you.)
  • 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
  • It's not simply a matter of stability. Take, for example, my firewall/router at home. It's a mere 386/33SX, with qute a small hard drive, and a very mature IP masquerading/NAT setup. I'm not in a big hurry to migrate to all of the various packages that 2.2 requires; the box works, and works well. A minor revison to 2.0 is quite sufficient.
    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.

  • 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.
  • "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 [berlin-consoritum.org]
  • Excuse me for being overly ignorant, but why does anyone care about the 2.0 tree? I had convinced myself that the main code base was in 2.2.0 .

    And on that note, why isn't anyone working on 1.2 anymore? :-)

  • Of the 60 machines that are auto-updating the Linux Counter, more than half (37) currently run 2.0 kernels.

    http://counter.li.org/scripts/ [li.org] for the script. The info isn't visible yet, unfortunately.

    The world is slowing down.
  • People who don't want to recompile for themselves can just subscribe to a linux distrubution (debian comes to mind) which will do the dirty work for you.
  • Looks like 2.2.12 has not propagated to all the mirrors yet; ftp9.us.kernel.org has it though.
  • Looks like most of the mirrors haven't picked it up yet. Found it at ftp9.us.kernel.org [patch in bzip2 [kernel.org] or gzip [kernel.org]]
  • At least with Linux you have a reasonable idea of what will break when you upgrade. What about Windows? Without any explination upgrading one of my machines from Win95 to Win98 caused the network card to stop working. The same model card in the same motherboard with the same BIOS revision on a different machine, also upgraded works fine. The difference is that the one that works is one where I flashed the EEPROM to choose the IRQ. They all work fine in Linux and NT.

    My point is that an OS upgrade (and really, when most people think of the kernel, they really mean the OS) is a violent action and in Linux it is far less so than in other products. MS has already prepared the world for problems with OS upgrades, we can just make it less painful with the new, shorter development cycle.

  • 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?

  • I've had trouble with 2.2 too, although in my case it was 2.2.10. 2.2.9 was rock-solid, as is 2.2.11; under 2.2.10 I got frequent lock-ups in X.

    "I want to use software that doesn't suck." - ESR
    "All software that isn't free sucks." - RMS

  • No, like many deprecated features (<APPLET> in HTML springs to mind), cuax was dropped because it served no useful purpose. It is certainly not "required by many widely used packages", as you suggest---ttySx can be used wherever cuax was used before.

    "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.
  • 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.
  • "Many Linux users in future won't understand how to recompile packages that get broken by kernel incompatibilities"

    These same users will not be upgrading their kernels to a new version by themselves, except as part of upgrading their linux distribution. Thus the distribution maintainers would have checked for such incompatibilities and fixed them and generally made sure things work.

    If there are packages on the system they have installed themselves, then it's perfectly reasonable for them to download/get new versions which can be installed in the same way they originally installed them.

    So there are no problems.

  • But like NT (or 98) you are beta tester even if you want to run production quality.

    Except that, unlike NT (or 98), no Unix admin is going to commit a production system to any new version of a kernel until it's been tested and it fixes a problem that actually exists or introduces a feature that is actually needed. Even if the new version is supposedly stable. The operating principle is "if it ain't broke, don't fix it".

  • 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 :-)
  • 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
  • Early stable releases are just massive beta tests. Of course unlike NT you can get the problems fixed quickly.

    ...and unlike NT you don't pay for the privilege of being a beta tester (snicker ;-)

    chris
  • If you had a clue you'd understand that "It's been deprecated" is a call for change.

    Think of the ISA bus: old, clunky, almost useless! The much vaunted PC98 standard (HA!) let everyone know that the ISA bus was being deprecated (or for you laymen "phazed out"). As a result devices that were a mainstay of the ISA bus were more rapidly redesigned and manufactured for the PCI bus (modems, soundcards). Modern motherboards overall have only 2 ISA slots, some less. If you have some old MIDI equipment and and old ISA soundcard then you'll just have to stick with an older motherboard. DUH! Progress has a price in compatability; you can only be backwards compatable for so long and then you have to cut off the straglers.

    Don't whine about "egos in motion". If you actually cared about using, for instance, some extremely old modem software and SMP simultaneosly you should either fix the packages yourself or write an e-mail to the maintainer pointing out the fact that he should have fixed this allready if it was deprecated in 2.0.x...
  • 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.

    I have seen very little evidence to support this point. Likewise compare this to the deprecation to the "dbmopen" function in Perl5. Indeed dmbopen still works, while deprecated, but "tie" is now the preferred method. In fact, tie does nothing more than make a call to dbmopen! Does that mean that it was for someone's sense of taste and not their intention to develop a new standard? No...

    AFAIK a new tie is being developed that will probably be much better than dbmopen ever could be. Likewise, while you can fudge a compatability with /dev/cua* I think it's likely that latter kernels will have a better method of accessing the serial ports and the old /dev/cua methods will crash and burn; better to force package maintaners to recode to the new standard before the old one is permanently removed than force a quick and viscious change right?

    So why retain such a feature indeffinately? Bloat the kernel a bit? No problem... What was that anecdote about windows? (a 32-bit patch to a 16-bit ...) ...or would you rather see development time spent on archaic interfaces rather than new features?

    ...and if you still want to whine about how these viscious dictators are making rediculous changes to your perfect linux you'd better put your ego in check until you can churn out a kernel feature or patch yourself. (ehem, I'm not complaining) So when ~1% of the users scream "You killed our feature!" and whine about how stupid/unfair it is they get quoted the Linux phillosophy.

    "Do It Yourself"

  • 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?
  • Don't forget about today's booming computer service industry...

    these people will still need ways to make a living when brain-dead linux distributions are the rage (if they ever are)
  • 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!
  • There's no such thing as bug-free software.

    Certainly Linux has bugs, but there are differences. First, the bugs generally don't seem to effect daily operation. Most of the bugs, I believe, have been security related.

    Second, when a bug is found in Linux, it's fixed. With Windows, you have to wait for the next service-pack, which could be months away. Because Linux bugs are fixed so promptly, it makes it look much more buggy then it is. Sure there have been, what, 12 upgrades to 2.2 so far? But how many bug fixes were in the most recent WinNT service pack? And as we get further along in the evolution of 2.2, the updates will get more & more scarce.

    (for a list of the updates in SP5 for WinNT, see the Windows NT 4.0 Service Pack 5 Updates Catalog [microsoft.com].)
  • BTW, remember that that was the FIFTH service pack. In theory, most of the bugs should be worked out in the first couple of updates, so this one should have fewer updates then the others, right? But we'll assume that each SP fixed the same number of bugs. That means, if each of the bugs had been fixed immediately rather than in service packs, we be at NT4.0.300 (5 * 60-- and that only counts the 60 updates to the base OS, not y2k, networking, shell, security, etc...)
  • What crap. Trolls are moderated down and no AC can moderate, so I don't know where you get that from.

    And what huge outcry?
    More to the point, if you even read as little as the article header posted you see "TCP/IP bug" as a reason to upgrade to 2.0.38.

    Me, I think anyone still using 2.0.x is a moron.

    ~Tim
    --
  • FreeBSD? Even though it is NOT commercial, it is reliable and well-engineered.
  • >1. Linux has bugs, contrary to the FUD often >spread here on slashdot.

    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 /. or who play with it on occasion, etc.


    (Sorry for this rambling post)
  • 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.]
  • tcfs/cfs seem to help nfs..of course they slow things down some.
  • *shrug* you could stick to 2.0.x if you like it. besides, mostly recompiling software with a cuax substitution to ttySx would do it...or a link. backward compatibility is nice but not when it gets in the way.
  • 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-
  • 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. ;)

  • Re:2.0.38? What happened to the 2.2 tree? (Score:3)

    by Sun Tzu ( 41522 ) on Wednesday August 25, 1999 @02:13PM (#1725308) Homepage Journal
    There are hermits among us, my boy, who are very slow to jump on the latest kernel for our servers. And, it's not just because we have impressive uptime to consider, either! We have predictable and adequate behavior in an older kernel running on a dedicated machine and we want to change as little as possible. A new 2.0 kernel with minor refinements and bug fixes isn't likely to break anything. The wonderful world of Linux works here too! Ain't it grand?
  • Actually, AC is responsible for maintaining and bux fixing the 2.0 series...
  • so you don't know what the bug is either.. does anyone 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?
  • What reliable, well-engineered commercial software? NT?
    --
  • Yay, triple kernel trees are almost over.

    -awc

  • Changes? (Score:3)

    by JaySWF ( 59721 ) on Wednesday August 25, 1999 @09:57PM (#1725315) Homepage
    Sorry for asking a (possibly) stupid question, but where can I read what has changed from 2.2.11 to 2.2.12?
  • 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?
  • Oops that url for the 2.2.11 notes was supposed to be www.linux.org.uk
  • Every single Microsoft hotfix contains a readme and has an associated knowledge base article. Don't spew if you don't know what you're talking about.


    -witz
  • You can see what have changed at: www.kernelnotes.org [kernelnotes.org]. And since it is Alan Cox who takes care of the 2.2-tree now - probably also at his diary, www.uk.linux.org/diary [linux.org].
  • I hate my forking kernel

Slashdot Top Deals

"Marriage is low down, but you spend the rest of your life paying for it." -- Baskins

Close