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.
Problem (Score:5, Insightful)
"Okay, so the summary of this is that you expect that 12 per cent to be back to where it should be next year, and you expect someone else to come up with a plan to do it," joked Bottomley. "That's open source."
That is also the problem. Everyone adds pieces and eventually it starts to become a mess. Then someone else should fix it.
Re:Problem (Score:5, Insightful)
That's all software.
Re: (Score:2)
That's called technical debt, it happens in every project: open, proprietary, big, small, one developer or a 100.
Re:Problem (Score:4, Insightful)
But when its open source, it's easier to think that maybe I cant be bothered to look at this now, someone else can do it. When its proprietary software and you get the assignment to look at it, you pretty much have to do it.
Re:Problem (Score:5, Insightful)
Properly managed opensource projects deal with this appropriately, some do not.
Properly managed proprietary projects deal with this appropriately, some do not.
Re: (Score:3, Insightful)
How does that work? In a proprietary project if your boss says "do this" you either do it or find another job. In an open source project you could just flame the hell out of the guy that told you on the public mailing list and carry on working on something else.
And in a proprietary project if customers want something fixed they can threaten to not pay which in even the most incompetent company will tend to make your boss tell you to fix it. In open source that mechanism does not exist.
Re: (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: (Score:3, Interesting)
properly managed (volunteer) open source projects deal with this appropriately, some do not.
I say "(volunteer)" because I think I recall some open source projects having only certain contributors, as opposed to anyone.
Re:Problem (Score:4, Interesting)
In FreeBSD, you chose to accept a project. If you fail to perform, you are replaced with another volunteer. It doesn't matter if you're a core committer or a port maintainer, it all works that way. There are occasional problems but overall a successful approach. Many other opensource projects do the same. That's why hierarchies work in opensource--they hold people accountable just like in a proprietary project.
Re:Problem (Score:5, Interesting)
It gets done because ultimately somebody says "Fuck this, I can't work on this bloated codebase any longer. We're refactoring, guys!"
Then, if the old lead dev / maintainer / admin doesn't like it, a fork happens...
Projects where this has happened before: The kernel itself, several times (as well as various subsystems, again several times), X (XFree to XOrg), KDE (2-3, 3-4), Amarok (1.x to 2.x), SodiPodi -> Inkscape, Firefox from 2 to 3... These are off the top of my mind, of course - there are lots more.
Of course, there are some cases where this process has failed. I don't think the failure rate is any higher (or lower) than proprietary projects, though...
The incentives are different, but they exist, nevertheless...
Re:Problem (Score:5, Interesting)
Precisely. The grandparent is forgetting that, in the proprietary world, the scenario you described can't happen. I can't go to my boss and tell him, "Screw this, I'm going to spend the next month refactoring our messy code, rather than adding new functionality." However, I can do that in an open-source project.
Re:Problem (Score:4, Funny)
In a proprietary project if your boss says "do this" you either do it or find another job.
Or you make excuses, pass the buck, and sponge off your colleagues until the next reorg.
Re:Problem (Score:5, Insightful)
The same way people in raid guild do what they're supposed to in raids even though it's only a game and raid officers can't do anything to you really; or members of Civil Air Patrol follow military customs and courtesies toward their officers despite those officers having no actual UCMJ authority; or people in SCA listen to the nobles of their "Baronies" despite those people not having any real world authority. When you join a group or a project, you agree to abide by the rules of the group or project. If you eventually find that you can't, you generally either leave or are forced out. if the project lead on a properly managed project asks you to do some boring grunt work, you either do it or find a new project and someone else will be asked to do the work.
If the project is generally fun or personally beneficial for you to work on, you'll do the grunt tasks you're asked to do, because otherwise you'll eventually be off the project. If the project wants to keep it's user base (and most do) it'll fix as many problems as it can to keep the users happy.
Re: (Score:3, Interesting)
How does that work? In a proprietary project if your boss says "do this" you either do it or find another job
You don't work in software, do you? I've worked at 5 different companies as a software engineer, and in all of these jobs I've never had my boss tell me to fix the crappy parts of the software I was assigned to work on. Actually in neither of them my boss even took the time to look at the code itself. It always was "[we | customer x ] needs [feature | bugfix] y within z [hours | weeks | days]. Make it happen."
Re: (Score:3, Insightful)
How does that work? In a proprietary project if your boss says "do this" you either do it or find another job.
Sure... You're given an assignment and you basically have to do it. But somewhere along the line somebody has to decide what is a priority and what isn't. Somebody decides what actually gets done. And it doesn't really matter if it's a proprietary project or not - stuff slips through the cracks.
You think a company is going to drop everything to refactor some code just because it's getting a little long in the tooth? Even though everything works? You think a company is going to put a whole lot of time
Re:Problem (Score:5, Insightful)
That's false of course:
1) the deciding factor for project management is the non-commercial/commercial status of a project, not the closed/open state of the source.
2) for non-commercial projects, both developers 'goodwill' and proper management are needed to avoid bloat; whereas for a commercial project only proper management is needed (as the management decides where the money will go).
Note that the Linux kernel is a blend of non-commercial and commercial projects as many developers are paid to work on the Linux kernel and many aren't.
Re: (Score:2)
Re:Problem (Score:5, Insightful)
I agree.
The people hating messes are the developers which have to look at this day by day. Cleaning up code is never something managers care about - its always driven by developers with a sense for order and simplicity.
That means that Open Source software has a higher chance of getting cleaned up than propietary software, because there you have a higher percentage of truly motivated developers and no managers to bug them. Sigh...
Re:Problem (Score:5, Insightful)
Cleaning up code is never something managers care about
Most managers care a LOT about cleaning up code. It's a waste of time in their eyes and most will write you up for wasting time if they discover that you are doing it.
They wanted it done last week, cleaning up code misses deadlines and is a waste of time as far as management is concerned.
Re:Problem (Score:5, Funny)
C++ makes sure nothing gets to become a real mess
You're funny. Can I have you come and perform for my birthday party?
Re:Problem (Score:5, Interesting)
If only there was somebody at the top deciding what to let it/reject in such a way to keep the bloat out! While I am a linux/gpl fanboi, i think the bsd distros don't have this problem because they have much stricter people at the top of their kernels, and i think this is yet another sign that Linus should not be the only one running the show. If Linus isn't producing the kernel desktop users need (it's bloated, has the wrong scheduler, etc) then distros should step up and work around the problem GIT makes it very easy for them to start elsewhere, their previous release tree, mm tree, etc and add the patches they require!
Before you jump at me and say that this will ruin Linux by duplicating work, it will still be the (essentially) same code that goes into the pool, its just the administration that changes, and producing incompatible distro's isn't a problem as the userspace API is fairly stable and changes to the ABI for prop drivers can be agreed on by the major players (or they can just follow linus's changes to them, or go crazy and stabilise the ABI so that the prop drivers work)
Re:Problem (Score:5, Informative)
Re:Problem (Score:5, Interesting)
Constant changes, i.e. lack of stable KBI (kernel binary interface) does not help.
Eventually keeping your incompatible stack is easier than keeping up-to-date with latest and "greatest", especially if you happen to test your code.
Re: (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 par
Re:Problem (Score:5, Interesting)
The BSD distros do not have this problem, but it's not just the strict top-down management.
It's the users.
Linux is trying to court three major user groups wih the exact same kernel, and trying to be all things to all people. The big corporations who make up most of the Linux coding/funding/purchasing want better server performance (more processors, more RAM, etc). The desktop guys want better desktop, laptop, and netbook experiences (3D graphics, sound cards, processor power scaling). The third are the end-users who contribute almost nothing but want the system to be easy and simple.
BSD however, really only has one user base - and they largely want the same thing. Stability, security, and performance. So all the cute little desktop friendly stuff that Linux keeps adding and all the server-specific stuff that Linux keeps adding aren't there. There's just the one major direction.
Or at least that's my experience, and I've been using it since 2.x.
Re:Problem (Score:4, Interesting)
I'm not understanding something. If BSD lacks both the "desktop friendly stuff" and the "server-specific stuff"... then what exactly are BSD-based systems doing so stably, securely, and speedily?
Re:Problem (Score:5, Funny)
Re: (Score:3, Insightful)
Why should Linus focus for Desktop Linux. It is a dead horse... Deal with it. Its a Dyeing market. Let Microsoft go down with that ship. Linux should be designed better for cloud/distributive processing, and server stuff. We are getting to a point we don't need desktops we need a thin client that can connect to the network. And let someone else do the work.
LOL
People have been denying the need for and predicting the death of desktop computing since before desktop computing existed (for at least 50 years, http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote [wikipedia.org]).
The only thing that has happened is that computing has become more and more pervasive as people hold more computing power in their hand than existed in the computer room 50 years ago.
If desktop computing ever goes away, it will be because the desk is gone. People will still have their own computer
Re: (Score:3, Insightful)
Why should Linus focus for Desktop Linux.
I'm not saying he should, but desktop distro's certainly need to!
Re:Problem (Score:4, Insightful)
Why should Linus focus for Desktop Linux. It is a dead horse...
And in some part is a dead horse thank to Linus himself.
Point is that "perfect kernel" from system developer POV, is "piece of useless junk" from POV of application developers.
Sound interface is at best dysfunctional. Video acceleration is constantly "under construction" (redone 5th time now or so). Real-time timers required for smooth multimedia and games are still at large.
Just look at Apple's Mac OS X on how problems have to be handled. Instead of debating about what should/shouldn't be in "perfect kernel," people concentrate their work on areas which actually relevant to application developers and of benefit to end users. Apple took the line "if we don't do it who else" while Linus' official line is something like "do it in userspace" or "do not care. don't have to. I'm system programmer."
Re: (Score:3)
by Jurily (900488) Alter Relationship on Tuesday September 22, @09:38AM (#29503123) While I am a linux/gpl fanboi, i think the bsd distros don't have this problem because they have much stricter people at the top of their kernels, and i think this is yet another sign that Linus should not be the only one running the show. Heh. BSD doesn't have this problem because nobody cares enough about them to contribute enough code. You don't really have to think about feature creep at 3 patches per week.
More FUD, thank you. BSD has a large and dedicated fan based and rather than just put any code willy nilly into the kernel it is carefully evaluated. FreeBSD powers the root nameservers and OpenBSD is arguably the most secure operating system in the world. With reputations like this to uphold, often state of the art features are not added to maintain stability and security. No need to start a flamewar. Both BSD and Linux would be better off with cooperation, rather than conflict. Especially because Li
Simple solution (Score:2, Insightful)
That is also the problem. Everyone adds pieces and eventually it starts to become a mess. Then someone else should fix it.
Or we can just use an old version. Unlike to the case of proprietary software, we are not being forced to upgrade to "bloated mess".
Re:Simple solution (Score:4, Insightful)
Clearly whoever modded you up has never tried what you are suggesting. I can only name a handfull of open source projects that backport security fixes to old versions and of those, they only backport to versions a few years old.
In fact, I'd say the longest lived "old version" is probably Apache 1.3. The 2.x series has been out for, what, forever and yet they continue to push out fixes for 1.3 (last was Jan. 2008).
I'd wager the biggest complaint I have with most open source is the a) dont understand what true stability means and as a result they b) rarely support old versions. It was one of the prime reasons I switched to FreeBSD. If I install FreeBSD 6.2 today, I know I'll get security fixes for at least a good half decade and probably a bit more if I track the 6.x series.
Yeah yeah yeah, debian, yeah yeah... but dont get me started on the other reasons I switched (cough crappy docs, cough, crappy unstable kernel, cough
Re: (Score:3, Interesting)
Erm actually its quite the opposite, windows XP got security patches for years, i doubt you'll find a safe 2.6.8 (~2004) kernel about. Even "slow" distros like debian only backport security fixes for 3 years after that you have to upgrade, or start maintaining your own kernel.
Re:Simple solution (Score:4, Funny)
Yea, I was rooting around in your system just the other say. You seem to be completely frugal when it comes to purchasing new software. On a plus side, your system is completely useless to me outside of just exploring around it a little. Good call and staying arcane.
I've met the enemy (Score:2, Insightful)
I've met the enemy and they is us.
Re: (Score:2)
I see where you are coming from, but I'll offer that bloat isn't necessarily *bad*. Personally, I've thought of Linux as somewhat to rather bloated for 5 or 6 years.
It just means there are a lot of available features. Many of which people need.
Bloat isn't a problem. In software, it's in a lot of places because that's what you need many (but not all) cases that target a wide audience. The problems come in two flavors. 1) the inability for an individual to turn off the bits he or she doesn't need, and 2) lack
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:I've met the enemy (Score:5, Insightful)
Until it causes system instability, slow performance, or increases the size of the code without adding any new features or fixing a problem. Bloat can become a problem, but it doesn't have to be. I thought I would just point that difference out because "isn't" seems to be an absolute which it shouldn't be.
Bloat is often moot (Score:2)
Re:Bloat is often moot (Score:5, Insightful)
Torvalds' use of the term "Bloated" in this case refers specifically to a loss of performance and an increase in size and memory usage, not of confusion.
I think there are two (competing) goals for the Linux kernel as a whole (well, there are as many goals as there are developers, of course, so the two competing goals are more of a continuum).
On one side, there is a desire for the Linux kernel to support more features so distros can be built to be more like popular mainstream operating systems like Windows and Mac. Ease-of-use, a pleasant user experience, separation/insulation from the dreaded Command Line, pretty graphics, massive hardware support, and support for more "oddball" configurations like multiple screens, etc. So it's desirable to have lots of driver support and lots of hooks into the operating system to support fancy stuff.
On the other, there is a desire for Linux to be small, sleek, and fast, particularly for embedded projects.
The former has been running the show for a while, and I think that's healthy and positive, but the kernel has gotten larger and slower at its basic job. For desktop users, this is good news since a lot of things that had to be done at "higher" levels can now be accomplished directly in the kernel, so they might actually have a faster user experience, and they've got resources to burn since most PCs are specced out for Windows, so Linux has a lot of spare growing room in that hardware.
But for embedded/minimalist supporters, it means they need to add more hardware to their machines to support the now-larger kernel, chock full of features they'll never need or want.
Re: (Score:3, Insightful)
On one side, there is a desire for the Linux kernel to support more features so distros can be built to be more like popular mainstream operating systems like Windows and Mac. Ease-of-use, a pleasant user experience, separation/insulation from the dreaded Command Line, pretty graphics, massive hardware support, and support for more "oddball" configurations like multiple screens, etc
I risk sounding like Stallman here, but in this case the distinction actually matters. We're discussing the kernel, not the OS.
Re: (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.
Re: (Score:3, Insightful)
Linux today does not boot significantly faster than it did 15 years ago. That's bloat.
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
What? No, that's not the kernel. That is:
> The BIOS - take a look at the LinuxBIOS or OpenBIOS work to see where that can be improved. But oh, my dear goodness, it can be improved.
> Incredible masses of new hardware that do need detection and configuration at boot time. That's been a sore point: it takes time to scan for all that hardware, and you can optimize it by leaving out tools, but people do like having their network cards and USB drives and graphics tablets work automatically at boot time. Tha
Re: (Score:3, Interesting)
init scripts especially are rather idiotic, and it's a testament to how much crap Windows is doing that Linux distros manage to load in roughly the same time.
It's especially dumb when things that could start after the system has finished booting, like samba and ssh, instead start first.
Likewise, driver detection. Um, no, you don't do that on startup, unless it's a first-time boot. You do that when the system is running, which means the very first time someone boots with that fancy new sound card the start
Re: (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 unde
Re: (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: (Score:3, Insightful)
What do you think is extra? What would you remove? Are you able to remove it?
For Ubuntu, I can easily answer these questions because the system is transparent
and I can act on my preferences without even being a developer because the system
is flexible, modular and open.
I can even get rid of a lot of Linuses kernel code because there's been a nice shiny
happy build GUI included with the kernel since the 1.x days.
So, Andrew Tannenbaum (Score:5, Funny)
Re: (Score:3, Interesting)
Basically, my thoughts on seeing the headline were "No shit, Sherlock", followed by "I guess Andy Tanenbaum was right, eh Linus?"
Linus's approach has always been "What the hell, throw it in the kernel". The result is that if you try running Linux on something like a Nokia N800 or N810, where there's only 128MB or 256MB of RAM, it crawls and thrashes even with the swap on flash memory.
Meanwhile, Tanenbaum's MINIX requires 16MB of RAM [minix3.org]. Good luck getting any kind of Linux to load in that amount of space.
Obvious weird Windows comparison (Score:4, Insightful)
Of course nobody refers to Windows' kernel when people call it bloatware. Linus however is not talking about Linux as a distro or an operating system, it's just the kernel that's too bloated in his view. And with over 11 million lines of code, it's hardly even a flame.
Now if only he had developed a microkernel instead...
Microkernels. Hmm... (Score:4, Insightful)
"Now if only he had developed a microkernel instead..."
It would be bloated AND slow.
But hey, it would look pretty in a high level UML diagram.
Re:Microkernels. Hmm... (Score:4, Interesting)
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:Obvious weird Windows comparison (Score:4, Insightful)
Well, if you just take a look at this monster [makelinux.net] I think you'll quickly will come to the conclusion that even providing the most basic functionality can lead to something quite complicated. And of course, "basic functionality" in 2009 means something else entirely when compared to 1991 when Linux started out.
It should be noted that of course the module-system works pretty good to keep things organised, so no developer needs to dig through millions of lines of code to make a few tweaks. But it's a monster nonetheless.
Re: (Score:2)
er... um... drivers are distributed with the kernel and are probably counted in the kernel 11MLOC metric.
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: (Score:3, Funny)
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.
I'm sorry, but you seem to be severely misinformed regarding the performance of modern Linux distributions vs Windows 7 on modern hardware. Yes, sure, you can use something like Debian and it will run faster than Windows 7 out of the box, but at what cost?
Re:Obvious weird Windows comparison (Score:4, Interesting)
I would like to believe this, but it hasn't been my experience.
I can tell you this: Vista (!!!) appears to run smoother and with a more-responsive UI on my laptop than when I try a default ubuntu install on the thing (for example, flash just crawls when I am viewing it thru firefox in ubuntu).
It has been my experience in the past that every time I install linux, it runs slower (or at least appears to run slower) than the windows install on the same machine.
I'm not trying to troll. Maybe someone could explain this phenomenon to me. I actually *want* to switch, but I can't if the alternative is providing a degraded experience.
Re: (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: (Score:3, Interesting)
also In many cases video drivers are not as well optimised either.
Over the years I have found that Windows feels snappier on an unloaded system whereas Linux generally tends to feel better on a machine under heavy load.
Re: (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
Re: (Score:2)
Linux is bloated... (Score:5, Funny)
Re:Linux is bloated... (Score:5, Funny)
It's easy to maintain your girlish figure when you are embalmed.
A Few More Bits of His Talk (Score:5, Interesting)
Uh, I'd love to say we have a plan. 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. I mean, there is no question about that. And whenever we add a new feature, it only gets worse.
And also:
He maintains, however, that stability is not a problem. "I think we've been pretty stable," he said. "We are finding the bugs as fast as we're adding them -- even though we're adding more code." Bottomley took this to mean that Torvalds views that the current level of integration acceptable under those terms. But Mr. Linux corrected him. "No. I'm not saying that," Torvalds answered. "Acceptable and avoidable are two different things. It's unacceptable but it's also probably unavoidable."
I think that's very important to note. His quote by itself is very self-loathing but to add that tit's unavoidable really says a lot. You want to be popular? You have to satisfy more people and in doing so you become more bloated. He does maintain that Linux remains stable and that's usually the biggest problem I have with bloat. It decreases stability. I don't think there's any reason to get excited about level headed rational and reflection.
Re:A Few More Bits of His Talk (Score:5, Funny)
but to add that tit's unavoidable really
I'm more of a bottom kinda guy myself, but hey, I get it.
Re: (Score:2)
You have to satisfy more people and in doing so you become more bloated.
So is this why I became so fat? And I thought it was all the food and beers. Damn those girls!
Specialist's bloat is not user's bloat (Score:5, Insightful)
What "bloat" in software means to LT as the high priest of the kernel and what bloat means to me as a user are two different things.
To a user, bloat means awkward, slow, inefficient, and needlessly large (if my storage space or bandwidth is limited). But these are all *perceived*. I don't perceive Linux to be bloated.
In fact, I find *NIX with almost any window manager to be the most efficient computer OS I have ever used. Linux is the best of them, despite being a clone of the UNIX userland.
If an OS can boot from a floppy or small USB key and be totally usable, it is certainly not bloatware. Rewrite the Linux userland in MONO or Java and then we'll talk about bloat.
Re: (Score:3, Insightful)
Funny, I find Open Office to be bloated compared to MS Office.
KDE/Gnome to be bloated to XP.
That's why I use the best tools for me: MS Office and XP (in that order)
It's not perfect, far from it, but works the best for me.
KDE, Gnome, OO just feels like molasses everytime I try, and don't misunderstand:
I've spent years under KDE, but given up on it every time after spending ungodly hours fixing what should work out of the box.
OO has awful UI. I can't use it. Feels like a program from the early 90's which you
Re:Specialist's bloat is not user's bloat (Score:5, Interesting)
Java is actually damn fast if you keep the JVM running at all times. Even wimpy mobile devices like the Kindle can run Java fine. The Kindle is just Linux + JVM on a puny ARM processor.
Re:Specialist's bloat is not user's bloat (Score:4, Interesting)
It's mostly because Linus isn't talking about the "Linux" you're talking about -- that is, a whole Linux distribution, as compared to other OSes.
He's talking about Linux itself, compared to what he thought it would be.
Basically, the original plan for Linux was never to be an OS in its own right, but to be just another POSIX kernel, one highly-tuned for the then state-of-the-art 386 chip. Even porting to PowerPC was never part of the plan. The fact that this kernel is so flexible and featureful -- that it has drivers for damned-near everything, that it runs on everything from cell phones to mainframes, from set-top boxes to thousand-machine clusters, from wristwatches to... Yeah, all that portability necessarily makes it bigger than what would strictly be needed for one architecture and a limited set of hardware.
It's also got to do with things like multiple schedulers, and it explains something of why Linus wanted one scheduler to rule them all -- the idea of pluggable schedulers is ludicrous, compared to the original idea of one kernel per platform, where you wouldn't have a Linux app, you'd have a Posix app that would run on Linux on x86, and on something entirely different on PPC, and yet another kernel on ARM. If it had been done that way, at least in theory, all of those kernels combined should've still been smaller than Linux currently is.
Are too many added drivers really the cause? (Score:5, Interesting)
Re: (Score:3, Insightful)
Comment removed (Score:5, Informative)
Re: (Score:3, Interesting)
I think the GPs concern is not about performance but about maintainability. Being a module doesn't really affect that. When the driver API changes every driver has to be changed. The more drivers the more work has to be done. What adds to this problem is that these APIs really do change in Linux.
Re: (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:5, Informative)
Re:Are too many added drivers really the cause? (Score:4, Insightful)
I have a laptop HD with my copy of Ubuntu running on it. I popped it into another model of laptop yesterday, (from a Dell D630 to a Lenovo T400) everything worked fine.
I plugged a printer in a week ago, worked fine. Connected my Cannon camera, it popped up and asked if I wanted to import the photos. I plugged in my wife's ipod, and it asked if I wanted to open Rythmbox.
On windows, I would have had to go to countless websites, download drivers (or itunes) install, and troubleshoot. With linux, all of that just worked. On XP it was a pain in the ass to switch between AHCI and compatibility mode on my laptop. With linux, I can switch whenever I want.. it just works..
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]
Reply (Score:2)
Re: (Score:2)
Compile it yourself! (Score:2)
It has been a long time since I needed to compile my own kernel and modules, but I can't imagine things have changed that much over the years. Seems to me that when compiling the kernel, you can select out a LOT of hardware support and other options that aren't necessary for that particular installation. It would surprise me to find that the kernel still fits on a floppy disk though.
Re: (Score:3, Informative)
Pick two (Score:5, Insightful)
(2) Compact/optimized
(3) Fast to market
Pick any two...
Re: (Score:3, Insightful)
(1) Large feature set (2) Compact/optimized (3) Fast to market Pick any two...
...and you'll get one. If you're lucky. And it won't be (3). And sometimes it won't be one of the two that you picked.
obvious (Score:5, Insightful)
Ah, the ever quotable Linus. (Score:5, Insightful)
This is like the salesman's nightmare, where you take the guy from engineering to visit the customer. Things are going great, the engineer can answer all the customer's questions.
Then you realize, *the stupid bastard is answering the questions honestly*.
Honesty is a basic requirement to be a halfway decent engineer. Persistent and incurable dissatisfaction with how you did the last job is another. Even if you *know* you did a great job, deep inside part of you knows you could have done it *better*.
What to do then? (Score:3, Interesting)
Bloated? Of course. Happens in every walk of life (Score:3, Interesting)
Bloated? Of course. Happens in every walk of life. It starts out lean and mean killing machine out of necessity, otherwise there is no success. Life is tough and to be other than at the top of efficiency is a death sentence.
After achieving success then being fat and lazy is a luxury that is no longer fatal.
This happens everywhere the jungle, in the business world, your job and governments. Evolution.
Another perspective (Score:5, Interesting)
Bloat isn't bad. [joelonsoftware.com]
Version 5.0 of Microsoft's flagship spreadsheet program Excel came out in 1993. It was positively huge: it required a whole 15 megabytes of hard drive space. In those days we could still remember our first 20MB PC hard drives (around 1985) and so 15MB sure seemed like a lot... In 1993, given the cost of hard drives in those days, Microsoft Excel 5.0 took up about $36 worth of hard drive space. In 2000, given the cost of hard drives in 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space...
In fact there are lots of great reasons for bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make your life better (when you use them) and don't usually hurt (when you don't). If your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible. Maybe, just maybe, if you tend to keep your hard drive full, that's one more Duran Duran MP3 you can download. But the loss to you of waiting an extra two months for the new version is perceptible, and the loss to the software company that has to give up two months of sales is even worse.
Microkernel (Score:5, Insightful)
Kernel Compression Prize Competition (Score:3, Interesting)
The goal of this competition would be to obtain the optimal factoring of the kernel architecture.
Funny! (Score:3, Insightful)
He should start a separate distro and call it leanux....not like we can't make do without another distro out there.
Poor Journalism (Score:3, Insightful)
MIcrokernels - life without patches (Score:5, Interesting)
Let's take a look at the patch history of QNX. [qnx.com] QNX is a message passing microkernel mostly used for embedded systems. But it can be run with a full GUI, runs on multiprocessors, and can be run as a server. Millions of "headless" embedded systems have QNX inside. I used it in a DARPA Grand Challenge vehicle. BigDog, the legged robot, runs QNX.
Drivers are outside the kernel. All drivers. File systems are outside the kernel. Networking is outside the kernel. And they're all application programs, not some special kind of loadable kernel module.
There have been 14 patches to QNX in the last two years. Only one is an actual kernel patch: "This patch contains updates to the PPCBE version of the SMP kernel. You need this patch only for Freescale MPC8641D boards." Only one is security-related: "This patch updates npm-tcpip-v6.so to fix a Denial of Service vulnerability where receipt of a specially crafted network packet forces the io-net network manager to fault (terminate)." Neither Linux nor Windows comes close to that record.
There's little "churn" in a good microkernel. Since little code is going in, new bugs aren't going in. Good microkernels tend to slowly converge toward a zero-bugs state.
QNX generally has a "there's only one way to do it" approach, like Python. Linux supports three completely different driver placement - compiled into the kernel, loadable as a kernel module at boot time, and run as a user process. QNX only supports one - run as a user process "resource manager". That simplifies things. A "one way to do it" approach means that the one best way is thoroughly exercised and tested. There are few seldom-used dark corners in critical code.
When QNX boots, it brings in an image with the kernel, a built-in process called "proc", any programs built into the boot image, and any shared objects ".so" wanted at boot. These last two run entirely in user space; they're just put in the boot image so they're there at startup. That's how drivers needed at startup get loaded. They don't have to be in the kernel. (In fact, you can put the whole boot image in ROM, and many embedded systems do this.)
A QNX "resource manager" is a program which has registered to receive messages for a certain portion of pathname space. The QNX kernel has no file systems; part of the initial "proc" process is a little program which keeps an in-memory table of "resource managers" and what part of pathname space they manage. This is similar to "mounting" a driver under Linux, but it doesn't require a file system up during boot. File systems are user programs which start up and ask for some pathname space, after which "open" messages are directed to that file system.
Another QNX simplification is that the kernel doesn't load programs. "exec" is implemented by a shared library. That library is loaded with the boot image, to allow things to start up. "exec" runs entirely in user space, with no special privileges, so if there's a bug in "exec" vulnerable to a mis-constructed executable, that program load fails and everything else goes on normally.
The price paid for this is some extra copying, since all I/O is done by message passing. This isn't much of a cost any more, because you're almost always copying from cache to cache. That's an important point. Message passing kernels used to be seen as expensive due to copying cost. But today, copying recently used material is cheap. On the other hand, some early microkernels (Mach comes to mind) worked very hard to mess with the MMU to avoid big copies, moving blocks from one address space to another by changing the MMU. This seems to be a lose on modern CPUs; the cache flushing required when you mess with the address space on recently used data hurts performance.
I used to pump uncompressed video through QNX message passing using 2% of a Pentium III class CPU. Message passing, done right, is not a major performance problem.
Re: (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
Re: (Score:3, Interesting)
The biggest problem with that is USB devices. Who knows what weirdo USB hardware you're going to want to plug into your computer in the next couple years. Using the stock Debian kernel, that's something I really don't need to worry about.