Me too. Of course, I *am* old so maybe that's why.

... the more systems will slip through your fingers."

I downloaded mosaic when the web was new and being a Linux user, Netscape was the only game in town and I suffered through the horrible Motif widgets because the browser and email client were the best of a poor set.

Firefox was wonderful when it came out and delivered a great shock to the system. IE 6 was bullocks and once people got used to downloading a browser, it opened the door wider for Opera and eventually Chrome. I don't know at what point they lost their way, but my Firefox nee IceWeasel got slower and slower and slower. The bickering over the trademark and the increasing performance problems lost me. Once I had to kill the browser every time I went to shut it down, I put Chrome in my sources.list and never looked back. Too bad, really.

That's great! I've been poking through their package mods and it looks like some real he-man coding was needed to get all this working with a more modern kernel and Xorg than it was originally intended. I need to send these guys a beer!

Unfortunately, my big needs aren't as simple as distro that works with the future-ported Poulsbo drivers. People and companies developing Linux products on netbooks and MIDs need those drivers in the mainline Linux kernel and Xorg source to gain wider general use, code reviews and more widespread testing. OEMs want to get a warm fuzzy that the drivers will still work and will still be maintained a year or two from now. As much as I love what I see in Jolicloud, I doubt many people will be willing to bet their company on them continuing to provide this Poulsbo support if Intel isn't willing to update their official drivers.

Thanks for the lead!

Half the available netbooks are running the GMA500 / Poulsbo and there hasn't been any support by Intel for Linux drivers since 2008. How can they claim MeeGo will support netbook and MID hardware without accelerated video drivers for their own product?

Agreed. There are certain classes of problems for which threads provide an elegant solution, but it is not the answer for every problem. The same with Object Oriented techniques; they really help in some cases. Unfortunately, there is a tendency in our industry to treat whatever this years popular tool or developmental concept as some kind of panacea and everything that has gone before as some kind of remedial solution for technological dinosaurs.

The truth is less cut and dried. UNIX philosophy still applies (small, discrete applications; clean interfaces; in separate process spaces), despite the inherited, object oriented model being in vogue. Threads are good for the kinds of parallel problems they solve, but you can't beat an straight-forward event loop for asynchronous performance and lack of obscure timing issues. Sometimes you just need an old fashioned FIFO for IPC, rather than some kind of sophisticated OS managed queuing system.

I'm old, but I've seen a lot. Most problems I've found in software development design / architecture is someone with a degree using the latest college-taught solutions to solve real-world problems and inadvertently making them almost impossible to solve.

I'm sure the EGlibc and EGcs naming was not entirely coincidental.