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
Money is sometimes a very good incentive, but sometimes things you work for money don't seem as much fun. It's hard to explian but it's true. When you get paid to build a system, it's not as much fun as when you build your own system. Myabe its the whole intrinsic vs. extrinsic motivation thing. My two cents.
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
This is a realy good idea, something like this should be done not only to GNOME but also to other window managers such as KDE. Even non linux based systems could need some work when it comes to memory leakage and optimization. This does'nt only help people with little RAM but helps everyone.. Hope everyone are willing to help.
Bits of News Giving you the latest bits.
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.
'cause a bloated gnome is just a hobbit... which is actually cooler.
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
Yeah, because GNOME is only developed by volunteer hermits living in caves at the moment. It's not like there are big companies paying developers' salaries to work on it or anything.
It's GPL therefore it's Free software. Whether people are paid to work on it or do it out of the goodness of their heart doesn't matter as long as their contributions are GPL.
Yeah I agree. I would certainly not call GNOME as a whole bloated these days. Since 2.6 or so they've begun to clean things up quite a bit, especially with Nautilus. It's actually usable now...
And as for the people complaining about memory usage... if you're running "top" with 512 MB of RAM and go "omg, 431520k used! It's GNOME's fault!" -- well then I don't know what to say to you. That is simply how Linux allocates its memory -- it uses almost all of it at any given time and distributes it between applications.
Is this motivation for people to find the bugs, i.e., there's some programmer out there thinking, "Hmm, if I do this and this, then Gnome will run three times as fast. Oh well, I'm a KDE supporter so I don't care." Or is this a way to reward all of those people who do care about Gnome and are working on it by giving them a specific area to concentrate on and then rewarding them for their hard work, in other words some programmer thinking, "Hmm, I've got some free time and I can either work on fixing eyecandy or fixing memory leaks. Guess I'll fix the memory leaks first and get a reward."
Everyone has been assuming that this is pure motivation, appealing to the greedy nature of people who aren't already contributing. I don't think that's the case. Generally speaking, those people who are good programmers and know the code well enough to actually identify and fix problem areas are probably already doing so. This "bounty" seems to be more a way of rewarding them and helping to give them a list of priorities.
the kernel development is funded by the OSDL, some are under the direct employ of redhat, and probably other companies (maybe novel, IBM, im not sure)
trolltech is a company that makes QT, and thats duel licensed, one license being GPL.
the firefox lead developer is employed by google.
many large opensource projects have people being paid to develop them fulltime, its a good thing because the source stays open.
I like this, from my observations it alwasy appears that OSS is a bit heavy on the memory while closed source tends to be heavier on harddrive and processor dependent (not to say it is bloat free, far from it). That said, I run Gnome 2.8 on my old Pentium 2 laptop with 128mb of RAM. It actually works decently well, other than the screen refreshes which can use up all my processor and still take a few days :) . It is quite usable though and future versions of gnome will hopefully perform even better.
Thank You Novell
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.
We might finally have the open source capitalism model that kills these "commie" snipes dead, and leaves proprietary competitors dead in the water. Offer to employ programmers by buying their labor in a contest! Leverage the open source on the Net to get as many job applicants as possible, who submit the finished work, then give the "job" to only a single winner whose superior work is used. The losers need only inspect the open source of the next version for any of their content to keep the process honest.
This creates parity for labor in the capital markets. Programmers can sell their labor as a packaged product, just as vendors can resell the programs to consumers. Programmers can market their code with better documentation, APIs and popular features. While integrators like Novell can get access to the labor market, without risking that the labor they're buying is better at job interviews than at delivering on deadline.
There is an issue of the "waste" of the losers' code submissions. But since these projects are open source, the losers can fork the project and compete with it. If the losers are really better, they can compete better with the original project - which itself might be forked by the original contest sponsor. Brand equity will determine winners in the long run, but the open source lets brand equity be earned by persistent quality, as determined by the consumer market, rather than the funder of the code.
Ladies and gentlemen, start your engines!
--
make install -not war
- 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.
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 ...
So, why does XP load so quickly? By accident?
Nope. it's because a lot of people put hard work into it.
puts ("Python r0cks\n");
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.
When you're like me, working through Univursity to pay for a computer science degree that's being paid concurrently, these are great. Rather than going to a soul killing job that has no relevance to my course of studies, but happens to pay me money, I can just do a mod to Gnome (which is relevant to my studies), and get paid 10 times my soul-sucking hourly rate.
This isn't for people who have jobs which pay them so much money they can have sexy-parties with hookers and blow every Tuesday, this is for people who need a little financial incentive to do it, or for people who aren't established and want to make some money while they're making their name. Obviously you're a hookers and blow kind of guy, so maybe you shouldn't send in any patches.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
One person attempted a hefty rewrite, but ended up forking to the Multi Gnome Terminal.
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
Sourceforge should extend it's donation system and create a bounty system. When you donate money to a project's bounty system, you get a vote for each dollar you give. People submit for the bounty, and then, you can vote for who will get the coding contract.
perception is reality
I just took a scan through all the bounties listed at the link and noticed a few things:
1) Many of the bounties are already fixed
2) The fixed bounties still haven't been claimed or paid after more than a year in some cases.
3) The bounty hunters all start early on the bounties, but then no progress for months while people wonder if it's being worked on.
4) Sometimes a patch is submitted, but it never gets applied by the coordinators.
5) It's very collaborative. Many are just a long thread of incomplete fixes that go on for years.
6) The patches often get lost after the original author gives up to it not being included after a period of months/years.
7) Changes often impact other projects, whose maintainers may not want thier project patched.
Frankly, I'm amazed that in some cases it takes 2 years to fix and patch a simple bug. Meanwhile, the source tree is changed, rendering the original patch unusable. Don't tell me how I should contribute to improve it. I was thinking about doing just that until I came to the realization of how horribly inefficient the whole process is. If I fix a bug, I don't want to wait 2 years, if ever, to get paid thank you.
Before you even touch any vector-to-map conversions you should make sure your disk IO is optimal. If you are reading/writing/opening any file more than once, you will see no measurable gain from adding binary search to some measly thousand element vector. If you are using the network without a pretty darn good reason, or not caching the results, you can forget about doing any other optimizations. If you need to start twenty daemons to run a word processor, you have some serious architecture design issues.
In other words: fix the slow stuff first!
Basic visual cues are "eye candy," the favorite intellectual fallback weapon to describe anything that makes you feel less elite for using it.
This isn't 1987 anymore. My CPU can handle drawing pleasing visual effects so that after 13 hours of programming, my eyes aren't fatigued.
And there's nothing better than "oops, something screwed up my registry, gotta delete it and start from zero."
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001