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)
I tried to optimize my gnome once with a suit of +2 leather armor and a new red hat, but he still ended up getting slain by a bunch of kobolds.
DecafJedi
my weblog: apropos of something
This is great news. I switched from KDE about a year ago because of the newer gnome interface. (2.4+?) I run gnome on FreeBSD 5-stable and found that my biggest complaint is the memory usage. I have a dual xeon 2.0 gig with 1 gig of ram and gnome + xorg eat up at least 200-300mb of the ram. Maybe while they are at it they can fix some other problems with gnome like the fact the default stack size needs to be increased in many non linux systems when porting it!!!!!
MidnightBSD: The BSD for Everyone
And the next set of bounties will be offered for cleaning up bugs introduced by rapidly encouraging people motivated only by money to make changes to Gnome without fully considering the ramifications of these memory reductions. :-)
I wonder if there will ever be enough bounty's on offer to make a career out of it.
I can just see all the coder bounty hunters with their boba fett helmets on.
The Borg assimilated my race & all I got was this lousy T-shirt
Gnome-terminal is going to make someone ridiculously wealthy. Seriously, there's so much room for optimization that a good coder will be able to retire off that one program.
REM Old programmers don't die. They just GOSUB without RETURN.
Offering money is a great way of getting people interested in many things, but do the people who are capable of creating valuable bug reports and/or patches really need these bounties?
I wonder how many crappy bug reports and patches are to be submitted because of the "easy" money being given. I do believe that the bounties will go to the right people and for the right reasons, but more the crap, the more it takes work to find the gems.
Nevertheless, it's about time to unbloat Gnome.
Tapio 'itn' Nuutinen
As you can see from Novell's actions they are totally biased towards Gnome but still they make more money out of Suse distribution which uses KDE extensively.
Feel the irony?
They should instead be desktop neutral and support KDE developers too...
Never learn by your mistakes, if you do you may never dare to try again
Please don't call KDE a window manager.
Both KDE and Gnome use window managers, but neither of them are window managers
(the fact that you can change which window manager is used by KDE and Gnome
is a good indication that they, themselves, are not window managers).
xwinman.org gives an excellent introduction to both window managers and
desktop environments. Give it a look.
*sigh* back to work...
Now, it seems that (finally) developers are looking at resources that our programs use.
Unfortunately, for many in developing countries (like me, here in Brazil) having a computer filled with RAM and with the fastest processor available on the market isn't an option.
For instance, my desktop has a Duron 600MHz with 256MB of RAM. That's the fastest computer to which I have access here and it is some years old, but still working fine.
I can't say how happy I am with this bounty for optimization of memory.
In Computer Science we always have this concern with both time and space complexity and it seems that if Free Software developers start caring about good data structures and good algorithms (and avoid layers and layers and layers of abstraction over and over), we can actually use our computers more efficiently.
Again, this is especially important for those who have to use computers of two or three generations ago.
A welcome movement indeed.
P.S.: If you have never felt the need for less memory comsumption, then you won't probably understand how important this project is and probably this post makes little sense to you.
- Remove all deprecated libraries from the codebase of the Gnome core.
- Remove or replace subsystems which never really were useful
- Make all demons optional
Yeah, I know that all would be a Herculean effort. Probably, it makes more sense to start with a lean and clean codebase like XFCE and just bring its usability to Gnome level, instead of cleaning up a bloated mess...In its history, Gnome has changed its libraries and subsystems several times, from imlib to gdk-pixbuf, from gnome-canvas to pango, from Corba to Bonobo to possibly Mono, from esd to gstreamer, and so on. Many Gnome apps still use older, deprecated libraries. Get rid of those libraries and port all apps to the standard core API.
I'm thinking of Bonobo and gnome-vfs here which are not consistently used in Gnome and whose quality and use value is questionable. If their functionality is still needed, it could be replaced by KDE's superior kioslaves and kparts (just as KDE is ditching its arts sound demon in favor of gstreamer)
Neither Gnome, nor KDE applications should be depending on any desktop-specific userspace demons. Make it possible to deactivate gconf, for example, and have applications read and write configuration files the classical Unix way, by one central switch. Make the sound demon optional, so that audio output could just be written (in old-fashioned, non-overlapping way) to /dev/dsp.
Etc.etc. The demons might have some use for some people, for for many, they are just bloat and unnecessary complexity.
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
The best way of ensuring that it stays fixed is to give all the gnome developers PIIIs with 128 Mb RAM.
There's no reason why a team of people couldn't work together daily, in a traditional "day job", to produce software to submit to these bounties. In fact, given that the risk of the code not making into acceptance by deadline is now borne by the coders, a team that's working on several bounties at once (perhaps in different projects) a better way to spread the risk. This model lets a team work on what they want, when they want, for whom they want, with whom they want. Without all the baggage that's bundled with a day job at the buyer of the code, including the mixed bag of projects assigned to team members.
--
make install -not war
In The Hobbit, gnomes were used to refer to the Noldor, but Tolkein changed that because of the stereotype gnome being short-and-fat and very unelvish (in the Tolkein universe). An overweight Noldor would look a lot like an overweight human. And, if the movies are to be believed, very gay, but I'm not buying that ...
While they've still got a long way to go, each successive release of KDE is substantially improved in terms of required CPU power and memory usage. KDE 3 ran a great deal faster than KDE 2 despite all sorts of added functionality, and KDE 3.4 RC1 is the fastest yet by a pretty big margin. The upcoming Qt 4 has a whole slew of performance improvements which should reduce requirements further.
The bounties Novell is offering are too low. They're offering $1-200 for tasks that will take an adequately skilled programmer, already familiar with GNOME, something like 2-4h to complete, including the docs that will let GNOME integrate the code (which will help win the bounty). The programmer doesn't need to spend time testing the code, though that will increase their chances of winning. So they're offering $50:h.
That isn't enough to support a community of coders, even if the range of bounties were scaled up to supply a significant headcount with enough work to keep busy (say, 500-1000 bounties a year). The labor might be fueled by people who are coding GNOME anyway, to prioritize completion/submission of some tasks. But the better, even more productive coders won't be available at those rates. It remains to be seen whether a multitude of mediocre submissions can compensate for too-cheap bounties that can't attract quality coders. Or perhaps this model will merely send all coding offshore, to programmers who can work so cheap that a single $100 bounty won can fund a month of unsuccessful submissions to other bounties they lose.
--
make install -not war
Seriously... I've spent a very significant amount of time optimizing four shipped titles now--mostly games, one commercial shrinkwrap application--for both speed and size tradeoffs.
The big annoying thing with optimization is that assuming you are working with talented people (I believe the people who work on GNOME are talented), there is generally little low-hanging fruit. An example of low hanging fruit is places where you are using--for example--a vector, but you should be using a map or a hash table. Another example is places where complex code can be skipped over by checking some preconditions and bailing early.
Although premature optimization is the root of all evil, most of us recognize these sorts of places early, and do the relevant optimization work in the first place. What you're left with in terms of optimizations is places where your initial architecture is *just wrong.* This kind of performance / memory deficiency really sucks, because most of the time the code is too complex and there are too many other dependent pieces of code to do the necessary rewrite.
The other thing that makes optimization work hard is (lack of) tools. There are basically two types of problems you can optimize: speed and size. Sometimes you get lucky, and fixing size problems *also* increase speed (generally because your smaller code now fits in the instruction cache, or because your data memory fits in the L1 or L2), but that is usually the exception. With size problems, the best bet is usually to make all objects pooled individually. This allows you to dump out information during the program run as to how many objects you've allocated of a particular class, as well as how much memory they're taking up.
With speed concerns, it's a little more difficult. There are basically two types of speed problems. Problems that occur constantly, and problems that occur as a result of user interaction or are themselves cyclical. Effectively it's a matter of identifying spikes versus identifying plateaus. Plateuas are the easier of the two, because they are identifiable via tools like Intel's VTune (which has been--I believe--ported to Linux by Intel). But spikes are harder, in that identifying them requires code instrumentation, and although there are some suites that will do it automatically, they often over instrument places which lead to artificial spiking.
Anyhoo, sorry for rambling... optimization is something very near and dear to my heart.
I currently have no clever signature witicism to add here.
I think this is a horrible idea. When you have to offer bounties to encourage people to alter open source, then you're basically hiring and paying programmers...Open source isn't about hiring and paying people, it's about everyone working together to make better software for themselves.
I think you are confusing Open Source Software and Ken Kesey's Magic School Bus. One solution to this problem is for your to do way less drugs.
Here's a reason: Most people with the experience needed to do this work easily make well over the ammount these bounties offer (~$200 for something that is very non-trivial) in less than a day or two at their day job. The bounties are simply added incentive to fix messy problems, very rarely will you see somebody take them on unless they already wanted to scratch that itch.
What I would like to see is the ability for me as a user to add to the existing bounties and start new ones of my own. I would like to be able to propose a bounty and send money to a reputable bounty clearinghouse like at Novell or Ubuntu, and then they could offer the bounty as if it was their own since they have my cash until the bounty expires or is completed. And then while the bounty is still up for grabs I would like to be able to send the clearinghouse money to add to the existing bounties in order to make them more lucrative to potential hackers.
I could setup this site right now fairly easily, but people wouldn't trust my joe random site as well as they would trust a bigger and more established organization like Novell or Ubuntu/Canonical. But I can't be the only one looking to put my money where my mouth is, so why does this functionality not exist?
501 Not Implemented