Post a Comment
Everyone is trying to pull up Gnome's socks in terms of startup time and performance, which is really great.
Also see Nat's blog about his idea of replacing the gnome startup script. Lots of good info on planet.gnome.org for those that are interested.
Looking forward to Gnome 2.14 
RE: The pit is deep and the problems are big.
http://nat.org/2005/october/#Keep-It-Simple-Stupid
is The link I belive someone above mentions, and nat greatly improved start up time with this script. so expect to see gnome with much faster start up times in the future.
combining this with other perforcmence stuff and the GTK, performence stuff, stuff help gnome greatl;y.
-Nex6
-nex6.blogspot.com
RE[2]: The pit is deep and the problems are big.
from http://www.archivemag.co.uk/gloss/T.html
Troll: a newsgroup post that is deliberately incorrect, intended to provoke readers; or a person who makes such a post
hope this helps you IP: 84.31.152
"Please reduce memory usage, GNOME is so slow compared to everything else."
See http://live.gnome.org/MemoryReduction
"Then drop some useless pieces of software (evolution, epiphany to name the worst ones)"
What, pray tell, makes Evolution and Epiphany "useless." That's a fairly strong statement. If you like, say, Thunderbird and Firefox better, that's fine. Why denigrate other possible choices, however?
"stop stupid debates like java vs .Net and just use C !!! God, GNOME lacks of direction..."
That debate doesn't appear to have flared up in awhile. The Novell people like to use Mono. The RedHat people like to use Python and Java. The general developer community appears to like C, C++, python, and Mono.
As for lack of direction, the active developers set the direction by what they want to hack on. There's no dictator saying, "This is what we will do!" That is not the way KDE works either. That said, the GNOME people are putting more and more effort into GTK+ regarding speed, memory reduction, and additional useful cross-platform widgets. The goal is to make GNOME a thin layer above GTK+.
It appears to me that much of the current GNOME work is happening in the infrastructure level: cleaning up APIs, adding widgets, consolidating libraries, etc. It's fairly exciting from a developer standpoint, especially when you factor in Cairo and D-Bus.
Looks like startup is an issue for more programs. Recently Michael Meeks has done some research to speed up OpenOffice.org's startup time. One of his conclusions: "So part of the problem is kernel work"
http://www.linuxformat.co.uk/modules.php?op=modload&name=News&file=...
Maybe the kernel hackers should look into these kind of problems.
Just wanted to congratulate Lorenzo on an excellent piece of work, and a great article (even though it's still in draft format).
Rarely do we see analysis of this depth, and too often we see and read comments of pure conjecture and speculation. Many of the comments here fall into that category.
bootchartd seems a fantastic resource, and combined with strace et al. form a formidable tool for quantative analysis. I only hope the technical barriers to the solutions mentioned are overcome and implemented.
And lets home Lorenzo and others like him move on to other subsystems in Linux, and pick off the low-hanging fruit if nothing else, we can all look forward to fast, tight Linux distrobutions that rock. Oh, for those that think they have that already, I'm sure that could run even faster . . .
i'd really like to see something done with the init before that. init is really getting of age and is not the best/flexible thing to have on a desktop.
overall the bootup time is step in the right direction. it is essential for full linux laptop experience. the next step is really working standby/hibernate.
I'm very impressed by this well done analysis and carefull proposal of solutions. There are few open source developers out there who actually spend time on such "boring" activities as improving startup time or reducing memory usage, as normally you don't get so much fame as when implementing new features.
Thanks to googles summer of code and of course to lorenzo for this nice work. I hope to see some of these improvements in the next gnome version.
Seeing how this kind of work isn't that hard, compared to actually implementing optimizations, the question is: How do we encourage this kind of work?
Research is an area that really lacks resources in OSS-world. How do we create an environment where serious resarch like this is the norm?


