Slashdot Mirror
Bounties for Gnome Optimization
Eugenia writes "Novell and OSNews are sponsoring the memory reduction project led by Novell's Ben Mauer by providing bounties to developers to help to clean up bloat in GNOME and related programs."
← Back to Stories (view on slashdot.org)
...is to make it KDE. :-P
Things like this make me love OSS, an effort to vut bloat? when was the last time a closed-source software outfit (Microsoft I am looking at you) acctually tried to make the packege MORE efficiant? the simple answer is Never that I can remember.
True, GNOME terminal is a disgrace -- which is a shame, because GNOME generally is much better than KDE in the code bloat stakes. Seriously, KDE is a code bloat monster... the fact of using C++ is bad enough, but add in the QT mega-bloat and the generally shitty coding you find in KDE, and the result is hideous.
... that even with all that money and resources being thrown at Gnome, they can only keep up with KDE, not surpass it. ...
Yeah, right. We all know KDE is better than Gnome. Thats why nobody uses Gnome.
Maybe KDE has better design
Most certainly not.
You forgot two things though. It uses a proprietary widget toolkit and prioritizes features over functionality. Gnome does the reverse and some people prefer it that way. Not to mention Gnome uses less ram on my system then kde and gnome also follows a really good HIG.
Regards,
Steve
To explain my rebuttal of the "KDE has better design" claim:
i cle&sid=318
Gnome is more open in development. It allows concurrent solutions for the same problem. Later the best solution will get picked, and the other solutions are deprecated. This might sound like a pain in the ass. It is.
But the alternative (the approach used by KDE) is even worse. The requirements are collected and after that one solution is implemented. There are no alternatives to this solution. Just as you learned in your software engineering textbook. To bad reality doesnt play by the textbook rules. Requirements change all of the time - there is just no way to know them before you have a working implementation and its learned about limitations - there is no way to fix this later.
The different design approach resulted in a pretty crappy start for Gnome. But it is gaining speed (as you can see with the 2.X releases). KDE OTOH seems to seriously slow down the older it gets.
Some of these points can also be found here:
http://www.ofb.biz/modules.php?name=News&file=art