posted by Eugenia Loli on Tue 16th Jul 2002 20:01 UTC
IconOSNews is pleased to host today an exclusive interview with Waldo Bastian, the well known KDE developer and SuSE employee. Waldo has been involved pretty much in all levels in KDE's code, from Konqueror to kdelibs, to games and Kicker. Waldo speaks today about the success of KDE, its future, UnitedLinux, development and much more.

1. KDE is today leading the XFree86 desktop envinronment's userbase with well over 50% of usage worldwide. It seems that the "eternal battle" with Gnome is over, at least as the numbers of usage suggest (Gnome reportedly has around ~21% these days). Will this success have an impact to the way the KDE developers work, into something more "corporate" or "serious", or will it continue as is?

Waldo Bastian Waldo Bastian: KDE has always concentrated on making the best desktop for its users, the level of popularity of GNOME does little to influence that. The existence of GNOME has influenced KDE of course in the sense that Trolltech has GPL'ed Qt, the existence of GNOME certainly played a role in that.

I don't expect any change in the way how KDE developers work. People work on KDE because they enjoy doing so. It's nice if some company can save a few million on its desktop licenses because of that, but that is usually not what motivates people to work on KDE.

2. KDE 3.1-alpha was released recently and a lot of people seem to love the new goodies. What are the future plans, feature-wise, after the release of KDE 3.1 at the end of the year?

Waldo Bastian: We have no idea yet. KDE in general has never planned very much ahead. It was only with KDE 3.0 that our current release manager, Dirk Mueller, has introduced release feature plans in which developers can list the things they plan to do before the next release. The result of that can be seen here. Whatever falls out of that typically moves up to the next release. The feature plan for KDE 3.2 can be found here. But as you can see it is still very empty at this point.

3. I read in the KDE devel mailing lists that TrollTech does not always "listen" to the KDE's needs. KDE sometimes require changes to the code or new widgets, but TrollTech does not always comply. What the KDE project can do about the issue?

Waldo Bastian: In general TrollTech is reasonably responsive to our needs. But just like all of us they have a finite amount of developers and time and an infinite amount of wishes and demands for features. Some things to make them more responsive:
* Tell them about the things you need. This is so trivial that people sometimes forget it. It's like those discussions on a mailinglist where people say "they should make this" and "they should make that". But when you don't send that to the Trolls themselves it is very unlikely that they start doing that all out of themselves. Keep in mind that there is a difference between telling what you need and demanding to have it by tomorrow afternoon.
* Do it yourself and send them patches. After all, we have the source.
* Catch a live Troll, lock it up and feed it beer till it promises to make whatever you need. Milka chocolate also gives great results.

It should be noted that the same tactics probably can be applied to KDE developers as well.

4. Tell us about SuSE's involvement to the KDE project. Will UnitedLinux also choose KDE?

Waldo Bastian: SuSE has been very supportive of KDE pretty much since the start. Over the years they have provided KDE with money, hardware, bandwidth, SuSE CDs, assistance during conferences and expositions. And certainly just as important :-) they have hired me and allow me to work almost exclusively on KDE.

UnitedLinux will include a very basic KDE 3 desktop. Since UnitedLinux is aimed at servers it will not include any KDE applications (not very many at least)

5. A lot has been said about UnitedLinux. What is your opinion on trying to further commercialize the GNU/Linux platform? Do you believe that Linux has a better chance to increase its installed userbase with the help of big companies adopting it as their product, or with the "traditional" method of GNU through spreading the GPL philosophy to new users?

Waldo Bastian: There are many different Linux users that all have different needs. UnitedLinux aims at a very specific set of users, enterprise users, which have very specific needs. For these big users having guarantees is very important, for them it matters if you say "yeah, I think it will work" or "yes, I guarantee that it will work". Some people ridicule PHBs who ask "Who am I going to sue when it doesn't work?" but for them that's a big concern, not that they have much of a chance of suing with todays software licenses, but at least they will sleep better knowing that they have their own ass covered.

That said, that isn't a reason why the installed userbase couldn't be increased through grassroots efforts at the same time. Linux has reached many server-rooms through the grassroot efforts of techies and there are many more places where Linux can become a success through grassroot efforts, think of your friends and family, your aunt, your granddad. There is an enormous potential there. I think that that is also a very powerfull aspect of Linux: everyone can take it and modify it to better suit his or her purposes, and everyone can do so at the same time.

I think commercial success for Linux, in any market, is important because it adds to the credibility of the platform as a whole and it tends to makes more people available to improve it. On the other hand it is important to recognize that companies act in their own interest and not necessarily in the interest of the Linux community. I don't think IBM spends so much money on Linux because they fully agree with Richard Stallman, they spend it because they think it is an investment that pays off. Whatever their motives, the result is that quite a few extra people help out to improve Linux. I think that's beneficial for Linux.

6. What are you currently working on? Any exciting new projects?

Waldo Bastian: No, I only do dull things ;-) I am responsible for a fair amount of code in the base libs so I spend quite some time on bugfixes and maintenance work there and providing other developers with functionality that they need. I also am working on the kde-usability list to get usability issues resolved. Apart from that I'm working together with the GNOME people and others to create some common standards.

7. What are the top 3 changes that you would like to see in the Qt API to make your programming experience more confortable?

Waldo Bastian: The Qt API is very comfortable, I am very happy with it as is. There is a small change that I would like to see that would allow us to do icon-loading on demand, which would improve start up time. Lubos Lunak made a patch for that and that will hopefully be part of Qt 3.1. Apart from that I have a collapsable QSplitter on my wishlist and for the distant future I would like to see a more modular plugin approach for the various dialogs so that Qt-only applications running under KDE will automatically use KDEs file dialog etc.

8. What do you think about the development tools on Linux? Do you believe that the lack of tools or abilities like Purify, auto-vectorizing, recompiling part of an app while it's running, or incremental linking can have an impact on the overall quality and speed of the Linux applications?

Waldo Bastian: I think that the lack of in-depth development tools is being addresses rapidly at the moment. Since the start of this year we are using valgrind within KDE. Valgrind is comparable with Purify but much easier to use, Free Software and doesn't have a hefty price tag. Julian Seward really has done an outstanding job with that.

I can't comment on th auto-vectorizing part because I have no experience with that.

The recompiling and linking issues that you mentioned don't really influence the quality or speed of applications in the end, it's more that they make the development process itself more bearable for the developers. Especially compiling C++ is a relatively slow process at the moment. The GCC people are working on (or already have?) support for precompiled headers, and that will hopefully improve things quite a bit in the future.

One of the things that I still find lacking are good performance analysis tools. gprof works ok for a simple piece of C code, but for a typical KDE application it is inadequate. Also I do not know any tools that would allow you to look at system performance as a whole, taking into account I/O and the scheduling between processes.

Last week someone alerted me to some sourceforge projects that where working in that direction but I haven't had time to check those out yet.

9. How do you see Linux in the next 2-3 years? While Linux has already proved its success to the server market, what does it need to be done to be considered a viable desktop as well?

Waldo Bastian: I think it is very close to being viable, in fact I expect to see an increasing number of large deployments this year. I think the business desktop is viable right now, especially for organizations that have an IT department already. The consumer desktop is more difficult, partly because Linux still requires a certain level of expertise from its users, partly because the OEM market is under mob-rule from Redmond. I think Lindows is very bold in this regard by selling PCs through Walmart with a KDE-based desktop pre-installed. They will be a good test to see if Linux is ready for the consumer market.

10. Even with the changes in the KDE 3.x and even when using object prelinking, C++ applications are still loading pretty slowly on Linux. Is any work being done to the GNU/Linux Loader to fix the issue?

Waldo Bastian: The library loader that comes with SuSE 8.0 has changes which effectively cause the same level of improvement as "object prelinking". That makes object prelinking pretty much obsolete. That fixes approximately half of the linking problem. The other half is going to be fixed by "prelinking" support in the GNU linker. (I use quotes because "object prelinking" and "prelinking" are really very different techniques) I don't follow the issue very closely at the moment so I don't know if is part already of a stable release.

I'm looking forward to the day when this new linker is widely in use because then it will become painfully clear where the linker was causing the slowness and where it is solely to blame on the application developer. At the moment it is much to easy for developers to shift the blame on the linker.

11. Being a bit realistic, not many people are running KDE in anything less than 166 Mhz PC with at least 48 MB of RAM. Do you think that switching the actual code from pure i386-centric to use and require MMX at places that speed is critical, can help to significantly increase the overall speed of KDE? Would the KDE project consider a switch to require i586-MMX for the x86 version of KDE?

Waldo Bastian: The KDE project creates source code that runs on a variety of Unix platforms. It's up to either the end-user or the distributor to compile it with additional optimization options that it sees fit. There are few places where we provide processor specific optimized code, e.g. that makes use of MMX, mostly in the multimedia area, to take advantage of MMX when available.

e p (0)    43 Comment(s)

Technology White Papers

See More