But what about screen readers, you ask. Somebody did a web thing you don’t like. Doesn’t this break screen readers?

It seems the easy way to find out would be to test. But that requires caring about screen reader usability enough to actually have one on hand to test. Much easier to wag fingers. Screen readers are the starving children of web accessibility arguments. Why don’t you care about the starving children?

It’s borrowing somebody else’s concerns to score internet points. Oh, hi, I just wanted to try this on and post a few comments, you can have it back now. Thanks. I wouldn’t want to have to think about this all the time.

I mostly like go, but after working with it a bit more I realize there are a few jibs of which the cut I do not like.

more...

I had some go code I wanted to quickly iterate on. Go compiles pretty quickly, but not instantly. Like 2 seconds. In some places, I can use gopher-lua, which gets me pretty close to 0 second iteration delay, but there’s a big up front development cost. It’s useful for scripting an existing program and adding custom behavior, but less useful for experimenting to see what happens when I do X. What I need is an actual interpreter for go, not an interpreter in go.

more...

My phone decided it didn’t like my face and wouldn’t let me log in. Unusually, instead of giving me some retries, it immediately locked me out, requiring a passcode. At first I thought this might be a security measure, but I’m pretty sure it was just a glitch. However, it’s an interesting possibility for an authorization system. Fast lockout after a near match.

more...

New year, new network. WireGuard promises to be a simpler more secure alternative to IPsec, and there’s a beta iOS client, so I thought I’d try my hand at setting up a server endpoint.

more...

I tried out a new laptop.

more...

Sometimes there’s just too many words and I want to look at visualizations and graphics. A collection of links.

The Information is Beautiful Awards are a good place to start. Entry Showcase. 2017 winners. 2018 winners.

Bloomberg Graphics is a nice collection. Or follow @BBGVisualData.

The Economist Graphic detail is a nice collection.

The Financial Times Graphics is a nice collection.

The Wall Street Journal Graphics is a nice collection . Or follow @wsjgraphics. 2017 Year in Graphics. 2018 Year in Graphics.

The Chicago Sun-Times Graphics collection doesn’t see many updates.

The Los Angeles Times Graphics collection doesn’t see many updates.

The Chicago Tribune doesn’t seem to have a dedicated page. Or follow @ChiTribGraphics.

The New York Times has a multimedia section, but it’s still photos. Or follow @nytgraphics. 2017 Year in Graphics. (2018?)

The Washington Post also seems to lack a dedicated page. Or follow @PostGraphics. 2017 Year in Graphics. 2018 Best Graphics.

Depending on whether it is day or night, I prefer a light screen or a dark screen. I would like switching between these two modes of operation to be quick and easy. Easy in this case means I am willing to run a command, but not ctrl-click on 21 different xterms.

more...

Some thoughts on cowboys vs conservatorships after reading De-facto closed source: the case for understandable software. I can’t say I disagree with anything there. Software is too complicated and should be simpler. There is, however, an angle which wasn’t examined. Or at least an alternative that wasn’t fully explored, which is to trust authors in a way which works.

The original problem (or one of them) is the result of a fiercely independent code slinging cowboy distribution model. You write some code, toss it on the tubes, people use it, and then... you move on and hand your star over to somebody else. The de jure maintainer has changed. There’s no continuity.

Another model is to place the code in a conservatorship. Like a curated list of awesome, except actually curated. When the original author steps away, nothing changes. The de jure maintainer is the same. Continuity.

There are many examples of such conservatorships, although we rarely use the term. We might consider the OpenBSD project. Some time ago, Sylvestre wrote and contributed a fuse implementation. Then life moves on, as it does, and so did he, leaving the code without a direct maintainer. But OpenBSD didn’t just hand the code over to somebody else. It’s still ours, even if we could be doing a better job improving it. To be completely honest, although it gets the occasional commit, it may be close to de facto unmaintained. The important fact, however, is that it’s de jure maintained. Users of the fuse code can trust that it won’t get randocoined.

This isn’t an all or nothing proposition. Handing over maintenance doesn’t require assigning copyright. The code is still open, it can be forked out of the conservatorship at any time. And in exchange, there are other people to help fix bugs and answer questions when you go on vacation. You’re not trapped working on a project you’ve lost interest in out of a sense of duty because there’s a succession plan.

See also: Towards a more collaborative OSS model.

My ERL melted itself. Again. Time for a replacement. I went with a Protectli FW4A. It’s a small industrial enclosure, fanless, with four ethernet ports.

more...