Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux 2.4.0-test1 Released 179

Posted by Hemos from the almost-2.4 dept.
Chris Cheney writes: "Linux 2.4.0-test1 is out with a note from Linus for more details. Why does all the cool stuff come out after potato is frozen? " With Linus being gone for three weeks, Alan is likely to maintain a 2.4.0-ac series. It's getting closer...
This discussion has been archived. No new comments can be posted.

Linux 2.4.0-test1 Released More

Linux 2.4.0-test1 Released

Comments Filter:

  • Re:How stable is 2.4..... (Score:1)

    by Anonymous Coward
    I am running the 2.3.99-pre series since 2.2.x won't work correctly with my Adaptec card. 2.3.99-prex/2.4.0-testx are stable enough to use, so long as you learn the no-nos and avoid those things till they're fixed. (The two I've hit are: Don't mount a filesystem via loopback; it hangs. VMWare only works with particular versions of 2.3.99-prex.) So, it's usable on a desktop machine. But if you put it on a server or such at this point, you're foolish.

  • AC kernel? (Score:1)

    by Anonymous Coward
    ...Alan likely to maintain a 2.4.0-ac series.

    An Anonymous Coward-series kernel? Has the /. effect finally gone too far? Is it any coincidence that Alan's initials are AC?
  • If I understand it correctly you don't need them unless you're debugging the kernel. So yeah, most people can safely delete them. :-)
  • I feel like such an "old timer" on the Linux scene sometimes, but then I realize that it took a full four years (1991-1994?) just to get to Linux 1.0.

    Then I don't feel like such an old-timer any more.

    - A.P. (props to the old school)
    --


    "One World, one Web, one Program" - Microsoft promotional ad

  • I saw a few similar answers to yours and the all left out a _vitally_important_ step.
    You need to reboot before you build the modules so they can be built under the kernel they are meant for

    Damn... now I have to nitpick...
    On my systems its menuconfig, not menu_config
    make bzImage will build a kernel but won't install it, it will leave it in the build tree (/usr/src/linux/arch/i386/boot specifically (at least for x86 kernels))
    It's possible to use this kernel but you need to install it by hand.
  • I have been ever since I picked up that copy of Linux Journal (I think!) last fall/winter with 2.4 as the cover-feature.

    LOL I was reading something like that yesterday while waiting to get interviewed for an uber-cool linux admin job.

    "If Santa was good to you, you have kernel 2.4......"
    T'was a January issue of a linux rag, not sure if it was Linux Journal though.
  • Well, since nobody else has replied to this one yet, I'll jump in and say that the best thing to do would be to try it and see. :^)
  • do I need to say more? The fact is that red hat makes changing the kernel damn' near impossible w/o installing the next system upgrade. Try replacing the kernel on some of the most recent red hat releases and everything breaks (well....upgrade red hat in general and everything breaks....but that's another issue).


    Who am I?
    Why am here?
    Where is the chocolate?
  • Comment removed based on user account deletion
  • So instead of using the only distribution that seamlessly upgrades itself over the network, you're using which other distribution that's more current? I understand that software released in the past grows old after time, but unless Red Hat, LinuxPPC, Slackware, Turbolinux, Mandrake, and friends each have a time machine, I don't see how their situation would be any different--their releases get old at the same rate as Debians', but they're less convenient to upgrade.

    --
  • I don't know what the previous poster was about but I'm running 2.3.99-pre9 on BP6 with the root partition on a disk hooked to the HPT366/UDMA66 controller.
  • Your comments are generally obnoxious and don't further the discussion. I too had a problem with compiling my first kernel over three years ago and I had read the HOWTO and consulted helpful web pages. It's the little things (and old documentation) that trip most people up. I still don't know what I did wrong the first time, but I luckily did it on a test machine. You seem to have little patience for people without your wealth of experience in all things. Please stay in your ivory tower and continue your post-doc studies until you can be nice and play with the rest of us.


    _damnit_
  • > I saw a few similar answers to yours and the all left out a _vitally_important_ step.
    > You need to reboot before you build the modules so they can be built under the kernel they are meant for

    Ummm no. Modules are compiled against the kernel source, not the running binary. You most certainly do not need to (or want to) reboot before compiling modules.
    --
    Though I use a Macintosh, I am not a mac-bigot. I just hate Windoze.
  • Get this thing fixed already 2.3.x is very much faster than 2.2 and im sick of using buggy software

    So fix it, use 2.2 until 2.4 is actually released (and preferably a few service packs... er... point releases after), or use a different OS. Prerelease software generally tends to be buggy. If you've been running 2.3.x for "a long time now" then you should know this.

    --

  • As far as I can tell the only thing in the directory is the readme. I'm pretty jazzed to try this out and have all the fun and thrills of a not-really-released-yet kernel... but hmmm, no tarball.
    Am I reading Linus' readme incorrectly? Doesn't it say "there's a 2.4.0-test1 kernel here"? I assumed that the "doesn't really exist yet" statement meant that its not really the actual 2.4 release and that the later statement is an exception to "... doesn't exist...".
    Or does the first statement override all later statements?
    Anyway... if anyone knows where it actually is could you let us know?
  • This is off topic, but when will potato be released? It's been frozen since the middle of january, isn't it time to release it already? Would any Debian developers care to comment?
    ___
  • I think 'make config' is the hardest part. And it's the most important bit - if you are happy with the default set of kernel features, why bother to build a new one?
  • i (and probably many of the debian maintainers) would much rather see a kernel that has had almost a year and a half to mature (ie 2.2.x) used in potato than one which is just entering the .0 testing phase. i think trying to cram 2.4.x into potato even if the freeze hadnt happened yet would sacrifice some of debian's well known stability.

    --Siva

    Keyboard not found.
  • What I've always done is just add an entry to lilo.conf that points directly to the compiled kernel in the source tree. call it "test", make it non-default.

    Once you've booted the kernel once and made sure everything works as expected, then cp it to the proper place and make it your default kernel.

    I don't seem to build many non-bootable kernels anymore, but back in my early Linux days I built quite a few.
  • If you haven't already, be sure to read the readme that's linked from the story, it's actually kinda neat to see.

    I mean, while obviously every is going to find it now that it has been mentioned on Slashdot and likely other sites, it's still neat to find something thats sorta hidden like that. :)

    Perhaps I should upgrade my Linux test box, (Stuck on Windows for my main machines, sadly), it looks like it could be neat. :)

    Jerrith
  • Sadly to say, but I haven't looked to see what HOWTO comes with the kernels. I just know that years ago when I complied my first one I printed out the KERNEL-HOWTO and followed it step-by-step. I'm interested to know what HOWTO you are reading that made it seem so complicated?

    ---
  • I'm thinking of giving this a try at home on my RedHat 6.2 desktop. Anything that needs to be updated on 6.2 before attempting to use these kernels?

  • you have to swap in the newly compile System.map file so lilo and your system don't have hissy fits.

    Really? Hmmm... I just always delete the System.map files and run lilo... seems to work just fine.

    I always wondered what they were for :^)

    "Free your mind and your ass will follow"

  • The file you should be editting is the top level kernel Makefile. You have to remove the comment at the start of the line
    #export INSTALL_PATH=/boot
  • I have looked on 3 different mirrors and cannot find it. There is a v2.4 directory, but this just contains the README-2.4 file. The latest I can see in the testing directory is 2.3.99pre10-3. So where is 2.4.0-test1 kernel source?

  • LVM [msede.com] support, and USB support is enough for me. LVM makes disk partitioning and administration MUCH easier. Hello, to playing with new filesystems!

  • A lot of senior developers. We let the newbies slave :-)
  • Hehe...

    That has got to be the funniest thing I have read in a looooooooooong time :-)

    --
    grappler
  • I agree there is a certain amount of difficulty in compiling a new kernel the first time, but a bit of digging and you can find some really useful info.

    Compliling my kernel requires me to enter two lines.

    # make menu_config

    here you configure the kernel

    # make dep clean; make bzImage; make modules; make modules_install; make install

    ok now this build the kernel and the modules. Install's the modules. Create's all the new files in /boot including symlinks for vmlinuz, vmlinuz.old, System.map. It also asks if you want to run lilo, if lilo fails (or you say no) it'll offer to make a boot disk. So long as your /etc/lilo.conf is setup to use /boot/vmlinuz for default kernel /boot/vmlinuz.old for old kernel (i.e. your working kernel) and /boot/System.map you will probably never need to play with /boot or lilo.conf again, especially inexperienced users. How more automated could you want. The problem is none of the distributions seem to do this as standard, and its a shame.


    --

    "I was either onto something, or on something!"

  • I have been using RedHat distro since 5.0 and I have only once had a problem with kernel compile and recompile and it was because I did not follow the instructions correctly.

    Hell, if you only follow MaximumLinux magazine kernel compilation guide, written for utter newbies, you will be able to do the job easily.

    And btw, I have never read kernel-howto.

    Use make xconfig ......
  • Something like your First-Post-ALizer allready exists for Linux... and Slashdot allready has a patch for it...

    No rapid fire posting from a single IP...

    Stopped long before you even started... how sad...

    In the mean time people keep bitch slapping Slashdot for the moderation system it has with out ever once saying what would be reasonable.

    Slashdots moderation system is fine...
    It's people who bombard Slasdot that are the problem...

  • Now's your chance to vote in the kernel 2.4.0 release date poll at http://LinuxNinja.com/ [linuxninja.com]!

    (Okay, polls are lame, and I'm probably going to take a karma hit for this, but c'mon, this story is stale by now anyway). :^)

  • Mr. Blake:

    Please place your attitude where your head apparently resides.

    *If* you are as capable as you imply, why not lend this poor fellow a helping hand and teach him, and many others, something useful. Your comment merely builds the impression that our favorite OS is only for self-important jerks. If that is the case, perhaps I'll switch to something else.

    iceaxe

  • > Oh, I know. I just found it rather funny - something seeming to be hidden comes out front. Nothing really special, I guess.

    Sorry, I didn't mean to sound like I was dissing you. I thought your post was funny too. I was just curious how long it actually took for word to leak out, and I posted it because I thought others might be curious too.

    BTW, my claim of 11-1/2 hours is modulo whatever differences there are in timezones between kernel.org and /..org.

    --
  • >Announced on slashdot is about as bad as it can get :)

    -rw-r--r-- 1 korg korg 639 May 24 19:33 README-2.4
    Well... the secret was safe for a whole 11-1/2 hours. Internet time, no less.

    --
  • > If exchanging a kernel is such a dang-blasted important task for any Linux user to know how to do, why is it so complicated?

    Yeah, they should make it easy like it is under Windows.

    [caveat sarcasm impaired]

    --
  • It Looks like it has been announced now. I haven't been using any of the 2.3.x kernels as I haven't had a need. Now I think I would like to start. Any huge "gotchas" that I should know about before I put this on my backup system?
  • Of course, you're just a troll, since anyone capable of typing in "slashdot.org" in the address field readily knows Java needs a VM and people have tried to write kernels in Java and failed :)

    As for C++ porting, this has been debated and probably still is, but it isn't going to happen because many people feel there's a performance overhead with the added complexity of OO.

    Try, however a "grep goto\ * -r | wc -l" on the kernel sources and you'll be shocked by the extensive usage of "the four letter word". While this is probably efficient, it makes for incomprehensible spaghetti code and should be cleaned up in for 2.5 imho :)

    --
  • That would be:


    make menuconfig

    make-kpkg --revision=your_version kernel_image

    dpkg -i kernel-image-version.deb


    For debian :)

    Greets, Floris
    ------
  • Oh, I know. I just found it rather funny - something seeming to be hidden comes out front. Nothing really special, I guess.

    Dan
    ls: .sig: File not found.
  • There really hasn't been much of a delay between 2.2.x and 2.4.0. Anyone remember how long it took to go from 1.2.13 to 2.0? *That* was a wait.

    At least, it seemed like it to me.

    - A.P.
    --


    "One World, one Web, one Program" - Microsoft promotional ad

  • From the kernel Makefile:

    #
    # INSTALL_PATH specifies where to place the updated kernel and system map
    # images. Uncomment if you want to place them anywhere other than root.

    INSTALL_PATH=/boot


    Fresh from the tarball sources have INSTALL_PATH commented out.. the default is /

    Most distros make boot on seperate partition to get around the 1024 cylinder limitation. IIRC there is a new version of lilo that doesn't have the issue.
  • People like repetition. It's reassuring.

    People like repetition. It's reassuring.

    Yes, I know. I've had a very hard week.

  • I was wondering if someone more aware could let me know where to send bug reports. For some reason, it doesn't seem logical to flood Linus with bug reports, but without joining the kernel mailing lists, how can we post bug reports?

  • What I got from his message was that he compiled and installed the kernel.. but on reboot? his system was unusable.

    I've now recompiled different kernels on various systems well over 100 times. ( Mostly for embeded PC use ) And frankly removing certain drivers or options in the kernel config will build you an unusable kernel. The kernel will hang on boot or do other "interesting" things if you actually get to the login prompt.

    The point is that it's not easy to compile a new kernel if your're trying to customize it in anyway. It's a trial and error type of situaton.

    Of course anyone who is messing with their Kernel should always make sure lilo has a stable kernel to fall back on. Install the new kernel but leave the old one around for emergency boot. Unless the new kernel happens to trash your disk :)

    Ex-Nt-User

  • Are you by chance running a Red Hat distribution?

    Red Hat tends to do things a little bit differently, I believe it has to do with the initial ramdisk (initrd) setup they use to load modules on boot-up.

    Check Here for the Red Hat-specific kernel building HOWTO. [redhat.com]
  • $ less /usr/src/linux/REPORTING-BUGS
  • Java bytecode cannot be run natively.

    Did he say anything about Java bytecode? Java doesn't necessarily imply Java bytecode; see, for example, The GNU Compiler for the Java(tm) Programming Language [cygnus.com], which can either produce bytecode or native machine code. (Yes, it means you don't automatically get Write Once Run Anywhere if you compile to native machine code, but perhaps there are applications where that doesn't matter.)

  • Why is changing the engine in my car so complicated? i bought the damn thing and there's no way i'm going to trade in my ford ka *just* to get a better engine. i bought a new engine that said it would fit, but it's *so* much harder to do then the other things i do with my car (i.e. drive, fill the tank, change the oil, wash it, etc).

    there are all these bolts and screws and the tools! dear god the tools. i need a "hydrolic lift," wtf?!

    i'm tellin' ya, these ford people had better get their act together.
  • Sorry... I feel like i'm beating a dead horse... but this got me:

    1. Why is swapping the Kernel so complicated? Why not automate this more?

    How do you mean automate it more? If you do:

    make menuconfig Maybe this is the problem... but if you use the .config file from redhat or something, then everything is a module anyway...

    make dep

    make clean

    make bzImage

    make modules

    make modules_install

    make bzlilo

    done..... I put all the make statments in to a 'script' and call it "complie." (Orginial, eh?). Then all you have to do is make menuconfig, copy your .config file from the previous kernel (if its the same tree anyway), and then type ./complie...wait 4 or 5 minutes (3 on mine) and then reboot.



    ---

  • Just a comment: I have never used the "*lilo" or "install" targets, since I'm not really sure of what they do. And I like my kernels named after what's in them, so I end up with kernels like /vmlinuz-2.2.13-smp-bigphysarea-3compatch or /vmlinuz-2.2.13-smp-adaptec and so on. Makes it easier to see how they differ.

    And if you have to copy the kernel to a lot of machines, it't easier if you don't have to mess with a bunch of modules, so I usually compile everything I need into the kernel, if I can.

  • Don't use "make bzlilo". Use "make install". "make install" can be customized to fit your distribution by putting a script in /sbin/installkernel.
  • Is there not a gnu parted which does this?
  • If exchanging a kernel is such a dang-blasted important task for any Linux user to know how to do, why is it so complicated?

    I think you're operating from a faulty precept here; who says it's important for any user to know how to do this?

    Any user who *DOESN'T* know how to swap a kernel should be using a distribution such as Red Hat, Mandrake, Caldera etc. where it IS easy to swap a kernel.

    --
  • I sometimes get into this with RedHat.

    Downloading and installing stuff is fine, but part of the reason you choose a distro with a package manager (like RPM or apt) is to have dependancies taken care of. If you install a new version of ssl or gnome or some core package by hand, you've broken your dependancy tree and it's a mess trying to get back on the rails. Especially if you didn't pick the same directories as the package maintainer for your installation.

    • Do you really post as AC, or are you just posting this anonymously because you're afraid that you might actually lose one whole karma point because of the offtopicness? If the latter, please seek professional help.
    • If you really feel that strongly about it, isn't it worth losing a karma point or two, rather than having it buried with a score of 0, where few people will ever see it (assuming it doesn't get moderated up)?
    • Have you considered that some of us moderators often view moderation as a service for the reader rather than a punishment/reward system for the poster? Sure, it's tough luck that the guy posted his remark so soon after an identical one that he probably never even saw the original, but why should the reader have to suffer for his bad luck by having to read the same thing twice? Especially when it's such an obvious post that 75% of the people are already thinking the same quip, with them all scrambling to be the first to actually post it. I say, to the victor go the spoils and "+2, Funny"s, and to the slowpoke go the collective ridicule of the community and "-1, Redundant"s.

    Cheers,
    ZicoKnows@hotmail.com

  • >> I'm just wondering. Who, if not Alan Cox whould maintain the ac (Alan Cox) patch-series? 8-)

    > Why, Anonymous Coward, of course!

    printf("Booting kernel 2.4.0-ac12...\n");
    printf("f1r57 p057!!!\n");
    system.karma -= 1;
    printf("Decompressing vmlinuz...\n");

    --
  • Eric Raymond has hacked up a new kernel configuration scheme that is supposed to be considerably better than the one used today. Too bad it seems to late for it to be used in 2.4, but hey, it looks great [tuxedo.org]! :)
    --
  • I don't believe that any LFS will be in 2.4. They will be add-on patches and a 2.5.0 thing.

    JFS, XFS, and ReiserFS all rely on a layer called pagebuf that hasn't been fully agreed to or implemented yet.

  • Will the patch for 2.3.99-pre5 work for this one?
  • Well, I never found the process complicated or terribly trouble prone. I know this isn't terribly helpful to you.

    The hardest part of teaching is remembering what it is like not to know. Perhaps if you can be more specific about what you found complicated it would help somebody help you.

    I think the complexity, such as it is, comes from PC BIOS. It's a real pain. LILO does a great job in simplifying dealing with this, but it sure is possible to screw things up, and there's lots of stuff that's simply hard to do. Try changing the IDE controller you're booting from, for example. Ugh.

    That said, simply creating a new kernel and booting from it is about as simple as things get. Give the kernel a new file name, and a line for the boot image in lilo.conf, and run lilo. It works like a charm for me.

    Setion 4.4 of the Kernel-HOWTO discusses this, but if you don't have things set up just that way, you need to It's important to read the README in the /usr/doc/lilo-x.xx directory and understand it reasonably well.

  • Why does all the cool stuff come out after potato is frozen?

    Does this seem familiar to anyone (kernel 2.2)? That's the reason I moved away from Debian. Don't get me wrong, Debian is a very cool distro with many innovative and intelligent features (especially the package management system). However, they just can't seem to get on the ball with their releases; as soon as you install one, a lot of your software is instantly old. For my purposes, I can't run the latest unstable or frozen system, so I have no choice but to not use Debian.

  • The "gotchas" I know about:
    There is some kind of bug with networking where the network suddenly dies and you have to reboot, my roommate and I both had problems with it as late as 2.3.99pre5, but another rommate didn't even have a glitch in networking.
    Also there was no new support for Ultra66 (doesn't bother me, I don't have ultra66).

    My questions are:
    Was support for ultra66 added?
    Did the networking bug get tracked down/fixed?
    Does anyone know if ext3 support is included in this version and/or the *real* 2.4?
    Is it any good as far as JFSes go?
    How long before we can expect tools developed for ext3, is there anyone working on that now?
    Will this kernel series have native support for IBM's JFS?

    The reason I'm asking so many questions about JFS is that many companies are not going to Linux because of the lack of a Journaling File System.

    Devil Ducky
  • What a bunch of diddly changes to an already stable system. My need to upgrade = zero.
  • Whoa, this is a genuinly funny post. What exactly makes it off-topic? Humor is never off topic.
  • Actually, even C++ (which is a pretty lightweight resource-wise) OO language needs significant runtime resources. Even in BeOS (Where C++ is modus oparendi in user level stuff) C++ is discouraged for kernel-level stuff (namely drivers and modules)
  • Hello, Linux is mainly a non-Java bytecode CPU. (Yes, I'm being sarcastic, Linux doesn't run on any Java bytecode CPUs.)
  • Damn you Linux zealots are idiots. What is wrong with expecting a NEW distro to come with up to date software? Its not that hard, but unlike you, normal people actually have work to do. They can't spend their entire weekend updating their Linux distro. Does expecting the people who's responsibility it is to maintain the distro to actually maintain it make you less 31337 (Or however it's spelled.)
  • Yo, not everyone is hooked to a T1. Plus, it takes a lot of config to switch a system from 2.0 to 2.2. In addition, a lot of packages need some extra config time in vastly newer versions. This config is not done automatically. It is their job to maintain the distro, not mine. If they don't do it, what the hell is wrong with not using it?
  • Actually, the goto is not a bad thing.

    Not when used correctly, that is. As unconditional jump within a function body, it allows you to handle all exceptions in one place easily.

    For example:
    if(!connect("site"))
    goto error;
    if(!send("string"))
    goto error;
    ....
    error:
    handle_error();

    (Yes, this is simplified)

    As you can see, it saves you from doing the usual solution (calling another function, either passing it the variables or adding to the global variable namespace). This is desireable when performance is critical, or when the recovery is so trivial it does not justify the expense of a function call (ie: you just rewind a stream by one byte). Also, if this code is specific to one function, why make two?

    As another example, any try { } .. catch { } code in C++ is just another example of a goto -- except that it's more structured around specifically handling error conditions within a block of code. The same concept can be applied to C very successfully.

    Of course, this doesn't mean you should go and used hundreds of gotos. That's like using hundreds of for() statements, or while() loops when there is no reason to. And no one really knows what will happen if you goto something in another function (C has no ret instruction equivalent) :-)

    ---
  • I hope this hasn't already been posted, but here [lwn.net] is a pretty convenient and well written list of the new 2.4 features [lwn.net].
  • One of the things that really tick me off is that Linux (or is it just EXT2?) doesn't (as far as I know.. only spent one afternoon trying to find information) have any way to resize partitions after you have made them. This is something that I expect from DOS and windows 9x.. not Linux.

    The only solutions that I found where commercial ones like Partition Magic. Surely there is a place for a Open source project in this department!

    Rami
    --
  • the fact is that there are really all of about 6 comands needed to compile and instal the kernel.
    make config
    make dep
    make clean
    make *Image
    make modules
    make module_install


    The fact is that there are several hundred options that must be addressed in make config.

    Just stop for a second and think of this process on any other OS. It is virtually impossible to build a customized kernel for Windows, NT, MacOS. But on Unices it is not uncommon. It is downright difficult, and the cause of many a seasoned sys admin to pull his hair out to need to rebuild a kernel on Tru64, Solaris, or other commercial Unices. It is SOOOO much easier on linux it is not even funny. Yet still, there are many ways to screw up. You open a strange can of worms when you decide to begin to build kernels.

    If you are like me, you began to build kernels because your hardware was not ordinary. I need reasonable NFS for some machines and that requires patches. I need a development kernel so my laptop Cardbus will work without locking on interrupt conflicts, and that required some fiddling.

    Yet still, when I build a development kernel, it takes 3-4 tries to "get it right". If I am lucky I can build a standard kernel on the first try, but that is not the norm.

    So when someone tries FOR THE FIRST TIME and doesn't quite get it right, I say "You are expecting too much."

    Consider yourself blessed if you have the option to customize a kernel. Consider yourself lucky if you can build one and have it work on the first try. Consider yourself lucky if your system never gets hosed. If that is too much to accept then install the kernel from your distribution. They spend a lot of money and time and effort to ensure that your kernel will not hose your system. Building a development kernel from source is NEVER a low risk endeavor. If you do it lots you will still sometimes get burned.

    There are AMPLE warning about the process in the kernel READMEs. You will ALWAYS see lots of precautions to people who ask about building development kernels. Yet still, sometimes, people ask questions about why it is so difficult to build a kernel under linux.

    So you have to wonder, has this person EVER built a kernel for ANY other OS ?? Why should he think customizing a kernel with HUNDREDS of options should be something failsafe ? When he ignored the README files in his kernel source ?? The initial stance is completely tweaked, and that needs addressing.

    That being said, /. is not a forum for that kind of advice anyway. Take it to comp.os.linux.setup. Read the HOWTOs. Look at every file an /boot and wonder what it is doing. Don't expect it will be easy - it won't. You will make mistakes. You can hose your system. There are ample warnings. There are reasonable alternatives, such as getting prepackaged distributions from vendors.

    And if you suffer. And if you work long and hard at it, you will be able to build successful kernels, most of the time. Sometimes you will still screw up. That's life on the bleeding edge. Why do you think they call it the bleeding edge, anyway ??

    If you want advice, I will tell you to keep an xterm open whil you run make config, and grep a lot in /proc/ to see what options you are currently using. Don't expect it to be easy. Expect that you will screw things up. Keep a boot disk handy, and lots of coffee. Back up your system. And enjoy. There are few things that give more of a sense of accomplishment than building a new kernel to solve some problem specific to your setup.
  • *If* you are as capable as you imply, why not lend this poor fellow a helping hand and teach him, and many others, something useful. Your comment merely builds the impression that our favorite OS is only for self-important jerks. If that is the case, perhaps I'll switch to something else.

    Come on. Someone tries to build a kernel without even looking through HOWTOs, or reading up on how to build kernels at kernelnotes.org. He doesn't know the role of System.map (which will, BTW, not hose your system, just leave you without symbols, generally innocuous).

    The HOWTO says MUCH more than I will ever place in a /. post. He should read the HOWTO, backup his system, brew a lot of coffee, and prepare for a long evening.

    The other alternative is for him to use prepackaged systems that upgrade the kernel for you, such as those from all major OS vendors. Even that is a step beyond what MOST linux users do.

    His, and your, expectancies are a little high. Most users NEVER build a kernel. This is a role that is moving more and more towards the distributions. That being said, building a kernel is a lot easier than other builds, like emacs, or XFree86, or GNOME, or KDE2. Downright simple in comparison.

    If you want to switch to another system because you don't like the attitude of its users, you are using an OS for reasons far different than mine.
  • Get this thing fixed already 2.3.x is very much faster than 2.2 and im sick of using buggy software
    If you are sick of bugy software why are you using test kernels? Switch back to a stable version. To quote from www.kernel.org [kernel.org] "The latest stable version of the Linux kernel is: 2.2.15 "
    Or better yet, how many patches have you submitted? Thats how open source is supposed to work. If you don't like it, fix it yourself or shut up and wait. I'm sure everyone would appreciate it being done sooner, but you to come here and bitch about it not being stable should not be tolerated.
    For the record, I've never submitted a patch to the kernetl, but I've never bitched that the "test" kernels were buggy!
  • There are seriously cool things making their way into the kernel these days. My two favorites are LVM (the logical volume manager: Heinz Maushagen's baby that mimics the capabilities of HPUX and AIX logical volume managers; more info at http://linux.msede.com/lvm/) and ReiserFS (ok, not really in yet, but they're making great progress).

    But there are major problems with really fundamental stuff left. The VM system has been undergoing somewhat fundamental changes in the past week and a half. If 2.4 comes out any time in the next month, I'm waiting for 2.4.5 or 2.4.10 before I put this thing into production.

    Still, with the rewritten pci device interface and cleaner APIs to a bunch of kernel functionality, I'm more excited than ever to start working with the new kernel in development mode at least.
  • It took me a while to find it (the search engine on linuxjournal.com is really not what it should be!) but here's a link:

    http://www2.linuxjournal.com/lj-issues/issue73/3 882.html

    very interesting article. it starts by addressing the first yucky thing i found about python (that whitespace and indentation actually *matter*!). it goes on to convince me that this is a language i really need to learn.
  • Yeah, i havn't bothered to upgrade my kernel either (Outside of changing to a newer distro), but i think it's time for me to compile 2.4. Most of the bugs in the todo list don't seem that serious (for me), the Tulip NIC problem is the only one that might cause problems. And hey, there are bugs in 2.2.x as well...

    If it wasn't for the new /dev stuff, USB and a few other smaller changes, i wouldn't bother either though.
  • Since there's no need to recompile and reinstall modules if you aren't updating them, frequent flyers often skip this step when customizing a kernel (especially on slow machines). This can lead to the following problem:

    If you recompile without changing versions and include less modules in the new kernel, you might get complaints about object files when rebooting. So,

    % cd /lib/modules; rm -rf 2.x.x
    % cd /usr/src/linux
    % make modules; make modules_install
    % reboot
    and the problem goes away. This one is puzzling when you first start making custom kernels, but it is documented.

    I think what the previous poster was referring to is that you won't notice the problem until you reboot, if you don't always reinstall modules.

    ---------///----------
    This post is not redundant, please don't moderate it as such. I repeat, this post is not redundant.

  • It's plenty well documented. There's a HOWTO. There are free Linux books from LDP. Linux is probably the most documented OS in the world, as any search engine will show you.

    I really don't see what is so complicated about this:

    % cd /usr/src/linux; make menuconfig
    [choose your options, then save]
    % make dep && make clean && make bzImage && make bzlilo && reboot

    Is that really so bad? Your lilo complaints are just ignorant: the Kernel-HOWTO does mention zlilo and bzlilo, last time I checked.

    Recompiling a Linux kernel is quite simple compared to other Unices. Coming from an old-style BSD and new SysV background, I find the Linux way to be rather luxurious.

    I'm not trying to flame you. I just think you didn't RTFM. If you fscked up that badly, you didn't read it well enough. And didn't you back up your old kernel first? You didn't make a boot disk, did you? You didn't test the new kernel before "swapping" it, did you? If you've done your homework, Linux is very forgiving.

    I'd be interested in hearing more of your problem. What did you find "complex?" What problem necessitated a full system restoration? Details, please.

    ---------///----------
    This post is not redundant, please don't moderate it as such. I repeat, this post is not redundant.

  • I think this is an appropriate thread to dredge up this old post of mine, from February. I thought this was good enough to save. I think it helps emphasize just how cool a new minor release number is. ;-)

    ///---------------------------------------

    Torvalds begins work on Linux 2.3.48.9.2.7.43, possibly
    Posted by CmdrTaco on Sunday February 27, @10:36AM
    from the rob-sucks-tarballs dept
    Linus Torvalds, creator of Linux, accidentally hit his keyboard with his elbow today. We have yet to receive confirmation that the resulting code will be be included in the next development kernel, but we can never be too sure. Here is the code in full:

    kjnlkmf ,m58u45knm ,9804
    8v793oy5n9*(&V(*N&

    This won't compile under GCC, so we can only assume the code is pretty experimental. Look for the tarballs to be released this evening.

    Torvalds comments, "What? Oh, yeah, I accidentally hit my keyboard with my elbow when I reached to get my tea. What? Is it part of the new kernel? You're kidding, right?"

    We'll update the article as soon as we get more information. The Linux world hasn't been in such frenzied anticipation since the release of kernel 2.3.48.9.2.7.42, which was about ten minutes ago.


    Interview: Alan Cox farted
    Posted by Hemos on Sunday February 27, @10:34AM
    from the whats-that-smell dept
    Linux guru and hacker-extrodinaire Alan Cox farted earlier today. What do you think this says about the future of Linux development? Alan's ass will respond to the highest moderated posts later this week.


    ESR and JonKatz to participate in "Zealot Deathmatch"
    Posted by Roblimo on Sunday February 27, @10:33AM
    from the die-bitch-die dept
    Open source proponent Eric S. Raymond and Slashdot nutcase JonKatz are reportedly organizing a "Zealot Arena Deathmatch" to raise money for the Apache Software Foundation. The fight is expected to be a tough one, because while Katz is genuinely insane, ESR has the power of girly, elfish looks. A spokesman from Apache says that, "while we don't encourage violence, we'll do anything for money."


    VA Linux aquired by Klingons, Rob bows down to new alien masters
    Posted by emmett on Sunday February 27, @10:32AM
    from the star-shit-enterprise dept
    VA Linux Systems, owner of Andover.net, owner of Slashdot.org, owner of Rob's ass, was officially aquired by the Klingon Empire earlier this morning. The Klingons, who have recently taken over Kellogs, GM, and Disney, are looking forward to absorbing more major corporations in the near future. The US Government is discussing investigating the Klingons for holding a monopoly over "every aspect of our lives", to which the Klingons responded, "Puny human scum! I will crush you like a bug and feast upon your steaming entrails." Finally, some competition for Microsoft!


    Red Hat and VA stock at all time high!
    Posted by CmdrTaco on Sunday February 27, @10:31AM
    from the i-am-so-rich dept
    Dude, have you heard the market reports today? I am so fucking rich! If this keeps up, I'll be able to stop doing this Slashdot crap! Hell yeah!

    ---------------------------------------///

    I should really update that last one, though, in light of recent events:

    ///---------------------------------------

    Red Hat and VA stock at all time low...
    Posted by CmdrTaco on Thursday May 25, @10:31AM
    from the i-am-so-fscked dept
    Shit... say, how's the job market for goateed Perl-monkies?

    ---------------------------------------///

    ---------///----------
    This post is not redundant, please don't moderate it as such. I repeat, this post is not redundant.

  • for ordinary users to compile kernels and install new releases.

    It's a magnificent pain in the ass. Get the right compiler and new version of the utilities and make sure all of them are built and properly installed just to find that, say the VM system is still being balanced and the kernel can't be used for useful work right now.

    It's necessary if you want to contribute to testing the new kernel. It's necessary if you have hardware thiat is wither not or poorly supported in stable releases of the kernel.

    But the vast majority of people can get along with their old kernels (perhaps with minor version upgrades i.e. 2.2.5->2.2.15) and wait until the distribution maintainers release a new kernel version to upgrade.

    Anomalous: inconsistent with or deviating from what is usual, normal, or expected
  • Check out BuildKernel, it's an automated bash shell script that can download and install your kernel. If you don't want to configure your kernel, it can use your old .config file from your current kernel. Check out http://users.dhp.com/~whisper/ buildkernel/index.html [dhp.com].

  • And lets face it, Tux would have to be the cutest thing in a Disney movie since...well, since, forever.

  • It's there as plain as day. Linus says:
    "It's not a real 2.4.0 release, but we should be getting closer"

    In other words, this kernel may as well be called 2.3.99pre10 for all that it counts. I hate to make the comparison, but I'm going to: was Win2000 RC1 beta software or was it the final version? It was a beta.
    The same goes for this - in this case I think the 2.4 designation is worth very little. It's still got significant bug levels and people shouldn't be jumping the gun to get at it.

    All MHO, of course.

    --

  • And there is FIPS, working under DOS. I used it when installing my first Linux (a RedHat). Lots of fears before actually trying, but absolutely no problem. Sure, there's no GUI.
  • If you're coming from a 2.2x kernel (I wouldn't suggest the 2.4 test kernel from anything less than a good 2.2 installation) you'll probably want to go grab the latest modutils package... it'll make life easier.. trust me.
  • C++ and Java are the "obvious" choices, even to illiterate Pointy-Haired Bosses, but unfortunately have a need for considerable runtime systems, particularly Java. A JVM requires a memory manager, which leaves you having to lift yourself by your own bootstraps if you write the JVM in Java, and thereby require a JVM and a memory manager, which leaves you recursing infinitely...

    More reasonable alternatives would include:

    • Modula-3 [m3.org], in which is written Spin. [berkeley.edu]
    • Or perhaps Oberon, [oberon.ethz.ch] which has been used to construct several OS-like environments.
    • Or perhaps even Eiffel, [cf.ac.uk] whose Design By Contract [gauss.muc.de] approach makes claims that C++ can provide anything describable as rock solid look very silly.
    • Based on the number of language compilers being built using ML, [bell-labs.com] I'd think it to perhaps be a candidate. The ability to do heavy-duty static type inference would, not unlike with Eiffel, make claims of C++ being "rock solid" look pretty sad.

    Yes, these languages don't have syntax that slavishly resembles C. But it's not as if the actual semantics of C++ or Java are actually that much like C...

  • System requirements (Score:3)

    by Ed Avis ( 5917 ) <ed@membled.com> on Thursday May 25, 2000 @05:17AM (#1049309) Homepage
    What sort of system is needed to run the current 2.3 and 2.4-test kernels? Going from 2.0 to 2.2 was a big jump in memory consumption, although apparently things did improve a little during the late 2.1 series.

    Will I still be able to run the latest kernel on my 8Mbyte machine?
  • From the readme:

    Have fun. And let's see how many people find this without it even being
    announced ;)

    Announced on slashdot is about as bad as it can get :)

    Dan
    ls: .sig: File not found.

  • How to get 2.4.0-test1 (Score:3)

    by darth xenu ( 96256 ) on Thursday May 25, 2000 @04:52AM (#1049311)
    Here's how to get it:

    1. download 2.3.99pre9 from ftp.kernel.org/pub/linux/kernel/v2.3
    2. download the pre10-3 patch from ftp.kernel.org/pub/linux/kernel/testing

    If you look at the pre10-3 patch, it says 2.4.0-test1 in the Makefile.

  • If exchanging a kernel is such a dang-blasted important task for any Linux user to know how to do, why is it so complicated?

    I assume you refer to the difficulty of configuring the kernel correctly, i.e. running make {config|menuconfig|xconfig} and choosing the right options for what you want to do. I give the anwer: it's so complicated because it has to be. With power comes complexity; there really isn't any good, flexible way around that. There are lots of options because people run Linux on lots of different kinds of systems, and not all of them want, for example, SCSI support, or network support, or USB support, etc.

    As near as I, at least, can tell, if you take away the complexity, and the requirement of knowing what you're doing, you'll dramatically decrease the flexibility and (obviously) the configurability of the OS.

    As for Don't say that a 'normal' user doesn't need to do a kernel swap, well, sorry, most users don't need to do a kernel build. They can quite happily wait for RedHat or Debian or SuSE or whomever to release a 2.4.x kernel and download the binaries.

    I compiled from source my first kernel two days ago, and let me tell you: it ain't something that I would recommend any user do.

    It isn't something I would recommend just any user do, either. At least, not without some sort of preparation and due diligence (e.g. read the help files, and don't say yes or no until you know what they're talking about). I'm not trying to imply you didn't prepare and do your due diligence, by the way; I'm agreeing with you.

    1. Why is swapping the Kernel so complicated? Why not automate this more?

    I'm not positive, 'cause I don't use it, but I think that Debian, for example, has automated new kernel builds. I couldn't speak for any other distros, not having used 'em.

    The HOWTO that comes with the kernel source doesn't mention ANYWHERE that you have to swap in the newly compile System.map file so lilo and your system don't have hissy fits.

    I'd agree that that's a problem. I hope you send/sent an e-mail to the HOWTO maintainer.

  • Secret? (Score:4)

    by BlueUnderwear ( 73957 ) on Thursday May 25, 2000 @03:36AM (#1049313)
    Maybe Linus should have put an NDA around that README file. Then he would now have grounds to sue Slashdot!

  • About the Kernel and newer users. (Score:4)

    by Lonesmurf ( 88531 ) on Thursday May 25, 2000 @03:12AM (#1049314) Homepage
    I am no advanced Linux user. I know my way around the system well enough to get by however I do run into problem on an almost regular basis.

    Now that I've made some sort of introduction, I would like to ask a simple question of the Linux using community: If exchanging a kernel is such a dang-blasted important task for any Linux user to know how to do, why is it so complicated?

    [Don't say that a 'normal' user doesn't need to do a kernel swap, it doesn't lead to any interesting discussion. I did it because I wanted to test the USB stacks with some of the devices that my company develops.]

    I compiled from source my first kernel two days ago, and let me tell you: it ain't something that I would recommend any user do. In fact, I royally screwed my system to the point that I had to restore from backup!

    The questions presented:


    1. Why is swapping the Kernel so complicated? Why not automate this more?
    2. Why is the process not better documented? (Don't tell me that it is, because it is not. The HOWTO that comes with the kernel source doesn't mention ANYWHERE that you have to swap in the newly compile System.map file so lilo and your system don't have hissy fits.)


    --

    I realise that some of what i referenced may be a bit off (that System.map thing in particular). Be gentle.

    Rami James
    Pixel Pusher
    ALST R&D Center, IL
    --

  • sounds awfully suspicious... (Score:4)

    by The_Messenger ( 110966 ) on Thursday May 25, 2000 @06:58AM (#1049315) Homepage Journal
    Am I the only one that sees the beginning of a crappy Disney comedy here? Linus goes on "vacation" for three weeks... but never comes back! Poor Alan is left in charge of the rambunctious kernel, and merry hijinks ensue! Linus, meanwhile, lives the high life in Brazil under the alias "Mr. Pinkerton". But back home, an evil Race Condition from Outer Space threatens to destroy all of Linux Land! Thankfully, Linus returns home just in time to save the day. Linus and Alan live happily ever after, with the Race Condition as the family pet!

    McDonald's gets the merchandising deal (Happy Meals come with "Linux Heros" figurines) and Eisner makes another few million.

    The End.

    ---------///----------
    This post is not redundant, please don't moderate it as such. I repeat, this post is not redundant.

  • Guide to moderation for this article (Score:5)

    by Anonymous Coward on Thursday May 25, 2000 @03:15AM (#1049316)

    And another other open source releases announced on /.

    • Informative - poster cut 'n' pasted from the FAQ linked to in the article.
    • Insightful - poster waffled on about how this is a Good Thing for everyone.
    • Interesting - poster asked what was in this release.
    • Funny - poster said anything negative about Microsoft.
    • Offtopic - poster made a good point relating this to something other than Linux.
    • Troll - well-thought out opinion which *gasp* does not praise Open Source, RMS, Linux or other /. "heroes" and which uses full sentances.
    • Flamebait - as above, but without the full sentances.

    Please moderate accordingly, and your crack will be delivered as per usual.

  • Re:Alan likely to maintain 2.4.0-ac series (Score:5)

    by kressb ( 28493 ) on Thursday May 25, 2000 @03:26AM (#1049317) Homepage
    I'm just wondering. Who, if not Alan Cox whould maintain the ac (Alan Cox) patch-series? 8-)

    Why, Anonymous Coward, of course!

  • Alan's Todo list (Score:5)

    by cehf2 ( 101100 ) on Thursday May 25, 2000 @03:11AM (#1049318)
    Before people get their hopes up, you should check out the length of Alan Cox's Todo list. It is not small :(

    Capable Of Corrupting Your FS
    -----------------------------
    E820 memory setup causes crashes/corruption on some laptops
    Use PCI DMA by default in IDE is unsafe on VIA VPx x<3

    Security
    --------
    Fix module remove race bug (mostly done - Al Viro)
    exec loader permissions
    Semaphore races (fix in 2.2)
    Semaphore memory leak (fix in 2.2)
    Exploitable leak in file locking (Willy)
    TTY and N_HDLC layer called poll_wait twice per fd and corrupt memory
    ATM layer calls poll_wait twice per fd and corrupts memory
    Random calls poll_wait twice per fd and corrupts memory
    PCI sound calls poll_wait twice per fd and corrupts memory
    sbus audio calls poll_wait twice per fd and corrupts memory
    access_process_mm oops/lockup if task->mm changes (Manfred) [user can cause deliberately]
    RtSig limit handling bug
    Signals leak kernel memory (security) [FIX in ac tree]

    Boot Time Failures
    ------------------
    IDE fails on some VIA boards (eg the i-opener)
    AHA29xx driver appears to stomp other cards
    Use PCI DMA 'lost interrupt' problem with some hw [which ?]
    (NEC Versa LX with PIIX tuning)
    HT6560/UMC8672 ide sets up stuff too early (before region stuff can be done)
    Crashes on boot on some Compaqs ? (may be fixed)
    IBM MCA driver breaks on Device_Inquiry at boot
    DEFXX driver appears broken
    ACPI hangs on boot for some systems

    In Progress
    -----------
    Dcache threading (Al Viro)
    Merge the network fixes (DaveM)
    Finish I2O merge (Intel/Alan)
    Fix all remaining PCI code to use new resources and enable_Device (mostly done)

    Fix Exists But Isnt Merged
    --------------------------
    Update SGI VisWS to new-style IRQ handling (Ingo)
    64bit lockf support
    Support MP table above 1Gig (Ingo)
    Finish sorting out VM balancing (Rik Van Riel, Juan Quintela et al)
    Dont panic on boot when meeting HP boxes with wacked APIC table numbering (AC)
    Scheduler bugs in RT (Dimitris)
    Fix eth= command line
    HFS is still broken
    AIC7xxx doesnt work non PCI ? (Doug says OK, new version due anyway)
    8139 + bridging fails
    Fix hpfs_unlink (Al Viro)
    put_user is broken for i386 machines (security) - sem stuff may be wrong too
    BusLogic crashes when you cat /proc/scsi/BusLogic/0 (Robert de Vries)
    Loopback fs hangs

    To Do
    -----
    SHM code corrupts memory
    Floppy driver broken by VFS changes. Other drivers may be too
    (Stuff gets called after _close now - unload race possibly too)
    Tulip hang on rmmod/crashes sometimes
    Devfs races, Sockfs (removing NULL ->i_sb stuf) (Al Viro)
    Restore O_SYNC functionality
    Debian report that the gcc 2.95 possibly miscompiles fault.c or mm/remap.c
    (Perl script available from Arjan)
    Fix further NFS races (Al Viro)
    Trace numerous random crashes in the inode cache
    Test other file systems on write
    The netdev name changing stuff broke GRE
    Audit all char and block drivers to ensure they are safe with the 2.3
    locking - a lot of them are not especially on the open() path.
    Stick lock_kernel() calls around driver with issues to hard to fix nicely
    for 2.4 itself
    PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (may be fixed ?)
    pci_socket crash on unload
    truncate_inode_pages does unsafe page cache operations
    Linux sends a 1K buffer with SCSI inquiries. The ANSI-SCSI limit is 255.
    Linux uses TEST_UNIT_READY to chck for device presence on a PUN/LUN. The
    INQUIRY is the only valid test allowed by the spec.

    To Do But Non Showstopper
    -------------------------
    Make syncppp use new ppp code
    Finish 64bit vfs merges (lockf64 and friends missing)
    NCR5380 isnt smp safe
    DMFE is not SMP safe
    Go through as 2.4pre kicks in and figure what we should mark obsolete for
    the final 2.4
    Union mount (Al Viro)
    Per Process rtsigio limit
    Fix SPX socket code
    Boot hangs on a range of Dell docking stations (Latitude)
    iget abuse in knfsd
    Some people report 2.3.x serial problems
    USB hangs on APM suspend on some machines
    PCMCIA crashes on unloading pci_socket
    ISAPnP IRQ handling failing on SB1000 + resource handling bug
    TB Multisound driver hasnt been updated for new isa I/O totally.
    Fix boards with different TSC per CPU and kill TSC use on them
    DVD-RAM is apparently not working for write currently (Rogier Wolff)

    Compatibility Errors
    --------------------
    Xterm broke in 2.3.99pre6 (FIONREAD/select loop)

    Probably Post 2.4
    -----------------
    per super block write_super needs an async flag
    addres_space needs a VM pressure/flush callback (Ingo)
    per file_op rw_kiovec

    Drivers In 2.2 not 2.4
    ----------------------

    To Check
    --------
    Check O_APPEND atomicity bug fixing is complete
    Protection on isize (sct) [Al Viro mostly done]
    Mikulas claims we need to fix the getblk/mark_buffer_uptodate thing for
    2.3.x as well
    Network block device seems broken by block device changes
    Fbcon races
    VFS?VM - mmap/write deadlock (demo code seems to show lock is there)
    rw sempahores on page faults (mmap_sem)
    kiobuf seperate lock functions/bounce/page_address fixes
    Fix routing by fwmark
    Some FB drivers check the A000 area and find it busy then bomb out
    rw semaphores on inodes to fix read/truncate races ? [Probably fixed]
    Not all device drivers are safe now the write inode lock isnt taken on write
    File locking needs checking for races
    Multiwrite IDE breaks on a disk error [minor issue at best]
    ACPI/APM suspend issue - IDE related stuff ?
    NFS bugs are fixed
    Floppy last block cache flush error
    Chase reports of SMB not working
    Locking on getcwd
    floppy fails on some machines
    IRDA calls get random bytes before random is set up
    Some AWE cards are not being found by ISAPnP ??
    SHM segments not always being detached and destroyed right ?
  • Interestingly enough, Eric Raymond just yesterday posted that he has produced a beta version of a new configuration and build management system for the kernel.

    Since he's known for metalanguages and minilanguages (computer languages of minimal scope), not surprisingly, he rewrote the configuration management language used to control kernel builds.

    Two relevant points here, though:

    1) I don't think that this will help your situation of *installing* rather than *building* a new kernel.

    2) It's written in Python. If you read ESR's piece in Linux Journal last month, this is no surprise at all, but the reception on the kernel list was decidedly cool, on balance. ESR held his own with arguments about 'freeze' which can produce compilable C code from a python program (albeit somewhat inelegantly) and arguments about the existing perl and tk/tcl dependencies that are already in the kernel build system, but there was still widespread (and sometimes unprincipled) opposition to the whole idea of using Python at all.

    I doubt that the new config system will get incorporated until 2.5, though.

  • Alan likely to maintain 2.4.0-ac series (Score:5)

    by kaunio ( 125290 ) on Thursday May 25, 2000 @03:12AM (#1049320) Homepage
    I'm just wondering. Who, if not Alan Cox whould maintain the ac (Alan Cox) patch-series? 8-)

Slashdot Top Deals

Business is a good game -- lots of competition and minimum of rules. You keep score with money. -- Nolan Bushnell, founder of Atari

Close