Coruscating Lucubrations

Mozilla's Rust Language

2012-01-26T05:31:00.000-08:00

Mozilla released version 0.1 of it's programming language offering called Rust. There are a number of things about Rust which are nice; it uses LLVM, which means it gets tail-call-optimization, which Go doesn't have; it has isolated, lightweight tasks, and channels much like Go; I've come across discussions about Erlang-style supervisors, which is encouraging; it has a Ruby-like syntax for closures; it has some limited type inferrence (very similar in scope to what Go can do); and it has pattern matching a-la OCaml, which Go doesn't. On top of all of this, the executables it produces for small applications are two orders of magnitude smaller than those produced by Go (Go's "Hello World" is 1.2MB; Rust's is 14KB). I don't have any performance comparisons yet, but I wouldn't be surprised if Rust was (currently) faster than Go. Go's compiler is faster, the value of which increases proportional to the size of the project on which you're working.

Despite all of this, I haven't switched over to Rust yet; it's a touchy-feel-ey reason, more than anything concrete. Go feels more mature, despite Rust being older. The Go library documentation is much better, and the developer tools feel more complete. And it's just easier to code in; Rust is a bit more wordy in tiny little ways. For example, to do something multithreaded, in Rust you'll end up doing something like this:

  let in = comm::port::int();
  let out = comm::chan::int(in);
  task::spawn { ||
    some_func(out);
  }
  let res = comm::recv(in);

ports are for writing to, and chans are for reading from, and never the twain shall meet. In Go, the equivalent would be:

  var inout = make(chan int)
  go some_func(inout)
  res := <-inout

There in't a huge difference, but the Rust version is more wordy, and not any more clear. I just get a tiny, nagging feeling that, over time, the verbosity of Rust would start to wear. Especially with the whole port/chan thing, which smells an awful lot like boiler-plate.

The other thing is that I keep having trouble writing threaded apps in Rust. At some point in every attempt, something or other blocks me and I can't get around it. Most recently, it had to do with the fact that you can't send a port to a function if that function is in another task. This means that you can't share a port between tasks. You can't do this:

   let in = comm::port::int();
   task::spawn { || comm::recv(in); }

The Rust compiler raises this as an error (unsendable value). I will readily admit that this is almost certainly a failure on my part to understand the idiomatic idiosyncrasies of Rust, and that there may be a way to accomplish this, but my question remains: if you can't share ports between tasks, then how do you implement a single-producer / multiple-consumer multi-threaded application? I didn't find any code in any of the examples in src/test (in the Rust repository) which demonstrated something like this, and when I asked on #rust IRC, my question was met with silence.

What it all boils down to is that, at least for me, Rust is being a PITA to get started with, whereas Go wasn't. And in some ways, they're really very similar languages; they both have the "arg TYPE" ordering of type declarations; they both have "type SOMETHING {" structure for records; they have similar threading models and channel communications... but Google, in my mind, at least, has been much more successful at making Go accessible than Mozilla has with Rust. So for now, I'm going to continue working with Go, and keep an eye on developments in Rust.

P.S., I can't properly annotate the Rust examples because blogger.com doesn't handle less-than / greater-than signs.

Droid Incredible 2

2011-12-08T18:29:00.001-08:00

I have a new company phone; I got it yesterday, and have been spending the usual amount of time getting it set up and playing with it. I'm pleasantly surprised by the battery life, actually; at the time of this writing, the phone has been on for 31 hours and has about 40% battery left; 39% has been used by the display. I don't know how much time I've spent in calls, but I've made or received 12 of them in that 31 hours. Not too shabby.

The cult of technology personality

2011-10-27T03:09:00.000-07:00

Recently, I've come to the conclusion that products are irrelevant; popularity is all in branding and marketing. Us developers (of hardware and software) like to kid ourselves into thinking that we're the ones who do the "real work,"but really, it's the sales and marketing people who are the backbone. Apple didn't "invent" the smartphone, any more than they invented the MP3 player (they were three years late on that), or the laptop, or the slate PC (again,late by several years), or any of the other stuff they've been successful with in the past ten years.. They've just been able to corner the "sexy" market, throughgood advertising and branding. I think that since Jobs returned to thecompany, they also payed more attention to quality and product polish, and werewilling to sacrifice volume in the increased costs that often incurred; he had the same attention to detail at NeXT, although he failed to identify the right market for that platform. But Ireally think what makes a successful product is the cult of personality.

Other examples:

Microsoft. There is almost always been a better competing product towhatever Microsoft is selling, but Microsoft managed to capture the Business sector with its early and intimate association with IBM. Even OS/2, an arguably better OS, couldn't wrestle that crown away, and that's because they didn't have Bill Gates, not because it was a technically inferior product.
Linux. Minix predates Linux, and had the potential to be as successful as Linux, and can be argued to have a better architecture, but Tanenbaum haddifferent priorities and isn't, I dare suggest, the personality that Linus is. Or, if you don't like microkernels, BSD. Same thing: they don't lack technology, they lack Linus.
Java. There are many at least equivalent languages out there, even if you restrict yourself to the OO space, but none of them had Sun behindit. Sun pushed Java aggressively. I'm not going to credit McNeally or Goslingdirectly for that; I don't think there was a personality behind that one, justaggressive and persistent marketing.

History is littered with the detritus of better products that lost to inferior products, simply because of better marketing.

Universal truths

2011-10-06T17:15:00.000-07:00

The fact that channel communications (whatever their implementation details) take much, much longer than function calls seems to be a constant truth no matter what the programming language. I don't have the benchmarks for Erlang offhand, but here are ones that I just recently ran for Go:

main.BenchmarkChannel-2     500000              6106 ns/op
main.BenchmarkFunction-2        100000000               10.2 ns/op
main.BenchmarkAnonymous-2       100000000               11.5 ns/op

Here's the source code in case you want to pick holes in my benchmark:

package main

import "testing"

func BenchmarkChannel(b *testing.B) {
        c := make(chan int, 1000)
        accum := 0
        go func() { for { accum += <-c } }()
        for i := 0; i < b.N; i++ {
                c <- i
        }
}

func BenchmarkFunction(b *testing.B) {
        accum := 0
        for i := 0; i < b.N; i++ {
                handle(i, &accum)
        }
}

func handle(v int, accum *int) {
        *accum += v
}

func BenchmarkAnonymous(b *testing.B) {
        accum := 0
        f := func(i int) { accum += i }
        for i := 0; i < b.N; i++ {
                f(i)
        }
}

This was run with:

gotest -run -cpu=2 -bench='.*'

Changing GOMAXPROCS didn't make any difference. I was running it on a Core 2 Duo. It's not hugely surprising, but still. It makes me wonder how the ratio of performance compares between languages.

Just a rant

2011-09-21T05:22:00.000-07:00

I need to get this out of my system. It's probably better if you just go ahead and skip this rant; there's nothing constructive in it.

Windows
Windows sucks. There's really nothing more to say about it; it's a horrible operating system, and I don't know why anybody -- especially anybody in a management position -- would think that it's suitable for running a business on. It's buggy, slow, bloated, and obtuse. It's so bad at being a server, I don't even know where to begin criticizing it. And as bad as it sucks being a server, it really sucks at being a desktop computer, too. There really is nothing redeeming about it. Using it is a painful chore; it's my personal belief that anybody who thinks otherwise has simply been conditioned to believe so. It's like, if you hit somebody frequently and often enough, they get used to being beaten. That's Windows. It is like being beaten by an entire company.

DellDell hardware sucks. I have both a (personal) two year old MacBook Pro and a one-year-old (company) Dell Latitude E6410. If I put the Dell to sleep (not hibernate), the battery gives out within 48 hours. If I put the Mac to sleep, the battery gives out after... well, I don't know how long, because I've never had the battery give out. It lasts at least a week, though; I went backpacking once and was gone for about a week, and the Mac still woke up after I got back. Granted, the Dell does have more memory than the Mac (8GB vs 4GB), and that's going to affect the battery drain. That's still pretty pathetic. And the battery on the Mac lasts a lot longer; I can get a full 6 hours out of it, with constant use (if not heavy load)... the Dell gives out in about 3. The CPUs in both have two cores each; Windows claims the Dell's CPU is running at 2.4GHz, and OSX claims it's running at 2.5GHz. The Mac's display is larger (15" vs. 14"), and that's a big battery drain. Of course, the Dell is running Windows, so you have suckage upon suckage. Windows is probably doing more to kill the battery life than the Dell hardware. I've heard that the Mac will hibernate itself while it is asleep if it detects that the battery is going to give out. Again, I wouldn't know, because I've never had the battery drain entirely while the Mac was asleep, and because OSX does so much of this smart stuff behind the scenes.

If I close the lid on my Mac, it goes to sleep. If I open the lid, it wakes up. All of the Dells in our company have this feature turned off because if you sleep a Windows laptop by closing the lid, odds are good that the laptop will never wake up, or won't be able to find a wireless connection after it resumes, or something. That's why you see people walking the halls with their laptop lids only partially closed. Every time you see that, just remember: Windows sucks.

All of the managers above a certain level at my company get Macs. All of the peons get Dells. Honestly, the Macs aren't much more expensive. A new 15" Pro starts at $1800 for a quad-core 2GHz 4GB RAM 500GB HD; a new 14" E6410 dual-core 2.8GHz 4GB RAM 380GB HD starts at $1400. Not much difference in price there -- and you're getting better, newer hardware in the Mac.

It baffles me why people are still running their businesses on Windows, and on Dell hardware.

Incremental backups with btrfs

2011-09-07T05:54:00.000-07:00

btrfs is teh win. No, seriously. It's not the only file system that can do this, but it's the first one I've had installed, and it's beautiful, man.

I got myself a little 2TB external USB 3.0 hard drive ($99! Past Sean, be very jealous) and wrote a backup script; my first version had all of this complex Towers of Hanoi rotation scheme, but then I realized I didn't need any of it if I used btrfs's snapshots. Now, my backup script consists mainly of:

sg_start --start /dev/sdh   # Tell the drive to spin up

mount /dev/sdh1 /mnt/backups

btrfsctl -s /mnt/backups/backup-$todays_date \

            /mnt/backups/backup-$yesterdays_date

rsync -va --numeric-ids --delete-before --ignore-errors \

      --partial --inplace $backup_paths \

      /mnt/backups/backup-$todays_date

sync

umount /mnt/backups

sg_start --stop /dev/sdh

It does a little more than that (error checking, logging, etc), but not much more.  After the first backup, the disk usage was 15GB; ten days later, I have ten incremental backups, and it's still 15GB.

Of course, the problem with this is that snapshots are, essentially, COW hard links; this means that if there's a corruption on the disk for a file, it'll affect all child snapshots.  My mitigation is to add another backup disk: they're only $99 (cripes, I can't get over that price), and each backup is taking about 8 minutes to run (most of that time is spent in rsync, detecting changes) -- I can easily affordable to run two backups a night.  It's not as safe as a rotation backup, but it's safe enough.

tmux magic

2011-09-01T11:11:00.000-07:00

I recently switched from GNU screen to tmux, so I'm discovering all of these awesome little features. This morning, I found out (accidentally) that you can remotely script sessions, and here's how it came about:

I added a new back-up disk and back-up scheme (more on that later), and decided to do a little cleaning while I was at it. I've got 10 years of digital photography in one drive, much of which isn't very well organized. There's a lot of duplication resulting from copying and moving things over the years, so I ran fdupes on that directory and it came back with more than 1,000 duplicate sets. These files are fairly large, and there are a few home videos mixed in there which are even larger, and so fdupes itself took a while to run; when it was done, I had found myself in a situation where I didn't want to press "1" a thousand times, but I also didn't want to re-run fdupes just to pipe yes n to it. Luckily, I remembered coming across a send-key command in the tmux man page, and that proved to be the solution.

It turns out that you can send any tmux command to any tmux session using the the command line, and this allows you to script any interaction you might want to have with tmux or any process that is running within tmux. You can take a (text) snapshot of a window buffer, and you can also send input events to any window. In my particular case, it ended up being the little shell script:

for x in `seq 1 1000`; do
tmux send-key -t 0:3 1 C-m
done

The tmux command says, "send, to session #0, window #3, the key '1' followed by Ctrl-M". This is really powerful; you can completely script any tmux session, including (for example) a start-up tmux script that runs processes, creates windows, and splits windows into panes.

tmux still lacks the ability to attach different clients to different windows within a session (or, if it allows that, I haven't yet discovered how to do it), which makes running tmux in an environment such as XMonad a little less pleasant than screen; however, this ability to do emergency, post-hoc scripting is a killer feature, and has sold me on tmux.

RML: Readable Markup Language

2011-07-05T20:13:00.000-07:00

In answer to my own post, I spent last weekend implementing my own markup language. You can find the results here (and the source here). FWIW. It's version 1.0, which means it works, but it doesn't have all of the features I want. A summary can be found here. I'm pretty pleased with it so far.

Never satisfied

2011-06-29T05:14:00.000-07:00

Every once in a while I find myself wasting a couple of hours re-trolling through the Wikipedia entry for lightweight markup languages, searching for the perfect markup system. They are all deficient in some way, and it's becoming increasingly evident that I'm either going to have to pick the least deficient one and write additional software for transforming it (ugh), or come up with my own (yeauck!).

As a preface, I'll just say that TeX is a non-starter; any tool that requires TeX (or LaTeX, or any derivation thereof) is not an option. I've said it before: all TeX packages require about a gigabyte of disk space, and TeX doesn't do anything significantly better than what Lout does in 11MB. TeX is bloated, and I simply don't want to have anything to do with it; it was fine when I was in college, when the only alternative was MS Word, but there are better alternatives out there, now.

RestructuredText has a huge amount of software for converting it into HTML, DocBook, PDF, Slidy, S5, and others, and it has very few dependencies. In particular, rst2pdf can generate PDF using only a small number of Python libraries. It has an awesome table syntax. It is easily extended to support dot diagrams, aafigure, and a host of other embedded images. You can use SVG images in an RST document, and both rst2pdf and rst2html will do the right thing. However, the markup is unintuitive and verbose, and sometimes awkward, and it lacks primitive support for basic things like underscore, superscript, subscript, and strike-through. While you can do these mark-ups with roles, they all require verbose syntax and both rst2pdf and rst2html don't handle whitespace in roles correctly (e.g., :strike:`- `)
Asciidoc has better syntax, although it too has no primitive support for underscore and strike-out. It's main failing is that writing asciidoc is a lot like programming: the conversion tools are extremely strict about syntax, and will utterly fail on any minimal mistake (whereas the RST tools will normally emit a warning and continue on, trying their best). Asciidoc converts everything through DocBook, which isn't itself so bad, but getting something into PDF requires either LaTeX (recommended) or FOP, and the FOP stylesheet needs tweaking to get it to work correctly. Altogether, Asciidoc is too fussy.
Markdown has OK syntax, although they stopped too short on the really useful heading syntax (only two levels with the underline style), and it requires extensions to get anything like table and fenced block syntax. Most damning, there's no way to convert Markdown to PDF without going through LaTeX.
Creole and Textile have dumb heading syntax -- they're pretty obviously designed to make editing wiki pages easier, not to produce plain ASCII documents that can also be converted into something else. Creole also has ugly list syntax. Textile's heading and blockquote markup is useless for reading the documents in plain-text. In particular, Textile's inline markup is almost perfect; unfortunately, the only conversion tool is to HTML, and the heading and blockquote markup really is unusable.

_emphasis_*strong*??citation??-deleted text-+inserted text+^superscript^~subscript~%span%

< right> left= center<> justify

ADM(Acronym Definition Markup)

Setext has interesting markup, but is pretty spartan. No table support, strike-through, image embedding; and there are two converters: one for converting to HTML, and one for converting to LaTeX. So, really only one usable (IMO) converter. It might be a good basis for extension into a more robust markup.
The Wikipedia page on Texy claims that it's the "most complex" markup language, but it doesn't support strike-out or underline. Otherwise, its syntax is quite interesting, as it its table support. However, there's no software for converting to either PDF or Slidy. The markup for adding style to text is tidy: .{color:red}
txt2tags, like RST, can be converted to a wide variety of output, and the syntax is interesting. It has support for underscore and strike-out, but not super or subscript, and the table syntax is not as interesting as Texy's. Actually, as I re-review it, it may be the most interesting of the bunch; I'm a bit concerned about the implied dependency on tabs, which you can't use in text fields on web pages, which would make it inappropriate for wiki. I don't care for the heading markup, but I think I could live with that.
Not mentioned on the Wikipedia entry is AFT (Almost Free Text), which is one of the original markup languages, and has been around for years. The source documents don't read quite as cleanly as other markups; it's pretty obvious that you're dealing with a markup language. There's no support for strike-out, and it requires LaTeX to generate PDF.

I just want something that reads like something you'd have composed in an email prior to HTML multipart-mime messages; simple syntax covering the basic cases (i.e., if I could do it with an old electric typewriter, the markup should be able to handle it as well. The whole purpose of the underscore key was to underscore words; it baffles me how a modern mark-up language could leave that out.). A rich, but easy, table syntax is a bonus, and being able to create PDF without installing a gigabyte of software (LaTeX) a must. HTML is required, but they all generate HTML; Slidy output is more or less required, too. Additional points are given to support for domain-specific markup, like aafigure (an awesome package for very simple diagrams) and dot -- an easy plug-in for passing blocks of text to an external program, and then being able to embed that output (which will probably be SVG, or some bit image format like PNG) into the resulting document, wins special mention.

No existing markup package does everything that I want, though. Dare I implement a new one?

Now we get to the annoying aspects of Go

2011-06-27T06:12:00.000-07:00

I've spent another ten hours or so writing extensive functional tests for my code, and fixing bugs, so I have some further thoughts about Go.

POLA

gotest continues to be easy to use and is versatile, even if you do have to implement a bunch of basic functionality yourself (there are no convenient "assert" functions, there's no setup or teardown functionality, and nothing like TestNG's DataProvider mechanism). Even functional testing of a server process is easier than in other languages, although I think most of that is again due to Go helping me separate my code into modules. I also found my first non-contrived reason to use goroutines for the first time. I really like goroutines, but that's probably because I really like Erlang's process paradigm.

What really bugs me are the inconsistencies. Go is self-consistent, which seems to be the Go-team's answer to any criticism of consistency in the language, which is itself annoying, but it isn't consistent in the Principle of Least Astonishment way. In fact, Go is really pretty bad when it comes to POLA. The thing that kept biting me this weekend -- and, admittedly, it was my fault resulting from a lack of experience with Go -- was the following case:

package main
type Foo map[string]string
type Bar struct {
thingOne string
thingTwo int
}
func main() {
x := new(Foo)
y := new(Bar)
(*y).thingOne = "hello"
(*y).thingTwo = 1
(*x)["x"] = "goodbye"
(*x)["y"] = "world"
}

Go requires that you know details about the implementation of the types defined above. x is not really a new object; it's a pointer to something that doesn't exist, while y is an actually allocated object. If you try to use x, you'll get a runtime fault and your program will crash. Instead, you have to do this:

x = make(Foo)

However, if you try to do the same thing with Bar:

y = make(Bar)

you get a compiler error. This bothers me, because it's one of those submarine bugs -- if you make a mistake in how you allocate an instance, you won't find out unless your tests actually hit that code. I had hoped we'd have gotten away from that by now. I'd rather Go just made make() work on structures, and then you could eschew new() entirely (unless you really needed it for a specific purpose), and this type of error would become exceedingly rare. It's a gotcha; it's an inconsistency in the syntax.

I've mentioned before that I like catching errors as early in the development process as possible, and this is the reason why I prefer strongly typed languages. The sort of problem that I've just mentioned weakens Go a bit in this area; for comparison, Haskell eliminates this sort of submarine bug -- if you can get your program to compile, it will run, and if it fails, it'll be entirely due to a logical, algorithmic error, not a type-usage one. There's no compiler yet that will check your logic for you, so Haskell is pretty close to perfect, in that respect.

Before anybody comments on my syntax use above, I'll point out that the dereferencing of the y pointer is unnecessary: Go does that for you. I did it for illustration purposes.

Pointers

It's been a long time since I've had to use pointers, and during my development and testing I was floundering around trying to determine when and when not to use them. At one point, I was getting annoyed and was thinking that this was another case of POLA in Go, but it turns out I didn't have to worry about it. All you have to do is to ensure that any function that needs to change a structure (or variable) gets passed a pointer, and Go happily figures out the rest. Another example:

func (b *Bar) foo() { b.thing = 1 }
func (b Bar) write() string { return fmt.Sprint(b) }
func tralaTrala() {
var b Bar
b.foo()
fmt.Println(b.write())

a := new(Bar)
a.foo()
fmt.Println(a.write())
}

tralaTrala() does not need to know whether a and b are pointers or not; Go will "do the right thing" here, and the syntax is the same despite the fact that the types of the two variables are different (one's a pointer, the other isn't). The only real issue is that, when writing a function, the programmer does need to know whether foo() and write() modify the state of the Bar they belong to, because s/he needs to know whether to request a pointer or not:

func doSomething( b Bar ) {
b.foo()
}

will probably end up being a runtime logic error, and Go does nothing to help you with these. This makes me think that the safest way to use Go is to pretend that it's entirely functional, and write all of your code that way, until you need to optimize it. This would mean that the signature for foo() would be:

foo() Bar

and it'd be used like this:

func doSomething( b Bar ) Bar {
rv := b.foo()
return rv
}

This is another thing that I'm not entirely happy about, but it may be a reasonable trade-off to provide a powerful optimization path.

More Golang adventures

2011-06-25T06:37:00.000-07:00

I recently wrote a little application called ConfigServer (although the project will probably be renamed). It is intended to be a tool to assist release managers and software deployments by providing a central server to hold configurations, but also allow configurations to be version controlled. ConfigServer provides some inheritance capability, the idea being that you can have a Cluster configuration, a Server configuration that inherits properties from the Cluster, and an Application configuration that inherits from the Server -- ConfigServer doesn't care about the schema, actually, but that's an implementation detail.

The original version of this application was written in Ruby, a language that I was once extremely well-versed in, but which I haven't used for anything but one-off command-line scripts in a few years. It took me about 6 hours to write the thing.

Out of curiosity, and since the project was so small, I decided to re-implement it in Go. When I started the rewrite, it was the second time I'd looked at Go syntax; the first was to fix a small benchmark program that was comparing Go to Vala (commentary on that is here), so it really was the first time I'd written any Go; I was utterly unfamiliar with the packages. The Go version took me about 20 hours. That time includes unit tests and a couple of refactorings to improve segregation of responsibility; I guesstimate that if I performed the same refactoring and writing unit tests for the Ruby code, I could probably spend another 6-10 hours; on the one hand, I know the shape of the modules/packages, but on the other hand, writing unit tests always takes a lot of time.

Cloc tells us this:

Language	files	blank	comment	code
Go	7	104	43	482
Ruby	1	59	55	326

This excludes unit tests. So here are my observations:

I'm frankly amazed that the Go LOC is so close to the Ruby LOC (33% larger). If I refactored the Ruby code to be more well-structured and encapsulated (and unit-testable), that LOC delta would shrink even more.
The Ruby program is a single, executable-and-library file. This was intentional. I was able to break up the Go code into more files because the end artifact would also be a single executable.
The Go compiler is wicked, stupid fast. gomake is nice, in that it uses standard Makefiles but provides includes to greatly simplify the Makefiles.
The Go unit test package is anemic, providing only the bare minimum of functionality.
Go has such potential for mixing in, but the language spec disallows it (you can only define functions on structures that are within your own package).
Even if I were as knowledgeable about Go as I am about Ruby, I'd still have been able to whip the Ruby version out faster. On the other hand, the Go version is much safer, and I trust that program a lot more -- it is, after all, type-checked. I guarantee that no matter how much I look at the Ruby code, if it runs for any length of time I'll eventually encounter a typing error because of a bug in the code.
Go has an amazingly useful set of built-in libraries, without being package and class bloated (like, say, Java). Although, the crypto package is curiously huge.
The Go package documentation, FTW!
Doing system exec stuff is easier in Ruby, but not by a lot.

All in all, Go surprises me; it's concise, easy, encourages good separation of concerns, is easy to read, and much more functional in feel than you'd expect from looking at the tutorial. At the same time, it has some unfortunate quirks: it's (currently) relatively slow for a compiled language, and builds large executables; some language constructs are just baffling in their constraints, such as range only being applicable to a small set of built-ins, rather than working on some well-defined interface; tail-call optimization is extremely limited, which is such a shame for a language as close to being a functional language as Go is; and the lack of ability to mix in to extra-package types is limiting.

To the first point in my list of Go quirks, I have no doubt that this will change rapidly, and Go will catch up; it's a very young language, after all. As to the last point, the explanation put forth by the Go developers is, frankly, weak. It's the same argument Gosling made about not supporting multiple inheritance in Java, which basically boils down to "programmers are stupid, and this feature will confuse them." I don't buy it; I'd rather have extra-package mix-ins with limitations based on technical merit than none at all.

I've learned that I vastly prefer the cost of slower development time to gain reliability and safety, as long as the cost isn't too high. Haskell is even safer, but it pushes the boundaries of how much pain I'm willing to endure trying to get code to pass through the type checker.

Right now, I'm thinking Go's a keeper. It is more productive than C, more reliable than Ruby, easier than Haskell, is superior to Erlang in a whole host of ways I won't enumerate here (although, I do like the features that the OTP brings to the table, many of which are "killer" features unavailable in any other language, which keeps Erlang highly relevant), and is far better than Java in terms of simplicity, syntax, typing, threading, native compilation, and memory use. Each of these languages surpasses Go in their own ways, but I believe that Google has successfully found that sweet spot in a practical language that minimizes the annoying attributes and boiler-plate, and provides strong typing, resulting in a highly "writeable" language that compiles to native executables. We'll see how I feel with a few gross more hours under my belt.

Restructuredtext vs Asciidoc

2011-06-17T15:25:00.000-07:00

This will be brief: RST beats Asciidoc. I actually prefer Asciidoc's syntax; it uses markup inherited from the markup people have been using in emails for more than a dozen years, while RST is hacky, obtuse, and contrived. I never will understand why people ignore defacto, organic standards in favor of inventing new standards which are worse. In any case, Asciidoc's syntax is better -- but the parse rules are just too involved. It can be difficult to construct a document from scratch; the parser is extremely picky, and there are too many dependencies on unstable libraries. This is supposed to be human-composable, human-readable text; the syntax rules should be more relaxed, and the parser more forgiving. So, for now, I'm sticking with RST, even though it has serious flaws. [1] It does have unparalleled table syntax, although unfortunately without any support for text alignment in cells.

[1] Such as:

No easy syntax for underscore, strike-through, superscript, or subscript
Bizarre, unintuitive choices for markup, like *xyz* for italics and **xyz** for bold
Unnecessarily verbose syntax for footnotes
No mechanism for continuing lines in lists after inline blocks

JVM hate

2011-06-10T06:58:00.000-07:00

I came across this paper, published by Google, comparing benchmarks in Scala, C++, Java, and Go. Scala comes out on top (well, under C++) in performance, by a decent margin. This surprised me a bit, but makes me happy -- Scala is a functional language, and I do think functional languages are the (medium) future of software development. My main beef with Scala is the JVM.

There are (in my mind) several problems with the JVM. First, Java is now owned by Oracle, who's begun suing companies using Java technology. This isn't like Sun's lawsuit against Microsoft way-back-when, which was about maintaining compatibility in the JVMs so as not to fragment Java; no, this time, it's about money: Oracle wants a piece of the Android pie. The lawsuit makes good business sense for Oracle, but it puts an indelible stain on Java and the JVM, and one that I can't abide. Now that Oracle has proven its willingness to go after companies using Java technology for financial gain, no company is safe, and every company should seriously consider whether using Java (or a JVM) is worth the financial risk.

Second, the JVM is a bloated hog. Yes, it is fast. It's amazingly fast. The scientists at Sun have done a great job with JIT optimizations, bringing Java performance up into the top tier of languages (grain of salt, but real-world reports of Java performance are pretty consistent). However, it's a memory hog, and it can be difficult to tune the garbage collection so that unexpected spikes don't occur, or applications don't crash with out-of-memory exceptions, and so on. Its start-up time is also a problem, and there's on old adage of "write once, debug everywhere" that's still relevant.

I'm not a big VM fan in general, any more. Ruby cured me of that, although I've been writing Java code long enough to have had my share of problems with the JVM, too (not recently; it has been pretty stable for years). Haskell programs that I wrote 7 years ago still compile and run, and unless there's a major API change in libc or libm, compiled programs continue to run reliably as well. This means that I can write a service, get it working the way I want, run it, and forget about it. It just runs forever, or until it crashes and gets restarted. Ruby applications, on the other hand, crash almost every time the Ruby VM gets upgraded, and this (IME) happens quite often, and unfortunately usually as part of a larger, system-wide upgrade. So the admin does a 'do-release-upgrade', the Ruby VM gets upgraded, and suddenly some Ruby service that I wrote a couple of years ago stops (silently) working. This doesn't happen with my Haskell apps; it doesn't happen to most natively compiled apps (or it happens much more rarely). It's a matter of trust. I trust natively compiled code more than VM code.

There's also a matter of ability to distribute code. With any VM (including the JVM), you have to be careful of the versions. At one company I previously worked at, we specified support for specific JVM builds, and upgrading the JVM version was fairly expensive, as QA had to run through much more comprehensive tests when the JVM changed. Because or product included several apps being developed by several different teams, we had to upgrade JVM versions in lock-step. And if you're writing an application that's intended to run on several nodes in a network, you have to make sure that your VMs are all in sync, version-wise. Erlang was especially bad about this.

Finally, VMs add another layer of failure. Not only can your hardware, OS, and libraries fail, but now you've got a VM that can contain errors and fail. Higher levels also seem to be more prone to bugs and failures, probably due to the increased complexity of the software. And the JVM is very complex.

This is why languages like Go and Haskell interest me. They're faster than (most) VM code, they're higher level than C, and they compile to native binaries and so don't have a dependency on a VM. I can compile a Haskell or Go program on Ubuntu Linux and scp it over to a RHEL machine and run it. Basically, as long as the architecture and platform is the same, you have a lot of leeway with binary portability. There's a lot of power in that, and it greatly simplifies network administration. And there's value in staying on the good side of network admins.

Go, Vala, and benchmarks

2011-06-10T06:27:00.000-07:00

When posting benchmarks comparisons, it's pretty important to ensure that you're testing the same amount of work. For example, if you're comparing the ability to construct objects and index them, you should make sure that you're generating the same indexes. Similarly, when you're comparing languages and are benchmarking the costs of things, you really should make sure that your programs are doing the same amount of work.

For example, consider Serge Hulne's posting to the Vala newsgroup, whereby he shows that Go is 2x slower than Vala. He posts programs in both languages that calculate the 10 most used words in the entire works of William Shakespeare. His algorithm is not the most efficient way to perform this task, but that's not the point; his point was to exercise aspects of both languages: object creation, array and associative array performance, IO; that sort of thing. The problem is that his Go version did a lot more unnecessary work than his Vala version; whether he did this on purpose to make Vala look better, or if he just accidentally left in some debugging code, I don't know... but if you're going to make assertions about performance benchmarks and you don't make sure that you're being as fair as reasonably possible given your skill level, then you just end up making yourself look silly.

In Serge's case, his Go program processed the text as Unicode, whereas his Vala program processed it as raw bytes. There was no excuse for this; it was a trivial change to make the Go version process bytes, too. That smells a lot like an intentional cheat. Then, too, the Go version did extra work that the Vala version didn't, like calculating the number of lines, words, and characters in the file -- although it never did anything with the values except sum them up. That's 5M (chars) + 900k (words) + 124k (lines) additional addition operations for the Go version. Finally, there was an unnecessary if-else-clause in a loop in the Go version that was being executed for every word, so 900k more branch operations (and branches are relatively expensive, as far as CPU operations go).

Getting rid of these things that the Go code was doing that the Vala code wasn't improved the speed of the Go program by 30% (0.78s vs 1.1s).

Go isn't going to be as fast as Vala, at least not in the immediate future; Vala does a pretty good job in it's translation to C, and GCC is pretty scary in it's ability to optimize. Go's compiler (6g, which is what I used, because gccgo isn't available on my Mac) is new -- although, I don't doubt Google's ability to eventually bring it down to the point where there's very little discernable difference in performance. My point is that if people are going to pretend to be scientists, doing benchmarks, collecting statistics, and presenting them as proofs, they really should be more careful about their code.

By the way, I'm not a Go programmer. I don't even know Go, beyond what I've learned by fixing Serge's code. I haven't read the tutorial, and this was the first time I'd ever compiled a Go program. There's something to be learned about that: both Vala and Go are readable enough that I could easily see what two programs were doing and identify the functional differences. Ironically, I did play around with Vala when it first came out, so I actually had more experience with Vala when I first came across Serge's code. For what it's worth, after this exercise, I've found that I prefer Go, and could see myself writing code in it. Vala is more like C++; it's basically C with some tacked-on features -- that's one reason why it's benchmarks are so close to C's. Go is a new language, with C-like syntax -- sort of like Java was, when it first came out, only less so. I'll have to see how goroutines work out; if they're not as effective as Erlang's processes, I may lose interest.

Jorg Walter posted a sort of critique focusing on Go (well, mostly it's a highly subjective rant) that gives a good overview of some of the more compelling features of Go; if you can ignore the opinions-stated-as-fact (which have the flavor of "only idiots prefer their braces on their own lines!") and the occasionally erroneous "factiod" ("Ruby faded away" -- huh?[1]), it's an interesting read.

[1] Visits to ruby-lang.org are down by half over the past year, but so are visits to python.org is down by half, and perl.org is down almost 2/3 -- he'd have more accurately implied that Perl faded away, although he'd have been better off not making that claim at all.

VirWox is a rip-off

2011-06-07T17:25:00.000-07:00

Say you want to buy some bitcoins. It turns out that it's a major pain in the ass, but one route is VirWox. Here's what you're looking at when you go this route:

Deposit money with PayPal. VirWox takes EUR 0.35 + 3.4%
Convert dollars to SLL. VirWox takes 3.5%
Convert SLL to BTC (bitcoins). VirWox takes 3.5%
Withdraw bitcoins. VirWox takes 0.02 BTC (currently, about 40¢) as a fee, and holds the transfer for 48 hours.

It's a lot like the old company towns: once you get your money in, they charge you for everything that you do with it. Luckily, this was just an experiment for me, and I didn't put any real money into this. If you're smart, you won't, either. VirWox is a con.

Parallels between Aikido and Wing Chun

2011-06-05T07:37:00.000-07:00

The seminar is going well, but is frustrating. We spent the entire four hours yesterday looking at daan chi sao: fook sao, tan sao, and bon sao. There are so many details in the smallest things!

I want to preface this by saying that I make a lot of gross generalizations here. These are nothing more than observations of an amateur.

I'm continually struck by the similarities between Aikido and Wing Chun, even though they're totally different. It may be the case for every martial art, but in particular it seems that both Aikido and Wing Chun share the characteristic that you can easily learn, say, bon sao or irimi nage, and they look bloody simple, but it takes a lot of practice (years?) to be able to do it correctly and effectively, and even after you think you've finally "got it", small deviations in the behavior of your partner (or changing partners) can totally throw you off and make you think that you haven't learned anything at all!

I'm seeing parallels between chi sao and ryote dori tenchinage; I'm thinking in particular of tenchinage suwari waza. They feel similar to me; although the details are wildly different, both emphasize the connection and feeling what the other person is doing. In fact, the dominant difference (again, from my extremely novice perspective) is that in Aikido one person is designated Uke; in Wing Chun, there is no Uke. I also see parallels in the fact that both Wing Chun and Aikido tend to minimize foot strikes, preferring to maintain a solid, stable connection to the ground. Aikido places more emphasis on this, but in Wing Chun we also talk about how to take advantage of balance (or imbalance). Aikido is all about using your opponent's force -- Wing Chun has that in spades, too. I keep encountering these parallels.

This brings up another interesting paradoxical, dichotomy of the two arts: Wing Chun is Japanese in style, and Aikido is Chinese. Traditionally, Japanese arts tend to be agressive: weight on the forward foot, always attacking, always moving forward; the epitome of this philosophy is Kendo. Contrast this with traditional Chinese Kung Fu, which is full of things like the cat stance, where weight is on the rear foot. However, (until recently, at least) our style of Wing Chun had a more 50/50 weight distribution and we've always emphasized that movement should always be forward. Blocks in Wing Chun aren't blocks; they're attacks. If your partner removes drops his arm, you're (usually) going to hit him. Again, I'm grossly generalizing, but I'm learning that if you think of your blocks this way, the techniques tend to work better. Movements in Wing Chun are economical and direct, linear -- rarely are they circular, like the windmilling movements found in other styles of Kung Fu. My point is that Wing Chun is Japanese in it's philosophy of forward movement and attacks in everything, even defense.

Aikido, on the other hand, is very receptive and indirect. Yes, in Aikido, you always move forward, and you tend to distribute your weight forward; that is still very Japanese. But the movements are circular; while you don't have the big, grand movements of many Kung Fu forms, you can still see the oscillations, the whirling swirls, of Kung Fu. I think this is what makes them seem so oddly similar to me; despite the fundamental differences in philosophy, they borrow enough from each other's cultural stereotypes that the parallels keep popping out at me.

No, Aikido isn't anything like Wing Chun. But consider this: if you imagine time-lapse photographs of Aikido and, say, the Kung Fu Snake form, and similar photographs of Wing Chun and, say, Kenpo Karate, I think you'd agree that the basic perception was that Wing Chun is more similar to Kenpo than to the Snake form, and Aikido more similar to the Snake form than to Kenpo. Absurdly, I am fascinated by this. I do think that culture has a strong influence on style and behavior, and that both Aikido and Wing Chun have gone against traditional stylistic norms, to meet (in a way) in the middle. No, they're not the same art, at all, but the ways in which they are similar is intriguing, given their unrelated origins.

Never trust your wife's martinis

2011-06-03T19:36:00.000-07:00

Sure, they look ordinary martinis, but they're mostly gin, and three times as large as a normal martini. I've always lived by the Dorothy Parker rule of thumb:

I like to have a martini
Two at the very most
Three, I'm under the table;
Four, I'm under the host.

Do not trust this rule-of-thumb when your wife is mixing the martinis!

Kung Fu seminars

2011-06-03T06:53:00.000-07:00

Sifu Dana Wong is back in town for a seminar at the MAF. As I was digging around to find the link to Sifu Wong's blog, I came across this photo from last year's seminar:

I'm really looking forward to this year's seminar!

Dana's a pretty good author, by the way. His blog is worth reading.

I'm a Slidy convert

2011-04-22T19:10:00.000-07:00

HTML Slidy is a way of putting slide shows (presentations) on the web. Think of it like OpenOffice Impress or MicroSoft PowerPoint, but more convenient and with less lock-in. Your viewers only need a web browser to view the presentation, and everybody has a web browser. Not everybody has MS PowerPoint. Not everybody has OO Impress. Furthermore, if you're on a conference call, it's much safer to use a web presentation than, say, NetMeeting, LiveMeeting, or whatever. In my experience, those are much more prone to network glitches bringing the entire meeting down than a simple HTTP connection. The one way that meeting software is superior to a web-shared presentation is that it's harder to sync advancing the slides with a web presentation.

Anyway, that's not what I was intending to write about. For years, I'd been using S5 for my slides. It works pretty well, but lately I've been using Slidy, and here's why:

Slidy is more lightweight. Boy, does S5 have a lot of JavaScript. There are a lot of files, in general, to use S5. Slidy is two files: one JavaScript, and one CSS (not counting image files, of course).
Slidy takes advantage of the fact that browsers have scroll bars. Yeah, ideally, you don't have them, but the fact is that it's never perfect, and there's always going to be somebody using an oddball sized screen so that one of your slides just doesn't quite fit. With S5, they'll never see that content. With Slidy, they just scroll.
I have experienced less wierdness with Slidy. Maybe it's because it is more simple, and doesn't get as fancy with the JavaScript as S5 does, but I encounter many fewer screwed-up layouts resulting from different browser vendor/versions. S5 was sort of twitchy. Slidy just works.
I've found that I spend far less time tweaking the input and output to get it to look right. In fact, with Slidy, it's usually just a matter of breaking lists (or, preferably, removing content), or setting the size on images. With S5, I'd sometimes spend hours tweaking font sizes to try to get things to fit and look right.
It's way, way easier to style Slidy.

S5 does have better transition support; but I don't use transitions. S5 does try harder to scale content so that it fits on the slide, and when it works, it's nice.

Mind you, I haven't actually written either S5 or Slidy HTML in a long while. I generate all of my presentations from RestructuredText, which is how I like it. There's a tool for generating PDF from Slidy called Prince that I haven't tried (it isn't freeware, and I haven't thought about trying to justify it to Management as a necessary purchase, yet); PDF generation of slides is about the only thing I'm missing.

Other things I've learned: pandoc's Slidy generation is painful, and I've yet to figure out how to coerce it to use my style sheets. It appears to utterly ignore the --data-dir directive, and insists on either linking directly to the W3C resources, or using it's own. rst2slidy works pretty well, but there's no real way to insert header images except my sed'ing the generated output (booo!), and docutils is broken in it's handling of images and SVG; it doesn't allow % in height or width, which is supported by HTML (c'mon, read the spec, people!), and it embeds SVG images in tags, rather than tags, despite the fact that works better (like, browsers figure out the image size from the image itself) and is supported by all modern browsers. Despite these annoyances, it works remarkably well, and these are all easily fixed -- which isn't the case when things go wrong with S5. You can spend hours in the guts of the S5 CSS trying to get things to look right. I know. I have.

So, yeah. I've been using Slidy exclusively for about 8 months, and I'm definitely a convert. I spend less time tweaking it, and it's more reliable.

Erlang's limitations in module encapsulation

2011-03-18T07:06:00.000-07:00

I was recently looking at mocking frameworks for Erlang, to facilitate unit testing. Mocking is a mechanism for easily producing objects and functionality to limit the scope of your tests. For example:

-module(a).
-export([a/1).
a(X) ->
b(X) * X.
b(X) ->
X * 5.

Pretend that b/1 does something like go to a database, or connect to some other remote service, or read from a file... something that may either take a long time, or might not be available in a test environment. For a unit test for a/1, what you're really concerned with is testing the functionality of a/1, not b/1; to accomplish this, you'd like to mock up the functionality of b/1 to be something known, so that you can prove a/1.

What you should be able to do with mocking is something like this (there are a lot of different ways that you could define the mocking interface; I'm just picking an arbitrary one):

mock:expect( ?MODULE, b, fun(X) -> X end).

Then you could define a unit test that says:

4 = a(2).

This makes a/1 provable through induction, because it isolates the code in a/1 -- which is exactly what you want in a unit test.

Unfortunately, you can't do this in Erlang in such a way that the unit tests don't impact the way you write the code being tested. This is due to a flaw in Erlang modules, and particularly, the export directive.

If you want to do mocking sample above in Erlang, the code being tested must become

-module(a).
-export([a/1,b/1]).
a(X) ->
a:b(X) * X.
b(X) ->
X * 5.

This is because mocking replaces the functionality of a function with different functionality, and the Erlang compiler hard-links the call to b/1 in a/1 unless you specify the module of b/1. This, in itself, is not a problem: the problem is that even within module a, references to functions within the same module must be exported. That is, if a/1 wants to call a:b/1, b/1 must be exported. Why is this a problem? Because it leads to comments like this, which you find all too commonly in Erlang projects:

-export([a/1]).
% -------------------------------------
% WARNING: DO NOT CALL THESE FUNCTIONS
-export([b/1]).

There are a number of reasons why the authors had to export b/1. Because spawn/3 can't call functions that aren't exported. Because mocking requires it. Because they want to support code reloading. All of which are valid use cases, and all of which force developers to over-expose their API, breaking encapsulation, and suggesting that Erlang's module handling is flawed.

The superiority of base-12

2011-02-04T07:07:00.000-08:00

It should be evident that, all other factors being equal, base-12 is a superior number base for humans than base-10. I won't go into too many details why this is true; there are many resources that discuss these details in length, but it's main strength is that it has more prime factors than base-10. 12 is divisible by 1,2,3,4 and 6; 10 is divisible only by 1,2, and 5. As to it's suitability over other systems, the next step up occurs at sexagesimal (base-60), which is divisible by 1,2,3,4,5 and 6, and that's an inconveniently large set of base numbers for humans. Dozenal is so useful that it's still commonly used today; a dozen eggs, a gross, our analog clocks, the number of signs in the zodiak, inches in a foot, etc., etc.

What this post is about, however, is how useful this is even beyond the first 12 numbers. Consider a gross (a dozen dozen, or 144₁₀), or 100₁₂:

	100₁₀	100₁₂
2	50₁₀	60₁₂
3	33.33₁₀	40₁₂
4	25₁₀	30₁₂
5	10₁₀	24;1₁₂
6	16.66₁₀	20₁₂
7	14.285714₁₀	18;6A3518₁₂
8	12.5₁₀	16₁₂
9	11.11₁₀	14₁₂
A₁₂	10₁₀	12;5₁₂
B₁₂		11;11₁₂
10₁₂		10₁₂

There are really only two (base) numbers that produce non-terminating divisors in a gross: B and 7. For 100₁₀, you have 3, 6, 7, and 9. Sidenote: I'm not thrilled with the selection of ";" as a floating-point character, but it seems to be what everybody is using, and there's really nothing better (unless we just stick with "."). Thankfully, there's no universal agreement on the character to use, and I reject the Dozenal Society of America's choice of "*" -- it's a really, really poor choice, as anybody who does any programming or, verily, basic math can tell you. "A" and "B" aren't very good, either, but at least they're recognizable to anybody who's ever taken a computer programming course.

BTW, the Dozenal Society of America has been busy building a nice new site; check it out.

My shocking Erlang discovery

2011-01-24T07:32:00.000-08:00

Sending messages to PIDs is really, really slow (comparatively).

Consider the following code, containing two tests that do almost the same thing. I say "almost" because there's a small bug causing the totals to be off-by-one, but they're performing the same amount of functional work. One uses PID message passing to increment a value; the other uses lambda expressions.

-module(test).

-export([test/2]).

-export([one/1, two/1]).

test(F, N) ->

    A = F(init),

    {T,R} = timer:tc( lists,foldl, [ fun( _, Acc) -> F(Acc) end, A, lists:seq(1, N) ]), 

    F({stop,R}),

    io:format("\n~ps~n",[T/1000000]).

done(T) ->

    io:format("\nDone ~p~n",[T]),

    io:format("Memory: ~p~n",[erlang:memory(processes_used)]).

one(init) ->

    spawn( fun loop/0 );

one({stop,X}) ->

    X ! exit;

one( X ) ->

    X ! go, X.

loop() -> loop(0,0).

loop( State, Ttl ) when State > 100000 ->

    io:format("."), 

    loop(0, Ttl + 1);

loop( State, Ttl ) ->

    receive

        go -> loop( State + 1, Ttl + 1 );

        exit -> done(Ttl)

    end.

two(init) ->

    fun(_) -> make_next( 0,0 ) end;

two({stop,R}) ->

    R(exit);

two( F ) ->

    F(0).

make_next(C,T) when C > 100000 ->

    io:format("."),

    make_next( 0, T+1);

make_next(C,T) ->

    fun(K) ->

            case K of

                exit -> done(T);

                _ -> make_next(C+1,T+1)

end

    end.

one() retains state by spawning a process that loops with it's own state. two() is the interesting code; it retains state by passing back a function factory. Would you have expected one() to be slower than two()? I wouldn't have, at least not to this degree (I cleaned the output a little):

447)~ % erl +native -smp

Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.2 (abort with ^G)

1> c(test).

{ok,test}

2> test:test( fun test:one/1, 10000000 ).

...................................................................................................

39.70179s

Done 10000099

Memory: 111707084

3> test:test( fun test:two/1, 10000000 ).

...................................................................................................

Done 10000098

Memory: 111710500

2.410091s

Using functions like this sixteen times faster than passing messages. That really surprises me, to be honest, and gives me something to think about before I go off and gen_server-ize all of my code.

I hate Yahoo!

2011-01-23T14:37:00.000-08:00

It's buggy and irritating (I'm talking about the Groups web site). Joining is totally borked if you don't already have a Yahoo! account, and the "tell the moderator why you want to join" has a 200-character limit on the message you send. Only, the Yahoo! web devs are so stupid that they didn't put a live character count on the text box, so it's a guessing game to figure out if your text is short enough -- or you have to manually count the letters yourself. Give me a break. Idiots. No wonder they're an almost-ran to Google.

Running a code server in erlang

2011-01-22T05:59:00.000-08:00

For as old as Erlang is, there's a distinct lack of documentation about some aspects of it. I've had a hard time finding information about how to run a code server, so I'm going to write down what I've learned here.

First, there are a couple of things I should note:

While you can use the erlang runtime as a hack-as-you-go platform, it's really better to follow the OTP principles; you get a lot of things for free that you otherwise end up writing yourself. So, go ahead and use gen_servers, and write your .app and .rel scripts. I know, it feels like a lot of metadata, and I hate systems that require a bunch of metadata files scattered around. This is because a profusion of metadata files is a common feature of some of the worst software systems -- Hibernate, for example -- but in this case, it's a necessary evil. You can get pretty far without the files, but in the end, you'll end up needing them anyway to take full advantage of the OTP, so go ahead and write them.
Erlang has a really wicked (as in, good) distribution mechanism, so if you can use it, consider it. When used, it'll build a tar-ball containing everything you need, including a stripped-down runtime, to run a worker node; copy the tar-ball to the destination machine, unpack it, and run your app.
What I describe here is probably not Erlang an "best practice," but it satisfies a need, and with a small tweak, it produces #3 above.

This whole thing hinges entirely on the boot script. I have been unable to figure out a way to run a code server without a boot script; the Erlang documentation says this, indirectly, in several places by noting that the boot script tells the runtime how (and from where) to load code. Although you might think, from reading the erl manpage, that you can inform the runtime about where to get code purely with -loader inet -hosts IP -id Name, you can't -- at least, I've not been able to coerce it so. A boot script depends on an .app, and while it can be written by hand, it's easier to generate it from a .rel.

This is what I believe to be the bare minimum to get a client to load code from a boot server:

A module with the application behaviour
A module with the supervisor behaviour
An .app file for your application
A .rel file, used to generate the boot script.

And if anybody knows of a way to use a code server with less crap, let me know. If you want to start up services on the worker, that's easy enough -- just fire them off from within the supervisor.

I'm starting entirely from scratch; you should be able to copy/paste and get up and running:

44)~% mkdir myapp ; cd myapp

45)~/myapp % mkdir ebin src

46)~/myapp % cat > src/myapp.erl

-module(myapp).

-behaviour(application).

-export([start/2,stop/1]).

start(_,_) -> myapp_sup:start_link().

stop(_) -> ok.

47)~/myapp % cat > src/myapp_sup.erl

-module(myapp_sup).

-behaviour(supervisor).

-export([start_link/0, init/1]).

start_link() -> supervisor:start_link({local, ?MODULE}, ?MODULE, []).

init(_) -> {ok, {{one_for_one, 1, 60}, [] }}.

48)~/myapp % cat > ebin/myapp.app

{application, myapp,

[{description, "MyApp"},

{id, "MyApp"},

{vsn, "0.0.1"},

{modules, [ myapp, myapp_sup ]},

{applications, [kernel,stdlib]},

{maxT, infinity},

{registered, [myapp, myapp_sup]},

{mod, {myapp,[]}}

]

49)~/myapp % cat > ebin/myapp.rel

{release, {"MyApp", "0.0.1"}, {erts, "5.8.2"},

[{kernel, "2.14.2"}

,{stdlib, "1.17.2"}

,{sasl, "2.1.9.2"}

,{crypto, "2.0.2"}

,{myapp, "0.0.1"}

]

50)~/myapp % erlc -o ebin src/*.erl

51)~/myapp % erl -id bootserver -name bootserver -setcookie cookie -run erl_boot_server start 192.168.0.6

Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.2 (abort with ^G)

(bootserver@Sean-Russells-MacBook-Pro.local)1> systools:make_script("ebin/myapp", [{path,["./ebin"]},local]).

(bootserver@Sean-Russells-MacBook-Pro.local)2> ls("ebin").

myapp.app myapp.beam myapp.boot myapp.rel

myapp.script myapp_sup.beam

ok(bootserver@Sean-Russells-MacBook-Pro.local)3>

User switch command

--> q

52)~/myapp %

You don't need to run erl with all of those args if you're just making the boot script; they're needed to run the boot server. Here's the client -- I've pared it down, because SASL dumps a bunch of debugging information that isn't relevant for this tutorial:

53)~ % erl -id slave -name slave -setcookie cookie -loader inet -hosts 192.168.0.6 -boot /Users/seanrussell/myapp/ebin/myapp

Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

=PROGRESS REPORT==== 22-Jan-2011::08:40:58 ===

supervisor: {local,sasl_safe_sup}

started: [{pid,<0.40.0>},

{name,alarm_handler},

{mfargs,{alarm_handler,start_link,[]}}, {restart_type,permanent},

{shutdown,2000},

{child_type,worker}]

A bunch of stuff snipped here

=PROGRESS REPORT==== 22-Jan-2011::08:40:58 ===

application: myapp

started_at: 'slave@Sean-Russells-MacBook-Pro.local'

Eshell V5.8.2 (abort with ^G)

(slave@Sean-Russells-MacBook-Pro.local)1> pwd().

/Users/seanrussell

(slave@Sean-Russells-MacBook-Pro.local)2> code:which(myapp).

"/Users/seanrussell/myapp/ebin/myapp.beam"

(slave@Sean-Russells-MacBook-Pro.local)3>

User switch command

--> q

54)~ %

Because I did this all on one machine, you might think that the slave is getting the code directly from the filesystem, but it isn't; this works just as well from a different machine.

It's instructive to take a look at the myapp.script file that systools creates, paying special attention to the paths. If you remove the local argument from make_script, then systools will change the absolute paths to $ROOT, which it expands to the value of that variable on the server, which is in turn set by the erl command. You can also add an argument {variable,[MYAPP,"."]}, and systools will replace the full path with the variable $MYAPP, which you can then define on the slave by adding the argument -env MYAPP /absolute/path/to/myapp/parent to the erl command.

Hopefully, this will help somebody else; it took me about three full days to figure this out. Erlang is well documented, but having good documentation doesn't always provide enough information for how to use a system, and Erlang OTP is horrible in that respect. Once you get it up and running, though, it's a thing of beauty.

Google eBookstore

2010-12-12T06:15:00.000-08:00

I was really excited about the opening of the Google eBookstore; unfortunately, and depressingly, eBookstore is made of fail:

Not all viewing format options are supported for all books. Some support epub and PDF, some are only readable online with a web viewer or some custom app
It isn't possible to find out what viewing format options are available for books
It isn't possible to filter books by download options

I'm not reading a book on my computer. I'm not reading it on my cell phone, either. And I'm not going to buy from a store that doesn't let me download (i.e. "own") what I purchase. eBookstore is, consequently, useless, to me, and it seems I'm stuck with Sony's overpriced store for now.

Google, until you support ePub for all of the books you sell, or at least give customers enough information for them to tell whether or not they're throwing money away on you, you won't be getting any more of mine.

Erlang + TokyoTyrant / TokyoCabinet / medici

2010-11-30T19:52:00.000-08:00

My first real, significant, observation about Erlang is this piece of advice to new Erlangers: repeat this mantra:

Mailboxes are not queues!

More experienced devs than I get this wrong. In any case, I've been working with Erlang and TokyoCabinet/Tyrant at work -- I've been using MongoDB, too; it isn't clear yet which will best fit our needs -- and I've been using medici by Jim McCoy, a set of libraries for interfacing with TokyoTyrant/Cabinet. I found a bug today in the principe module, which the following code demonstrates:

-module(principe_test).
-export([runtest/0, loop/0]).

mongod() -> "mongod".  % Where's your mongod executable?

runtest() ->
    start_mongo(),
    Inserter = spawn_link( fun ?MODULE:loop/0 ),
    Inserter ! quit,
    Inserter ! go,
    timer:sleep(500),
    {ok, Fd} = file:open("mongod.pid",[read]),
    {ok, Data} = file:read_line( Fd ),
    os:cmd(io_lib:format("kill -HUP ~p",[string:strip(Data,both,10)])).

start_mongo() ->
    filelib:ensure_dir("test/file"),
    Cmd = io_lib:format(
        "~s --dbpath ~s --port 9999 --fork --logpath ~s --pidfilepath ~s", 
        [   mongod(),
            filename:absname("test"), 
            filename:absname("mongod.log"), 
            filename:absname("mongod.pid") ]),
    os:cmd(Cmd),
    timer:sleep(1000).


loop() ->
    {ok, P} = principe:connect( [{port, 9999}] ),
    receive
        go -> principe:put( P, "key", "value" )
    end.

The problem is that principe:get/3 (and many other functions) use receive to get call-backs from the socket library, and assume that they're going to be receiving messages from only the socket library. This is a bad assumption. In effect, the methods hijack the mailbox of the calling process and then assume that they'll only find socket messages in there. Happily, the fix is really small:

diff --git a/src/principe.erl b/src/principe.erl
--- a/src/principe.erl
+++ b/src/principe.erl
@@ -718,7 +718,7 @@
            {error, conn_closed};
         {tcp_error, _, _} -> 
            {error, conn_error};
-        Data -> 
+    {tcp, _, _} = Data ->
            ResponseHandler(Data)
     after ?TIMEOUT -> 
            {error, timeout}

Incidentally, MongoDB is about 4x as fast as Riak, and TokyoTyrant is about 2x as fast as MongoDB. MongoDB and TokyoTyrant are faster than opening a file directly on disk for each small record. Riak is about as fast as direct filesystem access. That's almost certainly due to memory caching + bulk writes used by MDB & TT, vs. many, many inode create/write/close calls.

Taco Bell Programming

2010-11-25T05:56:00.000-08:00

Ted Dziuba has an interesting article on what he calls Taco Bell Programming; it's worth reading -- there is a lot of value in the concept he's promoting. I had some concerns about the practicality of the approach, so I ran some tests.

I produced a 297MB file containing 20 million lines of more-or-less random data:

ruby -e '20000000.times { |x| \
puts "#{x}\03#{rand(1000000)}" \
}' > bigfile.txt

Then I ran:

cat bigfile.txt |\

gawk -F '\03' '{print $1, $0}' |\

xargs -n2 -P7 printf "%s -- %s\n" > newfile.txt

This is a baseline; a data producer, such as pulling from a database, is going to produce data more slowly than cat, and printf is going to write lines more quickly than whatever we're doing to process the data. Here are the results:

P Time
----- --------------
7 68m
3 88m

1 241m

xargs was doing all of the work in this test, as far as top could tell, but the multiple processing helped. This confirmed my suspicions: xargs is having to spawn off a new Linux process for every line, which is not cheap. For comparison, a similar program written in Erlang (not known as being the fastest language in the world) was able to process the same amount of data, on a machine with half as many cores, in 20 minutes. In addition, the machine that it was running on was also: (1) running a process which was pulling data from a SqlServer database, itself, consuming 90% of a core, (2) inserting the results into a MongoDB database, and (3) running the MongoDB server that was being inserted into. So: half the resources, doing much more work, and it still runs over 3x as fast.

Ted's main point -- that code is a liability -- is still valid, and it's always useful starting out a project asking yourself how you could solve your problem with such tools. However, take such approaches with a grain of salt; if you can afford lackluster performance, it's probably a worthwhile solution. If performance is any sort of consideration, you may need to seek other solutions.

Raw milk is made of win

2010-11-24T04:35:00.000-08:00

Have I sung you the praises of raw milk? No?

Its good stuff, milk. I used to drink between a half and a full gallon a week, prior to moving to our house in Elverson, PA. The best thing about this house is that near it, just down the road, is a dairy, and this dairy sells raw milk. My wife commented the other day that we're up to two gallons a week. Sometimes, that's all I have as a meal.

The first time you try raw milk, the flavor is a bit odd -- it's not bad, but is definitely different. However, going back in the other direction (from raw to pasteurized) is an entirely different matter: after drinking raw milk for a few months, pasteurized milk sucks. It's almost undrinkable.

Anyway, I'm not on a campaign to convert anybody. I just love raw milk. If you want to know more, though, check out the wikipedia article, and this site.

Linux and the Mimo 710S

2010-11-22T18:42:00.000-08:00

The Mimo 710S is a small-ish LCD panel (7" diameter) that connects to your computer via a USB cable and acts as a monitor. It uses DisplayLink as a protocol. After some trial and tribulation, I got it set up and working with Ubuntu 10.10, and here is how I did it.

First, you need the udlfb kernel module, and the displaylink xorg driver. One of the best tutorials is provided by mulchman; I won't repeat what he says, although I will point out that he has you reboot your computer in the middle of the install, and that this was entirely unnecessary (I didn't). It's all pretty easy; install some build tools if you don't already have them, get the udlfb sources, and build and install the two parts. There are no pre-built packages for Ubuntu (as of the time of this writing).

That was the easy part. I had no problem getting the device registered, and the test cases packaged with udlfb worked immediately. My problem was getting something useful onto the device.

I had a number of issues. First, I didn't want to use Xinerama, because Xinerama imposes a bit-depth limitation (all displays under Xinerama must share the same bit depth; the Mimo has a max depth of 16 bits, and my graphics card doesn't want to do anything less than 24). Second, I have to use the fglrx drivers, because xmonad -- the very finest window manager, ever -- doesn't work on two screens properly without Xinerama. Third, fglrx crashes when it's paired with a displaylink device. I didn't dig into this very far; it's a pretty hard core-dump, though -- it's proprietary software, so that's to be expected. This combination of limitations (and it took me a while to discover all of them, let me tell you) drove my final solution, which I'm happy to say works just fine.

What I ended up with is two xserver instances -- one basically my pre-Mimo instance, and one a new instance for just the Mimo -- tied together with Synergy. If you don't know Synergy, go download it, now. It ranks among the most useful pieces of software, ever. It runs on Windows, Linux, and OSX, and lets you share a keyboard and mouse between multiple computers (or, as it happens, xservers) like a software KVM.

Anyway, here are the bits. First, you need to add a mimo section to your xorg. I just tacked this on to the end of mine:

########################################
# DisplayLink Screen
########################################
Section "ServerLayout"
  Identifier "Mimo Layout"
  Screen 0 "DisplayLinkScreen" 0 0
  Option "AutoAddDevices" "false"
  Option "AllowEmptyInput" "true"
  Option "AutoEnableDevices" "false"
EndSection

Section "Device"
  Identifier "DisplayLinkDevice"
  Driver "displaylink"
  Option "fbdev" "/dev/fb1"
EndSection

Section "Monitor"
  Identifier "DisplayLinkMonitor"
  DisplaySize 152 92
EndSection

Section "Screen"
  Identifier "DisplayLinkScreen"
  Device "DisplayLinkDevice"
  Monitor "DisplayLinkMonitor"
  DefaultDepth 16

  SubSection "Display"
   Viewport 0 0
   Depth 16
   Modes "800x480"
  EndSubSection
EndSection

The next bit is a script that looks like this:

#!/bin/sh

X -nolisten tcp -novtswitch -sharevts -layout "Mimo Layout" :1 &
synergys --config .synergyl --display :0 --name big --daemon
synergyc --display :1 --name little -f localhost &
DISPLAY=:1 xmonad &

The first piece of magic starts X in multihead mode; the -novtswitch argument is fricken' critical; without it, you're locked out of your computer. At least, I was. Once that's up, X is running on the Mimo, and you can now start synergys (server) on your main display (:0), and synergyc (client) on your Mimo display (:1), which allows you access to that second xserver with your input devices. I won't describe how to configure synergy; you can figure that out better from the synergy documentation. Suffice it to say that the --name arguments have to match what's in the file. The final line starts up another xmonad (or whatever window manager you like) on the second xserver. And voila:

That's the Mimo to the left, in case you couldn't tell. I run an IRC/IM client (irssi) on it, and it's perfect -- the chat's always visible. Here's another shot with xlock(s) running:

For $100-some bucks, it's not a bad investment.

Oh, that's a fairly decent Dell under the Mimo, but it has Windows 7 on it, and so is practically useless.

A perfect example of horrible design

2010-11-20T16:59:00.000-08:00

The vorbiscomment command of the Vorbis toolset is one of the most poorly designed pieces of software that I've had the misfortune of using in a long time. The tool can be used to either add a new comment to an ogg file, or entirely replace all comments. It can not be used to update an existing comment. It's a clear violation of "make the common case simple, and the uncommon possible." Updating, or modifying, comments is the one, most common, thing a user might want to do -- and you can't do that with vorbiscomment.

Here's a use case: you rip a CD, and accidentally enter the wrong DISCNUMBER -- say, 1 instead of 3 -- and you're left with 16 ripped songs all with good metadata, except for the DISCNUMBER. How do you fix this with vorbiscomment? Well, if the tool was not totally stupid, you'd do something like this:

   $ nonstupidvorbiscomment -u -t "DISKNUMBER=3" *.ogg

or, if (for whatever reason) you need to perform a more complex search:

   $ find . -regex ".*/Album/.*\.ogg" -exec \
   nonstupidvorbiscomment -u -t "DISCNUMBER=3" {} \;

But you can't do that, because vorbiscomment doesn't have a "-u" (update) argument. No, all you get is -w (write) and -a (add). So you end up doing something like this:

   $ find . -regex ".*/Album/.*\.ogg" -exec \
   echo vorbiscomment -l \"{}\" \| \
   sed \'s/DISCNUMBER=1/DISCNUMBER=3/\' \
   vorbiscomment -w -c - \"{}\" \; > runme.sh
   $ ./runme.sh
   $ rm runme.sh

Yeah, that's slick. Not. Somebody should have reviewed vorbiscomment before letting it be released.

Our new media streamer

2010-11-08T04:41:00.000-08:00

Sometime in the past couple of months, our Roku died. I don't know why; but it doesn't power on any more. Monika's never liked the thing, because she found it difficult to navigate -- we've digitized all of our CDs over the years, which means that we have some 6k songs on the server, and it can be challenging to find music when you're used to flipping through CD covers.

Another new development in our music consumption has been Pandora, and it's been nothing but a pain trying to stream Pandora over the Roku. So, last weekend, I purchased a new media streaming device; the one I chose was the Logitech Squeezebox Duet. We've had it for almost a week now, and it's been great -- this one is definitely a "buy."

In particular, there are three things about it we like:

The remote is awesome. It is large enough to show cover art, and scroll-lists (it might remind one of the iPod interface). It controls the server via wifi, so you don't need line-of-sight to control the box. The battery is respectable, considering the remote is running a full-fledged Linux install.
Pandora. Plus everything else you could want to stream. There are applets for a bunch of services, such as Last.fm, BBC, and Napster, as well as non-music stuff such as Flickr and Facebook. It's all easy to install, too.
Squeezebox Server. First, it runs on Linux. Yay, Logitech! And it's a nice piece of software, to boot: the UI is handsome and easy to navigate, it is trivial to set up, and it understands Ogg and Flac, and transcodes automatically if it needs to. Monika particularly likes setting up play lists on it, and controlling the music if she happens to be working on her computer.

Beyond these features, which are alone worth the cost of the system, I liked the fact that set-up was dead-simple. I've been struggling with mt-daapd (Firefly) for the past couple of years, and it's been challenging at times to keep transcoding configured and working. I've spent waaaay too much time in the mt-daapd.conf file. Squeezebox Server is in the Ubuntu repositories, so it wasn't even a manual download, and configuration is all through the web interface. Again, I've been thrilled with the server.

I also got a thrill when I discovered that you could ssh into the remote. I spent some time on the weekend unsuccessfully enabling the IR emitter on the handset; there's an app, but configuration is a pain and I never did get it to work. However, being able to ssh into the handset and look at the log files was interesting, and merits more exploration.

I'm excited about the extensibility, too. Theoretically, you can simul-stream to multiple devices in the house, and that's something else I'd like to look into; it'd be nice to have around the holidays.

There are always a couple of things that could be improved. First, I'd like to get the IR working so that I can use the remote to turn on the amp. There are solutions, but they're all pretty hacky, and the four hours I spent on the weekend trying to get SqueezeIR working is my limit these days for messing with something like this. Second, the remote takes a long time to wake up. I'm used to my Mac, which wakes up from sleep mode before I can fully open the lid; the Duet remote sits and spins for a dozen seconds or so before it presents it's UI. I blame Linux for that, though; I've yet to see a Linux box wake up from a sleep with anything resembling agility. Even Windows beats Linux there, and that's just sad.

So, if you're in the market for a streaming media receiver, I highly recommend the Logitech Squeezebox Duet. If all you're looking for is to stream Pandora, there are much cheaper alternatives; however, if you have a digital library that you want access to, as well as access to online streaming internet radio, the Duet is a low-pain solution.

Success!

2010-11-06T05:13:00.000-07:00

I did it. It was a long, hard slog, but I've finally gotten down to my target weight.

Actually, the first 35 pounds wasn't all that difficult. I started this last January at 240 pounds, setting my target at 200. The first 12 pounds went in the first two weeks, and then it was a pound here, two pounds there, with slippages around holidays. The problem was the plateau: I hovered between 204 and 206 for over 5 months, and although I never went back up above 206, I could never break 201, either.

There are a number of reasons for this. We're on the South Beach Diet, and while Monika has been pretty strict about it, I haven't been. For example, the holidays that I mentioned above means that we both gorge on whatever we normally would on the holiday, with little restraint. Those times have set me back as much as 4 pounds per event. When we go overseas, we don't watch what we eat (although, we tend to walk more, so that's nearly always a break-even for me -- I think I need to vacation more). And I have long-standing, recurring lunch with a friend on Friday, which ritualistically consists of a burger and beer (I give a nod to the diet by eschewing the fries for a salad, which I never eat anyway). Except at the start, I don't eat the menus for lunch. I eyeball it and stay low on the carbs. And breakfasts are fudge-able, as far as the fat content goes. I'm sure that the single-malts on the weekend haven't helped.

The lesson here is that if one sticks to the diet, one can lose weight pretty fast. Monika got down to her target weight (-35 lbs) within four months, and neither of us have changed our exercise habits significantly (she's always worked out; I, never). I also know that I can keep my weight to within this range by watching what I eat, and still allow myself scotch, and the occasionally beer and burger.

I claim this diet a success. Now, bring on the Thanksgiving and Christmas holidays!

pandoc & PDF

2010-11-05T06:03:00.000-07:00

Oy.

There's a good reason why I hate LaTeX, and that's bloat. Here's an example:

rst2pdf (restructured text to PDF) converts marked-up text to PDF. The package, and it's dependencies, take maybe a couple of tens of megs at the most.

pandoc depends on LaTeX to produce PDF files. The minimum packages needed to produce PDF with LaTeX (using markdown2pdf) consumes nearly a gigabyte of disk space. I mean, seriously; that's absurd. I'm no LaTeX newbie; it's always been a bloated hog, but it's getting much worse. And you know what? It doesn't do anything more than the alternatives. Lout, for example, at a fraction of the disk space will do math just as well, thank you, and produce just as pretty output with just as much control over formatting -- although, Lout appears to be defunct. Oh, well.

Anyway, I'm just frustrated with bloat lately, and although I really want to use pandoc (docutils is nice, but pandoc has a broader range of formatting options, such as markup for strike-out, subscript, and superscript, and better table formatting control), I'm loath to install a gig of crap just to get it.

Another reason why I hate Java

2010-08-07T07:35:00.000-07:00

It's the whole problem that there are layers and layers of crap between you, and what you want to do, and every one of those layers can have bugs. In this case, the bug is in Jakarta Ant. The problem is that it took me two hours to figure out that it wasn't something that I was doing, but that it was something in Ant, or the interaction with Ant and OSX's Java, or... well, I don't know where the problem is, and I don't really care. Struggling to get something as fundamental as this working isn't how I want to spend my time.

So, here's the thing: you'd expect these two chunks of Ant script to do, essentially, the same thing. Yeah, the internals are different, but you'd hope they'd have the same high-level effect:

classname="com.tsl.server.TslRMIImpl"/>

Right? I mean, nothing complex or tricky here. But they don't. Ant completely fucks up the first one; the class path is not set correctly. At least, it doesn't work with Ant 1.7.1 and Java 1.6.0 on OSX 10.6.4. Put these two lines in the same target, just like they are, and the first one prints out an entirely different classpath than the second (assuming that the class code prints the class path). The first one's class path isn't even remotely correct; a dump of the ClassLoader class path contains exactly one element, and that's some ant jar file.

Seriously, I have better things to do with my time than waste it tracking down somebody else's brain farts. It's why I hate the Java VM, and more especially, things built on top of it -- frameworks are especially bad, because they're just chock full of other people bad code.

Single Malt Scotches

2010-07-25T10:03:00.000-07:00

For the past few weeks, I've been sampling single malt scotches.

It all started when we went to visit Brett and Marnie in Paris, and were trying to think of a hostess gift for them. Marnie likes Cognac, so we thought we'd bring them a bottle -- there's a whole story around that which I won't get into, involving the TSA and difficulties in transporting bottles of flammable liquid on an airplane -- and in doing that, I spent a lot of time online researching Cognac, and found it fascinating.

When we got back, I got to thinking about Scotch. I have a couple of friends who are "into" single malts, and one who told me that the single malts are an entirely different beast from lesser Scotches (and whiskeys), so I thought I'd try it. I started out with a mid-range bottle of Scotch (ca. $70), which was good enough that I'm now on my fifth bottle (all of varying degrees of emptiness), and I thought it was a good time to lay down some thoughts on the varying brands.

I didn't keep track of the first bottle, but it was an 18yo bottle of something, and I liked it enough to consume the entire thing in short order. Can't say much about it aside from that. Here are the others currently in my cabinet.

Laphroaig 18yo
Very, very smokey. In fact, that's about all I taste, but then, my palette is not yet very sophisticated. Nonetheless, I really like this Scotch, and will keep it stocked. I don't yet know whether it would pair well with a cigar; it might be too much smoke, but then again, maybe it'd draw out the other flavors. Definitely needs water; it's 96 proof.

Balvenie, 15yo (cask 198, bottle 82)
Currently, my favorite Scotch. Very smooth, very fruity. Almost -- very nearly, sweet. Does not need water.

Tomatin 12yo
This tastes like what I expect Scotch to taste like; that is to say, it isn't very distinctive to me. Unfortunately, in the Army I once made myself extremely ill on a bunch of different alcohols, one of which was a whiskey that tasted very much like this Scotch, so I don't much like the taste. I may try an older Tomatin before I give up on the brand, but I suspect that I won't be stocking this one. Mind you: I'm sure it's a fine Scotch, and this is purely a matter of personal taste. It is well served (for me) by adding water, despite being (only?) 86 proof.

Glenfiddich 18yo
To my immature palette, this tastes identical to the Tomatin. I have a map of Scotland, and where in it each distillery finds itself, and I strongly suspect that these two distilleries are in close proximity. In any case, it'd take a more discerning palette than mine to tell the difference between these two, and (as I've said), I don't care for this particular taste.

My next bottle will be a 21yo bottle of Balvenie, and I may purchase a step up on the Laphroaig as well. I also need to start learning to pronounce these names.

American Manufacturing is dead to me

2010-07-20T04:36:00.000-07:00

Ok, ok... I'm making this statement based on a single Japanese company. It isn't fair. Zojirushi (the Japanese company in question) makes peerless products, though. They're well-designed and have outstanding production quality.

On the recommendation of our friends Asher and Harumi, we bought a Zojirushi rice cooker a couple of years ago. Mind you, I never realized what I'd be getting into when I went shopping for a rice cooker; Zojirushi themselves make, like, two dozen different models, and they aren't the only company in the business. In any case, we're really happy with the rice cooker. It's easy to use, easy to clean, and is full of features like a delayed start timer. What I found I liked the most, though, was the build quality. The plastic parts are robust, and it fits together nicely. There are no loose, wiggling bits, and it isn't complicated or ambiguous in dis-or-re-assembly.

The thing that prompted me to write this post, though, was that I just bought a Zojirushi travel mug. Now, you'd think that purchasing a travel mug would be simplicity itself, but it isn't. There are countless available, but most of the web sites don't tell you about the construction, and by the time I'd purchased my third one, I'd discovered that the American manufacturing industry's definition of "insulated" doesn't match my definition. Every one of those mugs is double-walled aluminum, and none of them retain heat even over the course of my commute into work.

As an aside: I know that these mugs are all, probably, produced in China. I'm guessing that they're designed in the U.S., and even if they aren't, they're branded by U.S. company logos. So take note: I don't give a hoot who's making the thing... you put your name on it, you're responsible for it.

I eventually discovered that Zojirushi manufactures a line of mugs. A bunch of them. Again, they have about a dozen models, of various designs, sizes, and intended use. I settled pretty quickly on the SM-DA series (there are two sizes sub-models, DA35 and DA50) because of their heat retention. Now, here's the first way in which this Japanese company beats it's American counterparts: they actually put heat retention metrics on their product page. You know, the kind of information you'd want to know if you were purchasing something that was supposed to be retaining heat. This model had other nice features, such as a locking, sealing lid. It took a while to find a place (that wasn't in Japan) to purchase it -- I got mine from a "bargaincell" through buy.com -- and it took even longer for them to ship it, but it arrived yesterday.

Here's where it gets good. First, nothing is in English except for the company name and product model. There are a lot of cute pictures of Anime-style people burning their faces by doing naughty things (not that kind of naughty, you pervert) with the mug. But, hell... it's a travel mug; how hard can it be?

The construction is, again, amazing. The cover is almost as heavy as the rest of the mug, which is amazing in two ways: the mug itself is super-light, and the lid is unusually heavy. The plastics are, again, robust; the rubbers are soft and pliable, and it all goes together with that typical Zojiushi solidness. The locking and release mechanism are simple to operate, and the seal is perfect. A perfect example of the quality is a very small thing: when the lid is folded back, it locks into place so it doesn't flop forward onto your face when you drink. It is details like that, which I know from experience you don't get from American products*, that make the difference.

And the best thing is that I poured coffee into it about 45 minutes ago, and the canister and lid are still cool to the touch, which means that there's been no (or very little) heat loss.

It might just be that Zojirushi makes good products. It might be that the Japanese, unlike Americans, are unwilling to settle for cheap, throw-away, crap. I suspect that it's the latter; Japan is a wealthy country. Regardless, I'll be looking first to Japanese products -- specifically, products primarily intended for the Japanese market -- for future purchases.

Erlang vs. Haskell

2010-06-17T19:32:00.000-07:00

Well, I'm on the Erlang train, now. It's really hard to resist some of the platform's features; in particular:

The dead-simple threading and message passing
The syntactic sugar for binary matching
The VM, which provides support for dynamically modifying code at runtime
All of the support for supervisors, which provides massive reliability with minimal effort

What I don't like is the syntax. Erlang is a horrible, horrible language when it comes to syntax. It's verbose, and awkward, especially when coming from a language like Haskell. Take, for example, the following code, which finds the longest prefix that is also a suffix in a string (where prefix is defined as any sequence of characters including the first but excluding the last, and suffix as any sequence of characters including the last but excluding the first)

import List as D
longest arry = head $ D.sortBy (\x y -> compare (length y) (length x)) (matches arry)
matches x@(a:as) = D.intersect (substrs x) (map reverse (substrs (reverse as)))
where substrs xs = [ take n xs | n <- [1..length xs]]

Pretty simple, eh? Here's the exact same algorithm in Erlang:

-module(presuf).

-export([longest/1, max/1]).

max(Arry) -> length(longest(Arry)).

longest(Arry) -> head(lists:sort(fun(A,B) -> length(A) > length(B) end, matches(Arry))).

head([H|_]) -> H;

head([]) -> [].

matches(Xs) ->

Pres = substrs(1,Xs),

Sufs = lists:map( fun lists:reverse/1, substrs( 1, lists:reverse(Xs) ) ),

sets:to_list( sets:intersection( sets:from_list(Pres), sets:from_list(Sufs) ) ).

substrs( N, Xs ) when N < length(Xs) -> [lists:sublist( Xs, N )|substrs(N+1, Xs)];

substrs( _, _ ) -> [].

Pretty ugly. Despite this, the other platform features are, as I've said, irresistible, so I'm trying to wrap my head around the stupid syntax, crossing my fingers, and hoping for the best.

My Adventure with OSX

2010-04-06T05:13:00.000-07:00

I recently bought a Mac. I've had it now for a couple of months, and my opinions about it have stabilized enough for an essay on the topic. The summary: it was a mistake.

It isn't my first Mac. I've owned, used, and programmed on several different OSes in my life: Apple ][s, MVS, Amiga OS, NeXTSTEP, Windows, MacOS 9, and Linux.

Now, the Apple ][ OS was outstanding for the fact that, with a little experience, you could fully understand all parts of the system. DOS sucked, and still does. Amiga OS was OK, but while I used it for several years, it didn't have any particularly outstanding characteristics -- the thing that made the Amiga great was that it was really the first microcomputer to have every subcomponent as a separate processor. It had a CPU, a GPU, and sound chip... that's pretty common today, but Amiga pioneered that.

NeXTSTEP was the first truly great OS. It was what OSX tries to be: cohesive, integrated, simple, and powerful. Programming in NeXTSTEP was a joy. It clearly separated the view from the model/control through a drag/drop GUI builder that built resources, which you then loaded and hooked in to. Again, this (to my knowledge) was has generally been ignored by other technologies (Java, in particular, although Gnome does this right, and yes, I'm aware one's a language and the other's a GUI toolkit. Java is inseparable from its own GUI toolkit, though, and a platform as much as NeXTSTEP was, so I think it's a fair comparison). Steve Jobs killed NeXTSTEP through incompetent marketting -- he focused entirely on the business market and ignored the personal computer market, and if Steve had been less dense, NeXT could have killed Windows right then and there -- it was that much better.

For the past thirteen years, we've been a Linux house. For the past ten years, we've been a laptop house; both my wife and I use Linux -- for most of that time, running KDE. However, I've become increasingly pissed off with Linux. In the past two or three years, the kernel has been unstable and unreliable. Every release of Ubuntu should be called "Rampant Regressions," and even the Gentoo server (my old tower desktop, now full of disk and server processes) is a pain to upgrade because of a lack of clear migration paths for so much of the software that's running on it -- although, I don't have any problems with stability of the overall system. KDE4 was a nightmare -- if ever a piece of software should have been witheld for quality control, it was KDE4. It was so bad, we had switched to Gnome, which deserves its own rant, but at least it was stable.

I'd been looking for a new laptop to replace my aged TC4200, and was about to buy an Acer Timeline to match my wife's, which I got her for Christmas and which has been an outstanding little computer. However, I was seduced by the siren call of the MacBook Pro, which is an extremely attractive package. I went for the 15", and that was my first mistake.

The 15" MacBook Pro doesn't fit in anything. Tumi doesn't make much that it'll fit into (and I only buy Tumi), and while thin, it is simply too cumbersome to carry around. I'd probably have been happier with a 13", but the 15" was definitely a mistake. Comparatively, my wife's 14" Acer Aspire Timeline 4810T has a slightly smaller screen, but it fits in everything and is noticeably more portable.

There are several nice things about the MacBook:

It starts up really quickly. That login prompt is there in a dozen seconds; Linux can take up to a minute to start.
It resumes from a sleep super fast. I mean, super fast. Like, suspiciously fast. Like, moving your mouse to un-blank your screen fast.
I've never had a problem with the wifi. Computer wakes up, computer connects to the internet.
The hardware itself is pretty. I like the backlit keyboard, and the control keys for brightness, media control, and so on all work.
It is pretty dead-quiet, and doesn't get very hot.
I like some of the software on it. iBank is pretty nice, and it is a relief to finally have software support for some hardware, such as the Logitech Harmony remotes.

I have had quite a few problems with it, though:

The first laptop I got had a busted DVD-ROM. The Apple store replaced it, but I got the distinct impression that had my laptop been more than a day or two old, they'd have given me more trouble about it.
I've had the video camera lock up, such that the cam software isn't able to acquire an image. The only fix for this is a reboot.
I've had the bluetooth stop working, and the only fix for this is to reboot. I mean, seriously: reboot?? What is this, Windows?
I hate the OSX key bindings. Who the hell at Apple decided to ignore the defacto standards and change the bindings? CTRL-C/V/X doesn't copy/paste/cut -- no, you have to use Apple-C/V/X keys. Want to select a work in your editor with the keyboard? Is it CTRL-Shift-LeftArrow? No, no... that'd be too standard. On an Apple, it's Option-Shift-LeftArrow. What we need is a YouTube video of somebody repeatedly kicking the idiot who made the decision to have the OSX key bindings be different from every other fucking OS in the world in the nuts. Repeatedly. For an hour.
The mouse pad is stupid. Apple really needs to stop being idiots and finally put a second mouse button on their mouse pad. Seriously. Having to CTRL-Click to get the secondary functions is user-hostile, not user-friendly, you idiots.
There's no focus-follows-mouse. That's the second-most stupid thing about OSX (right after the key bindings).
All of the photo-editing software is expensive. Actually, all software for OSX is expensive, and I don't see much that's better than the free software equivalents on Linux. I don't think that Aperture is any easier to use than Bibble, and actually feels less powerful (and Bibble is available on Linux, too). It's better for managing photos than the Gimp, but Gimp is more powerful. And if you start looking at the Photoshop line of software, you're looking at serious money.

The battery life isn't quite as advertised. In fact, I get significantly less, and it isn't like I'm doing anything more than just browsing the web, most of the time.

The MacBook is nice hardware, although, as I've said, the 15" is awkward, and was a mistake. The 13" might have been OK. But, for less than half the price, you could get an Acer Timeline (or any of a number of similar laptops available today), with similar battery life, as good a screen, as much memory, albeit less CPU (most laptops this use scaled down CPUs; the MacBook has a pretty hefty one).

I won't be buying another Mac; in fact, I may be installing Linux on this one. At this point, I don't think OSX really offers any advantage -- and has several disadvantages -- to Linux. I don't think it is any easier to use, although it may be easier to maintain.

Apple is doing well, but I suspect that it's because they're successfully pulling off what Microsoft got away with in the 80's and 90's: they're suckering people into buying overly expensive products that are actually technically inferior to less-well-advertised alternatives. And I've been one of those suckers.

Fool me once, shame on me. You won't fool me twice, Apple.

Dear Google: Stop Reminding Me About Chrome

2010-03-29T04:33:00.000-07:00

I get these pop-ups on Google's web search page telling me to install Chrome (when I'm not using Chrome), because it's a faster way to search the web. Do you get them?

Well, dear Google, the reason why I'm not using Chrome at the moment is because your browser doesn't support Java on OSX, and there are several web sites that I use that rely on Java. Like it or not, Java is a standard; there are a lot of things you can't do with Javascript, and IMO, Java is a lesser evil when compared with the alternative of ActiveX. I'd have thought that that smart people like you would have had reservations about recommending a browser that lacks support for some pretty basic web technology in such a public manner.

Sincerely,

Somebody Who Wants To Use Chrome, But Can't.

Canonical's Misrepresentation of Support (Ubuntu)

2010-03-13T07:51:00.000-08:00

I've noticed something disturbing about the Ubuntu distribution. Mind you, Ubuntu is free software, so I don't expect much from it. However, I find this behavior disturbing. I'd prefer if they simply didn't pretend to offer support, rather than what they do do, which is waste everybody's time.

Here's an example, and here's how it goes:

User reports a bug. Often, user spends a lot of time actually looking into the problem, and provides dmesg dumps, lspci dumps, and so on.
Ubuntu team responds that this still isn't enough information, and requests increasingly obscure data
User provides the data. In the meantime, several other people post to the same bug, reporting the same behavior, and provide their own, additional, data
Ubuntu team recommends upgrading to some unsupported, alpha release, despite the fact that the bug was reported against an LTS (Long Term Support == "Stable") release, and the alpha release page includes warnings about not using it in a production environment
User is unwilling to upgrade to an unstable release
Ubuntu team closes the bug as invalid due to "not enough information."

Basically, the tactic is to make unreasonable demands of the bug submitter, and then close the bug by insinuating that the user is either (a) hallucinating, or (b) lazy and stupid. Look through the Ubuntu bug submissions, and a fair percentage of them follow this pattern. My own personal experience is that about 80% of Ubuntu bugs are handled this way (and, usually, I'm not the original submitter, but somebody who's experiencing the bug and has put it on their "watch" list). Very, very few bugs are actually closed with a satisfactory resolution by the submitter.

Back to my original comment: nobody buys Ubuntu. It's free, and it's stupid and selfish to get mad when you don't get support for something that's free. However, it's also stupid, and insensitive as well, to pretend to provide support when, really, you're just jacking off and wasting people's time.

I Give Up. I'm Buying A Mac

2010-03-03T18:20:00.000-08:00

I can't resist any longer. I'm going to give OSX a chance to piss me off for a while now.

It actually isn't my first Mac. At one time, I owned three Mac clones, running OS9. Boy, that sucked. I ended up with them mostly by accident; I bought one, and then got two given to me over the next year by people who hated OS9 as much as I did, but had more good sense to get rid of it much sooner.

Anyhoo, I can't resist the seductive siren call of the Macbook Pros. 15" screens, 0.9" thick, and 7 hours of battery life? Sign me up. If I really loath OSX, I can always use BootCamp to install Linux on it, although OSX would have to suck quite a bit to make up for the amount that Linux is annoying me right now.

Oh, and the 7 hour battery life is no joke. AnandTech did some tests on how long the 15" version runs, and they came up with 8 hours with light use: screen on 50%, loading web pages every 20s (so wireless was on), and playing MP3s the whole time. That's pretty damned impressive.

Plus, if I actually go insane and buy an Eigenharp, I have to have a Mac... they don't support anything else.

I know, I know; Apple is as evil, if not more, than Microsoft, but at least they don't also make shitty products, which Microsoft does do.

And there's my P.S.: I finally found a company that consistently makes worse products than Microsoft. A company that churns out steaming piles of stinky code more reliably than the Big Disease: Rational. I'm serious; I have yet to encounter a software product from Rational that wasn't indistinguishable from vomit. It's poorly designed, even more poorly implemented, and if it were free, it'd be overpriced. It makes me really nervous when people who supposedly are software experts -- because they do it for a living -- think that anything that comes from Rational is worth the CPU cycles, much less actual money. At least Microsoft has Excel, which isn't too bad. Rational just has overpriced consultants who, by the way, can't actually solve any of your problems.

Sweeteners

2010-02-13T05:56:00.000-08:00

We've been on the South Beach diet for nearly four weeks now, and it's working. Painfully slowly, but the scale is trending steadily downwards. We've both lost 16 lbs so far, and it hasn't sucked too much. Most of the time, we're not starving.

One note on the book: I know that they do it because it's "motivational," but I find the case studies in the book to be ludicrous. They're all, "I don't even look at ice cream in the store anymore." Yeah, that's technically true, but it's misleading; you don't look, because it's so fucking painful to not be able to have that stuff. Chips isle? Big no-no. I come out the other end crying. Bakery? I hear their voices, in my head, even from home.

By far the worst, though, is the beer. Beer, to the South Beach dieter, is Satan. Apparently, if you even look at beer, you'll gain weight. The theory is sound: beer is 100% carbs, with nothing redeeming in it to stop your body from turning it directly into fat. Personally, I think they're ignoring the fact that beer, like a person, also contains a soul, which is not measurable and is the source of everything good and right in the world. The inability to drink beer on this diet causes me actual, physical, pain. You know Munch's The Scream? That's me.

Anyway, to the point of this post: sugar substitutes. We've been through most of them over the past month, and I'm here to tell you: nothing is as good as sugar. Anybody who tells you that there is something as good as sugar is delusional (and you have to be, a little bit, to make diets like this bearable). Rather than lie to yourself, have a little backbone, and man up. Nothing is as good as sugar, but we did find something that's pretty darn close. I haven't found any substitute for honey, which means that I don't drink tea any more. That's sad, but compared to the other inconveniences of this diet (no baguette ), it ranks pretty far down on my complaints.

Stevia. Ok, I really don't see how anybody can count this as a "sweetener." The fact that it has a sweet-like taste is overwhelmed by the fact that it is also overwhelmingly nasty.
Splenda. I actually don't mind Splenda. It doesn't fool me, but it's an adequate substitute in a pinch. Monika really dislikes it, though, and claims that it has that oddly common "sugar substitute taste." I don't notice the aftertaste too much.
Agave. Ok, now, I could see how eating an Agave plant might be interesting, but as a sugar substitute... yuck. It doesn't have the aftertaste, but it certainly has it's own peculiar quality that completely distracts from whatever it is that you're trying to sweeten. I mean, when I eat or drink something sweetened with Agave, what I taste is Agave. Cookies taste like Agave. Coffee tastes like Agave juice. If you like eating Agave, then this is probably fine, but in my opinion, it defeats the purpose of the thing.
Aspartame. Yeah, this is the reason why there are so many other alternative sugar substitutes. It tastes like you're sweetening your food with cancer. I just can't get past the industrial taste.
Swerve. And now we come to the pay-out. This is an amazing product. The only problem with it is that it is outrageously expensive, and you can get it from only one source.

I discovered Swerve in the first week of the diet, while desperately looking for something that we could sweeten the South Beach desert recipes with (they only call for "sugar substitute" in the recipes) that we could stand. This stuff is, frankly, amazing. Like most sugar substitutes, the sweet taste hits your tongue at different places than sugar, but there's no real aftertaste to speak of. The oddest part of this sweetener is that it has an ethereal quality, almost like a smell of sweet, that lingers. It is hard to explain; however, even if we weren't on the South Beach diet, I could easily replace sugar with Swerve in my diet, and thereby reduce my daily glycemic index significantly... except for the price.

As I mentioned before, the only downside to this product is the cost. A pound is $17. Seventeen dollars. A five pound bag of sugar is, like, $2.50. That makes this Swerve about 35 times as expensive as sugar. And since one of Swerve's claims to fame is that it is a 1-to-1 substitute for sugar (1tbsp Swerve = 1tbsp sugar), that's pretty horrible. I tell you now, Swerve: those prices aren't sustainable. As we near our weight goals, we're going to re-introduce sugar, not because you're not good enough, but because you're so damned expensive.

I won't do too much of a sell-job on Swerve. I'm pretty much a convert, though, and highly recommend to anybody wanting to reduce the number of carbs they're intaking to give it a try. I'm guessing that cutting sugar out of your diet would make a pretty significant dent in your weight gain, or give a boost to your weight loss, or if you're hypoglycemic, or diabetic, or any of a number of other reasons.

As long as you can afford it.

The Intersection of Distributed Bug Trackers and End Users

2010-01-31T10:09:00.000-08:00

Lately (the past year or so) I've been using a tool called Ditz to manage my software issues. Ditz is a distributed issue tracking system; it stores issues locally in a format that is easy for version control systems to efficiently track. There are some interesting theories about these sorts of trackers (of which Ditz is but one); for one thing, issues can be branched and merged, which means that each branch can have a different state for the same issue -- a feature that most issue trackers lack. But it is also much easier for developers to use; there's no network traffic, so it can be used offline, and much more quickly than an online tracker. And you don't have to use a web interface.

However, these offline trackers have a disadvantage: they're offline. Ditz comes with a web interface, but it is static. There's a dynamic interface (called Sheila), but it's a pain to set up and doesn't have a lot of features. This makes it difficult to elicit bug reports from users.

On the other hand, you have Trac (and Redmine) which are outstanding issue trackers. Their only limitation is that they're entirely online, and I find them awkward -- as a developer -- to use.

So, I wrote a Ditz plugin, called ditz-trac, to sync Ditz with Trac. Admit it... you're awed by my creative naming scheme. In any case, it works fairly well, but the experience left me with some reservations, and ruminations.

I'm considering whether some sort of direct offline Trac tool might be lower cost for me. I like ditz just fine, but I'm not sure that I need my issue tracker to be version controllable -- I just need it to be off-line-able, and have a separate DB per project. The version-controllable nature of Ditz is inspiring, but I haven't used it yet (I don't branch a lot), and most projects get by without the feature. In fact, I'm increasingly convinced from what I've seen that software developers have no more -- and possibly less -- than a 50% stake in issue management; users have the other solid 50%. As for ease-of-use, ditz-like trackers have a split more like 95/5; web-based trackers split it more 80/20. The more I think about it, the more I believe that a solid web tracker which can be used off-line and sync'ed is the ideal design.

My experience with ditz-trac has shown me that the XMLRPC interface to Trac simply isn't sufficient for a robust off-line sync'ing. It imposes too many limitations on the event log. What I really need is direct write access to the Trac DB, so that I can manage the events with finer resolution. If I go down that path, though, then one wonders whether it might not be better to simply copy the sqlite DB, rather than trying to shoe-horn the two differing schemas (Trac/ditz) together.

I'm not sure what the best solution is, here. The branch-ability of Ditz creates obstacles for synchronization, and there are always going to be troubles while the web tracker doesn't support the concept of hash IDs (all that I've seen rely on sequential integer DB IDs, which play hell with implementing writeable clones). To really get a good sync solution, I'd have to modify the Trac or Redmine DB, and now the solution becomes more complex and difficult for users to install.

I need to think about this some more, obviously.

Gobo is made of Fail

2009-12-31T09:15:00.000-08:00

I spent a day messing with Gobo, and X is still messed up. Plus, Gobo seems to have even worse problems figuring out dependencies than other distros. Here's my experience, in a nutshell:

Look for some commo package using FindPackage (ssh, Xorg, etc). Wait while, every single time, it tries to sync with some server (caching is, obviously, broken).
Be unable to tell whether the package is a available as a binary, but at least we have a name.
Try to install some common package (InstallPackage). After another annoyingly long wait, InstallPackage fails to find a binary.
Compile the recipe from FindPackage.
The config stage, invariably, fails because it can't find some dependency.
Repeat from (1) for the dependency.
When finished recursing for the dependency missing in (5), try to compile the original package again.
Compile will fail, again, because -- for some unfathomable reason -- Gobo is too stupid to add the package you just installed to the pkgconfig chain.
Manually set PKG_CONFIG_PATH and try to compile again.
Repeat from (5), failing on some other dependency
And, remember, at every step, baby the process along because the Gobo tools are extremely interactive, and will always require at least one human query/response.

This is worse, even, than RPM, where at least you didn't have to go through the entire autobuild process to discover the recursive dependencies.

This renders Gobo entirely useless. I finally gave up when xorg-server needed specific versions of other packages that, apparently, weren't installed. I'm not even sure where it was getting the wrong versions of the packages. Furthermore, xrandr was utterly useless, having either been compiled without most of the functionality, or being some ancient version that didn't have the options. I'm not sure which is the case. I had been working with Gobo 014, which was supposed to be the most current, but the version of xrandr that was installed was some three-year-old 1.1 version which was unable to detect my external monitor correctly (xrandr 1.2, which has been out for a couple of years, has no such problem).

Other niggles:

SSH isn't installed off the CD. WTF?
X doesn't work with the install off the CD.
There are almost no binary packages. Everything is built through Compile, which is too stupid to resolve dependencies by itself (yah, this is my main complaint)
Half of the default mirrors are broken, or down. It is extremely common to wait while Gobo tries to contact two or three mirrors and times out before finding a useful mirror. This makes all Compiles even more painfully slow.
The recipes, apparently, don't refer to cached tarballs, and I encountered several recipes that referred to tarballs on third party servers which simply didn't exist any more. For example, the unionfs recipe is utterly broken. Which is exceptionally annoying as InstallPackage keeps complaining about unionfs not being available -- and you can't install it because of the missing tarball: catch-22.
The Gobo folk are focusing on the wrong thing. All of the emphasis is on the new filesystem layout. I don't object to the layout; it is an interesting experiment. But the real innovation is a package manager which can have multiple versions of software installed on the same system. If it worked, which it doesn't.

So, sadly, I'm downloading Ubuntu 9.10, because as much as it sucks, as flaky as new releases are, as many regressions as every upgrade introduces... at least you can get a working Xorg out of it.

sup... again!

2009-12-29T05:46:00.000-08:00

Argh! Aaaaargh!

So, I'm totally addicted to the gmail mail management workflow. I admit it. I can't bring myself to use a traditional email client -- it is, simply, painful. So, yesterday, I was going to use sup again (despite it's critical flaws), only now sup-sync segfaults! I've tried everything, including deleting the .sup directory. There's no help from Google.

There's no other explanation: I've angered the software gods, and they're punishing me.

The sad state of operating systems (and Linux distributions)

2009-12-29T05:42:00.000-08:00

I spent several hours yesterday getting NixOS installed on a spare laptop. I've been toying with Nix for a couple of years; it is an elegant solution to a thorny problem that all operating systems face, and about which I've written before: dependency hell.

The problem, in a nutshell, is that all modern software is built upon other software. These are dependencies, and often, the software being depended upon isn't explicitly aware of the dependents. Certainly, when the authors of the dependees update their software, they're unable to test all of the dependents. Consequently, and perhaps inevitably, things break when software is upgraded.

Linux -- and software written for Linux -- is particularly susceptible to this. Debian's deb packager has done an admirable job getting around software dependencies; Redhat's RPM has not. Still, the frustrating thing for me has been the fact that none of these deal with two very common things:

Users may want to install multiple versions of the same application at the same time. Stable, and test. This is extremely common because distributions simply can't keep up with the pace of software development. There is always some piece of software that I need to upgrade that the Ubuntu package maintainers simply haven't gotten to yet, and may not get to for a while. I want Mercurial 1.2, and Ubuntu is still on 1.0. Or, worse, and more commonly, there's no back-port for it; I have to upgrade my entire system just to get newer software. Which leads to the second item:
Linux is horribly unstable. Ever since Linus made the decision to get rid of stable kernels, any kernel upgrade is as likely as not to cause something on my laptop to fail. Linux has the worst history of regressions of any software I've seen, and I've written a fair share of regressions myself. Quality control is almost non-existent. The CDROM stops working, or the sound stops working, or the damned graphics card stops working, or the network... something breaks, almost every time. What this means is that upgrading between versions of Ubuntu -- which always involves a major kernel upgrade -- is like playing Russian Roulette with five of the six chambers full. After it's aged a bit, any given version stabilizes. In the meantime, you're stuck with using year-old software releases, which -- in computer terms -- means that you're using obsolete and unsupported software most of the time.

Ubuntu is really bad about the latter point. Every single time I've upgraded to a new, major, release of Ubuntu, hardware that previously worked perfectly fails. Gentoo is, possibly, worse. I'm running that on a server and upgrade it rarely, and it is always a chore to get software working again after an upgrade. So, when I recently revived a laptop, I decided to try a different distribution, called NixOS.

NixOS gets around both of those issues with a clever approach which is simple in concept: build and install software in a sandbox and link to its dependencies using a view composed of specific versions. So, for example (and this is greatly simplified), Nix will build and install glibc-1.0 in its own directory and creates a view that contains glibc-1.0 as the "official" glibc. Software that depends on glibc version 1.0 is built in this view. Views can be composed of different versions of different software, so you may have a view that looks like this:

glibc-1.0
ghc-6.08
kde-3.5

and another view that looks like this:

glibc-1.5
ghc-6.08
kde-3.5

Any mix of compatible software can be installed, and you can switch your environment on the fly.

This is a very powerful concept; it lets you maintain multiple versions of software on a system, and it allows you to boot into different, major versions of the composite whole -- which is not possible in any other Linux distro, or any other OS that I'm aware of -- without depending on virtualization (which is hideously expensive). Ironically, this is the same approach that ClearCase -- that evil, poorly designed, poorly implemented, version control system -- uses. Only, here it makes sense, because the views are designed by the packagers, who know what the software dependencies are.

The problem with NixOS is that it doesn't work. It may be the nature of it's being a young distro with few adherents. It may be some flaw in the terribly complex system that implements the rather simple concepts. But something is wrong with it. For one thing, half of the software packages wouldn't install; half of the messages were "unable to download the source package", and the other half were compile errors in the packages. And when I did manage to finally get X installed, it wouldn't start, because X couldn't find the video drivers -- which were also installed.

So, NixOS has some pretty serious flaws, and isn't ready for even casual use. I'll never run Gentoo again, because I don't fancy spending all of my weekends doing system maintenance. For kicks, I tried booting the Haiku R1α1 CD; Haiku is pretty impressive for how quickly it boots, but unfortunately has no USB support, so it was a non-starter.

I'd love to run Minix, except that there's no virtual memory support. It is all pretty sad that, after -- what, thirty? Fourty? -- years of modern computing systems, operating systems still suck. The only one that didn't was NeXTSTEP, but Steve Jobs killed that off through mis-management and incompetence.

Right now, I'm re-installing Gobo from an old CD. Gobo is a sort of half-way attempt at what NixOS does, but stops just short of the views. This means that you get different versions of software, but not for the important pieces like libc. Which is pretty crucial, if you're concerned about regressions. But, we'll see; maybe newer versions of Gobo fix the problems I'd had with it before. At the moment, I'm pretty depressed about it all.

sup disenchantment

2009-12-15T07:32:00.000-08:00

Ugh. Harsh reality rears its ugly head.

It turns out that sup isn't as great as I thought it was. For one thing, it doesn't write state back to the server. Consequently, if you ever view your inbox with anything other than sup -- or, god forbid, with sup itself running on a different machine -- then all of the work you've been doing to delete, flag, thread, label, and read email messages is lost. sup only works from a single machine, and any state is known only by that sup instance.

The sup folks call this a "philosophy." I call it "stupidity of the highest order." Or, maybe, I should call it laziness; I'd bet money that the only motivation for this "philosophy" was a desire to avoid writing synchronization code. Sloppy, lazy programming, in other words.

So, I take it back. Stay well away from sup: it's malfunctional to the point of being broken. And cross your fingers that someone does something similar, only implemented correctly this time, because the workflow paradigm really is powerful.

Sup is an outstanding email client

2009-12-12T07:49:00.000-08:00

Sup is a console-based email client that provides GMail-like management of mail accounts. It supports mbox, IMAP, and Maildir, and I'm here to tell you: it rocks. Archiving, labeling, filtering, tagging... the workflow of mail management is almost identical to how you manage email in GMail. I'd been slowly deprecating my other mail accounts in favor of GMail, but this was primarily because no other mail client (on Linux) provides the same capabilities as GMail. The only thing I don't like about GMail is that it is a web client, and web clients, with very few exceptions, suck. Yes, even GMail.

It take a little setting up, but you you've got the smasos, I highly recommend giving it a try. If you have multiple email accounts, you can even aggregate them into a single buffer. This is very nice.

It does have a few issues:

It is entirely console-based. Don't get me wrong; this is a great -- even killer -- feature. And while I love the vim/mutt-inspired key bindings, this is simply unusable for somebody like my wife, who isn't interested in surmounting the learning curve needed just to get to her email. It'd be nice to have a GUI option.
It's a bit of a pain to set up. There are several dependencies which, my first time around, took a while to get installed. The gem helps -- but, as I've often argued, the Linux community does not need a package manager for every programming language (CPAN, gem, easy_install, cabal, et al.).
It crashes quite a bit when it is hooked up to MS Exchange.
The tab completion for the contacts is very flaky. I would almost say that it useless, except that I haven't quite figured out yet if the Exchange-crashing thing is interfering with buffer syncing -- more investigation is necessary, but it has been giving me trouble.

In any case, like I said: if you're not console-adverse, and you can manage to circumvent the installation issues, I highly recommend giving Sup a try. I really believe that the GMail workflow is the future of mail management; it's only a matter of time before the other mail clients (Thunderbird, claws-mail, KMail, Evolution) catch on.

NoSQL, and the Zone Of Pain

2009-11-12T05:13:00.000-08:00

You can do some incredible things with SQL. It's a very full and complex language, and relational databases are venerable and well-tuned. There's a movement called NoSQL which argues that relational databases aren't appropriate for all problem domains, and that other database paradigms should be considered in any problem.

NoSQL focuses on key/value databases -- not strictly; you get graph dbs and even XPath query DBs, but most of these "distributed" DBs boil down to key/value DBs -- since that's what most of the proponents are. I haven't yet encountered a NoSQL advocate who recomments an OODB, for instance. They're all about Hadoop, Riak, CouchDB, HBase, and BigTable (although, there are more). I suspect that this is because Google gave these DBs a lot of credence when it was exposed that they weren't storing their data in a SQL database. OODBs never had such a persuasive validation, and consequently are much more rare.

Non-relational DBs appeal to me. For one thing, they are schema-less. Relational DBs are in the "zone of pain" -- this is the zone of things upon which there are lots of dependencies, and yet are concrete objects (and so require changes as software is developed). Things which have a lot of dependencies are very costly to change, which is why you want as many of these objects as possible to be abstract (interfaces) -- but DBs are concrete, which means that they will change as the software grows. The alternative is that software developers tie themselves into knots, and implement all sorts of shady coding, to avoid changing the DB schema. If you dispense with the schema, then the DB is no longer difficult to change -- because there is nothing to change. It takes DBs out of the zone of pain.

For a second thing, SQL is usually overkill. And, when it isn't, the schema is usually so baroque that nobody understands it. I worked on a project at the US Forest Service where the schema diagram, printed, was 15 feet long and 4 feet high, and printed in a barely readable font. It was utterly unnavigable. I don't know if one of the NoSQL databases would have been a better fit in that case, but I'd have liked to have found out. Except, there wasn't a NoSQL movement back then.

In any case, I found the following reading interesting:

Strange dreams

2009-11-08T03:45:00.000-08:00

In my dream, Brett and Marnie (my siblings-in-law, above) came by, and they both had flawless skin from the California sun. Marnie had gotten plastic surgery, and was telling us about how disgusting it was, and about how she woke up in the middle of it and had to have more sedative administered. She now looked like Claire Danes. Both of their hair was lighter -- Marie is already blonde, but Brett's a brunette, so now he was sort of brown with blonde highlights.

Reflecting on the dream, it seems pretty obvious that it was driven by my feelings about Brett's new position, and about how quickly they are (financially) out-distancing the rest of us. Financial success was translated into physical perfection. Which is funny, because I never used to care much about money, and even now, I can't work up much enthusiasm for it.

Anyway, that's the dream for today. The one I can remember, anyway.

Quality is not optional

2009-09-25T10:09:00.000-07:00

I keep seeing this "good enough" meme going around. At a company meeting where I work, recently, management was espousing the same crap.

I can only hope that these people are plagued with "50%-good" products. How about some 50%-good tires on their cars? Maybe they'd like some 50%-good surgery, or a 50%-good pacemaker. How about getting to fly in 50% good airplanes for the rest of his life? I know! Let's give their kids some "good enough" education!

I'm not surprised that most of this bullshit is coming out of a culture in which Walmart was able to become the success it has. Recently, we needed something for a weekend project and bought it from Walmart, because it was closest store. What poor quality crap. It'll all need to be replaced in a year, contributing to landfill and wasted resources. I'm not going purchase from Walmart any more, and I'm not going to spend money on half-baked, crap-quality software, either.

Word gets around about quality. It's the American auto-maker's nightmare right now. Ford, Chrystler, Chevrolet... they're all struggling to reverse decades of built-up public perception about poor quality, even when some of them are actually making fairly decent cars right now. It isn't quite the same with software; Microsoft has been making crap software for, well, ever, and they're still dominant. But I think that if you take the monopoly factor out of it, software companies do suffer from delivering half-assed product to their customers.

More on VCS, branching, merging, etc.

2009-09-15T06:27:00.000-07:00

Martin Fowler has posted a good discussion about the various flavors of processes to manage branching and merging. There's a lot of good information in there. His conclusion is that cherry picking with the VCS is undesirable, that cherry picking should be done in software, and that continuous integration is the preferred process. It's a good read (with pretty diagrams), although I don't agree with his conclusion.

In particular, he ignores the fact that some categories of changes can not be continuously integrated. For example, systemic architecture changes are one category which often can not be continuously integrated. Also, the examples provided by Martin entirely ignore parallel branches (in the feature-set sense, rather than the VCS sense) of the software, and/or long-lived support for releases. Of course, these are exceptions, and nothing in Martin's suggestion prevents the use of cherry picking to solve these cases.

Martin's suggestion is that it is better to do cherry-picking in the software through configuration, or licensing, or whatever, than to do it via the VCS. I don't believe that these approaches are mutually exclusive. You can have a modular architecture and VCS-controlled cherry picking at the same time, and I'd argue that this is where the DVCS niche lies. With a truly modular software architecture, you should be able to cherry-pick features from multiple development branches, on demand; the very nature of the modular architecture will ensure that conflicts are minimized. Furthermore, by the time you've invested the effort for a modular architecture, you don't need software-controlled plug-ins; in effect, you've forced yourself to isolate and compartmentalize feature sets, which is what you need to do to reduce merge conflicts.

So, a modular architecture is just a generalization of good loose coupling of software components. There's nothing inherent in this that requires a plug-in architecture or any other sort of software-driven cherry-picking. Once you have a modular architecture, you don't need continuous integration, in the sense that Martin suggests.

Martin proposes that incomplete features can be "hidden" by simply hiding the UI that drives the features. This is often not possible, if the features are woven into the business logic of the tool -- as is often the case where changes are made to existing features. The thing that bothers me the most is the concept of delivering half-baked, functionally untested code; it increases the opportunity for bugs, and eliminates the possibility of dropping features entirely. If a company develops feature A and then, at some point, decides to never deliver feature A (maybe the market has changed, perhaps some disruptive technology has rendered feature A obsolete), and that company has been doing continuous integration, then that feature is irrevocably interwoven into to the code base with numerous merges. The company is now in a position to spend significant resources un-weaving the feature, or be forced to deliver zombie code in their product. Again, this is solvable by sufficient isolation of the feature, but if you have that level of isolation, then why do you need continuous integration in the first place?

Cherry picking with the VCS can be powerful, and continuous integration should be used only where necessary. The key is that software absolutely must have a good, modular design, and if at all possible, architectural and interface changes should be continuously integrated. With VCS based cherry picking, organizations have the opportunity to decide to cut bait on a feature, and the overall code quality of released products will improve by the very fact that they don't contain hidden, unused, and un-functionally-tested code.

Multitasking and Software Development

2009-09-14T05:26:00.001-07:00

Three articles that I came upon recently seem related, although they stem from unconnected sources. The first is the Stanford study which shows that multitaskers not only don't do individual tasks very well but actually multitask more poorly than non-multitaskers do, and that they don't realize it, either. The second is a very well-written article by Paul Graham about the difference between Maker's and Manager's schedules. Of course, both provide examples of the Dunning-Kruger effect.

It's something that's been bothering me a lot lately, because I'm beginning to suffer from effects of the first two, and I'm afraid that it will lead to the third. In my job, I've increasingly been forced to multitask as my job duties have been changing. This is learned behavior, in my case at least, due to Manager's Meeting schedules, interruptions, the need to respond timely to email, and having to juggle multiple responsibilities. This has had a very definite affect on my programming ability. I'm not sure what I'm going to do about this, yet, but it has me concerned.

GNU Make

2009-07-18T05:53:00.000-07:00

Ok. How do you get make to conditionally include a file, based on the calling arguments? I'm not sure that this can be done, but I'd love to be proven otherwise.

I have a make file that builds a third party sub-project if it hasn't been built. It does this by including the sub-project's make file. The problem is that if the make file doesn't exist, a rule gets triggered to create it, which is a laborious process involving untarring a huge tarball and running through a sort of autobuild. The issue is that any target will trigger this, because of the "include" rule. This looks sort of like this:

... blah blah make rules
include subproject/makefile

subproject/makefile:
ReallyExpensiveAutocfgChain

clean:
rm subproject/makefile
.... blah blah other clean tasks

So, if you "make clean", and the project is already clean, the include triggers the create makefile rule, which then takes two or three minutes to create the makefile... so that it can be immediately deleted.

What I can't figure out is how to get make to conditionally include the file, or conditionally execute the make file creation rule, such that if "clean" is being resolved, it doesn't include the make file. I suspect that it has to do with some combination of $^ and the if clause, but I'm not yet sure if those auto-variables are set at the top level. Anyway, I'm still exploring.

Mercurial Rebase

2009-07-15T04:06:00.000-07:00

I read Martin Fowler's entry on using mqueues in Mercurial to squash a series of commits into a single commit, and while the post is informative, there's an easier way: the Mercurial rebase command.

The rebase extension has been included in Mercurial since 1.3, although it's been available since sometime in the 1.2 release, and can perform a number of useful alterations of a repository. For Martin's use case, his 5-step mqueue sequence is accomplished with two much more simple commands:

hg tag "Pre-rebase"
hg rebase -s --collapse

The tag is necessary because the rebase command will not operate on descendants or ancestor, and will not automatically create a new tip to hold the rebase. It'd be nice to be able to dispense with the tag, and it isn't necessary if you're (for example) rebasing from a branch onto another branch which already has other changes -- the key point here is that you need to have a different tip that you're rebasing onto which isn't either an ancestor or descendant of the branch that you're rebasing.

Here's a simple use case. First, I'll set up the repository:

Script started on Wed 15 Jul 2009 07:25:27 AM EDT
% mkdir squash
% cd squash
% hg init
% echo AAA > A
% echo BBB > B
% echo CCC > C
% echo DDD > D
% hg addremove
adding A
adding B
adding C
adding D
% hg ci -m 1
% hg mv A M
% hg ci -m 2
% hg mv B N
% hg ci -m 3
% hg mv C O
% hg ci -m 4
% hg mv D P
% hg ci -m 5
% hg glog
@ changeset: 4:347a96580b84
| tag: tip
| user: Sean Russell
| date: Wed Jul 15 07:26:40 2009 -0400
| summary: 5
|
o changeset: 3:e1e2c4e27fcf
| user: Sean Russell
| date: Wed Jul 15 07:26:34 2009 -0400
| summary: 4
|
o changeset: 2:47b3a7f41d78
| user: Sean Russell
| date: Wed Jul 15 07:26:28 2009 -0400
| summary: 3
|
o changeset: 1:e0879f674e71
| user: Sean Russell
| date: Wed Jul 15 07:26:24 2009 -0400
| summary: 2
|
o changeset: 0:2902dfa1725a
user: Sean Russell
date: Wed Jul 15 07:26:12 2009 -0400
summary: 1

Here's the actual rebase. First, switch to the revision that you want to rebase onto, then create a tag to create a new tip, then perform the rebase. In this example, I want to collapse revisions 1-4, so I switch to revision 0:

% hg up 0
4 files updated, 0 files merged, 4 files removed, 0 files unresolved
% hg tag Pre-collapse
% hg rebase -s 1 --collapse
saving bundle to /home/ser/squash/.hg/strip-backup/e0879f674e71-temp
adding branch
adding changesets
adding manifests
adding file changes
added 2 changesets with 5 changes to 5 files
rebase completed
% hg glog
@ changeset: 2:3420d5add3eb
| tag: tip
| user: Sean Russell
| date: Wed Jul 15 07:26:40 2009 -0400
| summary: Collapsed revision
|
o changeset: 1:a98523a2e8f9
| user: Sean Russell
| date: Wed Jul 15 07:26:50 2009 -0400
| summary: Added tag Pre-collapse for changeset 2902dfa1725a
|
o changeset: 0:2902dfa1725a
tag: Pre-collapse
user: Sean Russell
date: Wed Jul 15 07:26:12 2009 -0400
summary: 1

% exit

Script done on Wed 15 Jul 2009 07:27:04 AM EDT

The rebase command is quite useful, and the rebase page gives examples of a number of use cases. For cases like this, it's much easier than using the raw mqueue operations upon which it is based.

Why not to use Subversion

2009-04-05T13:36:00.001-07:00

I'm a big Subversion fan, and have been since it was first released. Or, I was, until recently, when I discovered that Subversion is fundamentally broken.
Some background: I've been using Subversion since 2000, when a project I was working on for the Forest Service chose to convert a CVS repository to it. Since then, I've been running a Subversion server that's been hosting a number of open source projects I work on, as well as having provided hosting service for a couple of projects that I don't work on. By and large, Subversion has been adequate, and stable enough, and I've been able to work my way out of any DB wedges or failed upgrades that I've gotten myself into. I've never used it on a large-scale, multi-user, multi-branch project, but I've taken comfort from the fact that projects such as KDE do use SVN.
Recently, however, I've been using Subversion at work. We switched to SVN from CVS (there's a whole story behind that) while at the same time the rest of the company was consolidating on ClearCase. I'm not going to go into why Subversion is superior to ClearCase; I'm still convinced that it is, and I strongly believe that you have to be insane to use ClearCase in the Enterprise. But now I think that while ClearCase should be avoided like the plague, I also believe that Subversion shouldn't be used, either.
The reason for this is because Subversion's merging mechanism is fundamentally, structurally, and architecturally broken. Subversion simply does not perform merges correctly.

Subversion's --reintegrate is useless if you use any sort of cherry-picking. Since I've never encountered a situation where cherry-picking wasn't leveraged at some point or other, --reintegrate is always useless.
Subversion performs merges changeset by changeset, which means that you will always perform more conflict resolution than you need to.
Subversion gets very confused, very easily, about tree merges. This is mostly because of (2).

As an illustration of how ... well, no other adjective really captures the scale of the issue, so forgive me ... of how fucked up (2) is, consider a series of changes from A to P on branch 1, and a similar -- yet unrelated -- series of changes from A to P on branch 2. Now merge branch 2 into branch 1. Despite the fact that P is the same on both branches, due to the fact that Subversion merges incrementally, that means that you're going to end up resolving a lot of conflicts that -- ultimately -- are entirely unnecessary.
While you're considering this, also consider how other version control systems, such as Mercurial, Bazarr, and Git, do not have this problem.
Finally, Subversion's whole merge-tracking mechanism is really buggy, which makes it a pain in the ass to use. And I don't mean "buggy in the edge cases," I mean "buggy in that you're always going to hit this bug in any non-trivial merge." There are work-arounds for the bugs, usually, but you only get to these work-arounds after running into one of the bugs, spending some time finding what the work-around is, and then re-starting your merge. You can spend hours running around in circles, hitting a bug, finding a work-around, restarting your merge, resolving conflicts, hitting a bug, finding a work-around, restarting your merge, resolving the same conflicts, getting a little further, hitting another bug, and so on. Hours.
So, I'm ditching Subversion. It just isn't worth it any more, when there are better revision control systems out there that do handle merging properly, and have other advantages such as distributability. If you never want to merge branches, then SVN is fine... but if you're doing only single-developer development (which is about the only place you're likely to entirely avoid branching and merging), then there are other reasons why you should consider a DVCS, anyway. Mercurial, Bazaar, and Git are easier to set up, transport, and share with untrusted peers. They're less effort to maintain -- admittedly, only by a tiny bit; I've never found SVN to take much administration, except in the bad-old BDB days. And they do merging correctly. Plus, most of them have nice features (sometimes as plug-ins), like block-level commits, cherry picking that doesn't break their versions of re-integrate (grumble), flexible rebasing, nice graphical views of the merge history (which can be really useful), patch queue/shelving support, integrated bisecting, and so on. And, usually, a workspace with full history often consumes not significantly more than a single SVN check-out. A Mercurial repository conversion (full history) of my work SVN repository consumes .99 GB, versus a single checked-out workspace in SVN at .3GB. Two SVN check-outs take up .6GB; two HG check-outs (using hg clone) consumes 1.12G. Three SVN, .9GB. Three HG, 1.26. You can see where this is going. And this is an unusual repository, with a large number of binaries stored in the repository.
When I use Mercurial, I miss some Subversion features, such as cheap copies and branches. Some people hate it, but I love the fact that tags and branches in Subversion are merely COW links. It solves a lot of problems in a very elegant way. Mercurial has its own quirks -- they all do -- but at least merging isn't broken like it is in Subversion.
Postscript...
The original title of this was "Why Subversion shouldn't be used for the enterprise," but then I realized that there's no reason to use it at all. It would be a fine choice for the enterprise if its merging was done properly and wasn't full of bugs. The enterprise is really the only place where Subversion's feature set makes it superior to DVCSes, but the enterprise is the one place where merging really has to be as trouble-free and correct as possible.