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.
Remember the Tanenbaum vs. Torvalds debate?
I wonder what Linus thinks about it now.
btw, here they are together.
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.)
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.
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.
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?
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.
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."
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.
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
and tell me which one is 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.
It's only marketing spin if you will always need all of the features in order to do anything meaningful.
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?"