Ars Technica Interviews Robert Love
functor writes "Ars Technica has interviewed kernel hacker Robert M. Love of MontaVista/Ximian fame. He covers current and future developments in the Linux kernel and on the desktop, particularly concerning the Linux process scheduler and its enhancements for system responsiveness and also his work toward Project Utopia, an effort to make Linux's device management on the (GNOME) desktop transparent and seamless. (Robert Love is the principal hacker who worked on kernel preemption for the Linux 2.6 kernel.)"
Linux already works fine as a desktop; what most potential switchers need are a few good apps to fill the role of Quickbooks, Exchange, iMovie and a handfull of other programs. They're happy with any schedular as long as their ogg/mp3 player doesn't skip while loading a big spreadsheet.
As to GNOME and KDE? Well, they're fine if you think all Microsoft's HCI mistakes are outweighed by the need to make it easy for their users to switch to an equally badly designed system. I don't and so I couldn't care less about what the programmers on these projects are wasting their time on this week.
My wish list for the desktop is: a decent file system which stores meta-data beyond the file name and date stamp, a program which decodes the data in Quickbook files so I can import into Gnucash, and a single, working, font system. None of these are very urgent but they're all more urgent than anything mentioned in the article.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Just a few comments.
1) KDE, as a project, is not Borg-like. We like to use other technologies when they work, and we use (and/or invent) better ones if the existing things don't work properly. (See CORBA.)
2) While it's nice to leverage existing technology and architecture, if you make use of too many existing projects it becomes an absolute nightmare to build everything from scratch. Even installing from binary packages is a huge pain - there are literally dozens of packages, and getting the dependency order correct is just insane. Can you tell me off the top of your head which libraries gdk-pixbuf, gtkglarea, ORBit, and libzvt depend on? I didn't think so.
3) Using all sorts of different projects means that you have different APIs for every library. One of the really nice features of having KDE based on Qt is that Qt provides a very nice, sane, predictable API for all sorts of different things - the same methods are available whenever they make sense. And since all of kdelibs is distributed as one package, and developed as one large package, the entirety of the API is much more cohesive than the ORBit API plus GTK+ plus libxml plus libsoup plus any other independently-developed libraries that you might need to include to get the functionality you need.
KDE and GNOME are evolving to serve very different markets and that's ok. I'm a KDE developer and I'm excited about everything in Project Utopia, even the GNOME-specific parts, because it gives me a chance to see what they do that I like and what they do that I dislike in their GUI and I have the opportunity to do things differently without duplicating the entirety of the Project Utopia tree. To use a very common analogy, it's much better for someone to reinvent the hubcap on the wheel than to keep reinventing the entire wheel every time.
I read the Evolution developers' blogs almost daily and I have yet to see anything about an "evolution-back-end-server" - I have seen some interesting things about Groupwise integration, but that's quite a far cry from the open source software that we all know and love.
And if you think that Novell will pay for Ximian developers to program something that will take away their Groupwise market, I want some of what you're smoking.
Also, I would love to know how exactly anything in the KDE API looks even remotely like anything in the MS Win32 API. I've programmed very briefly on Win32 and much more extensively with KDE and Qt, and I can tell you that they are absolutely nothing alike. But you don't seem to know what you're talking about anyway, so I'm not exactly surprised.
Hi,
...
...
The example you are pointing to is in fact one of the best examples you could have given that you are completely wrong with your reasoning.
The KDE Groupware project builds on Kolab
http://kolab.kde.org/
The Kolab Server has been a KDE independent project from the start in 2001. You don't need _any_ KDE libraries to use it and it's not built on top of anything that would be KDE specific. It was intentionally built this way to make it possible for other projects to _use_ it as well. It has been finished and stable since more than 8 months ago.
Still I don't see Ximian using it - Instead they seem to reinvent their own wheel from scratch now
And as you would find out if you were more open minded this isn't the only example where KDE creates technology which has never been KDE specific and which is has been discarded by other projects just to reinvent their own wheel.
So much for the pot calling the cattle black
Regards,
Torsten Rahn