KDE 3.1 RC3 is released and it is likely to be the last RC release. Download, install and report bugs.
KDE 3.1 RC3 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
KDE is the best desktop environment currently available to free *NIX users.
It is the most feature complete and user friendly by far with a great file manager.
However, the 3.x series KDE releases were sooo sloow IMO. Is the 3.1 any faster?
Gnome2 can’t compare right now (remember it is in developer’s not user release) in terms of features but it is much faster.
Anyone played around with this KDE enough to comment on the speed?
Well I’m running rc2 and I have to say it hauls. It’s remarkably fast, and in fact for what it’s worth it actually feels much faster than gnome (on my box). This could very well be a configuration issue with gnome, but while gnome apps do start faster, Nautilus and other apps feel sluggish in comparison to kde. In fact, on my box nautilus is almost unusable. Clearly, I’ve configured something wrong.
But, I don’t want to start a mines-bigger fest. GNOME these days is really impressive, and while I’ll happily stick with KDE (as a programmer, I prefer KDE’s APIs and design philosophy) I’ll continue to use GNOME apps where appropriate. I couldn’t get any work done without GFtp, even with KDE’s ftp ioslave for light work, gftp is just *better* when you need to do something more involved.
But what I’d like to say, is KDE needs to slow down the development process. It’s moving too fast, and I’m worried 3.1 will be released in a state which should, technically, be considered beta3 or beta4. I would like to see KDE STOP adding features, for let’s say 6 months, and just focus on bug squashing. I’m planning to go to a possible KDE hack-fest in philly in december to devote myself for a few days to bug hunting.
With regards to KDE speed, I think it’s fine. Apps start slowly, yes, but they run quickly — and that’s what counts, isn’t it? Furthermore, with a well configured system (which should be de facto for serious distros like SuSE and redhat) the slowness is marginal. Konq for me starts in ~2 seconds, KDevelop in ~4 or 5, KMail in 4 or 5, etc. Little apps in < 1. I have no complaints as long as they don’t crash — and these days, that’s pretty rare.
And, one more thing — I’ve managed to get fontconfig working, and with qt-copy and xft2 now I can manage my font’s in ~/.fonts! It’s great.
it loads stuff slow sure, but that will be MUCH better once every distro around and their mother begins to use ELF binary prelinking, which is a feature in the newer Glibc release..
With this, Konqueror went from starting in ~2 sec to starting in less than the blink of an eye..
Of course this prelinking stuff will benefit all of Linux.
@Shamyl Zakariya: this is not practical. If there is no official release for such a long time, a lot of untested code will pile up, making the next release even more unstable (because of the lack of syncing). You can’t stop people from writing features that they want/need…
The best thing to remove bugs is to do it yourself, as you intend to do…
I understand your point about the practicality; but KDe’s modular design means that that cool new IOSlave that you’re working on can just go into kdeextragear, or not go into kde at all but act as a third party addition.
Then, when it’s ready, it can go into kdelibs/kdebase. For example, look at VIMPart — instead of throwing a buggy new text editor part into kdelibs, it’s sitting in kdeextragear. It’s being debugged and all there, and when it’s ready it can be put into the main packages.
When I say KDE should temporarily feature freeze, I’m serious. As it stands, KDE does SO MUCH it’s amazing, and a fair amount of it can be extended through 3rd party addons. That’s why I feel like they should focus on making sure what’s in there is solid.
Secondly, I worry that the fast development pace of KDE might scare off businesses and companies that might be wanting to port their software. KDE may have pretty strong source compatibility (and, hopefully now with gcc 3.2 binary compatibility) but I can see companies being a little nervous investing time when they know that if it takes them 6 months to port some software to KDE’s APIs, it might already be out of date by the time it’s released.
I would like to see KDE STOP adding features, for let’s say 6 months, and just focus on bug squashing.
(…)
companies being a little nervous investing time when they know that if it takes them 6 months to port
There is a tread on this website about Linux gaining market only at the cost of Unix.
I like Linux but have given up on it. What you want is a Windows style of development. Stop for a while and polish and *serious debugging* is just not on the minds of this people. That’s only from a comercial application prespective developer that could be interested on porting his/hers application to KDE !
The other guys will tell you:
this is not practical. If there is no official release for such a long time, a lot of untested code
(…)
The best thing to remove bugs is to do it yourself, as you intend
Better not waste too much work time on this (KDE-Linux) people !
Linux will stay like it is for so long, it’s like that since I discover it (1999?).
Meanwhile, Mr. Bill Gates will keep laughing from it’s chair on top of the world.
My Linux box is SLOW. It has 256MBs of RAM och dual P200mmx. I used to run win2k as my main OS on it for a long time before I upgraded to a much faster athlon and with it XP. So I have installed gentoo on the old one (and after having my PSU totally die on me, I run the linux box as my main one for a short time). And I must say, even though I have doubled the amount of RAM since I ran win2k (from 128 to 256) KDE is dog slow, everything is painfully slow. We are talking ten times as slow.
So, it would be nice if KDE (and the XFree people) could make the goal for the next release (3.2 of KDE for instance) to be a massive improvement in performance. I suspect the problem lies with both KDE (bad redraws for instance), QT (which does draw a lot), and X (which is, painfully slow to say the least. When are you guys going to start using OpenGL to render everything?).
It should be easy to find stuff like overdraw. AND, why not implement double buffering in X? I hate that neither windows nor X has that…
There is a rather obvious grammatical error in your post:
It should be easy to find stuff like overdraw. AND, why not implement double buffering in X? I hate that neither windows nor X has that…
Do not use “neither” and “nor” in such a way again. You are bastardizing our language. Go to hell.
Have you tried ncftp ?
It is a command line, stand-alone tool but it is much better than all the other FTP client I’ve tried with Mdk8.2.