Older blog entries for tromey (starting at number 11)

Thanks to everybody who replied to my question yesterday.

raph: I agree strongly that something better could be done. I've often said that nobody would design the current auto* system from scratch. It is something that could only be grown -- each incremental step seemed pretty reasonable, but it left us with an unreasonable result.

In fact, I've spent a fair amount of time thinking about the properties we'd like in the successor tools. To wit:

• Integrate configuration with the build. This has a lot of nice properties, including parallelizability. Right now on an SMP box the build time can be dominated by configure.
• Read all the build description files at once and use a single invocation of the tool. No more recursive make, but we still preserve the nice qualities of having a separate Makefile in each directory. (We might move this direction with automake.)
• Represent tools as objects themselves. This lets us have automatic dependency tracking across all tools. It also lets us do command dependencies.
• Derived object caching. Right now people use cccache, which is nice; this would let us use that same idea for all steps of the build.

Some of this is what I was leading towards in my Software Carpentry entry. Unfortunately I behaved stupidly then and wrote it all on the last day, and as a result I can't recommend reading my entry :-(.

The bigger problems with such a tool are social, I think. Writing it probably isn't very hard. Deploying it would be, though.

For one thing, you'd have to address the reasons that make auto* popular: packages using these tools properly can be unpacked and work on minimal, ancient systems. Being forced to download a new tool is a pain.

For another thing, you'd need to rewrite existing Makefile.{am,in}s. This is a lot of work, though luckily it can mostly be pushed off on the package maintainers. Still, you'd need to do a few large packages by hand, just to make the new package popular enough.

It's hard to believe I can even advocate a from-scratch rewrite, given that I've read Joel on Software :-).

Anyway, in my entry yesterday I was more interested in exploring the emotional side of receiving (and sending) "sucks" email. I think it isn't so much about the reality of whether automake has had an effect or not, but rather techniques one could use to put such comments into the proper (ignorable :-) light.

For instance, in reality I know automake has had a real impact. I wrote a script last year to look at all the SRPMs in Red Hat Linux 6.2. About 50% use autoconf, and about 25% use automake. So that's pretty significant. I'm happy about that.

But even with this knowledge it is hard to read email about how the program sucks. We're not talking about reasoned criticism here, or even observations like raph's that the system as a whole is incoherent and overly complex. I think what happens is that the non-reasoned parts of the message somehow bring up my fears ("automake really does suck", or "everyone will read this and tomorrow switch to something else"), and that in turn makes me angry.

madscientist: I've tried the trick of writing an email and not sending it. Sometimes that satisfies.

Jim Meyering pointed out that my reply to yesterday's message wasn't really a flame anyway. And I guess this points towards another solution: fighting fair. For instance, comment on positions, not personalities.

I think the bigger picture, in terms of my response, is learning (once again) to insert my consciousness into the process. That is, don't simply respond, whether angrily or not. Instead, measure my own temperature, understand the reasons why, and only then respond in keeping with my "best" goals.

On the other side of things, I've learned over the years to temper my bug reports. I make a real effort to avoid the sorts of absolute, dualistic modes of speech I frequently see in hacking circles. For instance, I try not to write things like "this is completely broken" or "useless". Instead I find a more moderate tone suffices: "I think this is a bug", or "I would prefer that the program do ...". Changing my thinking, and thus my writing, in this way has really been an uphill battle. It's been interesting, though, as the more I'm able to do this the more I see how prevalent it is in the free software world.

Today I saw yet another "automake sucks" email. This time I ended up writing a mildly flamish reply. I hate this dynamic.

First, I hate being goaded into a reply. I'd rather be above it all. After all, while automake is flawed, most criticisms of it are really off-target. I don't mind reasoned criticism of automake's problems. In fact, that sort of thing is really useful in helping us understand what to do next, etc. But the typical "sucks" email isn't that. It is frequently someone's emotional reaction to some particular annoyance they've run into.

Not that emotional reactions are bad. I'm also occasionally irritated by the programs I use. Most of them have bugs and design flaws. I even sympathize with people who are frustrated by automake; I feel that same frustration sometimes.

Still, it is hard. I end up flaming people like this more frequently than I'd care to admit :-(. That's my own emotional reaction to their email -- a vicious cycle.

Do other free software hackers have this problem? I wonder if the volume of suckage email is something peculiar to automake (I suspect it is :-). How do you deal with this sort of thing?

Saw some movies recently:

• On Friday, Kissing Jessica Stein. It had some funny moments but really isn't recommendable.

• On Saturday, Minority Report. I liked it, and I don't really like Tom Cruise. Parts of it don't make sense logically (the set-up is self-supporting from the wrong end), but that's ok. It provides some nice insights (the various impacts of ubiquitous recognition technology, the casual benefits of being a precog) in an offhand, understated way.

• Tonight, Some Like It Hot at IFS. I hadn't seen it on the big screen. I laughed just as hard as I do every time; great movie.

Haven't done much non-work hacking lately. Automake mostly flies under Alexandre Duret-Lutz these days.

I finally checked in my direct-threading patch for the libgcj bytecode interpreter. This speeds things up quite a bit in most cases. But really haven't done anything more recently.

Lately I've been interested in multimedia and gstreamer, but since I got back from my various trips I haven't had time to really work on it. Plus, Red Hat Linux 7.3 doesn't like my video card too much; playing mpegs hangs the X server. And, anyway, with summer comes a more crowded social calendar.

Lately I've been thinking a lot about the many problems with how organizations, particularly corporations are structured and run. I'd prefer something flatter and more democratic, without the sorts of autocratic, demoralizing changes we ordinarily see. Books read: Peopleware (a classic, must-read book for computer professionals) and No Contest (still reading that one).

Lately I've done a ton of Classpath/libgcj merging. That's easy and makes me feel like I'm making progress. Also I wrote the assert feature for gcj -- I always make some nice progress on a self-contained project like this when I'm on a trip.

I saw a few movies lately:

• The Importance of Being Earnest. Enjoyable, though in the end it was missing some emotional punch. Still, I recommend it, if only to watch Colin Firth prance around.

• The Bourne Identity. There's an obvious Unix parody to be written here. The shell forgets its identity, acquires features, re-emerges as bash or zsh. Something like that. Anyway, for an action flick (I usually practice genre-relative reviewing) this was pretty good. It exceeded my expectations, which were quite low.

• Attack of the Clones. Not as bad as number 1.

• About a Boy. This was pretty good, but still missing something. Also I found the character development a bit trite.

• Sleeper. I saw this at the outdoor theater here, which is always fun.

• Monsoon Wedding. Loved it. Though Elyn pointed out that if it were an American film, I would hate it for espousing traditional values. Still, the energy and flair were there.

• Scotland, PA. A sometimes funny take on MacBeth, set in Pennsylvania of the 1970s. In the end I don't really enjoy cultural parodies like this. Plus, for me the real greatness of Shakespeare comes in his language, not his plots, and this version rewrote the script.

Yesterday I checked in what I hope is the last bug fix for gcj for the 3.1 release. That's a relief; on to new things.

Last night I saw a movie called American Astronaut. It is a musical comedy space opera western. More or less. It is one of the strangest movies I've seen in quite a while. I recommend it if you're feeling a bit silly and don't mind low-budget indie movies. It was inventive and enjoyable.

Another couple weeks spent on gcc 3.1. Luckily, this is going to end soon. Today I worked on what I think is the last critical gcj bug for this release.

We have a bit of a problem in gcj, which is that only two people (Alex and Per) are familiar with the front end, and only Alex is really familiar with certain parts. They're both apparently pretty busy with non-gcj stuff, which means that compiler problems go unfixed, patches go unreviewed, etc. Somebody needs to step up here. Maybe me.

I've been looking at Gnome again a bit. Today for fun I wrote a little gnome-session patch. It's pretty silly. I've also been looking at GStreamer, which looks quite nice. The documentation is pretty good overall, but there are still some important missing pieces.

I've been working on gcj 3.1 pretty much full time. Don't these entries get boring?

One thing I've noticed is that saying the words "upcoming release" acts much like chumming for sharks. Suddenly all these bugs I've never heard of appear, and suddenly lots of platforms that ordinarily never see patches start getting three or four a day. Keeping up with this is taxing.

It makes me wonder if there isn't something better we can do. Currently I'm leaning towards just incremental improvements: writing more tests, more documentation, having nightly regressions on more platforms. These things would at least let us know when we broke something that used to work.

Today I took a break from gcj 3.1 release work and replied to some Automake email. I also did some AWT hacking; most of the TestAWT application works with gcj now. The hardest thing is finding relatively simple AWT applications so I can test it.

I've been continuing to work on gcj 3.1. Things are coming along nicely. This is going to be an excellent release for us.

Last night I also did a little bit of work on Automake. We'll release 1.6.1, a bug-fix release, as soon as we fix the major bugs found in 1.6.

Today I read the guest essay on linuxandmain.com by Shawn Gordon. He argues against using the GPL. Now, he might have a good reason, but his examples and other supporting arguments really aren't very good. I'm not linking to it since really it isn't worth reading -- it isn't a serious essay.

Last night I gave a talk on autoconf, automake, and libtool at the local LUG. It went pretty well, I think, especially given how nervous I was at the start.

Lately I've been working on getting gcj 3.1 ready for release. You can see the status.