Wandering Thoughts archives

Another advantage of distributed version control systems

Havoc Pennington:

The obvious reply is that most people don't have commit access. But if someone's doing any kind of significant work, I think they should. And for my projects I've essentially always given out access as soon as someone did any kind of largish patch or frequency of patches.

My reply to Havoc is 'what about before then?'

The advantage of distributed version control systems is that they empower people to use version control right from the very start of working on your program, even if and when they are making a trivial patch. They are never left out in the cold, either without version control or having to build it themselves on top of whatever VCS your project uses.

(I can make an argument that version control is especially important for people just starting out with a project. Their uncertainty about the inner workings of the codebase means that they are the most likely people to make mis-steps and wrong turns, and thus to want to be able to roll back to when their change in progress was actually working.)

Given that version control is now one of our best practices and clearly the right thing to do, why do people still feel this way, that some people can get by without it? (Or just not feel that it's essential enough for everyone to use it.)

Part of the problem could be that people feel that many of the version control systems are actually not great in the small, so people feel that version control is only really interesting or worth it once you start doing a lot of work on the code (or even that it's a kind of hair shirt that you suffer through for the good of all).

(I don't have enough experience to hold a well informed opinion on this, but stuff so far points me towards 'yes'.)

Another factor is how the ubiquitous CVS/SVN twins make it easy to carry an uncommitted change in a checked out tree, doing automatic merges and so on for you as the master repository updates. You don't get any version history et al for your changes, but at least the pain level is low (I've been carrying private Firefox patches in a checked out CVS tree for literally years without problems).

(Of course there's other advantages to distributed version control systems. Bryan O'Sullivan has several good points too.)

Google and YouTube

A common meme among geeks is that Google's purchase of YouTube for $1.6 billion shows that Google has tipped over into being a profligate, dot-com style company with more money than common sense that's making stupid acquisitions. I disagree:

• it's not as if Google wasn't already active in the area; Google Video is living (for the moment) proof otherwise. Google thought the area was interesting well before YouTube was a runaway success.
• given that this was an all-stock deal, it's not as if Google is spending real money. When your stock is riding high is exactly the time for deals like this.

But this is still a lot of money to spend for a competitor in a field where no one is (yet) making any money.

Google's proclaimed goal is to organize the world's information. Not all of that information is in textual forms, and so if Google is serious they need to do something with the non-text information too. Google has already made some moves in this direction, like Google Images.

A fair amount of the information is in video. Understanding video is a hard problem, but in setting up Google Video and now in buying YouTube, Google has arranged a large supply of both video to work on and people to tell them if they're getting useful results.

(The video would probably be hard to get otherwise. Most video content is hard to crawl for various reasons, including its size (which makes people antsy about automated retrieval) and, yes, copyright issues.)

This line of thought leads inevitable to a 'Google Audio'. However, I suspect that it's impossible, since the music industry has pitbull lawyers and a hair trigger. (Wild speculation: MySpace would be a great place to work on the problem, since they have a lot of bands putting up their own music plus a natural target market for an 'if you enjoyed this, you might like ...' service.)

Why cursors blink

Cursors on 'dumb' serial terminals blink because their location usually is the most important spot on the screen; it was where your typing would go. Blinking made sure that you weren't going to lose track of it.

Cursors in terminal emulators blink because people haven't bothered to rethink this in the face of multiple windows. (I'm not sure that they've thought about it deeper than 'dumb terminal cursors blink, let's imitate them'.)

That's a strong statement. Let me try to justify it.

In GUI text controls, the active insertion point blinks (slowly) to keep it from being mistaken for a pipe character (according to the Apple Human Interface Guidelines) and to attract your attention to where your typing will go. However, the standard insertion point is a relatively hard to see vertical bar, usually floating in a sea of controls.

By contrast, terminal emulator cursors are usually square boxes, in a much more obvious setting (and their blinking is much, much more visible and thus much more irritating). Such a cursor is not going to be confused for any character normally found in nature (and if you are going to worry about reverse video spaces, you might as well worry about blinking reverse video spaces too).

A large blinking thing is a strong attention attractor, because people are reflexively attracted to apparent motion and change. However, in a multi-window environment you can't assume that you're the most important thing and that the user's attention should be dragged to you all the time, even if you currently have the mouse focus.

(As you can tell, this is one of my pet peeves.)

A reason to read blogs in reverse chronological order

I've finally found a good use for reading blogs in the reverse chronological order that everyone (even syndication feed readers) defaults to.

For various reasons, I am way behind in reading the syndication feeds that I (nominally) follow. In this situation, reverse chronological order turns out to be great for cherry-picking the current news and getting a quick sense of any important recent developments.

(It's not that the older entries are valueless, but since they've waited a while already they can likely wait a bit more.)

On a side note, being overloaded with unread entries magnifies all of the little irritations in feeds, including how Usenet readers solved all of these problems ten years ago.

(Partial feeds are especially irritating, mostly because they break the flow of skimming by forcing me to pause and open up a browser and wait for the entry to load and find the entry text in their design and etc. By contrast, hitting spacebar to page down has by now reached the status of a spinal reflex.)

Of course, probably the most sensible way to deal with the whole problem is to start unsubscribing from various aggregators and the like (especially now that one of them has picked up a vendor blog that seems to be basically marketing PR). But I'm bad at doing things like that, for reasons that don't fit in the margin of this entry.

(A big bang solution gets more and more tempting, though; if not unsubscribing, I could just do 'mark all read' on most of the feeds. Especially the ones I'm only reading because they come as default feeds with liferea.)

Thoughts on machine identity

One of the things my earlier entry got me thinking about was how differently people can see the issue of machine identity. Or, to make it more concrete, when do you give something a new name (even if the name is only in your head, not related to the OS-level hostname)?

(I could try to justify it by talking about how it shows something about how people think about their computers, but really it's just the kind of thing that satisfies my wandering curiosity, like discussions of computer naming schemes and pictures of people's desktops.)

One view is the physical one: a machine is its hardware, and new hardware means a new name. This is especially appealing for things like laptops, where a lot of the personality of the machine is in things like how the keyboard feels or the screen looks. It's also things like licensing software tend to think about it, famously including Microsoft's Windows activation stuff.

(Like all views of identity, things get fuzzy around the edges; for example, how many parts can you upgrade and replace (at once or spread out over time) before it's a different machine?)

I tend to a more abstract view of machine identity; as best I can describe it, machine identity is more or less tied to continuity of data and capabilities (somewhat in combination with the machine's role), not directly to hardware. As long as the hardware and the OS retain more or less the same capabilities, especially the ability to run my current software, it is the same machine.

This gets fuzzy around the edges for things like my current transition to Fedora Core 5 and the x86_64 architecture; a number of programs are falling off and my environment is changing a fair bit, although I have continuity of data and of a lot of programs. I'm not sure I still think of this as 'the same machine', and I certainly find myself wishing I could leave the old machine up with a reference copy of the old environment.

(I complicate my life by mostly assigning hostnames to roles instead of machine identities; for example, my main office machine is called 'hawkwind', regardless of what machine it is at the time. I do this because I tend to like my names too much to give them up just because I happen to have replaced the machine.)

The longevity of old hardware

In a bittersweet moment a week and a bit ago, I finally decommissioned my SGI R5K Indy. We got the machine in the summer of 1996, so it has been provided faithful, trouble-free service for just over ten years. That's impressive longevity, especially for the hard drives.

It was a pretty good machine when new, basically the top of the line of SGI's basic workstations; as a peon sysadmin, I was lucky to get it. I spent several years using it as my primary workstation and enjoying the various nifty SGI bits (including its video camera) before we moved from SGI servers to a PC and Linux environment; after that it lingered on in the background, still doing various bits and pieces.

(Even today, looking at it makes me feel nostalgic, a feeling which is helped by the distinctive case design and the SGI marbling on the monitor; SGI machines were never generic beige boxes. Even if the R5K Indy was not the best thing on the block, SGI worked hard to make it feel cool and sexy. A part of me still regrets that SGI ultimately lost to the PC juggernaut; sure, I get a lot more performance, but it lacks the pizzazz and personality.)

Part of the bittersweetness is that the Indy is probably the last of my machines that will be in service for such a long time. Not only am I letting go of a machine that's been running for ten years, I'm letting go of the idea of having hardware that I run for ten years. The world is a different place now; major OS and architecture transitions seem unlikely, disk capacity keeps growing rapidly, and my current machines instead have a kind of serial immortality, where the important thing is the data not the particular hardware it lives on at the moment.

One of the semi-impressive things (or alarming, depending on your perspective) is that the Indy has been running the same operating system for those ten years. I installed Irix 6.2 on it back in 1996, and it has run it ever since; we never upgraded.

Sidebar: the Indy's hardware configuration

The machine has a 150 MHz R5000 MIPS CPU with two 32K L1 caches (I and D), a shared 512K L2 cache (still a common size), and 64 MB memory. I think we bought it with a 1 GB internal SCSI disk; in its current configuration, it has a Micropolis 4743NS (4 GB) and a Seagate ST32430N (2 GB), with one of them in an external enclosure (probably the Seagate). Back in the days, this was a lot of disk space.

(Even when new, there were bits that were dowdy compared to the PCs of the day; 8-bit graphics (even with multiple hardware colormaps) were clearly on the way out, and the serial port speeds were nothing to write home about.)