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

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux Kernel 2.5.1 is Out 306

Posted by michael from the only-the-brave dept.
xise writes: "The next installment in the 2.5 Linux Kernel beta series, 2.5.1 is avaliable at the usual place Linux Kernel Archives. Remember to use the mirrors. You can read the changelog here."
This discussion has been archived. No new comments can be posted.

Linux Kernel 2.5.1 is Out More

Linux Kernel 2.5.1 is Out

Comments Filter:
  • Does this mean that no more new features will be introduced into the 2.4 series? Or is it only for bug fixes now?
    • New drivers and the like will continue to appear, and some things will get backported from 2.5. But further 2.4 development is likely to be concentrated on bugfixes and not fiddling too much with the core code.

      • Re:2.4? (Score:2, Interesting)

        by Anonymous Coward
        Funny, I always thought that's what the STABLE branch was for....

        It irritates me that linux developers insist on adding new "features" to "stable" kernels, rather than keeping a running development kernel year round. Things like the vm change early in the 2.4 series, and some HUGE, server breaking kernel changes should not appear in a stable kernel.

        Once new features are found, and coded, they should go immediately into the development kernel, and save the stable kernel for bug fixes, driver updates, and security enhancements.

        • Re:2.4? (Score:3, Informative)

          by derek_m ( 125935 )
          Typical anon coward junk.

          The core kernel will remain stable, new drivers will be added where they have no effect on the rest of the kernel - so its the users choice if they want the new drivers or not.

          One of these days the ACs will get a clue ....

          • The core kernel will remain stable, new drivers will be added where they have no effect on the rest of the kernel - so its the users choice if they want the new drivers or not.

            Like the vm changes? That was just a driver change that anyone could swap in or out of the stable 2.4 kernel, eh?

            Yes the anonymous cowards are a pain but sometimes they do make a good point.

        • Re:2.4? (Score:4, Informative)

          by msaavedra ( 29918 ) on Sunday December 16, 2001 @11:07PM (#2713326)
          Funny, I always thought that's what the STABLE branch was for....
          The stable branch is only stable in theory. In practice, the stability of any particular kernel (and any piece of software, for that matter) can only be determined after it has been widely tested in many situations for an extended period of time. However, not nearly enough people run the development and prerelease kernels to really say if the kernel will work right on all hardware in every situation. If you want a stable kernel, wait for a few weeks after a kernel release, and read the linux kernel mailing list and see which versions are stable are which are less so. Most problems are reported there pretty quickly.
          It irritates me that linux developers insist on adding new "features" to "stable" kernels, rather than keeping a running development kernel year round.
          Every kernel has -pre and -ac versions, which are basically the same as having a development kernel year-round. New features don't go straight into a final version of the kernel. And very few new features get added into the stable branch.
          Things like the vm change early in the 2.4 series, and some HUGE, server breaking kernel changes should not appear in a stable kernel.

          The vm change was made because the original 2.4 vm was not performing adequately, and as far as I know the new vm has caused very few problems, but has much better performance. Would you prefer that we all wait 1-2 years before we can use the improved vm in a stable kernel? I'd personally rather sacrifice a few versions of the "stable" branch and get this important change in now. It would have been nice if this was caught before the 2.4 release, but as I said, the number of people running the unstable branch is tiny compared to the number running the stable. Linus has to make a kernel release sometime, he can't just sit and let the same few people test forever, and he sure as hell can't pay huge teams to test each kernel before release. If this is what you want, use the kernel that comes with your favorite distro. These have been tested in this fashion.

          As far as the other "HUGE" changes, I'm not sure what you are referring to. Perhaps the addition of reiserfs and ext3fs? They were tested extensively in 2.3, not just added as an afterthought in 2.4.x. They simply were not ready until slightly after the rest of the kernel, and Linus didn't want to wait for them. Once again, should we have to wait years for journaling file systems when they were already very close to being ready? I see no problem with adding them, and if they scare you, just don't use them.

          Sure, there have been "server breaking kernel changes", most particularly the umount bug in 2.4.15, but this was due to a relatively small change. These thing happen and no changes to Linus's kernel release practices will prevent them. No one is perfect, and whining about it will not change that fact.

    • Should be only bugfixes for now, but I guess it's up to Marcelo.
    • This [lwn.net] current kernel section of LWN has a good overview of some current weirdness of what should be happening with the stable kernel. And here's a quote:

      Where do important changes get tested? One would think that, now that we finally have a development kernel again, non-trivial changes would show up there before being merged into the stable 2.4 series. Thus, there was some surprise when support for "hyperthreading" on PentiumIV processors went into 2.4.17-pre5. That support still does not exist in 2.5, and has thus not seen the wider testing that it could experience there.

      The reasoning behind putting this change into 2.4, as explained [lwn.net] by Alan Cox, is interesting. The claim that normal users will not be affected by the change is standard. But Alan also points out that, due to the ongoing block I/O work, the 2.5 series "isn't usable for that kind of thing in the near future." So, if a feature like hyperthreading is to be tried out, it must be added to the stable kernel series.

  • Perhaps /. is a bad place for this. (Score:2, Interesting)

    by Anonymous Coward
    Not because "slashdot isn't freshmeat," but becaused judging from the outcry from unsophisticated users who updated to the latest STABLE kernel when they probably should have been sticking with vendor supplied kernels, most slashdotters either already know about the releases, or probably shouldn't.

    Any newbie who trys to install 2.5.1 is in for a learning experience (especially if they use SCSI).
    • didn't you read the from line:

      from the only-the-brave dept

      It's obvious that only experienced kernel developers need apply.
    • Lol, yeah. I'm just waiting to handle the pleas for help from those who went and did just that. But since I'm no kernel guru, I'll just have to tell them they're on their own. Shoot, I barely understand SCSI on the 2.4 series. What changed?
      • Shoot, I barely understand SCSI on the 2.4 series. What changed?

        If you read the changelog (see link in /. blurb) you'll see lots of entries from Jens Axboe related to "bio". That's the new block I/O layer which is being born. That in turn means a rewrite of certain portions of all the block drivers, including IDE, SCSI, RAID, floppy, etc.

        Depending on your particular SCSI card, it may or may not work correctly, yet. I haven't been tracking the 2.5.1 prepatches - don't really have a system I can afford to trash - but I understand IDE and a few of the more popular SCSI cards were converted early on and probably work ok by now. But I don't trust that assumption enough to load 2.5.1 on my machine, which doesn't have quite a recent enough backup for my liking..

  • Please remember that the 2.5.x series is a development series and is NOT meant to be deployed in a stable environment. You are to expect bugs and problems with the 2.5.x series and generally it is not recommended that you install it UNLESS you can program and debug kernel stuff.

    You may want to just continue upgrading on the 2.4.x series and wait until 2.6.x is stable.

    -
    • > You are to expect bugs and problems with the
      > 2.5.x series and generally it is not
      > recommended that you install it UNLESS you can
      > program and debug kernel stuff

      They shoulda stuck this warning to the 2.4.x kernels too. ;)

      Sure it's gotten better in 2.4.16, but man it was a rocky road up to that point. Way it seems to me, if there's so little effective difference between a "beta" kernel and a "stable" one, warning about status is kind of irrelevant.

    • Re:This is development! DO NOT DEPLOY (Score:4, Informative)

      by iceburn ( 137875 ) <jmohr44@@@hotmail...com> on Monday December 17, 2001 @12:14AM (#2713495) Homepage
      Actually, I'd have to disagree with the parent post. You should NOT depend on 2.5.x for everyday usage, especially on a production server. You should build it on your home machine or test box and run it for a while to help iron out the bugs. This new-fangled Open Source thing only works if the end users hold up our end of the bargain. They release early and often, and we build and test it. If it doesn't work, try to submit a bug report and help out as best you can, then you can move back to your 2.4.x kernel with a clean concience.
      • You should build it on your home machine or test box and run it for a while to help iron out the bugs


        I agree with you ONLY IF you have a test box. I would not want to risk the data on my everyday use home box. If I had a test box, that is where this kernel would go.


        This new-fangled Open Source thing only works if the end users hold up our end of the bargain. They release early and often, and we build and test it.


        Even of open source users, we don't want them ALL to test stuff. Only those who are 1. Willing to take the risks of using dev. software and 2. Those that have the ability and DESIRE to return bug reports (and believe me when I say this is a more "elite" group than you might think). The trick of open source is that it ALLOWS people who are INTERESTED in the developement of a project to help. It does NOT mean that most people SHOULD. I would not want my girlfriend trying to recompile a kernel and then expect her to try to give a helpfull bug report to lkml. Even the testers of a new developement kernel should be very sophisticated users.

  • One of the key things for 2.4 if I remeber right was SMP support. Are they going to work on improving SMP support beyond the process level in 2.5? What could one list as the 'key bullet points' for 2.5 if talking to a manager type for futures of the Linux kernal?

    • Re:What are the new things they are working on? (Score:5, Informative)

      by chabotc ( 22496 ) <`chabotc' `at' `gmail.com'> on Sunday December 16, 2001 @10:20PM (#2713189) Homepage
      There are currently a few sub-projects going on for 2.5 to improve SMP/scalability on big iron.

      It seens every top-kernel developer or company has a different aproach, so its not clear which will be the one being picked (prolly a combination of patches)

      IBM has a patch to do a per-cpu que of tasks, allowing better scaling of the scheduler. This causes a lot of the task scheduler to be re-written

      Alan has a in-between solution with 8 que's (no matter the amount of CPU's), and a small part scheduler rewrite.

      Some other ppl have different aproaches to it all, cant remember their perspective on it (check LKM archives if ur interested).

      However the main point (as pointed out by alan and linus) seems to be: 99% of the linux boxes out there run only 3 concurent running tasks, so the scheduler has to remain optimized for this situation (!). The current scheduler handles this situation very well. So any updates and fixes are prolly likely to be non-intrusive to the current scheduler ;-)

      • Re:What are the new things they are working on? (Score:4, Interesting)

        by KidSock ( 150684 ) on Sunday December 16, 2001 @10:49PM (#2713277)
        99% of the linux boxes out there run only 3 concurent running tasks, so the scheduler has to remain optimized for this situation

        Interesting. But could this measurement be simplified to the point of being off base? A large percentage of these machines are webservers sitting idle so what do they care about scheduler optimizations? Same thoughts for single process number cruching ray tracing server farms. Shouldn't the focus be optimizing tasks that will benifit from being optimized? I know we have a few boxes that just run Java apps. I bet they would benifit from a new scheduler if the machine were a 4 way. So what are the bulk of these 99 out of 100 machines doing? They're not desktops.

        Also, what prevents Kernel developers from optimizing the scheduler for a Kernel development workstation :-P
        • Actualy when i check my ps aux / top on my desktop, i do indeed find between 2 and 4 processes in 'R' state (running). The rest is waiting for input (be it disk, user, video, whaterver).

          Remeber that very few desktop applications use all CPU slices (this would be very bad), but just respond on input, or play a mp3 or so (which is minimal cpu usage, it will be waiting for a timer event most of the time)

        • Hmmmm...[So I know next to nothing about how the kernel does its work.]

          With that qualification made in advance, I'll ask this question:

          Why can't the
          different process schedulers that might be appropriate to different work mixes, if they are significantly different algorithms, be loadable kernel modules?
          Is it that the code necessarily bleeds into too many routines? Is VM management similarly impractical to shove into a loadable kernel module?

          Apologies in advance if the question is too dumb.

      • Perhaps. Certainly on my home box I don't normally run LOTS of tasks. Maybe 5 files downloading, a terminal to check on statuses. Perhaps a compilation, and a game (say, FreeCell), so I don't start up anything else while waiting for things to finish. (This is a report from last night.)

        Most of the time I only have a quite small number of things happening. But during those times, the machine isn't busy anyway. But when I have several things happening at once, that's when the machine gets busy, so it needs the best scheduling.
  • Is this next? Why do submissions like new versions of devel-kernels make it into Slashdot at all? It's not as if most users will download this and deploy it on ANY system.

    I also don't see announcements of FreeBSD beta, only RELEASES. And it should stay that way.

    • FreeBSD probably has a more sensible policy here (Score:4, Insightful)

      by absurd_spork ( 454513 ) on Monday December 17, 2001 @03:50AM (#2713902) Homepage
      I also don't see announcements of FreeBSD beta, only RELEASES. And it should stay that way.


      This is mainly because FreeBSD does not assign flashy version numbers to their betas, only to releases. For a current beta, grab the FreeBSD-current [freebsd.org] distribution, and you're up to date. If you don't know how to do that, then it's not for you anyway.

      They don't advertize that, and I think it's a good idea not to do so, because it saves a lot of end users a lot of trouble. There's an extra section in the FreeBSD manual [freebsd.org] saying that the -current distribution is not "a fast-track to getting pre-release bits because you heard there is some cool new feature in there and you want to be the first on your block to have it", and that sums it up quite well. Better than assigning 5.0.7b1-BETA and waiting for end user complaints to pour in, anyway.
      • What follows is a kernel newbie's comment on the development of BSD and Linux kernels.

        BSD kernel development and Linux kernel development seem to be examples of two very different paradigms[1]

        FreeBSD[2] kernel development, bug tracking and fixing appear to be very formal, resulting in a rather sedate evolution. Linux versions of the same thing, although every bit as centralised as BSD projects (or even more so, because Linus decides what goes into the release), appears to be much less formal--I can find no Linux equivalent of FreeBSD's bug tracking system. [freebsd.org]

        The FreeBSD project does also appear to have more rigid project management. It's also much more of a single entity, too. Whereas the Linux kernel project is distinct from the distributions that use it, typically a BSD project includes management of everything from kernel development through package management to documentation, promotion and distribution of source media.

        [1] Sorry for dumping the p-word on you without warning there, but I think it's merited in this case [G,D&R].

        [2] Taking FreeBSD as an example of a BSD project.

    • I also don't see announcements of FreeBSD beta, only RELEASES. And it should stay that way.
      If we stopped posting about Linux betas and devel releases, then the only OS we'd hear about non-production-ready builds would be MS-Windows...arguably, every MS-Windows story is about non-production ready builds ;-)
  • So what new features will we see in 2.5.x? Is there a roadmap somewhere?

    • Re:New in 2.5.x? (Score:3, Informative)

      by be-fan ( 61476 )
      There was a kernel summit [lwn.net] about 2.5. I've also heard that they are working on lower latency (either through preemption or breaking up long no-preempt regions) and integrating ALSA.
    • Well, Linus doesn't make a roadmap; I think he feels it is counter to the Linux development methodology and would be unproductive. What gets put in the 2.5 series depends upon what patches people decide to submit.

      That said, I've read that the stuff that Linus WANTS to put into the new kernel include features for NUMA machines and stuff to improve scheduling abilities for embedded systems. Both of those probably mean a higher focus on making things SMP safe, and possibly work on making the kernel more preemtible. One thing Linus has said he will make sure of is that performance on uniprocessors and small SMP's doesn't suffer much as a result of this.

      Besides that, we can expect support for more devices, tons of bug-fixes, probably some more journalling filesystems, and all the other stuff that comes with Linux slowly maturing.

  • The mirrors (Score:5, Informative)

    by djn ( 118825 ) on Sunday December 16, 2001 @10:11PM (#2713161) Homepage
    Folks, the kernel mirrors are not at mirrors.kernel.org.

    The proper site for mirrors of the Linux Kernel is here [kernel.org].

    Here's a quick link [kernel.org] to those of you looking for US-based mirrors.

    -dan
    into unix and punk? check out unixpunx.org
  • Can't they fix the 2.4.x bug which loves to chew up a ton of pagecache?!? Just cut that thing down...
  • I have to support some of those old monsters. Does anyone know what the story is on the seperate driver issue? Considering the amount of effort it took to learn how to configure those boogers, I'm a little bummed that all that effort is going to waste.
    • Kill Smart Tags:
      meta name="MSSmartTagsPreventParsing" content="TRUE"

      Is this true?
    • Run the latest 2.4 - or upgrade your hardware, you can get new tulip cards (the netgear FA310TX for example) for 15 bucks, Or... I'm sure there will be a patch when 2.6 comes out.

      but I mean... Would it kill you to run 2.4.xx when 2.6 is out? I mean, bugfixes are still being applied to the 2.2 kernel...
      • Actually, as to the new tulip card issue, the problem with that is that the "cards" are actually integrated with some ancient DEC mainboards I take care of. I can always put extra cards into them, but it quickly turns into a hassle dealing with the second NIC (considering it takes about two hours to recompile a kernel on one of these things when I screw one up, and ordinary configuration is anything but fast)

        Of course, it wouldn't hurt at all to just leave them as they are, but what I'm really hoping for is one thing: more effecient IO processing. On machines this old, even a marginal improvement makes a big difference. And on the budget I have to work with, disposal is not an option.
        • considering it takes about two hours to recompile a kernel on one of these things when I screw one up

          Well then you should just compile the kernel on another machine and copy it across :-) Even if you have screwed the network access you can get a kernel across on a floppy (if you want to bring the source etc. over aswell I guess it better be a CDR(W).
    • Afaik there are 2 tulip drivers, tulip.o and de4x5.o. I believe tulip.o is the old driver.
      This would mean that your old tulip cards are only supported with tulip.o, and not anymore by de4x5.o.

      Or I'm wrong, and the reference to "old driver" is a reference to Donald Becker's tulip.o driver, which isn't included in 2.4 or 2.5. I believe that came with the 2.2 kernel and only supports 2.4 since recently.

      There are lots of different tulip cards. On 2.2.17 and earlier linksys cards had lots of troubles with the kernel drivers, and always came with their own drivers. For newbies that sucks.
      I think it's a good thing to seperate some of the drivers.
    • I have to support some of those old monsters. Does anyone know what the story is on the seperate driver issue? Considering the amount of effort it took to learn how to configure those boogers, I'm a little bummed that all that effort is going to waste.

      'tulip' as I'm sure you know supports quite an array of chips and cards - from the original DEC 21040 through the 10/100 2114x and several "imitation" chips. Not only that, but the other hardware on a tulip card can vary in minor but annoying ways.

      What seems to be happening is that the kernel people (Jeff Garzik probably) are getting tired of supporting all those configurations in a single driver. Thus the older chips and configurations will go in one driver and the newer ones in another. The old driver will need very little maintenance since it won't have to support any new hardware in the future.

      This is similar to what happened with the NE2000 driver - long ago it was split up into a legacy (ISA etc) driver and a PCI driver. See also the various NCR SCSI drivers.

      Upshot is, you just need to pick the correct driver for your hardware. Then do whatever it is you need to do currently to set up your card correctly (media settings?).

  • Can anyone tell me what is happening to Alan Cox's -AC releases? He hasn't posted a new one since 2.4.13-ac8, and I can't find anything saying he's stopped or whatever.

    • Re:-AC? (Score:4, Informative)

      by captredballs ( 71364 ) on Sunday December 16, 2001 @11:15PM (#2713350) Homepage
      Alan Cox no longer maintains [slashdot.org] the 2.4 kernel. He wanted to be more involved in 2.5 development and handed the job over to Marcelo Tosatti [slashdot.org].
      • Alan *never* maintained 2.4.X, he maintains 2.2.X to this day, you can even see a changelog recently involving some weird DMCA secrets withheld from the general populace (do a diff lay-Z people ;p) from 2.2.19 to 2.2.20.

        The -AC 2.4.X were a testing ground largely for his endeavors to merge as much as possible into the kernel above and beyond Linus' stable-er or more conservative (an approach which is subjective; some such as Alan see the new VM as avant guard) merging approach. I think that part of the aggressive merging going on in 2.4 with the -AC branch seeks to give RedHat the leg up on other distros with regard to the feature-laden-ness of the RedHat official kernel. For example, the RedHat 2.4.9 kernel release that is RPM-able (RPM KERNEL ARE EVIL ;p) contains EXT3 (as does the original RH7.2 kernel modification of 2.4.7). This was considerably sooner than 2.4.15. While Alan's 2.4 work is invaluable, he was not the maintainer.

        The maintenance of 2.4.X was handed off to Marcelo at 2.4.15 by Linus, according to "The Linux Portaloo" written by Cox sporadically, there was some confabulation regarding who would maintain 2.4. According to some recent posts, Alan fully intends on continuing his tireless and aggressive merges, but in the tie being he is, by my speculation, busy digesting the 2.5.X roadmap and rewriting SCSI drivers (:

        As far as the 2.5 kernels go, try them out, complain to the right people, and make sure to love Linux as well should.

        -Z
  • Reading the change logs, and there's lots of "bio" in there. What's that? Basic I/O?
    • Reading down a bit further in the logs, it seems to be "Block I/O". Now I know. :-)
      • Reading down a bit further in the logs, it seems to be "Block I/O". Now I know. :-)

        Yup, a shiny new block device layer, supposed to scale better on big boxes. It required significant changes to all block drivers, meaning all the hardware drivers for IDE, SCSI, RAID, floppy, etc.

        This is what makes 2.5.1 a "caution, do not try this at home" development kernel. The early kernels in 2.3 were pretty tame by comparison - the big breakage there (the Great Page Cache Migration) didn't happen until I think 2.3.7.

  • Argh(Argh()) (Score:5, Funny)

    by matticus ( 93537 ) on Sunday December 16, 2001 @10:54PM (#2713292) Homepage
    There are 5 standard replies every time slashdot lists a new kernel release.
    • Only the brave need apply! This is not for servers! Blah Blah!
    • Slashdot shouldn't post this!
    • So exactly what has changed?
    • My uptime! Argh!
    • There are 5 standard replies every time...

  • Upgrading (Score:4, Funny)

    by Zog ( 12506 ) <israelshirkNO@SPAMgmail.com> on Sunday December 16, 2001 @10:55PM (#2713296) Homepage
    I just finally got version 2.0.34 to not make my toaster oven radiate green antimatter. I've heard that 2.4.15-pre14 has this feature built in if I remount my disks enough without syncing and doing lots of little changes to my filesystem - I guess it'd be a bit unorthodox to use that method to make my toaster stop, but it should theoretically work. Does the 2.5 series have this problem solved?

    I kind of got frustrated after trying to patch it for a while, and just let it eat stuff before I finally made myself fix it, but when I sent in the patch, he said it was too big and obfuscated (I'm not quite sure what he meant - BettyLuJane could read it fine if I held her head on for her), but now I have to try all over again? 2.1 or 2.2 I think I could get done before it starts eating the sofa again, but 2.5? It'd eat all the way through the safety systems on all my Acme stuff, and I don't want that to happen again.

    I mean, 2.5 just sounds really big. Does it mean I have to use real names for my variables instead of just my favorite letters? Also, I don't think my toaster liked gcc. It said something about being incompatible with M$ PROPRIETARY ANTIMATTER-GENERATING TOASTER's. I still don't know where that came from, but it all went away when I rewrote the kernel in Visual Basic 2.0+.

    Well, thank you for your time. If you have any suggestions (or if you want to send me a new toaster - I can't really afford a new one quite yet), my email is gheiste.strauss@mickeymouse.com.

    P.S. If it does fix the antimatter problem, does that mean I don't have to worry about it destroying the city anymore? (these guys in suits wouldn't take me seriously when I told them I couldn't figure out what was going on, and they let me go after a couple of years, but I don't like them anymore - they aren't as polite as they used to be)
  • Home Alone 2 is on TV and after watching all of the terrible accidents that the bad guys go through I now realize why I don't attempt to update Linux myself, especially a development version. I could practically kill myself in the process, and it would be by my doing.

  • Don't overdo the caution (Score:5, Funny)

    by The Pim ( 140414 ) on Sunday December 16, 2001 @11:14PM (#2713348)
    from the only-the-brave dept.

    Ok, this is a development kernel, so you shouldn't just jump in as if it were a stable release. But keep in mind that this is only 2.5.1, where 2.5.0 == 2.4.15, a stable kernel. Since it's only been one revision, it can't have destabilized that much.

    A quick primer on kernel engineering might help. You know how the 2.4.x series solidified release by excruciating release? Well, the 2.5.x series is the same, only in reverse. It takes as much work to destabilize a kernel as it did to stabilize it, so don't expect crashes and corruption right away. In fact, just as a few 2.4.x releases were regressions, 2.5.1 might even be stabler than 2.5.0. That would be an accident, though, and the developers try to prevent it.

    To the Slashdot editors: You can dispense only so much over-caution before the readers decide you're crying wolf. As a community, we need to save up our restraint for the real hour of need, when the siren song of exotic new features lures even the most stolid administrator from the doldrums of predictable stability, into the roiling churn of highly evolved breakage. I would recommend toning down the warnings for now, and becoming progressively more shrill as the kernel hits its maximal instability.

    • Since it's only been one revision, it can't have destabilized that much.

      2.5.1 introduces major changes to the block device layer, a rather crucial bit of code. Bugs in that code might well eat your data. In fact, it's a good idea to put the dangerous changes in early rather than in a late phase of development.

      It takes as much work to destabilize a kernel as it did to stabilize it

      Absolutely untrue, as any programmer knows. It takes a lot of hard work to make something stable, but it only takes a one-character change at the wrong place to destabilize the system for all users (cf. 2.4.15).

    • Good god, people, if you couldn't read that one, the terrorists have already won! It was not interesting or insightful or overrated or any of the less polite things suggested by other posters. It was FUNNY.

      Please, restore my faith in humanity by reading it again and at least pretending to laugh if you still don't get it.

  • I think you guys missed some of the point... (Score:3, Insightful)

    by CMiYC ( 6473 ) on Sunday December 16, 2001 @11:15PM (#2713351) Homepage
    A lot of people seem to be complaining that Slashdot doesn't need to announce a development release... I think that its only being announced because its the first release of 2.5. Kind of like saying "hey, its started, just thought you'd crazy ones would like to know!" I very much doubt we are going to see EVERY 2.5.x release on the front page.

    And if you are one of those complaining... c'mon... grow up. Like it *really* killed you to read one extra headline.

  • Worse than beta (Score:3, Informative)

    by Webmonger ( 24302 ) on Sunday December 16, 2001 @11:18PM (#2713356) Homepage
    This is a development kernel. It's not beta. Beta generally means "feature-complete, but not fully tested". It's not alpha, because alpha usually means "mostly complete". Development means "not complete at all".

    Our company just started on the next release of our software, so I feel a bit "in tune" with where the kernel developers are at.

    The beginning of a new release should be the place where you make all the hard choices and break things. Then you start putting the pieces together, and if you broke the right stuff for the right reasons, it will be better (but probably less stable) than before. Gradually, you add more and more features, but they don't tend to break things as badly. Finally, you stop adding features, and work on polish.

    This is a development kernel, and things are broken because smart people decided to break them. Don't think it's beta. It's not.
  • Was 2.4.x Alpha then?

  • NTFS r/w (Score:3, Interesting)

    by omega9 ( 138280 ) on Monday December 17, 2001 @12:33AM (#2713541)
    I noticed mention of an upgrade to NTFS in the changelogs. I realize it can be argued as a non issue, but is there any real effort to stablize NTFS read/write? At work we're locked in to using W2k domain controllers, and have W2k in a few other places as well. Samba bridges the gap through the network, but in some cases directly mounting an NTFS partition would prove extremely useful. Or is this a non issue?

    • Re:NTFS r/w (Score:5, Informative)

      by ocelotbob ( 173602 ) <ocelot.ocelotbob@org> on Monday December 17, 2001 @12:42AM (#2713583) Homepage
      From what I understand, the NTFS situation is as much a legal problem as it is a technical issue. There are several people willing to hack the NTFS code, but they're currently under NDAs with MS, and as such, can't do anything about fixing the code. However, many of those NDAs are expiring, and people are beginning to hack the filesystem so that write support actually works. As it stands, reading from an NTFS partition works, but writing requires a chkdsk when you next boot Windows, but YMMV.
    • I wonder if NTFS was the first journalling filesystem supported under Linux. That would be amusing, to say the least.
      • Not fully supported. Remember, we've got ext3, jfs, reiserfs, and others with much better records then just read-only stable access with NTFS.

        Oh, and I've been researching more since I posted and if anyone else is interested check here [sourceforge.net] for for Linux-NTFS tools. They have two tools: ntfsfix attempts to repair any damage done when mounting NTFS partitions as r/w (couldn't they just merge the two projects?), and mkntfs allows you to create NTFS partitions. Their not new, but others may be interested in them. I happened to be there doing unrealated research.

        {offtopic}
        Can anyone provide insight as to where file permissions are stored on the drive? Are they stored as part of the header of the file(?) or is there a central location that holds that information? I.E. - if user omega9 has rwx on file.txt, where are the actuall bits that describe "omega9" and "rwx" in relation to "file.txt"? This has been imposibbly hard info to find.
        {/offtopic}
        • It's stored right beside the filename in the directory entry. Headers attached to every file? What do you think this is, MacOS with resource forks that can have metadata? YMMV if you're using something funny like BeOS or MSDOS, of course.
          • That's entirely up to the filesystem. And with ext2fs at least, they are NOT stored right "beside the filename" in the directory entry - they are stored in the i-nodes that are just referenced from the directory entry.
      • I wonder if NTFS was the first journalling filesystem supported under Linux. That would be amusing, to say the least.

        Well ... that depends on

        a) how you define "journalling" - some people consider NTFS to be a "logging" filesystem instead ...

        b) whether you count the fact that the Linux NTFS support doesn't actually journal the write data (which is what makes it so broken, I believe) ...

        c) if point (b) is ok with you, whether you consider a filesystem to be supported before it actually exists. Because ext3 in non-journalling mode was supported ever since ext2 was merged, which was way before NTFS support. (:

  • So when are... (Score:3, Interesting)

    by doorbot.com ( 184378 ) on Monday December 17, 2001 @03:38AM (#2713888) Journal
    XFS and JFS supposed to be merged into the kernel? I saw a post a while back on Slashdot that claimed Linus wanted IBM/SGI/etc to wait for 2.5. Well 2.5 is here...

    So the 64000 Euro question is... when are we getting ACL support? I've heard the IBM solution was good, but required a lot of kernel patches -- but that's what development kernels are all about!
    • So the 64000 Euro question is... when are we getting ACL support?


      You're probably going to have to offer more than $1.37 to get someone to hack that for you.

Slashdot Top Deals

"The only way for a reporter to look at a politician is down." -- H.L. Mencken

Close