Bobulate


Archive for November, 2009

Who is the FSFE?

Thursday, November 19th, 2009

The FSFE stand at FSCONS was staffed by a mix of full-time employees, interns, volunteers, Fellows, country team leads and (occasionally) anyone who would stand there for a few minutes while the rest took off for a food break. In order to show who the FSFE is, I took to drawing little portraits on the whiteboard. Now, my artistic skills are well known — I believe I’ve written of my sheer awesomeness with Kolourpaint; phrases like “skillz like a road-kill hedgehog” apply. Nonetheless, here is a little flash-card which you can use to identify FSFE people at your next conference.

people of FSFE flashcard

An alternative to KRecipes

Wednesday, November 18th, 2009

Every now and then I post a recipe on this blog, and sometimes I muse about KRecipes, and there have been a few KDE events (the launch event in Mountain View, or CampKDE) where I’ve baked cookies or done other foodie-oriented activities. You can usually count on me to go looking for interesting food (there is no guinea-pig to eat in London, BTW) at events as well. But this winter season, I’m looking at something different. We are looking at something different. The “we” here is the FSFE, and we’ve decided that there’s worse things to do than cook a lovely dinner for some of our friends. So as part of our 2009 Fundraiser the executive team (comprised of at least three affirmed foodies — I’m not sure we have anyone who can function as a sommelier though) will be cooking a lovely dinner for one lucky sponsor of the FSFE.

Perhaps I’ll be able to practice this weekend with Claudia in Berlin — I seem to remember we got along pretty well cooking dinner in Paul’s appartment last year, but it’s a little hazy. Otherwise I’m left to come up with something creative to do with the rutabaga in this week’s vegetable hamper all on my own.

So watch out: Freedom Food might be coming your way.

The Science of Innovation

Wednesday, November 18th, 2009

A somewhat odd article that touches on patents and science crossed my desk last week in the weekend science section of my newspaper, the NRC. It’s about an experiment used to detect dark matter, the DAMA experiment undertaken under the Gran Sasso mountain. Science is largely about reproducibility, at least in the physical sciences: an experiment must be repeatable for it to have any weight as a data point. The reporting might be a little sketchy here, but it claims that the experiment is not repeatable (by researchers elsewhere) because there’s a *patent* on some parts of the original experiment and no-one can deliver the parts to another group of researchers without violating the patent license. The patent holders in this case are the research group who did the experiment in the first place.

Now, this might simply come down to a basic patent licensing dispute (which might be resolved either by granting special permission by the patent holder to another research group, or by re-using some of the original equipment, or by working around the experiment design entirely), but it’s certainly an illustration of how patents can stand in the way of even basic science questions asking “is this true?”

A Day at FSCONS

Saturday, November 14th, 2009

FSCONS day one is nearly done. The FSFE track in the morning was fairly well attended. Both technical topics (like the Fellowship GPG smartcard) and legal. I’ve attended a few other talks, talked to lots of people about licensing issues, eaten scrumptious cookies (the catering is both vegetarian and excellent), and now I’m ready for a nap. After that, I have a few new software licenses to read and think about, because I’ve been asked to comment on several from a Free Software perspective. Not that I’m authoritative on that topic, but I can do the rough work.

Right, Constantly

Saturday, November 14th, 2009

Markey is right. Some of his commenters are not. So I’ll illustrate, because const-correctness and const-consistency is important for cross-platform quality. In other words, getting it right means that other plaforms than Linux-with-GNU-userland-and-gcc will be able to compile KDE apps in one go.

The main thing about const-consistency is that some compilers mangle the constness of parameters into the function name. Consider the following trivial bit of code:

extern void foo(const int i);

void bar(int i) { };

I compiled this bit on FreeBSD with gcc (which is a platform that doesn’t mangle constness into the name) and Solaris with Sun Studio 12 (which does). The output from nm is like this:

In FreeBSD:
0000000000000000 T _Z3bari
U _Z3fooi

In OpenSolaris:
[22] | 0| 5|FUNC |GLOB |0 |2 |void bar(int)
[__1cDbar6Fi_v_]
[24] | 0| 0|FUNC |GLOB |0 |UNDEF |void foo(const int)
[__1cDfoo6Fki_v_]

The name mangling is clearly different — but note that the parameter of foo() and bar() is typed “i” in both cases by g++, and as “i_v_” and “ki_v_” in Studio. I used nm -C under Solaris to show the de-mangled form of the names as well as the actual symbol. If I add -C against the g++-compiled object, then it prints foo(int) and bar(int) — the constness in the function parameter has disappeared.

The effect of this is that constness does matter on some platforms, and if the interface (e.g. .h file) says “const” then the implementation must do so as well; conversely, if there’s no const in the .h, don’t add a const in the .cc as a safeguard, because it breaks on linking.

As for the stylistic issue of const on POD parameters, well, Ilet’s call that a matter of taste (and the application of the relevant coding style guidelines for the code you’re working on).

QtCreator on OpenSolaris

Saturday, November 14th, 2009

At FSCONS I attended a talk by Johan Thelin — good to see someone whose blog I’ve followed for a long time, but whom I’d never met before — about QtCreator. The talk itself was a bit simple, more a “how to get the toolchain going” than a “deep secrets of Qt creator.” But because I was there I decided to update the OpenSolaris specfile for qtcreator to version 1.2.90 (the latest version for which a source download is available), and it took remarkably little effort to get it going.

Several of the patches from previous versions of the spec had been upstreamed — thanks Ossi — and only the bogus cruft patches remain like dragging in extra libraries and dealing with PTRACE.

The resulting qtcreator.bin works reasonably well — there’s an issue in detecting where Qt is installed, so I had to set that manually and the RPATH isn’t set to include lib/qtcreator/ — which means the method-autocompletion works and it does compile and run an application. I haven’t tried debugging or anything complicated, though.

This bit of Qt coding was in between my talk — on license selection and governance models in Free Software projects, where I was glad to have received useful feedback from the GNU hackers meeting yesterday — and a talk by Christina Haralanova. Just enough time to compile once, and it works.

North by North-West

Thursday, November 12th, 2009

Right. Got that heading? Now turn 90 degrees to your right, because Gothenburg is that way. It’s time for FSCONS, the Free Society Conference and Nordic Summit, so off we go. I’ll be talking about licensing, best practices in governance and trying to learn about Swedish copyright law for a few days. Looking forward to it, including taking advantage of Henrik.

KDE 4.3.2 on OpenSolaris

Wednesday, November 11th, 2009

For those tracking KDE4 OpenSolaris, I’ve updated the pkg repository for KDE4 packages. There’s a couple of things to note:

  • This build requires nv126 or later. Build 124 introduced some new incompatibilities in OpenSolaris itself, which trips up kdebase-apps builds — this has been hacked around, but we need to find a good fix that we can upstream.
  • There will be no KDE 4.3.3 from the KDE4-OpenSolaris folks. We’re going to focus on 4.4.0, since there’s plenty to chase after there. Hajma has been doing a great job in tracking trunk these days, and I’ve been tagging along with 4.3.2.
  • Upstreaming patches is tough. We intend to actually set up nightly builds that report to the KDE dashboard, as Alexander Neudorf has once again extended the hand of friendship to us non-Linux folks for the dashboard.
  • As always, the source specfiles can be found on solaris.bionicmutton.org/hg/ and they all point to the original upstream sources.

Bitlbee FTW!

Tuesday, November 10th, 2009

I’m old-school. No, really. Even in this day and age of graphical desktops (and, hey, I could hot-desk X11 sessions at home with my smartcard if I really wanted to) I keep an ssh tunnel open to a friendly server, with GNU screen and irssi in there. And that’s my Instant Messaging setup. Kopete is nice (er .. usually, although I haven’t managed to get it to do anything useful in Solaris yet), but misses the always-on functionality of screen.

But irssi is an IRC client, and the FSFE uses Jabber for much of its communication. There’s #fsfeurope on Freenode, but other than that .. the Fellowship page on communications channels is a good resource. I briefly mucked about with irssi-xmpp plugin on FreeBSD, but couldn’t get any useful functionality out of it. It also seemed quite complicated to set up right.

Enter BitlBee, which bridges some other IM clients to IRC, by acting as an IRC server locally. This is one of the rare times that I’ve rushed up to one of the developers of an application and gushed “I love your app! It improves my life!” Well, I’ve met Jelmer enough times at various conferences, I think I can take liberties like that 🙂 The FreeBSD port installs flawlessly, has a few issues when running in jails and segfaults on OTR requests, but those are technicalities: the functionality and the level of guidance given by BitlBee (the in-channel help is excellent) makes it dead simple to set up and use. And as a consequence, I now have 4 IRC channels (#ebn and #kde4-solaris among them) and 3 Jabber groupchats open (including the Fellowship channel), in screen, on my server, where I can enjoy years of uptime and uninterrupted conversation.

Thanks Jelmer, Maurits and Wilmer.

Changing standards for standards

Tuesday, November 10th, 2009

Yesterday I rattled on about change processes for open standards; or at least, tried to suggest I’d done some thinking on the topic. This post is a little more “meta” because I’m going to point to some articles describing how the standards up to which standards are held, change — in non-open ways.

First off, the Free Software Foundation Europe (FSFE) has a definition of Open Standard. Like I said, it’s one of many; it is based on the European Interoperability Framework (EIF) definition, strengthened a little for Free Software. The Dutch government agency for software, NOiV has a Dutch definition, again directly derived from the EIF one.

There is an update coming to the EIF, described in (among others) ArsTechnica’s “EU waffles” article. The update is still in draft form; the draft was leaked to Brenno de Winter. Since the update was supposed to have been published by now, the fact it’s still in draft suggests that the (non-open) process for updating it is not going too well. Ryan Paul picks out many of the key problems with the new (draft) definition, in particular changing the language from fairly clear, fairly forward thinking, to one that is muddled and unclear. Replacing clarity with confusion does not, to me, constitute a valuable change in a standard (a meta-standard, describing how other standards should work: in other words, muzziness here is damaging across a far wider scope than just one badly-written standard elsewhere).

In a sense, you could say “closed is the new open.” Or maybe “closed is just a kind of open, at the 0.0 mark on the sliding scale of openness.” Yes, and slavery is just 0.0 freedom, and broken is just 0.0 functioning. Indeed, on scales like that, you can make almost anything mean anything at all (lemons just taste 0.0 sweet).

Karsten Gerloff has the FSFE’s response, and points to an article by Glyn Moody (where I see Keith Jones has added a comment that pre-dates this entry, with the same gist — I think he misses the point where the new EIF says “for interoperability, we need open standards, and open standards are ..”; relatively good comments thread there, anyway.)