Linux 2.6.22 Kernel Released

An anonymous reader writes "Linux creator Linus Torvalds announced the official release of the 2.6.22 kernel: 'It's out there now (or at least in the process of mirroring out — if you don't see everything, give it a bit of time).' The previous stable kernel, 2.6.21, was released a little over two months ago. New features in the 2.6.22 kernel include a SLUB allocator which replaces the slab allocator, a new wireless stack, a new Firewire stack, and support for the Blackfin architecture. Source-level changes can be tracked via the gitweb interface to Linus' kernel tree."

Comments

What is this?

[Whiney Mac Fanboy]

Seriously, what the fuck is going on with slashdot?

I've read & reread the linked articles, and not a single mention of the iPhone - and it's been over 48 hours since an iPhone story. Seriously - it's like slashdot's turned into a linux site, instead of an iPhone site.

Let's not forget our roots folks - just because linux is the big hype story today.

Re:What is this?

[Corporate Troll]

You do justice to your nickname.

Re:What is this?

[Anonymous Coward]

You will be returned to regularly scheduled programming once they get the iphone to koad the linux kernel.

Re:What is this?

[Whiney Mac Fanboy]

You do justice to your nickname.

Thank you, but I do feel that there's a little too much redundancy in my nick. I mean, if I was called "mac fanboy", you'd assume whiney.

For that matter, if I was just called 'mac', everyone would read the implied 'whiney fanboy'

Re:What is this?

[Corporate Troll]

Nah, redundancy just enhances your whiney-ness, making it effectively recursive and without a stop condition that makes you infinitely whiney. Perfect for a Mac fanboy ;-) (1, Infinite Loop... and all...)

Re:What is this?

[CopaceticOpus]

Seriously - get 2.6.22 running on an iPhone, THEN we'll have a story!

Re:What is this?

[MadJo]

How about an iPhone-like phone that runs Linux? :)

Re:What is this?

[smittyoneeach]

Indeed, you are a double pleonasm, and should take pride in your superfluous redundancy.

Re:What is this?

[smittyoneeach]

2.6.22 certainly has the scalability, but does it hate itself sufficiently?

Re:What is this?

[Bob54321]

I only just noticed that it was Whiney. I always read Whitney. I should have realized - I mean girls on slashdot, what next?

Fire and brimstone coming down from the skies. Rivers and seas boiling. Forty years of darkness. Earthquakes, volcanoes... The dead rising from the grave. Human sacrifice, dogs and cats living together - mass hysteria.

Re:What is this?

[Whiney Mac Fanboy]

I only just noticed that it was Whiney. I always read Whitney.

Whitney mac fanboy? Is that someone called whitney who's a mac fanboy? Or a fanboy of whitney macs? Either way, I'm going to assume you watched the bodyguard waaaaaaaaaaaaaaaaay to many times ;-)

Re:What is this?

[Bob54321]

I honestly can say I have never seen the Bodyguard (or Titanic). I hardly ever have time to watch movies at the cinema and by the time they get to video I just can not bring myself to listen to the soundtrack one more time...

Re:What is this?

[Anonymous Coward]

Doesn't take much common sense to see that we needn't put the pee-pee in the poo-poo.
Form follows function.

Re:What is this?

[Anonymous Coward]

I've read & reread the linked articles

You must be new here, then

Re:What is this?

[Anonymous Coward]

I beg to differ. If you were just called "Mac", I would assume you're a large trucker wearing plaid who somehow bumped into slashdot by mistake. (Perhaps you assumed that slashing dots had something to do with truck racing?)

Re:What is this?

[jsight]

Maybe we should tag every story as "notaniphonestory" for fun. :-)

Re:What is this?

[jd]

That's nothing. Get Slashdot running on an iPhone, and you'll have a story. Well, at least until it melts.

Re:What is this?

[NoisySplatter]

I thought it was whiny mc fatboy, and didn't realize that you just wanted an iPhone.

Re:What is this?

[mikael]

Don't all driving license application forms have a line saying "please tear along the dotted line?"

Re:What is this?

[Ron_DeMara]

here's an iPhone story: http://www.youtube.com/watch?v=Vy20b7pCcrY&NR=1

What's SLUB?

[borizz]

TFA is /.ed and wikipedia doesn't help me. What's so good about the SLUB allocater?

Re:What's SLUB?

[nowhere.elysium]

Dude, Google is your friend: http://lwn.net/Articles/229984/

Re:What's SLUB?

[b1ufox]

http://lwn.net/Articles/229984/

There for you, help yourself.

BTW in short plain english, it adds some voodoo stuff to struct page, removes a lot of metadata cruft from the slab allocator, adds lesser and simple locking after removing most of locks which are not required because of the changes in the cache layer.

So if you are running your kernel on a huge farm of processors of the order of thousand(s), you ll find a remarkable memory saving, which is a big overhead in slab allocation.

HTH

Re:What's SLUB?

[Anonymous Coward]

Here you are.
An article with details, and details from the patch itself.

http://lwn.net/Articles/229984/
http://lwn.net/Articles/229096/

Re:What's SLUB?

[mrbluze]

I dunno.. maybe it means it'll run Linux.

Re:What's SLUB?

[hmallett]

it adds some voodoo stuff to struct page
I believe that brings the amount of the Linux kernel containing Voodoo to 13%.

Re:What's SLUB?

[morgan_greywolf]

I believe that brings the amount of the Linux kernel containing Voodoo to 13%.

Yeah, here's the breakdown of the 2.6.22-generic (Linus' kernel) source from krnl-magick-analyzer:


$ krnl-magick-analyzer --percentages --nice-format
Linux Kernel Magick Analyzer v0.01 -- Monday, July 9, 2007 8:30 AM DST

Linux Kernel Version: 2.6.22
Path: /usr/src/linux-2.6.22

High Magick 10%
Santeria (w/o chicken sacrifices) 5%
Santeria (w/chicken sacrifices) 5%
Witchcraft 8%
Hoodoo 7%
Voodoo (Voudon) 13%
Daemonology 20%
Other 22%

Re:What's SLUB?

[EagleEye101]

No I think you mean the number 9.

Re:What's SLUB?

[Anonymous Coward]

Meh. Not nearly enough.

Gehm's Corollary to Clarke's Third Law: "Any technology distinguishable from magic is insufficiently advanced."

Also, whatever the hell SLUB is, it's eventual replacement just HAS to be named GLUB. Anything else would be a mockery.

Re:What's SLUB?

[0xABADC0DA]

Ah, the GNU/Generation. In Linus/Linux speak:

# cat /proc/sys/kernel/voodoo
1: 10 5:5 8 7 13 20 0x00000022

--
GNU: A recursive acronym "GNU's Newbie Unix"

Re:What's SLUB?

[ncc74656]

Daemonology 20%

Who knew there was that much BSD code in Linux?

Re:What's SLUB?

[dooguls]

Dude,
I haven't cried laughing at a slashdot post in a long time. Wish I had some modpoints to donate.
My wife is looking at me with one of her "Why did I marry him again?" looks.
Hilarious.
--doug >

Re:What's SLUB?

[sjames]

It all started in Sixth Edition Unix with the comment "You are not expected to understand this" in the scheduler :-)

Re:What's SLUB?

[Anonymous Coward]

Then what's in the other part of the 31.7% of the kernel which is written in swahili?

Re:question on the wireless

[nowhere.elysium]

It's a wee bit offtopic, but try this: http://www.linuxquestions.org/questions/showthread .php?t=462105 Insofar as I'm aware, Linksys ones tend to work ok.

SLUB much better than slab

[Anonymous Coward]

Great improvement! SLUB is obviously better than slab, since it's all uppercase. I get a lot of emails these days using uppercase to distinguish their importance. I think it's a good thing the linux community is catching on to this IT trend.

Re:SLUB much better than slab

[smittyoneeach]

Some Lamers Upbraid BLUS
Savvy Llamas Understand Better.
Should Linus Use Buckshot?

Re:SLUB much better than slab

[Anonymous Coward]

Should Linus Use Bitkeeper? :-)

Re:SLUB much better than slab

[Anonymous Coward]

Somebody Likes Usual Backlash... ;)

Re:SLUB much better than slab

[jaju]

...distinguish their importance. You mean, impotence?

Re:question on the wireless

[paxmark1]

I got a Hawking USB with an antenna on it. That really helps me to leech, er, acess the web. It is RT73. I had to configure it manually, but works well now. Documentation a little turgid, but it works. The Edi-Max site probably has a slick set up for it by now. Kubuntu.

The USB ones can be exceedingly difficult to get to work. The directional antenna on this one really does work for me.

Re:GPL v3

[derrida]

I think this is just not true (yet). I haven't read anything in the changelogs.

Anybody

[Jaaay]

have any information on how good the new wireless stack is? That's what I'm most interested in.

Re:Anybody

[ThatSandersKid]

Still probably better than the "messy piles" you get with Windows.

Re:Anybody

[Erwos]

I have similar questions about what happened with the Firewire stack. I run a large number of 1394 drives, and I've always suspected the performance I was getting from them was rather sub-par, even when using the good TI chipets for the controllers.

If anyone could shine a little light on this, I'd be quite pleased.

Re:Anybody

[b1ufox]

Current firewire stack is way too small in size as compared to old firewire stack.

Second now there are less threads in the firewire subsystem, which is indeed good because kernel threads are really really a very stupid idea.

Last but not the least i have used TI firewire chipset with Basler IEE1394 cameras under Linux and trust me they knock teeth out of Windows Firewire stack.It was good and performed good even with two cameras working in real time image inspections.

I suspect the current stack is going to work atleast similar if not better, though i ll bet on it being better.This is a good sign also, as there is no point in patching things but point is in writing the whole messy thing again.And here we are.... hey wait TTY layer ...any takers? please :-)

Re:Anybody

[iabervon]

From a user perspective, it doesn't matter, but a number of drivers for releatively new hardware have been written to use it, which means that there will probably be a bunch more wireless cards supported by the mainstream kernel in the next few versions, and one fewer step to get drivers in 2.6.22. For example, Intel has a new driver for their a/b/g card that doesn't require a userspace regulatory daemon or anything (the firmware takes care of all of that), and this driver uses the new stack; they have plans to get this driver into the mainline kernel, at which point live CDs will start having wifi on new laptops with intel chipsets.

In 2.6.22, the new wireless stack isn't going to make any difference, because they haven't included any drivers that use it yet.

Re:Anybody

[Anonymous Coward]

Some info here:

http://liquidat.wordpress.com/2007/02/06/kernel-26 20-still-no-new-wlan-subsystem/

http://liquidat.wordpress.com/2007/03/02/new-linux -wlan-subsystem-integrated-into-mm-kernel-tree/

http://www.devicescape.com/news/releases/release_0 5-01-06_opensource.php

BTW, Fedora and Ubuntu already include the new stack with their own patches.

Re:Anybody

[xehonk]

I've tried the new stack with my devices. I must say I'm very impressed:
pro
- transfer speed went from about 19MB/s to 31MB/s
- initialization time (time from loading the module until all /dev/sd? entries are visible went down considerably (from a few seconds/device to almost instant)

con
- no multi-lun support: my ide controller (2 hds on one ide controller - one fw node) will only show one hd

Re:Anybody

[Demerara]

From TFA:

"...the new stack is actually a much better ground to build drivers upon that the current mess)."

Now this is really telling. I have heard some voices in the storm complaining about how Linux wireless support really sucked. All too often, these voices were shouted down - "RTFM", "well, it worked fine for me" - you know the drill. To read the 2.6.22 release notes and see the current Linux wireless stack described as "the current mess" is heartening and acknowledges the elephant in the room.

I look forward to downloading and trying the first live-CD distro to incorporate the new kernel and some available new drivers. Out of the box WiFi support - bring it on!

Re:GPL v3

[Anonymous Coward]

Mod parent down! Nonsense generator would do a better job.

But is disk IO fixed on amd64?

[Anonymous Coward]

For anyone in the dark, disk IO has been broken sometime after 2.6.17 on amd64.
I thought I was going crazy, being on 2.6.18 and discovering that any disk activity slows down the whole system, let alone accesses to any other disk.

Then I found a 19-page thread on the gentoo forums that says I'm not alone and it's not unique to a particular chipset:
http://forums.gentoo.org/viewtopic-t-482731-start- 450.html
(with evidence that the deadline scheduler may alleviate _some_ of the problem but not the root cause)

And more importantly the kernel bug report here:
http://bugzilla.kernel.org/show_bug.cgi?id=7372

So I'm happy people aren't ignoring the problem. ...Or should I be worried that something so utterly fundamental has been lost in the shuffle across so many kernels in the past year? Amid all the eagerness to add new features since then (virtualization for example, and now complete rewrites of firewire?!?!).

Why can't we have a 2.7 kernel for this stuff?

Re:But is disk IO fixed on amd64?

[Woy]

Furthermore, i believe this unbelievable bug is spilling into many reports of "slowdowns" in other apps because nobody expects this in the kernel.

Re:But is disk IO fixed on amd64?

[cerberusss]

Why can't we have a 2.7 kernel for this stuff?

So, why the trolling at the end of an otherwise good post? I'll quote Wikipedia for the people who have been living under a rock since 2.4:

The development model for Linux 2.6 was a significant change from the development model for Linux 2.5. Previously there was a stable branch (2.4) where only relatively minor and safe changes were merged, and an unstable branch (2.5), where bigger changes and cleanups were allowed. This meant that users would always have a well-tested 2.4 version with the latest security and bug fixes to use, though they would have to wait for the features which went into the 2.5 branch. The 2.5 branch was then eventually declared stable and renamed to 2.6. But instead of opening an unstable 2.7 branch, the kernel developers elected to continue putting major changes into the 2.6 "stable" branch. This had the desirable effect of not having to maintain an old stable branch, making new features quickly available, and getting more testing of the latest code.

However, the new 2.6 development model also meant that there was no stable branch for people just wanting security and bug fixes, and not needing the latest features. Fixes were only put into the latest version, so if a user wanted a version with all known bugs fixed they would also get all the latest features, which had not been well tested, and risked breaking things which had previously worked. A partial fix for this was the previously mentioned fourth version number digit (y in 2.6.x.y), which are series of point releases created by the stable team (Greg Kroah-Hartman, Chris Wright, maybe others). The stable team only released updates for the most recent kernel however, so this did not solve the problem of the missing stable kernel series. Linux distribution vendors, such as Red Hat and Debian, maintain the kernels which ship with their releases, so a solution for some people is to just follow a vendor kernel.

As a response to the lack of a stable kernel tree where people could coordinate the collection of bugfixes, in December of 2005 Adrian Bunk announced that he would keep releasing 2.6.16.y kernels when the stable team moved on to 2.6.17 [2]. He also plans to include driver updates, making the maintenance of the 2.6.16 series very similar to the old rules for maintenance of a stable series such as 2.4 [3].

Re:But is disk IO fixed on amd64?

[Anonymous Coward]

Wrt the 2.7: I assume that you mean the unstable branch (like 2.3). That numbering system is not used anymore. Now, we have stable releases on all 2.6.x and the experimentation happens between 2.6.x and 2.6.(x+1).rc1 releases. The .rcN are after the feature freeze, where the stabilization happens.

Linus is doubtful whether there will ever be a 2.7.

(Acording to Andrew Morton anyway, http://video.google.com/videoplay?docid=1742374580 386548257 )

Re:But is disk IO fixed on amd64?

[Anonymous Coward]

It's not just AMD, I see the same on Intel. It's been bugging me for ages, and I'd never been able to source. Although taring a large dir will trigger it on demand.

Re:But is disk IO fixed on amd64?

[wild_berry]

I suspect libATA is the problem. Are you using the NF4 or do you also have an SIL3114? And which are supported by the newer libATA IDE mechanism? Check here: http://kerneltrap.org/node/11695

Re:But is disk IO fixed on amd64?

[Anonymous Coward]

"Because Linus said so" is in fact not a particularly valid answer. Yes, Linus has the right to choose the development structure the kernel is now using, but that doesn't mean it is the best way to do it for everybody. dropping the distinction between "stable" and "development" versions was a sloppy, lazy move that simply pushed the responsibility for maintaining stable released off onto the distributors. That has essentially duplicated the work a hundred-fold, because each distribution must do the work themselves. We're told that this is a "better" arrangement, but it is clearly only better for Linus and the kernel developers, because they get to do less work and be lazy when it comes to making changes: "Want to rip out the allocator and replace it with a largely untested one? Sure, why not! Making sure everything works is the distributors problem, not ours!"

After the scheduler screw up early in 2.6 Linus basically threw his hands in the air and decided that hey, stable kernels are hard so fuck it, he couldn't be bothered any more.

He does great work and is a brilliant coder, but he clearly isn't a project manager. Nor, in fact, should he be one. The correct way to do things is to have someone who is a project manager, with a release engineering team, to take responsibility for it all. Fat chance.

Re:But is disk IO fixed on amd64?

[gmack]

"Because Linus said so" is in fact not a particularly valid answer. Yes, Linus has the right to choose the development structure the kernel is now using, but that doesn't mean it is the best way to do it for everybody. dropping the distinction between "stable" and "development" versions was a sloppy, lazy move that simply pushed the responsibility for maintaining stable released off onto the distributors. That has essentially duplicated the work a hundred-fold, because each distribution must do the work themselves. We're told that this is a "better" arrangement, but it is clearly only better for Linus and the kernel developers, because they get to do less work and be lazy when it comes to making changes: "Want to rip out the allocator and replace it with a largely untested one? Sure, why not! Making sure everything works is the distributors problem, not ours!"

Except that the old system didn't work at all. There were just too many changes to stabilize in any reasonable amount of time and while the debugging was happening the 2.4.x kernel was becoming so badly out of date that people (and distros) tried to back port changes from the 2.5.x tree.

The result was TWO unstable kernel trees and the vendor trees had a tendency to be even worse. The old system would have left those people using SATA in a worse situation then they are in now. Keep in mind that SATA came out after 2.6.x so the drivers would right now be somewhere in the 2.7.x series kernel still waiting to be debugged and the stable maintainers would be forced to try and backport the SATA drivers once again resulting in two unstable kernels

Re:But is disk IO fixed on amd64?

[ari_j]

My favorite part of this is that we now have two meaningless components of the version number when one was sufficient. The likelihood of a Linux 3.x is extremely low. But let's keep the 2 around just so we don't forget 1.x. Now that we have 2.6.x.y, what will it take to increment the 6?

Re:But is disk IO fixed on amd64?

[FrostedWheat]

I just upgraded to Fedora 7 and hit this problem .. copying files using rsync from the old computer made the computer unusable until it finished. Glad to see it's not just me. Thanks for the post!

Re:But is disk IO fixed on amd64?

[petermgreen]

afaict adding a SATA driver shouldn't be any more disruptive than adding a driver for any other SCSI or SCSI-like interface.

IMO there is nothing wrong with backporting new drivers (which should only affect people who use the hardware for which the new drivers are designed, not any other users of the kernel) into a stable kernel tree.

Re:But is disk IO fixed on amd64?

[cerberusss]

I have to say that I'm not particularly interested in what the version number means...

Re:But is disk IO fixed on amd64?

[cerberusss]

For me, it works. I'm using vendor-supplied kernels and they get paid for that. I'm not using vanilla kernels, I leave the testing up to the enthousiasts.

Re:But is disk IO fixed on amd64?

[gmack]

IMO there is nothing wrong with backporting new drivers (which should only affect people who use the hardware for which the new drivers are designed, not any other users of the kernel) into a stable kernel tree.

Except that in this thread people have been blaming the SATA problems on the new development method but in this case there would have been no difference.

The downside to backporting was that the differences between 2.4.x and 2.5.x were so large that the driver interfaces had a tendency to be completely different and the 2.4.x infrastructure in some cases just wasn't able to handle the newer drivers. In the case of one RAID card the 2.4.x drivers were just hopeless and I had to actually wait two weeks for 2.5.x to be stable enough and install it on my server and just hope it wouldn't crash.

Re:But is disk IO fixed on amd64?

[Xabraxas]

Yes, Linus has the right to choose the development structure the kernel is now using, but that doesn't mean it is the best way to do it for everybody. dropping the distinction between "stable" and "development" versions was a sloppy, lazy move that simply pushed the responsibility for maintaining stable released off onto the distributors. That has essentially duplicated the work a hundred-fold, because each distribution must do the work themselves.

It sounds to me like you don't remember the 2.4 kernel. Distributions actually had to do more work on the 2.4 kernel than they do now. When 2.4 was current most distributions were backporting 2.6 features into the 2.4 series kernel. In fact, by the time the 2.6 kernel was released some distributions' 2.4 kernels were not all that unsimilar in functionality but were patched to high hell.

Re:But is disk IO fixed on amd64?

[Anonymous Coward]

No, this is not chipset-specific. Most of the problem reports are on Nforce4, but I'm on the old VIA K8T800/8237 and also have 2 different Promise controllers. All exhibit the problem.

Re:But is disk IO fixed on amd64?

[plague3106]

Hmm, if Windows had this problem, it'd be trashed daily here on /. Yet this is the first I've heard of this problem..

Re:But is disk IO fixed on amd64?

[plague3106]

Why would Linux adopt this new model? It seems like a poor decision. System administrators WANT a version that only has bug / security fixes. MS has said that no new features would be added via service packs anymore after the inclusion of the firewall in XP SP2.

Re:But is disk IO fixed on amd64?

[fimbulvetr]

Seems like he's doing OK to me. He might not have the academics down for "Project Management" but that might be one of the reasons _WHY_ it's successful - because he just releases it. People can do whatever the hell the like with it, and are not burdened with the red tape of some team.

Re:But is disk IO fixed on amd64?

[cerberusss]

You don't get it. This already *is* the current model. If you're a sysadmin and you want a dependable release scheme, you need to stick to the Linux kernels that come with your Linux distribution. That distribution typically takes a Linux kernel version and doesn't make big changes during the 2 to 3 year life cycle of the distribution.

Re:But is disk IO fixed on amd64?

[plague3106]

The problem is that upgrading an entire distro is a pretty challenging task. So now not only do you need to update the kernel, you need to update ALL the software that came with the disto? That's even worse. At least with the older model, you had the option of just doing the kernel (which I've done).

Kernel security / bug fixes should not require that you also update your applications.

Also, you now have to wait two to three YEARS before getting security fixes? That's simply unacceptable..

Re:But is disk IO fixed on amd64?

[lordtoran]

Maybe you should stop toggling in your boot sector with mechanical switches and start using a distro with a package manager and all that fancy stuff, you know ...

Re:But is disk IO fixed on amd64?

[plague3106]

How is getting the latest ISO of a distro and running it to upgrade the tedious method? More to the point, why should I have to update applications which ARE working fine just to get security fixes to the kernel? How much lag time is there between a fix getting into the kernel and the distro incorporating said fix?

Perhaps you should try to address my post instead of writing poor insults.

Re:But is disk IO fixed on amd64?

[lordtoran]

Sorry, I understood it a bit wrong. I suppose you are talking about complete distro upgrades, which are required from time to time. In that case, if you decide to stick to the older version and thus not to update the apps, you will have to compile the newest kernels yourself because there will be no updated distribution packages. However, possible security holes in application software will stay unpatched.

Kernel fixes, especially vulnerabilities, are usually in the repositories within 24 hours.

I recommend you have a look at Gentoo if you need full control over the versions of software installed on your computer.

Re:But is disk IO fixed on amd64?

[cerberusss]

Your post got a -1, troll. And that's because every damn distro under the sun has the option to upgrade your kernel WITHOUT upgrading the entire distro.

Re:But is disk IO fixed on amd64?

[plague3106]

You just restated my position. From a systems administrator standpoint, that's a crumby way to get updates to the core OS. The change in stable vs. unstable branch only makes this problem worse, because now an admin isn't sure if the newest kernel has unstable features.

Re:But is disk IO fixed on amd64?

[plague3106]

You still have to wait for the distro to package said changes.

When I used Linux, the Kopete package was far behind, even though I needed the newest version because of protocol changes. The fact is that it takes quite a bit of time for distros to actually build the package to update the kernel. Which was the point of my post.

Re:But is disk IO fixed on amd64?

[cerberusss]

I see what you mean, however I think it's not fair to compare the packaging of an IM app to the kernel. If I'd venture to guess why anyone would not be happy with a vendor-supplied kernel, then it would be either of the following cases:

• Security risks, in which case most vendors are supplying an update
• Bugs, in which case most vendors are supplying an update
• New hardware, in which case a) hardware vendor supplies binary module or b) vendor supplies kernel source to compile a module against

Re:But is disk IO fixed on amd64?

[plague3106]

You're right; the kernel is much, much more difficult to package and test. Its not that the vendors don't provide updates, its the huge lag time between when the fix is available from kernel.org and the various distros.

Re:But is disk IO fixed on amd64?

[cerberusss]

You say it's huge, but I'm not so certain on that. Can you name specific cases where vendors took a long time for kernel issues that should've been fixed quickly by all accounts?

On a related point, I've realized in the past that distro kernels took over the burden of reading security mailing lists. However, we can assume there is some testing involved which is added to your own testing before applying patches/upgrades to your boxes. So that's what you gain.

Now you can say that this doesn't really add something, and I agree that's a question of opinion.

BTW I have to say I appreciate the good discussion.

YOU are the troll

[Aldric]

Linus has repeatedly stated that his code will not be converted to GPLv3. You are either grossly misinformed, or on someone's payroll. If so, they are not getting their money's worth.

Re:GPL v3

[Anonymous Coward]

No, it's all true. See the Free Software Foundation website (http://www.fsf.org/) for more info. Grandparent was *not* randomly generated. Parent is flamebait. Please mod down.

Not even a direct download link!

[Anonymous Coward]

And there isn't even a direct download link the full file in question...

Ummm, I guess now is the opportune time to wish the kernel.org sysops some good luck?

Welcome to slashdot

[sharperguy]

The best site out there for only letting you see a small portion of news on other websites, because the site goes down as soon as anything is posted about it.

Re:Welcome to slashdot

[Threni]

> The best site out there for only letting you see a small portion of news on other websites, because the site goes down as soon as
> anything is posted about it.

Clue for the new/clueless - check out the FAQ, under "Slashdot effect".

Re:Welcome to slashdot

[Anonymous Coward]

haha why are you even here dickface touch my nigger cock oops meant to post anon

Re:question on the wireless: easy answer

[the Hewster]

Anyways, I was thinking of adding one of these USB wireless accessories.. could anybody here recommend one that has a good track record of working in linux ?

anything from ZyDAS or Ralink should have good (and ever improving) fully supported, GPL drivers.

Re:question on the wireless

[Anonymous Coward]

dude go back to digg

Slashdotted, use the cache:

[evanjfraser]

http://kernelnewbies.org.nyud.net:8090/Linux_2_6_2 2#head-650cd139886ede5053ce6b7e1dd080b5378cc521

Re:GPL v3

[Anonymous Coward]

Some other possibly unnoticed effects of the GPLv3 include:
- You can't use a CPU of the same manufacturer that has previously executed GPLv3 code in the same room as a computer running a Microsoft operating system. If you have exhausted all the alternatives and you still need to run your GPLv3-infected hardware in the same room, you can negate this by drawing a chalk circle around the machines running the MS software and sprinkling a ground-up printed copy of the GPLv3 over and around them. This is all standard as per Section 5.
- In the case the Richard Stallman's or any of his buddies' computer blows up (for any reason - read the license for full details), he's allowed to walk into your house and take your computer right off your desk and keep it, even if it has never run GPLv3 code!
- If left unattended, disks containing copies of the GPLv3 can become corrupted and mutate into GPVv3 (General Public Virus version 3), which will assimilate all carbon and silicon-based matter with in a 3 mile radius into a demonic, electronic, GPLv3 spreading zombie ox (or it might be a buffalo - that part is unclear).

This is why we should all boycott GPLv3. It is just too evil and virusy.

Wow; Informative?

[WindBourne]

The fact that you were modded up informative really shows that somebody is out here doing a a REAL FUD jobber. Few here, would say that if the kernel did switch to GPL3, that it would not even have a mention in the posting. That means that the modders are deliberate, not just ignorant. Considering that they are modding, shows that most of the time, they do not step off the deep end. That pretty much means that several ppl (30% informative), are most likely on a payroll.

Re:Wow; Informative?

[neltana]

Never ascribe to FUD what can be explained by sheer stupidity.

I think the professional FUDers are a little more subtle than this. They always keep enough truth in their posts to allow for reasonable doubt...as opposed to the parent.

n00b

[ddvlad]

I don't understand 70% of the changes listed and don't care about/don't use the rest of them. I know, I know... I must be new here. *sigh*

Re:n00b

[Anonymous Coward]

I don't understand 70% of the changes listed and don't care about/don't use the rest of them. I know, I know... I must be new here. *sigh*

Not sure why that is modded Insightful and just above that is another user asking which usb device would be best to buy for a linux box, but that is modded "off-topic." I remember when slashdot was about news for geeks and sharing information about geeky things for linux/bsd/etc.. Now it seems like its just about modding up snarky comments and crap articles about george bush. Sad turn its taken over the last few years.

Re:n00b

[niceone]

You just made me realise that I don't even know what kernel I'm running. I think I should just delete myself right now.

(turns out it is only 2.6.17)

Re:n00b

[fbjon]

Slashdot has always been turning for the worse. In fact, it never was any better in the first place.

Re:n00b

[Yetihehe]

If it was always turning for worse, it means somewhere in the past it was better than now. Your post is illogical, you will be assimilated.

Re:n00b

[HAKdragon]

Well, how about "Slashot, going down hill since 1997" ?

Re:n00b

[dpilot]

Just because you don't understand them or know that you use them doesn't mean that you really don't use or benefit from them.

Do you know and understand all of the technology in your car? your cell phone?

Re:n00b

[SEE]

Well, how about "Slashot, going down hill since 1997" ? Sounds about right.

Goto considered harmful?

[random0xff]

So I have never ever checked source code from Linux, and I don't know C or C++, but I decided to look at some changes. The first code I see has a goto in it. I always thought goto was considered harmful?

http://git.kernel.org/?p=linux/kernel/git/torvalds /linux-2.6.git;a=blobdiff;f=fs/utimes.c;h=b3c88952 465fa28cce7e0bb213fceaf59873fdf9;hp=480f7c8c29da13 ee10941f5cf5e560faffbde0a6;hb=1e5de2837c166535f9bb 4232bfe97ea1f9fc7a1c;hpb=4e99325b462ba180757685826 21af74a6b79d2a5

Re:Goto considered harmful?

[mrjb]

Off topic, but the point of not using goto is that program structure may suffer because of it (if you've read mr. Dijkstra's paper you would know this- the result was the whole 'structured programming' movement). As long as one is careful about program structure, however, using goto is no problem.

To beginning and average programmers, 'do not use goto' is the best advice to avoid problems.

But kernel hackers are hardly beginning or average programmers. They know very well when they can use goto without problems, and when to avoid it. When used properly, goto will result in better performing, easier to maintain, more elegant, easier to read code.

Re:Goto considered harmful?

[Don_dumb]

Whoops, forgot to delete that line of code

Re:Goto considered harmful?

[Cyberax]

See http://kerneltrap.org/node/553/2131 for explanation. In short, Linus has good reasons to use goto.

Re:Goto considered harmful?

[vadim_t]

IMO, goto has been demonized a bit too much.

Yeah, too much of it results in spaghetti code.

But used well, it can compensate for the lack of some things in C. For example, exiting nested loops. In Perl you can say "last NAME", where NAME is the name you gave to the loop, and exit from the outer loop directly.

In C, if you avoid goto what results is a check in every loop to determine whether the inner loop decided that we've got to bail out. This is much uglier than just using goto in the first place, and more error prone too.

Using goto is also handy for error handling: When you're allocating memory, goto allows jumping to the right point in the cleanup process, instead of duplicating bits of code everywhere.

It's my understanding that in kernel programming goto also has advantages in terms of speed over other alternatives.

That's not to say we should use everywhere. But IMO, what to use should be decided on the basis of what is the cleanest and less error prone option -- If goto results in cleaner code, then use it, if it doesn't then don't.

Re:Goto considered harmful?

[Ruie]

The first code I see has a goto in it. I always thought goto was considered harmful?

In a nutshell, yes. But there is an important exception - goto's are ok when you jump down in the code (similar to a break in the loop), usually to a piece that frees allocated storage and exits function. In the code you cite, dput_and_out commits information and exits the function. In a way it is kinda a replacement for try {} catch {}, but with multiple try {} clauses.

Re:Goto considered harmful?

[Velaki]

When thinking about goto, first consider if you're performing a local jump or a non-local jump.

If you're using it for non-local return from inside nested loops and function across compilation units (read: files), why not use setjmp() and longjmp(), especially if you want to unwind the stack?

Mind you, you should keep careful track of memory allocation/deallocation functions when using this kind of chaotic/advanced program flow control, since you might malloc() before the setjmp(), but free() after it, but before the longjmp().

Wanna see nifty goto use? Look at the scanner code generated by lex.

Re:Goto considered harmful?

[Suzuran]

Remember that the kernel is C, not C++. The goto here is safe. The deal with GOTO was that it was not supposed to be used to jump from one function to another or to replace functions. (C will not allow you to do this.) That was the point of the "go to considered harmful" paper - That explicit jumps would cause people to avoid writing properly structured code. Inside a function a go-to is entirely legal and sometimes allows you to save clocks by skipping things you don't need. In kernel code, saving clocks is entirely worth it, since your function may possibly be re-entered at a high rate, and your code blocks all other code in the system (you're the kernel). In an application, it's less worth it and the goto is probably unnecessary.

Personally I use whatever the language gives me wherever I can to make things as computationally short as possible. Sacrificing performance for programmer comfort does not make sense. If the code looks ugly, but it works (and works fast!), that's all it needs to do. For every one programmer you have thousands of users, and the users don't care if the source is pretty or not.

Re:Goto considered harmful?

[T.E.D.]

Yeah, unrestricted use of goto's is generally considered a Bad Thing. However, there are two known situations where they actually can improve readability of a program:

• Implementing state machines.

  State machines have more or less entirely unstructured control to start with. The goto is a natural expression of this. You can avoid the dreaded "goto" in this situation by using a switch statement in a loop, with the cases representing each state. However, this is slower than the goto, and really no easier to read. For an example of this use of goto, see the code generated by lex.

• Simulating exceptions in languages that don't support them directly.

  Handling exceptional conditions inline can get quite ugly, and distracts the reader from the code representing the normal execution flow. It can also case a lot of duplicated code when there are several "exceptions" that need to be handled the same way. Instead, goto's can be used to redirect control to a separate "exception handler". The kernel code you linked appears to be an example of this kind of goto.

Re:Goto considered harmful?

[gowen]

See also "Structured programming with go to statements" by Don Knuth. He makes many of the same points that you do. IMGO goto's are the only sensible solution to a switch based on many ordered criteria. Say:
if(criterion1||criterion3){
    do_something();
    goto end_of_cases;
}

if(criterion2){
      do_something_else;
      goto end_of_cases;
}

if(criterion4){
      do something_else again();
      goto end_of_cases;
} /* and so-on */

end_of_cases:

Now you could do that with a load of if ... else if ... else if ... statements, but I don't think the code would be clearer, or less bug prone.

Re:Goto considered harmful?

[mypalmike]

Your cases are mutually exclusive. The following is indeed clearer, shorter, and less bug prone:


if(criterion1||criterion3){
        do_something();
} else if(criterion2){
        do_something_else;
} else if(criterion4){
        do something_else again();
} /* and so-on */

Re:Goto considered harmful?

[Anonymous Coward]

O.K. Now add multiple failure conditions which all require different levels of cleanup handling. That's pretty much most functions in a kernel. Which is why you use goto more: it's actually clearer and reduces code duplication, making it safer.

Re:Goto considered harmful?

[setagllib]

I think that even though GOTO itself is not necessarily such a bad thing, its current use in C is more of a hack now because C lacks some otherwise common *structured* constructs such as try..catch..finally. But my bigger problem with GOTO is that it's one of those things which completely and utterly destroys the ability to represent a program as a tree structure for possible branches, which keeps us even further from functional-like purity in C code.

GOTO is very rarely used in C++ where the pattern of relying on safe stack destructors (as a sort of 'finally') is wide-spread and well understood. It's downright forbidden in Java, which has solid garbage collection and an explicit 'finally', and therefore very little need for a specific GOTO. These features are much easier to reason about and understand than a GOTO C program which is basically just a self-traversing jump table.

Re:Goto considered harmful?

[gowen]

shorter perhaps. I don't see why it would be less bug prone.
And I do think the structure is less easy to parse, and less accurately reflects the logic and structure of the algorithm. I know flow charts are deeply unfashionable, but sometimes they capture exactly what you mean.

Different strokes for different folks.

Re:Goto considered harmful?

[sjames]

Edsger Dijkstra thought so and Niklaus Wirth is a true believer, I'm not so sure. The unrestrained use of GOTO in fortran and BASIC is certainly very harmful and needs to go away, ESPECIALLY in BASIC where you can (but shouldn't) GOTO from one subroutine to another.

On the other hand, well considered use of goto is quite another mater. The most common GOOD use of goto is as a way to unwind your state in case of an error. This works quite well in a function that must acquire and release several resources in a naturally nested manner. In that case it's quite natural to release the resources one after the other in order at the end of the function. In that case, the cleanest way to write the code is to have error conditions goto the appropriate nesting level at the end. The result CAN be written as nested if statements, but who wants the meat of the function indented 5 levels with multiple repeated compound conditionals in a while loop?

When goto is TOO pedantically avoided, the program logic can become so contorted to fit that it actually becomes unreadable. It can get especially nasty when the same sort of error handling may be required in several places. That leads to duplicated error handling code. Eventually, one or more cases of that code are missed during an update and you end up with an inconsistant mess.

It *IS* good to think very carefully when tempted to use goto, but it's also worth considering that it MIGHT prove to be the best answer for a particular problem.

In the example you point to, the if statements would get fairly contorted to avoid goto AND not duplicate code (cut 'n paste error handling is very harmful).

Students probably should be smacked for using goto since they probably don't have enough experiance to use them tastefully but never say never. Moderation is a good thing as long as you don't over-do it.

Re:Goto considered harmful?

[mypalmike]

shorter perhaps. I don't see why it would be less bug prone.

Come on now. Maintaining blocks + labels + gotos is clearly more error prone than just maintaining blocks.

And I do think the structure is less easy to parse, and less accurately reflects the logic and structure of the algorithm. I know flow charts are deeply unfashionable, but sometimes they capture exactly what you mean.

The multiple "else if" block is an extremely common idiom that an experienced programmer recognizes immediately. It exactly reflects the logic and structure of an "arbitrary switch". Seriously, you've never seen this before?

Re:Goto considered harmful?

[mypalmike]

O.K. Now add multiple failure conditions which all require different levels of cleanup handling. That's pretty much most functions in a kernel. Which is why you use goto more: it's actually clearer and reduces code duplication, making it safer.

If you need to break out of the block, fine: add a goto. I'm not claiming that gotos are useless. They're just not called for in this case.

Honestly, if C had exception handling, there would be almost no need for gotos in a kernel.

Re:Goto considered harmful?

[bmk67]

... The use of Fortran and BASIC is certainly very harmful ...

FYP

In all seriousness, the unrestrained use of goto by a novice is much like using a hammer to drive wood screws. It's the wrong tool for the task, and it yields poor results. On the other hand, the master carpenter not only knows to use a screwdriver, he also knows exactly which screwdriver of the dozens in his toolbelt is the correct tool for the job.

It's much the same in C programming - as another poster stated, "continue" and "break" (as well as "if..else") are equivalent to special-purpose goto's. The explicit "goto" is simply more flexible, and when used appropriately, it is not harmful. I can't recall using a goto more than one or two times in my career (outside of BASIC), and it was always for readability/optimization.

Though I haven't touched BASIC in decades (my experience was with AppleSoft BASIC, Commodore BASIC, BASICA and GW-BASIC), I do recall that it was quite impossible to write any kind of non-trivial elegant code in BASIC at that time. I do realize that BASIC has evolved into more structured forms. You can't polish a turd, but I digress.

Dijkstra certainly thought goto was harmful, and I'll not speak ill of the dead. As you say, Wirth is a true believer, a fanatic. At the time when Wirth was developing Pascal, he had a point - the unrestrained use of goto in the BASIC of his day, WAS harmful. For a time around 1982-1985 I drank the kool-aid as well, and embraced Pascal until I realized that Pascal itself should be considered harmful. ;-) Modula/2 was only moderately better. We used Pascal because we had no choice - and I abandoned the whole sorry mess of Wirth family languages and never looked back. Suffice it to say that Wirth's opinions on goto hold no weight with me.

Re:Goto considered harmful?

[sjames]

It sounds like we have similar experiances in the same timeframe. I used BASIC way back when because it was the usual thing to do on Apple][ and C64. A bit of GW-BASIC thrown in as I got used to the PC. My first Pascal exposure was UCSD for the Apple][. It was a nice learning experiance, but it seemed like it wanted to make me jump through hoops and do it's bidding when I was supposed to be in charge.

Once I got my hands on a C compiler I never looked back.

To be fair to Dijkstra, the goto he was talking about was of the BASIC and Fortran V variety and they are indeed a mess. Wirth's response is not unlike replacing kitchen knives with safety scissors becaause some people manage to cut themselves.

I use goto more frequently, but only in firmware and kernel code. I suppose that's due to the larger complexity of error states and the careful cleanup that must follow.

Re:Goto considered harmful?

[gowen]

Sure, I've seen it a million times. But that doesn't mean its the best. It's certainly elegant if there are 3 or 4 or 5 criteria. But 20 or 30?

I'll take the goto, seriously. I'd certainly recommend using them sparingly, and never, ever use them to jump backwards. In well structured code, there's no more cost in maintaining an occasional label than checking all those braces match where you think they do.

In a subroutine would you really prefer
if(criterion1){
    do_something;
} else if(criterion2) {
    do_something_else();
} else if(criterion3) {
    etc...
}
return;

instead of
if(criterion1){
    do_something();
    return;
}
if(criterion2){
    do_something_else();
    return;
}
if(criterion3){
    etc...
}

To an experienced programmer they're the same. To an inexperienced/non-programmer, the latter is evidently clearer. Understanding the former code requires the knowledge that the second else only get checked if both the first two if()s are false. That's fairly basic, but it's not clear without that little extra knowledge.

Re:Goto considered harmful?

[mypalmike]

The (if.. else if.. else if..) idiom is a "generalized switch". When I first encountered it, I recall being confused a bit, so your point is a fair one. I think the expectation is that the elses should somehow create a nested structure. Yet the code does not reflect a nesting in its layout. If C had some sort of generalized switch syntax like


genswitch
{
      case (cond1)
      {
            firstthing();
      }
      case (cond2)
      {
            some = other + stuff;
      } .. etc ..
}
... would you agree that it's better than goto? If so, then it's really a minor question of syntax. A novice programmer might be confused by the (if..else if..else if) syntax, but there are lots of much harder problems in programming than picking up this idiom.

As for the multiple returns versus multiple "else if's", I still prefer multiple "else if's". Being familiar with the idiom, I think it's just as clear. (And with any decent compiler, it will compile to the same binary, so you wouldn't get the minor speed gains from reducing the number of jumps.) The benefit of multiple "else if's" is again, maintainability. Many people, myself included, consider having a single return statement within a function to be a best practice. It's not a rule I live by, but I rarely find that multiple points of return are necessary for flow clarity nor speed (though, in those cases, I will use them). This enforces the idea that structure defines flow, a core concept in structured programming. It makes for easier static code analysis, which helps both compiler code optimization and with programmers tracking down logic/flow-related bugs. Of course, this practice is a lot easier to follow in a language that has exception handling, so you don't have to jump through hoops to signal error conditions.

Re:Goto considered harmful?

[gowen]

... would you agree that it's better than goto?

Definitely. Abso-damn-lutely. That language syntax expresses the concept beautifully. Now, do you want fallthrough?

Re:Goto considered harmful?

[mypalmike]

Now, do you want fallthrough?

I'm not sure if you're being sarcastic. :) No, I don't want fallthrough. Depending on the situation, fallthrough is trivially rewritten by making the downstream case blocks into functions, or using non-exclusive ifs. An example of the former:

switch (foo ) {
case 1:
  doA();
 
// FALL THROUGH
case 2:
  x = ( y << 2 ) + 1;
  doB(x);
  break;
 
case 3:
  e = m * c * c;
  break;
}

is rewritten:

int transmogrify( int y ) {
  int x;
  x = ( y << 2 ) + 1;
  doB(x);
  return x;
}
 
switch (foo ) {
case 1:
  doA();
  x = transmogrify(y);
  break;
 
case 2:
  x = transmogrify(y);
  break;
 
case 3:
  e = m * c * c;
  break;
}

Linux 3.0.0

[Colin Smith]

Ok. You have a major release, it's permission to break all backwards compatibility, to completely change the face of computing.

Given the hardware around. What features should Linux 3.0.0 have?

Re:Linux 3.0.0

[Anonymous Coward]

Ha ha ha. Those days are over, baby. Linux is now about legacy and keeping the corporate customers happy. You'll have to wait till the next wonderboy with a funny name dreams up a new, groundbreaking OS. Actually, I'm not sure that there was anything groundbreaking about Linux as an OS, but I suppose that's beside the point, or is it?

Re:Linux 3.0.0

[backwardMechanic]

iPhone support?

Re:Linux 3.0.0

[MichaelSmith]

Given the hardware around. What features should Linux 3.0.0 have?

• The ability to scale from supercomputers, mainframes to handhelds, without recompilation
• Transparent clustering. Run this process somewhere else with as much or as little user control is a required
• Fine grained security. Maybe something which lets you build a userland which can't be exploited in any way shape or form
• Built in support for virtual machines. Something like java in the kernel
• Better APIs for kernel modules. Being able to run some modules in a real sandbox

Re:Linux 3.0.0

[LuckyStarr]

Easy. I'd like it to have these features of course.

Though they gradually sneak into Linux anyway. So no big deal.

Re:Linux 3.0.0

[KiloByte]

Here you go.

It's going to be a microkernel using a special message-passing version of Visual Basic.

Re:Linux 3.0.0

[mrogers]

Subusers: ordinary users should be able to create 'subusers' with subsets of their privileges. That would make it easy for ordinary users to run applications in sandboxes.

For example, I should be able to create a www subuser that has access to my bookmarks and cache, but can only access other parts of the filesystem when I explicitly authorise it. (Authorisation can be seamless: make the file selection dialog into a separate setuid process that runs with my full privileges.)

What kernel changes are needed? The UID field needs to be split into two parts (user ID and subuser ID), and any operation that's allowed for a subuser must also be allowed for that subuser's owner (same user ID, subuser ID == 0). The C library will need to mask out the subuser ID for things like getpwuid. And that's about it. Extra security for users who want it, no extra hassle for users who don't, and no extra hassle for administrators.

Re:Linux 3.0.0

[smittyoneeach]

Subsequent to your port, sure.

Re:Linux 3.0.0

[fbjon]

Subusers: ordinary users should be able to create 'subusers' with subsets of their privileges. That would make it easy for ordinary users to run applications in sandboxes. This sounds great, a hierarchy of users instead of a flat-file society. It couldn't even be that difficult to implement, I would guess?

Re:Linux 3.0.0

[Erik Hensema]

Linux 3.x wouldn't have to be compatible with Linux 2.x (that's the criterium for upping the major version number in the Linux kernel). So, we could have all sorts of exotic incompatible stuff :)

I personally would love to see Posix as a compatibility layer in a much reworked OS with a object-relational filesystem done right. But that won't be done in the next decade or so, so I won't hold my breath ;)

Re:Linux 3.0.0

[b1ufox]

> * The ability to scale from supercomputers, mainframes to handhelds, without recompilation

Thats next to impossible for a modern fairly efficient operating system. Why? Because kernels which run on handhelds , supercomputers and mainframes have different constraints in terms of memory, power management and similar technical terminological stuff :).

> * Transparent clustering. Run this process somewhere else with as much or as little user control is a required

Oh boy!!! this is how SMP kernels work when you run them on a multiprocessor systems.

> * Fine grained security. Maybe something which lets you build a userland which can't be exploited in any way shape or form

lolz ...:D i would mod you funny, but thats idiotic, why should kernel worry about user code at all? BTW if you are so paranoid try SELinux.

> * Built in support for virtual machines. Something like java in the kernel

This is what VMI (Virtual machine Interface) does right now in the kernel along with the KVM(kernel virtual machine) and please do not compare and OS with Java stuff. Java do not deserve to be compared to a highly performing kernel.

> * Better APIs for kernel modules. Being able to run some modules in a real sandbox

BTW whats wrong with current APIs?I do not find anything wrong being a developer.And i bet no user needs API, because they do not even care which kernel it is forget API. Sandbox yes, try Xen or any other virtual machine.But do not try to expect a fault tolerant monolithic kernel just for the sake of weird fantasy[atleast not so soon :)]

Re:Linux 3.0.0

[TheLink]

I'd rather have "sandbox templates".

So that I (and my relatives etc) don't have to set up subusers etc.

Basically when I launch some program I see:
"Program: 'Fun ScreenSaver' requires 'Normal ScreenSaver Install' privileges"

Allow: Yes/No?
Give [Drop down list of sandbox templates] privileges instead.
Checkbox - remember decision for this program.

Then I might choose Yes, and the screensaver will be installed as per a normal screensaver - no extra stuff AND when it is launched, it'll only have screensaver access to the system - very sandboxed.

But if I see:
"Program: 'Fun ScreenSaver' requires 'Full User Install' privileges" with a red background I'd probably click No. Same for 'Full System' privileges.

It's not that easy of course - since you need to define a lot of decent defaults - like a safe, flexible and user friendly way to configure the screensaver. AND the templates have got to work - otherwise everyone will just choose 'Full System' ;).

But I think that is what's needed for "Personal Computing Security for the Masses". Not the crap called Vista UAC.

You might use SELinux (or AppArmor) as building blocks, but they are far from sufficient by themselves.

Re:Linux 3.0.0

[LarsG]

Because kernels which run on handhelds, supercomputers and mainframes have different constraints in terms of memory, power management

Not to mention different CPU families, a kernel compiled for ARM7 isn't going to run on IBM POWER.

Re:Linux 3.0.0

[mhall119]

> * Built in support for virtual machines. Something like java in the kernel

This is what VMI (Virtual machine Interface) does right now in the kernel along with the KVM(kernel virtual machine) and please do not compare and OS with Java stuff. Java do not deserve to be compared to a highly performing kernel. I don't think that's what he was talking about. KVM is used for hardware virtualization, not byte-code execution like the Java VM. That said, I don't understand what having the JVM built into the kernel would accomplish, besides giving slightly improving startup of Java apps and generally forcing the Kernel to consume more memory. It would also give rise to all the known problems of running multiple Java apps within the same VM instance, which is why the standard JVM doesn't do this already. I also don't see why Java can't be compared to an OS kernel, there are several Java-based OS's and specialized processors that run Java byte-code in hardware, so in that setup it's really no different than a kernel written in C.

Re:Linux 3.0.0

[metamatic]

A decent filesystem.

Right now, ReiserFS is unsupported by many distributions because it's legacy "maintenance only" code. JFS is also not supported by many distributions (e.g. Kubuntu), I don't know why. And XFS is problematic. I resorted to using ext3, which is just horrible from a performance point of view.

What I really wish is that we could have ZFS or Reiser4. However, those are unlikely for obvious reasons.

Re:Linux 3.0.0

[mikael]

You don't need to split the UID - just add a subuser ID. Then getpwuid doesn't need to be modified. Add another function getsubuid. But this change would probably have to adopted by many networking protocols as the userid is used sometimes to grant permission.

Although it would be good if an application could be sandboxed simply by having a whitelist/blacklist of directory paths that it could access.

Re:Linux 3.0.0

[Colin Smith]

> * Transparent clustering. Run this process somewhere else with as much or as little user control is a required

Oh boy!!! this is how SMP kernels work when you run them on a multiprocessor systems. But not when you have multiple discrete single CPU systems. Or multiple discrete multiprocessor systems.

Imagine all your machines automatically acted as a single box when they were connected to the LAN. Or other low latency interconnect like Infiniband.

I think the closest thing is Mosix:

http://www.mosix.org/txt_about.html

Then you're on to the network queueing systems like NQS, PBS, Torque, Sun Grid Engine, Condor ...

Re:Linux 3.0.0

[Eunuchswear]

Transparent clustering. Run this process somewhere else with as much or as little user control is a required

http://www.openssi.eu/

Re:Linux 3.0.0

[jZnat]

Realtime support. I don't mean two incompatible patchsets, but an actual effort to make Linux work as a realtime operating system.

Also, I'd like to see more things move to userspace whenever possible. Make Linux more of a hybrid kernel and all that.

And try their damned hardest to try and support those crappy Broadcom wireless chipsets so people can stop complaining about "nonexistant wireless support" in Linux.

Re:Linux 3.0.0

[charlesnw]

Um. You misread his post. He said something LIKE java. Not java. Now I am not sure why one would want a common language runtime (whether that be Java/Parrot/.NET) in the kernel level but maybe I am just weird.

Re:Linux 3.0.0

[jfmiller]

This is more about where I'd like to see computers go in general. Someone has mentioned Kernel Level support for Java, I'd like to add Kernel level support for dynamic languages. I find that Ruby, LUA, and Lisp are becoming more then just script writing languages. With Hardware diversifying rather then simply getting faster, it is time to move the application programmer one more level back from the hardware. I would therefore advocate for any future Linux kernel to Make these paradigms as efficient and standard as possible.

JFMILLER

Re:Linux 3.0.0

[verbatim_verbose]

Actually, one of the well-engineered things about the linux kernel is that it can be enhanced to add new architectures like this without needing to be rewritten:

2.6.19 added the Atmel AVR32 architecture
2.6.20 added support for the PS3 and additional ARM processors (Is the iPhone an ARM?)
2.6.21 added support for 2 new architectures, PA SEMI PWRficient and celleb (Toshiba)
2.6.22 added the Blackfin architecture

I know it was meant as a joke, but don't be surprised if in a couple of months there's a 2.6.23/24 with iPhone support. Or heck, maybe it will run on it already, I dunno.

Re:Linux 3.0.0

[diego.viola]

I want a hybrid kernel, with the performance of a monolithic kernel and the flexibility of a micro-kernel.

Re:Linux 3.0.0

[diego.viola]

GPLv3 would be nice to see in Linux 3.0, and also a merge with the Hurd kernel

Re:Linux 3.0.0

[MichaelSmith]

I was thinking in terms of being able to run binaries without any risk at all. The java applet sandbox is pretty good for that, or at least it was in the past.

Being able to load a driver for a new device and being absolutely sure that it can only bring itself down, not corrupt anything in the kernel.

Installing software should be as safe as installing a new appliance in your house. It only does one thing. It can sneak out the front door with your CD collection in ther middle of the night.

Software in general, and kernel modules in particular, can't be trusted in that way, but I don't see why they shouldn't be. I was thinking in terms of a bytecode interpreter available to the kernel with a builtin sandbox and precicely defined APIs so that you could run risky software.

Re:Linux 3.0.0

[backwardMechanic]

Real realtime is quite an odd requirement - not many of us have real use for it, but it puts some pretty heavy requirements on the kernel. Why do you want it?

More thing in userspace, I'll sign up to that. I think you're probably re-inventing the microkernel, but that's no bad thing.

You're not a QNX fan by any chance?

Re:Linux 3.0.0

[diego.viola]

http://lkml.org/lkml/2005/3/2/247 - 2.6.: still a stable kernel, but accept bigger changes leading up to it (timeframe: a month or two). - 2..x: aim for big changes that may destabilize the kernel for several releases (timeframe: a year or two) - .x.x: Linus went crazy, broke absolutely _everything_, and rewrote the kernel to be a microkernel using a special message-passing version of Visual Basic. (timeframe: "we expect that he will be released from the mental institution in a decade or two"). Linux 3.0.0 is going to be a micro-kernel or hybrid probably

Re:Linux 3.0.0

[pbaer]

Proper ZFS support.

Re:Linux 3.0.0

[b1ufox]

>KVM is used for hardware virtualization

Yes it is.But question was if i understood it correctly, built in support for virtualization.And KVM does help a hypervisor if it is going to use hardware virtualization like AMD's SVM or Intel's VT-x technique.

May be i am misunderstanding something? but i would like to be corrected verbatim.

Re:Linux 3.0.0

[sjames]

I'm not so sure I want java in userspace, much less in the kernel!

Seriously, you don't really want anything that heavy in the kernel. Far better is to boil all of the protection down to a small set of helpers that can go into the kernel to better cooperate with a userspace sandbox.

Running kernel modules in a sandbox is a conflict in terms! In Linux, there is a hard dividing line between userspace with pagable virtual memory, access restrictions etc and kernelspace where everything runs in a common memory space, cannot be paged, and has no access restrictions at all. Again, seperate what you want in a sandbox from the essential system access in the kernel.

A kernel module to deal with virtual to physical address mapping and to route interrupts to userspace would go a long way without introducing the massive overhead of a sandbox in the kernel.

The kernel IS moving stedily to finer graind security. There's SELinux is you can stomach the d ense inter-dependant hairball that it's configuration is. Otherwise, ACLs on files have been available for some time even though most distros don't use them. Root has been split into 32 different capabilities in the kernel for a long time. It's all bundled into root vs. not root in a single function simply because Posix capabilities turned out to be poorly designed. The nail in the coffin however was that at the time there was no support for extended attributes, so capabilities were embedded into the ELF header of binaries (YUCK!!!). I have a patchset that allows for individual capabilities rather than suid root on binaries, but it's not quite ready for release. (watch this space :-)

Re:Linux 3.0.0

[renoX]

>Built in support for virtual machines. Something like java in the kernel

I don't think that something like Java should be in the kernel, but there could surely be better communications with the GC used in Java (and other language) and with the kernel memory manager, this way the GC could better use the memory: increasing the heap used in low memory pressure situation and reducing memory used by the GC when the memory pressure increase.

There have been some research on this topic, and now that Java is GPL, maybe this will happen.

Re:Linux 3.0.0

[diego.viola]

it would be cool also to see Plan 9 features in the Linux kernel and GNU tools in general

Re:GPL v3

[Anonymous Coward]

Good lord! Perhaps if the major media conglomerates cooperate with Microsoft and SCO, they can create a way to save us from this menace!

no zfs. no gpl 3

[Anonymous Coward]

lame.

Re:question on the wireless

[Technician]

Anyways, I was thinking of adding one of these USB wireless accessories.. could anybody here recommend one that has a good track record of working in linux ?

I would recommend using one of the PCMCIA cards instead. Find one that uses the Anthros chipset. I picked up a D-LINK one that was recognised by Dapper Drake. I didn't need to install NDIS Wrapper of Network Manager. I don't remember the model number of the card, but setting it up was as easy as setting it up in Windows except I didn't need to use the setup CD that came with it. Dapper recognised it as an Unknown Wireless. Properties showed it has an Anthros chipset made by D-Link. From there I gave it a static IP on my LAN and plugged in the WEP key after picking my SSID from a list. I added some DNS listings and put in the gateway address of my router and I was online. There have been some difficulty with configuring many of the USB cards. Check the forums and purchase carefully.

New wireless stack? Firewire stack? WTF?

[brunes69]

Whatever happened to the releases being STABLE??

Am I the only one who cringes when someone says they have released a totally new wireless stack in a point release? Does everyone forget the VM switch fiasco already?

I really really regret the switchover to this whole new "accelerated" kernel dev. phase. Since this is just a point release, but has a totally new wireless stack, how do I know that my next OS update won't just break my whole networking setup? Argh.

Re:New wireless stack? Firewire stack? WTF?

[Viol8]

Well said. Its about damn time that they spun off 2.7 and started to fix all the bugs in 2.6. This whole 2.6 series has been one horrible mess after another with new features shoe horned in or current ones radically updated with no thought to people using 2.6 on production systems.

Re:New wireless stack? Firewire stack? WTF?

[smittyoneeach]

Your arguably insightful post was kinda flattend in advance by GKH at OLS:
http://www.linux.com/feature/115767

Re:New wireless stack? Firewire stack? WTF?

[shani]

Run 2.6.16 and quit complaining.

Or, just use whatever your favorite distribution publishes for you.

Re:New wireless stack? Firewire stack? WTF?

[blowdart]

Whatever happened to the releases being STABLE??

Come on, in order to win the desktop Linux needs to be more like windows. More frequent service packs, errr, kernel upgrades will help.

Re:New wireless stack? Firewire stack? WTF?

[oliverthered]

now all we need is hardware vendors to notice this and start releasing drivers for the 2.6.16 kernel knowing that the api/abi isn't going to change all the time

Re:New wireless stack? Firewire stack? WTF?

[Anonymous Coward]

That's because there is no 2.7 planned.

If you go digging around for the stories at the launch of 2.6, you'll find it mentioned that 2.6 is both the stable and development branch. New features are introduced in 2.6.x releases; bugfixes and other tuneups are in the 2.6.x.y releases.

Use the 2.6.x.y releases if you want stability, but try not to tear your hair out as 2.6.x.y+1 comes out a few days to a few hours after 2.6.x.y was released.

While I understand why they dropped the even/odd thing (was found confusing by some and they weren't getting enough testers), moving to the current scheme isn't what I'd call an improvement.

Re:New wireless stack? Firewire stack? WTF?

[cerberusss]

I've seen some insightful posts from you so I'm not assuming you're trolling. But this has been discussed to death. There are perfect kernels in the 2.6 series and they're created by your vendor. That's what Linus wants and that's how it goes.

Re:New wireless stack? Firewire stack? WTF?

[s2jcpete]

Did you read the article? It is not enabled by default, at least till all the drivers get ported to it.

Re:New wireless stack? Firewire stack? WTF?

[Anonymous Coward]

Because new wireless stack is needed due to the current stuff not really working all that well. Everyone who has struggled getting wireless to work on Linux (and that's a lot of people) knows that.

Re:New wireless stack? Firewire stack? WTF?

[baadger]

Both the 'old' firewire and the 'old' wireless frameworks and their corresponding drivers are still in the tree. If you don't want to use these new and relatively untested stacks then simply don't use them in your 2.6.22 config.

Re:New wireless stack? Firewire stack? WTF?

[tolonuga]

2-3 weeks of development where changes go in, 9-10 weeks of testing and bug fixing.
that is stable. you can't get a .0 release more stable than it is after 9-10 weeks of testing.
if a 3 month cycle for new releases is not good enough, you have these options:
  * use 2.6.16.* it has been maintained for about 18 months and still is
  * use the kernel of your linux distribution. they typically maintain it for about 1-3 years, longer for the enterprise edition.

also remember that you don't need to switch to the latest version, no one is forcing you.
a .0 release is only as good as the developer with their resources for testing can get it.
the status is called "banana green" and it now need time with real users to mature.

as for the features you mentioned, they are additions, not replacement. having two implementations of something next to each other
behind the same generic interface allows early testing and smooth migration. it doesn't harm the existing implementation or makes
it less stable. simply not turn them on and you won't run into problems.

Re:New wireless stack? Firewire stack? WTF?

[goarilla]

that's maybe how linus wants it but ffs
many of use slackware users use home brew vanilla kernels
on another note i really don't have any problems with the 2.6.x line of kernels
they perform excellent for me, the only that annoys me is the huge list op options
which makes it sometimes very cumbersome to build the right kernel

Re:New wireless stack? Firewire stack? WTF?

[Viol8]

Oh please , perfect kernels? What planet are you on? Who modded this rubbish insightful?

Re:New wireless stack? Firewire stack? WTF?

[cerberusss]

*Laughs* alright, they're not perfect. However, my point stays: it's no use rehashing the same old discussion about 2.6 and 2.7, because it's all hypothetical.

Re:New wireless stack? Firewire stack? WTF?

[Anonymous Coward]

Like at least a few, I'm aware that that's what Linus wants. More power to him--hopefully someday in the future this accelerated schedule will lead to a Linux machine that actually functions as well as Windows on modern hardware. In the meantime, it's causing an awful lot of pain and anguish.

Myself, I need my servers to be stable and a release schedule that I can depend on, so the 2.6.x series of kernels was what finally pushed me completely to BSD for my UNIX needs.

Re:New wireless stack? Firewire stack? WTF?

[dpilot]

Seems to me that what we need is a hunk'a'code based on things like lspci that checks out your existing hardware, views your current partitions, perhaps asks you a *few* questions, and spits out an initial kernel config. At that point, you can either build a kernel that way, or use that as a starting point to tweak the config, and then build.

I know, in my spare time...

Re:New wireless stack? Firewire stack? WTF?

[cerberusss]

Myself, I need my servers to be stable and a release schedule that I can depend on,

But why doesn't for instance Debian provide this for you?

Re:New wireless stack? Firewire stack? WTF?

[iabervon]

The new wireless stack has been in development for ages now, testing for half a year, and it's just now being included at all. This is a point release simply because they didn't break wireless in the kernel years ago when they decided to write a new stack, leaving wireless broken for years and years before eventually reaching a point where it only failed to work for people who weren't bothering to complain any more, at which point the version number could change and it would be called "stable", despite the fact that it wouldn't actually work in general.

Including this new wireless stack won't break anything for anybody, because the old wireless stack is still there, and there are no included drivers at all that use the new one.

Re:New wireless stack? Firewire stack? WTF?

[WilliamSChips]

many of use slackware users use home brew vanilla kernels Easy solution to that: Don't use Slackware. That piece of shit needs to die already.

Re:New wireless stack? Firewire stack? WTF?

[Anonymous Coward]

>Myself, I need my servers to be stable and a release schedule that I can depend on,

But why doesn't for instance Debian provide this for you?

Perhaps you missed the part about "... release schedule that I can depend on".

I don't know how great BSD is at meeting planned release schedules, but Debian's release schedule is an 'earliest possible date' kind of thing.

Re:New wireless stack? Firewire stack? WTF?

[GreyWolf3000]

The new stack doesn't *replace* the old one, it sits alongside it. Soon, the existing stack (actually, I believe there are two) will be marked as 'deprecated.' Eventually, probably years from now, when all the drivers have moved to the new stack(s), the old one(s) will be removed.

Software design principles 101 tells us that you don't remove code unless no other components rely on it, and you don't replace existing code that sucks, you reproduce its functionality with better code that can coexist with the old.

Re:New wireless stack? Firewire stack? WTF?

[Anonymous Coward]

Slackware is the only linux distro I find usable on my servers. Desktop machines are another matter.

Re:New wireless stack? Firewire stack? WTF?

[ichigo 2.0]

Myself, I need my servers to be stable and a release schedule that I can depend on

Then why upgrade your kernel? You should only need to upgrade the programs that expose open ports to the outside world, unless there's something I'm missing? Some kernel improvements might give more performance, but if you're running a server that close to the limit it would probably be better to upgrade the hardware.

Re:New wireless stack? Firewire stack? WTF?

[dragonturtle69]

Dude, Slackware is not a POS. It is for those who really want control over their system, and knowledge. If you want a quick, easy to install and configure system, Slackware may not be for you, at least until you write your own GUI tools

Re:New wireless stack? Firewire stack? WTF?

[WilliamSChips]

The "Control" Slackware gives you is the ability to ruin the system by fscking up dependencies(the other option is to compile from source, in which case you should just use Gentoo). The "knowledge" Slackware gives you isn't that different from the knowledge I already got from Gentoo, except the latter has a better package management program.

Headline does not match the story

[dbIII]

Follow the links above if you really want to see how the above poster is misrepresenting things to embrace a much larger picture - it's clear whoever modded them up did not.

Specific complaints should be stated as such instead of rubbish about it all being broken. The Gentoo thread quoted above is about people discovering that writing to optical drives is horribly slow and puts a lot of load on the CPU in comparison to dealing with hard disks - looking up ATAPI may have been a good move at that point instead of a lot of speculation.

Re:Headline does not match the story

[Anonymous Coward]

Dude, you haven't read the links have you?

http://forums.gentoo.org/viewtopic-t-482731-start- 450.html
"... And of course all along I've been experiencing the slowdowns with the SATA (now back to IDE) disk access mentioned at the beginning of this thread."

http://bugzilla.kernel.org/show_bug.cgi?id=7372
"... The only thing related to libata I can think of is NCQ interacting badly with io scheduler..."
"...Yes, and this means that the problem is getting worse with TCQ/NCQ enabled, but
it is not the root cause."

This issue really is about disk IO performance in general, not specifically CD burning! Please don't make light of what is a very serious problem. It was at a point today where I had a hard time even starting "top" today during some DV video playback. Unacceptable.

Re:Headline does not match the story

[greg1104]

It would be helpful were you to actually read all of the attached links completely instead of seeing some bogus reports in the Gentoo area and dismissing the whole thing based on that subset.

I'd suggest http://bugzilla.kernel.org/show_bug.cgi?id=7372#c1 08 and http://bugzilla.kernel.org/show_bug.cgi?id=7372#c1 12 as the best summary of the kind of problem people are running into. There are no optical devices involved.

Re:Headline does not match the story

[swarsron]

>The Gentoo thread quoted above is about people discovering that writing to optical drives is horribly slow and puts a lot of load on the CPU in comparison to dealing with hard disks

First sentence of the thread:
"Has anyone noticed a slowness or unresponiveness during disk access on a NForce4 Ultra system with a serial ata disk attached to it?"

So no, no optical drives and i have the same problem with my nforce 4/AMD 64 SATA setup here.

Crashing soon a kernel near you...

[backwardMechanic]

To quote from the bottom of the page: [The mm-tree] can crash your machine, eat your data (unlikely but not impossible) or kidnap your family (just because it has never happened it doesn't mean you're safe)

I notice the patches being tested include Reiser 4...suddenly the above warning appears a bit more sinister.

Re:Crashing soon a kernel near you...

[kollywabbles]

Filesystems are overrated. You don't really need one anyway.

Re:Crashing soon a kernel near you...

[soleblaze]

Yeah, but what most people don't realize is that using some of the more experimental features in the kernel (such as raid 6) Caused George Bush to be re-elected.

131 ---help---
132 WARNING: RAID-6 is currently highly experimental. If you
133 use it, there is no guarantee whatsoever that it won't
134 destroy your data, eat your disk drives, insult your mother,
135 or re-appoint George W. Bush.

If there isn't going to be a 3.0 release...

[smittyoneeach]

What is the point of retaining the 2.6?
Why not just call the thing "22"? This has the advantage of putting the kernel in the same version neighborhood as GNU/Emacs.
Oh, wait...being too close to GNU/Emacs's version number might bring development to a crawl.
Never mind.

Re:If there isn't going to be a 3.0 release...

[Aladrin]

Who said there would not be a 3.0 release?

And what's with the need to jump version numbers at the drop of a hat?

And why the need to tell someone else how to name their product, when you don't contribute to it at all?

Re:If there isn't going to be a 3.0 release...

[Anonymous Coward]

Somebody's got a case of the Mondays.
And I'm struggling to get through the learning curve, to contribute one day.
The cliche is "power, performance, ease of use: pick any two".
Linux, without the slightest bit of remorse, opts for the first two.
Not a complaint, an observation. Patience. I'll get there.

Re:no zfs. no gpl 3

[KoldKompress]

Linux has been crafted from so many hands, some of them now dead, GPL3 looks highly unlikely for Linux. That and Linus' dislike of the GPL3.

TCP Illinois congestion control.

[Zombie Ryushu]

This is an implementation of TCP Illinois invented by Shao Liu at University of Illinois. It is a another variant of Reno which adapts the alpha and beta parameters based on RTT. The basic idea is to increase window less rapidly as delay approaches the maximum.

Illinois Congestion control is helpful with network games as that tends to spike my connection.

Re:TCP Illinois congestion control.

[goarilla]

Illinois Congestion control is helpful with network games as that tends to spike my connection.

i don't think so since most network games use UDP and not TCP

R:Wow; ===parent is troll===

[Anonymous Coward]

If you hate the Slashdot moderation system so much, why post comments here?

Mod parent down please

Re:R:Wow; ===parent is troll===

[Anonymous Coward]

Dude, quit asking mods what to do. If you want to affect the mod points, log in, post for a few months without being a fucktard so your karma doesn't go in the shitter, and mod for your self.

2.7.x kernell?

[Oxide]

Are we gonna ever have a 2.7.xx developmental branch? how long are we going to keep adding features and breaking things in the stable branch? why doesn't Linus hand over the 2.6 to another maintainer like he did for 2.4 and begin a developmental branch to try out new stuff?

Re:2.7.x kernell?

[TeknoHog]

We've gone through this over and over. Previous devel branches went too far, taking forever to stabilize in the end, so Linus & co. figured it's better to do more incremental development within the single metastable branch. Really stable releases are up to distro maintainers.

Re:2.7.x kernell?

[ispeters]

Are we gonna ever have a 2.7.xx developmental branch?

Not in the foreseeable future--Linus has decided not to do this. I would have thought you'd heard about this because the decision was made a long time ago and nobody's ever hinted that anyone's mind has changed.

how long are we going to keep adding features and breaking things in the stable branch?

Your question doesn't make sense. 2.6.x is not a "stable branch". You're using old terminology. Linus has decided that 2.6.x is the new development platform. The distros are free to create 2.6.x.y versions that are stable. I would have thought you'd heard about this because the decision was made a long time ago and nobody's ever hinted that anyone's mind has changed.

why doesn't Linus hand over the 2.6 to another maintainer like he did for 2.4 and begin a developmental branch to try out new stuff?

Linus thought he'd give something new a try. Everyone's working together on the current tree and, if anyone's interested (like, say, a distro), they're free to take a 2.6.x edition and make a 2.6.x.y series of stable kernels. I would have thought you'd heard about this because the decision was made a long time ago and nobody's ever hinted that anyone's mind has changed.

Ian

Re:2.7.x kernell?

[Dan Ost]

What did they break?

Unless I missed something, everything they added is an optional replacement to what was already there. Don't use the new stuff if you don't want it.

Re:2.7.x kernell?

[turgid]

Linus thought he'd give something new a try. Everyone's working together on the current tree and, if anyone's interested (like, say, a distro), they're free to take a 2.6.x edition and make a 2.6.x.y series of stable kernels.

The trouble is "everyone" is "working together on the current tree" therefore there is no one available to make a "stable branch" other than the big money players like RedHat and SuSE.

This plays directly into the hands of other big money like IBM, who can now claim that Linux is "less stable than AIX," and Microsoft, who can now say, "see that free stuff isn't as stable as they claim."

Those of us who can't afford $700 for a RedHat license get to use experimental kernels if we want to keep up with new hardware support.

I'm seriously considering going back to Solaris, which is now Free as in Speech.

Re:2.7.x kernell?

[Anonymous Coward]

Those of us who can't afford $700 for a RedHat license get to use experimental kernels if we want to keep up with new hardware support.

Given the number of times they are mentioned, I'm suprised you haven't heard of the free "de-branded" versions of RHEL known as WhiteBox, CentOS etc.
They appear to be exactly what you want i.e. exactly the same stable kernel versions as the corresponding RHEL releases.

Re:question on the wireless

[the Hewster]

Linksys ones tend to work ok.

No, Linksys, like most manufacturers, often change the chipset they use in their wifi cards. So you basically don't know what your buying when you get a Linksys card and it's hit or miss to get it working. When using Linux you need to look for a wifi card with either a ZyDAS or Ralink chipset. If you can't find out what chipset the card is using, don't buy it! Find one where you can tell.

Re:question on the wireless

[TeknoHog]

Check the forums and purchase carefully.

The purchasing part is hard to do when the same model comes with a different chipset each day, depending on constellations and sunspot activity.

Re:question on the wireless

[nowhere.elysium]

Fair enough. The last couple of USB WiFi dongles I used were Linksys, and they were fine. Nonetheless, you're right: they do have a habit of buggering about with the chipset every so often...

Re:question on the wireless

[vtcodger]

*** Anyways, I was thinking of adding one of these USB wireless accessories.. could anybody here recommend one that has a good track record of working in linux ?***

I'd be careful about anything with a Broadcom chip. There is a Broadcom driver for Linux, but it doesn't always work. The alternative is ndiswrapper which can somehow make a Windows driver work under Linux. My experience was that setting up ndiswrapper was not much fun. Not knocking ndiswrapper -- I'm utterly astounded that it works at all

Obligatory comment

[Anonymous Coward]

Yeah, but does it run Linux?
eeeh, strike that.

Re:Obligatory comment

[feedmetrolls]

In Soviet Russia, Beowulf clusters of these imagine you...or something.

Re:Obligatory comment

[lordtoran]

Imagine a Soviet Beowulf cluster of Linux kernels releasing YOU!

Torrent File

[Anonymous Coward]

Torrent File Here

Re:no zfs. no gpl 3

[mhall119]

I know this was probably a troll, but ZFS is available through FUSE.

Re:question on the wireless

[Technician]

The purchasing part is hard to do when the same model comes with a different chipset each day, depending on constellations and sunspot activity.

Either take your laptop in and test drive them (explain it to the salesman, especially if they are on comission.. A fit is a sale.), find a good restocking policy, or spemd little. My D-Link card that worked came from Goodwill. It pays to look.

Re:no zfs. no gpl 3

[SolusSD]

but you can always choose to accept the terms of the gplv3 license for any gplv2 licensed software. there you go. :)

Re:question on the wireless

[Anonymous Coward]

An adult film producer surely knows how to do plug & play.

Re:Stop posting these

[Dan Ost]

Sure, but how many of those 0.001% of the Linux users that this matters to actually read Slashdot? Probably more than you realize.

I, for one, haven't used a distro kernel (discounting LiveCDs) for 4+ years now. I love the discussion on Slashdot whenever a new kernel is released.

Voodoo percentage.

[Anonymous Coward]

Only 13%? I'm disappointed. I had the chickens and the rum all ready to go this weekend when I installed it. I guess I'll just settle for a good Cigar and a splash of rum. The chickens are needed until the percentage hits 20%.

So the RA2500 driver will work in Ubuntu again?

[Anonymous Coward]

New wireless stack, perhaps that also means that Ubuntu gets a working ra2500 driver again? I'm currently sentenced to using the LTS version as later versions don't support my wireless any more. Yes, there are work-arounds but they all require downloading stuff. Not possible when your connection doesn't work. Chicken-and-egg problem.

Re:So the RA2500 driver will work in Ubuntu again?

[Hucko]

download them before upgrading?

Re:question on the wireless

[monkeySauce]

From there I gave it a static IP on my LAN and plugged in the WEP key after picking my SSID from a list.

You sounded like you knew what you were talking about until I got to this point.

Everybody knows WEP is a waste of time. If you really want your wireless to be secure, just wrap the access point in a HEPA filter, but make sure you cover your laptop with the exact same grade of filter, to ensure compatibility. THAT will keep the undesirables out (assuming they are larger than .3 microns).

Re:question on the wireless

[Deliveranc3]

Sorry to be spelling Nazi but I think the parent meant Atheros (confirmed by quick google search).... I have that chipset in my laptop, it has a good reputation because it worked in Dapper but my edgy upgrade broke it and each new kernel requires me to set it up again... bummer.

MOD PARENT UP

[Woy]

While I use and love Linux, i couldn't agree more with you. This bug has been driving me crazy, as i was looking for the cause in userspace, and it coincided with the move to compiz-fusion. The animations of compiz eyecandy make even the slightest system slowdown noticeable so this bug pretty much killed desktop compositing in the affected platforms until it is solved (it runs but its not fluid). And with that we lose a great tool to generate interest in the Linux OS.

PUIS

[Anonymous Coward]

It looks like power-up in standby support was finally added to libata:
http://www.linuxhq.com/kernel/v2.6/22/drivers/ata/ libata-core.c

Finally I'll be able to use staggered spinup for SATA drives on machines that don't support it in hardware. Plus, hdparm -s should no longer be quite as dangerous.

Re:question on the wireless

[MSG]

I presume you mean "Atheros". I recommend not using those cards. Atheros cards do not have Free Software drivers; they're binary-only. They don't handle suspend well, which is kind of a big issue when you're dealing with a laptop. Ralink or Intel cards are a much better bet.

Re:GPL v3

[WilliamSChips]

you can negate this by drawing a chalk circle around the machines running the MS software and sprinkling a ground-up printed copy of the GPLv3 over and around them. This is all standard as per Section 5. So now Microsoft's blaming their system instability on Harry Dresden...

Re:question on the wireless

[piojo]

I have had lots of trouble with ralink (drivers that wouldn't compile, or when they did compile, didn't work). The two chipsets that have worked the best for me were Atheros and Atmel (though Atheros may need some installation of software (madwifi), and both will need firmware, but both just worked on Ubuntu). The card I just bought with the Atheros chipset is a D-link, but like the parent said, they don't always use the same chipsets. People I've talked to seem to think that linksys often works.

In the future, I'll always buy wireless cards at a mortar and brick store, where I can return them if they don't work. It's not worth my time to fuck with drivers that are unsupported.

HASTY MODERATORS

[fnj]

Follow the links above if you really want to see how the above poster is misrepresenting things

No, dbill, it is you who is misrepresenting, and/or evidently not following the links attentively, or with comprehension. As the other respondents have pointed out, the bug has nothing to do with optical drives. It has to do with large hard-disk copies making the entire system unresponsive. It is a very serious bug. You're of course right that it's not all broken, but there is a serious/crippling flaw here showing up in certain classes of system configurations.

Re:no zfs. no gpl 3

[Hatta]

Which is hardly worth mentioning. There's a reason we usually put filesystems in the kernel, performance.

Re:GPL v3

[Anonymous Coward]

I did not notice it was April already.

Re:no zfs. no gpl 3

[Anonymous Coward]

No. 'cause Linus thought he was smarter(*) than those who wrote the GPL, and made sure that there'd be no way for anyone to change the license, not even himself. He deleted the part that says V2 or "a later version" in the code that he wrote (and others followed) without taking the necessary precaution to have other means to switch to a new license or version of a license.

Of course, now linus understands the purpose of "V2 or a later version", but instead of saying he scr*wed up, he just claims that GPLv2 is fine, or says he doesn't like V3.

(*) maybe he is, and made sure that linux would be stuck with a flawed license?

Re:question on the wireless

[Technician]

I thought you were onto something until I realized you might not be running Linux over wireless by this statement;

Everybody knows WEP is a waste of time. If you really want your wireless to be secure, just wrap the access point in a HEPA filter, but make sure you cover your laptop with the exact same grade of filter, to ensure compatibility. THAT will keep the undesirables out (assuming they are larger than .3 microns).

Have you had any luck using WPA on an older distro such as Dapper? I set up to get connected. I live on the end of a road and have brick exterior so signal offsite is wimpy. Not too many wardrivers find me and there are lots of unsecured points nearby so I'm not a high profile target.

It's like being in the jungle with a companion and being attacked by a lion. I don't have to outrun the lion. I just have to run faster than my companion.

Just checking this google page summs it up.
http://www.google.com/search?hl=en&q=Linux+and+WPA &btnG=Google+Search
I started with the basics to get a working connection. I can try to add WPA later, but enough have had problems.

How did you know I work in a cleanroom?

Switching to Libata

[Anonymous Coward]

Hi! I'm using a vanilla kernel (2.6.22) and am trying to switch from the old IDE drivers to libata for my PATA hard disk (currently the root is /dev/hda2). I've compiled a kernel with just the libata portion but when I try to boot I get the following message: vfs: cannot open root device UUID=blahblah or unknown-block (0,0)

My /etc/fstab and /boot/grub/menu.lst have the correct UUID for the root fs, what can be wrong here that it can't properly find the root fs ?

More information:
1. Libata and PATA are configured _not_ as a module, they're static in the kernel.
2. I'm not using initrd.
3. I've tried to boot from grub with root=/dev/sda2 instead of using UUID, but had the same error.
4. I've an force2 motherboard and am using the CONFIG_PATA_AMD option.

Thanks in advance for any comment about this.
JC

Re:question on the wireless

[monkeySauce]

I DO use Linux over wireless, only it's WPA2/AES-CCMP. However I am running Kubuntu Feisty. Maybe it's time for an upgrade?

I don't buy the "safe enough" arguments. It's broken. Friends don't let friends use WEP.

Re:question on the wireless

[disasm]

Don't forget the Intel chipset. Those work great out of the box. I'm not sure if they've come out with any pci cards, but their internal wireless works like a charm. Sam

Re:no zfs. no gpl 3

[the_greywolf]

There's no tangible performance difference with userspace filesystems. People have even gotten a system to boot off of them. (initrd just has to have the module handy.) The NTFS-ng driver arguably has better performance as a userspace filesystem than NTFS.SYS does on Windows!

What...

[Ayanami Rei]

JFS is one of the better linux filesystems. And while you can't select it in the installer, you can definitely install the tools to support JFS from universe in Kubuntu, and it's similarly available in the Fedora base repositories. The kernels come with the modules pre-built already, so...

And you can shrink and grow them. And it has nice backup and fsck utilities... Oh, and it supports extended attributes and ACLs and all that good stuff. And it's faster than XFS.

So use it!

Re:What...

[metamatic]

The problem is, it's a bit of a pain upgrading Kubuntu when the boot CD doesn't recognize any of your partitions because they're JFS.

Re:What...

[drinkypoo]

The problem is, it's a bit of a pain upgrading Kubuntu when the boot CD doesn't recognize any of your partitions because they're JFS.

Don't boot and upgrade. Add the cdrom as a source (there's a command that does this specifically, I forget what it is) and do a live upgrade.

This works for any apt-based distribution AFAIK. Certainly it works for *ubuntu and debian. And it uses less memory than running a livecd!

Re:What...

[metamatic]

Yeah, but Ubuntu say they don't support apt-based dist-upgrades.

Re:What...

[drinkypoo]

So you're saying, you've paid for support? Glad to see someone is supporting Ubuntu monetarily.

Re:What...

[metamatic]

No, I'm saying I paid for Gentoo, paid for a copy of Xandros, but I haven't seen an obvious way to pay for Ubuntu. All the DVDs are out of stock at Amazon. Maybe when 7.10 ships...

Re:What...

[drinkypoo]

Sorry, it was a cheap conversational device. I'm just saying, if you're using the free support, it doesn't much matter if you're dist-upgrading or CD-upgrading, because the free support options (forums, irc, etc) don't care.

TTY/console/fbdev/DRM reorganization

[kinema]

hey wait TTY layer ...any takers? please :-)

I'm with you brother. What ever happened to John Smirl's console rearchitecture proposal he presented at OLS 2004?

Re:User "Aldric" is a cyber-vandal

[rbanffy]

This is getting increasingly Digg-like...

Sales support / commission on $39 part?

[billstewart]

USB Wireless parts aren't exactly expensive - maybe a Wireless-N or a version with a fancy antenna still costs over $50, but most of the wireless-g parts are under $50, especially if they're on sale. And if you try to ask the average Fry's employee about obscure Linux kernel compatibility questions, they might feel bad about not knowing (unlike a typical retail consumer products store employee, who won't feel bad about not knowing...) but they're not going to know.

But maybe they'll let you try it out in the store anyway.

Oops

[MichaelSmith]

"It can sneak out the front door with your CD collection in ther middle of the night"

s/can/can not/

Re:Upgrade

[Technician]

However I am running Kubuntu Feisty. Maybe it's time for an upgrade?

Probably true. I'm running Dapper because I have a life. I spend little time as a noob putzing with it. I'm more of an end user. I settled on Dapper because it is the LTS version so I wouldn't have to be on the 6 month upgrade cycle.

Anyway, in a couple years, I'll upgrade. In the meantime I'll enjoy the sunshine and warm weather, camping, etc. When rainy weather sets in and I have time to blow my install and learn how to recover it, I'll ditz with it.

In the meantime, I have a date with a jetski.

Re:question on the wireless

[Technician]

I don't buy the "safe enough" arguments. It's broken. Friends don't let friends use WEP.

Swing by and leach then. Good luck. I use more then 1 router. WEP may be weak on the wireless level.. but it's not the only level of protection.

Notice in my original post the requirement to assign a static IP, manualy assign DNS, gateway, etc. Remember I use more than 1 router. You would need to be pretty dedicated to analise the packets to properly configure a working connection without being noticed. I watch the packets also.

Re:Upgrade

[monkeySauce]

I've found the upgrade process to be surprisingly painless, from one release to the next. However if you are going to upgrade from Dapper in "a few years" you'll almost certainly be looking at a reload rather than upgrade. It's debatable whether you will have saved much time in the end, and in the meantime you will miss out on things like WPA, for example.

I had planned on running Dapper/LTS on some systems for ease of maintenance but I've since upgraded them to Edgy and Feisty because of features or improvements in the newer releases, and because upgrading is just so easy. In fact I moved to Kubuntu from Gentoo in part to spend less time on system administration and more time actually using the computer or doing outdoor things like you mentioned; and even with occasional upgrades, time spent maintaining my Ubuntu systems is minimal.

Re:question on the wireless

[monkeySauce]

Not using DHCP adds a layer of obscurity, not protection.

After cracking WEP and sniffing traffic, all the necessary settings could be trivially obtained. "Pretty dedicated" to run ethereal/wireshark? Not really.

And finally, you still use Dapper and WEP because you have a life. Because you enjoy the sunshine and warm weather, camping, etc. Because you are dating a jetski.
And yet you reserve time for "watching the packets" to see if anyone has pwned your network yet? Wow.

Get Snort, setup WPA, and eat, sleep and be merry. That's my advice.

Re:Upgrade

[Technician]

but I've since upgraded them to Edgy and Feisty

I've heard of several problems with the upgrade from Dapper to Edgy, so I have been avoiding that upgrade. Most of the Forums recommend a new install instead. With a new install, you need to reset most everyting and start over with non-free codecs, MTP Library for the Zen, drivers & apps for the video capture card, configuring Myth, e-mail, Flash 9, Flashblock, etc. For me the re-configure would be times 3.. My laptop, my kids desktop, and my dual boot desktop.

In the meantime, I'm enjoying the sunshine. I'll save that one for a rainy day. I'm not willing to set aside a sunny day just incase the upgrade has problems and requires more time to tweak. As a noob, many of these tasks require quite a bit of time in Google searches.

Re:question on the wireless

[Technician]

And yet you reserve time for "watching the packets" to see if anyone has pwned your network yet? Wow.

It isn't hard. It's mostly automated. If I'm out and there is a burst of traffic, it requires investigating. Some rules when violated send an alert.

Due to a few open unsecured AP's in the neighberhood, I haven't had activity in over a year. It's pretty low maitenence/low risk. It's simply easier to go elsewhere.

Take an old P2 box and install snort between your internet wired router and your wireless router and LAN. Set alerts and check it once in a while if you don't hear from it.

As far as someone pwned the network, remember, I have more than one router. It's not all on the same LAN segment. Wireless mostly goes to a gateway router and a couple networked printers. The rest of the lan is further NAT'ed. Good luck.

Re:no zfs. no gpl 3

[andersbergh]

I think the GPLv2 is a better license - I'm not against tivoization. They release their changes to the source code, so you can still benefit from that. If they want their box locked down, fine with me. Why is the GPLv2 flawed?

Re:question on the wireless

[the_womble]

You would need to be pretty dedicated to analise the packets

That would require a lot of dedication

Re:question on the wireless

[sjames]

You've got to be kidding! The driver is madwifi It's not yet in the kernel, but it compiles and installs easily. It is easily the most capable hardware/driver combo I have seen for 802.11.

It DOES include a binary-only firmware componant (HAL), but that's mandated by the U.S. FCC (and equivilants in other countries) so you "can't" command the card to violate current regulations. Other wireless cards have that limitation as well and more restrictive licensing on the firmware componant as well. At least the madwifi firmware is freely redistributable.

Re:no zfs. no gpl 3

[Anonymous Coward]

It's about being able to change the software that is run by the hardware you use. What are you going to do the day that you have all the software, but no hardware to run it on because all PCs are locked down by the vendor? As for the GPLv2 flaws, well read GPLv3, and you'll get an idea of what is flawed according to the FSF.

But that's beside my point. It is absolutely necessary to have a way to update the license used for distributing software (unless you go public domain). That's not specific to the GPLv2->GPLv3. It's true of any license, proprietary or otherwise (e.g. at some point the advertisement clause was removed from the BSD license). It's likely that down the road, license fubar will need updating (changing legal framework, unanticipated issues, etc). Linus has created a situation where it is impossible to update the license of the linux kernel.

Re:question on the wireless

[si618]

I picked up an ASUS USB WiFi for a cheap price, works a treat in BackTrack 2, was able to crack our companies wi-fi network in less than 5 minutes of data capture using Kismet and 1 second of cracking with aircrack-ng.