Havoc's Blog

Nat’s
X‑rays look extremely similar to mine. I don’t even want to think
about how badly that hurt at the time. Everyone be nice to Nat.

(This post was originally found at http://log.ometer.com/2004–11.html#22)

Ross,
my favorite feature request for SJ is a better way to handle my CDs
that come up “unknown” — it might be nice if SJ supported submitting
the info to MusicBrainz? (Doesn’t
it use MusicBrainz? I don’t even know.) Also, e.g. MusicBrainz lists
two different Daydream
Nation but my Daydream Nation comes up as unrecognized, so perhaps
some sort of feature where you enter the title and artist and it pulls
down the track names, and then sends a new CD signature to MusicBrainz.

That said I really love the simple
just-does-what-I-want-without-a-lot-of-nonsense aspect of Sound Juicer
so feel free to ignore my features to preserve that. 😉

(This post was originally found at http://log.ometer.com/2004–11.html#20)

I got a ton of suggestions for the home music system, it will take me
a while to process, try some things, and post results. (Since I know
everyone is in suspense to know how the very last hacker on earth to
get around to a home music system will set it up.)

(This post was originally found at http://log.ometer.com/2004–11.html#20.2)

Luis, if you read
Hyperion be sure you have the sequel handy, since the first book
pretty much just ends in the middle of the story. The second book
seems to have a good stopping point. I haven’t read the other ones.

(This post was originally found at http://log.ometer.com/2004–11.html#20.3)

I’ve been reading version control system manuals lately for some
reason, joining the Colin
club. Also talked to Graydon a little bit about monotone since he’s in town for
the Java summit.

Here’s how I’d like to go about comparing these systems. (I didn’t do
it yet, I may be too lazy for now.) We should be able to look at how
our software development process works and make a list of the tasks
involved; and see how well the various source control systems support
those tasks. I admit, this ignores the potential for an
earth-shattering revolution in the software development process by
presupposing what the high-level tasks are. But it sounds useful to
see which of these systems most nicely supports our current process
and social organization. Or perhaps we’ll see that they are all
essentially the same.

Here are some example tasks:

• Starting work on a new patch with a defined goal
  (“I want to fix bug #123456”)
• Submitting a patch to the mainline project
  (“Dear maintainer, here is my fix for #123456, please apply”)
• Reviewing pending patches for one’s own mainline project
• Accept/reject patches, with comments
• Make a new development release
• Make a new bugfixes-only stable release
• Backport a fix from the development version to the stable
  version
• Restore a recent (perhaps never-submitted-to-mainline) version of
  a file you’re working on, since you just accidentally deleted it
• See what changed recently that may have broken the build
• Get the latest version of the software
• Adapt a patch to work with a different version than the one you
  wrote it for (aka resolve conflicts)

For each of these tasks, we should be able to completely describe the
stuff you have to type and/or click on to perform them using each
system. Right now many of them involve bugzilla, mailing lists,
etc. in addition to a source control system. Which points to the
potential usefulness of a comprehensive UI for programmer
collaboration, designed for the open source process… someone write
that. 😉

In addition to the steps to do each task, we might want to note any
interesting properties of each task using each system. For example,
whether the task can be done offline; whether it’s slow or fast;
security concerns; etc.

Part of the reason I’m thinking along these lines is that in looking
at monotone, I get the feeling I could do a lot of really neat things
with it but that right now it’s a little too “policy-free” and these
neat things might require too much thinking on my part.

A fun thing about monotone is that it’s peer-to-peer based on public
key crypto; you can make assertions about changes to the source tree,
and you can collect other people’s assertions. To define the
“mainline” of a project you would say something like “use all changes
to branch foo signed by person a, b, or c” — while with CVS you say
something like “all changes to HEAD that are on the server gnome.org.”
Given the recent freedesktop.org hacking incident, I can see the merit
of the monotone approach. There’s no way to tamper with a source tree
without stealing a private key and passphrase.

Graydon said today that he’s looking at including in the repository
itself the list of “committers” at each point in the revision
history. So say I start a project and work on it for a while; at first
the project mainline is defined as all revisions I have signed with my
key. At some point I could change the default committers for the
branch to include Colin; and then anyone checking out the branch who
doesn’t specify otherwise would get stuff either one of us had
signed. Patches Colin submitted before he became a committer, however,
would not suddenly be added. And if I later kicked Colin out of the
project, his post-kickout changes would not be used either.

With monotone today, as I understand it you have to specify on your
own local system all keys you trust to make changes, and then all
changes signed by those people are in the source code you check out.
For something like GNOME you can imagine the mess as our
trusted-persons lists got out of sync, and we each had a somewhat
different version of the code.

I know Graydon could explain all this more accurately than I can.

Here are a couple more feature ideas I have.

• The version control system keeps track of how to submit patches
  (mailing list, bugzilla, etc.) and has a “submit patch” command.
  (Prereq: the system has a concept of a patch you’re working on for submission)
• The version control system tracks submitted patches for the maintainer
  and supports easy review and acceptance/rejection of them.
• Easy way to have a conversation about any patch (as we do now in
  bugzilla typically)
• Allow the maintainer to easily hack on the patch, merge their changes
  with it, and then bounce the patch back to the submitter for more
  work — I often want to just fix the nitpicks instead of writing
  them down, then give someone the patch back to fix the big stuff.
• Often you want to commit a number of times before you submit a patch
  officially (sometimes people will make a CVS branch for this).
  A nice feature would be to avoid the need to do this manually;
  just have the developer tools automatically “commit” every time you
  save from the editor, or even make the whole undo buffer persistent.
  Much more plausible with monotone than with CVS.

Anyhow, there’s unquestionably a lot of room for improvement in our
developer tools. One of the questions in my mind is how far you can
get if you define the problem as only version control; at some point
the really useful stuff would involve the editor, the bug tracker, and
so forth as well.

(This post was originally found at http://log.ometer.com/2004–11.html#19)

We bought a
really strange game.

(This post was originally found at http://log.ometer.com/2004–11.html#16)

I shouldn’t say Tivo sucks; I admit I’m doing something obscure and
geeky with the file share of music. But, while I’m complaining about
home electronics, I do have a basic Tivo complaint: they need to be
the cable box.

In Raleigh, we had a PVR that was built in to the cable box. Compared
to Tivo, it was buggy and the UI was atrocious. However, it had
several vital advantages over our current cable-box-plus-Tivo setup:

• No lag due to Tivo-acts-as-remote-control-for-cable-box
• The program guide was more accurate, so shows didn’t get clipped
  at the end
• It had multiple tuners, so you could watch a show while recording
  another
• It would avoid problems such as changing the channel while recording,
  or leaving the cable box on mute
• One less remote control
• You can’t use “On Demand”, Pay Per View, and other cable features
  from Tivo

No question that the cable companies are deliberately squeezing out
Tivo, and it’s pretty sad that Tivo created this category of device
and probably isn’t going to benefit from it in the long term. I don’t
know how Tivo can get around the situation though: a combined cable
box plus PVR is a dramatically better user experience, even if
the cable box PVR is pretty lame compared to Tivo’s.

I guess you can get Tivo integrated with a satellite box, one reason I
wanted satellite instead of cable. Sadly we have too many trees.

This is incidentally another reason I haven’t tried MythTV; I’m hoping
to get a PVR from the cable company. I’m even feeling a bit friendly
toward Comcast, since they just wholesale rewrote the UI
on the cable box and the new one seems optimized for, say, watching TV
(rather than whatever the old one was supposed to be for).

(This post was originally found at http://log.ometer.com/2004–11.html#15)

About 5 years behind the curve, I decided that it would be nice to rip
all our CDs, box them up, put them in the basement, and play the full
music collection on shuffle.

To start, I got an external hard drive and the nifty Linksys
NSLU2. The NSLU2 is a $79 Linux server with two USB ports. You
give it a blank USB hard drive, and it formats it with ext3; one small
partition has some admin files for the OS, and the other partition
holds your data. The NSLU2 runs Samba and acts as a file server.

So my plan was as follows: let NSLU2 format the drive, then attach the
drive directly to my laptop and rip CDs onto it. Move the drive back
to the NSLU2 and voila, a file server with all my music. This part
worked great. Even better: since I was using Sound Juicer and
HAL/gnome-volume-manager in Fedora Core 3, I believe it could have
been done without a command line. (Though I cheated and got rsync
involved.) Now we can access all our music from any of the 3 PCs.

The reason I got the NSLU2 was that our PCs are off most of the time,
since they’re loud and obnoxious. I figured I’d just put the NSLU2 and
hard drive next to my wireless router and stuff the whole mess in the
closet. That way no particular PC would have to stay on all the time,
and ideally they could all be turned off while we listened to music
on the stereo.

And that’s where the problem arises: how to get from a file share full
of music to our stereo system?

Plan A was to use the Tivo. It turns out that this has two
showstoppers. First, it requires a server running on a PC; Not
compatible with my “keep the PCs turned off” goal or my “Windows is
only for games” goal. Second, even if we could live with that, the
Tivo server software simply refuses to load any files found on a
network file share. Lame!

Switching to Plan B, I found a bunch
of products to connect 802.11 to your stereo but virtually all of
them require a daemon that runs on a Windows PC. The only “digital
media player” I can find that will read files straight from a file
server is the Roku
HD1000, but it’s huge overkill, and costs too much (especially
since wireless requires an external adapter). From reading reviews, I
also get the impression that nearly all of these “digital media
players” are total crap, and that the required PC software is even
worse. The nicest- and simplest-looking of the
wireless-to-stereo-system converters is of course the AirPort Express, but
it too requires a PC-hosted iTunes server.

So after searching for the last few hours, I’m giving up on finding a
prebuilt appliance that will work. My Plan C thought was to buy a
small fanless Linux machine, an embedded board or something, and
install Rhythmbox on it. But that sounds like a serious pain in the
ass, and I avoided something like MythTV in the first place because I
didn’t want to fool around with custom hardware and software setups.

I had one last thought just now: “wait, the NSLU2 is a small
fanless Linux machine.” And then Google turned up running
an iTunes server on the NSLU2. Which would mean I could use the
AirPort Express. So tomorrow’s plan is to read that article and see if
it looks possible. Still a pain in the ass, but at least no hardware
hacking is involved.

If it works, my total solution will be 1 external hard drive ($179), 1
NSLU2 ($79), 1 AirPort Express ($129) coming in under $400, which is
not that bad. I am making it worse by adding a second external hard
drive for backing up both music and data from the PCs, but that’s
optional.

If Tivo didn’t suck, then I could just go into the Tivo UI on my TV,
enter the file share name, and have the music available; since the
Tivo already uses a wireless adapter. If that had worked I could have
solved the whole problem for $260 and without using the command line
once.

It’s interesting that probably the majority of gadgets I’ve used and
researched in the course of sorting this out are Linux-based.
Including the Tivo, the NSLU2, and many of the digital media players.

(This post was originally found at http://log.ometer.com/2004–11.html#15.2)

I made my program work, and have to admit that it would have taken a
lot longer in any other language (due to either intrinsic or
logistical issues with said languages). Though I am still grumpy about codeset
conversion:

>>> f = open("/tmp/foo1", "w")
>>> fb = open("/tmp/foo2", "wb")
>>> s = u'\N{ARABIC LETTER KHAH}'
>>> f.write(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\u062e' in position 0: ordinal not in range(128)
>>> fb.write(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\u062e' in position 0: ordinal not in range(128)

On another note, interesting to read Nat’s post
on software design. Basically the same contrast drawn in The Inmates
are Running the Asylum, between design-driven and feature-driven
development.

The complexity that comes in is that feature-driven development exists
for real reasons. Two big ones are that people use feature
matrixes to decide what to buy, and customers (and users) really do
get angry in the face of regressions and changes, even small ones.

Balancing this properly is very, very hard. You could explain the
history of GNOME (and probably many other projects) in terms of
trying to get the balance right.

(This post was originally found at http://log.ometer.com/2004–10.html#31)

Fighting with Python. Has anyone else noticed that it’s really hard to
figure out how to use the standard library? There aren’t type
declarations, the API conventions are all over the map, and
the docs are often pretty uninformative.

But the thing that really has me upset is this.
By default, the standard Python “print” statement will 1) convert to
ASCII and 2) throw a fatal exception if the conversion fails. Both 1)
and 2) are broken beyond words. On top of that, apparently the default
encoding will change from ASCII to locale encoding if stdout isatty(),
and not if you say redirect to a file; or something bizarre like
that. No! No! No! Cluebat!

To fix it you have to do this:

sys.stdout = codecs.getwriter("utf-8")(sys.__stdout__)

Which of course is impossible to figure out from the docs, though
Google turned it up.

Before stumbling on this I spent a lot of time trying to convert
_parse_response() in xmlrpclib.py to handle invalid UTF‑8 in the
stream. The API docs sound promising (with
ignore/replace/xmlreplacecharrefs/etc. error handlers), but heck if I
can find the right magic.

(This post was originally found at http://log.ometer.com/2004–10.html#29)