Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
Linux Software

Linux 2.4.18 Released 391

Posted by michael from the power-of-pure-penguins dept.
Kourino writes: "Marcelo announced the release of 2.4.18 a couple hours ago after 4 release candidates, but the tree marked 2.4.18 on kernel.org is missing the -rc4 patch that finally made the kernel releasable. Basically, what's marked as 2.4.18 is really -rc3, and what's marked as -rc4 is what should have become 2.4.18. According to Marcelo on #kernelnewbies, most users won't be affected, but people on SPARC systems should definitely grab 2.4.18-rc4. Your best bet is probably just to get 2.4.17 and patch to 2.4.18-rc4. Seems 2.4 is destined to be an "interesting" release branch ^_^; For the new release, head over to your favorite kernel.org mirror. (Marcelo will set things straight in 2.4.19-pre1.)"
This discussion has been archived. No new comments can be posted.

Linux 2.4.18 Released More

Linux 2.4.18 Released

Comments Filter:

  • NEW UPDATE (Score:1, Funny)

    by 8bahl ( 233857 )
    I want the new MS OS killer... 2.4.666
  • It seems that Sun is now 20 years old. Happy Birthday Sun. So on its birtday it get a nice new Linux patch for its platform. Ok everyone Dig out your old Sparc 2's and install you Linux kernel.

  • Version numbers. (Score:2, Insightful)

    by saintlupus ( 227599 )
    Basically, what's marked as 2.4.18 is really -rc3, and what's marked as -rc4 is what should have become 2.4.18. According to Marcelo on #kernelnewbies, most users won't be affected, but people on SPARC systems should definitely grab 2.4.18-rc4.

    Wow. Now that's professionalism, eh? Good thing that this whole Open Source badge makes it all okay.

    Would the fifteen second delay to rename a couple files before release really have killed anyone?

    --saint

    • Re:Version numbers. (Score:5, Insightful)

      by markj02 ( 544487 ) on Monday February 25, 2002 @06:01PM (#3067307)
      Wow. Now that's professionalism, eh? Good thing that this whole Open Source badge makes it all okay.

      No. What makes it OK is that the fix is out within 24 hours, that even 2.4.18-rc3 is very usable, and that people who run anything on Linux shouldn't be upgrading to a kernel that has just been released, even in the "stable" series.

      Microsoft, just to pick one commercial example, releases a new version of Windows once every few years, and major service packs fairly infrequently. They also invest hundreds of millions of dollars in each release. And, you pay hundreds of dollars for Microsoft's software. That's what makes it not OK when Microsoft breaks a kernel release and users end up being stuck with it for months. And Microsoft releases packages with major flaws constantly, much bigger flaws than a forgotten rc4 patch.

      • More like: no patch needed. One can download 2.2.18-rc4, which is identical to what the -final release was supposed to be. So, really, someone can just use that instead of the real -rc3/-final.


        Anyway, not reuploading the release without a peep is a responsibility thing to do. He could have just reuploaded the release, with the possibility that a few people would get burned. Keep it all under wraps and no one would even know about it.

      • Kinda like how service pack 2 for NT on alpha "fixed" so much stuff, like the DHCP server. It fixed it so well that it just didn't work at all.

        The MS solution was "don't install SP2, just wait for SP3 to come out." That was many months down the road.

    • Re:Version numbers. (Score:4, Insightful)

      by Arandir ( 19206 ) on Monday February 25, 2002 @11:17PM (#3068642) Homepage Journal
      That's not professionalism, it's a complete lack of any plan. Sometimes I suspect Linux doesn't even have a release manager. What? They don't? I knew it!

      Open Source means that such bonehead blunders get fixed quickly and efficiently. In the meantime, this is the stable branch of the poster boy for Open Source. This raw egg everywhere certainly demonstrates the openness, but it doesn't do jack to demonstrate any professionalism.

      Of course, nothing in life is perfect. But the whole 2.4 branch has been plagued by crap like this from day one. Frankly, Linux is starting to get a reputation, and it's not a pretty one.
  • > Load code did not set personality for
    > binaries without an interpreter: This was
    > breaking static apps on several archs

    Okay, but Which architectures does this affect? It might be nice to know.

  • I can't trust this release... (Score:3, Insightful)

    by Anonymous Coward on Monday February 25, 2002 @05:40PM (#3067176)
    the tree marked 2.4.18 on kernel.org is missing the -rc4 patch that finally made the kernel releasable. Basically, what's marked as 2.4.18 is really -rc3, and what's marked as -rc4 is what should have become 2.4.18. According to Marcelo on #kernelnewbies, most users won't be affected, but people on SPARC systems should definitely grab 2.4.18-rc4. Your best bet is probably just to get 2.4.17 and patch to 2.4.18-rc4. Seems 2.4 is destined to be an "interesting" release branch ^_^;

    I've had enough kernel problems in the past. The degree of uncertainty presented around this latest Kernel doesn't inspire a whole lot of confidence.

    Think I'll hold off for a while, thanks.
  • Wouldn't it have been smarter to create a proper Linux-2.4.18.tar.gz (and bz2), and update the kernel.org and mirror sites, and THEN post to Slashdot and other such places?

    This is just going to confuse people!
    • It's called trial-by-fire.

      Once the flames die down, and the dust settles, he'll probably not do that again.
    • Unfortunately, it's not that simple. Once he released the new version and posted about it, he couldn't change the binaries. That would means 2 different binaries were released for the same file (even if in a short period of time), and that could cause even worse problems (how could someone know, in the future, which version a file really is? What if a mirror didn't get the new files properly?)
      • simple, replace the old tar balls (those arn't binaries) with the new ones AND make a show of the md5sum of the new kernel. that way people could download from a mirror (most mirrors show the md5sum anyway) and md5 it and see if they get the same value.

  • 2.4.19-pre1 is out now. (Score:5, Informative)

    by dietz ( 553239 ) on Monday February 25, 2002 @05:43PM (#3067197)
    Here's the ChangeLog [skylab.org].

    That was quick. (It includes a lot more stuff than just the patch missing from rc4).
    • It includes a lot more stuff than just the patch missing from rc4

      Ironically, it doesn't mention the missing patch, so I just hope he didn't forget it again :)

      (just kidding, he probably had the pre1 ready already, and decided to release it quickly to fix the rc4 problem, but then he just forgot to add this new 'change' to the log).

    • The problem is that it doesn't only include the missing patch from -rc4. A lot of stuff considered too experimental for the 2.4.18 kernel was saved until 2.4.19-pre1, but that version is now required for most non-x86 platforms. Suddenly people are locked into testing experimental code if they're using a non-x86 architecture and require updates in the 2.4.18-pre's, and this is a BAD THING.
      • But wait... just use 2.4.18-rc4!

      • Re:2.4.19-pre1 is out now. (Score:3, Insightful)

        by Eil ( 82413 )

        Or you could simply use the current stable kernel that's running on your machine right now.

        My production machines are all still on 2.4.5, perhaps the most stable of the 2.4 series. (In my experience.)
    • Don't forget it is a -pre. Marcelo was keeping a lot of patches out of the late 18-pres because he wanted to get the damn thing stable.

      We should also note the time that has gone past between 2.4.17 and 2.4.18 - more than two whole months. This is Marcelo's first real own kernel in my opinion. 2.4.16 was a bug fix for 2.4.15 - 2.4.17 came out only a few weeks afterwards, but this baby really had time to mature.

      This is also why I don't mind reading this (commenting on all the "This is not freshmeat" discussions) on slashdot. This is a stable kernel, the first for a long time. It is not like in the times when a new "stable" kernel came out like every other day and people got annoyed.

      I have 2.4.18-rc4 running for almost 9 hours now (basically since it came out) with setiathome, dnetc, tftpd, nfs, smbd, cups, pppoe, bind9, dhcpd3, tftpd (for remote booting clients) using huge reiserfs partitions and I like what I see. It is just my busybox DSL router, firewall and file server, so not really a production system, but it is in a server case, running a dual pentium II so hardware that while not fully up to date resembles that of production servers in medium sized companies. I don't normally pull a new kernel everytime one comes out, but I suddenly needed NFS support which I didn't have compiled in before, so I decided to upgrade to either .18 or the most current release candidate. Before that it was running for at least a month on .17.

  • It really isnt easy to label your files correctly, it really isnt ;-)

    Wait, theres a system in it, we all are confused now, and wont dowload this kernel too fast, so somebody discovered the *really horrible bug* before we even know what we have to download to have it crash our fs. Well done.

    Thats just like voting in Florida, the ballots there also have an integrated intellegence test.
  • You've all heard this before, but that way people who aren't particularly interested in minor kernel revisions but are interested in general Linux stories can filter away the linux kernel topic.
    • Imagine that it's 1983, and I decided that I wanted to filter out everything that wasn't of particular interest to me at that time.

      Now, jump ahead to 2002. I would have missed all the great leaps of the past 20 years. I wouldn't even have a clue that I would want a beowulf cluster of Commodore 64's! I might even post a comment like this to Ask Slashdot: "Hello Slashdot, I was in a restaurant the other day and I overheard some people laughing hysterically about something called Amiga. It sounded really fun. Doesn anyone know if I can buy one?" Oh, I would have been just like Rip Van Winkle if I had managed to filter out everything that wasn't of interest to me.


    • This reminds of those people who complain that there's nothing good on TV but spend 6-8 hours watching it anyway.

      Take the Linux kernel updates out of the Linux OS topic? If you do that, then you'd have to rename the Linux OS topic to "GNU-based OS" topic because the only thing that makes Linux Linux is the kernel.

      If you don't want to read about "minor" version releases then for god's sake use your scroll bar and read something else. Betteryet, read a book
      • Take the Linux kernel updates out of the Linux OS topic? If you do that, then you'd have to rename the Linux OS topic to "GNU-based OS" topic because the only thing that makes Linux Linux is the kernel.

        Yeah, the kernel. And all the drivers within that kernel that only Linxu supports, like filesytems and packet filters. And the FHS, and the LSB and the standards they entail, like SysV and RPM. And all those the distributions that don't distribute other OSs (everyone except Debian). And all the software ports that are for Linux and not for any other Unix. And the various political issues which surround Linux and not BSD and other OSes.

        Yeah, there's no Linux OS or Linxu specific issues. If that were the case, you'd have crazy stuff for each individual Unix OS, like a BSD section or apple.slashdot.org, and we all know that would never happen, right?

        Its about signal noise ratio. You don't seem to understand that.

  • amd cache coherency (Score:4, Interesting)

    by theEdgeSMAK ( 467213 ) on Monday February 25, 2002 @05:46PM (#3067223) Homepage
    Has anybody addressed the amd cache coherency bug? I'm still booting with mem=nopentium. That makes me sad.

    jeremy

    • Re:amd cache coherency (Score:4, Insightful)

      by strredwolf ( 532 ) on Monday February 25, 2002 @08:40PM (#3068129) Homepage Journal
      I belive this was fixed with 2.4.18-pre1, which was the first patch in.

      But I'm still scared over 2.4.18 missing the -rc4 patch, and both 2.4.18 and 2.4.19-pre1 are fresh. I'm not going to compile it even on my own system until 2.4.19 is released.

      Oh Alan, where are you...
      • Are you sure it is fixed at all? How could this have been fixed in 2.4.18-pre1 when the bug was first discovered when 2.4.18-pre7 was out [lwn.net]?

        I think I'll keep mem=nopentium until someone can point me to a changelog entry that mentions this directly.

  • Linux/SPARC (Score:5, Informative)

    by uzi ( 30210 ) on Monday February 25, 2002 @05:51PM (#3067247) Homepage
    I believe the problem is on sparc64 (and not sparc32). It's a trivial patch... just a few lines, so it's easy to have been overlooked.

    Anyone using a SPARC/Linux machine that wants the latest and greatest should always turn to the
    vger.samba.org [samba.org] sparc/linux kernel cvs tree. It's always got the latest stuff for both 64-bit and 32-bit SPARCs (and networking as well).

    That said, 64-bit SPARC machines should run fine with the recent kernels. For the 32-bit SPARC machines, I can only comment on the sun4m and sun4c machine. Currently, the sun4m machines should boot and be ok... the sun4c machines do not.

    sun4m machines: ss20, ss10, ss5, ss4, lx, classic, javastations
    sun4c machines: ss2, ss1+, ss1, ipx, ipc, slc, elc

  • How about a new Slashdot feature. (Score:3, Insightful)

    by jellomizer ( 103300 ) on Monday February 25, 2002 @05:52PM (#3067259)
    On the top right of the page a little box giving the current kernel version and the date/time of the change when you click on it you can get to its message board. That way you guys can get your Kernel Fix and read about your problems and us people who dont update the kernel in the main messages. I like getting news about Linux and Also Major Kernel versions. But all these little ones gets annoying. It seems like if anyone really want to post a story with there name on it they keep two browsers open and one refreshes kernel.org untill a version apears and then they post a message stating that. Say I can make a script to do that. (But I wont)
  • Appearantly, the missing piece from -rc4 is only missing from the patch, NOT the full tarball.

  • 2.4.18 IS OK? (Score:2, Informative)

    by beezly ( 197427 )
    There's a report on linux-kernel that the 2.4.18 tarball is actually ok.

    Has anyone had an opportunity to check?

    Here's a link to the chap saying it's ok:
    http://marc.theaimsgroup.com/?l=linux-kernel& m=101 467401412021&w=2

  • But what *I* want to know is... (Score:3, Funny)

    by Aexia ( 517457 ) on Monday February 25, 2002 @06:03PM (#3067317)
    whether the Linux underwear [uclick.com] for this version has been released yet.

  • Release frequency, release engineering thoughts. (Score:4, Insightful)

    by seantrue ( 195770 ) on Monday February 25, 2002 @06:03PM (#3067318)
    There is a natural rhythm to the frequency of a successfully released software system, which is an indescribably complex function of the size of the system, the size of the releasing team, the maturity of the software, the sophistication of the end user, and the cost of making mistakes.

    What is an ideal release frequency for one point in this space, is not at another.

    At one point I worked at a DOS extender company (Rational Systems, not related to Rational of California), and we released the software every week. The system was small, the team was small, the customers were very sophisticated, and the value of adding new features was very high. We were praised for being responsive. Three years later, the software was much bigger, the release cycle was down to 2 times a year, and the value of not adding new bugs to the old features was very high. We still got good marks for technical support.

    Unlike most commercial software, it's hard to point at revenue streams for Linux that justify the midlife software development expenses like full-time, paid-for, this-isn't-fun-but-it-has-to-get-done release engineering. Although there is a large virtual software team for this OS, I strongly suspect that there is less infrastructural support than you get with old fashioned, iron vendor supported systems like Solaris, HP-UX, et al. TANSTAAFL, folks.

    Don't get me wrong, I use Linux daily, my servers run on it, and I depend on a variety of other open source software (particularly Python!). I even buy RedHat/KRUD releases just so that some value flows back into the release process from a happy recipient. But I sometimes feel like holding my breath while installing that next kernel release!

    TANSTAAFL -- There ain't no such thing as a free lunch. Thanks, RAH, wherever you are!

    • Don't get me wrong, I use Linux daily, my servers run on it, and I depend on a variety of other open source software (particularly Python!). I even buy RedHat/KRUD releases just so that some value flows back into the release process from a happy recipient.
      It's very sad that you have to say it. It reminds me of communist regimes where every, say, philosopher had to mention in every article that his theory is consistent with teachings of Marx and Lenin.

      Moderators are supposed to rate your comment, the way how you explain opinion, but not your position in the so-called OS War. Unfortunately, they do the opposite quite often. Now you have to be with one of the camps to be heard and understood.

      I used to like this site.

  • 2.4.18 with rc4 applied seems to be a stable, well-tested kernel that has gone through all the testing needed for a release. It deserves its own kernel version number. Since 2.4.18 is not-quite-right, why not just make what was going to be 2.4.18 into 2.4.19?

  • Why can't they fix it now? (Score:5, Insightful)

    by irq ( 68200 ) on Monday February 25, 2002 @06:09PM (#3067348)
    Why can't they just rename the files?
    I mean, these people make operating systems, right?
    • Because it would be bad to have two seperate versions of 2.4.18 out there. Because once they put it into the mirror system, it starts to propogate, and it would proably cause problems if a second version of 2.4.18 was put up.

      • Re:Why can't they fix it now? (Score:4, Insightful)

        by Bronster ( 13157 ) <slashdot@brong.net> on Monday February 25, 2002 @11:17PM (#3068640) Homepage
        Honestly, what they _should_ have done is put out 2.4.19, with nothing but that _one_ patch, marked 2.4.18 DONTUSE, and started with 2.4.20-pre1. Who cares about an extra number?
        • Care to explain? What's exactly wrong with 2.4.18? It seems to me that you are basing your opinion on comments of those who don't know what they are talking about.

          I don't see anything in 2.4.19-pre1 that would justify immediate release of 2.4.19 and marking 2.4.18 as DONTUSE.

          2.4.18 was released only once, with the personality bug fixed. There was no "other" 2.4.18.

          If a bug is found in a release candidate, it is the right thing to do to make another release candidate with this bug fixed and no other changes, and that's exactly what has been done. I see no point in releasing 2.4.18 with a known bug and marking it DONTUSE right away.

          • What I just read is this:
            rc3 was released with a bug.
            rc4 was released with the bug fixed
            rc3 was marked final anyway.

            so now we have a final relaese with a bug that a *later* rc did not have.
            • rc3 was released with a bug.
              rc4 was released with the bug fixed
              rc3 was marked final anyway.

              More than that, it's a show-stopper bug on non-Intel architectures. That's sort-of bad and stuff - there's no reason to leave something with a known bug as the most recent release any longer than necessary.. there's an infinite number of version numbers available, it's not like anything would be wasted (and anyone downloading the patch would only have to get a couple of Kb).

  • VIA and Cyrix III must have rc-4 (Score:3, Insightful)

    by Dark Coder ( 66759 ) on Monday February 25, 2002 @06:19PM (#3067395)
    If you have a Cyrix III 1Ghz and a VIA southbridge controller, you must have the -rc4 .
  • Yep, now I know what kernel I'll be running on Debian Stable in 2005...
  • Say what you want, but looks like true reason for missing SPARC patch is just a revenge on Sun for this [heise.de].

  • Just give me a kernel that turns off my computer (Score:3, Interesting)

    by Bradee-oh! ( 459922 ) on Monday February 25, 2002 @07:27PM (#3067802)
    The only kernel that's ever actually powered down my machine on shutdown or halt is the special 2.4.8 included with my Mandrake distro.

    Has anyone else had this problem and actually fixed it??
  • I'm not compiling until this patch [kernel.org] is available for 2.4.18. It combines Ingo's O(1) scheduler with RML's preemptible kernel code patch.
  • Linux was fantastic when Sun released Solaris 7 - their first 64 bit OS. It meant that you could give a new lease of life to those 'cherished' old SPARCstation 1/2/Classic/LX/10 etc. The reason? Solaris bloat. Solaris has grown up with the Sun hardware range. Versions 7 and 8 have a great deal of code which supports later generation hardware. It's getting pretty difficult to fit it on a 1 gig disk - even a custom install, let alone the 420MB drive which came with my old sparcy2.

    The non-pagable kernel memory used to fit, just about, in 32MB with some to spare for buffer cache (well, 2.5.1 did) . Nowadays it just swaps horribly. Why you ask? the old SPARC workstations don't have much of the hardware which new versions of Solaris provide support for (much of it installed even if you don't have the hardware grr.). Solaris has a mature multithreaded kernel, it has amazingly well tuned, truly scalable, kernel synchronisation primitives (check out the book "Solaris Internels" - Mauro, Mc Dougall) it has in-kernel support for Sun's hardware enterprise features; dynamic reconfiguration (the ability to tell Solaris to stop using memory, CPU or IO devices on a certain system board, drain the memory to swap, re-dispatch the active processes to other CPUs, remap the IP addresses to other cards, detach the board, replace, reattach - start using the new hardware - no reboot), hotplug PCI, processor sets, dynamic system domains etc. etc.

    Decent Sun boxes (by that I mean anything with more that 4MB L2 cache and SCSI disks - a curse on Ultra 5/10/X1/SunBlade 100s), will run Solaris 8 very well, plus you get a tier one Oracle/Sybase/Java platform, with all of your favourite window managers/web browsers/IRC clients etc. available for download.

    Mark my words, once Linux starts making real inroads on the sort of Enterprise server kit (i.e. more than 8 SMP CPUs, and much more than 4gb RAM) that you need for serious financial/HR/government/pharms. type applications , it too will be bloated. You could argue it already is - my 486SX/8MB of RAM gave very good service as a firewall, using ipchains and kernel 2.2. Kernel 2.4 and iptables (and I suppose my new stateful filter) make it rather too slow to survive my next hardware cull. Ah well, out with the old...

    • If the bloat of the newer Solaris OSs makes your old hardware perform like a beached whale, why not just run Solaris 2.6? Its still maintained and will run packages of its era. So what that the latest Oracle won't run (or run well) on it, or that your old machine won't execute 64 bit code? It wasn't meant to run the latest Oracle monster, and the hardware was never meant to run 64 bit code.

      (Granted, running SPARC Linux may be more entertaining, and I still suspect it would run faster than any version of Solaris...)
  • I tried to reason on an IRC channel where marcelo (and other kernel 'hackers') hang out. I was kiboshed. I tried to convince them that fixing the tarball called 2.4.18.tar.gz would be a good thing to do.

    Here is some of my reasoning, musings and retorts to those who 'know' more than I do.

    "Is there a plan to fix the 2.4.18.tar.gz or will I have to patch it. It is really annoying if this isn't going to be fixed to rc4/final, instead I have to patch 2.4.17 with the RC4 patch. This makes it difficult to use kernel.org as a "library". Pretend in some number of months some Joe Schmoe says 'Gee, 2.4.18 has been out for a while and is considered stable,' downloads it, and misses the RC4 patch."

    This was rejected as reasonable. I was told that assuming a release is stable is bad practice, particularly based on how long its been out. My impression was this was the stable branch. I'm sure that, for example, RedHat picked 2.4.7 and 2.4.9 and hacked them for their own distributions for some reason or another. They, like the rest of use, should be ensured that what is fixed in the changelog should be included in a given release. I don't like being shunned for being closer to correct.

    "I appreciate the need for a releases in software. The line is drawn, certain things are in, other are out. Its just that what was determined to be final and what is being masqueraded as such are two different things. so, the gatekeeper in this case should be able to rectify the mistake."

    From the group came no response. The conversation had turned to more pressing things, such as people bragging about compiling XFS into highly experimental versions of the linux kernel. Proper release procedure is not nearly as important as strutting about having XFS working in a situation where it probably shouldn't.

    Here is a reply, which was well stated and polite, but I vehemently disagree with:
    "Zeio: You and Marcelo both :) everyone would have liked this to be a better release than it was, but ... mistakes happen. and, once published, one must live with them. :)"

    So, with this reasoning, if I published a book. For the sake of argument this book is supposed to have 10,000 copies printed. I catch a typo after shipping 1,000. Wow, the rest of the 9,000 people have to eat the typo because once something is released it shouldn't be changed.

    I also state this:
    "I'm suggesting a viable way of dealing with it[the mis-release], to fix the problem by putting what was supposed to be final in place of the tarball which masquerades itself as a release, or rename it to DONT USE like 2.4.11. I would expect higher standards from the linux maintainer.

    Finally, to my dismay, I realize that there is denigration concerning the theory that and open community should be attempting to mold the linux kernel tree into a pillar of perfection. Lines have to be drawn, periodic shortcomings have to be accepted until fixed, but gross errors which are easily fixable should be ignored because 2.4.19 is on the way. I'll lower my expectations of the "stable" 2.4 linux tree for the time being. I'll put 2.4.18 in the same category as 2.4.11 and the "greased turkey" release. Seems this is becoming a norm. I strongly appose nonchalant and half assed attitudes towards maintain something of this importance.

    Another joke was made that this only gravely affected SPARC users. This reinforces the wholly incorrect attitude that x86 should come before others. I'd bet that if this 2.4.18 wouldn't boot on x86, they would have re-released it.

    Sadly, I had to point out that even Mickey$oft was forced to re-release service pack 6 to 6A. The claim was that 2.4.19pre1 is already out, and that 2.4.19 will likely be out in less time that it took Mickeysoft to put out 6A. These to me are excuses. Inferior ones. I expect more from linux than Microsoft. I expect a group project to put its best foot forward. I'd hate to have to write code for a project where FINAL is a line that is arbitrarily drawn. I know I'm over reacting, but I tend to like testing the latest stable release when they come out, and wouldn't you know it I have a SPARC. Guess I'll wait for 2.4.19, like I had to wait after 2.4.11 (2.4.12 was out soon, albeit with a broken LPT module, but that is when Linus maintained 2.4) and greased turkey. Sorry, I don't like to patch a previous major release, I just don't like doing it, I don't get off on it, I don't want the hassle, even though it is easy and have done it for things like the AIC driver when it was taking them forever to integrate the changes into the stable tree.

    Linus, show this kid how to rectify an error and do it quickly.

    • I'm suggesting a viable way of dealing with it[the mis-release], to fix the problem by putting what was supposed to be final in place of the tarball which masquerades itself as a release, or rename it to DONT USE like 2.4.11.

      The trouble with changing the 2.4.18 tarball on kernel.org is that having two different releases called 2.4.18 out there will lead to more confusion than it's worth. This is particularly important because kernel prepatches are distributed as diffs against the releases.

      Linus, show this kid how to rectify an error and do it quickly.

      Hmm... you know what? I think I see the reason you were "kiboshed". (Hint: it's not because of Marcelo's immaturity.)

  • Support for announcing new kernels (Score:5, Insightful)

    by herk ( 313044 ) on Monday February 25, 2002 @11:00PM (#3068590) Homepage
    Yeah that's right, I said it. I LIKE having Slashdot announce new kernels. This is where I always hear about new releases. I don't want to check a kernel site every day of the year, I'd rather see it on a site I'm reading anyhow.

    Too many people bitching about such pointless dribble; 2.4 sucks, BSD owns Linux, stop posting these kernel releases.(Despite the fact that it's clearly geek news, and being posted on a geek news site) And then we add capability to exclude topics from your slashdot homepage, and people still bitch.

    This is a tech news site, Linux kernels are a perfectly viable news item. 2.4 does not suck. If you think it does, move on to something else. Ignore the topics. Stop ripping up people doing a perfectly good job.
  • I thought I'd help out the /. community by providing a little practice for those people who are not interested in reading kernel release announcements but seem to still have trouble not clicking on the links.

    Below are four links - three are of interest to most people here, one probably is not. Try going through the list and ONLY following the links you like (repeat until you can do it almost every time), have fun!

    1. Slashdot [slashdot.org]
    2. [H]ard|OCP [hardocp.com]
    3. G0atse Guy [goatse.cx]
    4. Kernel.org [kernel.org]

    How did you do? Just keep practicing with this list, and you'll be able to enjoy slashdot to the fullest in no time at all!

Slashdot Top Deals

The reason why worry kills more people than work is that more people worry than work.

Close