GitLab

Still prefer the curvy one aesthetically, but it's not supported in
Merriweather and having all basic/common textual elements of the site be
provided by the main font choice has some value.

Because why not.

Also don't need to use special three dots character.

Ensure kerning and things get activated.

For the most part code stuff will only be ASCII, so cut back the subset
to just that. Cuts the file size in half.

A bunch of updates[1], notably true small caps and kerning improvements.

A variety of optical sizes are provided now, the 6pt is closest to the
original font[2].

[1] https://github.com/SorkinType/Merriweather#5-april-2020-eben-sorkin-merriweather-v2100
[2] https://github.com/SorkinType/Merriweather/issues/523#issuecomment-752799372

Give code elements a different background color, setting them off from
regular text. Maybe one day I'll be able to structure documents such
that it's not required, but that's not today, things feel more clear and
readable with some explicit delineation. The print styles carry on
without a background color for ink-saving.

As a part of this, switch all code blocks to be content wide instead of
full width by default. It's not perfect, particularly for code blocks
with line numbers enabled, but I don't tend to use those, so punting on
that for now.

Use zenburn for dark code theme.

The search index will change when any content changes and the client
side search JS references the index file URL. So if we hash the index
file, that changes the hash of the JS that references the new name,
which in turn, changes the JS `script` tag for all HTML pages, which
means we have to upload new versions of every HTML page when content
anywhere on the site changes.

Not that big of a deal, but I'd rather deploys not have to upload and
invalidate every page on the site when unrelated stuff changes.

So instead use a stable address for the search index URL and have it be
a resource that we ask the browser to always revalidate (like for the
HTML content itself) instead of allowing a long cache lifetime.

Drops support for the last few `TLS_RSA_*` ciphers, specifically:

- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA256

Which at this point in history, should not impact many systems.

And move CAA block towards the top of DNS stuff.

Actually been running this configuration for a year or so, but never
committed it.

`viewer-response` Lambdas are invoked for every response from CloudFront
-> user, so the response after processing by the Lambda is not stored in
CloudFront. Good for highly dynamic stuff. But also means the Lambda
gets invoked on *every* response from CloudFront, which can add
latency (and monetary cost).

`origin-response` Lambdas are invoked for every response from the origin
-> CloudFront, so the output *is* cached in CloudFront. This means the
cost of the Lambda is only paid when CloudFront needs to reach back to
the origin for a resource. But it also means if there are changes made
the Lambda, will need to invalidate everything in CloudFront in order to
pick up the changes uniformly.

Since the current deploy process invalidates updated paths in
CloudFront, we can set the cache control header for files that are not
versioned by name, e.g., the HTML pages, to have a long cache lifetime
in CloudFront (`s-maxage`), while ensuring browsers/users also check
they are getting the latest content (`max-age=0,must-revalidate`)
CloudFront has. Goal being to help CloudFront have to check with the
origin as little as possible, should serve from it's cache immediately.

Nix flakes are still experimental, but why not experiment.