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

 


Forgot your password?
Close
typodupeerror
×
Programming Software Linux IT Technology

Linux Kernel Release Numbering Revisited 93

Posted by Zonk from the important-minutia dept.
An anonymous reader writes "KernelTrap has a summary of a lengthy discussion on the Linux kernel mailing list, in which Linus Torvalds has suggested using an alternative numbering scheme for kernel development. The current 2.6 kernel has been different than older development trees, as active development has been happening at a rapid rate in the officially "stable" kernel, instead of forking the expected 2.7 "development branch" for this effort. In Linus' latest proposal, he suggests using the same odd and even arrangement where an odd number signifies a development release, and an even number signifies a stable release. The difference being that this will all happen under 2.6 and thus at a much more rapid rate. For example, the upcoming 2.6.12 release would focus on fixing bugs and thus be more stable, while the following 2.6.13 release would include new functionality and thus could be less stable."
This discussion has been archived. No new comments can be posted.

Linux Kernel Release Numbering Revisited More

Linux Kernel Release Numbering Revisited

Comments Filter:
  • Just call the next kernel Linux XP. Worked for Microsoft!

  • that's what -rcX is for (Score:3, Interesting)

    by rsw ( 70577 ) on Thursday March 03, 2005 @01:48PM (#11835735) Homepage
    Why not add new functionality in release candidates, and only make it an official release once it's stable?

    -rsw
    • Because there is too much changing too quickly.

      Basically, problems are found that need to be fixed before new functionality that is in an RC has really been tested.

      If you want a stable kernel that you don't have time to mess with every week, then stick to the 2.4.x series.

      • Stable kernels is what Stable series used to be about.
        Who cares if changes are quickly in the stable branch if the branch really is unstable and never stabilizes?
        This just means you can't use a vanilla Linux kernel. You are forced to use patched kernels from large distros (those endorsing OSDL??), and hope they _really_ do their job, or stick with 2.4...
        I'm not against short release cycles. But kernels won't be nearly as stable as they become in earlier stable branches... 2.2.16 or 2.4.18 were rock solid ke

    • chicken/egg (Score:3, Interesting)

      by smittyoneeach ( 243267 ) *
      No one wants to mess with a new kernel until it's stable.
      The ALSA drivers were held up as an example of something that worked until it hit userland, and suddenly, ALSA was salsa on Thinkpads.
      The marketing question *gasp* becomes, How do we entice users into compiling and testing on broader architectures?
      Actually, Gentoo, for one, at least makes it semi-manageable to have a fistful of kernels--I may actually emerge something for fun.
      (The agony of getting my 11g with WEP and nVidia all configured has been
      • Of course you could always start the script from /etc/conf.d/local.start

  • 2.7? (Score:2)

    by JVert ( 578547 )
    Does this mean there will be no 2.7? or 2.7 will be based on an odd minor version of 2.6? confused and I cant read it again cause all I see is this: .x.x: Linus went crazy, broke absolutely _everything_, and rewrote
    the kernel to be a microkernel using a special message-passing version
    of Visual Basic. (timeframe: "we expect that he will be released from
    the mental institution in a decade or two").

    • Well, perhaps Linux is maturing enough where it could be 2.6 forever. Solaris has had the SunOS 5.X kernels for a decade or so, now.

      This would be a good thing, IMO. A mature base is necessary to really tackle Windows in the years ahead.

      • Comment removed (Score:5, Insightful)

        by account_deleted ( 4530225 ) on Thursday March 03, 2005 @02:48PM (#11836405)
        Comment removed based on user account deletion

        • Re:2.7? (Score:4, Insightful)

          by greppling ( 601175 ) on Thursday March 03, 2005 @05:36PM (#11838334)
          Well, perhaps Linux is maturing enough where it could be 2.6 forever.

          There is always room for improvement, new ideas, new architectures, hardware, etc that open up new pathways to more flexible or secure operating system organization.

          What you are missing that the linux kernel development process has matured quite a lot. Now there is a steady stream of new features into 2.6. There is no backlog of huge patches that introduce new features and are available only in vendor kernels.

          I wouldn't bet a lot of money on it, but I wouldn't be surprised if the current kernel in 5 years was 2.6.xx (which still would look completely different to current 2.6.11).

          • I think this is a big mistake. It changes the meaning of the numbering scheme to no useful end. There is no good reason that we should not have separate stable and development branches. There are many good reasons why such a division should exist, however.

            One thing I am not clear on is how the backported features are tested. Are they just someone's patchset until the bugs are worked out, or are they backported to the development release before the release you're updating and tested before the stable relea

          • I've generally found the current 2.6 series to be reasonably solid, but I can't say I've been entirely happy with the way development has happened over the hast few "stable" releases.

            I've had a policy of using mainstream brand-name hardware components for some years for ease of configuration, but using "make oldconfig" on a basis of a known-to-be-good .config file has left me with devices not working (properly) with 2.6.8, 2.6.8.1 and 2.6.10. However, 2.6.5, 2.6.7 and 2.6.9 all worked fine. I was beginning

        • It's hard to argue against "improvement, new ideas, new architectures, hardware, etc" but I'll toss one thing in: we are talking about the kernel here, and not the whole system.

          That's why I would disagree with the Windows 95 comparison (not the only reason ;) ). Looking at the GNU/Linux system, yeah- there's room for improvement, new ideas, etc., but in a different way than for the kernel.

          Linus himself has said in interviews that he sees the kernel overall as becoming more stable, and that the next big r
        • For the grandparent, it was announced back when 2.6.1 or so was released that there would be no 2.7.x. 2.6.x would be used as development releases, however there would be no official "stable" version, the distributions had to decide which were stable enough for their OSes.

          So, how long until Linus admits that this was a mistake ? It was the right decision initially, and I think the 2.6 kernel is better now for it, but it's not feasible in the long run. People want a stable branch, especially if this kern
      • Well, perhaps Linux is maturing enough where it could be 2.6 forever.

        Only if Linux had a fixed goal, and it's not the case. Like TeX, that does what it does and that's it: it's perfect, nothing more to envolve. It's version number is converging to "pi", and is now 3.14159 IIRC. Each release adds a new digit. :)
      • "Well, perhaps Linux is maturing enough where it could be 2.6 forever."

        If that were true, my CD drive would work.

        Not a troll: libata doesn't work for PATA drives, but my kernel uses it anyway and reports the CD drive as not supported. Ultimately it proved easier to add a spare Promise ATA card than to fix the problem.

        I've had plenty of problems like this with 2.6, but Linux wouldn't be acceptable as a desktop OS to me without the responsiveness of 2.6. It's the best alternative because Linux has better r
        • "But there's no way I'd let a Linux 2.6 system touch a server. None of the distros that care about stability will touch 2.6 (Debian, Slackware, etc). If I couldn't use OpenBSD, those are the only Linuxes I would touch.

          It's annoying because Linux 2.4 getting pretty long in tooth. This obsession with new features is keeping the kernel that already has lots of good features from being usable."

          This is why you should be using Solaris 10 on your servers ;)
          • "This is why you should be using Solaris 10 on your servers ;)"

            hehe :)

            Well no matter how new it is, I'd trust Solaris to stabalize over time. The issue with Linux is that it's as bad now as it was when 2.6.0 was released.
    • Where is 2.7? I'd like to know this too.

      I read in a recent Linus interview that he is waiting for all major distributions to move to 2.6. How is that suppose to happen if 2.6 is where all development is happening? Wouldn't handing 2.6 off to the Alan Cox's of the Linux world where development is restricted to "fixes" be a better way to encourage the distribution vendors to move, as it has for the all previous "stable" kernels? Distribution vendors are always one release behind the development kernel, a
      • It's explained right there in the blurb: 2.6.even is supposed to be the stable kernel, the one Distro vendors will use. 2.6.odd is the version with new features.

        It's the same as before, just on a more rapid cycle.

        • I swear not every kernel is suitable with every distro. We need to start calling the source 2.6.x.x_redhat, 2.6.x.x_debian or something.

          • Uhm, that is done already. For intance, gentoo calls its kernels "linux-2.6.x-gentoo-rx"

          • Re:2.7? (Score:3, Interesting)

            by kbielefe ( 606566 )

            I swear not every kernel is suitable with every distro.

            Exactly why Linus thought the lack of a 2.7 kernel series would work out. Every distro applies their chosen set of patches to the vanilla kernel, uses their own specific configuration, and does their own testing. Gentoo x86 users can choose from about 10 different kernels, all with the same version number. I'm sure he was thinking that if he didn't do a stable kernel, that the distros would.

            Rolling your own stable kernel isn't that hard to do, esp

            • Can I get this kernel thing from Windows Update? I want to make sure my computer is patched. Thanks!
            • Every distro applies their chosen set of patches to the vanilla kernel, uses their own specific configuration, and does their own testing.

              Slackware doesn't
              I don't

              I make my servers with 2.6.x and mostly slackware.
              I really do wish Linus would atleast put out a 2.6.11u on an "unstable" kernel , and then 2.6.12 for a "stable" one. - telegraph it for the stupid out there.

              ( am I the only one missing out on LKML since ECN was turned on )

  • This would be helpful (Score:4, Interesting)

    by SunFan ( 845761 ) on Thursday March 03, 2005 @01:56PM (#11835832)

    One thing hurting Linux' credibility is that it is hard to predict volatility in it. If it works out that I would know to avoid odd 2.6.x releases, that would be very helpful.

    People want everything, so obviously it's difficult to balance development against stability. This is one area where Solaris has an edge, where even though it takes longer from something to get into the commercial release, at least someone took a look at it before putting it there. Only now has GNOME made it officially into Solaris 10, but there are few issues with it, which is nice.

  • why does it matter? (Score:2, Interesting)

    by capoccia ( 312092 ) *
    why does it matter what the versioning scheme is?
    • Because Linus appoints release managers for each kernel version, and if he gets to keep Andrew Morton around a little longer so they can keep working together on it, he'd like to.

      At least, that's how I see it.
    • It isn't just a question of what to label the kernels, it is mostly about how they are developed. Maintaining software is a constant cycle of adding features, which unavoidably introduce bugs (creating instability), which are then fixed (adding stability). Since open source software is used as it is developed, the timing of each part of that cycle can make a big difference to the user.

      Right now each kernel developer is going through that cycle at their own rate. At any given time, some developers are i

    • why does it matter what the versioning scheme is?

      What it is; not so important.

      People knowing what it is and agreeing on what it should be; yeah, that's pretty important.
  • Do they not want to have a 2.7, does it really need to stay at some version of 2.6.x.x.x forever?

    • Should some major reworking of the guts of the kernel break a lot of stuff, which in turn requires a lot of fixing, then there will be a 2.7 developmental fork to tidy up this and to ease the adoption of the newer systems stuffed into the kernel. It's also possible that 2.6.all.your.base.are.belong.to.us will be renamed 2.7 or 2.8 to simplify the numbers.

      At the moment, there aren't a great number of changes to major kernel architecture -- or at least changes which damage the way other stuff works -- so as

  • I have a much better idea. (Score:4, Interesting)

    by jd ( 1658 ) <imipak@ y a hoo.com> on Thursday March 03, 2005 @02:16PM (#11836069) Homepage Journal
    Let's have two testing phases. Phase 1, the -dev part of the cycle, would be where you have all of the development, adding of new features, breaking of random drivers, etc. Phase 1 finishes when Andrew Morton passes out from shock because all the usable code from his patches has been integrated in the official kernel.


    Phase 2, the -pre part of the cycle, would be where you have the stabilization and verification. It would be less a soft freeze and more a slushy, but the idea is to make sure everything works. Phase 2 finishes when Linus Torvalds is bodily hauled out of the computer room to play five-dimensional scrabble with his kids.


    What you'd end up with is a release that is reasonably stable, AND YET developers would still get to increase the pace of development. You can have it both ways, provided you keep things in sync.

    • Except the problem is that distro maintainers will never include an dev kernel as the default choice. Most end users, especially businesses, don't want any part of a dev kernel. And I don't really understand how your version is different than the old major.even-stable/major.old-dev model.

      I find that less people will use the dev branch and it'll in turn get less testing. Therefore development slows down for stabilities sake. Thus having a labeled dev branch slows development.

      What I think Linus was th
      • I believe he was suggesting that instead of:

        2.6.(2n+1) == add features
        2.6.(2n) == stabilize

        We instead do:

        2.6.n-devK == add features
        2.6.n-preK == fix bugs
        2.6.n == fairly stable

        I get the Linux kernel mailing list delivered to my inbox, and although I don't read it thoroughly, it does seem that there isn't a lot of "only fix bugs" time before a kernel is released. There are even changes between the final "release candidate" and the final version (when generally, a release candidate is a version that
    • The problem with your approach is that phase 1 will never end, and nobody will want to work on phase 2. Andrew Morton's not going to stop writing patches, and neither is anyone else. You've gotta cut the updates off sometime if you want to release within our lifetimes. This means that some good code won't make it in, but it isn't the end of the world if the release cycle is short enough; you can just add it next cycle and it will be in a stable released kernel in a month or two.

      If you look at Linus's p

  • Bigger! (Score:4, Funny)

    by mrbaggs ( 864520 ) on Thursday March 03, 2005 @02:37PM (#11836285)
    They should just put the version numbers up really high. Everything with a high number is popular. Maybe put an XL or a GT on the end for good measure.

  • I like it (Score:4, Insightful)

    by LordNimon ( 85072 ) on Thursday March 03, 2005 @02:40PM (#11836311)
    The problem with major development trees like 2.4.x vs 2.5.x was that the release cycles were too long, and that people hated the back- and forward-porting.

    This is my #1 complaint with the Linux version numbering scheme as it is now. Basically, the version number means nothing. Features are being back-ported to older releases, so that you have "feature gaps" in the releases. For instance, a new feature that was introduced in 2.6.5 could be ported to 2.4.20. What that means is that this feature would exist in versions 2.4.20 through 2.4.29, and 2.6.5 through 2.6.11, but not in 2.6.0 through 2.6.4. The current numbering scheme makes this kind of behavior too tempting.

    I would love to see an end to back-porting of features, from both Linus and the distributions.

    • Re:I like it (Score:4, Informative)

      by Compenguin ( 175952 ) on Thursday March 03, 2005 @03:01PM (#11836553)
      This isn't such an issue if yoyu were migrating from 2.4.20-29 you wouldn't go to 2.6.0-7 you'd go for 8/9/10/11. Thre really isn't a feature gap because even though 2.6.0 is bigger than 2.4.29 it is from a parrellel branch. It was released much earlier than 2.4.29. You really shouldn't be going to a kernel that is significantly chronologiclly older. 2.4.29 is there for people who can't don't want to migrate to 2.6 series kernels. It would be much more chaotic and dangerous to drop the old kernel series as soon as a new one is released. Furthermore, 99% of backports are bug fixes and drivers.
      • What if you're writing a driver that needs to support all 2.4 and 2.6 kernels?
        • Well, its the positive aspect of Open SOurce under GPL.

          Pay somebody who does Linux kernel programming (not cutting teeth on mm or somesuch) to write it for you.

          • I don't need to pay someone else to do my job. What I would like is to have kernel development make more sense, so that I don't have to go through so many hoops to get my drivers to compile.
        • Although its nice to say that your driver supports all 2.4 and 2.6 kernels, the trewth is that the driver doesn't need to support the oldest kernels of a stable series. Furthermore, if the kernel team hadn't backported the feature you want the driver would only work with 2.6 kernels period. So at least you have some 2.4 compatibilty.
          • A lot of the back-ported features are just renaming functions or replacing them with some equivalents. In other words, you don't get any new capability, but you have to change your code anyway.

            And yes, my driver DOES need to support the oldest kernels of a stable series. Our customers use a wide variety of 2.4 and 2.6 kernels.

            • $ grep -i backport ChangeLog-2.4.29
              o [SCTP] Remove sk_xxx macros to be consistent with the rest of networking cod
              e and to avoid backporting issues.
              o [NETFILTER]: Backport fixes for ip6t_LOG
              o [NETFILTER]: Backport fixes for ip6t_dst
              o [NETFILTER]: Backport fixes for ip6t_eui64
              o [NETFILTER]: Backport fixes for ip6t_frag
              o [NETFILTER]: Backport fixes for ip6t_hbh
              o [NETFILTER]: Backport fixes for ip6t_ipv6header
              o [NETFILTER]: Backport fixes for ip6t_multiport
              o [NETFILTER]: Backport fixe
    • Features are being back-ported to older releases, so that you have "feature gaps" in the releases. For instance, a new feature that was introduced in 2.6.5 could be ported to 2.4.20. What that means is that this feature would exist in versions 2.4.20 through 2.4.29, and 2.6.5 through 2.6.11, but not in 2.6.0 through 2.6.4. The current numbering scheme makes this kind of behavior too tempting.

      FreeBSD fixed this problem by using build dates for its patchlevels. If Linux used this scheme, you could have a 2

  • This is good (Score:4, Interesting)

    by Anonymous Coward on Thursday March 03, 2005 @03:49PM (#11837088)
    This would be a good idea. I compiled 2.6.11 this morning on my laptop, and the alsa nm256 driver locks up the machine on boot :(. This has been happening on and off for some time. I found patches in the module developer's cvs that helped me fix it in 2.6.10, but apparently these didn't make it into 2.6.11 (or it got broken in some other way).

    2.6 is great and there are lots of great new features and development in the kernel. But it would be good if some dot releases were only bugfix releases because right now I think 2.6 is much less reliable than late 2.4 kernels were. On my laptop this only serves to annoy me, but I run servers at work (and a webserver @ home), and right now I don't feel confident at all running newer 2.6 kernels on a production server.

  • Not granular enough (Score:4, Insightful)

    by m50d ( 797211 ) on Thursday March 03, 2005 @04:12PM (#11837319) Homepage Journal
    One release is not enough to get all the bugs out of a new feature. You need at least three before you can begin to call it stable. I can see why 2.4/2.5 is considered too long, but 2.6.12 and 2.6.13 isn't enough of a gap. Unless they want to move to lots of use of the fourth number, which I suppose is a possible strategy. 2.6.11 has new features which will be stable by 2.6.12.3. But if they do that there will be too many stable releases, or too many stable releases which aren't actually stable. So I think they need to move to having lots of unstable releases with the same first three version numbers. So we will have 2.6.12.x and 2.6.13.x trees running in parallel like 2.4 and 2.5, but not as separated, maybe 5 or 6 versions under each before moving on to 2.6.14.x and 2.6.15.x. That could work.

  • Asymptote... (Score:2, Funny)

    by physx ( 572283 )
    Anyone got a guess on where the kernel number will converge? I'm looking forward to linux version 3.14159...
  • Why not go back to the good old days? When new version were released very often. Then: 1.3.5->1.3.6->1.3.7 were rapid (ok, maybe its a bad example, but you get the point).

    Now instead its 2.6.11-r3->2.6.11.r4->2.6.11.r5.

    This is just an inflations problem. Why not accept that development is faster now when so much more resources and so many more developers are involved?

    Call it 2.7.1->2.7.2->2.7.3. Release 2.8 in a matter of weeks. When 2.8 is really good, call 2.8.XX final, and go on with
  • While a few developers liked the idea, most preferred to get more serious about the 2.6.x.y idea. And since Greg "the USB-guy" KH and Chris Wright volunteered to maintain it, it seems like this will be taken seriously this time.

    This sounds like the best solution in the best interest of actual users.

  • Just do it the OLD WAY (Score:5, Insightful)

    by Malor ( 3658 ) on Thursday March 03, 2005 @05:57PM (#11838607) Journal
    I do NOT understnnd why he won't just fork off 2.7. 2.6 is unstable and untrustworthy, and it's not going to GET stable until they STOP SCREWING WITH IT.

    Linux 2.4, the last stable kernel, has had 29 versions as of this post. Admittedly, the chaos of the first 10 or 11 releases were from exactly the same kind of stupidity we're seeing now, development continuing in the 'stable' branch.

    Since 2.4.11, there have been EIGHTEEN PATCHES to get 2.4 to the relative stability it's at now, and even so, it's still not as good as 2.2 on a lot of hardware. A single release is NOT ENOUGH to get things stable. 2.4 is still not that robust, on many configurations, after eighteen patches. There's no way that one patch is gonna do it.

    Linux, PLEASE go play in 2.7 and let everyone else get 2.6 stable. It's not trustworthy now, and I will not use 2.6 kernels in any kind of serious production environment because of it. A single release is NOT going to be stable. If you freeze it right this second and branch off to 2.7, the kernel should actually be fairly stable by 2.6.25. With all the extra code in the 2.6 tree, it wouldn't surprise me if it got to 2.6.60 before it was really and truly 'finished'.

    Claiming that 'distributions will make it stable' is basically waving your hand in the air and hoping that other people will fix it, while you madly add new problems by dumping untested code into the 'stable' tree.

    It's not working, and it's not ever going to work. The longer you keep trying to call a development branch 'stable', the more damage you do to Linux.

    • Re:Just do it the OLD WAY (Score:3, Insightful)

      by Xtifr ( 1323 )
      YES!!! I was going to mod you insightful, but decided to post my enthusiastic agreement instead. The two-pronged approach, with the stable branch and the development branch, was one of the most amazing and innovative development models I'd seen in years, and it's proved itself time and time again, not just on the kernel but on other projects as well.

      The 2.6 series has just been a mess. I upgraded briefly, but quickly retreated to 2.4. Frankly, if Linus doesn't go ahead and make himself a new playground
    • This is absolutely correct. New features should NEVER be integrated into an older stable kernel until they are already into a newer stable kernel. In other words, it's okay to backport stuff from 2.4 to 2.2 and kick out a later 2.2 release, that makes some sense although in other senses, people should just bloody go to 2.4. But, putting new things that haven't even been tested into any 2. kernel is ridiculous. Even drivers shouldn't make it into a "stable" kernel until they have had some test time on the un
    • I don't know what exactly is your problem but I have been using 2.6 kernels for a while in my 2 home PC's and on 6 PCs in my company, some 2.6.8 and 2.6.10 and they all work fine.

    • I like Linus' new proposal (and I even thought of this years ago), but I think it is mostly psychological. Bugs will be fixed in both 2.6.even and 2.6.odd releases, but with 2.6.even releases "themed" to be stabilizing bugfix releases, kernel developers will focus more on bugfixes and less on pushing out immat ure features. Plus, the 2.6.even releases will increase the rate of kernel releases, so bugs will get fixed sooner. Currently, some bug in 2.6.10 (let's say) wouldn't get fixed until 2.6.11 and users

      • Re:Just do it the OLD WAY (Score:1, Interesting)

        by Anonymous Coward
        In 2.6, he gave the example of switching from 3-level page tables to 4-level page tables. Linus, that is NOT a minor change!

        Actually, it isn't as big a change as it sounds like. And it is something that, if it breaks will *really* blow up in a big way, not just silent data corruption for 4 people with usb asdf dongles. So it was easy to iron out the bugs in testing.

    • Didn't they make Debian stable for people like you?

      --grendel drago

    • I do NOT understnnd why he won't just fork off 2.7.
      ...
      Linux 2.4, the last stable kernel, has had 29 versions as of this post. Admittedly, the chaos of the first 10 or 11 releases were from exactly the same kind of stupidity we're seeing now, development continuing in the 'stable' branch.

      Since 2.4.11, there have been EIGHTEEN PATCHES to get 2.4 to the relative stability it's at now, and even so, it's still not as good as 2.2 on a lot of hardware.

      Has it occurred to you that having a big development

      • Then they need a longer release-candidate cycle. What they REALLY need is a big bank of machines on which they can run automated test cycles. I would happily contribute both money and hardware to such a cause. Linux is complex enough that it needs QA now. I don't mind testing when I know it's testing. I resent very much being FORCED to test.

        Once a kernel line is declared stable, it should be STABLE... you stop screwing with it! You fix the problems, perhaps backport support for new hardware, and most

  • Multiple branches are a good thing (Score:3, Insightful)

    by maxphunk ( 222449 ) on Thursday March 03, 2005 @11:15PM (#11840972) Journal
    Look at FreeBSD, -STABLE and -CURRENT tags for any given release simply let one know whats up. You can upgrade to -STABLE, and get all your bug/security fixes without worrying about throwing off the system. If you do feel adventurous, you can for -CURRENT... BUT it contains new stuff and should not be used in production. I think Linux needs similar levels of distinction.
    • Ever heard about Debian STABLE and Debian TESTING? Yeah, that's another good example. STABLE is really stable, but not everybody can run "old" software on their machines. I run Debian TESTING (sarge) on my machines, but would run to UNSTABLE (sid) because I don't need bleeding egde updates.
  • I think it makes sense to provide a plan that can set expectations, particularly one that is easily explained. Version numers should rarely change, implying a leap of technology that cannot be represented in the release number. The release number should represent significant changes to the sub-functions, but not on the level that would be considered a technology leap. The modification number would be exactly for patches and incidental changes. The template for this looks like v.rr.mm and mirrors version
  • ...before you write me off, give me a serious listen.

    Spilt off the development of drivers out of the main kernel tree. I great deal of instability arises from the drivers and how they interact with the kernel systems. Virtualize the drivers interface (further tahn it already is), such that the kernel talks through virtual hardware, doing something network related talk to the Vnic. The Vnic would then be interfaced with the actual network driver which is built in a seperate build process. Its coded to talk to the actual hardware, and send back only the things that the kernel actually needs. This is really just an extention of the existing module system...
  • That's because nothing has been added to Linux since 2.4. You've got a bunch of guys tweaking VMs and messing with latency, but really, Linux reached a brick wall a long time ago, and kernel development is really just a research project for really smark hobbyists. 2.4 was important because it brought USB drivers, but nobody has figured out yet how to tune it successfully for the desktop, and what we really need now is wifi drivers, that's the new USB, and it's already 2 years too late. 2.6 should have bee

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close