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."
From the article:
/. then...
"There are always people who would rather talk about it than actually help with development."
So we can take it he reads
graspee
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.
That's a good point, and it's well known.
It's damn near time someone decided to scrap X and write KDE directly on top of the kernel.
Mooniacs for iOS and Android
I'v been using Qt since 1996, and I think it is the best written set of GUI classes out there. I also think C++ is the best compromise between performance and abstraction for graphical user interfaces. That does not mean there aren't some problems, however...
Does anyone else think that Qt should forward declare more classes than it does? The compilation time of Qt projects has went up five fold since Qt 1.x due to excessive of C++ templates. Sure there are ways to cope with it: distcc, ccache - but this is not addressing the primary problem - C++ compiles are too bloody slow and getting slower all the time.
On another topic, who else thinks C++0x should make provisions to forward declare templatized class instances? Including all these template definitions in every header file is complete death for compilation time: #include <string>, for example. Precompiled headers help a little, but are easily corrupted and the cause of many bad builds.
I like KDE3 better than KDE2, because when I swap from a console, it doesn't throw my mouse into the top right corner, but it's so bloated.
Even worse, there are now way too many configuration utilities...I can't keep them straight. Instead of adding features and bloat to make things easier for stupid Windows users, how about ganging together and documenting how I can to Task X from a console? Better documentation means that you don't have to dumb down the product, you just end up with smarter users.
Well, welcome to the world of *bsd.
Having separate userlands and kernels is a mess, and only linux is willing to deal with it. The rest of the unix world seems to realize that the kernel maintainers should also handle the basic userland applications.
That said, it's still time for someone to build a new UI server that isn't X. X is big, and X is nice for serving to a bunch of terminals, but it's a mess for desktop machines.
Mooniacs for iOS and Android
Repeat, KDE is no window manager but a desktop environment - kwin is the window manager.
And why did they interview them? He has nothing new to say likely due to that he is not much involved in today's KDE development (3 CVS commits until today this year). The second representive stepped back from the interview because of low involvement but with 7 CVS commits this year he has even contributed more lately.
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...
X11 performs well on my Maxine, a 25Mhz R3000 processor. It's not the CPU that makes the performance, it's the video card and how well written the driver is.
Most XFree86 drivers aren't as good as they could be. But that's obvious to most people.
If you haven't noticed the trend in computer science, it's that we trade performance for managability. C over assembler, C++ over C, Java over C++, etc. I'd rather have more logical overhead that freeping creaturism on the part of my X server.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
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
Yadda yadda... yeah, lets pull a Mozilla on X - that'll turn out well. *rolls-eyes*
--Giving to trolls for the benefit of us all
Actually export has turned out to be a sort of misfeature. Most C++ gurus have now realised that it doesn't really do what it was hoped it would do. See this - http://www.cuj.com/current/index.htm?topic=current
(Scroll down to bottom)
"Sutter's Mill -- 'Export' Restrictions, Part 2 Until further notice: the tariffs on export are too high for everyday use."
(The whole article is only available in the print version)
In fact the very first implementation of export has turned out to be a very pyrrhic victory as said by the developers themselves. Turns out that export will need some serious redisign before any of the other C++ vendors will use it. Certainly the intent was good and one needs something like export. But export as it stands today doesn't quite cut it. The basic problem. Its too complex to implement and use and it breaks some other very basic C++ rules when you use it. Also its implementers say that it would be very difficult to give the users a consistent set of rules/advice on how to use it without getting shot in the foot. So looks like we can all forget export for a while. No need to worry about GCC or others not supporting it. Lets all wait for export v2 for that. In any case the C++ comittee agrees that they did too much of an invention with that feature without having the requisite expereince inspite of C++ compiler vendors warnign against it.
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.
You may find remote windowing "grievous" and bloaty, but I know many people like myself who use this feature everyday. You have to remember that X is often actually run on servers (without heads, even). Sure, it might make more sense to have the remote server in a different package... oh, wait, it is. If you take responsibility for your own pacakage management it's not hard to slim X down (or any other *nix program, for that matter).
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
Assuming that Mono works well and there is a Managed C++ compiler, it is relatively easy for KDE to switch to Mono.
For Gnome switching will be much more difficult because their current C with GObject style can not be easily converted without a major rewrite. (You can, of course, still write wrappers, but it's not much fun to go back to such a low-level system each time you want to enhance the core libraries)
Another problem for Gnome will be that they have attracted many old-school hackers with their pure C policy. Do you think that they will they happily switch to C# for new developments?
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).
Please! Not more of this "X is bad for desktop machines" BS. Why is it that you trolls can talk about how bad it is, yet you can never offer viable explanations as to WHY there is a problem with it.
Give your machine a proper installation. Give your machine proper drivers for accelleration. Then come back to me and tell me what is wrong with X. I'll be waiting.
I was gonna mod you, but I figured I'd reply instead...
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).
This argument is pretty ordinary. PC anywhere, years and years ago, was much faster than X now. PCAnywhere could actually be usable over a 33.6kb modem connection, and the same can definitely _not_ be said for X. It wasn't wonderful, but it was usable.
Send lawyers, guns, and money!
I'll refer you to my reply to a post of similar nature, in which another troll (such as yourself) stated the same thing without backing it up with fact.
Enjoy...
> 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
I am willing to bet that your problem is bad configuration, in particular hard disk configuration. Check out hdparm, and make sure your disks are using DMA, etc.. (LinuxGazette has a write-up)
Bullshit. Both of them result in a call to graphic driver which , generally, is better optimized on Windows.
>>>>>>>>>
First, the graphics driver doesn't do all that much these days. For example, with Xft2 and sub pixel anti-aliasing, the graphics driver doesn't even handle blitting of text anymore. Second, it depends on the drivers. The NVIDIA drivers I use, for example, are just as good as the Windows version. That said, if it's a driver problem, it's not X's fault, is it?
They use it the way it was intended.
Every fucking Qt call of say QPainter maps almost directly to Xlib function.
What else would you have them to do ?
>>>>>>>>
Do you really believe that? Qt and GTK+ use X as basically a blit engine. They do all the drawing in pixmaps (in software) then blit the results to the screen via the X server. That's most definately *not* how X was designed to be used. There are also numerous issues about not using the protocol properly. Thus, I refer you to the recent thread on the X Render mailing list about XFree86's performance.
A deep unwavering belief is a sure sign you're missing something...
My God. I post a simple comment one day (I don't post to Slashdot a whole lot, if you read my user info) and the next day I see fifteen messages in response to my post, many of them simply saying I'm a troll.
I'm not trolling!
Guess what I've done. I run ratpoison now. The branding is far less apparent now with the lack of window decorations, but I still have that gear throbbing in the corner of Konqueror. I go to the help menu, and at the bottom is "About KDE".
Now don't get me wrong, it really isn't *that* important to me. I can live with some of the branding, I don't use many KDE applications anyway. But it would be nice to do without...
But I gather a lot of people disagree with me. That's fine, I like independent thinking. But that doesn't make me a troll.
Qt doesn't even use C++ -- they have this MOC preprocessor dealy to handle their signals-and-slots connections (delegates in C# speak), so they have invented a new language (C+++) which they handle with a macro processor (as C++ once was implemented as a preprocessor to C).
I'm just sharing this information because it may be useful to others in a similar situation:
GCC 3.2 compiles Qt C++ code 20% to 30% faster on average than GCC 2.95 with the exact same compiler flags.
for example compile times for $QT_DIR/examples/table/statistics/main.cpp:
g++ 2.95: 11.59user 0.15system 0:11.74elapsed
g++ 3.2: 8.32user 0.10system 0:09.04elapsed
every little bit helps.
For the record, the use of the -fno-implicit-templates g++ compile flag did not improve Qt C++ compile times at all in my tests. I guess Qt does not use as many templates as I had previously thought.