Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Linux Software

Kernel 2.5.3 Released 371

cybercyst writes: "You know the drill... Lets go hit those servers!" As usual, see kernel.org for the download or the changelog. Anyone using 2.5 for anything except testing?
This discussion has been archived. No new comments can be posted.

Kernel 2.5.3 Released

Comments Filter:
  • Using it? (Score:5, Funny)

    by SilentChris ( 452960 ) on Wednesday January 30, 2002 @07:35PM (#2928223) Homepage
    "Anyone using 2.5 for anything except testing?"

    Are you kidding me? I'm using it to browse the internet right n-

    • Re:Using it? (Score:2, Insightful)

      by Woko ( 112284 )
      I'm still nervous about using 2.4 - Its really irritating to find production environments going down because the VM subsystem decided to kill mysqld
      • Re:Using it? (Score:3, Interesting)

        by HeUnique ( 187 )
        You can either get 2.4.17, add the 2.4.18pre3 and Alan Cox's 2.4.18pre3-ac2 patch..

        Or simply get 2.4.17 + Rik's latest rmap patch..

        I done some very heavy testing for 36 hours keeping the processor runnning at %99 and all memory occupied while compiling KDE CVS (full), XFree CVS (full), and the kernel itself over and over..

        It passed all without a single fail.
      • Re:Using it? (Score:2, Insightful)

        by Sivar ( 316343 )
        Production environments? That's what FreeBSD is for. >

        Seriously though (and I was serious), most companies with experiences IT people aren't going to use anything that hasn't been thoroughly tested internally (like the latest releases of the kernel that have the new VM), but then most companies probably wouldn't use MySQL in a production environment either...though I would argue that it is more solid than most operating systems.
  • drill (Score:3, Insightful)

    by geekoid ( 135745 ) <dadinportland@y[ ]o.com ['aho' in gap]> on Wednesday January 30, 2002 @07:35PM (#2928229) Homepage Journal
    Not everyone know the drill, perhaps a link to a step by step instructions on how to do it should be included. You don't want to sacare off the new people, do ya?
    • Re:drill (Score:5, Insightful)

      by furiousgeorge ( 30912 ) on Wednesday January 30, 2002 @07:36PM (#2928235)
      New people shouldn't be upgrading their kernel...... ESPECIALLY to an unstable development one.

      If you don't know how to do it you shouldn't be doing it anyway.
      • Everyone has a first time to install a devel kernel and they need to know how to do it before they can. Besides, completely fscking up your system is a good "lesson" to learn along the way :-)

        (BTW, "new people" ??? Aren't they called "babies"? Now they really _shouldn't_ be installing kernels at all. That would be worrying and unnatural to say the least)
      • Re:drill (Score:5, Funny)

        by sabinm ( 447146 ) on Wednesday January 30, 2002 @08:05PM (#2928389) Homepage Journal
        If you don't know how to do it you shouldn't be doing it anyway

        Riiiight. That's probably why you're still a virgin
        • Re:drill (Score:3, Funny)

          by Webmonger ( 24302 )

          Your sig is especially appropriate for that post :-)

          It's time to let your children compile devel kernels. It's time to let the bed bugs bite. . .

    • Not only that, but kernel 2.5.3 of WHAT???

      ;-)
    • The Drill is pretty well-documented all over the place, including in the kernel source documentation. Don't encourage linux newbies to use experimental kernels.

      - A.P.
  • Use The Mirrors, Luke!

    Please refrain from flooding kernel.org every damn time you post that a new kernel is released. You should link directly to the list of mirrors. As has been said before, anyone who would even venture on compiling and using something like this could easily find the appropriate folder on an FTP mirror from which to download the new source.

    That is all.
    - Eric Krout
  • i WAS running it.. (Score:3, Interesting)

    by ByteHog ( 247706 ) <{chris} {at} {bytehog.com}> on Wednesday January 30, 2002 @07:39PM (#2928251) Homepage
    until a bug in the 2.5.2 series prevented me from using my swapspace. Everything else worked perfectly though. I'm back to 2.4 until sometime in the near future...
  • New Poll! (Score:4, Funny)

    by dbretton ( 242493 ) on Wednesday January 30, 2002 @07:43PM (#2928277) Homepage
    Number of Maintainer Patches Dropped By Linus in 2.5.3:

    5
    10
    30
    69
    CowboyNeal!
  • by Metrollica ( 552191 ) <m etrollica AT hotmail D0T com> on Wednesday January 30, 2002 @07:43PM (#2928282) Homepage Journal
    Why does the kernel go through stable and then unstable forks? Can't it always be a stable build, like with Windows?
    • i think the comparason would be:
      linux unstable/development (2.odd) == windows beta
      linux "beta" == windows gold
      linux stable == windows after 3 service packs

      or something like that
    • Why does the kernel go through stable and then unstable forks? Can't it always be a stable build, like with Windows?



      Because Linux development is don't in public in front of everyone, The unstable portion of Windows development is done behind closed doors and not seen by the public (given Windows past tendancy to crash when sneezed on it's arguable that some portion is really done in public).



      That's the difference between open source and closed source - you get to see the stuff as it's being developed and if you want you can get involved and do some yourself. On the other hand if you only want to use the stable versions stick with the even numbered releases (2.0, 2.2, 2.4).

    • Don't be too smug there Mr Metrollica. My experience, humble as it may be, with linux 2.4.x has been that it was unstable until 2.5 appeared. Well, after that one little problem was cleared up in 2.5. Anyway, my point is, that even in the stable fork it takes a while for it to become stablised.

      BTW, don't get me wrong, the guys and gals working on the kernel are a talented bunch and 2.4 is a vast improvement in many ways over 2.2.

  • Small Notes (Score:5, Informative)

    by worldwideweber ( 116531 ) on Wednesday January 30, 2002 @07:45PM (#2928287) Homepage Journal
    (1) If you get any link errors when compiling your new kernel which refer to lock_kernel and unlock_kernel. Just add #include <linux/smp_lock.h> to whatever files generate the complaints.

    (2) If you have any SCSI drives that were broken because of the Block IO Layer changes, then this kernel most likely fixes them. Apparently, the "various scsi driver fixes" includes the parallel port zip driver (ppa.c) for any who care :).
  • Patches!! (Score:5, Informative)

    by The Pi-Guy ( 529892 ) <joshua+slashdot@ ... m ['uaw' in gap]> on Wednesday January 30, 2002 @07:45PM (#2928288) Homepage
    Ok ok ok - we all know that kernel.org's got some cashflow problems, so people PLEASE use the mirrors and patches!! To apply the patch, from the older version, CD in, then use patch -p1 kernel-2.5.3.patch (or whatever.) Make sure to make clean first also, just for paranoia. Anyway, have fun.

    --joshua
    P.S. Not redundant, no one's said this yet.
    • Re:Patches!! (Score:3, Informative)

      by GigsVT ( 208848 )
      You know, the kernel.org guys never claimed cash flow problems, they just wanted another "main site" mirror for redundancy.

      After the outage when /. ran the story, everyone just ASS-U-ME ed that it was cash flow problems, when the LKML archive clearly shows it was just technical difficulties.

      That said, people should be getting diffs when they can anyway, there is no point in wasting bandwidth.
    • Re:Patches!! (Score:3, Insightful)

      by jsse ( 254124 )
      Ok ok ok - we all know that kernel.org's got some cashflow problems, so people PLEASE use the mirrors and patches!!

      I agree, but downloading from kernel.org is just too convenient...I know 90% of people would feel the same. :)

      Btw, while the mirrors are official sites, why couldn't kernel.org automatically redirectly the requests to their mirrors according to clients' origin? I'm sure the cost of running kernel.org would be significantly lowered.

      Technically it's feasible because many people has already done this for commercial servers. Is there any difficulties(political? Legal? Ownership?) make it impossible?

      Just wonder.
      • Re:Patches!! (Score:4, Informative)

        by hpa ( 7948 ) on Wednesday January 30, 2002 @11:06PM (#2929131) Homepage
        Technically it's feasible because many people has already done this for commercial servers. Is there any difficulties(political? Legal? Ownership?) make it impossible?

        The difficulties are administrative/ownership. We (the kernel.org staff) has no real control of the mirrors, so I can't guarantee that any particular mirror is always up to date. For that reason, it seems more fair to let users at least know that they're using a mirror.

        That being said, the mirror system participants provide a huge service, without which we would certainly have bandwidth problems.

        • Just have kernel.org connect to the mirror, see if the filesize matches (assuming we know more or less where to find it, even searching through the kernel directory tree would probably be worth it) and if it does, the mirror is updated and you can add it to the list of mirrors you can redirect to. The bandwidth of listing a couple files should be well spent compared to having lots more downloading directly from kernel.org

          Kjella
    • Re:Patches!! (Score:3, Informative)

      by Phexro ( 9814 )
      a better way to do it:


      $ tar -xzjf linux-x.y.z.tar.bz2
      $ sh ./linux/scripts/patch-kernel ./linux /path/to/patches


      this will apply all the patches in /path/to/patches in the correct order to bring the source tree to the latest version you have a patch for.
  • I want MovieOS! You know MovieOS! It's the operating system used in such movies as Hackers. Where.. you know, you hack into a machine and your face appears on the computer! When does MovieOS become available for public release?
  • by glwtta ( 532858 ) on Wednesday January 30, 2002 @07:46PM (#2928299) Homepage
    Slashdot shouldn't be announcing these! Whine whine whine, bitch bitch bitch... This doesn't belong here!! Waaaahhh!!! This just shows how much slashdot has come down in quality. I hate JonKatz. I don't know how not to click on a link.

    (italics just seemed whinier for some reason)

    Not interested? DON'T CLICK ON THE FUCKING STORY AND DON'T POST TO THE FUCKING DISCUSSION. Get a life. Go outside and play.

    I for one don't check kernel.org daily, I do want to know when the new patches come out, I do check /. daily - is the overwhelming sense of something logical and useful dawning on you yet?

  • by Jacek Poplawski ( 223457 ) on Wednesday January 30, 2002 @07:47PM (#2928300)
    "I just stopped using Windows and now you tell me to use Mirrors?" - said Aunt Tillie, just before compiling 2.5.3 kernel.
  • If anyone is wondering about the future builds of Linux, here they are.

    (This message is long, but hopefully interesting? Please read it!)

    An idea for a "variation on the theme" for version numbers occurred to me a
    while back, but with 2.4 coming soon, this seems like an opportune time to
    suggest it and see if anyone likes it...

    The Linux kernel established the current scheme with version 1.0, and it
    has been widely copied since. (Was it used before then by anyone else?)
    Even numbers in the version number for stable releases and odd numbers for
    development releases has worked quite well. This encodes some meaning into
    the version number, which makes the status of kernel versions easier to
    identify. I'd like to extend this further by adding a digit to development
    version numbers representing the current phase of the development cycle.
    This is easiest to explain by way of an example proposal:

    2.4.xx Current stable release series. (Well, almost current.)

    2.5.0.xx Initial integration -- No architectural changes allowed
    while the inevitable backlog of pending patches from the
    last stabilization effort are integrated and stabilized.
    The final 2.5.0.xx release should be re-released as a new
    2.4.1 stable release. This series should resemble a
    combination of 2.5.8.xx and 2.5.9.xx below, and should be
    suitable for non-mission-critical production use. This is
    a fork from the stable series that re-merges once before
    diverging again for radical development work.

    2.5.1.xx EXTREMELY unstable -- Major architectural changes, any new
    features and major feature changes allowed as the tree is
    thrown wide open for bizarre and wild experimental work,
    much of which may be discarded as experimental prototypes
    prove that some ideas that sounded good weren't so good.
    Suitable only for the extremely brave or foolish. Even
    developers may wish to avoid this series unless they're
    doing the experimenting. Expect constant crashing.

    2.5.2.xx VERY unstable -- Much like 2.5.1.xx series, but experiments
    should a little less wild now. Best time to focus on the
    major architectural changes that are goals for the 2.6.xx
    stable series. Most developers would want to work with
    this series, but not depend on it heavily for daily use.
    Expect nearly constant crashing.

    2.5.3.xx Unstable -- Significant architectural changes, new features
    and major feature changes allowed. Most experimental work
    should be finished by now; new experimental work should be
    developed in a forked tree until suitable for integration
    into development tree. Suitable for developers, should be
    stable for short periods of time. Expect frequent crashes.


    2.5.4.xx Almost stable -- Reasonable architectural changes allowed,
    new features and major feature changes allowed. Suitable
    for developers only, but "bleeding edge" users may want to
    try it out briefly. Expect random crashes, but should be
    stable enough to be more-or-less usable.

    2.5.5.xx Somewhat stable -- Small architectural changes allowed,
    new features and significant feature changes allowed.
    Suitable for developers and "bleeding edge" users only.
    Expected to crash once or twice per day, but should be
    stable for hours at a time.

    2.5.6.xx Reasonably stable -- Minor architectural changes allowed,
    medium feature changes allowed. Suitable for experimental
    servers or the more patient of the average desktop users.
    Not suitable for any production use; may crash several
    times per week.

    2.5.7.xx Mostly stable -- No architectural changes allowed, new
    features and small feature changes allowed. Should be
    suitable for the average desktop user or for a test server.
    Not suitable for most production use; expected to crash
    every few weeks or so.

    2.5.8.xx Initial release candidates -- No architectural changes, and
    only minor feature changes or clean new features allowed.
    Bugfixes and carefully selected patches only. Should be
    suitable for production use only on non-mission-critical
    systems. (This series would be equivalent to "pre" series
    in the past preceding a new stable release series.)

    2.5.9.xx Final release candidates -- No architectural, new features
    or feature changes allowed at all. Bugfixes ONLY; final
    tuning before 2.6.xx stable release series. Final release
    candidates should be almost suitable for production use on
    mission-critical systems, as any stable series release
    should be. (This depends on getting 2.5.8.xx used on some
    production systems first...)
    The 2.5.9.xx series should REPLACE the traditional initial
    stable series stabilization efforts. The final release in
    this series should be re-released as 2.6.0 and 2.7.0.0 with
    no changes but the version number -- if more bugfixes are
    needed, it's not time yet. Only when it's time to fork for
    a new development series should the stable series be
    declared. (This should avoid embarassments like 2.2.0 --
    a "stable" release that crashed rather easily...)
    2.6.xx Next stable release series.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/
    • by BasharTeg ( 71923 ) on Wednesday January 30, 2002 @08:01PM (#2928376) Homepage
      > 2.4.xx Current stable release series. (Well, almost current.)

      (Well, almost stable.)

      Can't argue with the term -series- though.
  • Nice release (Score:3, Interesting)

    by daserver ( 524964 ) on Wednesday January 30, 2002 @07:49PM (#2928316) Homepage
    This is a very nice release. As you can see from the changelog the new ide drivers are finally in 2.5.x. Lets hope this will give Marcelo one more reason to include them in 2.4.x.
    The O(1) Scheduler from Ingo is also in here (version J9) at the moment.

    All of these patches are also available for 2.4.x! Im running aa WM, scheduler O(1) [redhat.com] and the new ide patches right now and have been for more than a wekk without any problems whatsoever. Also for those of you that want to try riks VM [surriel.com] there's also a patch for that.
    Anyway those patches are only for those of you adventoures like me :-). But it has been said that Rik's VM brings the VM back to the -ac13 state.
  • by smak ( 193931 )
    What I want to know is when the new build language takes over ?

    Any idea folks ?
    • Re:CML2 (Score:2, Informative)

      by Ilmari ( 17261 )
      To pick a nit, CML2 [tuxedo.org] is the new config language. The new build system is kubild2.5 [sourceforge.net], developed by Keith Owens.
      • The new build system is kubild2.5

        How do you pronounce that? Cuebild or Coobild?

        BTW, does anyone else think that kbuild sounds like it is somehow related to KDE? Funny how that happens.

  • Damn, no ATA RAID for me, then :)
    This one has been reported on the LKML some weeks ago but AFAIK now fix is made public yet...

    make[3]: Entering directory `/usr/src/linux/drivers/ide'
    ld -m elf_i386 -r -o ide-mod.o ide-taskfile.o ide.o ide-features.o ide-adma.o ide-dma.o ide-pci.o pdc202xx.o via82cxxx.o ide-proc.o
    ld -m elf_i386 -r -o ide-probe-mod.o ide-probe.o ide-geometry.o
    gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -DEXPORT_SYMTAB -c ataraid.c
    ataraid.c: In function `ataraid_ioctl':
    ataraid.c:73: invalid operands to binary &
    ataraid.c:72: warning: `minor' might be used uninitialized in this function
    ataraid.c: In function `ataraid_open':
    ataraid.c:83: invalid operands to binary &
    ataraid.c:82: warning: `minor' might be used uninitialized in this function
    ataraid.c: In function `ataraid_release':
    ataraid.c:94: invalid operands to binary &
    ataraid.c:93: warning: `minor' might be used uninitialized in this function
    ataraid.c: In function `ataraid_make_request':
    ataraid.c:105: structure has no member named `b_rdev'
    ataraid.c:103: warning: `minor' might be used uninitialized in this function
    ataraid.c: In function `ataraid_split_request':
    ataraid.c:182: structure has no member named `b_rsector'
    ataraid.c:193: warning: passing arg 1 of `generic_make_request' makes pointer from integer without a cast
    ataraid.c:193: too many arguments to function `generic_make_request'
    ataraid.c:194: warning: passing arg 1 of `generic_make_request' makes pointer from integer without a cast
    ataraid.c:194: too many arguments to function `generic_make_request'
    ataraid.c: In function `ataraid_register_disk':
    ataraid.c:233: incompatible type for argument 2 of `register_disk'
    ataraid.c: In function `ataraid_init':
    ataraid.c:249: `hardsect_size' undeclared (first use in this function)
    ataraid.c:249: (Each undeclared identifier is reported only once
    ataraid.c:249: for each function it appears in.)
    ataraid.c:280: warning: passing arg 2 of `blk_queue_make_request' from incompatible pointer type
    ataraid.c: In function `ataraid_exit':
    ataraid.c:289: `hardsect_size' undeclared (first use in this function)
    make[3]: *** [ataraid.o] Error 1
    make[3]: Leaving directory `/usr/src/linux/drivers/ide'
    make[2]: *** [first_rule] Error 2
    make[2]: Leaving directory `/usr/src/linux/drivers/ide'
    make[1]: *** [_subdir_ide] Error 2
    make[1]: Leaving directory `/usr/src/linux/drivers'
    make: *** [_dir_drivers] Error 2
  • I got yer patches [patches.org] right here!
  • mirrors (Score:5, Informative)

    by Xandu ( 99419 ) <{matt} {at} {truch.net}> on Wednesday January 30, 2002 @07:53PM (#2928335) Homepage Journal
    Note:

    mirrors.kernel.org [kernel.org] is NOT the list of mirrors of the kernel, it's the list of mirrors of other sites.

    For the kernel, you want www.kernel.org/mirrors/ [kernel.org] to find your local mirror of kernel.org (which is usually www.COUNTRYCODE.kernel.org).
  • by Adnans ( 2862 ) on Wednesday January 30, 2002 @07:58PM (#2928357) Homepage Journal
    But where is XFS? Extended attributes (arbitrary tuples for files) support would be cool. But we need XFS for that since that's the only Linux FS that supports this right now, I think.

  • Google cache? (Score:3, Interesting)

    by Webmoth ( 75878 ) on Wednesday January 30, 2002 @08:05PM (#2928390) Homepage
    It's about time the Google implemented a system to automatically mirror or cache every page linked to on Slashdot (as soon as the link appears) so we have some place to go when the original site gets slashdotted.
    • This gets brought up so many times it should probably be in the FAQ. Maybe it is by now. Slashdot does not link to the google cache because they don't have any arrangement with google, and there is no such deal because they do not want sites that depend on banner impressions (amazingly some folks think banner ads still make money) naming them as a party in a lawsuit that claims they conspired to redirect traffic away from their site. It wouldn't matter if the suit had merit, all it takes is one dot-bomb that decides lawsuit shakedowns are its new revenue stream to make life hell for a lot of people at OSDN.

      'course maybe someone will sue slashdot for linking to them in the first place...
  • Well (Score:2, Funny)

    by /dev/trash ( 182850 )
    Since most of 2.4.x has been pretty much beta why should I go to 2.5 for testing????
  • The 2.0.xx kernel (Score:3, Interesting)

    by deadgoon42 ( 309575 ) on Wednesday January 30, 2002 @08:16PM (#2928443) Journal
    I noticed on kernel.org that there are now listings for the 2.0.xx kernels (sorry if I'm behind the times, I don't check the site every day). Is anyone out there still using the 2.0.xx kernel (or earlier version)? If so, what are the reasons? Maybe a little off topic, but I think it would be interesting to see what's going on with older Linux versions and how they are being used.
  • by IvyMike ( 178408 ) on Wednesday January 30, 2002 @08:19PM (#2928457)

    Yeah, I know, everybody and their mother whines about, "Why does slashdot post new kernel announcements, wah, wah wah!" And I'm going to do the same, but hopefully I'm a litte more constructive.

    What I'd like to see in these announcements is a description of what's changed. Not the changelists; I want the executive summary. Something like "New kernel 2.5.3 released; includes fixes for the FCI bus problems of 2.5.2, as well as the new virtual monitor support!" That would be immensely useful to those of us who don't want to install every kernel and keep track of every new feature, but do like to stay aware of the bigger trends.

    P.S. There is no such thing as the FCI bus or virtual monitor support, as far as I know, it was just an example. But if you're smart enough to come up with the executive summary for this release, please, post it. This time and every time.

    • see that's what the discussion is for! that's why you go and read what people who know what they are talking about have to say about the new kernel, without actually having to install it (ok, most of them don't either, and don't know what they are talking about, but you get the idea); of course most of that is buried under whining, and whining about whining (I do that), and whining about whining about whining (that's starting to be a new thing apparently), but that's why we have this great moderation system - it all makes sense in the end, really!

      I really doubt that one person could compress all the relevant information about a new patch release into one paragraph, especially immediately after the announcement and if that person does other things too; besides you'd only get what JonKatz (for example) thinks of the new kernel release then, which may not always be as informative as you think.

    • Have you tried reading the Linux Weekly News [lwn.net] kernel update? Reading that every week keeps me quite well informed. For instance, this week's (or next week's, depending on how you look at it) kernel page reads [lwn.net]
      The current development kernel release is 2.5.3, which was released on January 30 (changelog). The biggest change in the more recent prepatches has been the split of the massive (> 1MB) Configure.help file into multiple, smaller files spread out over the source tree. This change will make those files easier to maintain (it is hoped); in the mean time, however, it has broken a number of the configuration tools. Other changes include a large ReiserFS update and the inclusion of Nathan Scott's extended attribute patch, which paves the way for access control lists and other useful stuff in the future.
      And it goes on into more detail after that. The previous issue talked about the new ATA drivers.

      (I'm not affiliated with LWN. I just like the service.)

    • A good pace to find this information is Kernel Traffic [zork.net]. It's like a summary of the mailing list.
  • by dimator ( 71399 ) on Wednesday January 30, 2002 @08:25PM (#2928477) Homepage Journal
    Let's run down the list. I'll combine my whoring into one succinct post:
    • Please, people, use the mirrors [kernel.org]! It's only polite, don't /. the main server! (+5 Informative)
    • Please, people, download patches to save bandwidth! I'm so smart and cool! (+5 Informative)
    • Please, people, don't use developmental kernels in production environments. These are only for testing! (+5 Interesting)
    • Since when is /. about software updates? That's what freshmeat is for! I hate slashdot! (+5 Insightful)
    • You assholes that complain about software update stories on /. piss me off. DON'T CLICK ON THE FUCKING LINK, AND DON'T POST TO THE DISCUSSION! (+5 Insightful)


    Did I miss anything?
  • by WIAKywbfatw ( 307557 ) on Wednesday January 30, 2002 @09:06PM (#2928618) Journal
    "Lets go hit those servers!"

    Hitting a server is not a good idea. Hit them too hard and you will break something important and the server will cease to function properly.

    The once lively server will be dead. It won't be resting, it'll be stone dead. It'll have passed on. It'll be no more. It will cease to be!

    It'll have expired and gone to meet its maker. It'll be a stiff. Bereft of life, it'll rest in peace. If it wasn't for the fact that it had been mounted to a rack it'll be pushing up the daisies!

    Its processing cycles will be history. It'll be off the twig. It will have kicked the bucket, shuffled off its mortal coil, run down the curtain and joined the bleedin' choir invisibile!

    IT WILL BE AN EX-SERVER!

    Oh yeah, the sysadmin will be pissed at you too.
  • Have they finally fixed the i810_audi drivers to make them work with the 44.100hz playback rate?

    Looks like I'm going to have my first time unstable ;)

    X
    • I've got a crappy^H^H^H^H^Hlittle asus motherboard at work that's hobbled with one of these horrible i810 chipsets (i815 actually), anyway, the sound has been working on 2.4 for some time now.
  • It really annoys me that you can't count on the Linux developers to write good documentation. When Matt Dillon made his changes to FreeBSD's VM, he wrote up a bunch of documentation explaining it. When Andrea Archangeli did his changes to the Linux VM, he didn't officially document them at all. Now, we have this crazy new bio (block-I/O) layer that's supposed to be all super-cool, but there are no docs explaining how its works!

Real programmers don't bring brown-bag lunches. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.

Working...