6 ms·
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
by ecq 17y ago
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 http://lwn.net/images/conf/lca2007/lt-ast.jpg
- Tuna-Fish 17y agoI'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.)
- ecq 17y agoyou're wrong on several points i don't know where to begin. sorry i don't agree with you.
- ecq 17y agoCompare Linux and QNX (http://en.wikipedia.org/wiki/QNX http://en.wikipedia.org/wiki/QNX) and tell me which one is bloated.
- ido 17y agoDo QNX provide the same features as linux?
- ecq 17y agoYou 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.
- Tuna-Fish 17y agoBut 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.
- praptak 17y ago"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.
- rapind 17y agoI 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.
- jerf 17y agoAfter 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?"
- tensor 17y agoDoes 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.
- stinkytaco 17y agoThe 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?
- dkarl 17y agoSaying 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.
- anonjon 17y agoA microkernel is in theory not bloated. The whole point is that you put a lot of the 'features' off into the separate modules, meaning that pretty much the only thing that the kernel takes care of is process sync. (Process sync happens in both monolithic and microkernel designs). The problem is that no one has figured out how to properly stratify the design so that the process sync code is suitably general for all of the different modules, and is still efficient. (Efficiency, not bloat, is the problem with microkernels). Linux being a microkernel is orthogonal to any bloat situation.
- skwiddor 17y ago> 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."
- Daishiman 17y agoDoes 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.
- skwiddor 17y agoDoes 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
- acg 17y agoHow 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.
- morphir 17y agowho of them should have had on the t-shirt *Im_with_stupid ?