Now that our service is production-ready, it’s time to deploy it somewhere.

There’s a lot of ways to approach this: what we are going to do, though, is build a docker image. Or, I should say, an OCI image.

This is still a series about Nix, but again: because the best way to see the benefits of Nix is to do it without Nix first, we’ll use only Docker’s tooling to build the image.

What’s a ktls

I started work on ktls and ktls-sys, a pair of crates exposing Kernel TLS offload to Rust, about two years ago.

kTLS lets the kernel (and, in turn, any network interface that supports it) take care of encryption, framing, etc., for the entire duration of a TLS connection… as soon as you have a TLS connection.

For the handshake itself (hellos, change cipher, encrypted extensions, certificate verification, etc.), you still have to use a userland TLS implementation.

ooc is perhaps one of my proudest achievements, but at the same time it’s one of the most annoying thorns in my side.

The main reason is that its design is flawed, and some things can’t be easily fixed at this point. Now don’t get me wrong: every design is flawed to some extent. Design, either when done by a lone coder, or by a committee, never comes out “perfect” — ignoring the fact there is no universal/objective measure of “perfectness”.

Long story short: a couple of my articles got really popular on a bunch of sites, and someone, somewhere, went “well, let’s see how much traffic that smart-ass can handle”, and suddenly I was on the receiving end of a couple DDoS attacks.

It really doesn’t matter what the articles were about — the attack is certainly not representative of how folks on either side of any number of debates generally behave.

Hey everyone!

This article is brought to you by a shameless nerd snipe, courtesy of Pascal.

In case you’ve blocked Twitter for your own good, this reads:

There should be a post explaining and comparing smolstr and smartstring (and maybe others, like smallstr)

Well, I took the bait.

But, since this is me writing, I get to set the rules:

• There will be no “maybe others” - we’ll review just the first two

There are news!

Here are all the changes I’m implementing, summarized as a table:

The day 13 puzzle needs a speech therapist.

…because it has an awful lisp!! Ahhhahahahhhh

No but seriously we have what are ostensibly S-expressions, except they use JSON-adjacent notation:

[1,1,3,1,1] [1,1,5,1,1] [[1],[2,3,4]] [[1],4] [9] [[8,7,6]] [[4,4],4,4] [[4,4],4,4,4] [7,7,7,7] [7,7,7] [] [3] [[[]]] [[]] [1,[2,[3,[4,[5,6,7]]]],8,9] [1,[2,[3,[4,[5,6,0]]]],8,9]

In the day 8 problem, our input is a height map:

30373 25512 65332 33549 35390

This is a 5x5 grid, and every number denotes the height of a tree. For part 1, we must find out how many trees are visible from the outside of the grid.

If we consider the first row, from the left: only the 3 is visible: it obscures the 0. From the right, 3 and 7 are visible.

I’ve been working on the itch.io desktop app for about a year now, so I thought I’d make a quick recap:

At the time of this writing, the app has been downloaded about 460K times (including updates). Not counting the back-end, the app and its various components are made up of around 100K lines of code (mostly javascript and golang), most of which is open-source.

Day 2, Day 2! Woo!

The Advent of Code 2020, Day 2 problem talks about passwords. Sounds familiar.

Basically, our input looks like this:

1-3 a: abcde 1-3 b: cdefg 2-9 c: ccccccccc

Each line contains a “password policy” and a “password”. For the first line, the policy is that the password must contain between 1 and 3 (inclusive) times the letter “a”.