NewsForge has caught up with KDE developer George Staikos to talk with him about the upcoming KDE 3.3 release, KDE's future, Konqueror, KWallet, freedesktop.org, KOffice and more.
The applications that you have issues with, kmail and konqueror have changed enormously even during the last year. The fix for khtml issues is to upgrade to the latest version. Kmail is almost a different application from 3.0. Hence, only the most serious security fixes will be backported. Indeed it is a manpower issue.
As for speed, you are missing the enormous optimizations that happened between 3.1 and 3.2. KDE finally started to feel snappy with 3.2.
Binary incompatibility during the 3.x series is a bug that would be fixed.
Derek, don't waste time with this troll, please :)
> Derek, don't waste time with this troll, please :)
This is the problem with KDE community. Every time some one says something politically incorrect, they get flamed.
Why *politically* incorrect? Just incorrect- it's the obvious consensus here and elsewhere that KDE has been getting faster with recent releases.
> Just incorrect- it's the obvious consensus here and elsewhere that
> KDE has been getting faster with recent releases.
So my experience is incorrect apparently.
Ask anyone who isn't incredibly passionate about KDE
(i.e. does not read the dot regularly for sure) and
ask them if it loads fast.
Perhaps it has been getting slightly faster with more
recent releases (again, it seems slower for me) but
as an overall trend it is getting slower. e.g. You
can't possibly tell me that it loads after than KDE 1 or 2.
That would be extreme BS.
KDE 1 or 2 are not recent releases. The whole thread was about the KDE 3.x series - why do want to compare it now with KDE 1?
> why do want to compare it now with KDE 1?
oops, wrong thread sorry. another thread was made a claim that it has been getting faster with _every_ release.
It loads and runs faster than KDE 2. It takes more memory maybe, but it's faster. KDE 1.x was a totally different architecture, and yes, KDE 3.3 is slower than KDE 1.x was.
> It loads and runs faster than KDE 2.
i really don't get it. i changed the hostname thing and it's made no difference. kde 2 was really really much faster for me.
then please stick with kde 2 if you like. it sounds like you're running hardware that is 6 years old. you might want to run software for that hardware. a troll indeed.
The problem is that some people talk about performance as "speed when inside KDE" and others consider performance to be "loading time".
Personally, I couldn't care less about loading time; I don't constantly reboot my computer and it's the performance inside KDE that matters. That part *has* been getting better (ie. 3.1 -> 3.2)
> > If you really need a version that old you might consider paying someone to
> > do the backports for you.
> That won't work - you need the actual developers doing it IMO.
Well, in many cases it could be the actual developer who could get paid. :-)
> Else other fixes get swept underneath the carpet (e.g. a structural redesign
> to fix some bugs can't be backported directly - must hack around it in older > branches).
Exactly, it's not a trivial matter, and that's why I consider it too much to ask from volunteers to make the same fixes in 3_3_BRANCH, 3_2_BRANCH, 3_1_BRANCH *and* 3_0_BRANCH (or to even more, if I take your comparison to Win98 "6 years" into account).
I'm using KDE at home and at work and I can live with regularly updating it (Fortunately, I'm in the favourable position to decide myself what I run on my workstation even though I'm just an employee... I know, not everyone is that lucky.).
> But I admit that most of us are volunteers so I can't do much more than my
> share. But if KDE is targeting the enterprise, this doesn't sit well.
A distributor with paying customers demanding such a long-time support and maintenance could step in here...
> A distributor with paying customers demanding such a long-time support and
> maintenance could step in here...
But as I said, I don't think distros can do a good a job as the developers themselves. They will miss important fixes.
> > A distributor with paying customers demanding such a long-time support and
> > maintenance could step in here...
> But as I said, I don't think distros can do a good a job as the developers
But as I said, the distributor can pay one of the original authors so they don't have to do it in their scarce free time after their normal day job. Free software is not necessarily about working for free.
Besides it seems that disributors *are* maintaining their older versions. Please read the posts by Scott Wheeler. It seems he knows what he's talking about.
> They will miss important fixes.
I don't think that's necessarily the case. There are tools like the CVS commit mailing list. There are announcements of important fixes. There's the CVS digest. Maybe others, I'm not working for a distributor. But most importantly, there's working with the community and in the community, even by paying the authors to do the grunt work. But I'm repeating myself.
> This is not quality. This is not supporting branches about 6 months after the initial release. Even MS gives more support.
There simply aren't enough developers, sorry.
> There simply aren't enough developers, sorry.
One might consider of course to strip down KDE core if that would be the case. Eg. yes building the mime/kpart/dcop/.. infrastructure, but no for a kcm module that configures Fn keys on sony laptops (no offence btw. just an example - actually I would favor replacing 99% of these kcms to kde-bindings script versions anyway - that would save some compile time :-)
The speed difference between Windows (98, XP, Server 2003) and KDE 3.3 is quite apparent.
At least start up time has been getting worse with every release. I remember the days of KDE 2 which boot in 15s on my 1998 computer. It now takes 60s. I just can't believe the people who claim that KDE is getting faster.
The MS OS often loads the user shell first, then the services. When I compare my 800mhz PC (with Gentoo Linux and KDE CVS) and my parents' 1800mhz PC (with MS os) I see that my PC doesn't boot faster, but login is faster on my PC. (maybe partially because no AntiVirus and Zone Alarm stuff needed)
Use prelinking, buy ram or every five years a new computer.
> Use prelinking
That actually seems to _slow_ things down!
> buy ram
256MB isn't enough?
> or every five years a new computer.
Even on my 2.2 Ghz Celeron, it's slow (about 30s).
> > Use prelinking
> That actually seems to _slow_ things down!
Then you're making something wrong. Or you tried objprelink.
> Then you're making something wrong.
Just letting Fedora Core 2's cron script do its work.
> Or you tried objprelink.
What's the difference?
Fedora Core 2? Above you wrote
> I'm using KDE_3_0_BRANCH
So, you did install KDE_3_0_BRANCH on Fedora Core 2 instead of using the contained KDE 3.2.2!?
Or are you just an inconsistent troll?
How is it so slow on your computer. I don´t have a 2.2Ghz (P4 1.6) and KDE loads in 6 completly in 6 seconds without any tunning in KDE startup script.
Your packages are probably not well built.
Or he's got that problem where the system can't find the hostname properly.
> Or he's got that problem where the system can't find the hostname properly.
Could you please let me know where I can find more info on this? I may be blaming the wrong people...
If KDE apps seem to take too long to start, even on a fast system, make sure the hostname you have in /etc/hostname points to 127.0.0.1 in /etc/hosts.
> So, you did install KDE_3_0_BRANCH on Fedora Core 2 instead of using the
> contained KDE 3.2.2!?
1998 computer: KDE 3.0 from bin packages, core of KDE 3.3 from source
2004 computer: KDE 3.2 from bin packages, with prelinking even
Hey, you have a 2.2Ghz machine? If I were you I'd do my development on that machine instead of the 1998 one you mentioned above....
> Hey, you have a 2.2Ghz machine? If I were you I'd do my development on
> that machine instead of the 1998 one you mentioned above....
if a sibling didn't hog it for playing windows games :( i would
"At least start up time has been getting worse with every release."
Well, I compared KDE3.2.3 to 3.3-Beta2, and found out it was exactly the opposite. beta2 booted several seconds faster than 3.2.3 did.
I'm just saying as a general trend it's been getting worse (actually, I am also surprised that you found 3.3 to be faster than 3.2 starting up as well, but anyway).
Needing to time startup "speed" improvements with a watch or having a splash screen means it's still too slow IMHO.
I'm really sorry, but I dont get it. KDE 3.0.3 is slower in every aspect, at least on my pc. I've seen KDE become faster with every release. 3.0.x wasn't really pleasant on my pc, but now 3.3.0 is out, it runs smooth. login times decreased, and most apps start faster.
Most of the perceived time these days is IO. Log in and log out to get your disk buffers full and you'll notice that things are still pretty snappy.
The problem is that naturally we've gotten to where a modern desktop uses a lot more data -- whether applications themselves or the data they load -- than it did a few years ago.
On the other hand, harddrives while they've gotten a lot larger haven't gotten a lot faster.
If you're waiting on the harddisk it really doesn't matter if you've got a 700 MHz Duron or a P4 -- it's still going to feel slow.
> The problem is that naturally we've gotten to where a modern
> desktop uses a lot more data -- whether applications themselves
> or the data they load -- than it did a few years ago.
But isn't there something KDE can do? A (fresh) Windows install
logs in _much_ faster than KDE.
That's because Windows and KDE do it differently. When you log in to KDE and you get to the desktop, it's fully usable with all services and background-apps up & running. In Windows, you get to the desktop fast, but the system is still far from usable. It's still loading the background-services and the like. The time it takes to get to a fully functional desktop on KDE and on Windows is propably more or less the same. Windows _might_ be a bit faster, but the difference is not that dramatic.
Windows only _appears_ to be faster since you get the desktop faster. But that doesn't mean it's faster in reality.
As KDE does not create packages it can not prelink them.
Modern glibcs (2.3) do pretty much all of the stuff that used to be advantageous with prelinking anyway.
"I'm just saying as a general trend it's been getting worse"
And I'm just saying that as a general trend it's been getting better and better on my computer. Ever KDE-release is a bit faster than the previous one was.
"Needing to time startup "speed" improvements with a watch or having a splash screen means it's still too slow IMHO."
How fast should it be then? After a fresh reboot, it takes something like 10 seconds for KDE to boot on my machine (3.2.3 takes few seconds more). Subsequent logins take about 4-5 seconds (about 8 seconds on 3.2.3). And since I don't reboot my machine constantly, starting up KDE takes about 4-5 seconds for me. Do you expect it to be instantenious?? I'm sorry, but that's just not going to happen. 4-5 seconds is good enough IMO. And it's faster whn W2K is on the same machine.
FWIW: I also run KDE on my ancient laptop. It has 300Mhz P2, really slow HD (hdparm gives it about 7-8MB/sec), 320MB RAM and unaccelerated vid-card. Of course KDE is slower there, but it's still usable. I should know since it's the only GUI I run on that machine.
> > "I'm just saying as a general trend it's been getting worse"
> And I'm just saying that as a general trend it's been getting better
> and better on my computer. Ever KDE-release is a bit faster than
> the previous one was.
So by induction on your argument, KDE 3.3 loads faster than KDE 1.0?
> How fast should it be then? After a fresh reboot, it takes something like 10
> seconds for KDE to boot on my machine
Yes that would be good but even on a >2Ghz system, KDE can't manage that.
> I should know since it's the only GUI I run on that machine.
Unfair comparison but try this: install a fresh Windows 98. It boots _and_ logs in in 15s on a 300 Mhz! (that's faster than the BIOS). Also on the same machine Windows Server 2003 logs in faster and apps pop up faster.
> So by induction on your argument, KDE 3.3 loads faster than KDE 1.0?
There is one exception: kde 2.0 loaded slower than kde 1.2. KDE 3.3 DOES in fact load faster than kde 2.0.
> Yes that would be good but even on a >2Ghz system, KDE can't manage that.
KDE startup isn't bound that much by processor speed, but hard drive speed.
> Unfair comparison but try this: install a fresh Windows 98. It boots _and_ logs in in 15s on a 300 Mhz!
Bullshit.. If you said that win2k loaded that fast, I would beleive you, but not win98. Later versions of Windows boot up much faster than earlier versions of windows.
> There is one exception: kde 2.0 loaded slower than kde 1.2.
> KDE 3.3 DOES in fact load faster than kde 2.0.
i can't comment much about the kde 1 series (used it for a day).
but I do remember seeing kde 2.0 on mandrake 7.2 loading in 15s.
Everything went downhill after upgrading to kde 2.1 (that was
when they switched the logo to the KDE with the clouds :) and
now I'm sitting here with approx. 50s load time.
> > Unfair comparison but try this: install a fresh Windows 98.
> > It boots _and_ logs in in 15s on a 300 Mhz!
try it and see.
note however, i do mean _fresh_ install (after the first boot
as well to handle all the useless firsttime things).
what a friendly KDE community. even if you consider me to be
a troll, that's not particularly polite.
> If you said that win2k loaded that fast, I would beleive you,
nein, Win98 is faster than win2k by a mile.
"So by induction on your argument, KDE 3.3 loads faster than KDE 1.0?"
No. There was a significant regression in 1.x ==> 2.0. But since then it has been getting faster. Usually the changes were pretty minor but it seems that 3.1.x ==> 3.2 was a big jump. And again, 3.2.3 ==> 3.3 is pretty big jump (but not as big as 3.2 was)
"> How fast should it be then? After a fresh reboot, it takes something like 10
> seconds for KDE to boot on my machine
Yes that would be good but even on a >2Ghz system, KDE can't manage that."
I have a 2.2GHz Athlon 64, and KDE does manage it. And subsequent logins are 4-5 seconds. So what are you complaining? 4-5 seconds is such a short time that you could't really do anything extra. even if it were cut down to 2 seconds!
"Unfair comparison but try this: install a fresh Windows 98. It boots _and_ logs in in 15s on a 300 Mhz!"
Or better yet: I could run DOS on that machine! I bet it would boot in 5 seoonds!
Seriously: I thought we were talking about serious operating-systems with top-of-the line UI's here?
Jep - I fully agree with you!
Its very fast and boots in 5 secs on my 2 Ghz system.
But during work, if I kill konqueror, its quiet annoying if it takes 2-5 secs after Alt+F2+Url to open ...
and then waiting 2-5 secs to let konqueror build up the page :D
But in my eyes its a question of fine-tune and benchmarking!
We should integrate it into the next kde-release and build up a quiality-feedback for resource-management! (Get loading time in combination with system-specs!)
A simple "Yes" at first kde-startup and
kde will check the startup/sysusage time (incl. systeminfo (mem,arch,ghz,hdspeed))
and send it to a central-database at kde.org or elsewhere.
So will will have all information where improvements a needed!
impossible ??? - Let´s render the impossible into reality !!!
"But during work, if I kill konqueror, its quiet annoying if it takes 2-5 secs after Alt+F2+Url to open ...
and then waiting 2-5 secs to let konqueror build up the page :D"
First launch of Konqueror takes about 1 second on my machine. After that, it's instantenious. Actual browsing is really fast as well.
I did think about KDE's boot-up time yesterday. Non KDE-users usually complain that it takes too long to start up. But those people compare it to something like Fluxbox ;). But we could try to make it faster.
What Windows does is that loads the desktop really fast and then it loads the background-services (so the desktop is not usable yet, it just appears to start up really fast). Maybe we could do something similar? Now, I have no idea how KDE's start-up process works in practice, so I don't know if this is doable:
When you start up KDE, it initializes the system-services, loads the desktop and the kicker and does other miscellianeous tasks. Could some of those be done in advance? I mean that when the user gets to KDM, the system would already load kicker, the desktop and some other things in the background. It would take few seconds for the user to type in his username/password, and that time could be used to start up KDE. When the user logs in, the kicker and desktop would already be loaded, and the system simply restores the session, which would mean that it configures the desktop and kicker according to the users settings. Besides Kicker and Desktop, there might also be other things that could be preloaded as well.
the theory is that when user logs in to KDE, it does not load all the stuff over and over again, it would already be loaded. Only thing that is done during start-up is to read the users settings and configure the desktop accordingly. this would take the best of the Windows-approach, but it would also make sure that when the user gets to the desktop, it would really be usable (unlike in Windows)
Now, problem is that there are people who use KDM, but they use other desktops as well (Gnome, XFCE, Fluxbox etc.). In that case, preloading KDE would be a waste of resources for them. That's why we would need a simple configuration-option in the Control Center ("Preload parts of KDE?" or something).
Unfortunately preloading kicker etc. would not work - they would be running as the wrong user.
Awww, crap :(. Well, it was worth a shot anyway :)
On the other hand, caching kicker and related programs by just doing fopen(kicker) ; read() ; close() ; could save a lot of time. As KDM waits for users to log in, KDM could be putting KDE programs into disk cache.
As disks are the main bottleneck, this would be win-win: fast and unobtrusive for fast disks, and a worth optimization for slow disks.
What makes you think disks are the bottle neck? This is rarely the case.
Hmm, unless there is a lot of very complex math to be done, hard-drives *are* the slowest part of the computed. It sure isn't the CPU, RAM or video card in the vast majority of cases.