Quantcast

Muy bien

Muy bien, originally uploaded by tiki.robot.

Apotheosis of crapitalism

Art & flowers!



Art & flowers!, originally uploaded by tiki.robot.

Raj finally has at it with my old PowerBook… Sniff…

Just ask Donkey Kong.. He’s in my crew

This is Auto-Tune the News #2. It gets awesome at 1m 23s:

Also, Michael Gregory’s other videos.

whee! bike pr0n!!

some crazy amazing stunt work in this video! if only i could hop a curb. sigh

this motherboard grows trees.



this motherboard grows trees., originally uploaded by tiki.robot.

approximately 6,914,333 trees.

Brewster Kahle’s terracotta army

just part

Trader Vic’s Rum Case

They have a few more in their collection than I do..

IMG_5580

IMG_5584

TikiTV In Action

Here are some old pics of Sam and Peliom vj-ing with the open source TikiTV software at the Timothy Leary Archives event at 111 Minna. Way fun!

IMG_5628

IMG_5631

IMG_5629

IMG_5633

Calistoga community bbq & potluck 2

god’s oddities

calistoga community bbq and potluck

"I don’t wanna grow up"

brunch!!



brunch!!, originally uploaded by tiki.robot.

heart shaped like a panini…

chez maman brunch, recommended!

TAP Plastics



TAP Plastics, originally uploaded by tiki.robot.

near 12th and south van ness

Reception for the Linux conferences

at the exploratorium.

Linux Collaboration Summit ‘09 (1)

LCS started today. Attendee demographics changed as the Embedded conference ended…

Linux Storage and Filesystems Summit ‘09 (1)

Embedded Linux Conference ‘09 (1)

Dirk Hohndel’s keynote. Why use Linux on an embedded device? "It’s the ability (for ODMs) to control your device (by not being locked in to proprietary OSes from chip vendors) … Not because it’s ‘free.’ "

J-town looking west

J-town looking west, originally uploaded by tiki.robot.

Peace pagoda in the foreground, USF at the left side in the distance

Wi-fi at 33,000 feet

This may be a first: a TikiRobot post from 33,000 feet in the air.  The Aircell “Gogo” in-flight wireless Internet service was available on the coast-to-coast flight I was on,  so I decided to check it out.  There was one pricing plan offered, $7.95 for the duration of the flight.  This seemed reasonable, although it involved suffering through a pointless registration process and a CAPTCHA.

I was hoping to provide a thorough assessment of the plane’s connection, but unexpectedly, figuring out how to deal with the internal Wi-fi network consumed most of the flight. There was some weird Wi-fi issue between my Linux laptop and the plane access points.  The ath5k driver kept renegotiating the rate and rescanning, effectively shutting down the connection.  Maybe some other user on the plane was blasting away with some high-power card and trashing the connection?  Perhaps it had something to do with the same network being advertised at 2.412GHz, 2.462GHz, 5.18GHz, 5.22GHz?  Whatever the problem was, locking the Wi-fi rate at 6Mb/s seemed to help.  But then suddenly the driver kept reporting that it had been “deauthenticated.”  It would then reauthenticate and then promptly get deauthenticated again.  Eventually the card shit itself and reported an uncorrectable error to the PCI-E controller.  As to what was going on, who knows.  I will have to dig deeper when I am not crammed into economy class.  It’s an RSI fiesta here, gimped up with my laptop V’ed between the seat in front of me and my belly, arms twisted like paperclips over the keyboard, spilling drinks on my unbelievably tolerant seatmate.

Hoping to get some kind of useful information, I ran paired pings against a server in New York and the local router IP address.  Any time they both went down together, I discarded the data and blamed the Wi-fi driver. This provided some useful short-term data points:

— 172.19.131.2 ping statistics — (the plane’s internal router)
60 packets transmitted, 60 received, 0% packet loss, time 59199ms
rtt min/avg/max/mdev = 1.071/1.841/16.340/1.983 ms
— my server ping statistics —
63 packets transmitted, 63 received, 0% packet loss, time 62758ms
rtt min/avg/max/mdev = 102.039/162.023/426.589/85.505 ms

This is while above Vernal, Utah. The original latency floor to this server shortly after takeoff from New York was about 77ms.  I was geekily satisfied to see the latency floor gradually increase as the plane flew across the country.

When the Wi-fi connection actually worked, the service was surprisingly usable. The Transformers cosplay YouTube video played with only brief stutters.  ssh was responsive.  Aircell has some QoS problems to straighten out, though.  Jitter was quite high and ping rtts occasionally shot up to several seconds.  Aircell should enforce fairness on all of these connections at both the towers and the internal plane routers and upper-bound round-trip latency at 750ms or so.

I had expected their network to use satellites, but it apparently is a terrestrial network using two separate 1.5MHz blocks in the 800-900MHz band.  Looks like there are about a hundred cells scattered around the country.  It seems the RF interface is EV-DO Rev A.  The flacks are tooting 2Mb/sec throughput, that must be in cloud-cuckoo land, or perhaps “compression-caching land. ” 1.25MHz channel bandwidth and 0.5 bits per Hz = 750Kbps best-case on the RF side. That’s not accounting for protocol overhead, etc.  The 300-500Kb/sec mentioned here sounds more realistic.

Here are some other network details.  The plane hardware runs Linux.  http, https, ssh ports are not blocked.  My device received a local private address in the 172/8 network.  The public IP address appeared in this netblock:

CI – Aircell LLC SID-15031 ATTWH-12-130-116-0-22-0709263746 (NET-12-130-116-0-1)
12.130.116.0 – 12.130.119.255

Here’s a traceroute from a few hops away from my server to the Aircell outbound IP address:

6  cr1.n54ny.ip.att.net (12.122.131.146)  24.727 ms  24.319 ms  24.754 ms
7  cr2.cgcil.ip.att.net (12.122.1.2)  24.897 ms  25.325 ms  25.160 ms
8  gar8.cgcil.ip.att.net (12.122.132.161)  25.338 ms  24.858 ms  25.224 ms
9  mdf001c7613r0001-gig-10-1.chi2.attens.net (12.122.254.18)  25.805 ms  25.615 ms  25.833 ms
10  mdf001c7613r0004-gig-12-1.chi2.attens.net (12.130.96.174)  25.725 ms  25.501 ms  25.588 ms
11  12.130.100.142 (12.130.100.142)  25.195 ms  72.253 ms  25.567 ms
12  12.130.115.249 (12.130.115.249)  25.724 ms  25.815 ms  25.723 ms
13  * * *

One interesting (free!) potential use for this system would be to play peer-to-peer games with others on the same flight.  That shouldn’t require any connection to Aircell’s terrestial network at all.

moar than meets the eye

These are not your average Transformers fans:

kat vs hedge

I’ve already made most of you watch this video of Maru the Cat, walking around the house with a bag on his head. It is maybe the most awesome video on the internet:

Well, here is the hedgehog version, via reddit:

Also, here is a video of Maru playing with a box:

ffmpeg building on mac intel/x386

ffmpeg v0.5 just came out. it’s the bomb. it’s got tons of fixes and massive amounts of new codecs that it can read. for example, it can now decode my professional filmmaker brother’s “DVC ProHD” highly proprietary (and massive bitrate!) format! it can also decode flac and 24-bit flac. (encoding flac is disappointing though).

at any rate! macports is a great way to get it installed on your mac.
the current way of setting up macports and then doing
sudo port install ffmpeg
works fine on my PPC at work (oddly — pretty old computer now) but not my Air (intel x386)

So I set out to find the fixes needed to make it work. Here they are:

step 1: install macports — see http://www.macports.org/install.php

sudo port install x264 +noasm # for i386 (not needed for PPC)
sudo port fetch ffmpeg
sudo port checksum ffmpeg
sudo port extract ffmpeg
sudo port patch ffmpeg
remove “–enable-shared” from /opt/local/var/macports/sources/rsync.macports.org/release/ports/multimedia/ffmpeg/Portfile
sudo port install ffmpeg

(and “ffplay” is pretty cool now! i am considering using it over mplayer, hmm….)