Linux 2.6.27 Out

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."

Comments

Not in upcoming Debian

[gringer]

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

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

Re:Not in upcoming Debian

[Bent Mind]

To each their own. However, I always preferred having the driver just be there when I need it. I always found it annoying, under Windows, to have to hunt down drivers. Especially when you have a hundred similar devices that have the same binary driver blob (same chipset) but require a hundred different INF files because every company that assembles a board insists on having a unique driver download. Then you can throw in driver signing that makes life even more difficult.

Linux drivers are much easier to deal with.

This is a huge amount of work

[QuantumG]

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.

Re:This is a huge amount of work

[QuantumG]

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.

Re:This is a huge amount of work

[RzUpAnmsCwrds]

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.

When I was at Microsoft, that's exactly how it worked. All code had to be reviewed and approved by the feature owner and the PM. There was also a team that reviewed any changes to the common libraries, in addition to the PM.

In addition, to actually get code checked in, it had to pass FxCop (code standards verification tool), not break the build, and not break any of the build verification tests (BVTs).

Mind you, I worked in the test team. Developers have to go through all of the same steps, and then their code also gets tested by the test team.

'pure' flash devices

[Chris Pimlott]

Before you get all excited about running UBIFS on your USB drive, take note: UBI is not for consumer flash media. 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?

Embedded devices for sure

[Weaselmancer]

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*.

Re:ACPI

[Anonymous Coward]

> 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.

Re:Linux 2.6.27 Out

[frankm_slashdot]

sad part is i just pre-ordered the openbsd 4.4 cd set... hah. im not sure if i should be proud or ashamed.

then again, i sometimes think im the last of the right-os-for-the-job heretics... openbsd on my firewall. solaris (with zfs) on my fileserver... mac os x on my main desktop... (i dabble in photoshop and video.. mostly failed fark contests. ha) and windows vista on my macbook pro (along side of os x of course)... because i do a lot of autocad/solidworks stuff on the side. my webserver runs gentoo..

i guess you could call me a glutton for punishment.