Linux Kernel 2.6.14 Released

digitalderbs writes "Linux kernel 2.6.14 was released on 10-28. OSnews reports on new features like 'HostAP, FUSE, the linux port of the plan9's 9P protocol, netlink connector, relayfs, securityfs, centrino's wireless drivers, support for DCCP (currently a RFC draft, PPTP, full 4 page-table support for ppc64, numa-aware slab allocator, lock-free descriptor lookup' and many other things. The changelog is also available."

Comments

First post

[Anonymous Coward]

word to GNAA

Oh Noes

[Legendof_Pedro]

And suddenly the entire internet collapses as the world's supply of geeks begin their downloads.


Also, you were eaten by a grue.
Oh Noes!

wow

[msh104]

that's quite a lot of features for a sub release. I especially like the centrino drivers, I guess I'll give it a try. :)

Re:wow

[lostlogic]

Keep in mind the new kernel development model, where anything outside of major architectural changes is permissable in the Y of W.X.Y releases, and there is now the stable W.X.Y.Z releases to provide stabilized security patched kernels for those who want a slower moving target.

Re:wow

[mp3phish]

Maybe with those centrino drivers we can get this thing running wireless in linux:
Centrino pumpkin pc

Re:wow

[Maavin]

they are working.... :)

Re:wow

[cloudmaster]

I think they mistyped the version in the article. The 2.6 series is considered stable, and doesn't get a bunch of new features added liek this without several months of testing. New features of this magnitude would be in 2.7, or maybe 2.6.x-ac. For years, even minor numbers have meant stable and odd unstable. Geez, get with the program guys. :)

Even Debian has it ready!

[jZnat]

Even Debian had this ready before the article! Word on the mailing lists it that they also hope to be able to release GNOME 2.14 (or was it 2.16?) in parallel with GNOME later on. Now wouldn't that be cool?

Re:Even Debian has it ready!

[The Lerneaen Hydra]

Well I for one welcome our new Linux overlords.

Re:Even Debian has it ready!

[aichpvee]

Word on the mailing lists it that they also hope to be able to release GNOME 2.14 (or was it 2.16?) in parallel with GNOME later on. Now wouldn't that be cool?

No.

Re:Obligatory...

[jZnat]

Obligatory "you must be a Gentoo user" response.

Notable Release

[Doc Ruby]

The "comprehensible changelog" is slashdotted. Why is the high-level feature list of the release such a low priority, though so demanded? I know programmers prefer writing C to writing English (or Finnish, or Hindi, or German). But what good is code people don't install because they don't know what it does for us? There are so many people hanging around OSS projects who can't or don't contribute to the code. Surely some of those people can help by at least distilling the changes into a brief description. Release notes might not be the most important product of a release cycle, but they often control everything that product consumers do after the release is published.

Re:Notable Release

[MoogMan]

Kernels are not intended for the consumer. It is assumed that you have a certain level of understanding to install and configure the Linux Kernel.

Re:Notable Release

[Doc Ruby]

You're using the wrong definition of "consumer" - too narrow. People consume kernels whenever we install them, even when we're developers, or even kernel committers. And kernel consumers don't even necessarily configure or build them - "apt-get install kernel-image" is the act of a kernel consumer. When that consumer knows the upgrade is worth consuming. The minimum amount of understanding should be necessary for people to upgrade: the understanding that they want to upgrade.

Re:Notable Release

[Billly Gates]

Try reading the netbsd changes log to figure out what NetBSD 3.0 will include. Only bob_smiley wrote driver for the hijinker api.

still have no clue what NetBSD 3.0 will come and I am supposed to figure it out on my own.

Re:Notable Release

[Anonymous Coward]

Carefully concealed on the NetBSD site: Significant changes from NetBSD 2.0 to 3.0

Re:Notable Release

[The_Dougster]

Kernels are not intended for the consumer. It is assumed that you have a certain level of understanding to install and configure the Linux Kernel.

True, but building your own kernel isn't particularly challenging either. Basically if you have installed your GCC compiler and a couple of extra packages then as long as you can follow a recipe you can probably build a reasonably good kernel tailored for your system.

Running LILO is probably the most dangerous part, because if your config file isn't right you can leave your system unbootable. A much better option is taking the time to learn GRUB and get it installed because once it is installed all you have to do is add a couple lines to a text file to add another kernel to the list. That way you just leave your existing kernel hanging around until you get your home-made one perfected. It usually takes me a couple of attempts to get a new kernel compiled to my satisfaction.

I don't upgrade my kernel very often either. Once I get a stable system that runs well and has all my drivers supported I usually keep that kernel for a year or so, unless I'm feeling bored and just want to play around with the latest and greatest for fun.

Re:Notable Release

[nihilogos]

Kernels are not intended for the consumer

Everyone should try compiling their own kernel at least once. It's not hard, and is a great learning experience. And there is something satisfying about knowing that the kernel you're running was compiled specifically for your machine, with no extraneous fluff like "Ham Radio Support".

Just make sure you keep the old one safe.

Re:Notable Release

[petermgreen]

can grub do a boot configuration once like lilo can.

boot configuration once is a very handy feature if you have a remote powerswitch but no other way of getting at the machine until/unless networking comes up.

Re:Notable Release

[Bitmanhome]

add a couple lines to a text file to add another kernel to the list. That way you just leave your existing kernel hanging around until you get your home-made one perfected.

LILO's the same way, dude, no difference. In fact, I do that with Debian-installed kernels so I can be sure they're clean. I even have Memtest86+ in the list too.

Re:Notable Release

[Wizarth]

Excuse me, but LILO allows the same thing. I think I currently have 4 kernels (plus WinXP) in my LILO config because I never get around to taking the old ones out of the list.

Re:Notable Release

[Anonymous Coward]

> Kernels are not intended for the consumer.

Quite so. Consumers can do all those things like I/O and memory management manually...

> It is assumed that you have a certain level of understanding to install and configure the Linux Kernel.

Which makes it not less convenient to be able to read a summary of highlights rather than having to dig through a long list of commits. Especially if you compile your own kernels.

Re:Notable Release

[Anonymous Coward]

What are the consumers supposed to run underneath all those pretty bells and whistles that adorn their favorite apps?? :)

Re:Notable Release

[marcosdumay]

"True, but building your own kernel isn't particularly challenging either. Basically if you have installed your GCC compiler and a couple of extra packages then as long as you can follow a recipe..."
...and know what every option means, and every device you have...
"...you can probably build a reasonably good kernel tailored for your system."

Compiling a kernel is for experienced users, it can only be this way.

Re:Notable Release

[Mr. Underbridge]

Running LILO is probably the most dangerous part, because if your config file isn't right you can leave your system unbootable.

Others have debunked most of your post, but I'll go for some more - you won't leave your system unbootable if you have a boot CD handy. Even to go back to Windows, you boot from the CD and do a format /MBR, and boot like normal. With linux, boot from CD, un-trash your lilo, and away you go.

There are advantages of Grub vs. LILO, but the ones you mentioned ain't it.

Re:Notable Release

[arose]

And it keeps you warm in the winter!

Re:Notable Release

[Malor]

Probably the single best resource on the Net for kernel discussion is Linux Weekly News, www.lwn.net. The main editor, Jon Corbet, is a very rare breed, a lucid writer who more or less understands the internals of the Linux kernel. As far as I can tell, in the entire Linux universe, this consists of a population of exactly one.

LWN has been around a long, long time, and it's one of the best Linux sites on the Net. Don't be put off by the relatively simple site design. The content is second to none.

Most of the really good stuff is on a time delay. If you subscribe, you get access immediately. Otherwise, you have to wait a week or two. Please do subscribe if you like it. It's not very expensive, and it's important to support the really good resources. Linux Weekly News is one of them.

(I'm not affiliated with them, except that I send in money every month.)

Re:Notable Release

[The_Dougster]

Well, unless it has recently been changed, with LILO, you have to run the program to install a new boot block after you toy around with the config file. If LILO encounters an error or something it usually installs a corrupt boot sector and you need a boot disk to get back in. I've been stung by this a couple times when I didn't realize that when LILO gave an error message that the system was at that point unbootable.

With GRUB it just boots up, reads the file from the drive, and then gives you a list of options depending on what was in the file. Also you can open the GRUB shell and edit the boot command lines in case they aren't exactly right. Once its boot sector is installed, all you have to do is modify the text file and thats it.

Re:Notable Release

[Malor]

There are two main reasons to run GRUB. The first is because you can build new kernel start lines on the fly. LILO has to be hardcoded with kernel locations on disk. You can change the boot parameters, but you can't start random kernels. GRUB, on the other hand, understands enough of the filesystems on which it lives to allow you to boot arbitrary kernels on the fly.

The second reason (closely related) is that if, for some reason, the kernel files move around on disk (did you just restore from backup?), LILO blows up, and GRUB just works.

Either bootloader can be used safely to remember multiple different kernels for routine experimentation.

Re:Notable Release

[pantherace]

No, it is an advantage.

Grub does not overwrite sector 0, EVERY TIME ONE CHANGES THE CONFIG. An operation which can fail for a number of reasons. (In other words, everytime lilo is run.) Grub instead writes the sector once, then relies on a text (and other files) which live in another sector. Even if grub's configuration file is messed up, grub will still come up, and likely be able to boot your old/new kernel. (There are ways of screwing this up, but all but one I can think of would result in lilo also failing, without even coming up.)

There are a lot of other advantages, but they weren't the one the GP was referring to. Rewriting Sector 0 like lilo does is like playing Russian Roulette with a hundred (or more) chamber pistol with one bullet.

Re:Notable Release

[The_Dougster]

Others have debunked most of your post, but I'll go for some more

Dude, I'm not pulling this stuff out of my butt. GRUB takes some time and effort to get it installed and then figure out how it works, but its really sweet when it all comes together. GRUB can even have a nice graphics boot screen with a arrow key menu boot screen. Its essentially the ultimate bootloader, and it can save you a lot of potential problems once you install it and learn how it works.

And I still contend that an average Linux guy can, with some trial and error, produce their own kernel by compiling it from source. While Debian, for instance, does provide some pretty good performing kernels which have basically every option compiled in and available as a module, you can also roll your own and cut out a lot of the fluff if you know what is inside your computer.

Linux is a monolithic kernel with modular support, but adding the capability to say install a SCSI module will make your kernel substantially larger. Since the kernel remains resident in memory at all times, the size of the kernel is a very important factor to achieving increased performance.

Ideally, you should make your monolithic kernel with all necessary features compiled directly into the kernel, and then build only those modules which you might possibly want to use but aren't really critical, or stuff like ALSA sound which doesn't work right unless its made in a modular fashion.

By doing this you get a nice small fast kernel which supports your hardware and not much else. Granted, its usually not really necessary in most cases, but it is interesting to do this, and you will possibly get a small performance increase if you do it correctly. Its worthwhile just to learn how to do it so in case you buy some new gadget that requires a very recent kernel for driver support then you are not intimidated by the process.

It really isn't all that difficult to make a kernel, and its kind of fun to do it. Expect to have to recompile a couple times and look at your bootup messages and use the dmesg command to check for bootup device driver errors. If you get errors go back into the kernel config menus and fix it and try again.

Finally, most of the kernel config options have a help option which explains what it does and something like "if unsure, say Y", only the really new options lack this, and if there is no help, and you don't know what it is, then just don't check it unless you get a boot error message of some kind which will probably lead you back to that option.

Making your own kernel is something that is kind of unique to Linux and I personally think that everybody should try it when they feel ready if for no other reason than "because you can."

Re:Notable Release

[richlv]

"Well, unless it has recently been changed, with LILO, you have to run the program to install a new boot block after you toy around with the config file. If LILO encounters an error or something it usually installs a corrupt boot sector and you need a boot disk to get back in."

i'm not sure wether current versions of lilo reset state if an error is encountered, but hey - if bootloader installations gives you errors you _should_ check your configuration and do it again until there are no errors, right ? if you reboot after seeing errors... that's not the best way to have a running system anyway :)

Re:Notable Release

[Anonymous Coward]

LILO can make the system unbootable without giving an error - actually, I'm surprised it would write the unbootable boot block when it did notice the error.

The advantage of Grub is that you don't write a new boot block at all. When the old one (from when you installed) works, it's going to keep working after you upgrade the kernel.

Re:Notable Release

[kermitthefrog917]

I like the "make install" kernel command. It creates two files vmlinuz and vmlinuz-2.6.13-gentoo-r3 (or whatever patchset you use). it renames the previous vmlinuz to vmlinuz.old and any previous vmlinuz-2.6.13-gentoo-r3 to vmlinuz-2.6.13-gentoo-r3.old.

It makes a grub config really simple. You set one command to vmlinuz and another to vmlinuz.old so you always have your previous kernel in case the new one locks up.

Re:Notable Release

[richlv]

"LILO can make the system unbootable without giving an error" - i'm pretty sure that is a bug. i have never experienced something like that.

both of these approaches have good and bad things (for example, grub has to know underlying filesystem), also a big factor is knwoledge with particular loader.

slackware still comes with lilo and i am thankful about that ;)
i'm used to it, it works for me, so i keep using it everywhere.
on servers you don't replace kernel that often, on experimental workstation i only a couple of times durign several years have forgotten to run lilo after kernel upgrade, no other problems experienced. also, because it is an experimental one, i always have handy some slackware or knoppix bootdisk - you just never know what might happen.

i don't think there is point arguing which one is "better", because they have different approaches. one might decide that one is better than the other in a particular case, but even then similarity with the one that is used is the biggest factor.

Re:Notable Release

[Scaba]

And they redeveloped the site a few years back with Quixote, a very cool, no-nonsense Python-based web framework.

Re:Notable Release

[Mr. Underbridge]

There are a lot of other advantages, but they weren't the one the GP was referring to. Rewriting Sector 0 like lilo does is like playing Russian Roulette with a hundred (or more) chamber pistol with one bullet.

With a popgun, since quick use of a bootdisk gets you out of trouble. I have YET to see a way to permanantly screw a system with LILO.

No, it is an advantage.

Grub does not overwrite sector 0, EVERY TIME ONE CHANGES THE CONFIG. An operation which can fail for a number of reasons. (In other words, everytime lilo is run.) Grub instead writes the sector once, then relies on a text (and other files) which live in another sector. Even if grub's configuration file is messed up, grub will still come up, and likely be able to boot your old/new kernel. (There are ways of screwing this up, but all but one I can think of would result in lilo also failing, without even coming up.)

That is a DISADVANTAGE, as if the HD that Grub is on goes down, you can't boot anything (as I recall) without reinstalling Grub on another partition, or a different boot loader. This happened to me.

Re:Notable Release

[Anonymous Coward]

...and then you just use your grub boot disk. Really, if your HD is down, your grub boot disk will handle things without trouble and boot your system just fine.

Reiser4?

[Anonymous Cumshot]

Does anyone know if/when reiser4 will be included into the mainline kernel? I recall reading a kerneltrap interview a while back with Andrew Morton, in which he basically said "sure, why not?" to including it into the next release..

Re:Reiser4?

[msh104]

I have a bad feeling that it is quicker for them to rewrite it using fuse that to get it into the mainstream kernel. that said, I think it will end up in the main stream kernel "someday". but I don't think we will see it until the next major kernel release.

Re:Reiser4?

[DJCF]

I believe there was some large disagreement on weather to include it into the kernel. If memory serves, Linus didn't want it but Hans did. So I don't think it will be included unless there is some change which makes Linux consider his stance on filesystems.

Do a search on slashdot for Hans' posts, they are quite insightful.

Re:Reiser4?

[bersl2]

There is much miscommunication happening w.r.t. Reiser4 on LKML and elsewhere. Until that is cleared up, don't expect Reiser4 in the mainline anytime soon without some kind of fallout.

Re:Reiser4?

[Jay Maynard]

Is reiser4 ready for prime time yet? The last I heard (admittedly, a year ago), it was nowhere that stable.

Re:Reiser4?

[m50d]

It's being kept out for insane political reasons. There are too big egos here, probably hans as well as the kernel developers, but they're the noticeable ones. I'm starting to think the kernel devs don't care about the users.

Re:Reiser4?

[Anonymous Coward]

It's stable, it's been stable by Hans standards(i.e. officially released) for the last year. The filesystem is pretty darn fast, stable, very secure, and quite advance. The issue isn't about the stability, it's about the code. One of the major things is it doesn't conform to Kernel Code guidelines, so Linus is arguing that it is going to make it harder to maintain and manage by other developers. Another issue is Reiser4's plugin system, which in Han's vision becomes the base of all filseystems and changes are brought in through plugins, and the issue is that the plugins system breaks the design of how the kernel deals with filesystems, it basically repeats functionality that could be replicated in other ways.

Re:Reiser4?

[Al Dimond]

Correct me if I don't know what I'm talking about (I'm sure I don't), but if one of the features (FUSE) allows filesystem userspace file system drivers, wouldn't that bypass the whole issue? Reiser can use different style than the kernel guidelines and use whatever kind of plugin system he likes, and the kernel folks won't have to worry about it?

Re:Reiser4?

[eclectro]

I don't know. I was reading a distros mailing list concerning this and there were mentions that Reiser4 has corrupted user's data. Maybe it needs to be more stable as other posters have pointed out, and it really isn't about politics.

Re:Reiser4?

[Jay Maynard]

it's been stable by Hans standards(i.e. officially released) for the last year
Hans's standards must be pretty low, then; when it was first released, it was known to be very fragile and lose data easily. Has it improved since then? We're talking about code that *must* be utterly reliable, and Hans's record in that regard is pretty lousy.

Re:Reiser4?

[Anonymous Coward]

They do keep including it, then resiserfs crashes and they lose all the changes! HA!

Re:Reiser4?

[msh104]

well, let me ask you a question in return.

how will you boot from a filesystem that can only be accessed using a driver/module/fuse thingy that is located on that same filesystem?

I admit you can do tricks with boot images or a small "startup" partition but that surely isn't much fun.

Re:Reiser4?

[The_Dougster]

I've actually been using IBM's JFS file system on my box, and I'm pretty happy with it. It seems to be extremely stable for one thing.

JFS wasn't the fastest in I/O throughput, but it wasn't all that much slower either. However, it had the lowest CPU utilization during I/O which to me seems to make my system run very smoothly. Even if the disk is thrashing like crazy while cron is doing daily maintenance, the overall responsiveness seems largely unaffected.

I played with Reiser3 for a while, and while it was fast, I ran into some problems when a crash and hard reboot corrupted my root partition. I'd like to give Reiser4 a shot sometime, but I'm not disappointed with JFS either.

Re:Reiser4?

[mechsoph]

an initrd. It shouldn't be any harder than booting off of raid or lvm.

Re:Reiser4?

[Al Dimond]

If your partitions are split up like many people's, that's exactly the effect. /boot is a small ext2 partition (or whatever your bootloader recognizes), / is a fairly small partition, usually ext2 or ext3 (or whatever your kernel will recognize w/o modules). Then /var and /usr are whatever you like, and usually /usr takes most of the drive (if /home isn't a link to /usr/home then you'd probably want a /home as well). Personally I don't have seperate /usr or /var partitions right now but that's just because my hard drive has a large Windows partition from when I used Windows that I just haven't felt like backing up and reclaiming for the last 2 years, so I have limited space for my GNU/Linux system and can't justify "wasting" potential storage space on empty space in / or /var. But the multiple partitions usually make recovery from certain types of HD failure easier, so when I do get around to doing that I'll probably make most of that space /usr and a decent chunk for /home.

Re:Reiser4?

[petermgreen]

from what i've heared things like LUFS and FUSE suck performance wise compared to real drivers in the kernel. This is not so imporant for a special purpose FS or a network mapper but you don't particularlly wan't your main partitions on them.

Re:Reiser4?

[slavemowgli]

Wow. That's the most diplomatic summary of the Reiser4 discussions I've ever seen, by far. :)

Re:Reiser4?

[The_Dougster]

... I'll probably make most of that space /usr and a decent chunk for /home.

Thats how I have my system set up. Something like 20G for / and around 35 for /usr/local where most of my games live. I also have a small 350M partition for FreeDOS mounted on /freedos and thats where GRUB lives in C:\boot\grub. That way if I hose my root partition for some reason I can still boot up GRUB and attempt a recovery.

I need to repartition sometime. I'd like to fool around with the new Minix3 or one of the BSD's but I'm all out of primary partitons at the moment. Probably I should just slap an old 10G drive in the next time I crack open my case to blow out the dust bunnies.

Re:Reiser4?

[m50d]

Of course it will have bugs, it's new. That's why it needs widespread use, yes marked as experimental or similar, to get them. Linux 2.6.0 was a lot less stable than reiser4 is now.

huh?

[bcrowell]

Wow, there's not a single thing on that list of features that I understand. Either these are names for things I wanted but didn't know the names for, or these are all things I don't need.

Hasn't the kernel pretty much reached the point where, for the average user, the only problems are those that just can't be fixed -- in other words, drivers for proprietary devices that haven't had their specs released by the manufacturers?

Re:huh?

[llamaguy]

If there's one thing you can never have too much of, it's features*.

*Not true: creature feep is an evil, evil disease. Take note, kiddies!

Re:huh?

[kneeless]

Just because you don't understand the features, doesn't mean their not useful to someone.

Re:huh?

[Kjella]

Wow, there's not a single thing on that list of features that I understand. Either these are names for things I wanted but didn't know the names for, or these are all things I don't need.

If you told me the changes in Ford's latest car engine, I probably wouldn't understand them either, certainly not if I need them or not. Normal people aren't supposed to understand a kernel change log. Device drivers are the odd exception, not the rule (and more often than not have little to do with the kernel, the kernel provides an interface and someone writes a driver to that interface).

Re:huh?

[radarsat1]

Hasn't the kernel pretty much reached the point where, for the average user, the only problems are those that just can't be fixed

A lot of things that the "average user" takes for granted are supported by features in the kernel that they didn't know even existed.
A lot of things that Linux *applications* need to do require kernel features that need to be implemented.
Take all the new search utilities (Beagle et al.) for example, they are depending on kernel features like "Inotify". If you read about Inotify you probably wouldn't give a damn, but you read about Beagle and then understand the point.
Same goes for other types of features, like more secure/reliable filesystems. Sure the average user "doesn't care", but he sure cares when that feature wasn't implemented and he ended up losing half his work to a crash.

Besides, one of the biggest complaints about Linux is that when a brand-new application comes along that requires a user to "patch and recompile the kernel", it's *too hard* for the average user. So be happy when these features become included by default.

Re:huh?

[kebes]

the only problems are those that just can't be fixed -- in other words, drivers for proprietary devices

(note: I'm no expert on the linux kernel) Yes and no. Much of what is left to be done in linux kernel has to do with proprietary devices. However, these things are not in the category "cannot be fixed." In fact, OSS developers constantly reverse-engineer new devices and standards, and get them working properly. It is hard, but can be done. For instance, this release includes enhanced support for Centrino, which is a standard for wireless connectivity (in laptops, etc.). Just because companies do not release specs does not mean that the linux kernel cannot include support for them. It is very very hard, but somehow they manage to do it!

And in a broader sense, the kernel is never "done" because computer hardware and software is constantly evolving, and thus the kernel must constantly evolve to meet modern demands. Yes, a 10-year old kernel will probably run your web server just fine, but the newer kernel versions integrate much better with newer hardware technology.

Re:huh?

[Hosiah]

creature feep is an evil, evil disease.

Yeah, and they didst bow their heads and think of KDE, and were enlightened...

*grinning, ducking, and running while MOONING at the same time...*

Re:huh?

[bcrowell]

Take all the new search utilities (Beagle et al.) for example, they are depending on kernel features like "Inotify". If you read about Inotify you probably wouldn't give a damn, but you read about Beagle and then understand the point.
Interesting example. I googled and read about Beagle and inotify. Well, actually, AFAICT the things Beagle is meant to do are things I'm already accomplishing just fine by using locate (and by keeping my directory structure logical). OK, it sounds like Beagle will also index the contents of files and not just their names, but actually locate+grep does that for me. Actually this kind of file indexing was one of the things on MacOS X that I considered a real nuisance -- I liked MacOS X better before they added it.

Same goes for other types of features, like more secure/reliable filesystems.
Sure, that's a good example, but didn't ext3 basically take care of file system corruption when you didn't power down correctly? And in any case, there's no substitute for backups.

In general, developers tend to value new, shiny features way more than their end users value them. As a user, I typically just want bugs to be squashed as early and often as possible.

Re:huh?

[l3v1]

there's not a single thing on that list of features that I understand

Just because you lack the level of knowledge enough to understand what the list consists of, doesn't mean those loads of fixes and features are all useless. In fact I'm really happy new features are not only shopwindow-additions like some big companies do: list for hours what they "added" so 6packs feel they really gave out their money for something.

Re:huh?

[Tom]

In fact, OSS developers constantly reverse-engineer new devices and standards, and get them working properly. It is hard, but can be done. For instance, this release includes enhanced support for Centrino, which is a standard for wireless connectivity (in laptops, etc.).

Bad example, these drivers are officially supported by Intel. See, e.g. the project page.

Re:huh?

[golgotha007]

Interesting example. I googled and read about an automobile called a Ferrari. Well, actually, AFAICT the things a Ferrari is meant to do are things I'm already accomplishing just fine with a horse (and not using any petrol.). OK, it sounds like a Farrari will also take me great distances, but actually a horse does that for me (it sometimes even takes days!), and you can pet and feed it, too! Actually driving a Ferrari is what I consider to be a real nuisance -- I liked the wild west days much better before they made it.

Just a heads up, are you sure you understand all of Beagle's capabilities? It sounds like you got about 2% correct.

Re:huh?

[MikeBabcock]

The grandparent poster was probably actually thinking of the nVidia ethernet drivers that were reverse engineered a little while back as part of the nForce chipsets.

Re:huh?

[einhverfr]

Wow, there's not a single thing on that list of features that I understand. Either these are names for things I wanted but didn't know the names for, or these are all things I don't need.

I was going to say:
Parse Error:
Perhaps you are missing an ) after "currently an RFC draft"

Most of the rest of it is quite interesting. I wonder how often PPTP will actually be used now that we have really mature IPSec implimentations in place....

Re:huh?

[photon317]

There's still a lot of fundamental work outside of proprietary drivers and keeping up with the latest specs and all that. The NUMA slab allocator in this release, for example, qualifies as that type of thing. So does the spinlock consolidation and the lockless file descriptor thing from the Changelog. The Linux kernel is a huge, huge project. We could freeze all hardware and standards in the world so that there was nothing left to do but refine the kernel we have today, and it would still take another 5+ years before the changes settled down to "oh well, that's as good as we can get it".

Re:huh?

[jrockway]

#CONFIG_NEW_FEATURE=n

There, no feature creep.

Re:huh?

[richlv]

well, there is on very important change, at least for me. fuse. it basically allows you to mount anything that has a required driver - the coolest one being sshfs, also ftpfs is nice. maybe you are interested in cvsfs.
see this : http://fuse.sourceforge.net/wiki/index.php/FileSys tems

then, this one is nice : "Suspend support for CIFS filesystem"
basically, if you had an smb share mounted & suspended, after resuming it was not accessible. supposedly this works now :)

"Driver for the IBM Hard Drive Active Protection System (HDAPS)" could be cool, unfortunately i don't have a thinkpad.

9p support seems OMG !#&#, but i probably will have no practiacal use of it for a long time (see papers on plan9, they are thoughts provoking).

well, there are other things (wireless drivers, PPTP conntrack) that will be useful to some people but not for me.

so this is a pretty feature stuffed release and some of them are rrrrrrrreally nice. though i still wish for a 2.7 fork...

Re:huh?

[radarsat1]

Actually this kind of file indexing was one of the things on MacOS X that I considered a real nuisance -- I liked MacOS X better before they added it.

Which is why it's nice to have to option of not compiling it into the kernel if you don't want it. Yay!

Sure, that's a good example, but didn't ext3 basically take care of file system corruption when you didn't power down correctly? And in any case, there's no substitute for backups.

And ext3 is??????? That's right, a kernel feature! Anyways, this is totally off the topic of my statement..

In general, developers tend to value new, shiny features way more than their end users value them. As a user, I typically just want bugs to be squashed as early and often as possible.

Ah, but you are not the only kind of user. Personally I don't mind new features at all. :) I really enjoy using and working with Linux, and I like to be able to be proud that it is "up to scratch" among its competitors. (For the most part anyway..)

Also, believe me that corporate servers depend on many features that you may not care about. The same I'm sure goes for embedded systems. There is a lot more to Linux than the desktop.

Anyways, I do understand what you're saying. But that's why these things are all optional. People who want them implemented will do so. Those who are more interested in bug fixes will do their part. It all works out nicely... and what we end up with is a damn nice operating system. I would agree with you but I think I realize that there's no lack of interest in fixing bugs. The article was about the new features, but I'm sure the new release contains plenty of bug fixes.

Ah the kernel recompile

[Anonymous Coward]

But it's not the same as service packing windows. Honest!

This is funny

[cuerty]

Because of this troll.
lol.

Re:This is funny

[CyricZ]

How is it a "troll"? It's obviously pointing out a very real flaw with regards the Slashdot news reporting.

Kids these days throw around the word "troll" like politicians throw around the words "terrorist" and "communist". It is often used out of context and at the wrong times, and thus has no true meaning any longer.

Re:This is funny

[Homology]

Kids these days throw around the word "troll" like politicians throw around the words "terrorist" and "communist". It is often used out of context and at the wrong times, and thus has no true meaning any longer.

I just meta-moderated a troll as unfair, which I usually do, by the way. Just because a moderator disagrees with a post does not make the author of the post a troll.

Re:This is funny

[The Lerneaen Hydra]

I for one find it very ironic that CynicZ's post got modded to troll.

Re:This is funny

[Anonymous Coward]

One of the problems is that there isn't a mod for "wrong". So if you encounter a post which is just obviously incorrect, how do you mod it? Overrated, troll, or flamebait are your only options..

Re:This is funny

[CyricZ]

I think it's a good thing that happened. It just proves I'm correct.

Centrino wireless drivers

[lord_rob the only on]

How does that differ from ipw2200 drivers ?

BTW, here's a coral link for the kernel changelog.

Re:Centrino wireless drivers

[BenV666]

That's where they come from. However, the version included in this kernel is a bit lower than the latest release on sourceforge. (1.0 vs 1.0.8 if I'm correct)

Look out Linux gimps, here comes the troll song!

[Anonymous Coward]

"The problem's all inside your head", she said to me
The crap filter is annoying, I agree
You can defeat it if you do it logically
There must be fifty ways to troll on Slashdot

She said it's not really my habit to intrude
The sensationalist titles are often misconstrued
The editors' spelling may be somewhat crude
There must be fifty ways to troll on Slashdot
Fifty ways to troll on Slashdot

Mods are on crack, Jack
Repost spam, Sam
GNAA, Ray
Just set yourself free
Get a first post, Gus
You don't need to discuss much
Hit the refresh key, Lee
And get yourself free

Goatse.cx Tex,
Widen the page, Dave
Stephen King's dead, Fred
Just set yourself free
Change the article text, Gus
You don't need to discuss much
BSD's dead, Lee
Just get yourself free

Although it grieves me to see Zonk in so much pain
I post "I fail it!" and then start to smile again
Netcraft confirms that Wikipedia explains
About the fifty ways to troll on Slashdot

She said why don't we both karma whore tonight
Thinks about your breathing, you'll begin to see the light
She poured hot grits down herself and I know she was right
There must be fifty ways to troll on Slashdot
Fifty ways to troll on Slashdot

Is it whack, Jack
Viewing tubgirl, Earl
Mod up a flame, Shane
Just set yourself free
KDE sucks, Gus
You don't need to discuss much
Referral link, Lee
Just set yourself free

Great for klik and go applications

[Anonymous Coward]

Well, this new kernel is great news for the http://klik.atekon.de/ service which allows you to directly run the latest experimental linux applications or stable debian packages in a user account by just clicking a link to run and install without messing up your installation (just like selfcontained Apple appliction folders).

The mounting of file systems without root permisson means klik will become even easier to install on linux distributions. And it already runs on several distributions without configuaration.

Re:Great for klik and go applications

[Anonymous Coward]

Gary Silverman recently discovered klik: "1 yr. ago I taught my 71 aged Grandma how to use Kanotix + email/KMail + webbrowsing/Konqueror. She really enjoyed it. 3 months ago she phoned my and complained: Why hadn't I told her about that easy one-click installation method of new software?! I didnt get what she wanted to explain to me. She got angry and hang up, when I told her this was impossible... Last month we went to visit her. She showed me how to do it. You can imagine that my jaws dropped 10+ inches. I must have displayed the most stupid face I ever made in my life."
Source: http://dot.kde.org/1126867980/

So if you would like to see yourself: http://klik.atekon.de/

Re:Great for klik and go applications

[Tandoori Haggis]

That's impressive!

Article text

[Anonymous Coward]

2.6.14

• Released October 27, 2005 changelog

• Numa-aware slab allocator: It creates slabs on multiple nodes and manages slabs in such a way that locality of allocations is optimized. Each node has its own list of partial, free and full slabs. All object allocations for a node occur from node specific slab lists (commit - benchmarks)

• Lazy page table copies in fork() for VMAs without anonymous pages (the ones with anonymous pages are still copied): Defer copying of ptes until fault time when it is possible to reconstruct the pte from backing store, speeding up fork() greatly specially for processes using lots of shared memory (commit)

• Add /proc/$PID/smaps: This file will shows how much memory is resident in each mapping. Useful for people who want to perform memory consumption analysis (commit)

• Add /proc/$PID/numa_maps: This file will show on which nodes pages reside (commit)

• Lock-free file descriptor look-up (commit) - (commit)

• Four-level page table support for the ppc64 architecture: extends the usable user address range to 44 bits (16T). (commit)

• Support hotplug cpu on 32-bit SMP powermacs: When a cpu is off-lined, it is put into sleep mode with interrupts disabled. It can be on-lined again by asserting its soft-reset pin, which is connected to a GPIO pin (commit)

• Add TASK_NONINTERACTIVE task state bit to the cpu scheduler: It can be used by blocking points to mark the task's wait as "non-interactive". This does not mean the task will be considered a CPU-hog - the wait will simply not have an effect on the waiting task's priority - positive or negative alike (commit)

• PPTP (Point-to-Point Tunneling Protocol) support: RFC 2637. Used to implement VPN products (notably, Microsoft in all the Windows versions). Wikipedia article (commit)

• DCCP: "Datagram Congestion Control Protocol". Datagram protocol (like UDP), but with a congestion control mechanism. (LWN article) Currently a RFC draft (commit)

• Implement SKB fast cloning: Protocols that make extensive use of SKB cloning, for example TCP, eat at least 2 allocations per packet sent as a result. To

Re:Article text

[Doc Ruby]

I love it when I get what I want!

Re:Article text

[Anonymous Coward]

Largefile support for accounting

Oh dear. Admin forgets that accounting is running. But it doesn't matter because it can't create files bigger than 2GB. Until now. Cue systems running out of disk space.

Re:Article text

[Anonymous Coward]

With such a massive list of changes, how many new bugs are introduced by this kernel?

Don't get me wrong, I really appreciate the awesome progress made by this point release--it probably contains more advances than most major releases of other OS like FreeBSD, OpenBSD, or NetBSD.

But at what price? Are there point releases of the Kernel that are strictly for bugfixes or is that where release candidates come in? Or patches by individual distros?

Re:Article text

[Anonymous Coward]

With such a massive list of changes, how many new bugs are introduced by this kernel?

16.3

Don't get me wrong, I really appreciate the awesome progress made by this point release--it probably contains more advances than most major releases of other OS like FreeBSD, OpenBSD, or NetBSD.

But at what price?

$12.57 and a cheeseburger.

Are there point releases of the Kernel that are strictly for bugfixes

Yes.

or is that where release candidates come in?

Those too.

Or patches by individual distros?

And those.

Re:Obligatory...

[ch3]

Yeah well being a Gentoo user, I got this news 2 days ago (and it seems it just finished compiling)

File descriptor offsets?

[Gerald]

Does it let you determine offsets for open files yet? I'd really, really like to be able to run lsof -o under Linux.

Re:File descriptor offsets?

[CyricZ]

Solaris has offered that functionality for years. Perhaps you'd just be better of using Solaris instead of Linux. Considering Sun's recent actions, it is a very viable option these days.

Re:File descriptor offsets?

[achurch]

Try this patch. It's worked fine for me for the last few years.

Re:File descriptor offsets?

[Anonymous Coward]

My mom said that exact same thing last Tuesday!

Re:File descriptor offsets?

[kasperd]

Try this patch.

I took a quick look on that patch, and on a first look it looks good. I'm surely going to try that out some day, because it is a feature I have often missed.

Re:Obligatory...

[Anonymous Coward]

it takes you 2 days to compile a kernel?
your computer most be from the stoneage then...

Re:Look out Linux gimps, here comes the troll song

[toddbu]

I think the appropriate mod for this would be "redundant" or perhaps offtopic, not troll. Anyone who would mod this as a troll either has no sense of humor or perhaps has never heard the song 50 Ways to Leave Your Lover . You gotta wonder what Paul Simon thinks of this version?

Personally, I'd love to hear a new rendition of You Can Call Me Al crafted for Slashdot.

PPTP

[abigor]

That's nice to see this finally in there, very good for those of us that need to use this protocol to VPN in to work. No more MPPE patches for me!

Re:PPTP

[mmclure]

Sorry - this isn't the MPPE patches. This is support for PPTP packets being tracked through iptables. What I believe this will let you do is have multiple PCs behind a Linux firewall be able to use PPTP at the same time (prior to this PPTP through a Linux iptables firewall would work for only one PC at a time.)

Re:PPTP

[abigor]

Damn!

I wonder why the MPPE patch isn't a part of the stock kernel then? It's been around forever.

Re:PPTP

[mmclure]

I'm pretty sure patent concerns are part of it.

Re:PPTP

[petermgreen]

from your description of one pc at a time i'm guessing you mean behind a linux nat.

You are on the Intarweb.

[turgid]

Wow, there's not a single thing on that list of features that I understand.

You are on the Intarweb. Get reading. There is plenty of good information available, epsecially about computer science.

Re:The latest _stable_ version of the Linux kernel

[RLiegh]

I have to agree. I've managed to get 2.6 to work with ubuntu; but only after I chmod -x /etc/init.d/hotplug*.

Assuming they reach a point where 2.6 can play nice w/ hotplug, then I'll check it out again.

Numa aware?

[MrFlannel]

Just what we need, a kernel that can dance along. So, I guess this means it has ARM support?

What is...

[dubl-u]

I wondered what a bunch of those things were. Here's what I found in a quick search:

• NUMA - Non-Uniform Memory Access, a step beyond symmetric multiprocessing allowing for more processors and memory local to each processor
• HostAP - appears to be a driver for certain wireless chipsets that allows your computer to act as an access point
• FUSE - Filesystem in User Space, rather than kernel space
• relayfs - a common mechanism for getting large chunks of data out of the kernel safely, apparently for thing like tracing
• securityfs - apparently another pseudo-filesystem that is meant to unify things that are being handled in different ways now.
• DCCP - Datagram Congestion Control Protocol, apparently part-way between TCP and UDP, DCCP provides congestion control without TCP's reliability guarantees. Meant for streaming media, MMORPGs, and other apps that need UDPs timeliness but don't want to blindly flood links

Just a quick scan of pages, though, so I could be off on some of these.

Re:The latest _stable_ version of the Linux kernel

[l3v1]

I don't think you not being able to configure a cdrom under 2.6.x is really the fault of the 2.6 kernel branch. You either have some cdrom no living human on this planet supports, or you're in the need of some linux-knowing friend living nearby.

Thinkpad owners, old and new

[karmaflux]

Not only does this kernel support the Active Protection system on newer thinkpad hard drives, it also supports DRM for the Savage graphics series. Most importantly for me, as a T23 owner: they fixed the crash-on-resume bug in the SuperSavage series!

Re:Thinkpad owners, old and new

[plj]

So now they have DRM support in Linux kernel?! Eeeevil!!!

*ducks*

Re:Thinkpad owners, old and new

[Otterley]

Except that the Active Protection support doesn't actually stop the disk from spinning and park the drive heads like it should. It merely makes the sensors available to userspace applications.

Truth in advertising, kids!

Re:Thinkpad owners, old and new

[samurphy21]

Even if it did work in linux as the sensor designers intended, it would make little difference. The active protection system sucks, and at my office we still end up replacing about half of the over 5000 IBM Thinkpad hard drives in circulation every year due to mysterious, spontaneous failure. They lasted a lot longer, with a failure rate of around 10-15% back in the days of the Thinkpad 385ED (a p266 based system) but most of that can be chalked up to how much more capacity the new drives (40-80G) have versus the old ones (6-10g).

Re:Obligatory...

[Anonymous Coward]

Would you like a muffler with that?

FUSE is way cool

[Anonymous Coward]

Check out FuseFS, for example (see why it's cool). Or encfs (see O'Reilly article).

Linux is starting to go beyond emulating the Unixes of yore, to create a whole new world of computing.

Re:FUSE is way cool

[EvilSporkMan]

Sounds like that's approaching what Plan 9 was supposed to be...very interesting. I don't like network filesystems (an example from the linked article) that much, though, because mv, cp, rm, and friends don't give you progress indications.

Error:

[DJCater]

missing ) in parenthetical

(currently a RFC draft, PPTP, full 4 page-table support for ppc64, numa-aware slab allocator, lock-free descriptor lookup' and many other things. The changelog is also available."

Welcome to Slashdot.

Higher-level features

[Anonymous Coward]

Wow, there's not a single thing on that list of features that I understand.

Much of what is on that list is a bit esoteric, but I think you might be exagerating. If you don't know what these are, you don't deserve the title of ``geek'':

PPTP (Point-to-Point Tunneling Protocol) support: RFC 2637 [ietf.org]. Used to implement VPN products (notably, Microsoft in all the Windows versions).

IPV6: Support several new sockopt / ancillary data in Advanced API (RFC3542)

FUSE: Allows to implement a fully functional filesystem in a userspace program

9P support: Linux port of the Plan9's 9P protocol

Suspend support for CIFS filesystem

HostAP: Adds support to work as "Wireless Access Point"

Driver for the IBM Hard Drive Active Protection System (HDAPS), an accelerometer found in most modern Thinkpads (LWN article)

Add Apple USB touchpad driver for the USB touchpad which can be found on post-February 2005 Apple Powerbooks

Largefile support for accounting: The accounting subsystem in the kernel can not correctly handle files larger than 2GB. This fixes it by adding the O_LARGEFILE flag

Re:Higher-level features

[bastardsquadmuzz]

> Driver for the IBM Hard Drive Active Protection System (HDAPS), an
> accelerometer found in most modern Thinkpads (LWN article)

I read an interesting article about this in Linux Format recently. Apparently the people who were working to get this protection system functional found that they could also use the data from it to calculate the exact orientation of the laptop. They created a demo where an image of a laptop stays parallel to the ground whichever way up you hold the laptop. At least, thats what the article seemed to indicate. I don't have any links to back it up.

Re:The latest _stable_ version of the Linux kernel

[gall0ws]

It was just an example :)

PS. Now my cd-drive works.

Re:Reiser4? -- victim of politics+human nature

[toby]

By all accounts Reiser4 deserves to be in the kernel -- it's great forward-looking technology; reiser3 is a great success. Unfortunately Reiser4 seems caught in the crossfire of egos, and nobody wants to rise above petty squabbles (and I'm not blaming Hans. He's the guy who's invested all the energy and no small amount of intelligence into the product, for grot's sake).

It's time, IMHO, for Linus to pull rank and just order it merged.

But...

[WTBF]

But does it run linux?

how does this apply to ubuntu

[Cannedbread]

when will ubuntu get it?, i just ordered an intel/pro 2200 wireless card and so this makes me happy.\ but still i notice no changes to the orinoco wireless drivers.... this card has been around for ages, and is beloved by many wireless hackers, and yet, the kernels drivers for this card do not allow it to scan. whats up with that?

Re:how does this apply to ubuntu

[Andrew Tanenbaum]

In about a year.

Re:how does this apply to ubuntu

[level_headed_midwest]

Yeah! I know- I have an Orinico Gold 802.11b card sitting in the bottom of my laptop. It's a 3-year-old card and it still can't scan for APs. I wish somebody had gotten onto getting that fixed, but I guess I am guilty as well as I can't code beyond "Hello World."

Re:how does this apply to ubuntu

[Anonymous Coward]

you dont have to code, just install the latest version from
http://www.nongnu.org/orinoco/; that will give you scanning support.

Re:how does this apply to ubuntu

[steve's nose is blee]

There's a driver patch for those cards, I just got it running myself this weekend, email me and I'll help you out with it. snixon (at) gmail (dot) com

Re:Obligatory...

[$RANDOMLUSER]

And your point would be?

Absolutely no difference for those applications

[Andy Dodd]

You've always been able to mount filesystems as a normal user if you set up your fstab correctly. You will never be able to do so without some sort of prior configuration because it's a massive security risk if any user can mount/unmount any FS.

FUSE has nothing to do with security or user permissions for mounting. FUSE allows filesystem drivers to be run in userspace (most likely still with root permissions) rather than forcing them to be compiled into the kernel or loaded as a kernel module. (Similar to binfmt_misc for "executables", where the kernel does not directly execute certain executable files, but can be told which userspace program it can call in order to execute it.)

Re:Absolutely no difference for those applications

[Anonymous Coward]

Well, this klik developer thinks FUSE will aid in some significant way in the future.

http://www.kdedevelopers.org/node/1578

WOOT!

[Andy Dodd]

They fixed SBP2 device removal!

(Previously, removing the SBP2, aka IEEE 1394 storage device, driver from the kernel had a habit of doing Bad Things.)

Re:Reiser4? -- victim of politics+human nature

[lubricated]

If it's anything like 3 was when it came into the kernel please leave it out. 3 was only let into the kernel because reiser bitched and bitched, but it was unstable and buggy. I have been much happier with ext3.

SMP AMD64s need this version

[Jay Maynard]

If you're running an SMP AMD64, you need this version to avoid random segfaults. It turns out that 4-level page table support on all but very current AMDs tickles a processor bug. See this discussion on the kernel Bugzilla for more detail than you ever wanted to know.

Re:SMP AMD64s need this version

[PenGun]

If you are running any x86-64 with Nvidia cards this fixes several things. Quake 4 for one ;).

    PenGun
  Do What Now ??? ... Standards and Practices !

Re:Reiser4? -- victim of politics+human nature

[Bloater]

Linus won't order it in since Andrew Morton (his right-hand man) has already indicated that it will go in. There are a few concerns raised by Christoph Hellwig (lkml's resident pitt-bull) that Andrew Morton has asked to be fixed before it goes into vanilla. Mostly these issues have only held up inclusion (a filesystem would normally have got merged with just those style issues) because of concerns that after inclusion the code would be abandoned and even cleanups being opposed by the original developers as allegedly happened with reiser3.

features and performance are *not* the top priorities in Linux, the top priority is maintainability. The rate at which features and performance improvements are added is a consequence of the maintainability, which must not be compromised for the sake of a slightly cool filesystem.

reiser3 solid as a rock, today

[toby]

I've heard people complain about reiser3 who were presumably burned by early versions. Never had any problems myself in 30 or 40 reiser systems (desktops, laptops, servers).

Re:reiser3 solid as a rock, today

[Fnord]

I've been burned repeatedly in multiple production environments with recent (as of the beginning of this year) and every reiser installation has failed. This isn't annecdotal "yeah I used it once on questionable hardware and it didn't work right" evidence. This is "I had 18 storage servers storing 125 million files apiece on decent SCSI raid cards with enterprise quality disks, and every one of them was corrupted within eight months, while the 6 using ext3 (because they weren't as many small files) were completely fine". Reiser3's performance for lots of small files beats everything else out there, even some dedicated storage systems like NetApps, but it trades any semblance of data integrity to achieve this. I'm afraid to even try Reiser4 if this is the kind of software Hans Reiser puts out as stable.

Re:Reiser4? -- victim of politics+human nature

[dubl-u]

and I'm not blaming Hans.

Reading that thread, I'm not sure why. ReiserFS may be the bees' knees, but that's no excuse for that kind of behavior. Kernel style is kernel style; if Reiser thinks they should change kernel style, that's a reasonable thing to discuss, but the fuck-you-my-code's-better-than-your-crappy-code routine sure isn't the way to go about it.

Where it destines...

[rnd0110]

I just wonder where adding new features will lead Linux (or any other actively developed OS). Aren't there any conceptually simpler ways on the horison to help support all that hardware? Are there any new OS architecture ideas
not just extensive growth? Are there any good ideas for the silicon side as well? I do not believe CPUs need to be
that complicated...

It's great Linux stays on top of the hardware complexity race, though. As I said, I just wonder...

Re:Where it destines...

[Dan_Bercell]

You can bet the big companies like MS, IMB, HP...etc have departments doing research into this area, as it would be big money.

Re:Reiser4? -- victim of politics+human nature

[toby]

features and performance are *not* the top priorities in Linux, the top priority is maintainability.

There is little to indicate Namesys' code is less maintainable than anyone else's. Most indications are that it is probably significantly better than many subsystems. Reiser4 in particular has been redesigned for modularity, etc...

Plan 9 protocol and FUSE

[spitzak]

If these work, this is BIG news. IMHO these make Linux into a completely new operating system, not just a Unix clone. Everything a computer process can think about should be named in a single hierarchial namespace. Until now all operating systems except Plan9 have been bogged down by concepts that think that only blocks of bytes on a disk are eligable for this naming scheme.

Expect vast numbers of FUSE programs. In the future I expect *most* non-trivial programs to actually be FUSE programs.

Re:Plan 9 protocol and FUSE

[Short Circuit]

I look at my (admittedly small) AMV, and MOD/STM/S3M/XM/etc. collections, and wish they had a consistent and useful naming scheme. I've always wanted to write an app that would allow me to browse my collections logically.

There's two ways to do this. One would require creating huge volumes of symlinks for the different ways I'd want to search my collections. The other would be FUSE.

Of course, even with the inclusion of FUSE into the kernel, it's not like I'll have time to actually go and write it.

Another app I'd like to see would be remote access to CD/DVD writing devices. Basically, a network-operated cdrecord. But I've had no illusions about being able to write that...

Re:Plan 9 protocol and FUSE

[benow]

Yeah, fuse is nifty. I whipped up a little db backed browser for offline media... intend to tie it to jukeboxes for autoload, cache and stream of files on optical media. With the db backend, the data can be represented in many hierarchies (album/artist/label/etc), and as there are fuse java bindings, coding, expansion and integration with db/web systems is easier. It is still tree based, and it is a bit slower than in kernel fs, but many uses for it, certainly.

Re:Plan 9 protocol and FUSE

[Anonymous Coward]

couldn't you just export /dev/hdc via nfs? (over gigabit LAN, with good drivers, this *should* work perfectly, right?)

Re:Plan 9 protocol and FUSE

[Short Circuit]

The problem is that I'm not satisfied with the filenames currently given the files. Placement of different fields, such as name, author name, video source, etct., is inconsistent. And sometimes important fields are omitted altogether.

If I were to write this application, I'd want the filenames to be generated from stored metadata.

Re:The latest _stable_ version of the Linux kernel

[Anonymous Coward]

Odd numbers (like 2.5 and 2.7) are only used for experimental kernels. What you're really waiting for is a 2.8 kernel, and given the life of 2.6 I don't see 2.8 coming anytime soon.

that's kind of the point

[lubricated]

I think reiser 4 should be delayed untill it's ready this time, instead of burning a bunch of users, like 3 did.

Re:that's kind of the point

[CaptainPinko]

things never mature till they are released and live in the real world... just like the 2.6 kernel

Re:that's kind of the point

[Anonymous Coward]

I agree about reiser being delayed. Ive had Reiser4 destroy 2 filesystems, it worked fine for about half a year then they both decided to die randomly, none of the fsck/repair tools did anything when rebuilding the superblock and filesystem, probally the atomic stuff was screwing up. Happened on both amd64 and 32. Also i think desktop users should avoid it, it might be a fast filesystem but it is a cpu hog, my computer is running faster on ext3 than it did on reiser4.

modern wifi, finally...but more needed

[drwho]

This is great, now that HostAP and Centrino are in the kernel. We've needed this to be in the mainstream kernel for some time. But Atheros support is still missing, and it's just as important, if not more important, than either of those chipsets. Most people are aware of the MadWifi drivers with closed-source HAL (i.e. part of the driver is closed source), but there's also a project by OpenBSD to make a completely open source driver for the Atheros cards, called OpenHAL. It's been ported to linux: http://cvs.pdos.csail.mit.edu/cvs/roofnet/release/ openhal/ - but needs testing. Please work on it!

Re:modern wifi, finally...but more needed

[Sancho]

I was under the impression that ipw2200 drivers still required a binary-only module to operate. Has this been changed, or do 2.6.14 kernel users just need to download that module now (rather than the whole driver package) in order to have a functional wireless card?

Re:modern wifi, finally...but more needed

[Anonymous Coward]

The centrino drivers need a firmware to run. This isn't the same as a closed source module because the firmware doesn't run on the CPU, it executes on the subprocessor of the card itself (and thus can't screw up the entire system AFAIK). //fatal

Re:modern wifi, finally...but more needed

[Anonymous Coward]

Theres another version which has been posted on the linux networking mailinglist on August 5. (Search for "atheros driver" at http://news.gmane.org/gmane.linux.network )
One of the madwifi developers told me about it and said that he thought that it was more promising then the "openhal" version. I bet that if it works out it'll hopefully be easier to merge since the madwifi(+openhal) code would need some serious cleanup (removing wrapper/compability macros) before it'll get anywhere near merge-ready. //fatal

Re:modern wifi, finally...but more needed

[Anonymous Coward]

Apparently this is the place to get the drivers posted to netdev: http://mateusz.agrest.org/atheros/ //fatal

Re:Reiser4? -- victim of politics+human nature

[Bloater]

The vfs already has modularity, and the vfs is *the* Linux filesystem where the filesystems are modules that implement separate storage backends but all the same semantics.

One problem with reiser4 (now addressed in the code proposed for inclusion at this time) was that it changed some of the defined semantics of the vfs. This bit won't go in until it is thoroughly discussed and user-space has subsequently been prepared for it (and deprecation of the old behaviour widely expected).

The problem with the modularity of reiser4 is that is implemented fully inside reiser4 instead of being designed as a modification of the vfs where reiser4 simply provides one storage backend. The reiser4 modules should have been put right up behind the vfs as a proof of concept for the first integration, where the new modularity features could be moved bit-by-bit into the vfs, where all filesystem are then just a storage backend and all could be easily made to support the transaction and query facilities expected.

Some of the style problems included things like generic datatypes being implemented in the reiser4 directory instead of as a general facility for the kernel as a whole. Most of these were fixed, I believe, but AFAIK the problem of the level at which the modularity is implemented, and the failure to distinguish between semantic/feature modules and storage backend is not a good design.

Re:Reiser4? -- victim of politics+human nature

[IpSo_]

Reiser3 is FAR from abandoned by Namesys. Anyone can post patches to it and get them in the kernel, Hans has no control over that, and it has been proven because SuSE developers have gotten patches in to the kernel against Hans wishes.

ReiserFS3 is "version 3" of the Reiser filesystem. Hans wants it to be deemed "stable" and free from new FEATURES, and only bug fixes be applied. Any new features he wants to put in the next version of ReiserFS, v4. Rarely do you see MAJOR features from Kernel v2.6 being backported to v2.4, there is reason for that, because with features comes bugs.

For some reason people consider this to be abandoning Reiser3. When it is quite the opposite.

Stability

[Penguinoflight]

Yeah, everyone likes to get their features, but whats the point when your kernel is unusable? This is not just a subrelease, its the 14th subrelease of the 2.6 kernel. Linux 2.4 is too old to be usable with newer systems, and 2.6 may be totally unstable on your system. Most of the features mentioned in this release aren't even implemented in manufactured system hardware, so their inclusion is not urgent.

I would have much rather read "New features: nothing" at this point in the development of 2.6.

Re:Stability

[Anonymous Coward]

The point is that for the majority of users out there, 2.6.14 will probably be stable unless the kernel team really screwed up. If it's unstable on someone's system, they can revert back to 2.6.13 or earlier. I doubt many main stream distros will ship this without testing it, so the impact of your complaint? Probably less than 1%. Go back to your mom's basement.

Re:Stability

[Slashcrunch]

So if 2.4.x doesn't float your boat, try something a little behind the leading edge such as 2.6.10

You haven't said the 2.6.14 kernel is unusable, you hint that it could be. You say that it _may_ be totally unstable, not that it is. What is the actual problem? You smell very troll-ish to me.

I'm more than happy with the pace of development and I can stick with an older release if I need to. History shows that if you wait a bit your hardware will be supported. Whats the problem here? Sounds like a lot of complaining over nothing to me.

Re:Stability

[q.kontinuum]

But you did notice the new versioning system of the linux kernel lately, didn't you? From http://en.wikipedia.org/wiki/Linux_kernel#Versions

For illustration, let it be assumed that the version number is composed thus: A.B.C[.D]

A D number first occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code. However, there were not enough other changes to legitimate the release of a new minor revision (which would have been 2.6.9). So, 2.6.8.1 was released, with the only change being the fix of that error. With 2.6.11, this was adopted as the new official versioning policy. Bugfixes and security patches are now managed by the fourth number, whereas bigger changes are only implemented in minor revision changes (the C number).

So, if you want stability go for the 2.6.13.4, it contains all bugfixes since 2.6.0 release (dec. 03), and the newest features are released already for 2 months and therefore tested.

But I do agree that it looks like the older stables are not maintained very long, e.g. when I look at the changelog to the 2.6.12.[1..6], none of the patches is available for the 2.6.11, also I'm pretty sure some of the fixed bugs are there as well.

So basically, if I want the latest bugfixes, I also need to accept features which are only released for two months and therefore might be unstable. I think, it would be a very good idea to pick one stable release p.a. and maintain it a bit longer, e.g. the 2.6.11.

Re:Stability

[Penguinoflight]

Yeah, I'm too optimistic for some. Depending on your system the latest C-version of linux 2.6 may be completely unstable, or run just fine. When you make landmark changes to implement drivers for hardware, hardware that hasn't even been implemented in systems as of yet the result is random instability.

I hadn't heard about a shift in release style that the unlce poster mentioned, but as he stated, it doesn't really matter in practice. Earlier on a Quazi-"D" release was implemented as linux 2.4.12, which was really just a mission critical patch to 2.4.11.

Obviously with all the lingo used to discuss this topic, the kernel versioning system is too complex, and implemented incorrectly. There is no reason for fundamental changes to be implemented in the "C" revisions.

Gentoo users do not compile...

[phsdv]

Gentoo users do not compile but they emerge world all the time.

I myself emerged sys-kernel/gentoo-sources-2.6.13-r3 on Sat Oct 15 12:31:27 2005, So it is really time for a new kernel!

Re:Gentoo users do not compile...

[The_Dougster]

Actually I'm currently running Gentoo but I only emerge -uD world maybe every six months or so. It takes me maybe a weekend to do this, so I generally wait until there have been massive changes before I put on my hard hat and rebuild everything.

I'm a really really old Linux user though. I was running Debian back in 1992. I still use Debian for all my peripheral machines which I don't want to spend a lot of time pissing around with for upgrades, but for my personal ricer box I find that Gentoo is a lot of fun to have.

There's no need to emerge world just for a new kernel, although I do typically use the gentoo-dev-sources for my kernels because they include those spiffy bootsplash patches with the framebuffer graphics consoles which I'm a sucker for (lol). I can personally attest that a GeforceFX 5900 can run vesafb graphics consoles and OpenGL accelerated X with no problems.

Linux graphics have never been better in my opinion. Now all we need is a decent GPL 3D drafting package, and I'll be in GNU Heaven.

Re:Gentoo users do not compile...

[phsdv]

Actually, every few weeks I do an emerge -pvtuDN world and see what I really want to upgrade.

Re:The latest _stable_ version of the Linux kernel

[Sancho]

The combination of my DVD-rom + sata controller caused me to lose the /dev entry for my cdrom when moving from 2.6.(around 8) to the 2.6.++(around 8) using th same kernel configuration. In fact, no kernel configuration would give it back except using ide-cdrom. That didn't give me DMA support, so DVD playback was nearly impossible. This was before the new kernel numbering scheme, so this sort of thing really shouldn't have happened.

It wasn't a user configuration issue. To get DMA support back, you have to change a define in a header file for the SATA driver. That isn't something your average user should have to do, and it's definitely not something your average user is going to be able to figure out for him/herself. It's also not within my definition of "stable".

Final straw

[Anonymous Coward]

I think this release of the Linux kernel is the final straw for me using FreeBSD.

Their failure to implement a fully functional ext3 makes it impossible to find a decent FreeBSD hosting company that offers virtual file partition management via web interface. Even with upcoming Xen3, most providers will be using Linux hosts and the inability to mount/resize FreeBSD partition is just another barrier for making FreeBSD available customers.

This latest release of Linux kernel is just another example of how difficult it will be for other OS to catch up in terms of continuously improving performance and features.

Here I come Debian. A formerly loyal FreeBSD fan since 3.x that is reminded of how Amiga lost out by failing to do simple things.

Re:Final straw

[Malor]

The Linux kernel has many features, but it has them at the expense of stability. This new kernel did not drive the network card properly on my server, an Athlon 1900+ on an ASUS K7V333. It complained about stuck interrupts.

To get it to run, I had to remove the 'noacpi' line from the kernel boot parameters. This makes me very nervous, because I ADDED it to fix a problem with the software RAID code on this machine. I got occasional, mysterious "ACPI error" messages in the system log, with no other explanation whatsoever. Then my RAID started failing routinely. One particular drive always failed, so of course I thought it was the drive, and replaced it. The new drive immediately started failing in exactly the same way.

Only by adding in the noacpi line was I able to use the system reliably. Now that noacpi no longer works, I may be backed into a corner... I may end up having to switch to some other server software I can trust. The Linux team's refusal to maintain old code without adding new features, just waving their hands in their air and saying that the distros will make it right, doesn't work for me. I already switched my firewall over to OpenBSD because I was tired of the incessant patching, security hole after security hole. On a CF-based system, that's a pain in the ass to administer. I haven't had to touch OpenBSD since I installed it, months ago.

I like features, but first and foremost I use open source software because it doesn't break. At least, for a long time, it didn't. The 2.6 kernel has directly cost me a couple hundred bucks, has had an absolute horde of problems ever since it shipped, and just failed for me YET AGAIN.

You may be impressed by all the whizbang features, but more and more, Linux is falling into the exact same trap that Microsoft has... shipping features instead of a solid product.

Re:Final straw

[The Warlock]

If the drive stops failing, they might have fixed that bug, and if it starts failing again, revert to the older kernel. After all, if it ain't broke...

Re:Final straw

[Malor]

Right, I did think of that after I posted.... perhaps it is finally fixed. But APIC mode scares me... it's bitten me personally, and I've seen numerous (bad) stories about it from others. I didn't start out particularly worried about it (or anything else in 2.6, for that matter), but I sure ended up that way. And with Linus' reputed habit of doing invisible security fixes, falling back kernels isn't a good idea unless one absolutely must.

Maybe, just maybe, they've nailed it down and it finally works. I'm sure they'll get it eventually. But from past experience, I wouldn't want to bet very much money on any specific release being the likely candidate. They're not letting the old code stabilize. Instead of fixing bugs and having a 2.6 maintainer, they're constantly shoveling new features at us along with the bugfixes. Either we accept them, or the distro maintainers have to work furiously to backport the bug fixes to kernels that are obsolete, being 90 days old.

That's NOT the way to get a stable system. The old way of doing things, with a stable release that lasted longer than two months, worked pretty well. This method, in my not at all humble opinion, doesn't.

One of the core kernel crew, I believe it was Rik Van Riel, said that it was pretty much fine with him if only one 'stable' release in three was actually stable.

Maybe I got lucky, and this is it.

Re:Final straw

[ArsonSmith]

...This just in...

BSD usage drops by 33%

Questioned the other two users both said, "BSD isn't dead yet."

A Linux user was quoted in saying in a british accent, "You'll be stone dead in a minute."

To which one of the remaining BSDers said, "I think I'll go for a walk."

Re:Reiser4? -- victim of politics+human nature

[uhoreg]

Reiser4 is very stable, except for the recent releases. The recent releases became unstable due to the changes requested by lkml, but I believe that it's getting back to its previous level of stability. (When you make large scale design changes like what was requested on lkml, you're bound to get some bugs.) But before those changes, Reiser4 was extremely stable. The developers stopped being able to find bugs, and users stopped being able to crash it. I've been running Reiser4 since last February, and several people have been running it for longer than that, and I've never had any problems with it. When the current users have stopped being able to crash it (and it's already been in the -mm tree for some time), it's time to put it into the mainline kernel, so that other users can start pounding on it.

anyone know any sites

[petermgreen]

that track which versions of the linux kernel are affected by which vunerabilities are fixed in what kernel versions? i'd like to know what kernel versions need to be upgraded or patched (and what to patch them with) to maintain a secure system.

Re:anyone know any sites

[VENONA]

If you're referring to numbered vulnerabilities, the vulnerability announcements are usually coordinated with the major distros, and released after patched vendor kernels are available.

If you use vanilla kernels from kernel.org, you're either going to have to try a snapshot (which carries additional risk) or wait for at least the next release candidate (which probably happens on longer timelines than you'll want).

Of course, you may get lucky, and find that the US-CERT, etc., announcement references a Web page containing code by whoever found the vulnerability. But most often, these only illustrate the problem. You'd have to write and test the patch yourself.

I don't know of any Web site that maintains a history of vulnerabilities against many distros, and all the various vendor kernels and/or patchbands which fix them. I'd love to find such a site, but doubt that it exists.

Re:anyone know any sites

[petermgreen]

All i'm really interested in is the vanilla kernels (if i use a distro kernel i expect the distro to look after it). Is there any site that tracks what versions of the vanilla kernel fixed what security holes?

Re:Just in time

[Anonymous Coward]

I assume this was a joke. Please explain.

Do it now

[PenGun]

Get this one !

    PenGun
  Do What Now ??? ... Standards and Practices !

Re:Reiser4? -- victim of politics+human nature

[slavemowgli]

Christoph (no, it's not me) is not "lkml's resident pitt-bull". He's just someone who knows a lot about filesystems and who's one of the more prolific contributors to the kernel - why Hans Reiser seems to think the he's on a personal crusade against Reiser4, I don't know, but I think it says a lot about Hans' own attitude. Christoph is trying to offer helpful suggestions and point out flaws in the current code, and he does have valid concerns. The real problem is that Hans is not a coder anymore who cares about code quality first and foremost, but rather a businessman - and he's willing to push a flawed product instead of trying to fix it, although why, I can only guess (it certainly does not seem to save him time). It seems to be some sort of ego thing, even though he admittedly can be rational and listen to concerns voiced by others at other times, too.

Oh, and it's "pit bull" - with one "t".

Oh, no!

[Anonymous Coward]

There goes the last *BSD user...

Re:The latest _stable_ version of the Linux kernel

[dtfinch]

The libata switch also broke support for S.M.A.R.T. monitoring on SATA drives. The driver simply wasn't ready for production use. So if you had a server full of SATA drives, and you updated from an early 2.6 kernel to a recent 2.6 kernel, you no longer have any way to know if some of your drives are nearing their end of life, or if some of them are running too hot.

Ham Radio support is good.

[jd]

It stops your wifi link from getting hungry.

A little more explanation

[jd]

9P allows you to share resources transparently - none of this "it's printer X on machine Y" nonsense. For most home users, that's not such a big deal - there aren't that many computers or devices. But even there, there may well be times when you want to move things around, or your roommate does so when drunk, and you still want things to work the way you'd expect.

IPv6 isn't a big deal for most people. Yet. If you've a laptop with IPv6, and you are in a cafe with wireless IPv6, then you move to a bookshop with wireless IPv6, you'd carry the connection with you. No disconnects, no reconnects. If you're instant messaging, nothing is lost. If you're listening to an Internet radio station, you'd not even detect the switchover. Which is all great, but not something that's actually widespread.

NUMA allows multiple processors to access memory "non-uniformly". In other words, normal memory has to all be reachable at the same time. Everything in lock-step. NUMA allows you to get past that limitation. If you're building a cluster and want all of memory to be seen as a single thing, not lots of chunks that are disconnected from each other, it is great. For everyone else, NUMA has no particular value at this time.

PPTP is only useful if you're wanting to connect to Windows machines using some of their fancier remote-access protocols. For that, it is unbeatable. Largely because Microsoft won't talk to anything else.

HostAP is great if you've a laptop with wireless and a PC connected to DSL or cable. You can turn your PC into a Wireless Access Point and give your laptop full access to the Internet. This is generally better than using any wireless option in your DSL modem or cable modem, because those generally suck for security or reliability.

Re:A little more explanation

[Anonymous Coward]

NUMA allows multiple processors to access memory "non-uniformly". In other words, normal memory has to all be reachable at the same time. Everything in lock-step. NUMA allows you to get past that limitation. If you're building a cluster and want all of memory to be seen as a single thing, not lots of chunks that are disconnected from each other, it is great. For everyone else, NUMA has no particular value at this time.

No, this is wrong.

First of all, Linux doesn't have SSI clustering support. There are some patches that do it, but for now if you want to take advantage of NUMA, you need a NUMA machine, which is definitely not a cluster.

Second, NUMA is of particular value for everyone with an AMD Opteron system with 2 CPUs up to someone with an SGI Altix with 512 of them. And it will only get more pervasive.

Re:A little more explanation

[Q2Serpent]

IPv6 has built-in support for re-configuring upstream routers to find your machine on a new network, with a new IP, automatically? Where an I read more about that?

Thanks for the Promise TX4000 Support!

[ic3p1ck]

Got myself a Promise Tx4000 card last week and was surprised that kernels before 2.6.13 didn't support it fully - the card was detected but the ATA disks weren't. I called the supplier and they gave me the 'linux not supported - buy at your own risk' speech. I was about to give up when I discovered that the latest kernel 2.6.13-rc5 (now 2.6.14) finally added support for the ATA channels on this card.

Thanks. It's much appreciated.

Re:Reiser4? -- victim of politics+human nature

[Bloater]

> Christoph (no, it's not me) is not "lkml's resident pitt-bull". He's just someone who knows a lot about filesystems and who's one of the more prolific contributors to the kernel - why Hans Reiser seems to think the he's on a personal crusade against Reiser4,

I don't doubt that he is very skilled, but he's still the resident pit bull, if you've read any of the flame fests he's been involved in. He jumps in to just about every fireball conjuring match that rears its ugly head on lkml (Hans Reiser is similar in his conviction, and that is the reason for their professional relationship problem that has undoubtedly delayed the passage of reiser4).

Re:Look out Linux gimps, here comes the troll song

[jBabel]

Wow! Congrats, this is funny as hell.

Re:Reiser4? -- victim of politics+human nature

[Anonymous Coward]

I agree that it would be nice for reiser4 to be in the kernel AND STABLE. The problem is, reiser4 isn't stable enough. Last thing I heard was that there needed to be some big updates/changes to the kernel. I expect reiser4 no sooner than 2.6.16.

Have you tried running reiser4 on any setup? If you pop into the channel #gentoo-amd64 on freenode IRC and ask them about reiser4 you'll find out about some weird problems that NEED to be fixed before its merged into a stable kernel. Also, try asking at #gentoo, the generic x86 channel, you'll probably run into some interesting stories :)

Don't get me wrong, I'd really like to start using reiser4 for everything now, but its far to risky for my data.

As for reiserfs [reiser3], its really stable and really nice now :) I use it for everything! (Yes, even the boot partition)

When reiser4 comes stable in the kernel, i'll be one of the first to test it out!

-Vlad Blanton

Re:Reiser4? -- victim of politics+human nature

[macshit]

The situation is even weirder than that... I've read most of their exchanges, and as far as I can figure, a lot of the friction in this particular case stems from a bizarre ego thing with Hans: Christoph seems to be somewhat young, and Hans apparently feels that as "a professional", it's beneath him to interact with Christoph as an equal (despite the fact that Christoph seem to be as knowledgeable and skillful as anyone else in this area).

Hans' attitude obviously collides rather disastrously with the largely meritocratic nature of the LKML. Luckily, he really does want to see Reiser4 go in, so after blowing large volumes of hot air (not helped by Christoph's general lack of tact), he finally settled down and began to deal with the technical issues instead of feeding his ego.

Allow me to translate

[jitterysquid]

Mooo. Moo moo moomoomooo, moo moo. MOO!
Moomoo moo moo moo moomoomoomoo.

Now, that's a pretty rough translation of the first point into simple Jersey. I haven't taken the technical/medical Jersey course yet so I can't translate some of the more obtuse bits. I hear that Guernsey is a little more suited to expressing computer science topics but I can't find a teacher.

Re:The latest _stable_ version of the Linux kernel

[Zey]

Mod the parent up. There's no way you can consider the 2.6 series stable when it's living on the bleeding edge.

The old ${Major version}.${odd|even}.${release} method solved the issue perfectly: if you're a kernel developer or you want the very latest, you ran from the odd Dev branch. If you're running a remote server or otherwise don't want to/can't take the risk, you ran the even Stable branch.

It was a big strength of Linux and it's greatly disappointing that this sensible system wasn't continued.

Re:The latest _stable_ version of the Linux kernel

[Anonymous Coward]

Try this:

smartctl -d ata -a /dev/sda

This will pass through the SMART commands on recent kernels.

your Linux problems

[r00t]

Let's start with "noacpi". This is a very bad thing to specify, as you've seen. Modern systems rely on ACPI. Many of us think that this is gross, because ACPI requires a byte-code interpreter in the kernel, but such is life as designed by some nameless Intel committee. Your BIOS settings should be all hot-plug, plug-and-play, ACPI, buzzword++. Linux works quite well with those settings. You're expected to have udev to manage /dev, the hotplug tools, etc. This is how modern hardware is intended to be used, and you'll get burned if you try to stick to the comfortable old ways of static configuration.

I presume your OpenBSD firewall is not on such modern hardware. Linux is the UNIX-like system that is most tolerant of this brave new world of hot-plug hardware.

As for your software RAID, you'll need to file a proper bug report. I have a guess though: your BIOS, via ACPI, is playing with power management settings or doing something related to suspend and resume. This scrambles the drive. Send BIOS settings info with your bug report to linux-kernel@vger.rutgers.edu please.

Re:your Linux problems

[Malor]

Well, perhaps it is indeed finally working... the ACPI messages describe the chipset by name now (VIA KT333), and are much more verbose about exactly what they're doing. I did think of the BIOS angle, and there have been no updates on this board in many, many moons. It was perfectly stable for me under Win2K as a desktop, a very nice board, and it stabilized nicely in noacpi mode. I do not think the board or the BIOS were at fault. I definitely haven't made any BIOS-level changes between then and now, so the increased verbosity leads me to believe that it now understands the chipset and will work. It didn't before, and mysteriously broke without any warning at all.

<rant> It should have, very clearly, told me that it didn't recognize the chipset it was on and that it was GUESSING at the settings. That would have saved me a couple of hundred bucks, because that would have been the first thing I'd have looked at, instead of replacing a functional drive. The total lack of any kind of reasonable error message whatsoever cost me. On top of that, this new changed behavior (suddenly noacpi doesn't work anymore) in a theoretically 'stable' line of kernels is pretty crappy. Freeze the features and go off and play in your own sandbox. When you're ready for testing, I'll happily jump in and start beating up on the RCs, once every 18 months or so.

I don't have time to do that every six weeks as yet more untested, unproven code is jammed down my throat along with the bugfixes I need to the LAST batch of untested, unproven code. I'll happily be QA once in awhile. I don't want to be QA all the damn time.

Re:your Linux problems

[Malor]

No such address. If you're going to tell me to send in a bug report, giving me a good address would be more useful.

: host vger.rutgers.edu[128.6.225.194] said: 550
        5.1.1 ... User unknown (in reply to RCPT TO
        command)

Savage support?

[colinrichardday]

Does this that 3D acceleration will work?

Re:Reiser4? -- victim of politics+human nature

[GreyWolf3000]

There were also issues of code in Reiser4 duplicated code in the VFS and general I/O areas.

abrasive personalities vs the technology

[toby]

I have very little tolerance for bad behaviour myself, but here's why I don't think "refusing to merge his code" is a useful reaction to any abrasiveness on the part of Hans:

1. it pointlessly weakens Linux
2. Hans and his team have done a lot of very difficult and competent work
3. the 'punishment' won't work anyway
4. every public forum attracts flame wars and ad hominems. LKML is no exception; and any grown-up developer should know what to expect and not take umbrage (including Hans).

It could still be refused or delayed for valid technical reasons. But if Hans' comments on the list offend people to the point where they reject his huge contributions, that's worse for Linux than a few strongly worded posts on Reiser's part.

Re:abrasive personalities vs the technology

[dubl-u]

It could still be refused or delayed for valid technical reasons. But if Hans' comments on the list offend people to the point where they reject his huge contributions, that's worse for Linux than a few strongly worded posts on Reiser's part.

I agree that outright refusal of ReiserFS code would be a mistake. But neither do I think the jerkiness, which goes beyond mere strong words, is trivial.

The Linux kernel isn't just a complex bit of technology; it's also a complicated social mechanism. As a kernel user, I don't just want new features now; I want the platform to say viable for decades. Politeness is a social lubricant that reduces wear, and mutual respect repairs personal strain.

The rank of hierarchy.

[jbn-o]

It's time, IMHO, for Linus to pull rank and just order it merged.

What rank would he pull? Or do you really mean state his opinion and hope that it is persuasive to convince those who follow his fork of the Linux kernel to continue in that way? In the free software world, nobody has rank. Some people command more attention ostensibly because of their achievements, or because they have persuaded others that they have good ideas. Positing this as rank leaves many unanswered questions including where this rank came from and how it works absent people who believe they must follow it.

Re:The rank of hierarchy.

[toby]

I mean "pull rank" in the way that he often does in this context - that may not amount to much more than firmly stating his position. This happens on the list with some frequency and effect. He didn't say anything in the cited thread, and I don't know what his current position is... Maybe he's already done what I am suggesting and I just missed it.

Plan 9 and Reiser4 better than UNIX file semantics

[spage]

If you read the ideas behind 9P and Reiser4, it seems time for apps to move beyond the UNIX file semantics we've had for 30 years. The 9P2000 USENIX paper (search for "Grave Robbers from Outer Space Using 9P2000 Under Linux" in the Google cache) mentions specific apps built on 9P, are they going to be part of Linux distributions?

What a great kernel!

Links

[jd]

Mobility was always intended to be part of the IPv6 standard. Originally, the routing protocol was supposed to take care of it, through the use of transient IP addresses in addition to the main IP address. This is the reason IPv6 numbers currently reserve the last 48 bits for your MAC address, with the rest assigned by upstream routers. It was intended to be very easy for routers to simply shuffle your location around with 100% guarantee of no address clashes.

At present, IPv6 mobility depends on a lot of fiddly detail. However, here are some links on how IPv6 mobility works under Linux and how it is currently intended to work:

• Mobile IPv6 for Linux - Includes initial support for "network mobility" (move whole networks around, not just machines)
  
• A study on transient addressing in Mobile IPv6
  
• British Telecom presentation on Mobile IPv6 using a home base system
  
• IETF working group for Mobile IPv6
  
• Historical Notes: Mobile IPv6 for Linux, in the days of the 2.1 kernels!
  

Quick summary: The user's machine registers with their home router (the home base). When they move to a different network, they notify their home router, which then sets up a transitory IP address on the remote network. The home router then cascades back up the routers the message that the fixed IP address of the mobile machine should now be routed to the transitory IP address, optimizing the routing. When an entire network moves, it notifies its home router in the same way, the only difference being that because you're migrating the router, you also migrate all of the machines attached to it - but none of the machines need to know this or be set up to handle it.

Re:The latest _stable_ version of the Linux kernel

[kbielefe]

The concept of "stable" in something as complex as an operating system kernel is highly user dependent. You praise the odd/even system for providing a stable kernel branch, but I had to maintain my own security patch set for quite a while because 2.4.20 or so broke some proprietary vpn software I needed to connect to work. I know I'm not the only one with a similar example.

The bottom line is that only the administrator of a system can create a truly stable kernel for that system. Distributions are the next most effective because they target a specific type of user. Expecting the kernel developers to make a stable kernel that will satisfy everyone is like expecting the government to make laws that everyone is happy with.

While I have seen a large number of generic "2.6 isn't stable" complaints, I don't think I've seen any more complaints on slashdot about something specific breaking on a 2.6 upgrade than something specific breaking on a 2.4 upgrade, especially comparing the first few releases of each series.

Reiser4 under FUSE?

[Falcon040]

Can't Reiser4 go under FUSE as it is?

Is this not the option they are taking?

I thought the whole point of FUSE was to put all the FileSystems in it, or am I mistaken?
Will all the other FSs go under FUSE? Like ext2, ext3, XFS, JFS, etc?

Re:Reiser4 under FUSE?

[imroy]

No, that is not what FUSE is for. Filesystems like ext2/3, XFS, JFS, Reiser, etc are on-disk fs's. There's really no point in putting them into usespace. You wouldn't really gain much, and you'd lose a lot of performance. FUSE is for high-level filesystems, like putting a fs in a database, or interfacing with WebDAV, FTP, Gmail, or Dallas 1-wire devices. There's no real need to put those sorts of fs's in kernel space. There'd be no performance increase since they're using network protocols or some other communication channel with high latency. And being in userspace, they can use handy third-party libraries instead of having to include even more code into (non-swaping) kernel memory. Some are even implemented in Perl or Python. FUSE isn't going to replace all those on-disk filesystems, but it will replace a few network filesystems (not NFS, more like WebDAV or even SMB/CIFS) and it will make it much easier to create trivial fs's. That's what FUSE is for.

Inflexibility == change

[CarpetShark]

I recall hearing that the AFS guys wanted to include it in Linux early on, and that they couldn't because of licensing issues. They *begged* Linus to accomodate them, and his response was, literally, "I DON'T CARE". I haven't really checked, but I think the AFS code in the kernel now proves that adamantly sticking to a well-thought position can work for the best in the end, even if there are initial problems.

There is also the example Richard Stallman, without whom we wouldn't even be having this conversation. He's famous for bugging people with his uncompromising attitudes. But I for one applaud him completely for that, and thank him sincerely.

It's not always true, but sometimes, insisting can be a good thing.

I don't think Hans is necessarily incorrect to have strong opinions. Some of the things on offer in Reiser4 sound great, and I agree with him that Linux should embrace new ideas more quickly. Hell, we're still trying to get ACLs widely accepted in Linux :(

Stallman

[toby]

Richard Stallman, without whom we wouldn't even be having this conversation. He's famous for bugging people with his uncompromising attitudes. But I for one applaud him completely for that, and thank him sincerely.

I heartily agree. Thanks for providing such an excellent example. People's aversion to change, or accepting new ideas, or their "difficult" authors - even when proven brilliant and world-changing - is something that frequently saddens me.

One cannot mention Stallman without some fool popping up and saying, "But I heard he puts kittens in microwave ovens for kicks," or "But I heard somebody disagreed with him once, so I refuse to listen," or "Isn't he that commie who says programmers should work for free?" or "But he wants to take away my SUV!"... There is a line in Batman Begins that sums it up: roughly We always fear what we do not understand.

What is even scarier are the people who work in this industry who don't even recognise the name. Yes, they exist...

You're right it does prove something...

[Anonymous Coward]

But only that at least some moderators are indeed insightful.

unrecognized chipset

[r00t]

It is a given that most chipsets will be unrecognized. This is especially true for new ones, but it's also true for old ones. There are far too many chipsets in the world.

This is usually OK.

Recognizing a chipset is mainly done when the chipset is found to be defective. In this case, Linux may take action to avoid the defects. Perhaps some performance features must be disabled, or some devices must not be enabled.

Re:unrecognized chipset

[Malor]

The problems are worse with the 2.6.14 kernel, not better... it just took awhile for them to start showing. I'm filing a bug report... hopefully it will help.

Kernel Recipe

[Bollenator]

"... then as long as you can follow a recipe you can probably build a reasonably good kernel tailored for your system."

Generally, when I'm following recipes, this isn't the way I do it:

"Eggs. Do I need eggs? No. Powdered products: flour. Do I need flour? Yes. Sugar. Do I need sugar? Heck yes. Sodium Benzoate? What the fizzle?"

*Googles*

"Hmmm, that doesn't help much... Fine, module."

Answer: You don't

[hackwrench]

You save those mod points for things that fit the categories Slashdot gives you. Though Slashdot seriously needs to expand its categories, make karma be a rating calculated between two users preferences/and or relevant to friend foe settings.

sorry, that's the old address

[r00t]

linux-kernel@vger.kernel.org

The vger.rutgers.edu address has been out of service for years.
Out of habit, I still send email there sometimes.