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

 


Forgot your password?
Close
typodupeerror
×
Announcements Software Upgrades Linux

2.6.13 Linux Kernel Released 464

Posted by Zonk from the almost-as-good-as-a-kernel-of-corn dept.
LynuxFre@k writes "Linux Torvalds announced the release of the 2.6.13 Linux kernel. He noted that there was a major change to the x86 PCI code, and that while all bugs from the change were believed to be found during the release candidate phase, it's possible that some devices may have problems. From this release on, it is intended that major changes only be merged into the kernel within two weeks after a major release. The rest of the time will be spent fixing bugs, with the goal of both increasing overall stability and decreasing the amount of time between major releases. Download the latest Linux kernel from a kernel.org mirror."
This discussion has been archived. No new comments can be posted.

2.6.13 Linux Kernel Released More

2.6.13 Linux Kernel Released

Comments Filter:

  • kernel bug fixes (Score:3, Insightful)

    by Ritz_Just_Ritz ( 883997 ) on Monday August 29, 2005 @08:47AM (#13426436)
    "From this release on, it is intended that major changes only be merged into the kernel within two weeks after a major release. The rest of the time will be spent fixing bugs, with the goal of both increasing overall stability and decreasing the amount of time between major releases."

    I wish Linus would arrive at a policy and just stick with it instead of all these gyrations of "we'll use this method from now on...no wait...we'll use this one from now on...and by the way I want everyone to switch revision control systems now...oh wait...sigh.

    • Re:kernel bug fixes (Score:3, Insightful)

      by red_dragon ( 1761 )

      I wish Linus would just stick with fixing bugs in stable releases and leave major changes to development versions, but I guess that'd take finding him a new toy to play with.

      • Developement-version = 2.6.x and 2-6.x-mmz

        Stable-version: 2.6.x.y and vendor-kernels

        Maybe things were named differently in the past. But what matters is they way they are named today.

    • Re:kernel bug fixes (Score:4, Insightful)

      by Skye16 ( 685048 ) on Monday August 29, 2005 @08:53AM (#13426473)
      As long as things aren't changing bimonthly, I don't see a horrendous problem. There's much to be said for being flexible.

      Then again, if it happens too often, more time is spent switching back and forth between the new "great" ideas than doing actual work.

    • Re:kernel bug fixes (Score:5, Insightful)

      by Knome_fan ( 898727 ) on Monday August 29, 2005 @08:54AM (#13426480)
      I can't really understand why so many people have a problem with the current policy and the policy changes.

      What exactly is wrong with refining the development process?

      • Re:kernel bug fixes (Score:3, Informative)

        by GigsVT ( 208848 )
        When I can't find a stable kernel for one of my servers, it's a serious problem.

        It's been hard to get long uptimes with 2.6... the network drivers are leaky/crash, SCSI support sucks.

        It's just not been very hot.
        • I guess you've been posting bug reports on bugzilla.kernel.org? Otherwise it's not *really* their fault that something doesn't work. Kernel developers test their code pretty well.
          • I guess you've been posting bug reports on bugzilla.kernel.org? Otherwise it's not *really* their fault that something doesn't work. Kernel developers test their code pretty well.

            Even if he has reported bugs, with the new features breaking stuff, he would probably find new bugs next release. But the fact of the matter is that 2.6 is less stable and it is the new development method that is to blame. Most people don't have time to track down bugs of this nature, especially in a bussiness environment wher

        • Re:kernel bug fixes (Score:3, Insightful)

          by sloanster ( 213766 )
          Hmm, it sounds somebody is trying to build a do-it-yourself kernel and screwing it up somehow. It sounds like somebody needs to quit trying to play kernel hacker and just use the kernel shipped by the vendor of the distro.

          We've been using SuSE Enterprise server on H/P DL hardware here and it is absolutely rock solid. We've been replacing HPUX with SuSE, and no matter how these boxes are pounded they handle the load very gracefully and without any hint of trouble. We're pleased to find that the 2.6 kernel sc
      • What exactly is wrong with refining the development process?

        Sometimes it seems like it's all refining and no development process actually happening. There are plenty of things that seem far more urgent, like releasing a kernel that's actually stable (it's at the stage that I'd go back to 2.4 if my distro didn't have so many things depending on 2.6).

    • Comment removed based on user account deletion

    • Re:kernel bug fixes (Score:5, Insightful)

      by 10Ghz ( 453478 ) on Monday August 29, 2005 @08:58AM (#13426502)
      It's not THAT bad. Revision control system has been changed twice during the lifetime of the kernel. Developement-method has been changed once, and now that method is simply being tweaked a bit. And what do you care how they develop the kernel? Are you are kernel-developer?

      Or how would you like them to do it? "We will do things this way, and by god, we will do it like this untill the end of time! Even if better ways of doing this comes along, we will not change our ways!"

      • Re:kernel bug fixes (Score:5, Interesting)

        by m50d ( 797211 ) on Monday August 29, 2005 @10:32AM (#13427222) Homepage Journal
        And what do you care how they develop the kernel?

        I care about the results, and so far the 2.6 tree has produced a grand total of one kernel that actually works for me (2.6.11). And the obvious cause, rightly or wrongly, seems to be Linus messing around with the development process.

        Or how would you like them to do it? "We will do things this way, and by god, we will do it like this untill the end of time! Even if better ways of doing this comes along, we will not change our ways!"

        How about "We will change things only when the alternative has been shown to be unambiguously better on a smaller project, and only when changing major versions". I believe in experimentation but the kernel is such an important project that a bit more conservatism is called for.

        • Re:kernel bug fixes (Score:3, Informative)

          by 10Ghz ( 453478 )

          I care about the results, and so far the 2.6 tree has produced a grand total of one kernel that actually works for me (2.6.11). And the obvious cause, rightly or wrongly, seems to be Linus messing around with the development process.

          if you have a kernel that work, why upgrade? And why use the vanilla-kernels at all? Vendor-kernels are the ones that are considered stable these days. And there IS a "stable"-branch of the kernel (the 2.6.x.y).

          believe in experimentation but the kernel is such an important proj

    • Re:kernel bug fixes (Score:2, Insightful)

      by Anonymous Coward
      Well I'm fairly sure Linus has a better handle on all the issues than you do.

      But... gee, if it bothers you that much you can point Andrew Morton to your kernel tree, or send him your patches. He does a pretty good job of ensuring things don't clash, and queues it up and merges with Linus, getting initial bug testing and review along the way.

    • I wish Linus would arrive at a policy and just stick with it instead of all these gyrations of "we'll use this method from now on...no wait...we'll use this one from now on...and by the way I want everyone to switch revision control systems now...oh wait...sigh.

      This PCI code rewrite doesn't bother me as much as some of the recent 2.6 releases including new drivers for obscure proprietary hardware.

      A large number of organizations (as well as Debian Stable and Redhat) still use 2.4. It's pretty pathetic.

      • Why would the developers care one bit about what's going into use in old ass distributions, by default?

          Debian Stable = things that have been 'thoroughly' tested for like 2 years or more. Hell, even using Debian Unstable, most of your software is still incredibly out of date.

          Red Hat isn't quite as slow. But pretty darned slow.
      • A large number of organizations (as well as Debian Stable and Redhat) still use 2.4. It's pretty pathetic. Debian provides both a 2.6 and a 2.4 kernel when you install debian stable, if you don't like it, use another distro. RHEL 3 was released quite some time ago, and the 2.4 kernel that was provided was probably heavy patched, since RedHat has quite a number of kernel hackers employed. RHEL 4 features a 2.6 kernel. If the only examples you could come up with of distros still using the 2.4 kernel, I'd s
      • Aside from security patches, any effort on 2.4 development/maintenance needs to stop. It's a brain drain


        It's a brain drain if you are in a resource limited environment. The resources working on 2.4 today would maybe not work on 2.6 if the 2.4 work was taken out from them (this is not even possible, given the open nature of the kernel).

        All my machines run on 2.6 and I have no issues with it.
      • A large number of organizations (as well as Debian Stable and Redhat) still use 2.4.

        Big companies don't like to change things. They don't want to be on the bleeding edge, due to perceived risk or some other nonsense. At my employer (a mega insurance company) there are still desktops and servers running Windows 2000, because it's too risky to upgrade. "They" are afraid something will break.

        None of our servers run the latest Solaris, AIX, DB2, WebSphere, Java VM or anything else for the same reason. No pr
      • A large number of organizations (as well as Debian Stable and Redhat) still use 2.4.

        Debian didn't care about switching to 2.6 because that would have delayed sarge even more...we all know debian. Redhat Advanced Server 4.0 uses 2.6 not 2.4 [google.com], suse's versions for servers too, so what is your point?

        As far as I know, except debian there's no major distro using 2.4 as default kernel.

        Right now 2.6 is a lame-duck kernel

        Wrong. Ubuntu, redhat, fedora, mandriva, suse, gentoo, knoopix, all of them use 2.6.
      • some of the recent 2.6 releases including new drivers for obscure proprietary hardware

        What is this nonsense ? You don't want Linux to support hardware ? Linux can not be usable by just supporting standard hardware you know ?

        A large number of organizations (as well as Debian Stable and Redhat) still use 2.4. It's pretty pathetic

        Isn't that a good thing ?!!! You sound like a troll. What is pathetic with that ?!! And FYI, RH does not use 2.4 as default anymore, and their 2.4 kernel included backports from 2.6.

      • I'm using 2.4 under Debian (Woody, or Old-Stable) for the past 2-3 years.

        It works with my hardware, and I consider it a proven kernel.

        Why should I upgrade a working kernel?

    • Re:kernel bug fixes (Score:3, Insightful)

      by bfields ( 66644 )

      I wish Linus would arrive at a policy and just stick with it instead of all these gyrations of "we'll use this method from now on...no wait...we'll use this one from now on...

      This case is typical of most such "policy changes" in that he's really just voicing something that's been a defacto policy for a while. All of 2.6 has followed the pattern that the biggest changes went in at the beginning of the -rc, with later -rc's being for stabilization, it's just that this hasn't been an explicit policy and has

  • Linux Torvalds (Score:4, Funny)

    by The New Andy ( 873493 ) on Monday August 29, 2005 @08:48AM (#13426444) Homepage Journal
    I'm sure there is a witty comment to make about the fact that the very first word in the article summary is wrong, but I can't quite fit it all together.

    I'm not really a grammar/spelling/correctness nazi either, so I can't really complain about slashdot going down hill. I just feel compelled to post.

    Uh... I wish my name was Linux?

  • Coral (Score:2, Informative)

    by Saiyine ( 689367 )

    This is a cool use for the Coral Cache, mirroring files this big: the kernel [nyud.net].


    --
    Dreamhost [dreamhost.com] superb hosting.
    Kunowalls!!! [kunowalls.host.sk] Random sexy wallpapers (NSFW!).

    • Re:Coral (Score:3, Informative)

      by croddy ( 659025 )
      dude, there's no need to stick kernel.org behind the (comparatively sluggish) coral cache.

      it's kernel.org. they mirror [kernel.org] other people's stuff.

    • Re:Coral (Score:5, Informative)

      by LnxAddct ( 679316 ) <sgk25@drexel.edu> on Monday August 29, 2005 @09:33AM (#13426717)
      You're kidding right? A kernel release like this doesn't even make kernel.org break a sweat. Read this [kerneltrap.org]. The only time they ever even start to see some strain on their bandwidth is with a new release of Fedora, because they are a mirror for it (both of their gigabit links become saturated). For kernel releases though, they say that their bandwidth stays pretty normal at around 150Mbps to 200Mbps.
      Regrds,
      Steve

  • Linus, not Linux (Score:5, Funny)

    by altanhaider ( 764914 ) <altanhaiderNO@SPAMgmail.com> on Monday August 29, 2005 @08:48AM (#13426448)
    It's LINUS Torvalds. God, I hate reading typoes!

  • New release strategy (Score:3, Interesting)

    by Sv-Manowar ( 772313 ) on Monday August 29, 2005 @08:56AM (#13426488) Homepage Journal
    The new release strategy being introduced as of this kernel, with two weeks before a feature freeze is an interesting step. The kernel development process has been changed a lot, and as much as some people may complain about these frequent changes, I believe it is in the search for a better way of working/more productivity. Surely exploring the problem for better solutions is a better way of trying to improve releases than putting up with a good-enough release method..

  • Ahem... (Score:5, Funny)

    by dwalsh ( 87765 ) on Monday August 29, 2005 @08:57AM (#13426496)
    2.6.13 Linux(TM) kernel

  • Hey! It's not Linux Torvalds... (Score:5, Funny)

    by yogix ( 865930 ) on Monday August 29, 2005 @08:59AM (#13426508)

    ... it's GNU/Linux Torvalds!

    - RMS

  • Devfs removed (Score:5, Informative)

    by Saiyine ( 689367 ) on Monday August 29, 2005 @09:05AM (#13426551) Homepage

    As they say in osnews [osnews.com], devfs [csiro.au] seems to have been removed from the kernel.

    --
    Dreamhost [dreamhost.com] superb hosting.
    Kunowalls!!! [kunowalls.host.sk] Random sexy wallpapers (NSFW!).

    • Re:Devfs removed (Score:5, Informative)

      by diegocgteleline.es ( 653730 ) on Monday August 29, 2005 @09:43AM (#13426794)
      not that many people is going to notice it - devfs wasn't really used in most of mainstream distros except 2 or 3. In some cases like Mandrake, they used it and then switched back.

      And it's not a surprise, linux's devfs implementation was broken from start, and the idea behind devfs isn't a relly good one. Fortunately, udev is much better...
    • er... ? devfs has been deprecated for several revisions now, and was hardly in use to begin with... ?

    • Re:Devfs removed (Score:3, Informative)

      by iabervon ( 1971 )
      Seems is the right word; the only thing removed at this point is the option to enable it. The idea is to get the attention of people who are still using it but haven't noticed, because things continued to work with old config files.

  • More kernel crashes as of late? (Score:5, Interesting)

    by suso ( 153703 ) * on Monday August 29, 2005 @09:10AM (#13426586) Journal
    I've been using Linux since 2.0.27. It has usually been generally quite stable for me. But recently, I've been encountering more and more kernel crashes. For trivial things to, like a kernel crash when I try to use ifconfig yesterday when setting up a machine. And random crashes on one of my servers that doesn't seem related to RAM. I know that some kernel versions have "problems", but it seems to be more than that. A recent trend of unstability. Can anyone else who has been using Linux for a significant amount of time attest to this?
    • Can't say I've noticed kernel problems of late, and I tend to use the ck branch. Been having freezes, but that was heat-related in one case, and dodgy nvidia drivers in the other.
    • I've had a few lock ups recently but I tend to blame the GLX module [happens with GL enabled XMMS plugins]. The kernel doesn't lock but XMMS basically rapes the cpu.

      As for instability I've been able to boot/run Linux on pretty much anything. Laptops are fairly bad for standards compliance and some cheaper mobos like MSI are not too friendly.

      Stick with ASUS or Gigabyte mobos, use dlink or broadcom networking, use nvidia GFX, etc... basically use HW from people who are linux friendly. :-)

      Tom
      • Right, I was also having the same problem with nvidia drivers and GL in general. But I'm talking about kernel panics, from the console (not even running X).
        • I'm running 2.6.12.5 on all my boxes [which include a Presario laptop, AMDX2 desktop, P4 Prescott desktop, P4 Smithfield desktop, P4 Northwood and a few AMD Semprons] with various configurations [both kernel and hardware].

          My only complaint with 2.6.12.x is that the timer is poorly based on TSC [hint: cpufreq changes the TSC rate!!!]. So I keep losing time. Fortunately I've mitigated this through a */10 in my crontab and I run rdate.... it's a poor fix but for now will do.

          Tom
      • ``broadcom networking, ... basically use HW from people who are linux friendly.''

        Hmm, Broadcom haven't been that Linux friendly lately with their wireless chipsets. People I know have bought Linksys gear with Broadcom chipsets, and were forced to use ndiswrapper because neither Broadcom nor Linksys will release drivers or specs.

    • Re:More kernel crashes as of late? (Score:5, Insightful)

      by Anonymous Coward on Monday August 29, 2005 @09:38AM (#13426757)
      Yes, unfortunately I have the same experience. I used to rely on the vanilla Linux kernel tree being rock solid. Now I feel I must stay many months behind in order to avoid potentially catastrophic problems. Considering the number of bug fixes, particularly w/ regard to security, that can show up in new kernel releases, it's not an ideal situation: you're damned if you do, and you're damned if you don't.

      I've recently had networking go south when packets were being written to localhost. Some adaptec scsi stuff was recently messed up, apparently now fixed in 2.6.13 - but no way I'm going to try it until it's been out for a while. I've seen problems with quotas in combination with ext3. I recently started experiencing connection tracking weirdnesses with an iptables setup I've used at home for probably a couple of years. I've seen versions where network latencies would grow ever so slowly until they reached a critical threshold that sent my server(s) spiraling into oblivion. Yes, I file bug reports. Yes, problems get fixed. But at the same time, new ones show up. Sometimes bad ones.

      I've become accustomed to rebooting Windows to fix problems, but that's exactly why I use Linux - because it was rock solid. I won't say that anymore, and it bums me out big time. I like new shiny objects too, but not at the expense of stability. Especially not on servers, which is where Linux has made the most headway.

      The problem with the current versioning system is that even if there is a bug-fix only decimal release, and even if there is only a two week window to introduce new features, the bug fixing won't get done. Why? Because new features are more fun than fixing bugs. Even if I can't submit a new feature until several months from now, that doesn't mean I won't work on it in leiu of fixing bugs.

      Linus should freeze the 2.6 kernel series against *any* new features at all, for a period of about a year. All work should be on increasing stability, ironing out bugs, improving device drivers, and other such menial housekeeping. The kernel contributers who really buck up, get to work, and help with this effort should get big karma bonuses from Linus. Those who hang back and work on their own thing should be pushed down a level in future kernel submission evaluations.

      Sorry to be so negative, but I really hope this gets better. I'm a huge fan, but I have been wasting way too much time lately dealing with problems that end up being way beyond my control. When there is a problem with my systems, I want it to be my fault, because then I can do something about it.
    • I attest that I have seen a surge of unstability on my Linux machines.
      And I can also attest that all the kernel panics or lock ups where due to hardware problems : SCSI and IDE disks crashing; IDE cdroms dieing, killing the IDE port entirely; mobo dieing.
      Actually, I think this must be due to the fact that my Linux machines run 24/24 7/7 since 2001 and that some components had never been replaced.

    • Re:More kernel crashes as of late? (Score:5, Informative)

      by hackstraw ( 262471 ) * on Monday August 29, 2005 @10:28AM (#13427178)

      Are these crashes repeatable or do they have any kind of similarity?

      I've been using Linux since 0.9x, and its been very stable for me over the years with a few exceptions that were experienced by other people as well.

      My first assumption when I have a seemingly random kernel crash with no meaningful data from the OOPs or other messages is that there is a problem with my hardware.

      For me, the Linux kernel is more robust than electrical power or hardware.

      YMMV.

    • Re:More kernel crashes as of late? (Score:5, Insightful)

      by bfields ( 66644 ) on Monday August 29, 2005 @11:41AM (#13427818) Homepage
      I've been using Linux since 2.0.27. It has usually been generally quite stable for me. But recently, I've been encountering more and more kernel crashes.... Can anyone else who has been using Linux for a significant amount of time attest to this?

      Not me.

      But it's very hard to generalize from one person's experience to any general "recent trend of unstability." Most of the bugs are in drivers, so people's experiences tend to be highly dependent on exactly which hardware they have.

      --Bruce Fields

    • Re:More kernel crashes as of late? (Score:4, Interesting)

      by iabervon ( 1971 ) on Monday August 29, 2005 @01:15PM (#13428585) Homepage Journal
      I've been using it since 1.2.13, and my experience has been the opposite: a 2.0.x had a "ping of death" bug; I skipped 2.2.x until I already needed features not available in it; 2.4.x was generally stable; early 2.6.x had a bug where it would sometimes not set up the keyboard or mouse correctly; and recent 2.6.x has had no problems at all.

      Have you tried reporting these crashes? I can't find anything about ifconfig triggering crashes. They can't test everything themselves, because they don't have every hardware configuration, so it's important for people who do to tell them when something is wrong.

  • Summary of new features (Score:5, Informative)

    by makomk ( 752139 ) on Monday August 29, 2005 @09:20AM (#13426643) Journal
    There's a good summary of the new features [lwn.net] over at LWN. Among other things, inotify has finally been merged in - about time! I wonder when Gentoo will add the new version to Portage, and if I'll dare to upgrade?
  • Download the latest Linux kernel from a kernel.org mirror.

    apt-get install kernel-image-2.6-686

    No, it won't get the latest kernel, but it will get one that has been tested a bit first.
  • I just finished configuring and compiling the kernel for my desktop last night, and now Linus decides that I'm not important to him. Why doesn't he return my calls? Doesn't he love me anymore??
  • ...When 2.6.12 came along it broke my IDE-SCSI setup (I use one quirky piece of software that REFUSES to work unless my DVD-ROM drive is accessable as a SCSI device, and there's no alternatives available for it) and I couldn't make it work again. In addition, I completely lost audio from my bttv device and couldn't restore it.

    I'm a bit hesitant to switch from 2.6.11.

  • Did ATAPI/AHCP on SATA become true on default? (Score:3, Interesting)

    by Wolfier ( 94144 ) on Monday August 29, 2005 @10:11AM (#13427007)
    I'd like to use the stock kernel as much as possible.

    As of now no SATA DVD drive works well unless you change one line and recompile the kernel.

    So many systems are now built as SATA-only (yes, the IDE ports are completely unused), stock kernels break all live-CD distributions - none of them will boot :(

  • Damnit! I just finished compiling Kernel 2.6.12-gentoo-r9 yesterday!!!! No. REALLY!
    • So:
      1. Copy your /boot/config-2.6.12-gentoo-r9 to /usr/src/linux/.config
      2. Run cd /usr/src/linux; make oldconfig and answer the questions.
      3. Spend 20 minute compiling the new kernel.

      There! You're all done for another few months, or until you feel the need to upgrade again.

  • Tannenbaum's Revenge? (Score:3, Interesting)

    by Anonymous Coward on Monday August 29, 2005 @10:53AM (#13427398)
    Okay, this is something that's been on my mind a while, so I hope it'll get some amount of attention and hopefully an interesting reply or two.

    I also hope it's not going to get modded down to the seventh level of hell, as I'm about to (gasp!) express disagreement with Linus.

    First of all, I am vaguely concerned about the Linux kernel development. It's been a long time since there's been major improvements under the hood. I've had Linux desktops freeze on me. In the past, that never happened. Ever. I don't know which kernels are trustworthy anymore. I've read something to the extent that stabilizing kernels is now considered the Linux commercial vendors' job. Excuse me, but WTF?

    In the meanwhile, while we Linux types wave our dicks around and gloat over how great we are, the guys at Redmond are happily making it possible to change video drivers in their OS on the fly, and to unload a crashed driver without taking down the system. Will it work? Probably not 100% well right away, but trust me, they WILL make it work or they'll die trying. And Windows 2000 is proof that they can certainly do things well when they put their minds to it.

    And Linux is about to become the unstable OS choice and it seriously pisses me off.

    A very long time ago, Linus Torvalds and Andrew Tanenbaum had a since famous argument about the core structure of the kernel.

    Linus's argument was, if my memory serves, that it all boils down to pushing bits around, and that you should as well push the bits in the simplest way.

    And this is where I disagree.

    Kernel development is about pushing around the bits that will push bits around. Those are the bits you want to push around in the simplest way. The goal is not simply to produce a good kernel, it's to produce a maintainable, efficiently improvable set of source that will compile into a good kernel. Otherwise, the end product you get is a good kernel for its time that will be a bitch to drag into the future.

    Perhaps the state of the Linux kernel development today is but Tanenbaum's schadenfreude.

    Assuming that kernel improvements have indeed, as is my admittedly fragmentary view, slowed down worryingly, I find myself wondering if, simply, now is when Tanenbaum should be speaking up, rather than all those years ago. The structural needs then were simple: few consumer devices, reduced architechtural diversity. Today's aren't. And there is STILL no 'just-works' way for third parties to deliver drivers to their customers. The least worse they can do is deliver sources to the kernel maintainers and hope that 1) they will be accepted, and 2) there won't be too many months between now and the moment their customer's OS uses that kernel. Or they can ship scripts that will compile glue code between their driver and the currently running kernel, and hope that the customer has a freaking compiler installed. I'm sorry, I can compile drivers and upgrade kernels manually, but neither are acceptable solutions for the mass market.

    In fact, I'll go out on a limb and predict that unless the kernel's structure and development processes are rethought to take into account the use of an OS as a three-party system -- the OS vendor, the user, and the commodity/paraphernalia providers -- Linux will never be a significant player in the desktop market.

    Thought on that? Please, please, please prove me wrong. I'm a long time Linux user, I did in my time the mandatory contributions to the kernel that allows me to speak up and bitch now, and from what I can see the future is not looking well for the Linux kernel. So please prove me wrong. Thanks.
    • I'd prove you wrong, but I stopped reading after you said that there's no major improvements "under the hood" (is there any part to the kernel that is not considered "under the hood") anymore. That claim alone shows that no matter how insightful you might otherwise be, you're completely out of touch with reality. :)

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close