Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Linux 2.6.27 Out

Posted by timothy on Thu Oct 09, 2008 10:58 PM
from the not-all-fancy-like-gnu dept.
diegocgteleline.es writes "Linux 2.6.27 has been released. It adds a new filesystem (UBIFS) for 'pure' flash-based storage, the page-cache is now lockless, much improved Direct I/O scalability and performance, delayed allocation support for ext4, multiqueue networking, data integrity support in the block layer, a function tracer, a mmio tracer, sysprof support, improved webcam support, support for the Intel wifi 5000 series and RTL8187B network cards, a new ath9k driver for the Atheros AR5008 and AR9001 chipsets, more new drivers, and many other improvements and fixes. Full list of changes can be found here."
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by grub (11606) <slashdot@grub.net> on Thursday October 09 2008, @10:59PM (#25324063) Homepage Journal

    Linux 2.6.27 is out, OpenBSD 4.4 is in!
  • by gringer (252588) on Thursday October 09 2008, @11:04PM (#25324107)

    It's a shame this won't be in the upcoming Lenny release of Debian. The in-kernel support for heaps of webcams via gspca is a very nice user-visible element of this release.

    http://release.debian.org/emails/release-update-200808 [debian.org]

    Although, I guess they made the decision for 2.6.26 before they realised that a September release would be an impossible target.

  • by QuantumG (50515) * <qg@biodome.org> on Thursday October 09 2008, @11:06PM (#25324121) Homepage Journal

    In only 3 months, all of this code has been completed and reviewed by multiple developers. This happens *every* three months. The pace at which the Linux kernel is moving and yet still maintaining quality is incredible. It is clearly the case that the Linux kernel has hit a new kind of critical mass and is now a form of software development that has never been seen before. The sheer number of people involved changes what is possible. If you suggested that every single change to the codebase be reviewed by multiple developers in a traditional proprietary software development house you would be, rightly, laughed at. There simply isn't the resources.

    • by FooAtWFU (699187) on Thursday October 09 2008, @11:29PM (#25324223) Homepage

      If you suggested that every single change to the codebase be reviewed by multiple developers in a traditional proprietary software development house you would be, rightly, laughed at. There simply isn't the resources.

      Where I work, it's called "pair programming".

      (If two programmers is enough to count as "multiple". Also, bug fixes are supposed to get an additional diff check.)

      If you do it right, you not only save time by not-writing bugs you don't have to fix later, but you can also avoid wasting all sorts of time (writing the feature wrong, going down paths that could lead to disaster, or spinning your wheels and banging your head when you can't figure out something stupid like feeding rrdtool deltas when it expects raw counters...), and you can bring new developers up to speed on a code base very very quickly.

    • by cryptoluddite (658517) on Friday October 10 2008, @12:14AM (#25324443)

      In only 3 months, all of this code has been completed and reviewed by multiple developers. This happens *every* three months. ... It is clearly the case that the Linux kernel has hit a new kind of critical mass and is now a form of software development that has never been seen before.

      Intel HDA audio still has static noise in the left channel since at least 2.6.20 kernel (probably before). This is a known problem and the solution is 'try random settings of some undocumented (outside the kernel source code) module parameters and hope it maybe works'.

      This is on Dell hardware. model=dell3stack, position_fix=1(?). This hardware works perfectly under Windows, with no tweaking whatsoever. It worked under older linux kernels, which means they probably broke something.

      The linux kernel is good, but just having a bunch of people look at the code means nothing unless they are actually finding and fixing problems people care about.

      • by QuantumG (50515) * <qg@biodome.org> on Friday October 10 2008, @12:18AM (#25324467) Homepage Journal

        Do you have this hardware? Any chance you could narrow down the versions it works on and the versions it doesn't?

        This is a general problem with kernel development.. if you don't have the hardware, it's a bitch to test. Please do contribute your findings.

        • by cryptoluddite (658517) on Friday October 10 2008, @12:40AM (#25324603)

          Do you have this hardware? Any chance you could narrow down the versions it works on and the versions it doesn't?

          Same hardware as this guy:
          https://bugs.launchpad.net/ubuntu/+source/linux/+bug/266927 [launchpad.net]

          System is at work... I would test except there are not any easy options for doing so there. Also, I realize that you can't be expected to fix hardware problems where you don't have the hardware... in fact I've personally seen code fail on one system and run perfectly on the exact same spec hardware sitting right next to it, with exactly the same software (ghosted).

          Mostly I'm just pointing out that there are longstanding problems in linux... the original fanboy post was way over the top.

      • by QuantumG (50515) * <qg@biodome.org> on Thursday October 09 2008, @11:18PM (#25324185) Homepage Journal

        Well, yes and no. The old LK dev model had unstable releases where bugs were expected. Now every release is stable, and bugs are truly anomalies.

        • by Kjella (173770) on Friday October 10 2008, @12:02AM (#25324391) Homepage

          Now every release is stable, and bugs are truly anomalies.

          Or so the theory goes. Some of the early 2.6 releases were a bit dubious and I had my doubts when they announced there'd no longer be a development kernel but it seems to have settled in nicely now, don't know if it's developers making better code before including it in the kernel, Linus being stricter, closer cooperation wtih distros or more testing feedback but all the later ones have been quite good from what I understand. At any rate, the kernel isn't the most exciting part for me as it seems to have all the parts to run a nice desktop already - it's userspace drivers, X+extensions, Compiz and Gnome/KDE that make up most of my improvement wishlist...

          • by RMingin (985478) on Friday October 10 2008, @01:53AM (#25324965) Homepage
            As far as I see, the real change is that what was the 2.4 and what was the 2.5 trees are now kept very close together. Active work (was 2.5) is done on the XX.YY.ZZ-preNUM kernels, it's all polished/troubleshot/reviewed in the XX.YY.ZZ-rcNUM kernels, and then it gets released. What was once 'stable tree' (2.4) work is now done on the XX.YY.ZZ.1 .2 .3 releases, and the developers move to XX.YY.ZZ+1-preNUM.


            It seems to work quite well, and now you no longer have to meddle with dark arts and unsupported known-broken dev kernels to get recent hardware working. Win win all around IMO.

            No more backporting/sideporting/up/down/leftporting to get current hardware code into current kernels, just all the dev community working on one codebase. Makes progress a lot more straightforward and apparently better/cleaner/less buggy.
  • AR5008 (Score:5, Interesting)

    by log0n (18224) on Thursday October 09 2008, @11:07PM (#25324123)

    Excellent! Macbook & Pro users can finally have wifi support.

      • Re:AR5008 (Score:5, Informative)

        by Ian Alexander (997430) on Friday October 10 2008, @12:32AM (#25324551)
        Some do, some don't. It depends on the revision and particular model you're using. I'm on a Santa Rosa Macbook with Broadcom, but earlier revisions used Atheros.
  • by reaktor (949798) on Thursday October 09 2008, @11:08PM (#25324129)
    W00t lots of goodies in this one. So... about time to change from the 2.6.infinity_and_beyond scheme to something else. What say you? I think the 2.6.x should have been left behind when the scheduler changed.
    • by jd (1658) <imipak@@@yahoo...com> on Friday October 10 2008, @12:13AM (#25324439) Homepage Journal
      Well, they can't release a 2.7, as SCO has already declared that that's the kernel that has the proprietary code in it. (Y'see, the Master, who cunningly disguised his alien identity by calling himself Darl, made an error in the time calculations and ended up traveling back in time too many years. Now's our chance to really screw up the space/time continuum.)
  • 'pure' flash devices (Score:5, Interesting)

    by Chris Pimlott (16212) on Thursday October 09 2008, @11:17PM (#25324177)

    Before you get all excited about running UBIFS on your USB drive, take note: UBI is not for consumer flash media [infradead.org]. These devices already incorporate hardware to hide their flash nature so they look like a plain old block device to your OS. UBI is for pure flash devices that directly expose the quirks and distinct characteristics of the underlying media.

    So what kind of flash hardware is this for? Embedded devices, apparently. But maybe as flash storage becomes more common, more devices will support raw access?

    • by moosesocks (264553) on Thursday October 09 2008, @11:33PM (#25324247) Homepage

      So what kind of flash hardware is this for? Embedded devices, apparently. But maybe as flash storage becomes more common, more devices will support raw access?

      Olympus' xD card format essentially specifies a direct connection between the NAND flash chips and its external interface.

      It's weird and proprietary, yes. However, it's already being done, and there are arguments to be had for minimizing the amount of circuitry on the memory card itself. Interacting directly with Flash isn't as uncommon as you might think it, and can be of huge benefits for portable/embedded devices that require low power consumption.

    • by schwaang (667808) on Friday October 10 2008, @12:01AM (#25324385)

      It seems quite likely that OLPC will largely replace jffs2 with UBI [gmane.org] for the internal nand on the XO. Good news. Maybe this will apply to the Asus eee as and other solid-state drives as well.

    • by Weaselmancer (533834) on Friday October 10 2008, @12:03AM (#25324397)

      Yeah, embedded devices definitely. It'll be awfully nice to see simple flash chips soldered onto a board rather than someone bolting an SD or compact flash socket onto them just so you can have a boot device.

      Fragile, more expensive, and adds another physical item that can break. And not only that, but you can drop about 20-30 dollars worth of non-essential hardware from your design and still be on target. If you do any embedded work you know how big 20 dollars worth of hardware savings is. This new driver is *huge*.

  • ACPI (Score:5, Insightful)

    by Detritus (11846) on Friday October 10 2008, @12:04AM (#25324401) Homepage
    Any chance that this will fix some of the ACPI problems with Linux? I recently had a terrible time trying to install Linux on a new Intel motherboard, mostly related to ACPI problems. I'm not blaming any of the Linux developers for this mess. I get the impression that ACPI is a disaster area and even Intel is unable to get it right on their own boards.
    • Re:ACPI (Score:5, Interesting)

      by Anonymous Coward on Friday October 10 2008, @12:30AM (#25324539)

      > Any chance that this will fix some of the ACPI problems with Linux?

      Just to be clear, ACPI problems are motherboard problems, not Linux problems.

      If the ACPI function of your motherboard is correct and compliant with the ACPI specification, Linux will work just fine.

      Part of the motherboard ACPI problem is that Windows expects, and uses, some functions within ACPI that are not compliant with the ACPI specification ... you know the drill: embrace, extend, obscure, try to screw the opposition ...

      Fortunately with ACPI we have not quite yet got to the "extinguish" phase.

        • by oatworm (969674) on Friday October 10 2008, @12:15AM (#25324453) Homepage
          If viruses were unique to Windows, we wouldn't have "root"kits. Instead, they'd be "Administrator"kits or perhaps "SYSTEM"kits.
            • by oatworm (969674) on Friday October 10 2008, @12:37AM (#25324581) Homepage
              I know this is going to get modded as "off topic", but let's cover this...

              SYSTEM and Local System are basically one and the same, and are almost perfectly synonymous with root. Network Service would be the equivalent of the "nobody" user - i.e. an account that you can use to run low-privilege services. Administrator would be the same as a user with administrative privileges in Linux (perhaps someone in the sudoers list). The trouble, of course, was that, until Vista/2008 came along, it was trivially easy for an Administrator to escalate to SYSTEM - you just had to run a scheduled job in interactive mode (think of a cron job with no password required) and you'd not only have root access, you'd also have access to the current user's console. For an administrator, this came in handy - of course, what was handy and convenient for an administrator was just as handy and convenient for someone else.
        • You are clearly one of those arrogant assholes since you think there is such a thing as a pecking order in cyberspace.

          As an arrogant asshole, you need to know you are one of the core reasons why Linux is only slowly gaining acceptance by the masses because you're too good to stoop to a "newbie's" level.

          That being said...nah, you're still an arrogant asshole.