A sillly destop idea: .desktop files should start with “#! some-new-program” and be executable. Then I could run them directly from the command line. Naturally the script interpreter would know how to parse command line arguments and pass them on to the underlying program appropriately.

I was reading about Gnome 3.0 recently (and I’m working on a long post about it), when I ran across a post by Luis Villa about Gnome versus web development. (BTW you should read his blog if you don’t already.)

I found this pretty compelling in general — it is a nice analysis and it is also a list of things that can actually be addressed without going crazy.

I’m interested in the deployment issue, since I’ve done some playing in this area with Java Web Start. And, though I think I don’t agree that this is really a blocker, it is still fun to think about a bit — the technology is fun and cool, I’m just not convinced it solves a pressing problem. (Your response here…)

First, yes, with C or C++ I think deployment is just going to continue to suck.

Java already solved this problem in a pretty nice way. It is no big deal to write a single-click install, with automatic updating, good security (either a sandbox or signatures for apps that need more permissions), etc. This could use a little work for better Gnome integration, and of course we should be shipping this in Fedora, but the amount of needed work here is quite small. (I assume C# has something similar but I really don’t know.)

I looked into this for Python a little this weekend. And, it looks like Python Eggs and the Python cheese shop provide a nice basis to make this work. Finishing this is pretty concrete:

• Define an XML document describing an application. This would include the same kinds of things that ended up in JNLP: icons, splash screens, the required python version, a list of python egg URLs, etc.
• Add some kind of signing to python egg downloads. Unfortunately I don’t think sandboxing is an option. One idea would be to restrict eggs to python.org and gnome.org URLs — but that interferes with the idea of easy deployment.
• Make a new URL type so that Mozilla will know to run appropriate python script to parse the XML, install the eggs, and launch the application.

For best results this would incorporate some things I was looking at for NetX: having the ability to download an application without running it; dbus integration so that a previously cached application won’t try to update itself in a net-less environment; drag-and-drop of entire applications from Mozilla to the panel; and now, integration with mathusalem when downloading eggs.

I’ve uploaded the slides from my auto-tools talk at NCLUG last night. I had a great time up there, as always, though I missed Bob Proulx this time.

I thought the talk went well. It was a gentle intro to the auto-tools: what they do, how to read the common bits, where to get more information. If you want a really thorough tutorial I recommend reading Alexandre’s 550 slides.

Andrew’s post about hacking the spec file editor using eclipse made me remember something I wish Eclipse could do: integrate better with free software projects.

I mean, it isn’t terrible that you have to download a team spec file, or whatever. But, it seems like things could be much better in this day and age.

For instance, simply clicking on a team project set link ought to pull up the project in Eclipse. That way every project on sourceforge could have a big “Hack Me” button.

I looked and I see I’ve written about this before. I’m persistent, or obsessive, or something.

I tried compiz on my FC6t3 box today. Fun stuff! I think my favorite effect is the deformation that happens when moving windows around… don’t tell my boss but I spent a couple hours today just dragging a terminal window hither and yon. Surely, I thought, the window would tear down the center if I moved it hard enough. But in the end desktop physics proves deceptive — or windows are tougher than they look.

These effects are a great drug. Every release now seems to have some new GUI gadget that flashes or strobes or vibrates. I suspect that those of us who work on free software every day are becoming increasingly jaded, requiring ever-stronger fixes to achive the same “gee whiz high”.

Fedora Core 23 is going to be truly amazing. Windows will emerge from photorealistic 3-D forests, crouching and scowling. We will use Tarzan avatars to bend them to our wills. As their tails lash we will see progress indications, new blog posts, and stock quotes flicker into being and then disappear in the motion.

Subsequent releases will feature themes downloadable from motion picture and television studios. Angelina or Spongebob will dig through layers of rendered mud — mud which on inspection will be seen to have been constructed from the contents of our home directories — to find shining diamonds. We will peer into the diamonds and, deep within their artificial luminescence, we will behold a galaxy filled with Emacs lisp, each cons a star.

I read a thread on the valgrind list about tracking bogus close calls, and I immediately thought that this would be a good job for frysk.

So, I gave it a try. It was absurdly easy to write…

First, frysk has included ftrace in its tree for a while — this is a very simple frysk-based analog to strace. I started by taking the ftrace sources and finding the spot where a system call is printed. Since ftrace.java is all of 200 lines of code, this took about 20 seconds.

Then I changed this code to look for a call to close (another 20 seconds) and in particular a failing call (slightly longer than 20 seconds, due to a frysk oddity — more objective observers would probably note that I hadn’t read the sources…).

Well, that’s it. Unfortunately it still doesn’t work — it turns out that libunwind still can’t properly make stack traces of other processes. I understand this is under development.

That’s disappointing of course. But today, contra both my mood of late and my general disposition, I’m more inclined to focus on the positive. It is very cool that this sort of hacking is so easy to do. In the future I think it will be even simpler: not only will the various bugs be sorted out, but you’ll be able to write little scripts to drive the frysk libraries — using jython, or groovy, or kawa, or whatever suits your fancy.

This ties into a couple of things I think are interesting.

One is that, in Java, most programs double as libraries as a consequence of the design of the language and runtime. No special care is needed to make this work; for very badly written programs you can simply load them via a new class loader and let them operate in their own universe. This in turn makes it much simpler to treat existing java programs as part of a toolbox that you can assemble as you like.

And, frysk is (or for the more cautious, will be) a very useful part of this toolbox — useful in a “java-y” way, in a “script-y” way, and with various front ends, useful in a “unix-y” way, I think. Essentially it enables us to write non-trivial ad hoc debugging and tracing scripts.

I heard about JNotify via the debian-java list today, so I downloaded it and gave it a whirl. While some of the code is a bit yucky (direct calls to syscall? Who does that?), it works quite nicely. And, in true Java style, it makes an effort to be cross-platform; a Windows port is included.

I don’t have any immediate use for this in my own hacking; too bad.

Anyway… I read about inotify a bit more today and I was pleased to discover that a watch on a directory can also yield notification about changes to files in that directory. This means that contrary to what I had heard (irc being what it is), this feature would definitely be usable for speeding up common operations in monotone. In fact, it’s a wonder that nobody has done this already.

Another area worth exploring is changing make to use inotify, to avoid all those pesky stats.

Is it appropriate to say that one has “discovered” a web site? A random aside.

Yesterday I discovered art.gnome.org. Some nice background images are there, and I immediately wondered why this isn’t directly integrated into the Gnome background chooser.

Of course, once I thought this I raced forward to thinking: Gnome really ought to interact with gnome.org in many more ways, perhaps also with a “branding component” (a la Eclipse) so that distros can route users via their sites first.

I’ve been thinking more about the opening of Java.

It is interesting how all the attention has been focused on Sun opening their implementation. For the most part this makes sense, of course — Sun is the center of the Java universe, and the first decision to open has to come from them.

But… seeing as IBM pushed so hard to get Sun to make Java open source, I think IBM not only ought to commit to opening their VM as well, but also do so on the same schedule, and with an eye toward having a single open source JVM project which spans all architectures.