Linus says Linux has become 'bloated and huge'(theregister.co.uk)
theregister.co.uk
Linus says Linux has become 'bloated and huge'
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/
12 comments
Whilst libata and the unifying of the WLAN may make the code easier to maintain, it will only save a tiny amount of memory and in the short term, just like any new code, is going to increase the number of bugs.
It sounds like the problem is that everyone is writing new features that probably not many people actually need (since they did fine with out it before - I'm not talking about drivers here) but it's slowing the whole kernel down and people need to go back and optimise that stuff.
It sounds like the problem is that everyone is writing new features that probably not many people actually need (since they did fine with out it before - I'm not talking about drivers here) but it's slowing the whole kernel down and people need to go back and optimise that stuff.
That's the problem though isn't it, you start off light weight and you continue working, adding more and more new and useful features until you have it all but now have a giant slow bloated system.
This makes me think of Apple's Snow Leopard. It was remarkable that they took an entire release just to shape up the code. Is something like that feasible for Linux with the open source model? Do you just have Linus tell everyone "I will only accept commits that improve performance and reduce memory footprint in this release?"
The difference is that Apple has a very specific idea what their kernel is for, where as Linux is pushed and pulled in different directions by people who want something very large scale or secure or embedded or lots of archetictures and so on.
Also you should put it in perspective, the Linux kernel itself is really not so bloated, that any normal user would notice, like they do with Gnome/KDE/Firefox's bloat. Even with that type of bloat, Linux distros still run well on a 1GB (probably less) and an old P4 CPU which people don't say about recent releases of OSX or Windows.
Also you should put it in perspective, the Linux kernel itself is really not so bloated, that any normal user would notice, like they do with Gnome/KDE/Firefox's bloat. Even with that type of bloat, Linux distros still run well on a 1GB (probably less) and an old P4 CPU which people don't say about recent releases of OSX or Windows.
That's classic creeping featurism, and there doesn't appear to be an easy way out. Either your project is rich and full-featured or it's lean and lightweight. I don't see how it can be both.
The approach that is inevitably taken by extremely large systems is to try to make all features optional except a sleek core. This is what OSGi is trying to do for Java. Unfortunately for the current debate, this is often called a "microkernel" approach. I'm not going to touch that one with a ten foot pole, but let's just say that hopefully Linux can be incrementally rearchitected to make more and more features optional without losing the benefits of its very successful "macrokernel" approach.
After all, Linux is already designed to make most of its code optional via the module systems. The only problem is that its core is becoming not-so-sleek, and they're probably already getting as much mileage out of the module system as they can hope for. One interesting possibility is that Linux could avoid the performance hit of run-time dynamism by introducing a new kind of compile-time feature selection. It's obvious to me that C isn't up to the task, but it might not be obvious to someone much smarter than me. Or maybe they could extend C. These days we think of the Linux kernel community as old, conservative, and unlikely to surprise, but who knows? I'll keep my fingers crossed.
After all, Linux is already designed to make most of its code optional via the module systems. The only problem is that its core is becoming not-so-sleek, and they're probably already getting as much mileage out of the module system as they can hope for. One interesting possibility is that Linux could avoid the performance hit of run-time dynamism by introducing a new kind of compile-time feature selection. It's obvious to me that C isn't up to the task, but it might not be obvious to someone much smarter than me. Or maybe they could extend C. These days we think of the Linux kernel community as old, conservative, and unlikely to surprise, but who knows? I'll keep my fingers crossed.
I think it just shows that open source isn't immune to the same kinds of problems that plague commercial software. As the market for a product expands, so too do the features people require for the software to work within an ecosystem of other software. More hardware to support requires more code, bigger systems.
Off topic: You wrote "commercial", while the correct term was "proprietary". You're not the only one. If I recall correctly, "Open source" was designed specifically to avoid this mistake. Apparently, that failed.
I think this shows the amount of bloat in an Open Source package increases with how widely used the project becomes. As an article posted a couple days ago on HN pointed out about 75% of Linux development is done by corporations these days. Those corporations often times create the same "good enough" code that most proprietary developers do.
Now the theory behind Open Source is that developers around the world can see bloat and fix it. But with very few exceptions the corporate developers aren't going to make their code more efficient. So you have 75% of developers creating bloated code and at best 25% left to fix it.
Meaning the amount of bloated code easily overwhelms those volunteers who are willing and able to fix it.
Now the theory behind Open Source is that developers around the world can see bloat and fix it. But with very few exceptions the corporate developers aren't going to make their code more efficient. So you have 75% of developers creating bloated code and at best 25% left to fix it.
Meaning the amount of bloated code easily overwhelms those volunteers who are willing and able to fix it.
indeed, it will be interesting to see how this issue gets tackled, if at all.
The only important factor on code quality is the quality of the people working on it. Open source or proprietary doesn't change anything.
Is it really possible to implement the full functionality of the Linux kernel in such a way that it would be significantly smaller? Obviously, there's bloat from bad code, but would a redesign of the kernel be seriously useful, or just a waste of time? As a (possible) comparison, is NetBSD's kernel any smaller?
It'd be nice to know if Linus had anything to say to that effect - it might lead to a more productive discussion than waxing lyrical about the wonders of microkernels.
It'd be nice to know if Linus had anything to say to that effect - it might lead to a more productive discussion than waxing lyrical about the wonders of microkernels.
> Torvalds answered. "Acceptable and avoidable are two different things. It's unacceptable but it's also probably unavoidable."
I think that's more or less where things are right now. You can't have tons of features without paying a price. They do a pretty good job of balancing things, but maybe someone will come along and improve things in the future.
I think that's more or less where things are right now. You can't have tons of features without paying a price. They do a pretty good job of balancing things, but maybe someone will come along and improve things in the future.
It's easy to make a tiny super efficient kernel. Just don't support stuff. WLAN? Who needs it? SMP? That'll never catch on. Take it out. Device driver support? Bleh. Let hardware makers post the source code on their websites and users can download and compile the code. No need to include it in the kernel source tree. And who uses anything but x86 anymore? Get all that PPC, ARM, SPARC non-sense out of there too. If we all work together we can make Linux completely useless but hey, it'll be tiny and efficient. We can sit around and congratulate each other for being such elegant programmers. We won't have to worry about those pesky end users anymore either.
Device drivers and processor architectures might make the source tree big, but they don't make the kernel slower or its memory footprint larger. I believe you can even still compile the kernel without SMP support.
I don't understand why he mentioned this.
I understand software bloat to describe the situation that arises when unnecessary features added to a program increases it's size and/or decreases performance, without providing significant user benefits.
In the article, Linus says "Acceptable and avoidable are two different things. It's unacceptable but it's also probably unavoidable."
If it's unavoidable, then the features that were added aren't really bloat, because it implies that these features are necessary, and that they provide significant benefits. Necessary additions that provide significant benefits could be anything from security features to IO.
IMO, Linus should either state what he thinks should be removed from the kernel, or he shouldn't even bother mentioning it at all.
If on the other hand he's lamenting the fact that there's a cost associated with adding features (necessary or unnecessary), well then I think most people understand that you can't have your cake and eat it, so even from that perspective his point seems redundant.
I understand software bloat to describe the situation that arises when unnecessary features added to a program increases it's size and/or decreases performance, without providing significant user benefits.
In the article, Linus says "Acceptable and avoidable are two different things. It's unacceptable but it's also probably unavoidable."
If it's unavoidable, then the features that were added aren't really bloat, because it implies that these features are necessary, and that they provide significant benefits. Necessary additions that provide significant benefits could be anything from security features to IO.
IMO, Linus should either state what he thinks should be removed from the kernel, or he shouldn't even bother mentioning it at all.
If on the other hand he's lamenting the fact that there's a cost associated with adding features (necessary or unnecessary), well then I think most people understand that you can't have your cake and eat it, so even from that perspective his point seems redundant.
How about "Linux Lite"? I know, it's probably a silly idea, but is it possible that the kernel team could provide a "core" kernel, that runs on most modern hardware, most popular filesystems, etc. Shoot for some arbitrary support level (80% of systems). Also provide a "large" kernel with everything. Distro maintainers can use either.
Actually, that brings up another point. Who, besides Slackware maybe, uses a stock kernel? Don't most distros customize it anyway? Am I being unfair in saying most Linux users don't really encounter the kernel at all?
Actually, that brings up another point. Who, besides Slackware maybe, uses a stock kernel? Don't most distros customize it anyway? Am I being unfair in saying most Linux users don't really encounter the kernel at all?
Roughly 11.5 million lines of code for the kernel.. That's way more than I would have imagined.. 5k lines a day are added and 2k are modified. (http://www.itworldcanada.com/a/IT-Workplace/68f20d4f-8ab9-40...)
IMHO it doesn't really jive with UNIX principles to have such a monolithic kernel.
IMHO it doesn't really jive with UNIX principles to have such a monolithic kernel.
It's monolithic but modular 11.5M LOC for every platform it runs on, not to mention drivers for the devices it supports, and all the modules for other functionality, pluggable file-systems and networking stacks. Now throw in code for backward compatibility going further back at least to 2.4 and you have 11.5M lines.
In reality, the core Linux kernel is just the stuff that compiles to vmlinux. You could read it all in a few weeks and understand it.
In reality, the core Linux kernel is just the stuff that compiles to vmlinux. You could read it all in a few weeks and understand it.
thats right, bloat
filesystems dont belong in the kernel.
filesystems dont belong in the kernel.
Yeah, there is the FUSE project: filesystem in a userspace. There are lots of interesting filesystems using this e.g. NTFS-3G, sshfs or ferrisfuse. These projects are valuable and most of them doesn't belong to the kernel as they use userspace libraries for network protocols and xml parsing.
Unfortunately native disk file systems like NTFS-3G is lot more slower than their native counterparts.
Unfortunately native disk file systems like NTFS-3G is lot more slower than their native counterparts.
&totse users ran tests of zfs-fuse back in the day and found that it was actually noticeably slower than native ext3. From that, I'm inclined to argue the opposite: filesystems should almost definitely be in-kernel. Granted, their tests were on Linux, not on a modern microkernel.
Linux, fuse
there's your problem. it's not designed for it
there's your problem. it's not designed for it
Well, with the last sentence I tried to write:
Unfortunately userspace file systems like NTFS-3G are lot slower than their native counterparts.
Which is understandable, regarding kernel calls are still quite expensive.
Unfortunately userspace file systems like NTFS-3G are lot slower than their native counterparts.
Which is understandable, regarding kernel calls are still quite expensive.
I wouldn't use Fuse as your benchmark. All of plan9's filesystems are userspace (except the one that uses a dedicated machine). They can saturate 10gbe so your objections really concern Fuse and it's hosts.
Who should decide if a piece of code to run in kernel space or user space?
user/developer/management/customer/congress/judiciaryNow micro kernel doesn't seem that stupid after all?
How would it reduce the bloat mentioned in the article? Would there be somehow less code to implement the same features in a microkernel architecture?
Microkernels are not superior from a technical perspective, but from a software engineering perspective.
-Monolithic kernels do not enforce modular implementations, inevitably leading to unnecessary dependencies
-Monolithic kernels need to be developed by a single party, who could not possibly manage such a large code base. The result is poorly maintained code.
-Monolithic kernels need to be recompiled to turn off features (and I have better things to do)
-Microkernels can tolerate more bugs (may be good or bad)
-probably a couple more
-Monolithic kernels do not enforce modular implementations, inevitably leading to unnecessary dependencies
-Monolithic kernels need to be developed by a single party, who could not possibly manage such a large code base. The result is poorly maintained code.
-Monolithic kernels need to be recompiled to turn off features (and I have better things to do)
-Microkernels can tolerate more bugs (may be good or bad)
-probably a couple more
The Linux kernel is monolithic, yet it provably does not "need to be developed by a single party" given the Linux development model - a lot of features are added in isolation by third parties and only added to mainline when they are mature and have a userbase.
Nor does the Linux kernel need to be recompiled to turn on/off features - most features can be turned on/off via /proc or sysctl or by loading / unloading modules.
As for the unnecessary dependencies, is this a problem in real life for Linux? No. Modules tend to depend on well defined kernel interfaces.
Nor does the Linux kernel need to be recompiled to turn on/off features - most features can be turned on/off via /proc or sysctl or by loading / unloading modules.
As for the unnecessary dependencies, is this a problem in real life for Linux? No. Modules tend to depend on well defined kernel interfaces.
Mot less code to implement, but it modularizes logic such that it's (theoretically) trivial to disable unneeded features. I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit.
There are a lot of other side benefits. As stable as Linux is, it still has a great deal of code executing in kernel mode, which is error-prone; microkernels can restart crashed processes on-the-fly without compromising the stability of the system rather easily. Also, some of the newer microkernels have formal proofs of their security properties, which is pretty damn fascinating! (albeit they assume the underlying proof system itself is error-free, which might not be true)
There are a lot of other side benefits. As stable as Linux is, it still has a great deal of code executing in kernel mode, which is error-prone; microkernels can restart crashed processes on-the-fly without compromising the stability of the system rather easily. Also, some of the newer microkernels have formal proofs of their security properties, which is pretty damn fascinating! (albeit they assume the underlying proof system itself is error-free, which might not be true)
As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy, and most of the kernel actually resides in dynloaded modules these days.
> I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit.
Such code doesn't matter. Most of it is in a dynloaded module, so it doesn't even eat ram, and even the stuff baked in the kernel hardly matters for performance -- the < 5 megabytes of ram doesn't even hurt in cellphones anymore, and the thing that hurts most is L1i cache use, where only code that is actually executed goes.
The bloat we are talking about is not the increase in the total size of the kernel, but the increase of the size of the commonly executed code paths. Linux being a microkernel would not help there, in fact it would hurt.
> I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit.
Such code doesn't matter. Most of it is in a dynloaded module, so it doesn't even eat ram, and even the stuff baked in the kernel hardly matters for performance -- the < 5 megabytes of ram doesn't even hurt in cellphones anymore, and the thing that hurts most is L1i cache use, where only code that is actually executed goes.
The bloat we are talking about is not the increase in the total size of the kernel, but the increase of the size of the commonly executed code paths. Linux being a microkernel would not help there, in fact it would hurt.
An increase of the size of commonly executed code paths could mean two things. First, it could mean that a lot of special casing has accumulated due to lack of modularisation or cleanup work.
Or it could mean that these cases do in fact have to be considered on that code path every time and that any "outsourcing" to user mode processes would in fact increase the size of the code path.
If it's the former, then the argument that a micro kernel design encourages more fine grained modularisation and leads to fewer special cases is not completely spurious in my opinion.
But all of this is impossible to judge without looking at the code itself.
Or it could mean that these cases do in fact have to be considered on that code path every time and that any "outsourcing" to user mode processes would in fact increase the size of the code path.
If it's the former, then the argument that a micro kernel design encourages more fine grained modularisation and leads to fewer special cases is not completely spurious in my opinion.
But all of this is impossible to judge without looking at the code itself.
Said in a simpler way: either Linux is poorly designed, or that amount of code is necessary for a general purpose kernel.
This assumes that someone needs and actively maintains every feature in the code.
This assumes that someone needs and actively maintains every feature in the code.
> either Linux is poorly designed
I take offense at the statement "Linux is designed" :)
Of course it is not optimal. Nothing else is either. How can we make it better?
I take offense at the statement "Linux is designed" :)
Of course it is not optimal. Nothing else is either. How can we make it better?
As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy
Yet in the interview, Linus says the kernel is getting bigger and slower because of new features, which presumably not everybody needs. "[W]e are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse." He isn't talking about code that can be compiled out or left unloaded if you don't need it. He's talking about code that ends up in your instruction cache whether you need the features or not.
Yet in the interview, Linus says the kernel is getting bigger and slower because of new features, which presumably not everybody needs. "[W]e are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse." He isn't talking about code that can be compiled out or left unloaded if you don't need it. He's talking about code that ends up in your instruction cache whether you need the features or not.
[deleted]
Despite the snarky tone of your comment, you hint at an interesting point:
Unix is NOT the be-all, end-all definitive operating system. Linux is NOT even the be-all, end-all Unix (or Unix-like). There is A LOT of research left to be done in operating systems / kernels and many many years of evolution to come.
It's a shame that it is SO HARD to build the ecosystem required to launch a kernel. New ideas are hard pressed to gain traction.
Unix is NOT the be-all, end-all definitive operating system. Linux is NOT even the be-all, end-all Unix (or Unix-like). There is A LOT of research left to be done in operating systems / kernels and many many years of evolution to come.
It's a shame that it is SO HARD to build the ecosystem required to launch a kernel. New ideas are hard pressed to gain traction.
Launching a kernel is easy.
Making people want to use it is hard, as most apps people want are boring to write and/or trapped in the poor design decisions of the past (e.g. POSIX).
Making people want to use it is hard, as most apps people want are boring to write and/or trapped in the poor design decisions of the past (e.g. POSIX).
You realize that OS X uses a micro-kernel, right? And that GNU Hurd is a micro-kernel too?
I wouldn't say OS X is a microkernel. Much of its codebase was built off of Mach, but much was also built off of BSD. For example, its network stack logic resides in the kernel, which is certainly not microkernel-esque. See http://en.wikipedia.org/wiki/Darwin_(operating_system)#Kerne...
"Mac OS X is sort of microkernelish. Inside, it consists of Berkeley UNIX riding on top of a modified version of the Mach microkernel. Since all of it runs in kernel mode (to get that little extra bit of performance) it is not a true microkernel, but Carnegie Mellon University had Berkeley UNIX running on Mach in user space years ago, so it probably could be done again, albeit with a small amount of performance loss, as with L4Linux. Work is underway to port the Apple BSD code (Darwin) to L4 to make it a true microkernel system." - Andy Tanenbaum
reference - http://www.cs.vu.nl/~ast/reliable-os/
reference - http://www.cs.vu.nl/~ast/reliable-os/
I realize that. On the same note, GNU HURD isn't technically a 'micro-kernel' because GNU Mach is the micro-kernel, but my point was that 'micro-kernel' instead of 'monolithic kernal' isn't some unexplored territory that only exists as theory in CompSci textbooks.
I'm not talking about just micro- vs macro- kernel. I'm talking about general OS-level research. Just look at what MSR is doing with Singularity: http://research.microsoft.com/en-us/projects/singularity/
OS X is not a microkernel and hasn't been one since 10.0. It is a hybrid kernel called the XNU kernel. It's Mach microkernel based with some low layer BSD smothered on top.
It would be interesting to see how the original Mach microkernel runs on modern hardware. At the time, the context switching of the Mach kernel was making performance poor. But this was on 300/400 MHz machines.
It would be interesting to see how the original Mach microkernel runs on modern hardware. At the time, the context switching of the Mach kernel was making performance poor. But this was on 300/400 MHz machines.
Is it really so hard to gain traction? Just write a UNIX micro kernel and add a compatibility layer for Linux device drivers, then you are set.
Define "linux device driver". Doing what you ask could easily require including most of linux.
The exo-kernel guys tried to go a route that radically eases evolution. Normally an operating system tries to abstract and protect/multiplex.
They were writing a sort of microkernel, that only multiplexes/protects users from each other, but exported the raw hardware interface to userland. The abstracting part of the OS would be implemented as (possibly shared) shared libraries.
They were writing a sort of microkernel, that only multiplexes/protects users from each other, but exported the raw hardware interface to userland. The abstracting part of the OS would be implemented as (possibly shared) shared libraries.
I'm actually (well, my friends are doing most of the work now) still writing one: http://www.xomb.org/
Interesting. I visited the wiki and will have a deeper look into it later.
Let me know if you have any questions, or feel free to jump on #xomb on freenode. We usually have a few people idling.
Isn't that what l4linux does? ( http://l4linux.org/ )
A micro kernel doesn't necessarily mean that there will be less bloat. It just means that different parts of the functionality of the kernel are split up into different programs.
But those programs have to talk to each other, and this message passing overhead increases with increased functionality (more programs). So it seems likely that there would be a definite performance drop as the functionality of a micro kernel increased.
But those programs have to talk to each other, and this message passing overhead increases with increased functionality (more programs). So it seems likely that there would be a definite performance drop as the functionality of a micro kernel increased.
it's a monolithic kernel what did he expect.
Remember the Tanenbaum vs. Torvalds debate?
I wonder what Linus thinks about it now.
btw, here they are together.
http://lwn.net/images/conf/lca2007/lt-ast.jpg
Remember the Tanenbaum vs. Torvalds debate?
I wonder what Linus thinks about it now.
btw, here they are together.
http://lwn.net/images/conf/lca2007/lt-ast.jpg
I'm sorry, but do you have any idea what you are talking about?
How the kernel is organized has no meaning on how bloated it is. A microkernel can be just as bloated, in it the bloat is just not in the kernel itself, but in the processes providing the services a monolithic kernel would provide. If anything, a microkernel is always more bloated because of the extra code needed to do all the process sync.
Linux being a microkernel would make the situation worse.
(What we need to do is to start spending more time on cutting features.)
How the kernel is organized has no meaning on how bloated it is. A microkernel can be just as bloated, in it the bloat is just not in the kernel itself, but in the processes providing the services a monolithic kernel would provide. If anything, a microkernel is always more bloated because of the extra code needed to do all the process sync.
Linux being a microkernel would make the situation worse.
(What we need to do is to start spending more time on cutting features.)
Does bloat mean too many features? In that case I'd say those features are there because someone needs them. They don't all have to be loaded. In a monolithic kernel that has modules, load the ones you need. In a microkernel, load and unload as needed on the go.
Then there is the support issue. In Linux, all the modules must be maintained by the kernel team. This may constitute bloat as the team may have an unnecessary amount of code to maintain. Some modules may only be used by a few people. The issue isn't the features, but rather Linus's philosophy.
From his posts, it seems he like to keep changing kernel APIs as he sees fit. If you have many modules, this creates problems. Without a strict API, you will frequently break modules and thus create a lot of maintenance work. Fixed APIs are both very important and very good for large scale collaboration. Without standards like POSIX or the Windows APIs, we wouldn't be where we are today.
The second aspect to this is security. Say you built a very stable API and let others make modules as they need them. In a monolithic model, to maintain security you must audit every module. Thus for Linux to stay secure, the kernel team would need to either declare many less used modules as "tainting the kernel" or audit them all: a lot of work. In a microkernel model, the kernel team, so long as they designed it right, can let users build modules without audit.
Saying something has too much bloat is ambiguous to the point of being useless. Many people use that term simply as meaning slow, or a lot of code, or even poorly designed code. It's always better to describe things precisely. If it has too many features, say so. If it has bad design, then state that.
Then there is the support issue. In Linux, all the modules must be maintained by the kernel team. This may constitute bloat as the team may have an unnecessary amount of code to maintain. Some modules may only be used by a few people. The issue isn't the features, but rather Linus's philosophy.
From his posts, it seems he like to keep changing kernel APIs as he sees fit. If you have many modules, this creates problems. Without a strict API, you will frequently break modules and thus create a lot of maintenance work. Fixed APIs are both very important and very good for large scale collaboration. Without standards like POSIX or the Windows APIs, we wouldn't be where we are today.
The second aspect to this is security. Say you built a very stable API and let others make modules as they need them. In a monolithic model, to maintain security you must audit every module. Thus for Linux to stay secure, the kernel team would need to either declare many less used modules as "tainting the kernel" or audit them all: a lot of work. In a microkernel model, the kernel team, so long as they designed it right, can let users build modules without audit.
Saying something has too much bloat is ambiguous to the point of being useless. Many people use that term simply as meaning slow, or a lot of code, or even poorly designed code. It's always better to describe things precisely. If it has too many features, say so. If it has bad design, then state that.
Saying something has too much bloat is ambiguous to the point of being useless. Many people use that term simply as meaning slow, or a lot of code, or even poorly designed code. It's always better to describe things precisely.
The interviewer asked Linus about benchmarks that show the kernel getting slower and slower each year. Linus acknowledged that the kernel is in fact slowing down. I don't think they would be worrying about badly configured kernels, or kernels with unnecessary modules loaded. I don't know what features Linus is talking about that make a properly configured Linux kernel bigger and slower than it was ten years ago. Nor do I see any explanation or examples cited on this page. I wish someone who understands would give some examples of the feature creep they're talking about.
The interviewer asked Linus about benchmarks that show the kernel getting slower and slower each year. Linus acknowledged that the kernel is in fact slowing down. I don't think they would be worrying about badly configured kernels, or kernels with unnecessary modules loaded. I don't know what features Linus is talking about that make a properly configured Linux kernel bigger and slower than it was ten years ago. Nor do I see any explanation or examples cited on this page. I wish someone who understands would give some examples of the feature creep they're talking about.
The flip side of this is that it takes control out of the kernel teams grasp and, as a result, causes a lot of finger pointing. At least now you can say "Kernel team, this is broke, fix it" and someone is responsible. The architecture you are proposing allows everyone to hem and haw and otherwise pass the buck.
There are similar problems in Firefox. Blame the extensions, not the browser. API or none, bad programmers can get their code to affect a lot of people.
Of course, if you want to reduce bloat, compile your own kernel. Get rid of the modules you don't need. Is that a lot different that what you propose?
There are similar problems in Firefox. Blame the extensions, not the browser. API or none, bad programmers can get their code to affect a lot of people.
Of course, if you want to reduce bloat, compile your own kernel. Get rid of the modules you don't need. Is that a lot different that what you propose?
How the kernel is organized has no meaning on how bloated it is
Software organization can cause bloat if the feature can be implemented in another way. For example, there may be multiple ways to establish the same network connection.
I'm not defending microkernels, but some kernel functions in userspace is not bad. Dismissing microkernel concepts immediately is just as bad as questioning whether Linus was wrong in not selecting that architecture.
Software organization can cause bloat if the feature can be implemented in another way. For example, there may be multiple ways to establish the same network connection.
I'm not defending microkernels, but some kernel functions in userspace is not bad. Dismissing microkernel concepts immediately is just as bad as questioning whether Linus was wrong in not selecting that architecture.
> If anything, a microkernel is always more bloated because of the extra code needed to do all the process sync.
there are more than two types.
We have fretted recently because the plan9 kernel is struggling to fit on a floppy disk when loaded up as an installer with most things turned on.
The whole of plan9, kernel, userspace, 386 binaries & sources for 6 architectures fit into 200Mb uncompressed (and the whole shooting match compiles in 15 minutes).
Linux is a re-implementation of an OS that was already considered dead by it's maintainers.
"Not only is UNIX dead, it's starting to smell really bad." Rob Pike circa 1991.
see also "Sometimes when you fill a vacuum, it still sucks."
there are more than two types.
We have fretted recently because the plan9 kernel is struggling to fit on a floppy disk when loaded up as an installer with most things turned on.
The whole of plan9, kernel, userspace, 386 binaries & sources for 6 architectures fit into 200Mb uncompressed (and the whole shooting match compiles in 15 minutes).
Linux is a re-implementation of an OS that was already considered dead by it's maintainers.
"Not only is UNIX dead, it's starting to smell really bad." Rob Pike circa 1991.
see also "Sometimes when you fill a vacuum, it still sucks."
Does plan9 support 15 different archs with all of their quirks and subarchitectures? WiFi stack? Support for different power modes? Framebuffers? Kernel probes, high resolution timers, extended inbuilt security APIs?
The beauty of plan9 comes from the interface to the userland, not from implementation details and features. If you wanted to add al those features to plan9 I seriously doubt you could get it as lean and quick as Linux.
The beauty of plan9 comes from the interface to the userland, not from implementation details and features. If you wanted to add al those features to plan9 I seriously doubt you could get it as lean and quick as Linux.
Does plan9 support 15 different archs with all of their quirks and subarchitectures?
no. only 11
WiFi stack? yes, and bluetooth
Support for different power modes? yes, I think so, can't say I've ever used it. does "echo blank > /dev/vgactl" count?
Framebuffers? no, it is a 21st century os
Kernel probes, high resolution timers, extended inbuilt security APIs? yes
all in 13 syscalls
WiFi stack? yes, and bluetooth
Support for different power modes? yes, I think so, can't say I've ever used it. does "echo blank > /dev/vgactl" count?
Framebuffers? no, it is a 21st century os
Kernel probes, high resolution timers, extended inbuilt security APIs? yes
all in 13 syscalls
Compare Linux and QNX (http://en.wikipedia.org/wiki/QNX)
and tell me which one is bloated.
and tell me which one is bloated.
Do QNX provide the same features as linux?
You can add "features" to QNX to make it comparable to Linux. The only difference is, since it's a microkernel, adding a feature to QNX won't make the kernel bloated. and that is the whole point i am trying to make.
"adding a feature to QNX won't make the kernel bloated"
Yeah, you have a piece of code named "the kernel" which you can point at and tell that it isn't bloated. But you can do this in Linux too, if you compile everything as loadable modules. That is just creative accounting of the bloat.
Yeah, you have a piece of code named "the kernel" which you can point at and tell that it isn't bloated. But you can do this in Linux too, if you compile everything as loadable modules. That is just creative accounting of the bloat.
I disagree. Sure it's bloated if you need / want all the features that create the bloat. However, if there are user's who require very few features then they end up with a very slim system.
It's only marketing spin if you will always need all of the features in order to do anything meaningful.
It's only marketing spin if you will always need all of the features in order to do anything meaningful.
After that reply, I find myself wondering if you actually know what the "Linux module system" is, because there is no difference between what you claim is an advantage and what Linux actually has.
Are you still having this debate with a purely academic definition of "monolithic" vs. "micro" kernels? Because neither of them exist anymore, and haven't for a long time; it's like CISC vs. RISC, in that arguing about it today is really missing the point since most everything is a mix. You need to address what Linux actually is, and what real microkernels exist, and what real performance they have, not regurgitate boring arguments from the 1980s that have simply been superceded (rather than one side "winning").
In fact, this goes for all you other commenters still having this argument. "Compare and contrast a microkernel running on CISC vs. a monolithic kernel running on RISC. Which will run best on a top-of-the-line Amiga, and how can this be best leveraged into flaming those who disagree with you?"
Are you still having this debate with a purely academic definition of "monolithic" vs. "micro" kernels? Because neither of them exist anymore, and haven't for a long time; it's like CISC vs. RISC, in that arguing about it today is really missing the point since most everything is a mix. You need to address what Linux actually is, and what real microkernels exist, and what real performance they have, not regurgitate boring arguments from the 1980s that have simply been superceded (rather than one side "winning").
In fact, this goes for all you other commenters still having this argument. "Compare and contrast a microkernel running on CISC vs. a monolithic kernel running on RISC. Which will run best on a top-of-the-line Amiga, and how can this be best leveraged into flaming those who disagree with you?"
linux kernel is still bloated even if you compile everything as a loadable kernel module. (except rtlinux)
But adding the features means adding them to userland processes. While this technically doesn't make the kernel bloated, it still means the bloated code has to be run, and has to occupy L1i. Having them in other processes only means they will eat even more cpu, as you have to use time to sync the processes.
you're wrong on several points i don't know where to begin. sorry i don't agree with you.
who of them should have had on the t-shirt *Im_with_stupid ?
Linus is getting old.
Out of context link bait drivel.
How so?
> "Uh, I'd love to say we have a plan," Torvalds replied to applause and chuckles from the audience. "I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary.
> "Uh, I'd love to say we have a plan," Torvalds replied to applause and chuckles from the audience. "I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary.
Does anyone know what icache is?
instruction cache?
Yes: instruction cache. Big programs are slow programs.
That's too simplistic. Programs with hot code sections that don't fit in icache are slow programs. If your program is huge but you spend all your time in a small fraction of code (typical) that fits in icache (no idea if that's typical), it's fine from a cache performance perspective.
I think joechung is more right here, icache in this instance means inode cache; the CPU D-Cache and I-Cache (not to be confused the file-system related dcache and icache for dentry cache and inode cache respectively) are of fixed size and you couldn't have "bloat" there. The FS inode cache is more likely to be bloated given the larger upper limit for disk storage compared to CPU cache.
No way, for three reasons. (1) Saying "icache" and meaning anything other than "instruction cache" would be an obvious recipe for confusion, and Linus is not stupid. (2) It makes excellent sense with the obvious "instruction cache" meaning: "our icache footprint" means "the number of instruction cache lines occupied by kernel code". (3) It makes no sense with the "inode cache" meaning: how could a growth in the amount of code in the kernel possibly have anything much to do with the size or the occupancy of the inode cache?
And you would be absolutely right. Thanks for the good analysis :-)
...Windows usually gets the bad wrap for bloat...
At the very least, badly edited.
At the very least, badly edited.
Does anyone know how much redundant code is in Linux right now? Would finding, isolating, generalising and merging it be a good way to start? I know of examples of this happening, e.g. libata taking over a lot of the old 'ide' drivers; the many attempts at unifying the various WLAN subsystems and drivers.