I've been essentially inactive publicly for a couple of years. I'll
have more information in time, but the past couple of years have given
me a lot of time to reflect and redefine parts of myself.
This is step toward surfacing.
Mastodon was far too much load on my server. And while the sever is
just a dinky like 1-vCPU VPS, it shouldn't _need_ any more than that; I
barely use Mastodon and I will not upgrade my server (and incur greater
costs for it).
Pleroma is compatible with Mastodon (based on ActivityPub) and much more
efficient. We'll see how I like it. My account transfer is happening
right now; the fediverse is a wonderful thing. :)
For some more context: Mastodon was fine for years, but after Musk's
takeover of Twitter and increased adoption of Mastodon, my sever became
burdened by all these new instances, despite _my_ use of it being
effectively nothing.
This notably introduces The TAME Programming Language Living Document,
and effort to begin to formalize the language I've been working on over
the past decade on-and-off for my employer.
Older versions of Gawk did not mind an empty string as the third
argument, but newer versions complain:
warning: gensub: third argument `' treated as 1
I'll be using this to show example HTML code and then output it as actual
HTML to be rendered as part of the article. Otherwise the HMTL has to be
duplicated and maintained in multiple places.
An alternative is to include a file, but that is much less convenient for
smaller snippets.
I hate Markdown as a format for disciplined writing, especially when I want
macros (mostly semantic), indexes, and such. I was originally going to use
LaTeX with Pandoc, but it lacks support for inline HTML and such, and I do
not want to distract too much from the work that I want to be doing.
Over the past year, my GNU Social timeline has gone almost completely
silent; it seems that many people have moved to Mastodon and maybe those
instances have stopped federating.
Further, GNU Social development has been stalled for a long time.
So this seems like an inevitable decision to give Mastodon a try. I'll
start by following people and will post both on here and GNU Social
initially. See https://social.mikegerwitz.com.
This better describes my experience and responsibilities, though I have
never been particularly comfortable with the term. My manager describes me
as an engineer in my current position anyway.
I do not have time to update the features that do not work without JS,
though admittedly they have done a good job of providing fallbacks to
some of the things that are listed here.
Was finally published. This year they included the slides in the video,
which is perfect, since this was a technical talk that used the slides to
demonstrate the commands, and I actually did some stuff on the computer
during the talk.
Though the PIP did slightly cut off some commands; see the PDF or Org
sources for the full commands.
I noticed a lot of odd `/rss.xml' requests in my 404 log. As it turns out,
it was my fault. This both fixes it and adds a redirect in case someone
tries to do this manually. I suppose that'd be convenient.
Wow. I had wanted to spend less than an hour on a response, and instead I
wound up writing my largest article since the NSA revelations and
GHS. Hopefully others find this useful.
I've been sitting on this for weeks because I didn't have the time to finish
final proofreading and changes. I need to release this before I sit on it
for another couple; I have to start working on my LP2019 talk soon.
* post/2019-02-18-ghcq-exceptional-access-e2ee-decentralization-reproducible.md:
New post.
* src/papers.rec: Add post to top.
I'm still debating whether to include the full text of the post within the
RSS feed, since some of them may be substantial (like the one I'll be
posting soon that I've been sitting on for a couple weeks because I'm too
busy/lazy to do final editing).
* src/rss.sh: Add "(Read full post)" link.
The inlined CSS intended to make the stylesheet applicaton less jarring on
slow connections was placed _after_ `style.css', which was causing it to
take precedence over the mobile layout. Silly mistake, and not good. And
it went unnoticed for too long; I didn't visit my own website on mobile for
a bit.
Sorry, mobile people!
* src/header.tpl.htm (head): Move style.css link below inline style.
The idea here is to provide as little CSS as is sensible for the initial
page load to be styled in a layout similar to the final layout. This
initial styling may be briefly visible on a slow conection.
Slow connections can happen for a variety of reasons. For example, I'm a
Tor user, and connection speeds vary. Mobile connection speeds can also
vary wildly.
This adds a few hundred bytes, but I was able to cut it down quite a bit,
and I don't find this to be unreasonable relative to the other data on
each page.
This automates creation of the header and footer. Previously I modified
them manually and they got out-of-sync.
This is deployed to a different location on my webserver, even though the
public route is `/projects'.
Rather than displaying the hash separately, this just makes the date a link
to the source code. Until I display a modification date, this will also
make it easy to see the history of the file.
This website honors the user's default font settings (both to be kind and
for accessibility reasons). Consequently, the responsive layout is based on
character units (ch) rather than pixels.
We have two sitautions to account for:
1. Old posts had both uppercase and lowercase letters in slugs; and
2. Some ids changed.
Lighttpd can't convert to lowercase and having a bunch of separate redirects
in my webserver configuration for the id changes is messy. So, this script
is intended to be called only when a post contains an uppercase character in
the path.
I had wanted to avoid _any_ sort of dynamic scripts. Oh well.
All other redirects are handled in the websevrer configuration (which isn't
part of this repo atm).
Rather than having Pandoc generate the id, which has the potential to change
over time and cause 404s, let's just generate the slug from the filename so
that the ids will never change. This also solves the awkward question of
what the filename should be, since it was previously something arbitrary.
This mass rename was accomplished via this simple shell script:
for p in *.meta; do
slug=$( recsel -P slug "$p" | xargs basename )
mv -v "${p/.meta/.md}" "${p:0:10}-$slug.md"
done
with minor manual tweaks where I saw fit. Of course, now I have some pretty
long filenames, which is undesirable.
The next step is to compare it with the slugs currently on mikegerwitz.com
and make them match. That's the next commit, and should be pretty simple.
Mike Gerwitz