Here’s a fun game I sometimes play on OpenBSD. Pick a directory under src and see what’s in it. (ok, it’s not Skyrim, but it’s also free to play.) I recently switched from being an i386 holdout to running amd64 and so this seemed like a good time to see what’s hiding under the libarch directory. libarch is an assortment of code specific to each platform that’s wrapped up in a convenient place, even though it’s completely unportable. What surprises will we find in the amd64 subdirectory of libarch?

more...

Got the new Roku 3. I had the very first original Roku (video player) from not long after it came out, then the upgraded XD model which honestly changed just about nothing. The model 3 is significantly improved.

It’s much faster. This shouldn’t have been an issue (how hard is it to scroll a few thumbnails? why was that slow?), but in any case it’s much snappier.

The remote uses radio instead of infrared. Major usability improvement. Worth the price of admission on its own? Maybe.

Very small. Meh. The previous models were hardly consuming too much space.

The USB port works well with a hard drive of movies (other previous models had them, but not mine), and is more convenient than turning on one of the other USB video playing devices.

Roku the company is in a precarious position. There are so many devices plugged into my TV it needs an HDMI switch. Every one of them is Netflix and Hulu and whatever capable. What use is a device that can only do streaming video? Because, for now, they do it better, mostly by being always on. If the PS4 comes with a 4W always on mode that can stream video, Roku is going to be in serious trouble.

According to The Open Group Base Specifications Issue 7 Chapter 2 (POSIX), there is a very narrow list of functions which are safe to call in a signal handler. This list appears in section 2.4.3 and notably omits strcpy and all the other str functions. But there’s a workaround.

more...

Here’s a new twist on password hashing schemes. The Honeywords Project introduces what I think is an interesting, but ultimately futile, approach to password security. There’s a paper linked that describes the scheme (worth reading) and an FAQ that doesn’t answer any questions I or anyone interested in the scheme is likely to ask (not worth reading).

more...

Remember when Delicious was going to shut down and you’d lose all your bookmarks? Fortunately there was time for me to download them all (to a hard drive I no longer have) before all was lost. Even more fortunately, Delicious never shut down and all my bookmarks are still there, years later and long after I’ve forgotten my password. Then came the news that Posterous was shutting down, but I didn’t care because I didn’t use it.

Recently I’ve been using Pocket not just to reformat and save articles for later, but also as an impromptu cross device bookmarking service. To that end I thought maybe I should flick through the old Delicious links and resave anything interesting to Pocket. Turns out I should have cared more about Posterous shuttering, some of the better content I wanted to save was hosted there and now it’s gone. Just one week too late! At least for now, it seems Google is still caching the original pages and not the error message, so I’ve populated Pocket with the cached view of such pages. I don’t know how much content they store on their servers, but I’ll have at least one offline copy on my iPad. What a mess.

The Archive Team’s effort to mirror Posterous may or may not have finished, but they haven’t updated their wiki page since a week before the shutdown and certainly haven’t put the archive back online.

flak uses pygments to generate the pretty highlighted code blocks. The original approach was to just shell out to the command line tool, but the performance is, ah, suboptimal. Caching mostly saves me, but at 0.1 secs per execution, highlighting five small samples pushes the initial page render up to half a second. Searching the intertubes for a pygments server didn’t reveal much. (The top hit is a random sample of highlighted code, not a highligher itself, and the other hits don’t seem very useful either.)

So here’s pyggy. It’s really simple. It listens on a port. You feed it a language, a length, and some code. It returns a length and some highlighted html. It’s not configurable. Maybe someone will find it useful.

import socket
import pygments
from pygments import formatters,lexers

html = formatters.get_formatter_by_name("html", noclasses=True, nowrap=True)
getlexer = lexers.get_lexer_by_name
highlight = pygments.highlight

serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
serv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
serv.bind(('127.0.0.1', 7878))
serv.listen(10)

while True:
        con, addr = serv.accept()
        try:
                fd = con.makefile()
                lang = fd.readline().strip()
                amt = int(fd.readline())
                code = fd.read(amt)

                rv = ""
                try:
                        lex = getlexer(lang)
                        rv = highlight(code, lex, html)
                except:
                        pass

                fd.write(str(len(rv)))
                fd.write("\n")
                fd.write(rv)
                fd.close()
        except:
                pass
        con.close()

pyggy.py

Today’s entrant for worst infographic comes to us courtesy of Esquire, April issue (Robert Redford cover), from a fluff piece about the TV show Mad Men.

We have two captions, each containing one fact, surrounding a single graphic. First, we have “nearly half” which might reasonably be presented as a pie chart. Then we have a pie chart of sorts, but with 34% in the middle. Then we have “34 percent more likely” which is the kind of fact that is not reasonably presented as a pie chart. I guess the artist decided to pick the format according to the first fact and the info from the second fact? What would have happened if the second statistic exceeded 100%? (Or worse, was negative? Would the colored region have started at the top and gone counter clockwise?)

One of the things I used to like about my phone was the fact that it didn’t have an ssh client. Going to a bar and drinking is a great accompaniment to reading about obscure server config tweaks, but less ideal a place for trying them out. I count the inability to screw things up as a feature. But then I wrote a mail system in ruby which required 24/7 care and feeding, and suddenly I couldn’t leave the house without a baby monitor.

I was vaguely familiar with Panic when they announced their ssh client, Prompt. There were two things I liked. First, Panic had reputation for building things which worked (I think, no personal experience). Second, some of the best iPhone apps come from established companies who build them either as an experiment or to meet their own needs, not trying to make a quick buck. The main problem was that at $7.99, Prompt was a full $7.99 more than I’d ever paid for an ssh client. Finally the price dropped temporarily to $1.99 and I took the plunge.

Short version: it works. There are a few bugs, but nothing major. It is almost certainly worth the full price, which only seems expensive in comparison to App Store pricing (and openssh). And now I can finally use my phone to suspend my laptop without getting out of bed.

There are also some free or lite ssh clients available, which are universally so bad as to not be worth naming. From terminal emulation too poor to run top to rejecting hostnames that didn’t contain a dot, the bugs are many and varied.

The early reviews of Google Glass are starting to arrive. Most seem enthusiastic, but I doubt I’d pay $1500 to beta test a gadget unless I was more than a little prejazzed to begin with. In the midst of processing these thoughts came the news that Google Now is available for the iPhone as well, giving me two things to complain about.

more...

Quote from a friend who develops mobile apps: “Amdahl’s law generalizes nicely outside of performance gains to mobile software platforms. Once you’ve fixed all the bugs that are fixable, all you are left with are the fundamental limits of the platform, which users don’t understand.” (And he’s not even talking about iPhone.) Mobile platforms are certainly the most common situation where the same app running on two different phones will have different features, but I’d say it even generalizes to all software.