Slashdot Mirror
KDE Developer Sirtaj Singh Kang Interviewed
highwaytohell writes "Sirtaj Singh Kang is a KDE developer and an official spokesman for KDE in Australia. In this interview conducted by the Sydney Morning Herald he talks about how the KDE project manages to maintain its hierarchy, where he sees KDE in the future, Linux portability issues and the relationship between Trolltech and KDE developers. The article gives a good insight into how maintainers and developers work to maintain one of the more popular window managers for Linux. Certainly worth a read."
Athlon Thunderbird 850mhz
512mb ram
Matrox G400 video card
Up to half a dozon clicks to open a folder because KDE is so slow and bloated.
I've got no desire to troll, but I know you'll mod this as such.
I just don't have will to upgrade my box every 8 months to the latest whiz-bang equipment just to have KDE (or Gnome for that matter) running at a speed faster than Windows ME on a Pentium. Improving speed and stability are far more important than adding features at this time - I think this needs to be realised.
I think for developers with 2gb of ram and the latest 533mhz system bus, it's easy to forget that all this fun-to-make eye-candy is not what users with sub $3,000 computers want. I'm not sure why I'm writing this. I'm just disillusioned with the direction I've seen Linux's desktop usability efforts go.
The trouble with trying to demand that KDE and Gnome be as fast as Windows (or Mac, or Atheos for that matter) is that those window managers are built on top of X Windows whereas the GWE subsystem of Windows is built directly into the kernel.
This means higher overhead for GUI work on those X-based windows managers because of the extra library calls and extra complexity that X offers. There is a lot to be said for the stuff that is in X, but much of it is simply not needed by most desktop users (remote windowing, as the most grievous example).
Its confusing enough for new users and irritating to everyone else. Why do we need the K's and the gears to proclaim "We own your computer!" Thats what Microsoft does and is one reason I have turned away. Let us brand our own computers, or better yet, leave the system unbranded. They are only tools, after all.
To me, KDE isn't a software development project but rather, a parade. They see how Apple and Microsoft like to throw parties and festivals for their releases, all in the name of marketing, and KDE sees this and gets the awful notion that this is an area they need to compete in. That marketing somehow matters to them. From this they get strange ideas that its wrong to change this branding, that every computer the software gets installed on is thiers.
I like the system for some parts, and not so for others: but I use it and appreciate it for the freedom it grants me. So my appreciations is noted. De-brand the desktop to make for a more useful system.
X is actually faster than the GDI for most things. Don't believe me? Benchmark it yourself? I've benchmarked it before, and for stuff like line drawing or bitmap blitting, X stands up well even to DirectX. The main problem is that the toolkits (ahem, Qt) don't really use X all that well. That said, a lot of problem is due to the fact that a properly fast KDE/GNOME desktop needs a lot of proper configuration. My KDE 3.1 desktop, for example, is as fast as WinXP for most things (expect app startup speed, but glibc 2.3 and prelinking should fix that) but it required some custom compiling and renice tricks to get it that way.
A deep unwavering belief is a sure sign you're missing something...
It's damn near time someone decided to scrap X and write KDE directly on top of the kernel.
But which kernel? Solaris? FreeBSD, IRIX? Linux? Probably the latter, I suppose. Not that you've excluded everyone else from using Linux, are you going to insist that GNOME and GNUStep be put in the kernel as well? What about XFCE? What about Blackbox, Windowmaker and IceWM?
And after Linus has a heart attack, who is going to revive him?
A Government Is a Body of People, Usually Notably Ungoverned
A good way to tackle this is to move as much code as possible out-of-line. I have a custom template container library where all of the major functions are implemented out-of-line - they work with void* pointers rather than a specific type. These void* containers are wrapped in a template class that just casts to/from void* and the templated type.
I've found that this approach is almost as flexible as the fully templated STL, and it compiles anywhere from 2-5 times faster and binaries are usually 2-5 times smaller than with STLport. (the improvement is even more dramatic in comparison with the inefficient GNU STL)
I've done a bit of research on this - the X architecture is not fundamentally flawed - it's just that some things are implemented poorly.
Current X applications do not sync with the window managers well enough. e.g. on Windows, window resizing is synchronous with repainting, whereas on X it is asynchronous - leading to a slow, "sticky" feeling and painting artifacts.
Same thing with mouse tracking - the X display refresh is not synced in any way with mouse position updates, so moving a window around feels "sticky."
I claim that it is possible to achieve as good a "feel" as Windows/GDI without any modification of the X architecture. However, window managers and GUI toolkits will need to communicate better in order to reach this goal.
The rest of the unix world seems to realize that the kernel maintainers should also handle the basic userland applications.
That's odd because the developers of Unix went on to write plan9 and that moves even more stuff out of the kernel and into the user space.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Same thing with mouse tracking - the X display refresh is not synced in any way with mouse position updates, so moving a window around feels "sticky."
This is actually fairly fundamental to the X paradigm, which is network-oriented. There needs to be no logic on the display device, so things like mouse movements are transmitted over the network for the remote application to see and deal with. It doesn't matter to X if the network is TCP/IP over a WAN or your localhost loopback adaptor. Therefore, it has to be asynchronous, or X would appear to just "freeze" while it was waiting for the network - better that it gives you some feedback and lets you keep working while it sorts itself out than to make you wait for proper synchonization of all GUI updates.
Sun solved this with NeWS which actually does put some interactivity on the display device - for example, you could click a button and the animation of it being "pressed" would be processed on the display and just the button-pressed event sent back over the network (X will have to send mouse-moved and button-pressed events one way, and drawing instructions to display the button pressing over the network). But NeWS never caught on because other workstation vendors weren't prepared to let Sun control the standard.
X is powerful, but it was never made to be fast, and never will be without sacrificing some flexibility. From the Windows perspective the opposite is true: it was made to be fast, and can't be made as flexible as X without sacrificing speed (try using an XP remote desktop over a WAN, for example, or PC Anywhere).
> KDE uses an html renderer (and hence - the
> related libraries) in its file navigator.
> Having a browser in memory is resource wasteful
> - this is why Win 3.1 and Win95 are so much faster.
Bullshit. Konqueror the filemanager does NOT I repeat NOT use an html renderer at all. Your statment was true for kfm. This was KDE-1.x, about three years ago.
If you do not use Konqueror for viewing html, khtml or kmozilla will not be loaded.
The speed difference comes from several factors.
1) Features. KDE has unicode support, i8n support, previewing, theming, is network transparent, loadable plugins....
Windows 95 is just crap compared to it.
2) Compiler and Linker. GCC is slow. The Linkers are slow. gcc favours correctness above speed. This is changing already with gcc-3.2.
3) Optimization pressure. There is noone willing to optimize for P100 with 8 MB ram, when a machine with Duron 800 and 256 MB ram costs less then 250 . Time is better spent on removing bugs and adding features than for optimizing for obsolete hardware.
Finally, KDE has become faster and faster. Optimizing too early gives shitty design. It is the last step.
KDE-3.1.x is a lot faster than KDE-1.x or 2.x or even 3.0 on a slow PC with enough (dirt cheap) memory. KDE3.x is more than fast enough on a PII-300 with 128 MB ram.
Moritz
And why did they interview them?
Ummm, because it was the Sydney Morning Herald, and those two were the Australian representatives of KDE.
Maybe they wanted an article on local open source developers?