|
|
Subscribe / Log in / New account

Giggle: A Git GUI

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

By Jake Edge
June 2, 2010

In the roughly five years that the Git distributed version control system has been around, it has gained quite a following. But at its core, Git is command-line oriented, which doesn't necessarily suit all of its users. Along the way, various GUI interfaces to Git have been created, including two Tcl/Tk-based tools that come with Git. Giggle is a GUI front-end for Git that is based on GTK+, which released a 0.5 version in late April.

The two tools that come with Git are oriented for two separate jobs: gitk is for browsing the repository, while git-gui provides a way to change the repository by committing files, merging, creating branches, and so on. The combination provides fairly full-featured access to Git but, because of its Tcl/Tk-based UI, lacks much in the way of eye appeal. In addition, those tools don't integrate well with a GNOME desktop, visually or functionally, which is what Giggle (and others) are trying to do.

Giggle combines both the repository browsing and changing functions into one program, but the feature set for the latter still lags git-gui. There are two modes in Giggle: "Browse" for looking through the source tree and "History" for looking at the commits in the repository.

[Giggle browse]

Browse mode has a three-panel view, with the source tree on the left, any currently selected file's contents at the top right, and a log and graph of the revision history of the file at the bottom right. Clicking on earlier revisions in the history section changes the file pane to show that revision as one might expect. In addition, hovering over lines in the file pane brings up a pop-up with the commit information when that line was added, so you are essentially always seeing the equivalent of git blame.

Other operations, like editing or committing a file, creating a branch or patch, etc. are also available in browse mode. Double-clicking on a file name brings up an editor, though how it chooses which editor is a bit of a puzzle. For the Linux kernel repository, it decided that Emacs was a good choice, but for the LWN site code, KWrite was deemed the proper choice. Presumably the latter comes from some default editor choice down in the guts of the KDE preferences, but it's unclear where Emacs came from—perhaps the different implementation languages (Python vs. C) played a role.

That points to one of the areas that makes Giggle somewhat difficult to use: lack of any documentation. It's easy enough to click around and figure most things out, but a small users' manual would not be out of place either. In addition, the "click around" method of figuring out Giggle runs afoul of its other main deficiency: performance.

The performance of Giggle is rather poor, especially considering that the underlying tool has a definite focus on speed. Starting up Giggle in a Linux kernel repository takes 15-20 seconds of 99% CPU usage before there is a usable interface. That might be understandable for a large repository with many files and revisions, like the Linux kernel, but the performance was much the same on a much smaller repository.

It's not just startup that is slow, either. Switching from browsing to history mode can sometimes take up to ten seconds. When scrolling through history, Giggle will just pause and eat CPU for a while. Overall, it is a fairly painful experience, especially when compared with gitk, which seems quite snappy. Giggle also suffered from a few crashes and hangs in an hour's worth of using it.

[Giggle history]

History mode has the git log output in the top panel, along with the commit graph. Once a commit is chosen, the files affected are shown in the lower left. Each file can then be selected to show the diff output from each change made to that file in the lower right pane. There is no side-by-side comparison of old vs. new versions that other tools have, which might make a nice addition.

The project has been around since it was created in a January 2007 hackathon, and has slowly added more features. Development releases have been fairly frequent of late, more-or-less monthly since January, but before then things seem to have stagnated for almost a year. It is unclear what the plans are for 0.6 and beyond, though the list of open issues gives some ideas of the kinds of bugs and features that will likely be addressed.

There are other fairly active Git GUI programs available including git-cola, a Python/Qt4-based program, and gitg, which also based on GTK+. The latter is meant to track Git clients on Windows and MacOS to try to provide a consistent interface to Git on all three platforms. In particular, it closely tracks the GitX interface for MacOS X.

[Gitk]

Other than purely visual attractiveness issues (and Tk definitely has a fairly clunky look and feel), it doesn't seem that Giggle and the other Git GUIs really provide very much beyond what gitk and git-gui do. That may explain the fairly slow pace of development for those tools as anyone who really wants a GUI interface to Git already has one at hand. It's also likely that standalone GUI interfaces are less interesting to those who are used to integrated development environments (IDEs) like Eclipse.

In the end, a GUI is supposed to make a tool easier to use, but Giggle does very little to make Git more approachable. The user still needs to understand a fair amount about Git in order to use the tool effectively. Once they do, using the command line may not be that much of a burden.



(Log in to post comments)

Giggle: A Git GUI

Posted Jun 2, 2010 17:52 UTC (Wed) by Sho (subscriber, #8956) [Link]

My personal favorite is <a href="http://digilander.libero.it/mcostalba/">qgit</a>. It's a very nice Qt4 git repository browser. Unfortunately its website is poorly maintained: The changelog ends at 1.5.7 and the download link points to 2.0, even though the newest released version is 2.3. Fortunately distros have picked up regardless.

EGit?

Posted Jun 2, 2010 19:57 UTC (Wed) by dmarti (subscriber, #11625) [Link]

EGit (git for Eclipse) has a pretty good EGit/User Guide. Anyone using it?

EGit?

Posted Jun 2, 2010 20:16 UTC (Wed) by fb (guest, #53265) [Link]

I use Eclipse all day, and I find Egit very poor. Documentation is ok, but functionality is seriously lacking.

Giggle: A Git GUI

Posted Jun 3, 2010 1:56 UTC (Thu) by sandsmark (guest, #62172) [Link]

QGit is very nice, though it seems the changelog stops with the last release based on Qt 3.

What would be even more awesome, though, would be a proper git library, so that applications that want to manipulate git repos wouldn't need to resort to invoking the various git binaries to do what they need.

Giggle: A Git GUI

Posted Jun 3, 2010 15:24 UTC (Thu) by waucka (guest, #63097) [Link]

Giggle: A Git GUI

Posted Jun 3, 2010 15:37 UTC (Thu) by wingo (guest, #26929) [Link]

Interesting link, thanks. Too bad it's GPLv2 only; I have an LGPLv3+ project I'd like to use it with.

Giggle: A Git GUI

Posted Jun 5, 2010 4:37 UTC (Sat) by jrn (subscriber, #64214) [Link]

The libgit2 authors provide some additional permission on top of the GPLv2:

In addition to the permissions in the GNU General Public License, the authors give you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combined executable.)

This is the traditional GCC runtime exception.

In other words, it seems that the libgit2 authors, at least, would not mind seeing you use the (unmodified) library from your LGPLv3+ project.

Giggle: A Git GUI

Posted Jun 3, 2010 15:39 UTC (Thu) by epa (subscriber, #39769) [Link]

I know of the libraries Dulwich (for Python) and Git# (for C#, etc) as independent implementations of git.

TortiseHG

Posted Jun 2, 2010 19:35 UTC (Wed) by JohnLenz (guest, #42089) [Link]

I use both git and mercurial, and when I am using git the thing I really miss is TortiseHG. TortiseHG is fast for browsing repositories, it is easy to stage changes visually during commit, and lots of other nice things. TortiseHG is better than all of the git guis I have tried, plus it has tons of documentation.

I also like that you can use TortiseHG from the command line (at least on linux). I don't even install the nautilus plugin, just use it straight from the command line.

Maybe someone should look into generalizing TortiseHG to work with both mercurial and git.

TortiseHG

Posted Jun 2, 2010 20:08 UTC (Wed) by Zariel (guest, #60868) [Link]

TortiseHG

Posted Jun 2, 2010 20:51 UTC (Wed) by JohnLenz (guest, #42089) [Link]

Looks like that is windows only; I am looking for something that works on linux. Also, I am not looking for shell integration, just a gui that can be launched from the command line.

TortiseHG is not a port of TrotiseSVN, they just have similar names while it looks like TortiseSVN is just a port of tortisesvn.

TortiseHG

Posted Jun 3, 2010 10:19 UTC (Thu) by njd27 (subscriber, #5770) [Link]

They have been planning to add git support to RabbitVCS (a Nautilus extension which behaves a lot like TortoiseSVN) for a while.

http://www.rabbitvcs.org/

TortiseHG

Posted Jun 2, 2010 22:49 UTC (Wed) by jonabbey (guest, #2736) [Link]

It doesn't look like the TortoiseGit project includes a Gnome extension or CLI toolset, though.

Giggle: A Git GUI

Posted Jun 2, 2010 20:02 UTC (Wed) by fb (guest, #53265) [Link]

I disagree with your comment about git on Eclipse. IMO eclipse lacks a decent git plugin. Egit, currently in incubation phase at the Eclipse foundation, is very limited. It can't do one fourth of what the subversion plugin can (WRT being a eclipse plugin).

It can't for instance offer a proper GUI front end to "git blame".

FWIW I've been using gitg as my commit frontend for a couple of months. While I wish for improvements (it reports an error on revert, and it needs a patch to avoid resizing on extremely long commit comments), I find it the most useful of all git GUIs.

For fast history browsing I always use TIG.

Giggle: A Git GUI

Posted Jun 2, 2010 23:46 UTC (Wed) by alexmurray (subscriber, #60581) [Link]

Indeed, gitg is much faster than giggle especially when browsing large trees like the linux kernel - start-up is almost instantaneous compared to the 15-20 seconds of giggle. The author should definitely give this a go instead.

Giggle: A Git GUI

Posted Jun 3, 2010 8:48 UTC (Thu) by man_ls (guest, #15091) [Link]

A lot of GUIs have been mentioned, I sense a grumpy editor's article coming up... (It is definitely in order.)

Giggle: A Git GUI

Posted Jun 2, 2010 20:54 UTC (Wed) by ikm (guest, #493) [Link]

> For the Linux kernel repository, it decided that Emacs was a good choice, but for the LWN site code, KWrite was deemed the proper choice.

Proper and sane program associations is something Linux desktop sorely needs to address. At least on my Debian machine most existing associations are just utterly insane. E.g. mp3 is associated with Audacity (yeah, like I want to edit mp3s!), .txt is associated with "less" (without the controlling terminal, of course), and so on. In fact I am having a hard time remembering the last time an association spawned actually made sense.

Giggle: A Git GUI

Posted Jun 2, 2010 21:07 UTC (Wed) by rsidd (subscriber, #2582) [Link]

Also, if the EDITOR environment variable exists, it should be honoured.

Giggle: A Git GUI

Posted Jun 3, 2010 3:42 UTC (Thu) by Los__D (guest, #15263) [Link]

Err, no. $EDITOR is for command line editing solely.

Popping up a terminal editor while using a GUI app, is almost as annoying as a GUI editor popping up while using the terminal

Debian associations

Posted Jun 2, 2010 21:47 UTC (Wed) by kmself (guest, #11565) [Link]

There are a few general places to look.

Your environment for starters. $EDITOR, $VISUAL, and several BROWSER variables (console, WWW, and unqualified).

The generic commands "sensible-browser", "sensible-editor", and "sensible-pager". These are shell scripts generally invoking what's defined in the environment. Look under /usr/bin.

The /etc/alternatives/ subsystem. man (8) update-alternatives for how to configure. This works by redirecting generic program names (say, 'editor', 'vi', or 'awk') through symlinks in /etc/alternatives/ to the system preferred default.

Depending on the tool, /etc/mailcap may get invoked. There's a user-defineable area at the top of the file.

GNOME, KDE, and XFCE4 each have their standard application associations which are more or (usually) less coordinated. Manage through their respective configuration utilities (gconf-editor, gconftool, gconftool-2 for GNOME, if you want to avoid the GUI configurator, not sure that KDE or XFCE4 have similar tools).

Some apps (OpenOffice.org and Iceweasel come to mind) have their own associations particularly for mail clients.

Yeah, it's a bit of a mess. There were good (or at least middlin') reasons for most of this at the time.

Debian associations

Posted Jun 2, 2010 23:47 UTC (Wed) by drag (guest, #31333) [Link]

GNOME, KDE, and XFCE4 each have their standard application associations which are more or (usually) less coordinated. Manage through their respective configuration utilities (gconf-editor, gconftool, gconftool-2 for GNOME, if you want to avoid the GUI configurator, not sure that KDE or XFCE4 have similar tools).

No... Not really. Not at least for well-written applications. There are tons of applications that do not follow the standards setup for handling file associations, but there are standards and they do not involve anything to do with gconf or anything like that.

In Gnome and KDE the file type association should be handled the same. I don't know about KDE 3.x stuff, but KDE 4.x should work sanely.

They all use the .desktop FreeDesktop.org standard.

The idea is that every typical desktop-oriented application should have a *.desktop file associated with it that gets installed to your system. This file describe what icon to use for it, internationalization names, short names, comments, how to launch he application, and that sort of thing.

example:
$ locate gedit.desktop
/usr/share/app-install/desktop/gedit.desktop
/usr/share/applications/gedit.desktop
/var/lib/menu-xdg/applications/menu-xdg/X-Debian-Applications-Editors-gedit.desktop


That way your desktop environment can educate itself and use automatically generated menus so that you don't have to hard code menus and file associations like you did in the bad old days.

------------------

Some examples on how to use it.

FOR LAUNCHING APPLICATIONS AT LOGIN:

To launch a application at start up make a symbolic link, copy the *.desktop file, or create your own *.desktop file and stick it into "$HOME/.config/autostart"

You can specify in there if you only want it to be launched from a particular desktop environment, or you can eliminate that and then all compliant desktop session managers should launch it at log in.

You can easily create your own .desktop file and store it at "$HOME/.local/share/applications"

MANAGING FILE TYPE ASSOCIATIONS:

File associations are managed by 'defaults.list' file. This file lists the mime type and then the corresponding *.desktop file for the application you want to be used by default.

This file is can be manually created and managed, or it will be created by your desktop environment (usually your file manager) when you change the defaults. You can edit it directly and will be honored right away.

Gnome and KDE (and probably other desktop environments) will have their own set of default lists. On my system (Debian) the Gnome list is located at "/usr/share/gnome/applications/defaults.list"

Your own settings will override the generic defaults and that file can be found at: "$HOME/.local/share/applications/defaults.list"

HOW TO DEAL WITH STUPID APPLICATIONS/APP AUTHORS:

These are applications that launch other applications to handle media whose authors don't have a clue about the freedesktop.org stuff, or are legacy applications.

Most of these applications you have to manually set their own application-specific configuration for launching external apps. (like you really want to spend your time configuring each and every application you use to use every other application you want to use)

To easily deal with them you just tell them to use the '/usr/bin/xdg-open' (or gnome-open) application. These are standardized tools designed to be used by scripts and application authors to make it possible to conform to the standards with minimal effort.

One example application I use that I need to do this with is Liferea. I use it for a variety of feeds, some of which are podcasts and some are video feeds. I just go through and use 'xdg-open' for every thing.

Similar problems exist for the users of Firefox and other non-Gnome/non-KDE applications. Also this is very common problem for GTK-using, but otherwise non-Gnome applications.

For applications like 'mutt' that want the spawned process to block until your finished with it then you'll have to go to greater lengths.

This python script will launch applications similar to xdg-open or gnome-open, but will block until you close out the child app.
#! /usr/bin/env python

import gnomevfs
import os
import sys

# taken from http://therning.org/magnus/archives/251

mime_type = gnomevfs.get_mime_type(sys.argv[1])
mime_app = gnomevfs.mime_get_default_application(mime_type)
application = os.popen('whereis %s' % mime_app[2]).readline().split(' ')[1]

os.execl(application, application, sys.argv[1])
I call it 'mutt-helper.py' and my $HOME/.mailcap file looks like this:
application/*; $HOME/bin/mutt-helper.py '%s'; test=test -n '$DISPLAY'
image/*; $HOME/bin/mutt-helper.py '%s'; test=test -n '$DISPLAY'
audio/*; $HOME/bin/mutt-helper.py '%s'; test=test -n '$DISPLAY'
multipart/*; $HOME/bin/mutt-helper.py '%s'; test=test -n '$DISPLAY'
video/*; $HOME/bin/mutt-helper.py '%s'; test=test -n '$DISPLAY'
text/*; $HOME/bin/mutt-helper.py '%s'; test=test -n '$DISPLAY'

Debian associations

Posted Jun 3, 2010 7:12 UTC (Thu) by rvfh (guest, #31018) [Link]

You could have contributed this as an article to LWN! Very informative, thank you.

Debian associations

Posted Jun 8, 2010 20:31 UTC (Tue) by nix (subscriber, #2304) [Link]

It is frankly insane that this is even necessary. It seems like 'block until complete' should be built into xdg-open.

Debian associations

Posted Jun 6, 2010 23:02 UTC (Sun) by mikov (guest, #33179) [Link]

I think you are forgetting additional settings like x-www-browser, 'gconftool-2 /desktop/gnome/url-handlers/http/command', and who knows what else...

Plus, on my system there are four separate defaults.list with conflicting settings:

/etc/gnome-vfs-2.0/defaults.list
/home/$HOME/.local/share/applications/defaults.list
/usr/local/share/applications/defaults.list
/usr/share/gnome/applications/defaults.list

I use KDE 3.5. Do they all apply? Which one takes precedence? I am sure I could find out, but who has time for such nonsense...

Seriously, this is a sad state of affairs.

Debian associations

Posted Jun 7, 2010 8:32 UTC (Mon) by ikm (guest, #493) [Link]

> I am sure I could find out, but who has time for such nonsense...

Yep, that's exactly why I just try not to use associations at all. It's not really handy, but it seems simpler than trying to figure out how to fix them.

Re: Debian associations

Posted Jun 10, 2010 4:30 UTC (Thu) by ldo (guest, #40946) [Link]

Ummm .. I notice you have single quotes instead of double ones in '$DISPLAY'. Does that do what you intend?

Giggle: A Git GUI

Posted Jun 2, 2010 22:30 UTC (Wed) by AndreE (guest, #60148) [Link]

Your Linux desktop != THE Linux Desktop.

On Fedora 13 all my app settings are sane by default.

Giggle: A Git GUI

Posted Jun 3, 2010 15:46 UTC (Thu) by ikm (guest, #493) [Link]

> Your Linux desktop != THE Linux Desktop.

Applies to you as well, don't you think? :)

Giggle: A Git GUI

Posted Jun 7, 2010 10:02 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

He doesn't make that claim however. You just need to file bug reports for distro specific issues and stop equating them as Linux desktop issues in general.

Giggle: A Git GUI

Posted Jun 7, 2010 11:37 UTC (Mon) by ikm (guest, #493) [Link]

The lack of a single standard isn't distro-specific.

Giggle: A Git GUI

Posted Jun 7, 2010 11:47 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Whatever lack of standard doesn't prevent distro package maintainers from fixing obvious bugs and making the file associations work.

Giggle: A Git GUI

Posted Jun 7, 2010 11:58 UTC (Mon) by ikm (guest, #493) [Link]

You suggest I file bugs against *all* the programs I use. No thanks. I still believe this is a general Linux desktop problem, even if some distros do put work to make the default associations sane. File associations is something an end-user should be able to manage in a clean, easy and universal way.

git frontends

Posted Jun 2, 2010 21:47 UTC (Wed) by dh (subscriber, #153) [Link]

I really like having graphical frontends for systems like git as they much better represent the inherent complexity than a command-line interface can do.

I almost daily access the git repositories in our company and most of the time, I use gitk and git-gui for browsing and checkin. Branch switching, branch creation and merging or rebasing I normally do on the command line and for the rather seldom deeper investigations into a file's history, I take qgit. The Eclipse egit integration I only use for its branch report in the projects window. And don't forget the ncurses-based "tig" client for remote access which I need sometimes - actually so seldom that I never remember the keys for the commands to use tig with...

Ciao, Dirk

git frontends

Posted Jun 2, 2010 22:46 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

Do you have programmable bash completion enabled (assuming you use bash)?

If not, try:

. /etc/bash_completion

or whatever it takes. Git's completion function is a great help in exploring the repository.

Giggle: A Git GUI

Posted Jun 2, 2010 22:52 UTC (Wed) by jonabbey (guest, #2736) [Link]

I use gitk and git gui ubiquitously, both on Linux and on Mac OS X.

Aren't there Tk themeing options which could be used to improve the Gnomishness of the gitk and git gui tools?

Giggle: A Git GUI

Posted Jun 3, 2010 10:31 UTC (Thu) by dgm (subscriber, #49227) [Link]

There are, from TK 8.5 onwards.
For some weird reason, Ubuntu 10.04 insists on using Tcl/Tk 8.4, even if 8.5 is installed from the repositories (and insists on removing gitk and git-gui if Tk 8.4 is removed!).

Default tk version on Debian-based systems

Posted Jun 11, 2010 8:04 UTC (Fri) by jrn (subscriber, #64214) [Link]

Try "update-alternatives --config wish" (or writing a symlink /usr/bin/wish8.5 -> wish on your $PATH if you lack privileges).

Default tk version on Debian-based systems

Posted Jun 20, 2010 19:28 UTC (Sun) by xolox (guest, #67839) [Link]

dgm & jrn: I just created an LWN.net account so I could thank you both! git-gui looks a lot better using my favorite anti-aliased TTF fonts :-)

For anyone else who's interested, executing "sudo apt-get install tk8.5 && sudo update-alternatives --config wish" does the trick on Ubuntu 9.10.

Giggle: A Git GUI

Posted Jun 2, 2010 23:21 UTC (Wed) by bfeeney (guest, #6855) [Link]

I'd recommend SmartGit myself. The basic version is free, but you pay for more advanced functionality. It has a very good diff/merge tool, and is dead easy to use.

Giggle: A Git GUI

Posted Jun 3, 2010 0:07 UTC (Thu) by mhelsley (guest, #11324) [Link]

"The performance of Giggle is rather poor, especially considering that the underlying tool has a definite focus on speed.
...
[giggle] can sometimes take up to ten seconds.
...
When scrolling through history, Giggle will just pause and eat CPU for a while."

I've had the same experiences with the commandline interface alone. Sometimes without consuming much in the way of cpu, disk, or network resources it will still pause for 5-10 seconds.

Giggle: A Git GUI

Posted Jun 3, 2010 15:17 UTC (Thu) by iabervon (subscriber, #722) [Link]

You might try strace on that; at one point someone reported a similar issue, which turned out to be some configuration problem with name resolution. From their reported strace, their system seemed to be trying to get responses from a time server that wasn't responding (fittingly named "timesink.svana.net"); it would wait 5 seconds twice before carrying on with a local timestamp or something like that.

git lola

Posted Jun 3, 2010 3:19 UTC (Thu) by conrad (guest, #3849) [Link]

I used to use giggle, but mainly just to see the branch history. Now I just use git lola, an alias for a pretty history graph in your terminal:

http://blog.kfish.org/2010/04/git-lola.html

It seems to fit more smoothly into the commandline workflow than launching a separate gui tool, is faster and works well over ssh.

git in color

Posted Jun 3, 2010 9:20 UTC (Thu) by man_ls (guest, #15091) [Link]

Thanks for the tip! I especially liked the bit about color though.

Giggle: A Git GUI

Posted Jun 3, 2010 13:09 UTC (Thu) by jdd (guest, #67071) [Link]

I'm really glad that tools like this are being written, as they'll probably do a lot to foster adoption of technologies like DVCSes, but I'm afraid I probably won't ever feel like using a GUI to my VC system.

Giggle: A Git GUI

Posted Jun 3, 2010 20:32 UTC (Thu) by magnus (subscriber, #34778) [Link]

In all Git GUI:s I've seen so far, the graph is more or less just a view. I would love to instead have a GUI with a fully graphical commit history editor. I imagine the history visualised as a tree graph, each commit being a container with patches in it, and one could move patches between commits by dragging, or perform cherry-picking/rebasing by moving boxes around.

Giggle: A Git GUI

Posted Jun 3, 2010 21:42 UTC (Thu) by sandmann (subscriber, #473) [Link]

You can't fix a broken user interface by writing a graphical tool on top of it.

Giggle: A Git GUI

Posted Jun 3, 2010 21:55 UTC (Thu) by jonabbey (guest, #2736) [Link]

Very true. Fortunately, we're talking about Git, not CVS.

Giggle: A Git GUI

Posted Jun 10, 2010 17:05 UTC (Thu) by jjardon (guest, #67079) [Link]

Hello,

We already have [1] some documentation in the new mallard [1] format. Will be available in the nex t release.
And yes, we have some performance problems I tried to minimize before the 0.5 release [2]. But more work is needed.

As always, patches welcomed ;)

[1] http://git.gnome.org/browse/giggle/commit/?id=225ad793ee5...
[2] http://projectmallard.org/
[2] http://blogs.gnome.org/jjardon/2010/03/30/improve-perform...


Copyright © 2010, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds