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)
Take out all the GUI eye candy and that will speed up about 50% on older systems.
What is your experience with new Linux on old hardware? I now believe that older Linux versions should be used; or, one of the light distros.
On a dual boot P233 with 64MB of RAM:
Win XP feels less sluggish than 2.6 with gnome.
The newer Linux stuff just requires more memory.
aterm is GPL, right? excellent
1. Rip out gnome-terminal and piss on it
2, slide xterm or aterm into its place
3. Profit?
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.
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
The key question is, why should Novell support it? Anything built with Qt needs to either be open source or be licensed to TrollTech. This isn't a big deal for Novell's own projects but when they're pushing a Novell libraries that have to be used by outside developers, they're going to want to base it on something that doesn't put additional licensing burdens on developers (Win32 development doesn't carry licensing costs).
If GNOME didn't exist, they'd likely put their backing on GNUstep or (god help us) Motif.
Stuff like Mono, which is heavily GNOME centric and runs on Win32/Linux/MacOSX, only makes the decision easier. They can plug "write-once-run-anywhere" for Novel libraries.
Of course, things may change if TrollTech found a way to make money by relicensing Qt to LGPL (or modified GPL as in Classpath) and provided seemless Java binding that can be used with GCJ and other free Java tools.
OTOH, if corporations focused on KDE, it would likely be optimized for simplified as GNOME is (and likely dump duplicate works like KOffice in favour of OpenOffice and Konq in favour of Firefox for browsing the way Epiphany/Gnumeric/Abiword is shoved in the background for more modern GNOME distributions). The KDE community is strongly against such moves, so even with these changes they may end up going back to GNOME because GNOME's culture is very receptive to KISS elegance.
So in the end, there are several non-technical issues why corps prefer GNOME.
No big deal. Lack of corporate support hasn't stopped GNUstep development and it would stop KDE development.
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.
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.
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.
If you think your RAM total is 100MB, you probably are crazy :) Base 2, remember? ;)
But yeah, GNOME is really inefficient, imho. I blame it on C and CORBA: in KDE, which is based on C++ and DCOP, it's obvious that components are integrated, and that code is shared in an object-oriented fashion. By comparison, GNOME feels like a few apps sharing a framebuffer and a widget renderer.
It's a shame, I really want to see GNOME take off, but I think the underlying technology choices really hold them back.
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
I run kde successfully in 62mb of ram
I am trolling
I think it's mostly pragmatism. KDE doesn't make boneheaded decisions out of zealotry or theoretical merits. And KDE people seem not to get as attached to their bad decisions as GNOME people, if they made a mistake they will fix it.
I am trolling
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.
It's not proprietary. Get your facts straight, please.
Also, KDE 4 will be very interesting: it's undergoing a complete HIG review, and there will be a lot of deep changes. Luckily, the features and solid architecture are already there for the new interface to take advantage of - unlike Gnome.
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!
I can vouch for this, the KDE desktop and all of its apps are nice and snappy on my aging Athlon 750. To put this in perspective, Firefox--a widely acclaimed "small footprint" browser--feels like bloatware in comparison. I use it over Konqueror only because I can use the Adblock and Googlebar plugins with it.
There isn't a file manager I'm personally satisfied with.
...) - it even provides a desktop and will automatically mount and unmount devices, if that floats your boat (you don't need to have it enabled)
Have you had a look at ROX? It's small, fast, and has some nice shell integration (eg. you can navigate directories/files as you would in bash, with tab completion, etc; you can run shell commands in a minibuffer; a command to open a terminal at the directory you're browsing
Personally, I use IceWM for windowmanagement (it's fast, more themeable than *box variants and provides a nice taskbar) coupled with ROX. I noticed the other day that this combo is what VectorLinux provides as an alternative to KDE, so obviously I'm not the only one using the two.