Long Overdue Update

• September 7, 2009
• Jannis Pohlmann

I haven't posted anything in a while, but I'm not complaining. The last month I've been mostly busy pretending to be busy. Ok, to be honest, that's not entirely true. Over at Xfce, we have achieved a lot in August:

• We've moved all Xfce repositories (including the goodies) over to Git. Kudos to Brian for doing most of the work.
• All Xfce translation updates are now submitted via Transifex. Thanks to the Transifex developers for all the support and for being such a friendly bunch. It amazes me that Dimitris, the founder of Indifex, is also active on our translations mailing list to support people!
• The migration of the Thunar core to GIO is complete and has been merged into the main development branch. The overall delta was 2.9MB, although admittedly, a big part of that is due to the removal of ThunarVFS, so I can only take credit for about 16,000 of the 24,335 insertions and 6,000 of the 41,356 deletions.
• We've kicked off the Xfce 4.8 development cycle on August 16th. The schedule and all other details are available on the wiki. Xfce 4.8 is scheduled for April 12th, 2010. Expect development releases of the various core components soon!

Other things I've been planning to blog about but didn't have the time to:

• Samuel is still busy setting up Buildbot. With less time than he had hoped for at hands this might still take a while.
• I was provided with a free Linutop 2 in June. I'd like to thank the Linutop company again for this gift! So far, I've only found the time to give it a few test boots but I'm planning to set it up as a Xfce test machine soon. Its limited hardware makes it much better platform than my rather powerful laptop and/or virtual machines for testing the speed and memory demand of Xfce.
• My thesis is progressing slowly. I think I have at least 3/4 finished now. I'll keep you posted about the result. I'm hoping to kick off the six month learning phase for my final exams before October because a friend of mine is already waiting for me. ;)

Build a project with Vala

• September 2, 2009
• Mike Massonnet

Autoconf script

AM_INIT_AUTOMAKE([1.11 dist-bzip2])
AM_MAINTAINER_MODE()

if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
  AM_PROG_VALAC([0.7.4])
  if test "x$VALAC" = "x" ; then
      AC_MSG_ERROR([Cannot find the "valac" compiler in your PATH])
  fi
fi

echo
echo "Build Configuration:"
echo
echo "* Maintainer Mode:        $USE_MAINTAINER_MODE"
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
echo
echo "    * Vala:               $VALAC"
echo
fi

Automake script

product_VALASOURCES = \
  obj1.vala \
  obj2.vala \
  main.vala

product_VALABUILTSOURCES = $(product_VALASOURCES:.vala=.c) product.h

if MAINTAINER_MODE
PACKAGES = --pkg=gtk+-2.0
BUILT_SOURCES = vala.stamp
vala.stamp: $(product_VALASOURCES)
  $(VALAC) --vapidir=$(srcdir) $(PACKAGES) $^ -C -H product.h
  touch $@
endif

product_SOURCES = \
  random-source.c \
  random-header.h \
  $(product_VALABUILTSOURCES)

EXTRA_DIST = $(product_VALASOURCES)
if MAINTAINER_MODE
CLEANFILES = \
  $(BUILT_SOURCES) \
  $(product_VALABUILTSOURCES)
endif

That's it

Code Comments

• August 18, 2009
• Brian Tarricone

I’m a bit of a minimalist when it comes to commenting my code. This is probably in some ways a bad thing; code that is completely obvious to me in its function may be difficult to understand for others, and I’m often not so great at realizing this on the first pass.

So that leads me to the purpose of code comments:

The purpose of commenting your code is to inform readers of that code what a section of nontrivial or non-obvious code does.

At least, this is my definition. Opinions differ, I’m sure. I might also add to that a clarification: “readers” in this case may include yourself. Code you wrote may even be incomprehensible to you if a decent amount of time has passed.

From this definition you can also infer something else, that I believe it’s unnecessary to comment obvious code. In fact, I’d argue that it’s harmful to comment obvious code, because you’re making it harder to follow, and you’re adding a barrier in front of the reader being easily able to distinguish between trivial and nontrivial code at a glance. You also increase the length of the code fragment, which may make it more difficult to read and understand in its entirety (if you can’t fit the entire fragment on one screen, you’ll have to scroll back and forth to see the entire thing).

However, too often – very often, it turns out – I see things like the following:

/* take a reference */
g_object_ref(object);

/* free string */
g_free(str);

And one of my favorites:

/* set the label text to "Time Left:" */
gtk_label_set_text(GTK_LABEL(label), "Time Left:");

(Yes, I actually have seen something very similar to that, though I don’t remember what the label text was.)

How do these comments actually add anything useful to the file? Every time I see one of these, a little part of me dies inside.

Now, the last one is just silly. Even someone who has never developed using the gtk+ UI toolkit can figure out what that line of code does without the comment. If you can’t, then a code comment there probably isn’t going to be enough to help you overall in any case.

The middle one is equally silly, though it’s understandable that someone might not know that g_free() is the glib equivalent of free(). However, consider your audience: is an extra line of code for a comment really useful here?

The first one is not quite so easy for me to dismiss. It presupposes a few bits of knowledge:

1. Understanding of what reference-counted memory management is.
2. Familiarity with the “ref/unref” pair, as opposed to only being exposed to something like the OpenStep “retain/release” (or even the COM/XPCOM “AddRef/Release”) terminology.
3. At least passing knowledge of what a GObject is.

Now, for code that makes heavy use of reference counting, I think presupposing #1 is not unreasonable. In this case, it doesn’t matter: the comment as presented will not help you if you don’t know what reference counting is.

Points #2 and #3 depend on your goals and potential audience. If you think that a decent number of readers may not be familiar with the “ref/unref” terminology, “take a reference” is probably enough to generate an “oh, duh!” moment in the reader’s head. As for #3, unless you intend your code to be able to act as a sort of GObject tutorial, that is, something that people aspiring to learn GObject programming might want to read, I think the comment there does not serve people unfamiliar with GObject. Regardless, most GObject-using code will probably be pretty confusing to someone who doesn’t know GObject, so whether or not you should comment g_object_ref() is going to be the least of your worries.

Now, I’m not going to claim that my code commenting is perfect… far from it. I could certainly stand to sprinkle comments a bit more liberally throughout my code. I tend to only comment public API (and then just a description of what the function does, not how it does it), and code fragments that are really nontrivial¹ and potentially hard to understand.

But there has to be a happy medium somewhere. While too-infrequent commenting can certainly make code harder to understand, I’d argue that too-frequent commenting is worse. It’s sorta like “the boy who cried wolf” in the sense that comments draw my eyes to them as a way of saying, “pay attention! This bit here is important!” (or tricky, or whatever). Overuse of comments just makes me start skipping over all of them, useful or otherwise.

of comments. I generally prefer clear code over neat hacks, even if the neat hack represents a reduction in lines of code or a moderate increase in performance. If I write a section of code and then look at it again and see that it looks too complex, I’ll usually try to immediately rewrite it to be simpler.

Code Comments

• August 18, 2009
• Brian Tarricone

I'm a bit of a minimalist when it comes to commenting my code. This is probably in some ways a bad thing; code that is completely obvious to me in its function may be difficult to understand for others, and I'm often not so great at realizing this on the first pass.

So that leads me to the purpose of code comments:

The purpose of commenting your code is to inform readers of that code what a section of nontrivial or non-obvious code does.

At least, this is my definition. Opinions differ, I'm sure. I might also add to that a clarification: "readers" in this case may include yourself. Code you wrote may even be incomprehensible to you if a decent amount of time has passed.

From this definition you can also infer something else, that I believe it's unnecessary to comment obvious code. In fact, I'd argue that it's harmful to comment obvious code, because you're making it harder to follow, and you're adding a barrier in front of the reader being easily able to distinguish between trivial and nontrivial code at a glance. You also increase the length of the code fragment, which may make it more difficult to read and understand in its entirety (if you can't fit the entire fragment on one screen, you'll have to scroll back and forth to see the entire thing).

However, too often -- very often, it turns out -- I see things like the following:

``/* take a reference */
g_object_ref(object);``

``/* free string */
g_free(str);``

And one of my favorites:

``/* set the label text to "Time Left:" */
gtk_label_set_text(GTK_LABEL(label), "Time Left:");``

(Yes, I actually have seen something very similar to that, though I don't remember what the label text was.)

How do these comments actually add anything useful to the file? Every time I see one of these, a little part of me dies inside.

Now, the last one is just silly. Even someone who has never developed using the gtk+ UI toolkit can figure out what that line of code does without the comment. If you can't, then a code comment there probably isn't going to be enough to help you overall in any case.

The middle one is equally silly, though it's understandable that someone might not know that g_free() is the glib equivalent of free(). However, consider your audience: is an extra line of code for a comment really useful here?

The first one is not quite so easy for me to dismiss. It presupposes a few bits of knowledge:

1. Understanding of what reference-counted memory management is.

2. Familiarity with the "ref/unref" pair, as opposed to only being exposed to something like the OpenStep "retain/release" (or even the COM/XPCOM "AddRef/Release") terminology

3. At least passing knowledge of what a GObject is

Now, for code that makes heavy use of reference counting, I think presupposing #1 is not unreasonable. In this case, it doesn't matter: the comment as presented will not help you if you don't know what reference counting is.

Points #2 and #3 depend on your goals and potential audience. If you think that a decent number of readers may not be familiar with the "ref/unref" terminology, "take a reference" is probably enough to generate an "oh, duh!" moment in the reader's head. As for #3, unless you intend your code to be able to act as a sort of GObject tutorial, that is, something that people aspiring to learn GObject programming might want to read, I think the comment there does not serve people unfamiliar with GObject. Regardless, most GObject-using code will probably be pretty confusing to someone who doesn't know GObject, so whether or not you should comment g_object_ref() is going to be the least of your worries.

Now, I'm not going to claim that my code commenting is perfect... far from it. I could certainly stand to sprinkle comments a bit more liberally throughout my code. I tend to only comment public API (and then just a description of what the function does, not how it does it), and code fragments that are really nontrivial[1] and potentially hard to understand.

But there has to be a happy medium somewhere. While too-infrequent commenting can certainly make code harder to understand, I'd argue that too-frequent commenting is worse. It's sorta like "the boy who cried wolf" in the sense that comments draw my eyes to them as a way of saying, "pay attention! This bit here is important!" (or tricky, or whatever). Overuse of comments just makes me start skipping over all of them, useful or otherwise.

<>[1] It's worth noting here that this point further reduces my volume of comments. I generally prefer clear code over neat hacks, even if the neat hack represents a reduction in lines of code or a moderate increase in performance. If I write a section of code and then look at it again and see that it looks too complex, I'll usually try to immediately rewrite it to be simpler.

Code Comments

• August 18, 2009
• Brian Tarricone

I’m a bit of a minimalist when it comes to commenting my code. This is probably in some ways a bad thing; code that is completely obvious to me in its function may be difficult to understand for others, and I’m often not so great at realizing this on the first pass.

So that leads me to the purpose of code comments:

The purpose of commenting your code is to inform readers of that code what a section of nontrivial or non-obvious code does.

At least, this is my definition. Opinions differ, I’m sure. I might also add to that a clarification: “readers” in this case may include yourself. Code you wrote may even be incomprehensible to you if a decent amount of time has passed.

From this definition you can also infer something else, that I believe it’s unnecessary to comment obvious code. In fact, I’d argue that it’s harmful to comment obvious code, because you’re making it harder to follow, and you’re adding a barrier in front of the reader being easily able to distinguish between trivial and nontrivial code at a glance. You also increase the length of the code fragment, which may make it more difficult to read and understand in its entirety (if you can’t fit the entire fragment on one screen, you’ll have to scroll back and forth to see the entire thing).

However, too often — very often, it turns out — I see things like the following:

/* take a reference */
g_object_ref(object);

/* free string */
g_free(str);

And one of my favorites:

/* set the label text to "Time Left:" */
gtk_label_set_text(GTK_LABEL(label), "Time Left:");

(Yes, I actually have seen something very similar to that, though I don’t remember what the label text was.)

How do these comments actually add anything useful to the file? Every time I see one of these, a little part of me dies inside.

Now, the last one is just silly. Even someone who has never developed using the gtk+ UI toolkit can figure out what that line of code does without the comment. If you can’t, then a code comment there probably isn’t going to be enough to help you overall in any case.

The middle one is equally silly, though it’s understandable that someone might not know that g_free() is the glib equivalent of free(). However, consider your audience: is an extra line of code for a comment really useful here?

The first one is not quite so easy for me to dismiss. It presupposes a few bits of knowledge:

1. Understanding of what reference-counted memory management is.
2. Familiarity with the “ref/unref” pair, as opposed to only being exposed to something like the OpenStep “retain/release” (or even the COM/XPCOM “AddRef/Release”) terminology
3. At least passing knowledge of what a GObject is

Now, for code that makes heavy use of reference counting, I think presupposing #1 is not unreasonable. In this case, it doesn’t matter: the comment as presented will not help you if you don’t know what reference counting is.

Points #2 and #3 depend on your goals and potential audience. If you think that a decent number of readers may not be familiar with the “ref/unref” terminology, “take a reference” is probably enough to generate an “oh, duh!” moment in the reader’s head. As for #3, unless you intend your code to be able to act as a sort of GObject tutorial, that is, something that people aspiring to learn GObject programming might want to read, I think the comment there does not serve people unfamiliar with GObject. Regardless, most GObject-using code will probably be pretty confusing to someone who doesn’t know GObject, so whether or not you should comment g_object_ref() is going to be the least of your worries.

Now, I’m not going to claim that my code commenting is perfect… far from it. I could certainly stand to sprinkle comments a bit more liberally throughout my code. I tend to only comment public API (and then just a description of what the function does, not how it does it), and code fragments that are really nontrivial[1] and potentially hard to understand.

But there has to be a happy medium somewhere. While too-infrequent commenting can certainly make code harder to understand, I’d argue that too-frequent commenting is worse. It’s sorta like “the boy who cried wolf” in the sense that comments draw my eyes to them as a way of saying, “pay attention! This bit here is important!” (or tricky, or whatever). Overuse of comments just makes me start skipping over all of them, useful or otherwise.

[1] It’s worth noting here that this point further reduces my volume of comments. I generally prefer clear code over neat hacks, even if the neat hack represents a reduction in lines of code or a moderate increase in performance. If I write a section of code and then look at it again and see that it looks too complex, I’ll usually try to immediately rewrite it to be simpler.

Xfce Stopwatch Plugin

• August 17, 2009
• ongardie.net: xfce

I needed an excuse to try Mike's Vala bindings for Xfce, so I created a new little plugin for the panel, the xfce4-stopwatch-plugin.

In the original release announcement on July 28th, I wrote:

This is the first release of the stopwatch panel plugin, which you can use to time yourself on different tasks. It's stable and usable, but quite minimal still.

The functionality is best summarized with this image from the web site:

Vala

From their web site,

Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C.

Instead of having to write tons of boilerplate code to create new GObjects in C and for other common tasks in developing GTK-based applications, Vala builds these features into the language. The Vala code you write passes through the Vala compiler, which produces GObject-based C code. From there, GCC compiles that to a binary as usual. There is no runtime, so Vala-produced code can run as fast as hand-coded C.

Vala makes it easy to write fast, object-oriented code for GTK-based projects. With Mike's Xfce bindings for Vala, you gain access to Xfce's libraries from Vala, letting you write panel plugins or other Xfce projects in Vala. It's a cool idea and something I definitely wanted to try.

Developing the Stopwatch Plugin

In general, Vala is pretty easy to write if you've worked with GObject before. I did hit a few bugs while developing even this simple plugin, so it's evident that Vala and the Xfce bindings aren't mature yet:

• I filed GNOME Bug 587150, a bug in Vala's POSIX bindings for the time_t type. Vala treats it as a GObject instead of an integer, making it unusable to pass around your program in many ways. This bug hasn't seen any attention yet, but I've worked around it for Stopwatch by not using time_t.

  Update: Evan Nemerson fixed this one.

• I patched a small bug in Xfce's Vala bindings for the XfceHVBox widget. The Vala compiler was producing calls to xfce_hv_box_new() instead of xfce_hvbox_new(), which of course caused a problem when GCC tried to resolve the symbol.
• I also filed GNOME Bug 589930, a bug in Vala's generated code for sscanf. It always added an extra NULL argument at the end of the arguments list. Jürg Billeter fixed this one quickly with this commit, which made it into Vala 0.7.5.

Despite these hurdles, writing the Stopwatch plugin in Vala has been a pleasure. Admittedly the plugin doesn't do much, but the code is very short and straight-forward.

Stopwatch will probably see just one or two more releases before it's feature-complete. I'd also like to port the Places plugin to Vala at some point, but I'm waiting to see how volume management plays out once ThunarVFS is gone.

Xfce Stopwatch Plugin

• August 17, 2009
• ongardie.net: xfce

I needed an excuse to try Mike's Vala bindings for Xfce, so I created a new little plugin for the panel, the xfce4-stopwatch-plugin.

In the original release announcement on July 28th, I wrote:

This is the first release of the stopwatch panel plugin, which you can use to time yourself on different tasks. It's stable and usable, but quite minimal still.

The functionality is best summarized with this image from the web site:

Vala

From their web site,

Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C.

Instead of having to write tons of boilerplate code to create new GObjects in C and for other common tasks in developing GTK-based applications, Vala builds these features into the language. The Vala code you write passes through the Vala compiler, which produces GObject-based C code. From there, GCC compiles that to a binary as usual. There is no runtime, so Vala-produced code can run as fast as hand-coded C.

Vala makes it easy to write fast, object-oriented code for GTK-based projects. With Mike's Xfce bindings for Vala, you gain access to Xfce's libraries from Vala, letting you write panel plugins or other Xfce projects in Vala. It's a cool idea and something I definitely wanted to try.

Developing the Stopwatch Plugin

In general, Vala is pretty easy to write if you've worked with GObject before. I did hit a few bugs while developing even this simple plugin, so it's evident that Vala and the Xfce bindings aren't mature yet:

• I filed GNOME Bug 587150, a bug in Vala's POSIX bindings for the time_t type. Vala treats it as a GObject instead of an integer, making it unusable to pass around your program in many ways. This bug hasn't seen any attention yet, but I've worked around it for Stopwatch by not using time_t.

  Update: Evan Nemerson fixed this one.

• I patched a small bug in Xfce's Vala bindings for the XfceHVBox widget. The Vala compiler was producing calls to xfce_hv_box_new() instead of xfce_hvbox_new(), which of course caused a problem when GCC tried to resolve the symbol.
• I also filed GNOME Bug 589930, a bug in Vala's generated code for sscanf. It always added an extra NULL argument at the end of the arguments list. Jürg Billeter fixed this one quickly with this commit, which made it into Vala 0.7.5.

Despite these hurdles, writing the Stopwatch plugin in Vala has been a pleasure. Admittedly the plugin doesn't do much, but the code is very short and straight-forward.

Stopwatch will probably see just one or two more releases before it's feature-complete. I'd also like to port the Places plugin to Vala at some point, but I'm waiting to see how volume management plays out once ThunarVFS is gone.

Code Comments

• August 15, 2009
• Brian Tarricone

The new Xfce release manager for users and packagers

• August 3, 2009
• Jannis Pohlmann

I deleted the last post about the release manager because due to the high number of changes I made it was soon out of date. So let's get back to the topic again. I'll split it up into two posts: this one which is for users and packagers mostly, and another one directed to developers or, more precisely, maintainers.

Let's start with a simple question (with a long answer): what am I talking about and what is this release manager anyway?

First, a bit of background. At Xfce, we are currently working on improving our infrastructure. We are about to switch to git and along with that, our repository layout will change. Xfce and goodie repositories will no longer be found in separate locations. We thought it would be nice to implement the same layout in other places as well, like Bugzilla and our download archive.

Nick went ahead and enabled so-called bugzilla classifications and used those to resemble the repository layout on bugzilla.xfce.org.

That still left us with separate download archives for core Xfce, goodies and other stuff. For goodies, we had a very simple release manager web application written in PHP that uploaded tarballs to http://goodies.xfce.org/releases/ and was able to send release announcements to mailing lists. The design however was very limited. For Xfce releases we had nothing like that. Uploading and copying tarballs around manually for each release was what we had to do.

And this is where the new all-in-one release manager comes into play. It's called Moka, it is written in Ruby using Sinatra, ERB and JSON and the source code can be found here.

For you as a user or packager, it does two things:

1. it uploads all (core and goodies) tarballs to http://archive.xfce.org which uses the same layout as our future git repositories and bugzilla
2. it pushes release announcements out to mailinglists, Atom feeds, identi.ca and Twitter.

Download archive

The layout is described in the archive reorganization section of this mail. It contains releases of all projects, be they goodies, core components or something else. Again, we use classifications like apps, libs, bindings or core to add semantics the archive layout.

All tarballs are accompanied by an MD5 and SHA1 checksum file. In the future, we're hoping to also support PGP signing of tarballs. So, for the 0.4.0 release of terminal, you'll get these three files:

• Terminal-0.4.0.tar.bz2
• Terminal-0.4.0.tar.bz2.md5
• Terminal-0.4.0.tar.bz2.sha1

If you download one of the checksum files along with the tarball you can verify the download went fine with md5sum -c Terminal-0.4.0.tar.bz2.md5 or sha1sum -c Terminal-0.4.0.tar.bz2.sha1.

Announcements

Release announcements are sent to different mailinglists (almost always to xfce@xfce.org, so you're on the safe side subscribing to that one), identi.ca/xfce and twitter.com/xfceofficial.

The status updates on identi.ca/xfce and twitter.com/xfceofficial use the following format:

terminal 0.4.0 released! http://releases.xfce.org/feeds/project/terminal !Xfce

Atom feeds for all projects are available on http://releases.xfce.org/feeds/project/. There also is a dedicated feed for bundle releases of Xfce core components available on http://releases.xfce.org/feeds/collection/xfce. These feeds provide more information about the releases than the posts on identi.ca or Twitter do. There's no central feed for all releases yet, but you can as well subscribe to the feeds offered to you by identi.ca or Twitter.

Mailinglist announcements and feed posts use the same format. Here's a good example for a project release announcement:

xfce4-power-manager 0.8.3 is now available for download from

  http://archive.xfce.org/src/apps/xfce4-power-manager/0.8/xfce4-power-manager-0.8.3.tar.bz2
  http://archive.xfce.org/src/apps/xfce4-power-manager/0.8/xfce4-power-manager-0.8.3.tar.bz2.md5
  http://archive.xfce.org/src/apps/xfce4-power-manager/0.8/xfce4-power-manager-0.8.3.tar.bz2.sha1

  SHA1 checksum: 2d531b9fc2afec3cff034e1acfc331051d8bf47a
   MD5 checksum: 0db6b6f5b13c8b0829c6a07b7dfdc980


What is xfce4-power-manager?
============================

This software is a power manager for the Xfce desktop, Xfce power
manager manages the power sources on the computer and the devices that
can be controlled to reduce their power consumption (such as LCD
brightness level, monitor sleep, CPU frequency scaling). In addition,
xfce4-power-manager provides a set of freedesktop-compliant DBus
interfaces to inform other applications about current power level so
that they can adjust their power consumption, and it provides the
inhibit interface which allows applications to prevent automatic sleep
actions via the power manager; as an example, the operating system’s
package manager should make use of this interface while it is performing
update operations.

Website:
  http://goodies.xfce.org/projects/applications/xfce4-power-manager


Release notes for 0.8.3
=======================

- Provides more standard org.fd.PowerManagement DBus methods and signal
(bug #5569).
- Make it possible to compile without network manager support.
- Add never show icon to the system tray configuration (bug #5613).
- Fix a typo that prevents from getting the correct critical
configuration (bug #5619).
- Use Gtk as a popup indicator to show the brightness level as the cairo
seems to be 
  problematic on some hardware. (bug #5544 #5632).
- Better alignement in the interface file, worked by Josef Havran.

This is what the new release manager does for you. I think or rather hope that it provides an efficient way to to keep you posted about what's going on. And hopefully, all of you enjoy our efforts to unify our infrastructure and by that make things more transparent. As always, if you have any ideas for improvements, let us know!

Finally: free Xubuntu CDs!

• July 31, 2009
• vincent

Xubuntu users have long clamoured for their beloved Linux distribution to be available in Ubuntu’s ShipIt service, but to no avail: Xubuntu’s user base was too marginal and, as a community-run project, Canonical could not provide support for it. Thus, they refrained from offering free Xubuntu CDs.

They still do, but there now is an alternative! Xubuntu is from now on available under the Quick Ship service run by On-Disk.com. As listed on the “Get Xubuntu” page, shipping is available for the USA and the rest of the world.

Unfortunately, despite the CDs being free of charge, you still have to pay for shipping them (as opposed to ShipIt). Still, for people suffering from a slow internet connection this is a great alternative, and the Xubuntu developers are very pleased that this service is still being made available to users. I should mention expicitly, though, that this service is not run by the Xubuntu developers, neither is it run by Canonical. This is an independent service provided by a home-based family business with heart for the open source community. Pasi Lallinaho, who is currently “the artwork guy” of Xubuntu, has expressed interest in providing graphics for the CD to make sure they match the Xubuntu style.

Still, I think this is a great development for Xubuntu and its users, and I want to thank On-Disk.com for doing this.