Thanks for your input Andrew, correcting what I didn't get :) On Onsdag 29. april 2009, Andrew Lee wrote: > * The benchmark is using XFCE, not LXDE. > This article didn't compare with LXDE. It's XFCE in the article: > http://ktown.kde.org/~seli/memory/desktop_benchmark.html
That's right. But you get into the same memory issues regarding libraries which the benchmark outlines above, even if LXDE may be flight light in itself ... This because of library towering issues at hand. Sorry for pointing that out, but my cynical engineering side was revealed :) Secondly choices done in Debian for end user experience are not always the best ones. Just a glimpse on what's done with OpenSuSE, Mandriva, Xandros and Ubuntu, you may see that others does a considerable better job providing desktops for end users compared with Debian. Even if Debian has improved immensely the last 4-5 years. That said, I know that such a statement commits. The good news is that desktop improvements usually made by distribution tailoring, are going into the desktop system itself. Usually the different Linux distroes are tailoring, plumbing and tweaking to get a really good desktop in place. Now much of this work are done within the different desktop environments itself, making everything blend nicely, and using common infrastructure as D-bus, x.org, HAL etc. Things that make you copy and past with ease between Gnome and KDE applications. E.g the educational experience from the MEDUSA project with 325.000 pupils and teachers in Canary Island who uses a Kubuntu based school desktop, are now tailored to be a standard part of KDE4 (finally): 1. http://www.grupocpd.com/archivos_documentos/info_meduxa/meduxa_project_released/PloneArticle_view Here is the roadmap and background for including experiences for education onto the desktop: 2. http://techbase.kde.org/Projects/Plasma/Education Such ideas may be useful for LXDE developers too? > I am packaging new LXDE components with lxde-common 0.4 release. And > I'd to see the real desktop_benchmark on recently version of these DEs. What's good news, is the race on improving Linux speed started by the interest for Mobile Internet Devices and Netbooks. Previously most free software developers ware focusing on catch up, getting the Linux desktop to be a real competitor to Mac and Windows, having having comparable functions and features. This goal was reached 3-4 years ago IMHO. This desktop catch up lead to memory eating beast as OpenOffice and Firefox, not focusing on memory usage. With Netbooks and phones we are in a kind of reversed Mores Law situation. Meaning that Netbooks are sold in an extremely price sensitive market, and phones even more. Then it might be more sense to reduce memory and cpu power a little to get enough battery power to run a bigger screen, or more hours working desktop before a recharge. When big manufacturers can cut of 10 USD to a 250 USD machine in production cost, it worth while the added cost of making improving the software - making it run smooth even with reduced computer power, getting longer battery life, bigger screen and mobile network which are up all the time. The race is on, focusing on memory footprint, running more software with less clock cycles, speed, ease of use and bling. We are already seeing great innovation ahead caused by speedy Web runtime (fast JavaScript engines) and effects on getting Linux on mobile devices. You've probably heard about the JavaScript web browser runtime race[3], Sugar Desktop Environment, KDE4 with built in bling, reduced power etc. 3. http://arstechnica.com/open-source/news/2008/10/extreme-javascript- performance.ars This is all examples on the mega trend we are in. More focus on user experience for different users, bling and speed -- with less cpu, smaller screens, longer batterylife and mobile Internet. It's just a matter of time before this innovations flushes into the Debian repositories, being ready for stable use with the next release, 20 months from now or so :) Best regards Knut Yrvin -- Privat mob: + 47 934 79 561 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
