If you’re interested in programming languages and you’re in Cambridge, you should come to this Boston Lispers meeting. The author of Clojure, Rich Hickey, reportedly gave a great talk at the JVM languages summit which hopefully he’ll reprise here!

At the plumber’s conference right now, just finished watching Arjan and Auke’s 5 second boot time talk. Very very impressive talk.

They drove a lot of changes into the entire stack, from how the kernel works to fixing HAL and X.org bugs, filesystem tweaks in order to get to 5 seconds. Of course they cut out some things too – since the netbook targets are mobile single user machines, they don’t use GDM, I’m pretty sure they aren’t starting CUPS, etc.

But this talk led me to only feel more strongly about something that I’ve been feeling increasingly more lately – that we have been far too complacent about accepting “Linux distribution” as a concept. This is the idea that you can take the Linux kernel and a variety of tarballs found on the Internet, compile them and put it in some variant of tar, and you have an operating system. It turns out it’s not that simple.

To create a compelling system, first, you need to make decisions about how things work and how things fit together. The “Linux distribution” mindset is an excuse for having different vendors make different decisions and we end up sharing very little. We need people like Arjan’s team, the Ubuntu team, the Fedora team, the OpenSuSE team to share far more than we do now. I think a lot of vendors (“distributions”) tend to have an insular mindset where they think they are the center of the universe and why doesn’t everyone just join their project anyways?

Five or six years ago I think there was more of a mindset that Linux and the Free Desktop was going to take over from Windows (“year of the Linux desktop” and all that) and each vendor thought they were going to take over the world and consequently were less interested in collaboration. Personally I don’t think we’re going to see that sudden takeover any time soon, but at the same time if we do things right there is a lot of opportunity.

It’s easy to say distributions are bad of course – far harder to actually collaborate better. How do we do that? Here’s an idea:

Share a core OS image built at freedesktop.org

We’re not going to unify all the different packaging tools tomorrow. However, there’s no reason that the core OS build tools and image (kernel, dbus, HAL, X.org) couldn’t be shared. So “distributions” could keep their favorite variant of tar and wget (.deb and apt, rpm and zypper, rpm and yum) for everything outside of the image. In other words you could still do “apt-get install epiphany” or “yum install httpd” whatever other app on top of the image and that would still work in a normal “packaging” way, but the core OS image would be rsync’d outside of that.

Each vendor would still control all of the code – each component of the image could have a “vendor” branch where vendors can add kernel drivers and the like. Image update policy would still be controlled by vendors.

There of of course other things that it’s completely stupid to fork like bug trackers and more importantly the bug reports. We need to do a much better job of sharing bugs in the right place – the upstream project.

In a sentence, take projects like freedesktop.org and gnome.org as more than just tarball sources and turn them into real collaboration points where things get tied together, sharing actual infrastructure. It wouldn’t be easy but really, we need to stop thinking that it’s acceptable to have 5+ major forks of the core OS infrastructure.

I’m back to using Emacs for editing C and Python code for now. There are various reasons for this, but mainly it comes down to the fact that I need an editor and not an IDE; creating projects just to edit a bit of code is too much overhead, at least in the IDEs I have tried. Now, one major problem Emacs has had forever is that people (including me) have implemented new modules for it that “unbreak” various parts, but the maintainer has been very conservative about changing anything.

For this reason, here’s what I consider the “minimal unbreak Emacs .emacs” file:

;;; Minimal Unbreak Emacs
; Waste of display space if you can't click on it
(if (not window-system) (menu-bar-mode nil))
; Really.
(iswitchb-mode t)
; Assuming you didn't use Emacs from before when the concept of
; selecting a single region of text interactively was not supported.
(transient-mark-mode t)
; This one is actually fixed in Emacs 22; http://www.emacswiki.org/cgi-bin/wiki/CopyAndPaste
(setq x-select-enable-clipboard t)
; The default for "uniquifying" buffer names sucks
(require 'uniquify)
(setq uniquify-buffer-name-style 'post-forward-angle-brackets)
; Slightly more debatable
(global-set-key (kbd "C-x C-b") 'ibuffer)

(set-scroll-bar-mode 'right)

; Custom keybindings
(global-set-key (kbd "C-c i") 'imenu)

Technically I shouldn’t be giving you a C-c prefixed function, but I don’t know of another good place for it. Anyways, enjoy. Someday Emacs will come out of the box unbroken; it’s happening, just very slowly.

Federico, self-signed certificates disproportionally affect programmers (particularly Free Software programmers) using random homebrew bugzilla instances. For a website with any kind of real user base, the hosting fees and salaries of the programmers/designers/etc. are going to dwarf (by orders of magnitude) the cost of a SSL certificate. Does it suck that you have to pay a fee to avoid a dialog? Sure. But rather than complain, some smart person needs to think of a way to make a distributed system that actually works with non-cryptographic expert people in some way; i.e. doesn’t just ask you “Do you trust this hex number”?

I won’t do this too often, but two things I saw today that were interesting:

• An Ars Techncia article on Larrabee, Intel’s new graphics architecture. Kind of scary they say “micro-OS” instead of “firmware”…is my next graphics card going to be running Linux? Regardless, Ars Technica has a well-deserved place in my feed reader.
• This thread on the Clojure group by a guy who wrote a DSL and compiler targeting Excel spreadsheets, originally in Ruby and now in Clojure. This is one of those things that remind me how different the day to day life of other programmers is from mine.

The Old Way:

1. Developer in libfoo (a C library) works on solving a problem, decides to create foo_bar() function
2. Function foo_bar works, and is committed
3. A period of time later, a new shared library appears in OS update package
4. You install the package
5. You try to use function bar from your favorite $LANGUAGE bindings, but it isn’t bound yet
6. You curse and go searching bugzilla to see what the status is
7. If upstream is active, some manual review is done to make sure the function is sanely callable from $LANGUAGE
8. If the function has some special requirements, sometimes metadata is manually added to hackish .defs files
9. A patch is eventually made and committed
10. Another period of time later, new bindings appear
11. You can call foo.bar()

Note that steps 7,8, and 9 have to be repeated for each binding, be that PyGTK, Gtk#, java-gnome, etc. Even worse they all have divergent .defs files.

The New Shiny Future Way:

1. Developer in libfoo (a C library) works on solving a problem, decides to create foo_bar() function
2. If it is not sanely bindable, author gets warning from g-ir-scanner, reworks it or adds metadata, commits
3. A period of time later, a new shared library appears in OS update package
4. You install the package
5. You can call g.foo, because your $LANGUAGE bindings use GObject-Introspection

The new way, obviously, is going to be significantly better. By actually including all the metadata necessary to interface with the system in the shared library (.so) itself, we eliminate a large lag time before improvements in the lower levels of the stack become usable to bindings. Even more important I think is that by integrating into the build process of the GObject-based C libraries, we can help ensure that authors don’t add new interfaces that are difficult to bind.

Why am I talking about this? Well, I just reached a major milestone in a side project I’ve been working on. Here’s a screenshot:

Instant GObject/WebKit bindings for the JVM

And not just WebKit of course – this is a large step forward for Java bindings for Gtk, Clutter, libnotify, libgypsy, various canvases like hippo canvas and in general the entire “Free desktop stack”.

Of course because it’s Java, it’s also instant bindings for Jython, Rhino, JRuby, Groovy, etc. Just ran this program with Jython trunk:

from org.gnome.gir.dynamic.WebKit import *
from org.gnome.gir.dynamic.Gtk import *
from org.gnome.gir.gobject import *

GObjectGlobals.init()
GtkGlobals.initCheck(None, None)
win = Window(WindowType.TOPLEVEL);
sw = ScrolledWindow(None, None)
win.add(sw)
wv = WebView()
wv.open("http://www.gnome.org")
sw.add(wv)
win.setSizeRequest(640, 480)
win.showAll();
GtkGlobals.main();

I just tossed up a web page for the project here. Right now it’s basically blocked on finishing gobject-introspection itself; finishing the .gir to .repo compiler. So I’ll be looking at that. My personal goal was to get bindings for some canvas (probably hippo), and clutter, along with all of Gtk+.

Let’s take a step back though. What I think is interesting about this is that it enables much more seamless multiple layer applications. I blogged about this before. At the bottom, you have unmanaged C (GObject) code. In the middle, you have a managed, statically typed core (Java/.NET). At the top, you have a managed, dynamic language (Groovy,Boo,Python,JavaScript). GObject-introspection dramatically lowers the pain for going between the bottom and middle layers. Using the JVM (or .NET) makes the middle and top layer transition much nicer, especially for a runtime-native language.

Realistically landing and finishing all of this is probably a year out at the earliest still. But it’s fun to hack on!

Edit: By the way, HotSSH version 0.2.5 is out, and this one actually has a README that tells you how to install it! It fixes various bugs, and most interesting it has the favicon work.

Awesome. In the near future, I can record a .OGG file, toss it up on the web somewhere (say my personal S3 bucket), and link to it in my blog with <video>. Now I have another motivation to make sure my family is using Firefox. Of course really what we also need is a general video hosting site that uses <video> – does one exist yet?

Today I spent a good chunk of time going through DBus bugs and pending patches. There are still some major things outstanding – large patches for Mac OS X and Windows integration, Scott’s timeout work, but I have a feeling after those we’ll be at the point where it really is basically done. Now we’re moving on to replacing the init system. Woo.

But, that’s not what is exciting about today. Is there anything exciting about today? Well, today is the day that Unix gained /etc/favicon.png. No, I’m not talking about HTTP, I’m talking about a HotSSH patch that I finished on the shuttle ride back:

Note the tabs have icons

The GNOME sysadmins haven’t yet put /etc/favicon.png on window.gnome.org, and I stole the freedesktop.org favicon for my local machine to test

Basically when you open a connection, we asynchronously run some Python code on the remote machine to test for the existence of /etc/favicon.png and if it exists, its mtime. If the cached favicon we have is old or nonexistent, we (again asynchronously) retrieve it via scp. All of this reuses OpenSSH’s connection sharing so you don’t have to reauthenticate for any of this.

A quick Q&A:

• OMGWTFBBQ! – That’s not a question.
• I’m a system administrator and I have a favicon.ico for our website, how do I set this up? – Run convert /path/to/favicon.ico /etc/favicon.png, copy around to all machines as appropriate, put it in Puppet or whatever.
• Are favicons associated with hosts or keys? – Good question, right now I attempt to associate them with the host key, but OpenSSH’s host key hashing foils that sadly. So probably with the host.
• Why? – Because it’s faster to recognize images than text.

Thomas blogged about my nemesis, bug 482354. I’ve been trying to upstream the fix for unbreaking clicking on links for quite a while now.

In it, Christophe brought up Rhythmbox, which is quite similar to Pidgin in how it acts with the tray icon.

Several years ago I was chatting with Seth about Rhythmbox and he mentioned that he thought it was a fairly special kind of application because it is generally used in a very “transient/background” way. For example, a normal way to use it would be minimized to the tray (not even in tasklist at the bottom); then when you want to switch songs or albums, you click the tray, do a quick search, and then minimize again. This contrasts with “regular” applications like Eclipse, Firefox, Evolution where it’s expected that you will often spend a substantial amount of time in them in one go.

The tray icon approach sort of works, but I think we could do better. Following is a potential approach that I’m recording in my blog so I don’t forget, and of course to gather comments.

Transient Application

First, for reference here is how Rhythmbox currently looks:

Unmodified Rhythmbox

And here’s a mockup of how it could work:

How Rhythmbox could be a “transient” application

The general idea is to treat the application window like a really fancy GtkMenu. Here’s a concrete list of user-visible behavioral changes:

• Clicking anywhere outside of the window causes it to minimize back to the tray icon.
• It does not appear in the task list
• There are no minimize/maximize buttons
• The close button does not actually exit the app (i.e. stop your music), but just minimizes
• There is a visible arrow showing you the association with the tray

Overall I think this approach will make the “show Rhythmbox window, choose song/album, start playing, make it go away” task nicer since you’ll only have to move your mouse to the tray icon and click once (to open) instead of twice (once to open, once to close). It will make it a lot clearer to the user what’s going on (in the current Rhythmbox we have the minimize/maximize animation, but no arrow).

Implementing this would require window manager changes, new GTK+ API for GtkStatusIcon, and updating several applications that fall in this category (Rhythmbox, Pidgin, Banshee, etc.) to use it. Also someone with actual graphics skills would have to draw the arrow. Does that sound like a lot of work just to save you one mouse click? Not when you’re applying the forehead mashing method of user experience improvement!

Now to find some time to implement it…

Edit: – I forgot to mention this would also be perfect for the new NetworkManager connection dialog.