Space Shuttle ade

A Blast From The Past: Shuttle Through The Decades from NPR on Vimeo.
While looking at the short NPR video over at Vimeo of the Space Shuttle's beginnings, it occurred to me - perhaps belatedly - why this last launch is such a sad event. The whole premise of sticking yourself on top of a burning candle just doesn't compare with the elegance of returning to earth in the same vehicle you took off in with a certain degree of style. A glide landing on an airstrip is so much more civilized than a splashdown in some ocean waiting to be fished out by a glorified trawler.
So, in that sense, the Space Shuttle, did live up to it's promise. It may not have been the cheap, reusable space truck that was envisioned, but it made space travel civilized.

Reversing a binary object in Erlang

While parsing a file as binary data in Erlang, which is much more efficient than as a string, which is a list of integers, you need to reverse the accumulated string. For some reason there is no BIF, built-in function, in Erlang for that. Of course you could do something like:


1> list_to_binary(lists:reverse(binary_to_list(<<"abcd">>))).
<<"dcba">>

But that is wrong on all levels of wrong-ness. Instead, searching for a better solution, I found at trapexit.org ~ Erlang ~ fastest binary reverse a code snippet that looked as promising as it was puzzling. It proved to be slightly wrong, so here is the corrected version:

reverse(B) ->  S = size(B)*8,  <<X:S/integer-little>>=B, <<X:S/integer-big>>.

It works by taking the binary, reinterpreting it as a little-endian integer and then converting it to a big-endian integer, which reverses the bytes. I'm not sure how fast it is, but assume the endian functionality is written into Beam, so it should be as fast as it can be.

Biking in the snow

A few months ago I bought a second hand Pashley-Moulton APB bicycle as a second bike for around town and for the winter. Well, the winter came with about 25 cm of snow and today I decided to bike to work. I have Schwalbe winter spike tires mounted on the 20" wheels. So I set out but had to stop a few times to free up the gears and brakes from snow and ice build-up. Despite the spikes and deeper profile, it was a struggle through snow deeper than 2 cm, so it was lucky that most of the paths were ploughed. Ice wasn't a problem with the spikes. The trip only took 10 min longer than with my recumbent on a dry day and I had a blast, but also a workout.

Installing CouchDB on a CentOS5 system

I'm migrating my new Twarfing code from home to a new server at work which involves installing CouchDB. Now, CentOS has no aspirations to be cutting-edge, so it doesn't have CouchDB in it's repository. You need to jump through some hoops to get it installed. There were good instructions on Port:EightyEight, but these turned out to be a bit out of date. This is what worked for me:

First you need the EPEL repository. I was using a 64bit system, so I did:

sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noarch.rpm

But you might need the i386 version. If all goes well, you should see something like:

Preparing...                ########################################### [100%]
 1:epel-release           ########################################### [100%]

Next I needed the basic prerequisites for CouchDB:

yum install ncurses-devel openssl-devel icu libicu-devel js js-devel curl-devel erlang libtool

Now, this is a bit different than Port:EightyEight described it: the erlang-devel package was not available anymore via EPEL, but this turned out not to be a problem. However, CentOS did ask me to reboot at this point for whatever reason.

After the reboot, it turned out that all I needed was:

sudo yum install couchdb

and CouchDB installed without needing the erlang-lang package. Also, it wasn't necessary to install from source either. The version of CouchDB I got was 0.10.0-1.el5 which is current as of writing if you really want to know.

The local.ini file will be in a different directory if installed this way:

/etc/couchdb/local.ini

I left that the way it was for now. Let's see if something else needs to be done. The Installing_on_RHEL5 wiki page seems to be the most relevant page to a CentOS installation. In it a user is created, but yum did this already and it looks just about right:

couchdb:x:101:104:Couchdb Database Server:/var/lib/couchdb:/bin/bash

And starting it certainly worked with:

sudo -i -u couchdb couchdb -b

And

sudo /etc/init.d/couchdb start

also worked. Connecting to the web interface worked once the cluster firewall was tunneled through.

Now for testing!

I've been quiet

I've not been blogging much at all recently, though I've been doing quite a bit. All the twarfing stuff takes a lot of time to develope and run. I'm also busy with some hush-hush virtualization security work. But I'll try to blog a bit more in future. I've been asked to post my malware ontology, so I'll definately post when that is up.

e-mail Truck

The New York Times has an opinion article titled Plugging in the Postal Service where Ruth Goldway expounds on the virtues of converting all the US postal delivery truck to electricity. It turns out that the US Postal Service has already looked into this in 2005. They had asked a Dutch company, E-Traction, that specializes in in-wheel electric motors and did a study on exactly that. Here is the text:

At the beginning of 2005 we were approached by the U.S. Postal Service to power their small delivery vans. Our calculations showed that with relatively minor modifications an e-Traction powered version could comfortably:

1. operate a U.S.P.S. delivery van,

2. with a single direct drive SM350/1AL unit with a side mounted differential,

3. using on average 3.1 kW per hour,

4. with only eight 100 Ah Lithium-Ion batteries,

5. for an entire workday,

6. with an average speed (when in motion) of 20 MPH,

7. with a maximum speed of 55 MPH,

8. at a total distance covered of 80 miles,

9. and an overall vehicle weight of 3,334 lbs*,

10. including one driver of 200 lbs,

11. and including 250 lbs of mail.

* Based on an empty vehicle weight of 3,050 lbs. Estimated weight loss in conversion: traction motor 270 lbs, transmission 175 lbs, and differential 175 lbs. Estimated weight gain in conversion: SM350/1AL 187 lbs, batteries 220 lbs, and onboard charger 22 lbs.

The cost of recharging these batteries with cheap electricity from the power grid can hardly be compared to the ever rising cost of fossil fuel. Our SM350/1AL has been designed for 600,000 miles between overhauls. The Lithium-Ion batteries will last at least 2,000 complete cycles or roughly 8 years.

Neither article answers the question of whether our power grid could handle charging up all these electric vehicles although Goldway suggests putting solar panels on the buildings to charge up these vans and other electric vehicles that happen drop in. It's also not clear how fast these vehicles could be converted or how fast batteries could be created, seeing that Toyota is also struggling to get enough for their own vehicles.
But, it is a nice idea. I like the idea of in-wheel electric motors, as they avoid most of the inefficiencies that a traditional power train has due to friction in the gears. With the motor in the wheel, the power is transferred directly onto the pavement. The trick is in the controlling electronics which I am sure is hard to get right.
It would be interesting to find out what the US Postal Service did with the full report from E-Traction. This would be a nice little job for a budding journalist.

Save.Y.Nu

Seen at the recent CCC 25C3 congress, apparently one-letter secondary level domain names are in danger and save.y.nu is calling to action. Certainly, I am in favor of shorter domain names for twitter and other applications where brevity is vital.
[Pardon the pathetic quality of my phone's camera.]