I believe that GNOME has significantly more developers than KDE. We would get a better idea if KDE published a summary of CVS activity like the weekly GNOME summary does.
This won't happen, though, if it would show less activity than is going on in GNOME. It would be interesting to see, however.
Summary of CVS activity is not a very useful thing. If I commit a new feature as 5 small changes instead of one large, does it make me 5 times better developer?
I also like KDE, but when I first installed it the memory usage was horrendous. I have 512Megs of memory and when KDE would load I would be left with about 50 Megs! (This is with almost everything else shut down, just X/KDE running) Gnome leaves me with alot more Memory,...
So you're claiming your KDE needs 450MiB memory? Wow, I wonder how I managed to run it on a machine with just 96MiB RAM and 128MiB swap (and a lot of free memory was still available).
Seriously, understanding 'top' or 'ps' output is not that simple as it seems. The formula for computing used memory from numbers given by 'top' is : Used_memory = mem used + swap used - cached - buff . Now go again to measure your memory usage, and if your number is still higher than 100MiB for plain KDE, there's something wrong with your install. For me, the number for a booted computer with plain KDE started is less than 50MiB (I'm not sure how much exactly and I'm not going to close all apps and logout just to find out).
Also, important portion of KDE's memory usage comes from gcc/glibc/binutils inefficient handling of C++ libraries ( see http://dforce.sh.cvut.cz/~seli/en/linking2 ). This is being worked on.
It would be nice if this got moderated up. I'm getting tired of repeating it.
And it seems like because of the kdeinit hack, starting apps is considerably slower if you're not using the KDE desktop than if you are.
You can avoid this by putting calling 'kdeinit' in some of your startup scripts called during starting X session, and preferably also calling 'kdeinit_shutdown' during the X session shutdown. This way kdeinit should keep running all the time, so starting KDE apps should be as fast as in KDE environment.
I hope you don't use the rpm, but compile the sources. The rpm (prelink-0.1.3) is awfully old and buggy. And you of course need recent binutils and patched glibc.
Re:Good grief!
on
KDE 2.2.2
·
· Score: 2, Informative
No. Actually the 5% speedup is caused by explicitly telling the Qt load routine the image type (i.e. png or xpm), so it doesn't have to find out itself. The icon server is under development.
Re:i'm going to suffer for this but...
on
KDE Wins 3 awards
·
· Score: 1, Informative
when i first installed kde2 it took me about five minutes to work out how to change the screen resolution and then i had to reset kde before it took effect. and don't get me started on the default setup's choice of font in konqueror.
Actually, these are X related problems, and KDE can't do much about it I'm afraid:(.
Doesn't change the fact that binding to C++ (Qt and KDE) is a chore, and C++ compilers are a minefield of weirdness. C++ is also slow and bloated - as you can see by running any KDE app, observing its start time and sloth like performance.
C++ itself is not slow and bloated, it's g++ and binutils that's awfully unoptimized for C++.
>I read this some tim ago on KDE KT Cousin [zork.net], >basically they say that KDE isn't that portable, and port to >Sun asch is going to take a while. GNOME is plain C and has >ran on Sun for a long time, so there's not so much trouble >to go through.
ROTFL. KDE runs fine on Solaris, and did a long time ago (just like on *BSD and even on *nix systems I've never heard of). On the other hand, I've heard rumours, that at the time Sun decided to join Gnome, Gnome actually didn't work on Solaris.
> And.. If Sun used KDE on their arch, they'd had to pay Qt >$$. That's pretty hard to explain to shareholders when >there's equivalent totally FREE option available.
> I'm not talking about government however;P
One doesn't have to pay TT for running KDE anywhere. You have to pay TT only for developing closed-source Qt apps (KDE apps as well).
This is interesting.
So you have running at the same time Mozzila, xmms, SO5.2, licq with "no slowdown", and you care about dcopserver making konqueror start 3 seconds longer ( on my K6/166, not on your 300MHz CPU ), and moreover needing 230kB RAM ( unshared, according to 'top' - you most probably don't know how to interpret the memory usage numbers ).
Those 7 other friends : some of them make konqueror and it's kio slaves have lower memory consumption and start faster, one of them takes care of mimetypes, next one cookies, and the rest is the kio slaves. So most people won't think it's necessary to provide the capability not to use dcopserver.
Qt had a C binding, called QtC. It was for Qt version 1.30 or so, and it probably still can be found somewhere. Anyway, nobody uses or used it, so there is no need of it. I personally don't see a reason why there should be a C binding if there is a C++ binding - it simply doesn't make sense to me. Qt has Perl and Python ( and maybe some more ) bindings, because they apparently are needed, but it doesn't have C binding now, because that's not needed.
Why can't all these idiots simply stop for at least a while... So KDE is a stranger with a candy ? And that ooh shining good-looking Gnome with themes that crashed all the time when it was 1.0 is then what ? KDE almost doesn't crash, looks good, works fine, I don't have to pay for it - it's good enough and I find it free enough. You're no better with your fanatism, Gnome is not the only choice... there are also other GUIs than KDE and Gnome. And, btw, Gnome is not truly free software, only public domain ( well, and maybe *BSD ) is truly free.
Oh yes, finishing ORBit. If I recall correctly, ORBit is not used in KDE because it simply doesn't ( or didn't at that time ) support things that were needed. So it would be a "bit" more that just finishing the C++ bindings. As for DCOP being crap... I'm actually neither CORBA nor DCOP expert, I just know what CORBA is and I've read both the ORBit and DCOP docs. The only real difference I mentioned was that there's actually no real difference between these two, maybe just DCOP being faster. Remote Procedure Call *shrug*. NIH... hey, that doesn't belong here, that's GNOME related.
Uhm, both KDE and Gnome are already pure open source GUI, aren't they ? ( btw, there are so many things that would be nice... me having 10000000$, no people using M$ Windows,... ). And, if you're so afraid of Troll Tech becoming next Bill Gates, you can start developing gtk version of kdelibs, and thus save the world.
The fact that KDE comes with its default window manager doesn't mean you have to use it. You can e.g. use Enlightenment with the current KDE 1.x . And, actually, most KDE apps need only the KDE libraries, so you can run them under Gnome as well.
There used to be C bindings, IIRC it was called QtC. But nobody used it, IMHO because C wrappers for C++ library is something really useless. It just shows KDE can have as many bindings as Gnome. Perl... I think there are Perl bindings, but I'm not sure. Anyway, if such things will be _really_ needed, they can and will be done.
Take a look at http://www.kde.org/applications.html ( and many other places ) and see all of the _freeware_ available. KDE dying because of lacking shareware ? A good joke. This is definitely not a reason for KDE to die. Also, if you sell your something for Gnome for $10, that not free. Oh, and btw, IMHO Qt is one of the reasons KDE is that successful as it is.
> KDE is tied to C++ C++ is better for GUI programming anyway, and since Qt has C bindings, Qt can have as many bindings as Gtk > KDE is not free Hmm, I don't have to pay for using KDE, I don't have to pay for developing free KDE apps. Ok, I know one has to buy Qt if they want to develop non-free KDE/Qt app, but this should actually make RMS very happy, shouldn't it ? > how is this FUD ? Unlike Mr. de Icaza, I'm too polite to answer.
Me, who's missing Sinclair BASIC bindings for Gnome.
Slashdot Mirror
The thing you're describing almost sounds like what KDE does ...
Summary of CVS activity is not a very useful thing. If I commit a new feature as 5 small changes instead of one large, does it make me 5 times better developer?
So you're claiming your KDE needs 450MiB memory? Wow, I wonder how I managed to run it on a machine with just 96MiB RAM and 128MiB swap (and a lot of free memory was still available).
Seriously, understanding 'top' or 'ps' output is not that simple as it seems. The formula for computing used memory from numbers given by 'top' is : Used_memory = mem used + swap used - cached - buff . Now go again to measure your memory usage, and if your number is still higher than 100MiB for plain KDE, there's something wrong with your install. For me, the number for a booted computer with plain KDE started is less than 50MiB (I'm not sure how much exactly and I'm not going to close all apps and logout just to find out).
Also, important portion of KDE's memory usage comes from gcc/glibc/binutils inefficient handling of C++ libraries ( see http://dforce.sh.cvut.cz/~seli/en/linking2 ). This is being worked on.
It would be nice if this got moderated up. I'm getting tired of repeating it.
> KDE is a good product, don't get me wrong. But why does it have to look just like MSFT's products?
The point is, it doesn't have to, it just can.
You can avoid this by putting calling 'kdeinit' in some of your startup scripts called during starting X session, and preferably also calling 'kdeinit_shutdown' during the X session shutdown. This way kdeinit should keep running all the time, so starting KDE apps should be as fast as in KDE environment.
I hope you don't use the rpm, but compile the sources. The rpm (prelink-0.1.3) is awfully old and buggy. And you of course need recent binutils and patched glibc.
No. Actually the 5% speedup is caused by explicitly telling the Qt load routine the image type (i.e. png or xpm), so it doesn't have to find out itself. The icon server is under development.
Actually, these are X related problems, and KDE can't do much about it I'm afraid :(.
C++ itself is not slow and bloated, it's g++ and binutils that's awfully unoptimized for C++.
>I read this some tim ago on KDE KT Cousin [zork.net], >basically they say that KDE isn't that portable, and port to >Sun asch is going to take a while. GNOME is plain C and has >ran on Sun for a long time, so there's not so much trouble >to go through.
;P
ROTFL. KDE runs fine on Solaris, and did a long time ago (just like on *BSD and even on *nix systems I've never heard of). On the other hand, I've heard rumours, that at the time Sun decided to join Gnome, Gnome actually didn't work on Solaris.
> And.. If Sun used KDE on their arch, they'd had to pay Qt >$$. That's pretty hard to explain to shareholders when >there's equivalent totally FREE option available.
> I'm not talking about government however
One doesn't have to pay TT for running KDE anywhere. You have to pay TT only for developing closed-source Qt apps (KDE apps as well).
This is interesting.
So you have running at the same time Mozzila, xmms, SO5.2, licq with "no slowdown", and you care about dcopserver making konqueror start 3 seconds longer ( on my K6/166, not on your 300MHz CPU ), and moreover needing 230kB RAM ( unshared, according to 'top' - you most probably don't know how to interpret the memory usage numbers ).
Those 7 other friends : some of them make konqueror and it's kio slaves have lower memory consumption and start faster, one of them takes care of mimetypes, next one cookies, and the rest is the kio slaves. So most people won't think it's necessary to provide the capability not to use dcopserver.
Qt had a C binding, called QtC. It was for Qt version 1.30 or so, and it probably still can be found somewhere.
Anyway, nobody uses or used it, so there is no need of it. I personally don't see a reason why there should be a C binding if there is a C++ binding - it simply doesn't make sense to me. Qt has Perl and Python ( and maybe some more ) bindings, because they apparently are needed, but it doesn't have C binding now, because that's not needed.
Why can't all these idiots simply stop for at least a while ... ... there are also other GUIs than KDE and Gnome.
So KDE is a stranger with a candy ? And that ooh shining good-looking Gnome with themes that crashed all the time when it was 1.0 is then what ? KDE almost doesn't crash, looks good, works fine, I don't have to pay for it - it's good enough and I find it free enough.
You're no better with your fanatism, Gnome is not the only choice
And, btw, Gnome is not truly free software, only public domain ( well, and maybe *BSD ) is truly free.
Oh yes, finishing ORBit. If I recall correctly, ORBit is not used in KDE because it simply doesn't ( or didn't at that time ) support things that were needed. So it would be a "bit" more that just finishing the C++ bindings. ... I'm actually neither CORBA nor DCOP expert, I just know what CORBA is and I've read both the ORBit and DCOP docs. The only real difference I mentioned was that there's actually no real difference between these two, maybe just DCOP being faster. Remote Procedure Call *shrug*. ... hey, that doesn't belong here, that's GNOME related.
As for DCOP being crap
NIH
Uhm, both KDE and Gnome are already pure open source GUI, aren't they ? ( btw, there are so many things that would be nice ... me having 10000000$, no people using M$ Windows, ... ).
And, if you're so afraid of Troll Tech becoming next Bill Gates, you can start developing gtk version of kdelibs, and thus save the world.
The fact that KDE comes with its default window manager doesn't mean you have to use it. You can e.g. use Enlightenment with the current KDE 1.x .
And, actually, most KDE apps need only the KDE libraries, so you can run them under Gnome as well.
There used to be C bindings, IIRC it was called QtC. But nobody used it, IMHO because C wrappers for C++ library is something really useless. It just shows KDE can have as many bindings as Gnome. ... I think there are Perl bindings, but I'm not sure.
Perl
Anyway, if such things will be _really_ needed, they can and will be done.
Not even GPL'd is truly free. Only public domain is truly free.
Enough said.
Take a look at http://www.kde.org/applications.html ( and many other places ) and see all of the _freeware_ available.
KDE dying because of lacking shareware ? A good joke. This is definitely not a reason for KDE to die.
Also, if you sell your something for Gnome for $10, that not free.
Oh, and btw, IMHO Qt is one of the reasons KDE is that successful as it is.
> KDE is tied to C++
C++ is better for GUI programming anyway, and since Qt has C bindings, Qt can have as many bindings as Gtk
> KDE is not free
Hmm, I don't have to pay for using KDE, I don't have to pay for developing free KDE apps. Ok, I know one has to buy Qt if they want to develop non-free KDE/Qt app, but this should actually make RMS very happy, shouldn't it ?
> how is this FUD ?
Unlike Mr. de Icaza, I'm too polite to answer.
Me, who's missing Sinclair BASIC bindings for Gnome.