Torvalds On Pluggable Security Models 216
eldavojohn writes "The KernelTrap highlights an interesting discussion on pluggable security models including some commentary by Linus Torvalds. While Torvalds argued against pluggable schedulers, he's all for pluggable security. Other members were voicing concerns with the pluggable nature of the Linux Security Model, but Torvalds put his foot down and said it stays. When asked why his stance was different between schedulers and security, he replied, 'Schedulers can be objectively tested. There's this thing called 'performance,' that can generally be quantified on a load basis. Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is hard science. The other one is people wanking around with their opinions.'"
Well (Score:3, Funny)
Re:Well (Score:5, Interesting)
Re:Well (Score:2)
But being theoretically able to measure something doesn't mean it's practical or the the results are always useful.
The thing is that Linus isn't talking about the general case here, he's referring specifically to these two cases. If you've got some kind of performance consideration for scheduling that's not being measured, or have good evidence that the current measurements aren't relevant to the user experience, you should bring it up. If you're just speaking in a general philosophic way, that's nice and all but I don't see how it's relevant.
No, he doesn't understand (Score:2)
Possibly (Score:2)
Re:Well (Score:5, Funny)
Re:Well (Score:5, Insightful)
Re:Well (Score:2)
Near all my software is arrogant, but I try to make it cluefull :)
Re:Well (Score:3, Funny)
I think he wrote Clippy.
Re:Well (Score:2, Informative)
Linus is an asshole.
Re:Well (Score:2)
But he's an asshole in a good way.
Re:Well (Score:2)
But he's an asshole in a good way.
Even when you do, getting dressed down by someone who knows WTF is up and is goal oriented and not just fucking with you hurts more, but is less humiliating than the usual abuse we (people) take from know nothing assholes who just want to ruin you for shits and giggles.
Re:Well (Score:2, Interesting)
Saying "no" is the toughest job in the world, but in this case it's a bit different. If you read further down in the thread this article was quoted from, you'd see that the purpose of LSM was so that Linux could keep going forward rather than being engaged in endless security flame wars.
Security is hard and in my own experience MLS guys can be real assholes. I cannot fault Linus for the decisions he made. Based on my own reading of the Smack code, I would think it merits inclusion - it looks very clean.
Re:Well (Score:3, Informative)
To some perhaps. To others he's just an effective team leader who makes decisions to focus efforts. The alternative is usually a lot of people flapping around like headless chickens since they don't know which way to go. Worse yet if the thing is run by an ineffective person or committee where development slows to a glacial pace because no patches are accepted or bogged down in protracted politics and debate. If you want to see what the kernel development would look like in those circumstances, look up XFree86, Emacs, Hurd etc.
Re:Well (Score:2)
If it takes one to know one, there's one thing I can't figure out, would you be Colonel or Captain Asshole ?
Re:Well (Score:3, Funny)
Re:Well (Score:5, Funny)
Re:Well (Score:2)
though the version I know is "don't anthropomorphize $objects, they hate that"
Re:Well (Score:2, Interesting)
Every time Linus has a decision to make there are two or more tom-cats out screeching and raising hell on the fence outside his window. Sometimes the tom-cats are looking at him like he is a tabby and your suprised if every so often he throws a boot at the tom-cats?
Re:Well (Score:5, Insightful)
You're not being very convincing either. You call Linus all sorts of things, without actually saying specifically why you think he is arrogant, clueless, and has no understanding. I'm open to the idea that he may be, but your post certainly does nothing to convince me of it.
At least Linus has specifically stated why he thinks security guys are "wanking around". It's because security people state that "only my version is correct", when they don't quantify exactly why this is the case. That certainly meets my criteria for "wanking around". Linus appears to have made a good judgement call.
Re:Well (Score:5, Insightful)
Security is a process. You make the effort needed to crack or crash a system beyond the value to the attacker, and they won't attack.
There's simply no need of SELinux in a coffee pot or an MP3 player. It's overkill. Linus is concerned with all the targets of the kernel, and not just the Sewper Seekret Survur next to the dresser in some kid's room.
Now _you_ might be using Linux to keep millions of credit card numbers or to process satellite intelligence for some national government, but that's not what everyone does with it. So long as there are reasons to focus more or less on security and different needs among those focusing on it, pluggable security models make sense.
For the vast majority of Linux targets, SELinux in particular is probably overkill. The scheduler effects everyone. If your main goal is security at all costs, use SELinux (it's not hard) or use OpenBSD instead of Linux.
Re:Well (Score:2)
I think Linus should read this and he, of course, would find it very agreeable since that's *exactly* how he defines his leadership model.
You can read it here (http://lwn.net/Articles/105375/), if you don't believe me.
Just look at its very first paragraph:
"Everybody thinks managers make decisions, and that decision-making is important. The bigger and more painful the decision, the bigger the manager must be to make it. That's very deep and obvious, but it's not actually true.
The name of the game is to _avoid_ having to make a decision. (...)"
Now, you can agree with his managerial style or not. Linus Torvalds provides the Linux kernel as an achievement of his managerial style, what will provide Mr. ShieldW0lf to counterargument?
Re:Well (Score:5, Insightful)
There is no security model that's better than others for all cases. They're all tradeoffs between convenience and security at the user level, and no, a security model is not quantifiable, as the amount of variation between specifications is mindboggling. Do you know the difference between RBAC, RAS, SELinux, AppArmor? Between the dozens of different and incompatible security systems used in AIX, Solaris, i5/OS, QNX, z/OS, and VMS? They all have their places, they all have their own advantages and disadvantages. Security doesn't stop with setting the "sticky bit".
But most importantly, security models are not CPU-intensive. Even the most demanding model will check file access permissions once in a blue moon in comparison to a scheduler. Schedulers store and use differnt information in very different ways which makes it difficult to make a generic framework that will support every possible datum they might need without making a significant impact on performance (it's a piece of code called thousands of times a second, performing rather complex computations).
Besides, it doesn't mean that Linux doesn't have several schedulers. It does, but they're kept under different branches, and they're sufficiently tunable to meet all your usual requirements, and CFS is a sufficiently superior alternative with the right stuff to warrant its maintenance in the mainline.
wanking around (Score:5, Funny)
Re:wanking around (Score:2)
Spot on Torvalds... (Score:4, Insightful)
If not, an artificial limit onto the integrity of the system would be created. Sure SELinux is a viable option, but why should we think it is the best ?
Re:Spot on Torvalds... (Score:5, Insightful)
So, no, security folks are not "wanking around" as some specific asshole seems to claim, they are using the best tools available to evaluate adequacy of different security solutions. Those that do not get this are not getting what security is about and what the state of the art is. These people should better stay far away from security-relevant decisions and let people that at least understand present technology in that area make the decisions.
Re:Spot on Torvalds... (Score:3, Insightful)
The best of present technology is modular to a certain extent, from a micro and macro perspective of system or network. Why implement a non-defacto standard of secure by including it in the kernel?
I've run SELinux, and I know that James Morris isn't stating he wants that exact implementation only, but he says choose one. How do we quantify that or any assertion and make an informed decision going forward knowing that there possibly is a more secure path to follow?
Re:Spot on Torvalds... (Score:2)
Security cannot be quantified in hard numbers, since security is always relative to the resources the adversary has.
I don't think anyone is asking for hard numbers for some general case. I think people are just asking for numbers for some specific cases. Lots of things in computing vary with one factor or another. I fail to see why one or many factors changing the outcome of what "best" is means you can't supply hard numbers.
Not that I think that hard numbers on which security model is really possible. I think security is a soft science because you can't really run any controlled experiments. Those kind of situations are vulnerable to "But X is better, I SWEAR!" "NO! Y IS BETTER!" since there's no way of finding out in any objective way what the right answer is.
These people should better stay far away from security-relevant decisions and let people that at least understand present technology in that area make the decisions.
I guess I see that as the height of arrogance. If you can't demonstrate why one approach is better than another to someone as technically capable as Linus, I think he's taking exactly the right approach. Maybe there is some kind of true wizardry going on here, and we should just trust you all. But I've never been comfortable with simply the "trust us!" approach to anything.
Re:Spot on Torvalds... (Score:5, Informative)
Re:Spot on Torvalds... (Score:2, Insightful)
Re:Spot on Torvalds... (Score:5, Insightful)
Yeah, because modularizing the scheduler doesn't have any performance or implementation or maintainance or QA problems.
-:sigma.SB
Re:Spot on Torvalds... (Score:2)
Now, if we can only kill off Daylight Savings Time. (seriously, if you want to get up an hour earlier, just GET UP AN HOUR EARLIER)
Re:Spot on Torvalds... (Score:2)
besides bonfire tales from the bearded ones on peyote during burning man.
Re:Spot on Torvalds... (Score:5, Insightful)
Re:Spot on Torvalds... (Score:2)
Ok, agreed... but, you can provide numbers to back that up. Statistics can always lie, regardless of if they are true. It's the fact that they are there and can be seen and visualized that is important. That being the case, it doesn't matter which way you lean towards schedulers. The fact that you cannot quantify security is an argument for keeping it modular.
Re:Spot on Torvalds... (Score:4, Informative)
Re:Spot on Torvalds... (Score:2)
Re:Spot on Torvalds... (Score:3, Interesting)
Apples... Oranges...
Re:Spot on Torvalds... (Score:2)
Re:Spot on Torvalds... (Score:2)
Re:Spot on Torvalds... (Score:2, Interesting)
I think some of the key scheduler performance metrics includes:
1. Context switch time.
2. Fair scheduling
3. Interactive tasks are interactive.
4. Certain applications always get larger portion of time if needed.
5. Real time.
There are things called "parameters" that you can adjust to adopt Linux
to your need.
This doesn't say Linux scheduler is perfect. It is evolving, too.
A few years ago, many embedded systems that needs real time scheduler
can't be implemented on Linux because timing requirements. Now the
scheduler supports real time and I can still use any applications
without knowing what the hack they have done to scheduler.
Now.
Give me an example that Linux scheduler can't satisfy your needs, and,
Give me an example that one security architecture satisfies you and me.
Re:Spot on Torvalds... (Score:2)
So we can quantify scheduling performance? (Score:5, Insightful)
If we don't keep scheduling modular, an artificial limit on the performance of the system will be created. Sure, CFS is a viable option, but why should we think it is the best ?
What's more, "wanking around with your settings" has often been what Linux has always been about. Ubuntu never uses chroot in a normal situation; does that mean it should be taken out? My GUI and hotplug utilities can automount anything I plug in; should
We haven't used anything but ELF for probably 5-10 years, yet, last I checked, a.out is still supported.
Why should the system be made non-modular?
Re:So we can quantify scheduling performance? (Score:2)
You are right, there always could possibly be a faster scheduler for a given system / task / embedded system.
One analogy however malformed uneducated and abysmal is:
Sure, it would be cool if you put NOS kit on a ferrari, but once you hit a wall it won't matter if you are going 150 or 225 if you aren't wearing a seatbelt or there are no airbags.
Re:So we can quantify scheduling performance? (Score:5, Insightful)
Re:So we can quantify scheduling performance? (Score:5, Interesting)
The security realm however is completely different. For one, the performance requirement does not exist. So the performance penalty that modular architecture brings is largely irrelevant. And since there exist no metrics that can be used to determine whether one security model is better than another without the usage context, a plug-able architecture is the best road to go down to let something that users CAN and WILL want to implement completely differently from one use-case to the next.
Re:So we can quantify scheduling performance? (Score:2)
If it had to be hot-pluggable -- as I believe some of these are -- then yes.
But just run "make menuconfig" and take a look at the insane number of options you have for compiling a Linux kernel. It seems to me that slapping some #ifdef statements around some code isn't going to make it perform any worse.
It might, however, be harder to maintain.
In security? Yes it does!
I mean, yes, we'll often choose the more secure model over the better-performing one, but not always. Consider the performance implications of, for example, trying to predict every possible state a program could be in, so you could determine whether or not to run the program -- programs which might possibly do things they aren't allowed to never get run in the first place.
Obviously, we don't do that. We do the analysis at runtime -- when a program attempts to do something it's not allowed to, we block it then, we don't try to predict it happening.
Except from what I understand, SELinux and ACLs are a superset of traditional Unix security, and could, in fact, completely replace it (and emulate it). So why not make SELinux the only security architecture?
Re:So we can quantify scheduling performance? (Score:2, Informative)
Hard realtime usually implies severe perfomance penalties. People who really need something like that probably dont use a vanilla kernel.
Torvalds usually doesnt care about something being the best. Its supposed to be good enough.
Using the word best requires you to say for what, otherwise you might as well use a word such as coolest, most geeky, most whatsoever.
Since Torvalds usually cares a lot about efficiency i guess that a plugable scheduler would be less performant.
Re:So we can quantify scheduling performance? (Score:2)
Using the word best requires you to say for what, otherwise you might as well use a word such as coolest, most geeky, most whatsoever.
So one is required to say for what something is best for, but not for what something is good for?
Maybe you want to think about this a bit more?
Re:So we can quantify scheduling performance? (Score:2)
Well, I was commenting on the format structure of your argument: my point is, if you are required to say what something is best for, I see no reason why you should not be able to be required to say what something is good for. Your reply may be cogent or not, I really do not have a strong opinion. I was only pointing that you may want to find a stronger argumentation.
Re:So we can quantify scheduling performance? (Score:2)
True enough, or at least, they don't use a kernel compiled with vanilla options.
The whole point of wanting a pluggable scheduler is to let the end-user answer that "for what" question, instead of having Linus answer it for you, or have to use a fork.
I don't argue that it has to be pluggable at runtime, and though I haven't been following this, I suspect that "at runtime" is what would slow down the architecture. Because if it's just another menuconfig option, that slows down development, not execution.
Ew, redundancy... (Score:2)
Yay for creative grammar... I apologize to anyone else who caught that. Preview is not my friend today :(
Re:Spot on Torvalds... (Score:2)
Security is, in fact, quantifyable - you can tell if your data is or is not secure in either absolute or relative terms. But that still misses one basic, very important element
Yes, taste *is* involved in security. Just as there are many different ways to sort data, and still wind up with an alphabeticalized list, there are also many different ways to secure your data, and still wind up with it being safe.
I don't do the dishes the same way my daughter does
So the SELinux folks don't do THEIR thing the same way the LSM folks do
I'm sorry, but I see this as a religious war along the lines of vi vs emacs. Give both camps their tools and let them do things according to their environment, level of risk, and taste.
Re:Spot on Torvalds... (Score:3, Insightful)
Re:Spot on Torvalds... (Score:2)
Because that means more code to maintain. Code that might be broken later.
However, I do think there's sufficient reason to keep it pluggable. We have all kinds of other things pluggable that don't need to be, and plenty of other cruft in the kernel -- think binary formats other than ELF, old filesystems that nobody uses, and completely depricated systems like OSS for sound.
This reeks of politics, something I thought Linus was good at avoiding.
Re:Spot on Torvalds... (Score:3, Informative)
Indeed, it's also been showing (RTFML) that scheduler improvements are mostly trivial and generally don't warrant such an effort.
Finally, one must consider that the enormous amount of bugs being introduced by touching so many different areas and applying different algorithms in different cases.
Maybe this is something for consideration with the 3.x branch (Of which Linus has no intention of making), but it seems like a reasonable decision so far given the data.
Re:Spot on Torvalds... (Score:3, Interesting)
I understand that it needs to be maintainable, but I would think a flexible architecture would be MORE maintainable, not less.
(I admit that I don't have enough experience to make such a statement, at least about Linux and C.)
Re:Spot on Torvalds... (Score:2)
Re:Spot on Torvalds... (Score:2)
Linus simply stopped accepting patches from either of them until they sorted out their differences.
He could have chosen sides, but he didn't.
Re:Spot on Torvalds... (Score:2)
<sarcasm>They only think they need them. Really, they're just wanking around with their settings.</sacrams>
Consider if we only supported, say, ext3 for the root filesystem, and the only filesystem supported for mounting. Anyone who wanted to work on new and exciting stuff, like, say, ext4, would do so with a fork. Access to other filesystems, like network, ISO/UDF, and FAT/NTFS, can be done in userspace -- see the various userspace VFS projects -- they don't have to be fast anyway, since they're generally removable media, or stuff rarely accessed. Anyone booting from the network is probably running a custom kernel anyway.
These are all arguments I've heard people use against pluggable schedulers, which don't make sense here. After all, you can't have two root filesystems at the same time...
And some systems don't need pre-emptive scheduling. And some of them could certainly do better with a round-robin scheduler, so that more time is spent crunching and less is spent deciding what to do.
The point is that the main kernel maintainers are deciding what's important and what's not. I don't know enough to understand whether it's seriously problematic to implement a pluggable scheduling system, but this does not get to be dismissed as "not important", and certainly not as "people just wanking with their settings". Multiple schedulers are necessary, in some form, even if they have to be in separate kernel forks.
Re:Spot on Torvalds... (Score:2)
Yeah. Sounds like ALSA/OSS.
In fact, there already are a few notable instances of this -- NTFS being the obvious example. The userspace NTFS implementation is actually much more robust and featureful.
Moreover, this is already true of every filesystem that I know of, to some extent. Remember that the userspace implementation need not provide everything the kernel implementation does -- even simple APIs to copy whole files in/out of the FS might be sufficient for most workloads.
But just how do you think mkfs.ext3 works? How about fsck.ext3? Or the various debugfs, dump, etc...
More likely, they'd develop it as a replacement. They'd use UserMode Linux, and they'd probably start with the ext3 code, so ext4 need never be in a state such that it can't be used as a root FS, even if only for a disk image.
More likely, ReiserFS would only be implemented in userspace. It's irrelevant -- using filesystems other than ext3 (or ext4) for your root filesystem is just wanking with settings, remember? You only need ReiserFS if some poor, uneducated soul happened to format their system with Reiser, then you have to use the userspace driver to back it up.
I imagine there are actually filesystems that have already moved to this level of support -- where the userspace utilities are really the only way of getting at the stuff, as all kernel support has been dropped.
Fortunately, there's still FUSE, but that's a big performance hit, and it does tend to invalidate your case against pluggable schedulers.
Re:Spot on Torvalds... (Score:2)
Indeed. Nothing about the system I proposed requires more duplication than we have, except for people wishing to run a different filesystem as root.
That's a fair point, but then...
Are you saying that what people want should dictate these decisions? Because if so, it seems plenty of people want the pluggable scheduler.
In that case, they get to run a patched kernel, and maybe not get updates, until they can either find a bootcd with a tool for migrating their data in-place (difficult to write for any filesystem), or they can back all their data up and restore it.
I seem to remember that Minix was, at one time, supported by the kernel. And I believe it's been removed, so anyone who was still using the original Minix or ext has to upgrade to ext2. And I believe ext2 is format-incompatible, meaning they had to back up and restore, though I could be wrong about that. I'm fairly sure ext4 will be incompatible, though.
Understand, too, that I'm playing devil's advocate here. I'm perfectly happy with pluggable filesystems, although I'm not particularly happy that so much of the filesystem is in the kernel, or that context switches are slow enough that it makes sense for them to be there. I'm just using it as a basis for explaining why I think pluggable schedulers might be a good idea.
Although there was another reply, kind of buried by now, maybe, pointing out that CFQ is very tunable and supports somewhat more limited plugins of its own. That would suggest it's more like replacing the Linux VFS with Reiser4 (and implementing existing filesystems as Reiser4 storage plugins), although I wouldn't recommend that either now, as unstable as Reiser (filesystem and person) can be.
Awesome (Score:3, Funny)
Thanks Linus, that cracked me up. I've always felt that way about a lot of the stuff the security guys do. I'm gonna forward that to our local security guys and see what they think!
Re:Awesome (Score:3, Insightful)
Re:Awesome (Score:2)
You're mixing types here and -fail- at logic. Process and Methodology are synonyms. Results can be from processes and methodologies. Results can be both objective and false/actual/perceived all at the same time. Etc. Were you trying to say "security is a lot of different things"? Thanks captain obvious.
SECURITY is (especially because of the obvious truth you pointed out) a concept with a subjective root: Ie, If I dont want anyone else to access the machine but me, my concept of what it means to secure the box is completely different from someone who runs a honeypot.
And while the fact that Im an enterprise security architect for a large organization (among other things) isn't a guarantee that I know wtf Im talking about, it's a pretty good indication that I have the basics down right
Re:Awesome (Score:2)
There is a fact of the matter whether a particular model or implementation can be breached by an adversary, even with infinite resources.
"No adversary should gain access to any resource unless implicitly or explicitly authorized to use it".
Both of these are true. But they both assume someone has (subjectively) identified which resources to protect and how much cost/effort should be spent to protect them. Without those subjective decisions, security models are irrelevant
Re:Awesome (Score:2)
I think someone missed the memo with "don't piss off the guys that could make your life hell". Have you any idea how quickly everything would come to a grinding halt if they were really anal about applying every detail in the security policies? No, I don't mean the normal terror regime, I mean the kind that'd actually kill the business and force change if they ever tried to apply it company-wide. Now, instead imagine that they make a point of applying it just to you...
Re:Awesome (Score:2)
Your comments have thus proven Linus's original comment perfectly valid. Security guys are wankers.
"don't piss off the guys that could make your life hell"
No... don't piss off the guy who administers your account and domain, owns your boxes and allows you to run your little FBI-CIA-NSA wannabe security empire.
Re:Linus is a foreigner (Score:2)
Cold Hard Engineering Measurement, or Science? (Score:3, Interesting)
``...the subjectivist states his judgments, whereas the objectivist sweeps them under the carpet by calling assumptions knowledge, and he basks in the glorious objectivity of science.'' - I.J. Good
I stopped reading TFA (Score:2, Interesting)
Damn I'm sick of scheduler FUD. It makes its way into every single linux conversation now, now matter how unrelated.
Re:I stopped reading TFA (Score:4, Funny)
You'll reprioritize when your starving children become zombies and your parent tries to kill you.
What about (Score:5, Funny)
Re:What about (Score:2)
Re:What about (Score:2)
Yes, but that's an iterative solution with a known end condition.
If you read all of it ... (Score:5, Informative)
His complete email reads:
Schedulers can be objectively tested. There's this thing called "performance", that can generally be quantified on a load basis.
Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers.
So the difference between them is simple: one is "hard science". The other one is "people wanking around with their opinions".
If you guys had been able to argue on hard data and be in agreement, LSM wouldn't have been needed in the first place.
BUT THAT WAS NOT THE CASE.
And perhaps more importantly:
BUT THAT IS *STILL* NOT THE CASE!
Sorry for the shouting, but I'm serious about this.
Al I alone in thinking that Linux basically says:
"Look I'm no security expert, and I'd be happy to follow your collective expert guidance if only:
(a) you could quantify what you're saying and turn it into engineering instead of a religious argument
(b) the lot of you could agree on *one* set of guidelines/features as being best all-around
Unfortunately it appears you can't do either. That being so, I'm not going to burn my fingers and blindly choose one security boondoggle over all the others. I'll just make them pluggable so that every one of you can have his own personal security system. End of discussion. Now go away and be happy."
Re:If you read all of it ... (Score:2)
> we'll have to continue dealing with several unpleasant issues, such as the
> abuse of the API by out of tree vendors,
Re:If you read all of it ... (Score:3, Funny)
Perhaps if people read all of Linus's email they would be more understanding and less quick to condemn him.
If I could read all of Linus's email, I think I would be more understanding of him wanting to be able to work with security models :p.
Re:If you read all of it ... (Score:2)
Bring deRaadt in for a consult (Score:2, Funny)
Ahem (Score:3, Informative)
Re:Ahem (Score:5, Insightful)
Scheduler vs Security Plugins (Score:3, Insightful)
As for the Linux scheduler, I wouldn't mind a choice in desktop vs server tweak settings in (a)
Enjoy,
irony (Score:2, Informative)
Re:Good. (Score:3, Informative)
I can't videoconference, edit videos, make mp3s, play video games or make a slideshow in Linux. How about a couple of kernel devs drop off and help Linux go the last mile.
Other than video conferencing (haven't tried), my wife and 13 year old son can do everything on your list (using SuSE, Fedora or Ubuntu).
Shouldn't you be posting questions to http://www.linuxquestions.org/ [linuxquestions.org] or http://www.justlinux.com/ [justlinux.com] ?
You wont get a RTFM response.
Slashdot isn't a Linux help forum.
Enjoy,
Re:Good. (Score:2)
Re:Good. (Score:2)
Just because you can't does not mean Linux can't.
VideoConference http://ekiga.org/ [ekiga.org]
Edit Video http://www.kdenlive.org/ [kdenlive.org]
Make mp3s: Insert CD copy mp3 folder with kde.org [slashdot.org] or Create new with http://audacity.sourceforge.net/ [sourceforge.net]
play video games with http://www.winehq.org/ [winehq.org] or http://www.transgaming.com/ [transgaming.com] or god forbid you play open source games designed for linux. Too many to list see here http://icculus.org/lgfaq/gamelist.php [icculus.org] for a start.
make a slideshow, Ever use http://picasa.google.com/linux/ [google.com] or KDE creates them on the fly from directory of pictures. Not to mention openoffice Impress http://www.openoffice.org/product/impress.html [openoffice.org]
How about a couple of kernel devs drop off and help Linux go the last mile.
How about you let the kernel devs do what they do best, and acquaint yourself with a little thing I like to call Google http://www.google.com/webhp [google.com].
Re:Good. (Score:2)
Maybe not as helpful, but it cracked me up.
Pidgin (Score:3, Insightful)
Pidgin is an instant messaging program for Windows, Linux, BSD, and other Unixes.
How is a shortcoming of this software a shortcoming of Linux? You may be right to say there is no combined im/VOIP/video conferencing suites for Linux. Sounds strange to me, though. Perhaps you can make a feature request for Pidgin.
Re:Language abuse (Score:2, Funny)
Re:Language abuse (Score:2)
Re:Language abuse (Score:3, Funny)
Re:like object oriented? (Score:5, Insightful)
At some point, you have to deal with the fact that there is going to be some overhead in dealing with an object-oriented approach. Even if the significance is near 0, the scheduler is pushing operations on the CPU on an incredibly large scale, which might show its ugly face in performance. IMHO, it wouldn't, but I guess Linus knows better than I...
Anyway, there is this great site called the Linux Kernel Archives [kernel.org], which has the source code for every version of the Linux kernel ever put out. If somebody was really serious about using their own CPU scheduler, all they have to do is take the latest version of the kernel, download the source code and modify sched.c to fit their needs. Even if it isn't object-oriented, that doesn't change the fact that everything else in the kernel only cares that default_wake_function tries to wake up a thread - it doesn't matter how it works on the inside. All the other parts know about is the sched.h header file.
Sure, it isn't on-the-fly pluggable, but different distributions could easily use different schedulers if they simply compile the kernel. A distribution could make a sched.c that is pluggable (it would have an interesting look to it, but it could be done). I wouldn't want to debug it, but for all this complaining, you'd think somebody would do something about it.
Re:like object oriented? (Score:5, Interesting)
Ahh, the "when in doubt claim OO is expensive" defense. Please tell me, how long does a modern CPU need to take a branch to an address in a well known fixed memory cell which is guaranteed to be in L1-cache? Do you think it is longer than a conditional branch needed to handle the case single core dual core? Is it longer than the combined times needed to additionally handle the case one CPU-chip two CPU-chips? I don't know, I haven't done the measuring, but I have doubts the first is the slowest as the opcode scheduler should be able to handle the first and especially has the advantage of an always taken jump. We are heading in a parallel future, there are scheduling differences between single core/dual core and single CPU/multiple CPU. Why on earth should the scheduler written for the most complicated case (it has to handle cases like one dual core and two triple cores and one quad core efficiently or it is not the best scheduler, no?) be more efficient than a single core scheduler on a machine with only a single core? Or are the benchmarks "tweaked" so the first is the "right" case to benchmark?
As written by multiple posters, yes, you can get benchmark results for schedulers, but what is the correct benchmark? Is it the maximum throughput model you don't want to have as a desktop box or the minimum waiting time for interactive jobs you don't want on a compute server? And if you need numbers to come up with the best security model, count line numbers, it is about as relevant.
Re:like object oriented? (Score:3)
The reason why the scheduler is so performance sensitive, is that it uses close to the worst case branching behavior possible. The following steps happen:
1. An interrupt occurs. The entire register set is pushed, page tables in the MMU are reloaded, and kernel code is executed. L1 and L2 cache are reloaded with kernel code and data.
2. Kernel code is executed. Hardware response issued.
3. Scheduler is executed. Per scheduling rules based on waiting processes, new process awakes.
4. New process executes. L1 and L2 caches reloaded. Page tables reloaded.
Massive amounts of CPU data are flushed and reloaded as the ISR / scheduler process executes. Additionally, the scheduler executes frequently. Sometimes the scheduler executes and changes processes once per interrupt, depending on what processes are waiting on what resources. Interrupt frequency significantly affects affects system performance, and the schedulers performance directly affects expensive activities like reloading the page table and reloading the L1 and L2 caches.
The last time I benchmarked the effect of interrupts on system performance, the numbers were like this:
At 1 kHz interrupt rate, the effect of a short background ISR on foreground performance was minimal. About 5% - 10%, depending on the computer.
At 10 kHz interrupt rate, the effect was significant (about 50%).
Between 20-30 kHz interrupt rate, almost all CPU time was being devoted to the ISR. Foreground processes almost stopped.
Testing was on a fast P-III machine or a slow P-4 machine. It has been a few years.
Modern multi-tasking 32-bit CPUs just can't handle very many interrupts per second. The problem is that both the L1 and L2 caches and the memory management tables get reloaded every time a major task switch occurs.
Even if the scheduling penalties were not significant, it is still not desirable to have a pluggable object oriented scheduler. A normal function call is:
CALL function_address
A call to a virtual function in an OO langauge is usually implemented as: // Indirect call
MOV EBX, vtable_address
CALL [EBX]
The OO code uses a fully indirect jump, which is significantly slower. However, the big issue is reliability. If the vtable accidentally gets clobbered due to bad code or a hardware fault, then the CALL instruction is a branch to nowhere. Your computer will crash. This fault is non-recoverable since it is in the scheduler itself. If instead we use the faster direct CALL instruction, we know that the scheduler always executes and hopefully some task will run (even if it is the wrong one.) Thus a reliability penalty is paid if we use an object-oriented pluggable scheduler approach.
For performance reasons, and for reliability reasons, it is a really good idea not to have indirect function calls in the scheduler code.
Re:like object oriented? (Score:2)
And why would that be relevant in this case? The kernel is written in C, not an OO language so it would have to be simulated in any case. What I would do is to define the interface as a sequence of jump slots. Then when a scheduler is "instantiated" just drop the new jump commands to the scheduler "methods" there. I don't see any reason why I would ever want to use two instances of the scheduler at the same time. When one is created the other can be destroyed. If I want to use two schedulers I would have to write a scheduler scheduler (and I doubt there is anything to be gained down that path). So what you would have instead of the direct call
is an indirect call: where the address and also the location to jump to is very likely in L1-cache as it is used very often.Sorry, I don't see how you get a magic kernel fault only affecting a very specific cell (the vtable). If something in the kernel starts to write to random memory cells, I would call it "reliable" if the system notices the problem, localizes the problem and solves the problem. I would much rather prefer fail-stop behavior (kernel panic).
Re:like object oriented? (Score:2)
Says somebody that, it seems, never tried that on real life.
Good luck with any functionality change in sched.c. And if you really want to mess with the scheduler, not thread wake up, I really desire you a lot of luck to keep the information you need without breaking any unrelated part of the kernel.
Re:What does Linux Torvald know about modularity? (Score:2)
This is Slashdot. Nudity.
Re:Need to plug goatse (Score:3, Funny)