On Ubuntu and g-s-t

After reading several comments on the Umbrella project, and talking with Michael Vogt and Daniel Holbach I had to drop my feelings about the whole thing:

As a developer

Pros: Perl “sucks”, it doesn’t suck per se, but not getting contributions *sucks* [1]. Python on the other hand is hype, currently there’s much more people willing to contribute coding in Python than coding in Perl, but that’s not news.

If there’s a Python replacement for the backends, I bet that there will be much more people willing to look at that code, and that can easily translate to more contributions, so if a framework to add support for other distributions is done too, that will make many people happy [2].

I strongly believe that s-t-b concept and structure is the right way, but experience forced me to think that it was in the wrong language.

Cons: Maybe most of the concepts would be reused, but there would be heaps of code that wouldn’t, the project status would be almost resetted to 0, it would go from supporting tenths of distros to supporting 1.

The big plan behind s-t-b, dbus, liboobs and g-s-t wasn’t just ditching the XML interface, it was to split things down to make contributions as painless as possible at any level (DBus also allows to do things that were nearly impossible with the XML interface, but that’s a different issue), For example the codebase in the backends has been shaved to 11KLOC (according to sloccount, much of it is common boilerplate, specific code for one distro must not reach more than 300-500 LOC). I’d like people to have a look at the code modifications before willing to replace parts of it (the new g-s-t structure also allows that quite more easily)

Replacing the frontends with python scripts is a different horse, reusing just the g-s-t glade interfaces reminds me what my beloved mentor Chema (RIP) told me once about RedHat doing the same a long time ago


I’ve failed, I once thought that s-t-b would be an excellent collaboration framework for distributions, the reality is that the only big distro using it now plans to switch, some other distros ship g-s-t as a curiosity and others don’t do that at all. The patches from distros, although very appreciated, have been very few, so s-t-b is miles away from where it could be (Maybe it’s just my lack of leadership, or that I’m a poor unemployed guy and don’t represent any big FS company, who knows)

In the case that Umbrella tries to do a multidistro framework (I bet it will success over s-t-b with time, people love Python after all), I don’t think I will collaborate regularly with code, I’ve been struggling with g-s-t for more than 4 years, and I’m not willing to start the very same thing from scratch. However, I’m fully available to give advice, after all I think I earned enough know-how on the subject.

I really hope that people won’t think I’m pissed off, Michael and Daniel are quite happy with their decision, if they are happy and take this to the end, I’m happy too. It’s just that I’m a practical guy, and I should focus on other parts of the desktop where my code would be more appreciated.

And now, off to my guitar lesson…

[1] Really, I think I could count contributors to s-t-b in the last year with the fingers of one hand. even my last post got no response at all
[2] You wouldn’t believe the ammount of people that tried to convince me to rewrite s-t-b in Python

4 thoughts on “On Ubuntu and g-s-t”

  1. I completely understand the frustration.

    Python *is* hyped, and many novice (and less novice) programmers will try and contribute stuff – I’m sure – if the system tools backends were written into Python.

    but let’s try to imagine the same situation in the late nineties (pre- and nearly-dot-bomb era): instead of Perl you would have had sh scripting; instead of Python you would have had Perl.

    what I’m saying – and what I tried to say in my blog – is that following the hype-du-jour is not an answer. if python gains us something *in the long run* I’ll be the first in line to say to ditch perl as the language of choice.

    by the way: never though about replacing part of the perl machinery with gobjects implemented using the Glib bindings? that would make the s-t-b “scale” better, and would allow changing backends more easily. just a thought. :-)

  2. I remember reading yesterday’s post, “A plea for help”, but it did not register with me that the gnome-system-tools had a perl backend nor have I previously been aware of it. It could be that the project has not received the needed recognition/advertising to attract a group of dedicated developers.

    I also believe that is impractical to re-write g-s-t in python and throwing away the perl code just for the sake of having everything written in python.

  3. well, just to say, i understand you get little contributions, however your work is very appreciated. even though perl is not a language i know, i don’t see the language as such a big issue. if someone wants to contribute, and is a programer (s)he’ll make in perl or any language.

    i’m not so crazy about this mono-language motto we’re getting into nowadays. maybe it’s because my language of choice is the ruby underdog. anyway i hope g-s-t flourishes forward… it’s very useful as it is and rewriting seems a useless waste of energy…

  4. Hi. I’m Thomas, I’m a GNOME developer. I write in C for my GNOME work, but in my day job I use Perl, so I know it pretty well. Can I help at all? I’m a bit busy with metacity at the moment, but I’d like to know how I can be of use.

Comments are closed.