Blow up Pluto

I think we should just blow up Pluto.

This would put the poor bugger out of its misery and end the debate over whether it’s a planet or not. We’d learn a lot from the engineering challenges, and it’d be an interesting social experiment. Who’d chain themselves to Pluto and try to save it? Environmentalists? Astronomers?

Then someone could upload the movie to Youtube, and people would make billions of remixes – a Matrix version, a ping-pong ball version, the Star Wars version which would make it look like Alderaan and superimpose a giant laser on the footage, etc. Enterprising individuals would mix in their favourite musical scores and add subtitles in languages they don’t master. It’d be, literally, a blast.

And the best part is, I’m sure we could pull this off. Just convince the US administration that it’s time to think a little bigger. Make a statement. Show everyone who’s in charge. It’d make a nice little going-away present for the GWB too. You know, real mission accomplished stuff.

FIXME: Article summary here

How many FIXMEs do the various projects in my jhbuild directory have? Curiosity got the better of me today:

hpj [~/work/jhbuild/gnome-2.16] for PKG in $(find . -maxdepth 1 -mindepth 1 -type d | cut -b 3- | sort); do N_FIXME=$(find $PKG -iregex ‘.*.(c|h|py|cpp|cc|hh|cs)$’ -exec grep -i FIXME {} ; | wc -l); printf “% 5d %sn” $N_FIXME $PKG; done | sort -n -r

718 evolution
444 evolution-data-server
429 gtk+
151 gstreamer
148 gtkhtml
147 nautilus
146 gst-plugins-base
125 gnome-vfs
123 ORBit2
107 gst-plugins-good
104 mozilla
89 metacity

…and so on. Try it yourself!

I expect these come in all difficulty levels – from the usually quite easy “should I free this?” to the harder “oh my god I’ve painted myself into a corner and need to re-architect a large chunk of the program”. Some will be worth fixing, others will not. The good thing is that they pinpoint potential problems for free, without having to run a debugger. Something for those oh-so-frequent idle moments?

Garbage in, garbage out

Or with verbs: Connect. Send. Receive.

For a while now, I’ve been of the opinion that we need a generic streaming/networking library for the GNOME core platform, for two reasons:

1. The Unix I/O API is hard to use correctly, and many applications get it wrong.

For instance, a “readable” condition followed by a zero-byte read() means that a socket was disconnected in an orderly fashion. This is not good API.

Problems caused by this API include:

  • Blocking the UI while waiting for a network or file operation. People don’t want to implement a buffering async pump every single time. By the way, did you know that local file I/O always blocks on Linux (and probably most other Unices), even if you set O_NONBLOCK?
  • Spinning on a slow, non-blocking FD, pegging the CPU.
  • Failure to save errno early. This leads to the infamous “Connection failed: Success” and other equally confusing error messages.
  • Not checking for the EINTR non-error, terminating a perfectly good FD and potentially losing data.
  • Writing to a socket that was closed in the remote end, resulting in an unhandled SIGPIPE and terminating the process.
  • Not checking the return value from close(). Very few apps do this. See the close(2) man page for why you should.
  • Closing an already closed FD. Since nobody checks the return value from close(), this goes largely undetected until the code is used in a threaded app. Then it will cause heisenbugs when the FD is re-used by another thread between the first and second close() statements. Unless you know what you’re looking for, this is incredibly hard to pin down.

It would be nice to have a single place in which to fix this. Also, we can provide Windows portability for applications that insist on this (transparently handling the fact that on Windows, files and sockets are very different things).

2. There is too little code reuse in stream implementations.

We need a way to compartmentalize stream elements in C, so that they can be re-combined to achieve specific tasks. For instance, you may want to add a rate control/throttling element to a file transfer protocol, or construct a pipeline of exec() subprocesses – or you may want to do something more adventurous, like SSL + uuencode + unencrypted IM protocol. We can also provide policy to help ease the pain of shunting data back and forth. If you’ve written code that asynchronously forwards data from a pipe to another, handling slow consumer/fast producer and vice versa, you know how ridiculously complex such code can get. What we want (or at least, what I want) is the ability to just connect the black boxes and call it a day.

GStreamer has had success with such an element-based architecture, and I think it makes sense in the more generic case too.

A solution?

I’m working on a library to resolve this situation, with the working title “Flow”. Currently it’s about 1/3 finished, with 10k LOC written. It depends on GLib, GObject and GThread. I’m reusing old network code of mine that is known to compile and run on Linux, FreeBSD and Windows, which should ease portability once the initial API is done.

You can get more details about the implementation I’m aiming for, as well as a preliminary tarball with totally unfinished code in it (but it passes distcheck!). If the response is positive, I’ll transfer it to the GNOME wiki.

I’m aware of other efforts, like gnet and gnetwork/gio, but for various reasons I don’t like them. gnet is too naive, and although James is a great guy, I disagree with him about some of his gio/gnetwork design goals – specifically that elements are always two-way and the decision to implement loadable modules with an XML registry. So rather than spend my time arguing, I’m doing this. I hope I’m not offending anyone too much by doing so.


Right. I’ve written a little script for Cacti, and I’m going to use it to show Telmex just what I mean by “intermittent DSL downtime”.

Intermittent Downtime

The orange bars indicate service outage. Every time this happens, my IP changes as an additional bonus. This has been going on since I got the subscription months ago, and despite numerous complaints and their seemingly sincere attempts at fixing the problem, nothing has changed. Pity me.

Update: I made the trivial script available. It takes one input (host to ping) and returns two outputs (avg latency and loss %).

Ready, on, boil

Got a new boiler installed today. This one is automatic, so we now have hot water on demand – which means I can stumble out of bed and directly into the shower, instead of getting dressed, stumbling outside, fiddling with flammable gas supply, stumbling back inside, staring at my desk for 20 minutes, undressing, showering and remembering to turn the boiler back off. Quite an improvement.

Telmex has been dicking around with my precious Internet all day. After weeks of different technicians demanding I cycle the modem’s power, replace my filters, replace most of my phone cabling (which I, out of sheer desperation, let them do), &c, they’ve been slowly arriving at the conclusion I suggested to begin with: Something’s wrong at the central.

I’ve been patient, letting them do their thing by the book, remembering that if 1) you fail to listen to an engineer and 2) something bad happens, you may be subject to 3) additional screwage, even if 1) and 2) are unrelated.

The central may apparently take another couple of days to fix. To their credit, though, this hasn’t cost me a thing apart from my copious spare time.