TV is the window to the soul.

Someone else's soul.

Someone famous.

"I have another theory, too: When software companies get to a certain size, they start taking their users for granted. They start treating their users as pawns in a battle against some other company. Faceless millions. Gotta copy everything the other company does, or risk falling behind. So they end up doing everything the other company does whether the users want it or not..."

http://evilbrainjono.net/blog?showcomments=true&permalink=1094

It's a bit of a failure of an article, since it's talking about how Firefox sucks now because they started doing frequent updates and so a bunch of users switched to Chrome.  This is of course ridiculous since Chrome has really frequent updates, so the thesis doesn't exactly hold together.  Perhaps even more ridiculous is that the quote above is complaining about Firefox, not about Google.

But it sounded insightful when taken out of context, so here you go, context-free.

port.py, portsh, and py-remoteexec

Although I haven't been posting a lot here in the last few months, and my various open source projects have been a little quiet (sorry), I am certainly not idle. I've been working on lots of cool stuff, and some of it I think you'll actually get to see eventually.

In the meantime, here's some work that's based on some of my already-released work. Back in September 2010, I wrote about traffic shaping on a Sheevaplug and introduced my little toy script for talking to serial ports, port.py. It's like minicom, but it doesn't try to re-emulate vt100 (yikes!) and you can understand the source code. Since then I've improved it a bit, adding lockfile support and transmit rate limiting, and making it a bit more modular. Oh, and it supports sending BREAK signals now. I used minicom for years, but well, now I don't!

By rearranging those modules, a couple weeks ago I wrote portsh, a program for automatically running arbitrary commands on a remote machine via a serial port. Let's say you've got a Sheevaplug, or one of the many random embedded devices available nowadays, and you want to run some automated tests (for example) on the device. Part of the test is to reconfigure the network interfaces, and if you do that, an ssh session (for example) would be disconnected, so the most reliable way to control the test is via the serial port. Sadly, using a serial port has a lot of problems that don't matter for interactive use, but which matter a lot when trying to automate stuff:

• It's slow (usually 115kbps or less).
• It doesn't separate stdout and stderr.
• It isn't 8-bit binary clean by default (for example, \r is translated automatically to \n in the default tty "cooked" mode).
• When you do set it to a binary-clean tty mode, you get into trouble if your script ever aborts halfway and you want to restart it (ctrl-c is disabled!)
• You can only have one session at a time.

portsh is designed to solve most of those problems. (Currently it doesn't really try to solve the "one session at a time" problem, but it's one step toward a possible solution.) How does it work?

Well, the idea is to start a program on the remote end of the connection that runs a non-binary protocol capable of carrying binary data. For these purposes, we use base64 encoding, which is a bit wasteful but well-defined. To offset some of the wasted bytes, we also gzip all the data before sending it through, so for some kinds of data (copies of log files, long 'ps' or file lists) the net result is faster than a raw serial port.

The portsh command line is intended to work like ssh with a command line:

   portsh ttyUSB0 ps ax

...which gives a clue about why the separation of stdout and stderr is so important. Programs like bup and sshuttle rely on that separation in order to work.

Now, as it happens, so far I haven't tried to run bup or sshuttle over a portsh connection (but I think it would work). I did, however, send binary data successfully:

   tar -cf - . | portsh ttyS0 'cd /tmp && mkdir -p foo && cd foo && tar -xf -'

(Yes, the command is just passed verbatim to system(), and thus you can't avoid the shell mangling its escape sequences. That's pretty bad for security/predictability - especially with filenames containing spaces - but I wanted to be really compatible with ssh, and sadly that's what ssh does.)

I've also successfully used David Anderson's py-remoteexec (that's Mercurial; see my py-remoteexec clone on github) through portsh to upload and run arbitrary python files on the remote end, which is where things can really get interesting.

Historical trivia: py-remoteexec is actually based on my upload yourself for fun and profit code from sshuttle, but cleaned up and generalized so it's easy to use in your own projects. Then I stole back the py-remoteexec 1st and 2nd stage assemblers, modifying them for non-binary-clean serial port behaviour, and that's what became portsh. So if you run py-remoteexec over portsh, you're actually running two levels of python remote script assembly, both of which are derived from sshuttle.

Confused yet? Don't fret. Exactly how it works isn't that important, unless you're amused by such things, in which case you're best to just view the portsh.py source. It's pretty readable, if you're crazy. But if you, like most people, don't care how it works, all you need to know is you clone my repository, and run portsh, and it gives you something like ssh-over-serial-port semantics. And because it uploads itself, all you need on the remote machine is python - you don't need to install any other tools.

Enjoy!

Irony is trying to debug why the kernel crashes one out of 1000 times when a big, scary, complex process core dumps, and finally realizing that actually the kernel crashes because there's a bug in how it generates core dumps.

At least, I think that's irony.  Or at least it's annoying.

Hypothesis: your program is not useful.

I can tell because it hasn't been running for weeks, and nobody noticed.

I always suspected C++ iostreams were bad, but I wasn't sure until I saw someone calling ofstream::imbue() today.  What a terrible name for a function.

I just realized I don't think the "Fi" in "Wi-Fi" stands for anything.

My sister has been working in tech support for an ISP for years now.  I told her I volunteered to help test our call center tomorrow to get ready for the launch, but didn't know what questions a real person would ask since they don't even have the product yet.  She had plenty of ideas.  Here are some:

Ask what the speeds are!  And how the installation works!

And if it will work with your pre-existing wires in your home!

And if they have to drill lots of holes.

And if it'll work if you don't have a computer, but you have 3 Xboxes and an ipad.

How abouuuuutt...  How long does it take to install?

Are there bandwidth restrictions?  Can I run a torrent server?

Do they really give you guys free food and massages?

Will the installer track mud from his boots all over my white carpets?

What's your name?  You have a real perrrty voice.

Do you provide a router?  Is it N or G?

Can I get pictures of my grandkids in an email?

What's the difference between this, and my current provider?

Is this fiber as good as the stuff in my Raisin Bran?

Ask "why???" a lot.

And the phrase "Uh, I ain't a technical person" is a good one.

Also, pretend to be hard of hearing.  Phone people love that.

I don't know what it is with my horrible evil hacks, they just never seem to work 100% reliably.  Will make more of them for practice.

"Google Fiber TV comes with a Bluetooth remote and a search interface that looks a bit like Google TV, but cleaned up and much simpler."  – http://www.theverge.com/2012/7/26/3187990/google-fiber-kansas-city

Take that.

"A spokesman for Time Warner, Kansas City’s dominant Internet provider, says his company is ready for the competition. 'We’re entrenched,' says Alex Dudley." – http://www.businessweek.com/articles/2012-07-26/googles-smoking-fast-fiber-network#r=nav

You can't make this stuff up.

How have I never heard of these online game streaming services?

http://www.criticalgamer.co.uk/2012/02/22/onlive-review/
http://www.gaikai.com/open-platform

The main complaint I see in reviews is (shockingly to me) not latency, but just blurry graphics caused by unreliable wifi and low-quality internet links.  But it could be seriously interesting in a fiber network, connected by nice stable MoCA instead of wifi, with tons of bandwidth to spare.

I knew OAuth sucked.  I didn't realize the authors agreed!

http://www.theregister.co.uk/2012/07/28/oauth_editor_quits/

The chef looked at my breakfast and said, "Wow, you are old school."  I'm not sure what that means, but of course I smiled and agreed out of politeness. 

Also, I don't know if he said it because of the giant heaping pile of french toast and eggs and bacon, or because I was pouring strawberry compote on top.