You'd need ELKS on a pre-386 machine.

On the whole, though, his intuitive sense of taste has been for Linux

s/been/been pretty good/

Proof-reading ability falls off with increasing blood alcohol levels, sadly ..

I don't see the problem, to be honest. the toolkit libraries of your apps (by definition running as you) turn requests for widgets into drawing primitives and pixels that need setting in a framebuffer. The X server draws them / sets them. What's the third level of protection protecting you against? Processes memory contents are already protected against each other, the worst the X server might be tricked into doing is reporting the window or clipboard contents of one app to another, which is usually something you want it to be able to do anyway.

There's a possible argument for being able to mark certain X clients as "sandboxed" in the X server, but running the X server as a separate user isn't going to help in that situation - just introduce more complexity.

Linus isn't perfect. His opinions evolve over time. On the whole, though, his intuitive sense of taste has been for Linux, I reckon.

Also, I think KGI wanted to push a lot more into kernel space that we have now, even with kernel mode-setting, though my aging memory may well fail me..

It's a truism: those who do not understand technology are destined to write clueless articles about it, apparently.*

Sorry, feeling particularly bitter and twisted this evening ..

(* or get appointed CTO)

It's backwards to the vast majority of people who never used the network capabilities of X.

Sadly, even when you demonstrate it in these days of Terminal Services / Remote Desktop / VNC, people aren't impressed. The fact that it worked just as well 20 years ago (when it was in fact more use - you generally had a thinner, dumber X terminal, and a choice of minis / servers to do your computation on) passes them by ..

Amen. I'm not generally a big fan of rich capitalists, but this guy saw what needed doing and had a go. I've got a lot of respect for people who actually try to get stuff done rather than just moaning, even if they are still aiming to make money off of it in the long term. With any luck he'll learn some lessons, and be able to use of the hardware, and come back later with a better plan.

I'm not a big fan of the aesthetics of these things either, but I accept their necessity.

Look at it this way - with fugly great wind farms all over the place, we'd have a constant visual reminder of the impact of our energy requirements. More incentive to reduce them than with invisible CO2 emissions and fossil fuel depletion..

Process creation / switching overheads have been pretty good on Linux for years, not sure about Windows. IPC is a different issue, but again with shared memory (rather than pushing stuff through pipes and sockets), the overhead should be minimal - assuming a well-designed architecture.

Having said that, I seem to recall that there are under-the-hood settings in Chrome that can be tweaked to control how enthusiastically it compartmentalizes - I imagine (and hope) FF will do the same.

My completely uninformed and amateur opinion is that it all went to nuts with the introduction of XUL. It blurred the distinction between the data the application was supposed to be processing and the application itself. I'm sure cool stuff can be, and has, been done in XUL, and I imagine the add-on system depends heavily on it (and related technologies), but I think it has overcomplicated the browser tremendously.

Still, Chrome's raised the bar in many ways, and managed (apparently) to implement extensions in a simpler way, so OSS has still won. The Right Thing is not always obvious, particularly for projects that started earlier and had to guess which way reality was going to jump. Five years ago it was probably quite a plausible idea that we'd be pulling down rich XUL applications from web, the technologies that won in the end (Web2.0-y Ajax-y stuff) were only just coming over the horizon ..

I'm more-or-less with you, but .. Netscape 4. Ugh. IIRC, version 3 hit the sweet spot regarding performance, footprint, and all the rest .. A bit like Win2K.

Tabs are just another form of MDI, and as such really chuck the whole document-centric computing idea out the window.

In reality, of course, they're pretty useful, but if someone could find a way of having another go at document-centricity while keeping the tabs, that would be nice. In theory the Win9x-style taskbar isn't much different from tabs, but in reality it doesn't seem to work nearly as well, regardless of all the bells and whistles MS seem to keep adding to it..

When HTML (and thus, rendering engines) were simpler, starting multiple copies of the browser was probably a perfectly reasonable approach, as any duplicated data wouldn't be that big. In the modern era, I agree, it has to be done more intelligently.

Hmm.. I've been using Firefox since 1.0, and I don't recall ever having a crash. Admittedly I'm getting old and my memory is going, but I'm more certain that I haven't seen one in recent history (2.0 upwards.) And yes, I do use flash. Not heavily, it has to be said, but often enough. The speed improvements in 3.5 were, IMNSHO, a higher priority than this multiprocess stuff ..

It is also possible to do non-blocking or async I/O, of course. A pain in the arse in many situations, but some applications are a good fit for a single process / thread model. Given the amount of state involved in modern web browsers, though, they're probably not one of them.

There always seems to be an arms race. I hate to say it, but for years, Windows offered a superior desktop experience for normal users, and that fact incited the OSS world to catch up, and arguably overtake. Similarly, Firefox leap-frogged IE quite drastically, causing MS to play catch-up, which they may just about have managed (not sure here, I gave up web design long ago, and don't have IE 8 anywhere to play with.)

In this picture, OSS doesn't always have the lead on features, but what I'm trying to point out is that there are other qualities where OSS does (IMNSHO) consistently trump commercial software, but these are difficult to identify, describe, and communicate to end-users. Should we continue to over-simplify and just tell people "OSS is better", or should we have a go at explaining, in more detail, exactly why?