Archive for August, 2006

Playing with frysk

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.

Beerfest

Should I be embarrassed that I enjoyed this movie?

Ever since Super Troopers (another film I rarely own up to liking) I’ve vowed to watch all the Broken Lizard films as they arrive. I was disappointed by Club Dread. And, truthfully, Beerfest isn’t really all that great.

Nevertheless, I’ve been a bit unhappy lately, and I really needed to see a silly movie about a secret beer drinking contest. And, what luck — there’s one in the theaters!

JNotify

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.

Gnome Art

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.

What’s good for the goose

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.

Open Source Java

You’ve probably already read about Sun’s continuing effort to open source Java. And, before I get too far into what I have to say — my preliminary reaction is that this is awesome.

Sun has even made a couple nice ways to provide feedback.

I think quite frequently about the properties that a free Java implementation must have; this, after all, is the reason for the existence of Classpath and gcj. I’m going to make a stab at writing them all down here, in the hopes that this helps the efforts at Sun.

License

What license should be used?

I don’t have a particular answer to that. However, I do have a few requirements to place on the result.

First, the license absolutely must be open in the DSFG sense. This probably goes without saying, but I figured I’d be explicit.

Second, ideally the license would be GPL compatible. It doesn’t make sense to me to limit innovation by closing off the JDK from mixing with an entire class of software. Also, a move like this would be an important victory in the battle against “license silos” and for license harmonization — important because, let’s face it, the opening of the JDK will be a truly significant open source event, the most important one in years.

If GPL compatibility somehow cannot be achieved, LGPL compatibility is still required. The reason for this is that a reasonable chunk of the platform (e.g., all the gnome-ish GUI libraries) are LGPL. This is a much lower bar to meet, I’m sure there won’t be a problem here.

Likewise ASL compatibility is a must.

Geir claims that the GPL would be a bad choice. From my perspective it would not be. True, Classpath isn’t pure GPL — but that is largely an accident of history, based on the embedded systems origin of gcj. My impression now is that with the advent of embeddded Linux, the embedded world has largely crossed the GPL barrier. Beyond that, my focus these days is really on the free operating systems like Linux; GPL would present no problems for, say, Fedora.

One important consideration in the license is what to do about patents. This isn’t really my area; I think patents are pretty bad and so I have a huge blank spot in my brain about them, a spot which is filled with a mixture of denial, anxiety, and loathing. The key is to make sure that the result is acceptable to the various players — corporations and also nonprofits like Debian or Fedora. This shouldn’t be hard, plenty of other organizations already have done it.

Compatibility

Sun worries about compatibility. I hope those fears can slowly be put to rest. At least here in the free world, we recognize that compatibility is very important. In fact, we put an absurd amount of effort into guaranteeing compatibility in Classpath. The whole point, for us, is to make it possible to run the enormous body of existing Java code on free OSs.

Ideally the TCK would also be opened as part of Java. I picture Fedora’s Sun-based Java RPM working much the same way as the GCC RPM: we would run the TCK as part of the build process, and die if it does not pass. This would provide critical quality assurance.

Note that rules requiring testing of binaries by some 3rd party won’t work too well. For Fedora and the like, the ability to build from source is crucial. This is especially true as the kernel and glibc hackers continue to innovate — over the years changes in these areas have caused problems for the various proprietary JVMs. (And, supporting this whole opening process: had the JVMs been opened, we would simply have fixed them. But due to their closed nature we either required workarounds, or simply lived with the brokenness.)

Sharing

We’ve heard that not all of the code will be available under an open-source license. It would be great to get more details on what, precisely, won’t be available.

The sooner we get feedback on this, the better. This seems like a great area for collaboration to occur. I can think of a couple ways to make it happen.

First, if the problem areas are already implemented in Classpath, we could open a discussion on contributing them. RMS would most likely have to be involved — but, really, his reputation is much worse than the reality. I’d support cooperation along these lines (assuming of course that the baseline is met properly: an acceptable license, etc). There are probably a few interesting things in Classpath that would benefit the JDK.

Second, if the areas in question aren’t covered by Classpath, maybe we could put a little focus on them in order to have the code available when the JDK is opened. This needn’t be a Classpath-driven effort — I’m sure many people out there would be interested in this same result.

Governance

There are plenty of well-run free software projects out there. Choosing a functioning governance model isn’t that big of a deal any more — heck, folks at Sun can just walk across campus and ask people working on any of their other free software projects. I’m just not concerned about this; the biggest thing is to have a committment to success, so that if something isn’t working, you change it.

That said, there are a couple things worth noting.

The JCP could be more open. Both Dalibor and Geir have covered this point well. Listen to them!

I’ve read the occasional blog entry worrying about simply opening the process to anybody. I agree with Simon here — anarchy is no way to run an open source project. I can’t think of a single successful one that is run that way; instead, developers have to earn their stripes by a process of patch submission and review. I don’t think Java should be any different; if anything, the barrier to entry ought to be a bit higher than ordinary, since Java is a large, mature, and (presumably 🙂 stable code base. We certainly vet people before giving them access to Classpath, and we also watch them more carefully just after they’ve been given commit rights.

Final Advice

You’ll probably see a lot of random, uninformed, and hostile commentary on slashdot and javalobby. At least, that’s been my experience historically — “open source java” is a big red flag for the bulls. My advice is, ignore the crap and concentrate on pushing forward.

Fedora Core 6 (test 2)

Last week I installed FC6 test 2 on my laptop. I did an upgrade (using CDs) from my FC5 install.

The install itself went very well. Anaconda weirdly showed strange characters while in text mode, but this was ignorable.

FC6 is shipping a new Eclipse — 3.2. This works pretty well; I found a bug or two and reported them, but nothing too serious. So far I haven’t explored many of the new features, but I did notice that I can now background “cvs diff” operations. I’ve been wanting that for a while…

The notification area on the panel is now properly translucent. For some reason its opacity really bothered me, and this is one of the few Gnome bugs I CCd myself on.

I installed yum-updatesd so that I could run puplet. So far it seems nice, though I have to say I preferred the old RHN icon (I’m probably the only person who liked that :-). But, icons always change; I’m very happy to have the functionality. I’m not too good at remembering to periodically “yum update”, you see.

In somewhat related news, I’ve been trying the Gnome sticky notes applet for managing my to-do list. We’ll see how that works out; over the years I’ve tried many different programs in this space, with little success.

Overall FC6t2 looks quite good to me. I’m constantly amazed that this whole process (not Fedora, but the entire free software setup) produces good results — and yet it does, year after year.

Miami Vice

As I left the theater, an albino guy was sitting by the bike racks, smoking a cigarette. As I passed he said, “that was a movie with no soul”.

And though it was interesting, at times gripping, and darker than the series — yeah.

Normally a good soulless movie reminds me not to be too complacent: sitting in Boulder, hacking on free software all day, it is pretty easy to engage with my problems, personal or profressional, and neglect some of the wider issues.

But, soulless isn’t what these “fear up” times call for, and so to me this movie struck a discordant note. I don’t need to see soulless, I’m soaking in it.

New Stuff Manager

I read about the New Stuff Manager on some Gnome list recently. Essentially it is a way to download python applets (into the deskbar… I don’t think I know what that is) from the net.

The design is rather scary… as in, maybe it will have signatures of some kind for security. No sandboxing available.

Naturally this area is already addressed in Java; there’s JNLP (aka “Java Web Start”; I never did learn what that acronym stands for. Probably, “Hey, This is Cool”). The idea is that applications are described by some XML, can be downloaded from the web, can be run in a sandbox (or signed and then trusted), can auto-update themselves, and a couple other niceties. I’ve blogged about this all before, since I occasionally play around with the netx implementation.

In fact, my goal with netx goes a bit further than the New Stuff Manager: I want to be able to drag a JNLP link from mozilla to the panel, and have it automatically cache the application for future offline use. As part of this it should also be possible to preload the JNLP cache with useful applications. Most of the pieces to achieve this already exist.

What stops me from finishing it, aside from the usual things, is that I’m not really convinced it serves a need. My own experiments with it have been technology driven — it is fun to play with. And that is fine for playing around. But in terms of, say, putting this into the platform, the question has to be whether it serves a user need.

Right now I don’t think that deployment is the most pressing issue facing Gnome. It seems unlikely to me that it is even on the top 5 list… instead Gnome seems to be in a more serious existential crisis, trying, once again, to decide what it is all about.

That said, there are situations where being able to download little runnable bits in a secure way does make sense. I’m thinking about Apple’s dashboard here — an area where applications are small, highly specialized, and perhaps topical or timely (e.g., I saw one for tracking world cup scores). One way to approach the security problem might be to simply restrict all downloads to gnome.org, and then have a vetting process before uploading anything; but this is really second best to having security designed into the runtime.

Speaking of Gnome — lately I’ve been wishing that Gnome had a “task manager”, which would sit in the notification area and track long-running tasks for me. This would let me start something (a download, a build in Eclipse — even a “make” with some little wrapper script) and then switch virtual desktops (or hide the application), so I could ignore it until it was finished, at which point it would pop up a helpful notification. Perhaps the applet would have a way to cancel the task a well.  Is this loony?  Has anybody else wanted this?