According to Linus, Linux Is "Bloated" 639
mjasay writes "Linus Torvalds, founder of the Linux kernel, made a somewhat surprising comment at LinuxCon in Portland, Ore., on Monday: 'Linux is bloated.' While the open-source community has long pointed the finger at Microsoft's Windows as bloated, it appears that with success has come added heft, heft that makes Linux 'huge and scary now,' according to Torvalds." TuxRadar provides a small capsule of his remarks as well, as does The Register.
Re:Obvious weird Windows comparison (Score:4, Informative)
Mostly drivers. Which are kind of irrelevant with regard to bloat because if you so desire, you can build a kernel that only contains drivers that you need. I realize that no distro can realistically do this with their pre-compiled kernels however, no one is going to compile support for everything that the Linux kernel is capable of supporting in a single kernel either.
I still think it is funny that Linux is considered "bloatware" when Windows will still use several times the same resources as Linux. For instance, take any desktop distro (Ubuntu, Fedora, etc...) and a complete installation including multiple desktop environments, browsers, office suites, etc... still takes up less disk space, memory and CPU than does a bare installation of Windows Vista/7.
Seems to me that "bloat" is completely relative and arbitrary.
Re:Translation: (Score:3, Informative)
the difference is
make menuconfig & modprobe -r
bloating in the windows kernel is compulsory!
bloat in the linux kernel is optional and much of it can be removed at runtime, ofc if the whole kernel is getting worse every release then that is bad. So before making comparisons to windows it's important do remember that an extra 10% of something small (once you trim the crap you don't need) is less than an extra 10% of something big (because you can't)
Re:Problem (Score:5, Informative)
Comment removed (Score:5, Informative)
Re:Compile it yourself! (Score:3, Informative)
was Tanenbaum right?? (Score:2, Informative)
Re:Are too many added drivers really the cause? (Score:2, Informative)
http://www.top500.org/stats/list/33/osfam [top500.org]
Perhaps you should consider moving from your planet to the real world.
Re:Problem (Score:3, Informative)
It's the same as any other volunteer work, you have absolutely no obligation to do the work but if you don't then your not going to be invited back and your work will be refused.
Re:Linux Need To Move On To GPL v3 (Score:3, Informative)
And is also utterly impossible while there is a single line of GPLv2-only code in it that the author doesn't give permission for, or whom is dead. There's quite a lot of code like that, there's a lot that can't be traced to an author, there's a lot of authors that won't give their permission, there's a lot that *can't* give their permission (employers, etc.) and there's so much of it that recreating it from scratch without reference to the original code would actually take longer than just starting a GPLv3 kernel from scratch.
And this has been discussed to death before. Ain't gonna happen - not out of some inate personal reasoning, but sheer impossibility.
Re:Are too many added drivers really the cause? (Score:3, Informative)
What you write makes no sense what so ever. The kernel provides interfaces between its core services and the drivers. It doesn't matter how many drivers exist, so long as they use the proper interfaces. All kernels work this way.
Re:Are too many added drivers really the cause? (Score:2, Informative)
Allowing untested third party drivers will create unstable system. When drivers are in kernel tree, they are be reviewed and fixed. If hardware manufacturers write and maintain drivers in own software repositories, drivers will be untested, unmaintained and crappy.
Re:Are too many added drivers really the cause? (Score:5, Informative)
Re:I've met the enemy (Score:5, Informative)
Problem is the "bloat" is in code only not in the running kernel.
I can easily compile a linux kernel that runs in very little space on a super slow processor and it screams.
Problem is the "bloat" that Linus is talking about is simply plain old kludgy coding done to get it out the door faster. Adding features need to stop and all kernel coders need to work on cleaning things up. It's the sucky part of the job that nobody wants to do, but it needs to be done. I've seen the insides of some kernel modules that will make your toes curl in fear as they are early prototypes pre-alphas at best.
Re:Microkernels. Hmm... (Score:5, Informative)
Yes.
QNX compared to a hand tuned embedded linux install is in fact Slow.
QNX on the other hand is a faster deploy time, you dont have to spend time wrapping your own embedded distro for your product, just pay the QNX license fee and you're off.
Back 4 years ago I proved that by making my own linux install for a company product and kicked out the QNX system. It ran far faster, but they did not want to pay to support the custom OS so we stuck with QNX, and they already paid for the QNX licensing.
Re:But, but but... (Score:4, Informative)
Heh, read the stable_API_nonsense.txt file in the kernel source. Here's an html version:
http://www.kroah.com/log/linux/stable_api_nonsense.html [kroah.com]
Re:Obvious weird Windows comparison (Score:3, Informative)
(for example, flash just crawls when I am viewing it thru firefox in ubuntu).
This is mainly because Adobe doesn't spend nearly as much time or money on the Linux port of flash.
Re:Problem (Score:3, Informative)
I've written a few proprietary kernel modules, and I don't think this problem is as significant as you believe. I found that it was pretty easy to take a stock kernel, build my driver to target it, and then move forward and build a set of version-dependent macros for the different KBI changes as they crop up. It's not like they change the entire KBI every day, and unless you're part of some big company you're not going to be targeting every kernel version in existence (and if you are in that circumstance, you'd have enough people to handle this task).
Re:Problem (Score:2, Informative)
Let's not forget Mozilla -> Firefox
Re:Bloat is often moot (Score:3, Informative)
I'm afraid that hardware detection may well be required, because critical services (such as NFS exports or MySQL) which rely on mounted partitions in most large-scale environments must have those directories already mounted before running 'exportfs' or before starting the relevant services, or they can create incredible chaos. And the flushing of /tmp/ is tricky: it's much safer to do at a well-defined init step, before the other services are running, and not potentially scrub weird components out from under people. It's not that people shouldn't write these components more sensibly: it's that they don't bother because init scripts are often an afterthought. I suspect you've not personally run into some of the potential adventures of /var/lib/mysql not being mounted when you start the MySQL daemon. It's an adventure.
I completely agree with you about material being in the wrong init levels frequently, and the need for dependency management. (RedHat has some old mistakes in handling wifi devices _after_ network initialization, which causes real chaos.) And forcing network file systems such as NFS or CIFS to wait until the network is running would make complete sense.
Re:Obvious weird Windows comparison (Score:3, Informative)
Unless Windows 7 has changed radically how drivers work under Windows, those usually require user installation on drivers. So, in different words, you're bullshitting.
Depends on what version of Windows you're using as a baseline, but I can say with some certainty: yes it's changed, because you're completely wrong.
I've yet to have to manually install a driver in Vista or Windows 7, and even XP did a pretty damned good job of finding all my drivers a few years ago when I re-installed it. (IIRC, the one it was missing was my USB wifi dongle, everything else it got fine.)
I have a radical idea: maybe you should actually *use* Vista or Windows 7 before slamming it. Just a thought.
Re:Bloat is often moot (Score:3, Informative)
Things like device drivers can be easily diked out. When it comes to stuff like memory managers, VFS, CPU schedulers, basic networking, so on and so forth, I imagine that the bloat hurts the embedded guys more.