KDE 2.2alpha2 is here! Blessed by release master Waldo Bastian only a few hours ago, this release has a ton of improvements over KDE 2.1.x. You can view the ChangeLog or glance at the alpha1 announcement for an overall idea of some of the changes versus the stable branch. However, to discover the rest of the cool stuff -- such as the new regexp filter in KNewsTicker or the Kicker taskbar/extension improvements -- you'll have to download KDE 2.2alpha2 and see for yourself. As usual, source is available as well as binary packages (read our policy) for Mandrake, Red Hat, SuSE and Tru64. Debian users should check the regular sources. Keep in mind that this alpha release is not for people who expect a stable desktop, there is a short list of known problems already.
Comments
Cool, I was wondering when this release would come about. Thanks a bunch! Two questions for ya:
1. What is a Debian APT source for this release?
2. To compile from CVS, what version of autoconf should I use? (I have 2.50 and it is giving me a faulty .config script)
Thanks!
-Josh
I reported the problem and was told to use autoconf 2.13. But I won't downgrade. I will just wait until they fixed it to work with autoconf 2.50.
autoconf 2.5x has enough syntax changes that it's not going to work with KDE (and many other things) for a while; it's not a release version, anyway.
actually, search on lists.kde.org for 'autoconf' and you will find a patch to acinclude.
that patch + running 'autoupdate' should fix it
I just downloaded the DEB from debian.org foro autoconf 2.13. Dpkg did a nice, smooth downgrade and I got things to compile. Just hope that a full system update from dselect won't download the newest (2.50) from APT again and overwrite 2.13. Anybody know if that will happen, or will Dselect/APT respect my manual package downgrade?
Thanks!
--Josh
in unstable, there is a 'autoconf2.13' package. just download it, and install it. if you keep autoconf2.50 around, it will use autoconf2.50 when possible, otherwise it will use autoconf2.13
However, unlike CVS, the alpha2 tarballs don't need autoconf, so I will stay with them a while.
I was aimlessly surfing sites, and I thought to myself, "Self - why don't you see if the dot is back on the air?"
Imagine my surprise to see the server back online and the release is out.
Just made my evening here in Ohio.
Any improvements in applications loading speed? The longer I use KDE the more annoyed I become at the 5-6 seconds required to load everything. I have a VERY fast machine... I can imagine how annoying it must be for someone with P2 300. I've actually thought about trying GNOME 1.4 :)
Wouldn't it be nice if there was a revert button for desktop styles? Currently switching styles can also change the desktop color. It would be nice if there was a revert button that would change the style and color to the previous settings (like GNOME has for GTK themes).
Rimmer
PS - How about a fix for bug #25490 in KDE 2.2?
If you have a VERY fast machine then something is VERY wrong. I only have a Celeron with a slow harddrive, and no single KDE application that I use takes as much as 5-6 seconds to load.
You might try FreeBSD too, I heard they get some good performance.
5-6 seconds is an exaggeration. However the time for applications such as KMail and Konqueror to load seems like an eternity to load compared to their Windows equivalent.
Konqueror never takes more than a second to load on all my machines (from 400MHz to 800MHz).
On my PII 267MHz with 256 Mb Konqueror 2.1.2 takes 7 seconds to load after having just closed it, while running almost no other applications. I'm using SuSE 7.1 with their 2.1.2 rpms.
This is strange - I'm running on a Celeron 466 with 128 MB of memory, and it takes at most 1 second to start up, much less if another session is already open. My KMail got several folders and contains about 12000 mails in total. It takes about 3 seconds to start, which is quite long, but I guess it takes some time to load those index-files :-)
So there must be something wrong with your configuration or the RPMs are compiled without any optimization turned on (?)
I still find it strange that the speed differs so much on computers that are quite similar.
Btw. I compiled everything from source...but I understand not everyone wants to do that. Maybe RPM builders should get better instructions, or the makefiles should have faster 'default' settings?
It might be the X that is trying to load loads of fonts for each application that starts. I wonder how I can speed this up. I don't even have or need anti-aliased fonts.
Just for the fun of it, I'll try an optimized compile myself and report the speed.
Even after loading konqueror a few times I can't get close to 1 second... I'm amazed that konqueror loads the first time in 1 second on your system.
What distribution and kernel are you using? SCSI or IDE hard drive?
Please tell us the secret!
That's probably because you already had most of it loaded. If you had enabled HTML viewing in Kmail, for example, khtml would already be loaded. On the other hand, starting up Konq without the khtml stuff loaded (by any KDE app) is much slower.
Chris
Hard drive speed tweaks may be the answer. try this:
/sbin/hdparm -c1 -d1 -a1 -m16 -u1 /dev/hda
*note - the hda is the drive on my box... you may have a different device setting ie /dev/hdb or /dev/hdc ect
just a thought
This helped me a LOT! Things start up at half the time now and XMMS has stopped distort sound when I start a new process.
Is there more tuneing that can be done? Was I just lucky that these parameters was right for my HD?
Take a look at the difference in testresults by Bonnie in attached file.
I recently upgraded from a 180MHz PPro to a 1.1GHz Athlon, and I must say that the startup times for applications don't differ very much. I believe the speed of the harddisk is more important (I still have the old disks from the PPro :-P). I expected much faster startup times.
/trynis
This might make your day.
http://upx.sourceforge.net/
Hey Christian, I want more commercial grade applications open sourced and ported to Linux, preferably under Qt/KDE. Oh, yeah, and throw in the world peace too. Maybe you have link to something that might make _my_ day?
:)
I'll look into it =)
Do you have Anti-Aliasing installed? With a lot of fonts (like I have) things really slow down. I hear that the next release of XFree86 (4.1) should fix this.
It was suppose to be out mid to late May, so keep an eye out for it! :-)
-Tim
4.1.0 is already out
This copied from the xfree86.org site:
XFree86 4.0.3 update release available[16 March 2001]
XFree86 4.0.3 is a bugfix/update release. It is an update that is installed on top of the 4.0.2 release. The next full release will be 4.1.0, scheduled for mid-late May 2001.
Feel free to visit.
About 4 seconds to launch konqueror, used to be faster before I upgraded from kde-2.1.0
I have compiled kde from source.
Use Debian/Testing with XFree-4.0.3
AMDk6II-450 w/ATA66 7200rpm drives and 160 MB RAM
Supposedly there is a "speed hack" in CVS (which would be into this alpha release, I think). I'm not sure, but they were talking about it a few weeks back after the article about "An Analysis of KDE Speed".
-Josh
that speed hack would be called 'kdeinit' and it is already in kde 2.1.1 i tought
Well if you need speed gnome is the place to go lol. Wait time you fire up that speed demon Nautalus. Wow it really fly's.
Craig
Actually.. Nautilus 1.0.3 starts just as fast as Konqueror 2.1.1 on the same hardware.
Nautilus-CVS is actually more responsive and faster than Konqueror 2.1.1.
Of course.. The KDE-gang may have improved their load-time in CVS/pre-2.2 as well.
Cool and i have some ocean front property in arizona to sell you. Go sell crazy some were else we're all filled up here.
Craig
Craig, there's no need to act like KDE is omnipotent. GNOME does have several nice features that I miss somewhat from my earlier linux experiences(such as nested cabinets), and I think that in the future a merge will certainly be a good idea. If we get serious commercial gui development (and I think we will) having two DE's and two DE toolkits is akin to having two executable formats (except that porting between is much harder).
Please, stop the anti-GNOME stuff.
I Hear a lot of this merge talk. Sorry if i'm ignorante but how are the two desktops going to merge? Are you talking merge of the teams? Once Xiamian goes under i could see more gnome developers defecting across the wall but i don't see how there could be a merge of the desktops. Even if it would be technically feasable which i'm not sure that it could be i still don't think we would want to do it anyway. In the end there can be only one. If i sound too pro kde well this is the dot so i think i'm permitted that.
Craig
>How are the two desktops going to merge?
I believe it's techincally feasible, if not right at the moment. Haven't you heard about the work on the gtk wrapper? Even with the speed decrements, that will mean very little in a couple years as optimizations improve and hardware becomes much cheaper and faster.
>Once Ximian goes under i could see more gnome developers defecting
It isn't defecting! That's just what I'm talking about, we aren't in competition! We both have the same goal, to provide a good Open Source desktop enviroment to the masses, and there's no reason at all we can't help each other, since there is almost no profit motivation!
>In the end there can only be one.
Nope, not true. Although a merge would be good, development on either of these projects will stop only once developer interest stops, and that's highly unlikely at this point since both DE's have a major user following. If we don't merge, what could also happen is we could both move toward different but similar niches with the DE scope (similar to what happened with emacs and vim, imho).
>If I sound too pro-kde well this is the dot so i think i'm permitted that
I wasn't saying you weren't. Similarly, this is the dot, and I'm allowed to tell you I think you're wrong :-)
>Even with the speed decrements, that will mean very little in a couple years as optimizations improve and hardware becomes much cheaper and faster.
Sounds like what they said about java. Your wrong here its a bad idea.
>we aren't in competition!
Huh? Hello Mcfly
>development on either of these projects will stop only once developer interest stops
Reality check. The majority of development on gnome will dry up when the VC money dry's up. One down one to go.
Craig
>>Even with the speed decrements, that will mean very little in a couple years as optimizations improve and hardware becomes much cheaper and faster.
>Sounds like what they said about java. Your wrong here its a bad idea.
Actually, you're probably right about that. What about diversion? I.e. both projects become more specialized toward a particular purpose. Perhaps GNOME will move more toward embedded devices and KDE more towards generalized PC usage, or GNOME in the office and KDE at home.
This happened, imho, in a way with emacs and vim : both have a heavy following, and both are in the general catagory of 'text editors', and one could argue convincingly about either being the best. But lately (at least as I have observed) vim seems to be used more for web development, and emacs for compiled languages, although either can be used for the other one.
>>we aren't in competition!
>Huh? Hello Mcfly
No really. We aren't in competition! Why should we be? We aren't competing over profits, we both have similar goals and similar motivations, and there is no 'war' because the success of one does not mean the other will die.
This is because the sucess of any Open Source bazaar-style project is determined entirely on how much developers are interested in it.
GNOME is not dependant on commercial money right now in the same way KDE is not dependant on commercial money right now : any developer of either project would probably be working on it anyways even if they weren't being paid, money just speeds up the process.
Without VC gnome would'nt have Nautalus or Redcarpet or Evolution. Enough said.
Craig
No, not enough said. These programs are pretty core progs, being (i believe) in order a browser/fileman, an installer, and a groupware suite, but just because they were developed as commercial interest doesn't mean they or something similar would never exist.
I suppose that had kivio not existed, it would have been impossible for kde to ever have a diagramming app and python bindings? Of course not, kivio's help merely speeded up the process.
A merge is not going to happen. There are too many differences. However, there will certainly more cooperation on some projects which can be done separately of the GUI and you just need to write a frontend for it. The possible use of aRts in Gnome and a version of the Ximian configuration utility are some possible projects were such cooperation can happen.
>A merge is not going to happen
I dunno about that, I've seen some incredible things happen on both projects. Perhaps in the end developes will write using whatever toolkit they want, and at least a sort-of port will be possible due to two-way wrappers, albiet slower then normal. Have you seen the gtk wrapper project? I also seem to recall something called KIMP, can someone provide URL's for either of those?
I do have a Compaq Armada 1750 with a PII running at 300MHz. My experience is more or less the same. It only takes 4 - 5 seconds to load aplications here... ;-) And oh yes, I'm running the Alpha2 on RH7.1.
The applications are slow to load because you enabled anti aliasing. Current releases of Xfree do not cache anti aliased font information and it has to be re-processed each time you start an anti aliased application, hence the slowness.
Wait for XFree 4.1 or turn off anti aliasing.
On my system (p2 400, 256Mb Ram), XFree 4.03 + kde 2.2 alpha 1 with all eye candy turned on, I have to wait 45s between the moment I type startx and the moment the desktop becomes usable :/ (only 6 seconds with blackbox)
This is insane. I can report around the same numbers for my computer. Just a slight difference tho, my computer is a Cyrix 133mhz, 64megs of RAM. Not a speed daemon of any sort. (I've got KDE2.1.1, with all bells and whistles I couldn think of).
You should very well consider changing distros. I've been converting a few friends of mine lately from to Debian lately ("There's a condition for me helping you out installing your linux machine again...") and the typical comment I get is: "Man, this runs faster, what'd you do??". I don't know what's wrong with all those distributions, but there's something rotten in the state of Denmark, and its not the cheese in the cafeteria.
In one case, the guy swears its TWICE as fast. (And no, that doens't mean the 'old' distros had millions of daemons running in the background, or such obvious performance killers)
I'm investigating the issue right now, if anyone has seen this too, please contact me.
Yours Truly,
Christian Lavoie
Yeah, I noticed this too.
I was a long time Mandrake user before I tried out Potato and I haven't looked back.
I have two hard drives right now: Debian Sid (My main machine) and Mandrake 8.0 (for testing things like KDE alphas..) and the speed difference between the two is amazing!
I use Mandrake for an hour or two, go back to Debian and can't believe it's the same base OS and _identicle_ hardware.
It's too bad too, as all of Mandrake's bells and whistles are tempting. On the other hand, how often do you play with NIC/printer settings once they're working?
I've been working on the same Debian install from last October, Mandrake's been through several versions since then.
Debian is super-sweet. I love that I do apt-get update && apt-get upgrade and voila! up-to-date OS.
Getting back to the point, I also have no idea why Mandrake/Red Hat is so much slower. I run Apache, sendmail, VMWare, SSHd, OpenLDAP and a slew of other servers on my Debian box too, and it's zippy. I'd love to help you investigate these differences..
Ben
One of the best speed improvements you can get is by making your hard disks use DMA transfers. This will generally making things load faster.
Run hdparm /dev/hda to see what things are currently set as.
hdparm -d1 /dev/hda turns DMA on on hda.
It does make a substational difference. I think the speed difference between distros can be explained by different ones enabling it by default.
Sorry to disappoint you, but DMA was turned off on my system... (Why not? No clue...)
(Thanx for the tip tho =)
Are there any counter-advices to using DMA on HDs?
I think it is safe to use DMA, except on afew dodgy drivers/controllers.
Just thought of another speed up (well not so much a speed up, as a way to increase responsiveness which I think Debian uses) is to run X at a -20 priority instead of 0.
Be careful with hdparm and DMA. I destroyed my hard drive with it awhile back. No more hdparm for me! Back everything up first, or do it from a fresh install (where you don't have much to lose).
-Justin
The difference could be in the way distros partition and use the harddisk. Harddisks rotate at a constant speed, but have more data on the outer sectors than on the inner sectors.
That means, your first partition will have a higher transfer rate than the last one.
Spliting your harddrive in several partitions can make your linux system slow if you put them in the wrong order. Beginners should only use two partitions: hda1 for swap and hda2 for /.
...and you should always have swap before your system partition to make it fast and reduce head movements.
... and Linux sometimes seems slower than Windows because Windows is always in /dev/hda1 ;-(
Stefan