Linus calls Linux 'bloated and huge'

I Wonder...

I wonder when the first Microsoft commissioned white papers that quote Linus will be issued? I wonder if they are stupid enough to use the performance gains of Windows 7 over Vista as proof of the superiority of Windows development and ignore the gigantic performance degradation of Vista over XP?

@Lou Gosselin

"Maybe Linus will finally overlook his pride and give up his stubborn decade long argument for feature-bloated monolithic kernels."

Running drivers in user-space would help code-bloat and performance how, exactly? The drivers aren't going to get any smaller - probably the reverse given the relaxed requirements - and running drivers in user-space is probably the best way to kill kernel performance known to man. Case in point - xnu has to be hybrid to avoid being unusable, and it runs like a mangy dog nonetheless.

Code bloat vs Moore's law etc.

AC wrote: "If the kernel is 2% slower per year, but the hardware is 2-10% faster per year... then there is no net problem, is there?"

Why yes, yes there is.

Personally I think it's a damn shame that with today's fire-breathing CPU's, there are many tasks that I could do far quicker on my 20-year-old Commodore Amiga than on some over-bloated modern monster with an OS that takes 1-2GB of RAM just to boot.

In my personal version of utopia, designing products like that should result in jailtime for the coders.

lou:

you mean, we have Linus to thank for the fact that all our hardware isn't run by black box, binary-only drivers?

Thanks, Linus!

Slowlaris

So, the Slowlaris Kernel gets faster all the time, while the Linux kernel gets slower.

We quickly need to find a new name for Linux, like Snailux.

So,

Linus answers honestly. Don't see a problem there. Some of you negative commenters forget this man enabled us to have a very flexible OS in every corner of our lives, with all freedoms, in as short a timeframe as 15 years. Have you forgotten how long ago it was that Microsoft started putting out an OS? what are it's limits? Yeah i'll stop there.

Wow....

as a kernel gain more feature, it became bloated (and full of bugs).

maybe now the linuxoid will think twice before bashing windows?

Re: No surprises here.

First of all, Linus is right. I have had at least 2 machines which were perfectly usable as media center client tipped over into unusability. They are now too slow (from 2.6.18 to 2.6.26).

Last 10 releases is roughly since NFSv4 has fully gone in. The ghastly thing has brought a few regressions that had not 2%, but 92% performance drops. Even with most of the problems fixed there is a boatload of places screaming for optimisation as of the last time I looked at it (2.6.28). Iteration across all elements is used instead of hashing and so on. Add to that slowdowns from moving portions of USB, parallel, etc to userland (hello Microkernel fans) and the picture is more or less complete - it definitely needs a feature freeze for at least a year in many areas until the code is sped up and optimised properly. Microkernel has nothing to do with it.

Using iteration to walk an ever-expanding permissions cache will be slow in microkernel. Same as in monolithic.

Bloat's The Thing

"....streamlined, small, hyper-efficient kernel..." Looks like Windows envy to me spawned by a perceived need to "catch up" to Windows and win the hearts of the unwashed masses.

Before the age of indoor plumbing, the only water leaks you had were in the roof. With the advent of in-wall water piping came leaks, corrosion, and clogs which mandated a greater need for maintenance. Whenever you add features, you add problems; that's just the nature of the beast.

If Linux actually expects to compete with Microsoft Windows, then bloat is the way to go. Well, unless you could convince the common user to accept less, which isn't likely.

Linus T. is still living in dreamland.

Good

I like it when people do not spam marketing on the world.

it's only bloated if you build and load it all

The kernel source is bloated, but it is only a template for a kernel.

It's not a requirement to build and load it all.

Many small and unbloated kernels are built from the bloated source.

What everyone is missing

The Linux kernel comes in Source Code form. If you're really desperate to squeeze every last trace of performance out of it, you can trim it right down to just the bits you need. And as recently as five years ago, that's exactly what people were doing. With 2.2 and 2.4, it was entirely normal to compile your own kernel: you compiled the filesystem and chipset drivers hard into the kernel, and built modules only for the hardware you actually had (or thought you might acquire).

Now that Linux is mainstream, and now processors are riduculously fast (probably due to the demands made by other operating systems), it's simply got past the point where anybody can be bothered to strip it down anymore and reached the point where you can spend more time deciding what not to include in the kernel, than you actually save by leaving it out. It probably isn't helping that hardware manufacturers all insist to make products that are largely incompatible with one another, thus requiring separate kernel modules, either.

But one thing is certain: If there's a gap in the market for a stripped-down Linux, it *will* be filled, one way or another.

This is one thing Apple actually got right. By controlling the hardware on which OSX runs, they at least know what they need to put in the kernel and what they can leave out.

@Anonymous Coward 2:20

Aaaah - I hate that argument! Just because computers are getting faster does not mean we should write our code less well, less efficiently 'because we have room too'. Write the same streamlined efficient code you wrote for old, "slow", memory challenged machines and it'll run like s**t off a stick. Write bloated inefficient code because there's no need to bother putting the effort into good programming then it will run OK, but give it to a colleague with an older slower machine and you're stuck.

They should put a contract on every copy of every programming language tutorial book, every computer science course, every training course, that requires the owner/attendee to promise to endeavour to write efficient code. If they can't promise that or don't see why they should then they should be shown the door.

Re: Funny.

Not a fanboy of either MS or Linux, use them both at work and have no real preference (maybe I'm just not techie enough!), but:

"Linux getting slower and bloated while Windows (7) getting faster and leaner."

Seriously? That's your argument?

Faster and leaner than what? Vista? An OS that Microsoft wants condemned to the recycle bin of history? That's like gaining 6 Stone last week, but boasting I've lost 2lb this week, aren't I amazing! It just doesn't fly...

Why closed source software works.

Projects this large, especially OSes, require that there is someone there to kill certain ideas before they become a problem. Its this sort of feel-good attitude that infests the open-source community that is killing it. What we have is developer that are trying to contribute by adding functions are extra features to things, but aren't good enough to make them lean and responsive. But no one wants to tell them that their code sucks and that they should do more practice and studying before it can be included. They don't want to do this because it will make them look like the bad guy, look like he is against the community and be flamed to hell and back.

The community reminds me of how current society is going. This whole "we are all winners and we should accept our differences", fuzzy warm feeling political correctness. This sort of bland non-offensive, culture-neutral crap. Yes, people should be treated fairly, based on their merits, but everyone should be told when they make mistakes. We only get better if we know we made a mistake. I mean, we are all adults, we should be able to handle such minor things, if someone tells me that 'your work sucks' I am not going to take it personal, I am going to work and try to show him wrong.

Really, its the community that is destroying itself. I was once a Zealot myself, but then I saw the dark side of the community. I saw the arrogance of the senior community members, constantly believing that their were always right and 'correcting' other people's work without giving them any information on how they can improve their code. I saw the constant in-fighting and power struggles amongst the project, each believing that they should be in charge of the project. I've seen the completely new programmers (Usually a fresh CS graduate, or sometime a high-school student) who've dove right in to projects messing things up code, trying to apply every rule they learned school (Usually rules that only apply to writing in BASIC or Java) and destroying some of the most elegant code I've ever seen, especially not documenting their code (Or sometime Over-documenting their code, take a look at the config file for Lynx if you want an example of what I am talking about). I've seen hard working, highly skilled developers sidelined because they don't just don't have the courage to say what they think. But the worst thing I saw was the near unlimited army of users that are constantly white-washing everything, trying to paint everything with puppies and kittens, completely ignoring the elephants in the room, these are the ones that pushed me to leave Open-source, and programming in general behind, to be the cynical, miserable bastard I turned into when I turned 21.

I congratulate Linus on coming out and addressing what has been ignored for the last several years, I hope more people start to speak out and maybe open-source may once again be respectable in my eyes. Hes is just a few years too late. I wholly agree that the Kernel has become too-bloated, there is so much that doesn't need to be there. Thre is far too much support for far too many devices built-in, sure it will support some obscure system bus that was made some manufacturer for only 2 years, but who the fuck cares? When was it said that the needs of the few have to outweigh the needs of everyone else? Why has society done this too? Why must I censor myself because it may offend someone? When did we become slaves to lawsuits and fines, afraid to say even the smallest thing to prevent alienating a small group of people? When did we move from 'rule of the majority, protection for the minority' to 'rule by special interest, fuck the majority, screw the other 98% of society, they don't know what it means to be oppressed'. When?

Always a trade off

Microsoft learned the hard way with Vista that OS efficiency is becoming important to the "average user" again - Vista felt like treacle on hardware that XP felt like lightning on and without giving the user that all important sense that it was really doing more for it. Linux needs to be careful not to cross this line, if indeed it hasn't already - these days when selecting an OS for my older boxes I'm generally finding XP gives me a more optimal experience for the resources.

I know there are some nice skinny distros out there that will run quite nicely on the older hardware but often this involves either compromising the user experience or the ease of access to the software I want - sure these are generally things you can work around but when XP is going to do the job and for a fraction of the effort why bother?

Re: Bloat's the thing

' "....streamlined, small, hyper-efficient kernel..." Looks like Windows envy to me'

Hahahahahahahahahahahahahaha!

And as for the earlier "Linux getting slower and bloated while Windows (7) getting faster and leaner.", have you actually *used* Windows recently, Mosh? As a software developer, I need to regularly flip between XP, Vista and Win7 on the same hardware and whether you are at the low or high end, XP is *way* faster every time.

Linus is just being honest. *All* operating systems are getting bloated, even his.

If this had been MS

It would have been marketed as feature rich and compatible, If this were Apple we wouldn't have heard anything and the fans would make excuses that its feature rich and compatible.

Linux may lack a bit of direction, but I'd rather have people who create the OS for the love of doing it than because it makes them big bucks.

Wot he said (Sam Liddicott)

Otherwise the Acer Aspire One wouldn't have you logged in in 12 seconds. And the kernel is stable. And the kernel is faster than Windows and MacOSX. Windows 7 and Snow Leopard are only now trying to speed things up. And how? By dropping features. With Linux the user can choose the features he wants to run with.

The bigger picture

Any distro ( Linux, Windows or other ) consists of a number of core essentials; kernel, drivers, protocol stacks, file system handlers and applications. The problem seems to be in how that is divvied -up; what's installable at runtime, what's compiled into the kernel, and it stands to reason the more pre-compiled into the kernel, or essential to load at runtime, the more bloated an OS as a whole becomes.

As Sam Liddicott says, it's entirely possible to build lean Linux kernels, and distros for that matter, and XP Embedded does the same for Windows. But that approach creates OS's for specific machines or a subset, not a fit for purpose OS for any and everything a user may have or want in the future, which is what a Desktop environment is.

Disk footprint is entirely different to run time memory footprint and execution speed so the approach to bloat should be towards lean and mean kernels, with the user able to add or remove drivers, protocol stacks, file systems and apps at runtime. Drivers in user-space may not be acceptable as Steen Hive notes but that doesn't mean they have to be pre-compiled into the kernel. Lou Gosselin is right to put the blame on "feature-bloated monolithic kernels", and it's time to fix that; Linus has dug his own hole and needs to get out of it.

Bloat is anything a particular user doesn't want or need but cannot be got rid of, so come on Linux guys and gals - and Linus in particular - show us how it should be done, don't just accept the "unacceptable but unavoidable" shrug of the shoulders and resignation to it.

Re: what problem? (AC 02:20)

I see. Who are you astroturfing for, Microsoft or Intel?

@Wortel

Yeah, and it's a shame the marketing is so dismal to.

RE: Funny!

Mosh Jahan wrote: "Linux getting slower and bloated while Windows (7) getting faster and leaner."

Yeah, that's like saying "I saw Kate Moss eating a few chips - but Mealoaf is on a diet"

Would that be the same performance-lite kernel...

...that runs on 19 0f the 20 fastest supercomputers and the vast majority of the next 480?

Oh, it's customisable, you say? You don't need to use everything it comes with?

Who'd have thought it?

PEBKAC

For years, we have known that compiling your own kernel is cool and results in a faster kernel.

For years, we have complained that ordinary users won't use Linux.

For years, ordinary users have feared Linux because it's not easy to install or use.

More recent distros are much more user friendly precisely because the kernel is so bloated.

So what do we want - a universal kernel that will run on pretty much anything, or some form of hideous hardware scanning autocompilers that recompile the kernel as soon as you plug in a new USB device?

It's a little like Apple's iPhone business model: it sucks, but 90% of the planet likes it, so we happy few will have to live with it.

@Crazy Operations Guy

"But no one wants to tell them that their code sucks and that they should do more practice and studying before it can be included."

Try and submit some sucky code to the linux kernel devs, and someone will definitely tell you that your code sucks.

"They don't want to do this because it will make them look like the bad guy, look like he is against the community and be flamed to hell and back."

When you get a major kernel dev, or even Linus himself, saying this, people tend to side with them. ;)

Not that I've submitted code to the kernel, I'm not good at C. But I have made a fool of myself on LKML and the replies were a little scathing. Certainly taught me to double-check things before clicking "Post".

@Mectron

Yeah maybe so, but at least we can have an honest and open discussion about the problems in Linux, with a possibility of some action. Windows what you got? A lot of whingeing and a hell of a lot of praying and hoping Billy and the boys will fix your problem! If not, nevermind there'll be a new version of the O/S along in, oh lets say 7 years time?!!?

@ Edwin

"So what do we want - a universal kernel that will run on pretty much anything, or some form of hideous hardware scanning autocompilers that recompile the kernel as soon as you plug in a new USB device?"

Actually, that's got legs.

Put a bloated catch-all kernel on the install disc, but also provide an advanced "super racing tune-up" installation option that will compile a brand new kernel with support for the auto-detected hardware and any more that the user selected (either from a menu, or just by having the user plug in their USB devices one at a time and auto-detecting them). After all, we know which modules we loaded in the first place, and which ones go with the new devices ..... well, they're obviously the ones we need to compile. Display a warning that this will take a long time and this is the last chance to bail out. Use a bootloader that supports multiple kernels, so you can start up in "super fast" mode (with your custom kernel) or "failsafe but slower" mode (with the stock one).

Now, if the user later acquires a new piece of hardware for which they didn't compile a driver module but the Source is in the Tree, the required module can always be built at a later date. Even if it is some device that needs its driver to be compiled "hard" into the kernel, or requires a new Kernel Source Tree to be downloaded, it will only be necessary to boot failsafe and rebuild the custom kernel.

This whole process can of course be almost fully automated, perhaps with a progress bar or even an amusing slideshow, for the sake of people who presumably have difficulty remembering how to spell "make".

@Crazy Operations Guy

Damn! That's good. But I suspect you'll be getting a lot of flack since you're posted real world experience as opposed to dream world fantasy.

small and lean isn't always efficient

I've used linux for over ten years, starting with the latest 1.2 - 1.3 kernels, and slowly climbing the ladder until now (fedora 10, 2.6.27). 1.2 kernels were terribly inefficient, but we didn't expected much of computers in those times, so it got away with it. But 2.0.x was really marvellous, albeit limited in functionalities. Then we got the 2.2.x series, that was rather experimental in spite of its alleged stable status, and performances sucked (big locks, many in-memory data copy etc.).

It was soon replaced by the 2.4 line. 2.4 is still rock stable today, and while it lacks many drivers for new hardware, it's pretty small and can run most of your exotic stuff (alpha, sparc smp). But in spite of being lean and stable, 2.4 is still full of the 2.2 conception quirks that are performance bottlenecks. Hence the need for 2.6.x, which originally aimed at streamlining the foundations of the kernel. Many O(n) algorithms were swapped out in favour of O(1) counterparts, and where it runs, 2.6, while generally much bigger than 2.4, runs way better and faster. That recently it begun to slow down a bit doesn't do justice to the extraordinary improvements it made over older kernels.

So maybe it's time to feature-freeze 2.6, and stabilize it while launching experimental 2.8 for new stuff. But in my books, 2.6 is still the most efficient kernel to date, and one of the most innovative, competing only with 2.0 in that area (2.0 brought a tremendous amount of novelties to linux, support for elf32 to begin with, and much, much, much more, and is still maintained for some embedded applications).

Now, I'm not a kernel hacker, but I've had the chance recently to play with NetBSD, I've used windows XP and Vista (not 7 yet), and a bit of MacOS X. While any of those can be marginally better than linux in a particular area, *after* spending an awful lot of time trimming it (just about like you could improve linux in the first place by tailoring a slackware to suit your needs), the conclusion is linux is the 4WD of OS. Runs everywhere, and pretty much goes over everything you can think of throwing at it. NetBSD ? Oh, you need to compile that kernel to get what you want (and I tell you, it's not for the faint of heart ; been compiling my linux kernel for ages without breaking a sweat, but NetBSD gives you chills down the spine). MacOS X ? Does everything, but random (x)thing will set you back another (y*10^3) $ - and forget about whatever computer you have, it's intel-apple only now. Windows ? ... I'm torturing myself to find a place where widows shines, and can't find none. It's a nightmare for everyone, from sys admins to users, albeit a familiar nightmare so they don't feel the need to wake up.

@ HarryCambs

The point is, you're supposed to put fences where as little as possible has to go through them -- not just where they happen to look pretty.

Drivers belong in kernel space (1) so that "ideal" hardware can be modelled (all things that do the same job should expose the same interface), and (2) so that hardware operations can be sanity-checked. Sure, you could implement a filesystem driver mainly in user space with just a straightforward bridge to the hardware in kernel space -- but how can you be certain then that it isn't going to attempt something silly? And then it becomes harder to enforce consistency of drivers between filesystems, which makes it harder to replace one with another.

@Doug Glass

No, hell get flak because he's not realy in touch with reality and is spouting random lines from HYS about being PC and how him saying to people "you suck" is good, but people telling him he sucks is bad.

@Sooty

"This sort of thing shows you up as 'not a software developer' or if you are, please god don't let you be one that i have to work with."

What a load of old codswallop.

Lean, well written and designed code is something all good software guys aspire to.

Unfortunately, a lot of people of calling themselves "programmer" learned a bit of HTML at school and think they can program.

Programming is an art and a very precise skill and too many people think they can do it without the proper practice, training and experience.

The evidence m'lud:

- Coders don't check function return codes;

- They allocate memory expecting it never to fail so they don't take the trouble to detect NULL from malloc();

- They don't check their buffers and overrun them;

- They assume that the stack is unlimited and stick massive great structures on there

- The use "handy" STL templates without checking if they really are efficient or appropriate for the application.

Holy cow I could go on and on.

I have seen complex systems that were written in C to run on DOS boxes that run for years without a reboot (seriously).

When you have to write code that has to run ALL the time, like for military systems, or at the local phone exchange, then you can truly call yourself "programmer".

Can anyone with a fresh install of windows...

...tell me what the memory footprint is before you load any apps...

Linux boots for me into about 230Mb of memory tops, whereas my current install of Win XP runs at about 450Mb after a fresh boot with about 42 processes (it's fairly lean by most standards).

Lean Efficient Code?

Real world programing requires trade off and compromises, and things are a hundred times more complex that what you see in a beginning programming book.

They will show you an simple program, lean an efficient. But in the real world ....

Well that program only covers 95% of cases ... adding additional code so that it works in all situations and the program is 10 times larger.

Now defensively verify all your input and check all your function calls for errors.

OK now you have to add system wide error handling to detect and recover from errors.

Don't forget security. You'll have to replace all that fast and simple c style string operations with data structures which are not vulnerable to buffer overruns, filter all incoming data ....

Oh and guess what ... that book taught you to program like your code was the only code running on the system, but you are coding in a multi-threaded multi processor envirtonment. So rewrite everything so that no two bits of code can ever step on each others toes.

Even at the level of writing a simple routine ... you can't just write "good lean code" ... its all about design trade offs and compromises.

When you go up to the high level design its the same thing. You can make the system more modular which will make it easier to understand, easier to test ... but then everytime a program wants to read from a file on the hard drive it has to pass through 7 layers of carefully tested and verified services then back up.

You can cut out all the overhead but then you have one big layer that is so interconnected and complex that you can't really test anything in isolation.

Or you can design everything in the most efficient way possible, but that design is inflexible. Every time you add a new feature you have to redesign from the ground up. Or you can build a flexible system whose design is less efficient but can easily be extended to accommodate change.

Then there are business concerns. Lets say there is a way to make your OS twice as efficient only its going to take 10 times as many programmers, and an extra 5 years and will break compatibility with 3rd party software.

Its all about balancing conflicting demands, design trade offs and market conditions.

Glib response

Small and compiled with only what you need? Gentoo (he says recompiling the kernel on his gentoo xbox...

@Jason Bloomberg

"Lou Gosselin is right to put the blame on "feature-bloated monolithic kernels"

Actually he isn't right at all. World + dog knows that Linux hasn't been a true monolithic kernel since before I learned to mix metaphors. It is only monolithic in the sense that drivers run in kernel space - in combination with udev, etc., drivers are never loaded into the kernel unless required by hardware, so unless you can find a way to do away with device drivers for an ever-expanding plethora of hardware, protocols and legacy systems, you're essentially up shit creek.

The so-called "micro"-kernel concept is a documented failure (xnu, L3, mach, excepting QNX maybe) in terms of both code-bloat, performance and maintainability when compared to kernels that contain other critical subsystems than IPC, Memory management and scheduling in the core code. Sure it's a great and elegant idea conceptually, but an abject failure at doing anything else except being a conversation topic among the University chattering classes.

Now the argument of exactly what should go in a kernel can be argued over till we're blue in the face, and sure Linux could maybe do with a prune here and there, but devices are supported by code, not Scotch Mist.

Full Speed Ahead :) Think of it as evolution in action.

Its great that he's not complacent, and hey, maybe if he highlights it someone will provide a plan (worth a shot).

If someone did come up with a solution then we can have our cake and eat it too!

Sneaky Linus ;)

The Kernel is evolution in action - good stuff that is of value survives, the rest dies, rots and finally disappears.

From what I have seen lately re the file system if you can _prove_ your case then ppl listen. Its the scientific method applied to software development... Which is why FOSS will win in the end... it is a modern scientific, capitalist development versus the proprietary, authoritarian, monopolistic, command economy model (and we know how that one will end).

Resource Control/Accessibility

I think user kernel modules are a bad idea ! The kernel *HAS* to be able to fully control access to hardware resources. With user kernel modules, just how can the kernel reliably be expected to do this without checking, and allowing/blocking everything the user module is doing ? I can see this being even more messy and resource intensive than having a kernel with all the hardware support compiled in. And also aren't user kernel modules just another attack vector to be exploited ? Or a serious risk of system crashes due to deadlocking of a vital resource ?

So if you want to slim down that kernel, then recompile it for your system - at least you have the flexibility to do that, albeit with a bit of research required in preparation. But if you're concerned about performance, you most likely have the background to learn what you need to do this, and enjoy it at the same time.

I think Linus is right though to observe that the kernel is getting larger, and losing some performance, but as has been stated there will be more error traps in the code, more features, etc. This should give a better end user experience with a more feature rich and stable system. So whilst there is maybe room for improvement (everything suffers from this !), I don't think the problem is severe. If there is a more effecient way to do something, equally stable in comparison with the current way, then lets include it. If it's bleeding edge, and not quite ready, keep developing it by all means, but it should not be in the stable kernel.

Now I've used vista, and I didn't see any performance problems that have been mentioned, though the machine it was on was reasonable spec, and I didn't run xp on the same box as a comparison. There was masses of eye-candy as is to be expected, and I even liked the northern lights screensaver. I just didn't like vista, and some features really started to grate, particularly the endless dialogue boxes warning that I might harm the machine by running something. But it did work, just not in a fashion that I like. xp is better, but still not my favourite system.

So I'll be sticking with my friendly bloated warthog of a Linux kernel, the Operating System and all the other fine software that I can run on it, whilst thanking all who contribute towards it for what they offer to any of us who want to use it.

Re: faster CPU's / Write more efficient code

it used to be (20 years ago) that you paid developers to write fast efficient code, and developers spent time to make their code efficient and fast enough.

These days, its usually cheaper to buy faster / more hardware...

Kitchen sink

Good feedback on this article. I moved to linux as it allowed me to do what I wanted, as against MS. With the more recent kernels I have been having a few grumbles from my wife from boot up times on her machine... But thats probably more to do with the cruft I have snuck on here system. Heartbeat and cluster services, to name a few. Am now trying ro come to grips with dkms for a kernel driver that I need. Personally I shudder at the thought of drivers not being compiled for the specific kernel. Keep the hardware lean an mean, please!

I have just had to download and install a driver for a logitech keyboard and mouse, for a client! 68MB! Non windows certified so you have to have another bl**dy keyboard and mouse to get it working. She unplugged to to move some cords, and the thing goes through the whole sequence again, requiring a separate keyboard. Oh and you can just plug on that you know is identified in as the prompt about a driver halts any autodetection of hardware, you have to pull the plug and put in the other keyboard and mouse. Don't get me started on HP printer drivers (~230MB!) plus another (69MB) required to install .NET. I have some clients who are still on dialup, and cannot get broadband, thank god it wasn't one of those!

The linux experience is in a whole different league. Most things just work, and I know if I want to get things going faster I can compile the thing myself...( I never do though ) A nice friendly system for auto compilation and optimization would be nice.

Tux, cause he's big monolithic, alive and happy!

@Doug Glass 08:00 GMT

Yeah, and you seemed to have missed the point. 'Linux', the kernel lest you forget, has developed much faster than any Microsoft product. And marketing? don't get me started. Marketing was invented by assholes with an exceptional ability to enhance the truth. Keep watching those happy happy joy joy Microsoft Vista television ads mate.

@Peter Kay

Not everybody's using an x86 ; my test gear was a sparcstation 20-712 that came empty, OS wise. I've got already a 10-512 that's happily running the latest supported sparc32/debian (etch) so I was willing to try something else, because of sparc32 being EOLed. FreeBSD : no sparc 32 support. Out. OpenBSD : no smp support on sparc 32 (at least this is clear from the installation web page). Out. NetBSD : no particular caveat, brags about being compatible with about every arch out there. OK, let's burn that iso. Hum. There are two conflicting statements in the INSTALL notes at the iso root... Can it go smp or what ? Check the mailing list archive : in -CURRENT, sparc32 smp is broken. But hey, -4 still does smp ! Let's burn -4. Install, boot, post-config, ok, seems to work, let's D/L some stuff. pkg_add -v windowmaker (yes, I know, serial console etc..., but that's beside the point). "Kernel attempting to lock itself against a lock", break to OBP. WTF ??? A couple of random crashes later, let's try to slim down the beast. Remove every obsolete bits in default pertaining to 4, 4c, 4d arch, config, depend, make... wait... wait... link fail ! Would you believe it, there's an undocumented ref in 'default.smp' to some 4d stuff in 'default'. Neither config nor depend gave me warning about it ! Goto config, etc.

Verdict : it somehow works for some values of work. I've less random deadlocks (but I still got some on occasion). My linux 10 has served me well for years, acting as dhcp provider, dns relay, and pop3 from my isp to local imap in my home network. The NetBSD 20 wouldn't cope with that reliably at the moment. It makes for a fine X terminal, which is a pity. Superior BSD stability my foot.

Flames, obviously.

It really is funny...

... just how religious some people are with regards to software. I've read a lot of comments on here that just fly in the face of the facts.

For instance, the fact that you can compile your own kernel if the source is too bloated - this is a non-argument and doesn't even begin to address the situation. The fact is, whether you Linux hardcore'ers like it or not, the majority of Linux users now would not have a clue how to go about this. Linux is still not a contender with MS in the desktop market but this isn't the geek only option it used to be. You need to get used to that and move on, develop a proper Windows Killer and not just copy it like all the smartphones copy the iPhone.

This argument: "Linux getting slower and bloated while Windows (7) getting faster and leaner." Made me LOL. Saying that Windows is getting faster because of the improvement of Win7 compared to Vista? WTF? Have you forgotten how fast W2K was on new hardware and how XP was reviled as bloatware when it was released? Then suddenly when Vista was released the same thing happened again... the hardware wasn't up to the pile of poo that was installed on it. Now Win7's out it's the saviour of MS, the best offering since (the once hated) XP. But only because it's running on quad cores with gigs of RAM.

It's a shame that people can't see that there is a major hardware/software imbalance here. As hardware improves, the software should evolve with it and run faster, but it's just not the case in today's bloatware infested world.

It never fails to amaze me how fanboyism can kill rational thought in otherwise intelligent human beings.

Modules?

Stop me if I'm on the wrong track here...

There is a difference between the linux codebase and what actually gets loaded when you run it. The difference is influenced by two things:

1. Things not complied at all

2. Things compiled as modules and not loaded at all

Now, from what I understand it, you only need to compile in things that are required in order for linux to start up and start mounting your disks so that it can start loading modules. So this basically means filesystems and chipset drivers.

Fine. So what's wrong with compiling *everything* else as modules? That way, you have access to *everything* that the linux kernel supports, while at the same time only needing to load the modules required to support the things you need? Other than the disk space used (which I doubt is significant these days) I don't see any downsides.

That just leaves the requirement of compiling in things that are required to boot. These can't be modules because the modules are potentially stored in a different partition to the boot partition, which may be on a different controller and use a different filesystem. Fair enough, that is a problem as the number of filesystems and chipsets is only going to increase over time.

So, how's about a new type of module - a "boot module" - which gets stored on the boot partition along with the kernel itself. I doubt it would result in any massive increase in storage requirement, since the kernel would be roughtly correspondingly smaller as a result.

So that way, the kernel binary itself becomes as "micro" as it can, it loads only the boot modules required in order to boot, and then only loads other modules as and when they are required.

Anyone see a problem with that?

Mac OS X Snow Leopard is FAST FAST FAST

Linux has become bloated and huge.

Mac OS X has become much slimmer and faster. Mac OS X generally is faster with every iteration, not slower. With Mac OS X Snow Leopard, it has also become much much slimmer.

Perhaps, Linux developers can use Apple as an example of where to go.