2025-02-03 18:51:54 PST
Bart Massey 2025
I've given an assignment in a couple of Rust classes I've
taught recently involving Cellular
Automaton
(CA) "Rule 110". The
latest version of the assignment is at the end of this post
— please take a second to read it, noting especially the
transition table there.
Implementing Rule 110
The obvious way to generate a next row using Rule 110 is to
walk over the current row one bit at a time, take the "left"
(L), "center" (C) and "right" (R) bit relative to the
current position, and use Rule 110 to compute an output
bit. Note that the output bit must be placed in a new row,
to avoid corrupting the row computation.
This algorithm allows various implementations of the row
datatype. A good starting place in a language with a Boolean
type and sized arrays — Rust — is to use an array of
Booleans as the row type. In Rust this looks like [bool;8]
and occupies one byte per boolean. The result is pretty
inefficient but easy to work with: for example, unlike in C
Rust array assignment and parameter passing is by value
(copied) instead of by reference.
Once you've fixed a representation of the row, and of the
LCR values — in Rust, just [bool; 3] — you can write a
function that, given an LCR, returns the correct Boolean;
that function finishes the algorithm. There are many ways to
accomplish this: a simple match (like C switch)
statement is probably as easy in Rust as anything. The Rust
compiler will even notice and report errors like incomplete
or overlapping matches, which is nice for catching
copy-paste bugs.
Going Bitwise
An obvious next step is to improve the performance of
everything by changing the data representation. Rows of
length up to 64 can conveniently be represented as a simple
unsigned integer: u64 in Rust, uint64_t in modern C.
(Rust also supports u128, but since that is not a native
type in most CPUs, more than 64 bits per row might indicate
time to just switch to a full-on bit-vector package.)
Now some shifting and masking can get the LCR bits at each
position into the low-order position, at which point the
Rule 110 calculation can just take an integer in the range
[0..7] to a Boolean. Indeed, this works for any CA rule:
my code contains this function
fn by_rule(rule: u8, bits: u64) -> u64 {
((rule >> (bits & 0x7) as u32) & 1) as u64
}
(Excuse the gross as casts in the Rust code. Rust does no
automatic numeric promotion, so getting the types right is
down to casting without screwing up: as casts cannot
panic, so will do weird (deterministic) things if you get
them wrong. Not a great language feature, honestly.)
This optimization provides a substantial speedup in my
application, but it still leaves a bunch on the table. For
"short" rows like this, we should be able to get bitwise
parallelism if we are careful. However, the only way I see
to do this is rule-specific: we can hard-wire a Boolean
computation using the structure of (for example) Rule 110
that produces the right answer. Let's do that.
Optimizing Boolean Functions
Rule 110 is defined by a Boolean truth table. These are
familiar objects to Computer Scientists and Electrical
Engineers. Let's write down the actual table, but upside down.
LCR Q
111 0
110 1
101 1
100 0
011 1
010 1
001 1
000 0
The reason for the name "Rule 110" is thus made apparent:
reading Q from top to bottom as a binary number yields
decimal 110. (You can tell that rule name inventor Stephen
Wolfram is not a "real" computer person. The rule numbering
should have been hex — 67 here — for ease of use.)
Those who recall days gone by or work with this stuff
regularly may see that there's an obvious Boolean expression
here that will produce the right answer. Let's let the
negation of a positive literal be its lowercase: for
example, "not L" is "l". Then the "sum of
products" (SOP) expression for Q is
LCr + LcR + lCR + lCr + lcR
where plus is bitwise "or" and adjacency is bitwise "and".
This is a fairly expensive expression to compute, so we'd
like to see if we can simplify it to something cheaper that
gives the same answer.
Boolean Algebra
One way is just using Boolean algebra: we can easily factor
L and l to get
L(Cr + cR) + l(CR + Cr + cR)
The extremely clever will note that we can then use
Boolean "xor", which we will denote with "^" as per horrible
C (and Rust) convention. (Why horrible? Because people
confuse it with exponentiation all the time, and then the
typechecker passes it, and then the bad thing happens.)
L(C ^ R) + l(CR + (C ^ R))
The next steps go as follows
L(C ^ R) + lCR + l(C ^ R)
(L + l)(C ^ R) + lCR
(C ^ R) + lCR
This is a boolean expression we can compute fairly cheaply:
it requires an "xor", an "or", two "and"s and a "not" for a
total of 5 operations.
Karnaugh Maps
By using Boolean algebra we got from
LCr + LcR + lCR + lCr + lcR
to
(C ^ R) + lCR
which is quite an improvement. But it was also a fairly
involved process with many fiddly steps to get wrong.
The Karnaugh
Map
is a well-known device in Electrical Engineering, but maybe
less well-known in Computer Science: a graphical method of
quickly simplifying a Boolean expression.
(Here we will work with our specific 3-literal
SOP expression. Karnaugh Maps can be made for any number of
literals, but they get hard to reason with as the number of
literals becomes large. They also can be used to simplify
product-of-sums (POS) expressions.)
The Karnaugh Map for our initial expression might look like this:
CR Cr cR cr
L 0 1 1 0
l 1 1 1 0
We have done the ordering "backward" because the original
truth table is backward: this is not normal, but it doesn't
matter to the method. We have also chosen to group C and R:
any grouping will work, although changing the representation
may make salient features more or less graphically obvious.
Now, the heart of the Karnaugh Map method is to try to
create large rectangles that cover all-ones areas. Each
rectangle corresponds to a min-term in the simplified SOP
formula.
Let's start with the large rectangle in the center, starring
each element.
CR Cr cR cr
L 0 *1 *1 0
l 1 *1 *1 0
This could give us two min-terms either vertically or
horizontally. However, the graphical view gives us an easy
way to spot what we spotted before: we will add the combined
term C ^ R. Now we have covered all the one-bits but the
lower-left one: we will cover that with a second 1×1 rectangle,
getting
CR Cr cR cr
L 0 1 1 0
l *1 1 1 0
This gives us a second min-term lCR, so our combined
expression is as before.
(C ^ R) + lCR
That was way easier. Our expression still has a cost of 5
operations.
But wait — there's more! In that last step we violated our
rule of making big rectangles. Nothing says the rectangles
can't overlap. Making the 1×3 rectangle
CR Cr cR cr
L 0 1 1 0
l *1 *1 *1 0
gives us l(C + cR) which isn't as cheap
as before. (In general, crossing even boundaries is
expensive.) But making the 1×2 rectangle
CR Cr cR cr
L 0 1 1 0
l *1 *1 1 0
gives us lC which is a 20% savings! Our expression
costs 4 now:
(C ^ R) + lC
This seems counterintuitive, so we should probably check it
with a truth table.
LCR C^R lC Q
111 0 0 0
110 1 0 1
101 1 0 1
100 0 0 0
011 0 1 1
010 1 1 1
001 1 0 1
000 0 0 0
Huh. Works perfectly.
Could we do better? Notice that Q has more 1 bits than 0 bits.
Maybe we should pay for a negation and work with the map
for q?
CR Cr cR cr
L 1 0 0 1
l 0 0 0 1
This leads to q as
cr + LCR
This has 7 operations counting the invisible negation, so
not as good.
Since we need Q we could try to deMorgan-ize and factor to
get
!(cr) !(LCR)
(C + R) (l + c + r)
(C + R) (l + c + r)
Cl + Cr + lR + cR
l(C + R) + (C ^ R)
5 operations, but we ended doing some fiddly Boolean
algebra again. Not an improvement.
Bitwise Parallelism
Now we have a really nice Boolean formula for Rule 110.
Yay. Remember that we started with a really nice formula
generalized over all rule numbers. What does the
specialization buy us?
Well, now we can use "bitwise parallelism" to generate all
the bits of the next row at once. Notice that R[i] is just
(C << 1)[i] and L[i] is (C >> 1)[i]. Soo…
let left = cur >> 1;
let right = cur << 1;
let next = (cur ^ right) | (!left & cur);
Note that Rust uses ! for bitwise negation of integer
types. Wouldn't have been my choice, but it's fine.
We've computed a whole next row of up to 64 bits at
once. This is nice. Really nice.
There's only one remaining problem. The end positions will
not be computed correctly. Right now we're shifting 0 into
the right value, and whatever was lying around in the
next-upper bit into the left. Then we're negating left
without consideration of how many bits actually need to
flip, essentially trashing the left bit for the next
iteration.
Wrapping Around
Recall that we are to "wrap around" at the ends. Let's add a
little masking and rotate action. Let nbits be the number
of least-significant bits that are supposed to be part of
the row. We can rotate right by shifting right and moving
the left bit back around. Similarly, we can rotate left by
shifting left and moving the right bit back around. The mask
at the end ensures that there's a 0 bit left of the
significant bits on the next cycle.
let left = (cur >> 1) | (cur << (nbits - 1));
let right = (cur << 1) | (cur >> (nbits - 1));
let mask = (1u64 << nbits).wrapping_sub(1);
let next = ((cur ^ right) | (!left & cur)) & mask;
The Rust compiler, when run in the default debug mode,
inserts integer wrap assertions in the code. (Honestly,
these should be on by default in optimized "release"
compiles as well. Sigh.) The wrapping_sub() disables the
wrap check, important when nbits == 64.
With the code above we can apparently produce a new row of
up to 64 bits in 15 cycles. Of course, that's a really gross
approximation to real performance. The calculation assumes
that everything can be in 64-bit registers all the time —
not unreasonable on a modern "big" CPU. The calculation also
doesn't take into account cycle times: the integer
operations may issue at two or more per cycle depending on…
things. But still…
Testing
We have done a lot to get to this point. We should probably
start by comparing with a known-good implementation to make
sure that our fiddly bit-wiggling works. I'll check the
first 10 rows of the 8-cell table from our assignment — that
should be good enough. (Remember the assignment? Seems like
a long time since we started there.) One moment, please.
Ok, full disclosure. The version of the row operation given
above is not what I started with. I made one masking bug and
missed one optimization in the first version. This is why we
test: the core idea was sound, but my code was not. Fixed.
Benchmarking and Performance
The whole point of all this fiddliness was, in some sense to
get a really fast implementation of Rule 110. Let's see how
we did.
The results? The old method (already faster) makes 100M rows
in about 3.36s. The new method makes 100M rows in
0.15s. Roughly a 22× speedup. 1.46s for 1B rows, about 685M
rows per second on a single core of my 2.2GHz machine.
But wait — there's one more set of tricks to apply. I can
set up rustc to compile for my real "modern" CPU (AMD
Ryzen 9 3900X) instead of some least-common-denominator
x86_64. I can also turn all the rustc optimizations I
know about up to 11. The result? Got 1B rows in 1.42s! Yeah,
compiler don't care.
After applying the same optimizations to the previous
version, I found 3.07s and 0.14s for 100M rows, respectively
— our speedup is about the same. The compiler can do a lot
more with the "slow" version, apparently, because there's
more code there to work with.
One final idea: this benchmark is somewhat specific. The row
width shouldn't matter much to the fast version, but it
matters a lot to the old version. I chose 8 bits just
because that is what we started with. Let's try a couple
more widths on 100M rows just to verify a bunch of
assumptions. With width 1, I get 0.75s and 0.14s
respectively. Still a respectable 5× speedup in the worst
("real") case. With width 64, I get 21.9s and 0.14s. That's
kind of a big deal.
We have won.
Future Work
Battles don't stay won. There's things we could do to be
stronger, faster, better than before.
-
Bit parallelism is the best parallelism. If you want to go
wider than 64-bit rows, though, you'll probably want to
investigate the other kind. The trick here, of course, is
the boundaries: some communication between cores is needed
on each cycle. This can slow you down massively. However,
because end corruption can only travel inward at one bit
per row, you can do some batching and fix things up
later. It all gets fiddly and really hard to make fast.
-
The manual process we went through to get the Rule 110 map
seems automatable. Some kind of nice Boolean formula
optimizer seems in order. Since there are only 256 rules
(some of which are utterly boring) we could pre-compute a
Boolean formula for each and hard-code it into a
table. Alternatively, we could find some reasonably fast
optimizer and do this on the fly. We really should handle
arbitrary rules.
Conclusions
I set out to write a short little thing to explain to those
interested what I was doing today. I would estimate that I
ended up spending about four hours writing and about two
hours actually doing the thing. This is not an unusual ratio
for me, and I think for others.
The good news is that I ended up with some interesting
insights for myself (even on this well-traveled road).
Hopefully you learned a thing or two as well.
Acknowledgments
CA Rule 110 was first introduced to me in Fall 2008 when I
was teaching a Multicore Computing class. (I ended up losing
to only a couple of students from the class of 20 or so,
pitting some forgotten variant of my single-threaded
implementation described in this article against their
16-core things.) Thanks much to the student who brought
this problem to the class.
Keith Packard and others taught me the art of bit-banging,
long ago. Thanks for that! Also thanks to Hank Warren's
Hacker's Delight, the one true bit-parallel book.
Availability
The Rust source code for everything here is available under
an open-source license at
https://github.com/pdx-cs-rust/hw-rule110-solution. Please
see the README there for details.
Appendix: Rule 110 Assignment
Bart Massey 2025
Background
In this exercise you will create an ASCII rendering of the
Rule 110
Elementary Cellular
Automaton
(CA). Not as scary as it sounds, and a nice simple Rust
thing to play with.
A CA starts with a random row of bits. We will represent 1
bits with * and 0 bits with .. Our starting row will
specifically be this 8-bit position for now.
*.*..*..
To produce the next row, take bits three at a time,
"wrapping around" if a boundary is hit (row 7 is next to row
0 and so forth). A group of three
bits in row n will determine the center bit position in
row n + 1 according to Rule 110:
111 → 0
110 → 1
101 → 1
100 → 0
011 → 1
010 → 1
001 → 1
000 → 0
So for our start, the first two rows will be
*.*..*..
***.**.*
(Notice the wraparound at the beginning and end.)
The Program
Write a program that prints ten rows starting with the two
given.
Challenges
(Challenges are not required, but give a chance to do
something extra. Turn them in and write them up in the README.)
-
Make your program take a command-line argument for the
starting row.
-
Time your program. See how fast you can make it
go. Compare performance with a C or C++ implementation.
You will probably have to modify the program to print a
lot more rows: maybe some number given by a command-line
argument.
2024-12-30 01:19:18 PST
Bart Massey 2024
I spent tonight continuing to work on moving my web content
to my cloud server. This particular task was bittersweet at
best.
My beloved brother Byron passed
away
in 2010. I miss him constantly.
Byron's website was at http://nealhere.com. I let the
domain name go, but kept the website alive in his memory at
http://nealhere.po8.org. Take a look: there's a lot of
cool old stuff there.
The move was complicated because Byron had built nealhere
using a now-ancient version of the excellent blosxom CGI
static site generator. nealhere also used server-side
includes and .htaccess. So I figured out how to make all
these things work with my new nginx installation.
-
blosxom needed CGI.pm to function. apt install libcgi-pm-perl.
-
blosxom needed plain old CGI. Unfortunately, "slow" CGI
is long gone, and the wrapping needed to make things work
with FastCGI took some discovery. apt install fcgiwrap,
then look at the nginx example under
/usr/share/doc/fcgiwrap to get some setup hints.
-
Byron's setup used .htaccess to do rewrites. Found out
how to do this with nginx rewrite rules.
-
Unfortunately, the cursed Zulip installation on the cloud
server had set the running userid of nginx to
zulip. This caused the fcgiwrap socket to be
inaccessible. It's also wrong and gross. I edited the
fcgiwrap.socket config file for systemd for now.
Everything is hard and I'm tired. I'm regretting not running
Zulip in a VM now. It clearly does not play nice with others.
I miss you, Byron.
2024-12-29 23:32:45 PST
Bart Massey 2024
In concert with the move I reported in my previous blog
entry, I decided to move my RSS feed reader
Miniflux to my cloud server. That is
the logical place for it, I think.
I spent six or eight hours trying, and gave up.
Miniflux is a server that polls RSS (and/or Atom) feeds
regularly and provides a web interface to browse them. I
like Miniflux's functionality very much: it became my RSS
solution sometime after Google
bailed
on Google Reader in 2013. I would love to think that Google
killed it because it was too hard to maintain, and with the
hope that others would take up the slack. The cynic in me,
though, thinks that Google killed Reader because it's really
hard to generate advertising dollars or gather much
interesting personal information with an RSS platform, even
one you control.
Anyhow, Miniflux is written in Go, which seems fine for
this. It also uses Postgres for its data store. I am a big
fan of Postgres in the abstract: it is the only truly
open-source database I am aware of that is usable for
"big" professional-grade deployments.
Sadly, I am less of a fan of Postgres in the concrete these
days. It has become really "enterprisey", and doesn't seem
to have much innovation or support for "normal" use
cases. The big problem with Postgres — the awful, awful
problem that has kept MySQL alive and made SQLite the
correct solution for this kind of deployment — is its
horrible authentication and security setup story. I have
watched students and open source developers struggle here,
and ultimately admit defeat. Heck, I have done it myself.
I don't have the energy to go into the Postgres setup and
administration story in detail. Here's a few of the commands
I typed at Postgres while trying to dump the miniflux
database on my old server and then restore it on my new
server. I don't know exactly what these do, so don't use
them unless you know what you are doing. They didn't work
for me much anyhow, but I put them here to give an idea and
because I may want them later. Notes, in other words.
ALTER DATABASE postgres REFRESH COLLATION VERSION;
CREATE USER miniflux WITH PASSWORD 'xxxxxxxx';
CREATE DATABASE miniflux WITH OWNER = miniflux;
GRANT ALL PRIVILEGES ON DATABASE miniflux TO miniflux;
\c miniflux
GRANT ALL PRIVILEGES ON SCHEMA public TO miniflux;
Eventually, after exploring and learning a lot, I got my
Miniflux installation running on my cloud server. It seemed
to be working perfectly, so I patted myself on the back and
went to bed.
In the morning, it developed that the feed sync couldn't
update the database. I kept getting a cryptic error about
"schema zulip". Something in the Zulip Postgres
installation, I eventually concluded, was keeping the
Miniflux Postgres installation from working. I tried to
debug it for quite a while, but eventually concluded it was
beyond me. I filed an
issue asking
for help from Miniflux (maybe should have tried Zulip as
well) and moved back to accessing Miniflux on my own server
for now.
I clearly have too much infrastructure in play. I need to
get it down somehow. Ah well. Will let you know if anything
develops: maybe you'll see the post via my Atom feed.
2024-12-29 02:19:25 PST
Bart Massey 2024
I've retired the main server that acts as the DMZ box for my
home network. The machine now called bartgone served me
faithfully for so many years that I have no idea how old it
actually is, but its time has come.
Hmm. Let's see how old bartgone might be.
- Intel "Core2 6400" @ 2.13GHz (probably Conroe Core 2 Duo E6400, 2006)
- 4GB RAM
- Intel DG965W Motherboard (2006)
So, best guess is late 2006 sometime. That makes bartgone
about 19 years old. During that time, it has run 24/7/365
faithfully and well, routing packets and providing services
to my home net and the internets.
I've replaced bartgone with bartlet, a GMK NucBox M6
mini-PC. I bought it cheap a couple of months ago.
- AMD Ryzen 5 6600H 12-core
- 16GB RAM
- Dual ethernet onboard
So far looks like it's going to be a fantastic
replacement. May it last me another 20 years.
2024-12-17 21:34:55 PST
Bart Massey 2024
Thought I'd do a quick post-mortem (damn near, anyway) on my
big adventure of the last few hours. It involved
reconfiguring a Zulip server I run, and
was supposed to be a quick thing. But Zulip is never quick.
Zulip has an interesting configuration option for allowing
multiple Zulip chat servers on a single host server. They
call this "realms" for some reason. By default you only get
the one default realm on your server, so that's what I got
when I very quickly set mine up a couple of years ago.
I now wanted to reconfigure to allow multiple realms:
https://site1.zulip.example.com (for example), and
https://site2.zulip.example.com instead of just
https://zulip.example.com on my cloud server.
Thus the fun began…
DNS
So the first thing was to get the domain names set up. I run
the DNS for example.com. I am serving it with bind9 or
bind or named — all different names for the same piece
of software in use on my home Linux server, depending on
context. It turns out that systemctl restart named and
systemctl restart bind9 are just aliases of each
other. Which is weird.
I've spent a lot of time in /etc/bind configuring this
thing, so I wasn't anticipating any big deal. I slapped
site1.zulip.example.com as an A record in the zone table
and… nope.
A half-hour of flailing later I called a friend who is both
generous with his time and a genius. He too was
confused. The thing we both thought should work, and the
internets thought should work, didn't work.
Skipping a bunch more flailing, the desired result was
achieved by adding a new zone for zulip.example.com in the
zone file for example.com (as zone master, backed up to my
friend as zone, er, alternate). With the NS and CNAME
records filled in just right, it all just worked.
Upgrading Zulip
Before I tried to do anything with Zulip, I figured I should
upgrade first, because it was time anyway and I'd be working
from a stable base. Sadly, Zulip is not packaged for Debian
as far as I can tell, so I had to download a big tarball and
have some script from the existing Zulip installation run
the upgrade.
The Zulip install script refused, because "unsupported
Debian version". Much digging around later, it turns out my
cloud server provider, who had graciously installed Debian
for me, had done something that altered both
/etc/debian_version and /etc/os-release to say I was
running trixie/sid. Some careful hand-editing of these
files got me back to where the Zulip script was willing to
admit that I had an OS they supported and install the
software.
There was one other quirk: the installer wanted libvips,
but Debian had only libvips42. Huh. So I broke down the
upgrade tarball, hand-edited the dependency, and then
rebuilt the tarball and gave it to the installer
again. Success.
Move The Existing Zulip
I then wanted to move the existing Zulip from
zulip.example.com to site1.zulip.example.com. I used the
Zulip backup script (wouldn't work earlier because of the
version thing) to back the existing Zulip up, then just used
another Zulip script to move the thing. Just worked, which
surprised me.
Deal With Nginx and Certificates
Of course, everything has to be TLS now. So I ran
another Zulip script which ran certbot to get a new TLS
certificate for site1.zulip.example.com. (Given the amount
of Zulip instances I ever expect to run, getting a wildcard
cert seemed like excessive effort.)
I then confronted a couple of sad realities: nothing was
working, and nginx configuration was the problem. I have
been using Apache since it came out, and I am just not that
comfortable with nginx. However, it was on this server because
reasons and seemed hard to replace, so I buckled down and
started to patch up the config.
One issue was another service running on my cloud box,
"Punchy". Punchy had its nginx config installed in
/etc/nginx/conf.d and really wanted to be in charge of the
TLS for everybody. I finally dpkg-diverted it to
sites-available where it should have been in the first
place.
The key finding of this phase was that every server
section needed to have a server_name set. Anything that
didn't just kind of took over everything else. Finally
sorted that all out.
One Last Zulip Config
At this point, I had my Zulip desktop client talking
successfully to site.zulip.example.com. Hooray.
Unfortunately, browser access not so much. The browser took
a login, but then just hung spinning, with a message that
said "if this doesn't come back in a few seconds try
reloading the page". Needless to say, a reload solved
nothing.
Much adventures later, I got out the browser developer
tools, which reported that Zulip was still trying (and
failing) to talk to zulip.example.com. I then discovered
/etc/zulip/config.py, which had zulip.example.com set as
primary, and no entry in the alternate hostname for
site1.zulip.example.com. I added the latter, and then
altered the nginx configuration to allow the former.
Conclusions and Future Work
Hooray. I'm back to where I started. Except now I'm running
Zulip the way I wanted to, and also now I've fixed the
Punchy config and also have figured out how to do a static
site for my cloud server using nginx. Way too many hours,
but a moderate success.
In digging through Zulip stuff I noticed that it may support
Github and Google for auth now. I need to look into this:
it's way more convenient.
Now if Zulip would fix alerts on mobile it might become
actually usable for people. Hooray.
2024-12-08 00:11:24 PST
Bart Massey 2024
Just got a Lenovo X1 Carbon Gen 13 Aura Edition (yes, its
real name) running Windows 11. I was setting up to dual-boot
Lenovo-endorsed Ubuntu Wayland, and started this notebook to
document the process.
The goal of this notebook is several-fold:
-
Remind future me what I did. ("'Future Me.' I hate that
guy. He knows what he did." —Julian Kongslie)
-
Give others a guide with some pitfalls pointed out and
navigated
-
Give feedback to the Ubuntu folks.
Background
It may be helpful to know where I'm coming from.
I started using 2.9BSD UNIX on a PDP-11 in 1982, and became
a paid sysadmin and later consultant and teacher of UNIX
stuff. I started with Linux around 1.2.13, using whatever
"distros" existed then. Later, I was a paid admin for a
network of Red Hat boxes, then switched to Debian at
slink. I've been using Debian continuously since then. I
have small patches in the Linux kernel. I was one of the
founders of Linux Plumber's Conference.
What I'm saying is that I'm old enough and arrogant enough
that the ridiculous mess that follows is something I can't
imagine a new Linux user wading through on their own. In my
opinion it was utterly irresponsible of Lenovo to claim they
supported Ubuntu on the Carbon Gen 13 when it worked like
this.
This is my first serious messing-about with Ubuntu. So
that's on me.
2024-12-04
Prepping For Linux
Previously on this machine, I had installed Debian Sid.
Gave it up, as X11 seemed not to be available and I didn't
want to figure out Debian Wayland. In the process I had
pre-done a few things to prep for Linux:
-
Modified Secure Boot: As shipped, Secure Boot would not
allow booting non-Microsoft OSes. Turned on laptop, got
into BIOS (repeatedly push F1 during boot) and found the
setting for Secure Boot and modified it to allow
Third-Party CA Certificates.
On the next Windows boot, this made me supply my BitLocker
key, since the Secure Boot setting had changed. Did so
without incident. I had no idea the Windows 11 install had
shipped with BitLocker.
-
Disabled Bitlocker: A partition with BitLocker enabled
cannot be resized by any means. However, needed to split
the main 2TB partition between Windows and Linux. So found
instructions for turning off BitLocker on the Windows
partition. Should have done this before modifying Secure
Boot.
-
Shrank Windows Partition: From the Debian installer,
shrank the Windows partition to 500GB (should be plenty
since I rarely use Windows for anything). I then let the
installer use its default partitioning scheme on the
resulting free space. Little did I know that I would
reclaim this free space and start over later with Ubuntu.
The total time for this step was probably around an hour. It
would be much faster if repeated.
Installing Ubuntu
Now I was ready to start over with Ubuntu. Some of these
steps were actually duplicates of Debian install things, but
we'll pretend that they were all new.
-
Configured DNS: Set up bartcarbon13.po8.org with IP
address 192.168.1.13 using my local DNS infrastructure.
-
Configured DHCP: Set up my local DHCP infrastructure to
recognize my machine with dhcp-client-identifier
bartcarbon13. This was necessary since the ethernet
address would be that of an adapter rather than the
machine itself.
-
Built Ubuntu USB bootstick: Grabbed an old 8GB USB flash
drive and copied a redundantly-named Ubuntu
plucky-mini-iso-amd64.iso onto the base drive device
(not a partition). Was extremely careful to check the
device with parted right before the copy: easy mistake
to copy your boot iso onto one of your actual hard drives,
leading directly to backup-recovery-town.
-
Booted from USB: Turned on the laptop and got into the
boot menu (repeatedly hit F12 during boot). Selected
booting from USB. Was confronted with micro-text menu due
to HIDPI display. Got my super-magnifying-glasses on.
-
Tried to start install: Turns out the micro-menu just
said "Choose an Ubuntu Distribution To Install". Why is
this a menu item?
Next micro-menu offered me a variety of options, none of
which was the "Plucky" the mini-iso said it would install
for me. I wouldn't mind an earlier Ubuntu, except I doubt
it would support the Intel ARC Graphics on my laptop.
Folks say installing Ubuntu is easier than installing
Debian. Don't think they've tried recently.
-
Tried installing again: Fetched a daily-build
plucky-desktop-amd64.iso after a 5-minute
download. 5.4GB should fit on my 8GB USB stick, but not
with miles to spare for sure. Dumped the ISO onto my USB
drive in another 18 minutes — that's a very slow drive and
a big image.
This time was presented with a four-item micro-menu. While
trying to figure out which option to select, the
bootloader timed out and started the default "Install
Ubuntu." Apparently I was going with that.
After a couple of minutes of staring at a splash screen, I
got an Ubuntu desktop screen. A minute later Ubuntu was
more-or-less up, apparently running as a Live Image off
the really slow USB drive. Not ideal, but I decided I
could try working with it.
-
Tried an actual install: Noticed "Install Ubuntu
25.04" in the lower-right corner of the desktop, and
decided to click on that once the handy USB drive activity
light mostly quit flashing. The only effect seemed to be
refreshing the list of volumes in the hotbar.
After a while I started clicking on things and eventually
ended up stuck in an application search screen. I
apparently had windows open according to the hotbar, but
had no idea how to get to them. A quick Google search of
"ubuntu return to desktop from app search screen" gave as
its top hit "Super+D or Ctrl+Alt+D: Show desktop". Nope.
Found a System 76 tutorial on Ubuntu Basics, which was
helpful. Still couldn't get anywhere.
Finally gave up and rebooted.
-
Tried installing again: This time chose "Ubuntu
(safe graphics)" from the boot menu, because I knew what
was coming. Figured maybe there were graphics issues with
the ARC stuff that weren't yet sorted on the Live
CD. Waited again for a couple of minutes for things to
come up.
This time I would be careful not to search for
applications.
Got a window that said "Preparing Ubuntu" this time!
Seemed more promising. I suspect graphics were just borked
on the previous attempt. Frickin' bespoke hardware.
-
Continued installing: OK! Got the expected installation
prompts. Apparently graphics were borked after all.
Everything was still micro-text, of course. Got out my
heavy magnifying glasses again. Then switched to my
Optivisor™ because the focal length of the glasses was
like two inches and I wanted my face out of the
screen.
But hey, on the second screen of the install I was offered
the accessbility option of "Desktop Zoom". Perfect! But it
turned out to be pan-and-zoom. Nope. Settled for "Large
Text" and continued magnification, with the plan of fixing
later.
-
Worked through the Ubuntu installer: Other than nice
graphics, the screens and choices seemed to be pretty
similar to the standard Debian installer.
Realized in here somewhere that I probably wanted to
set up an Ubuntu mirror at home. Sigh.
-
Changed disk partitions: Oh! The installer offered to
keep my old Debian installation and install Ubuntu as a
third way for now. Tough choice. I could always delete the
Debian partition later if I didn't miss it. But I couldn't
imagine why I wouldn't miss it, and it would be easier
now.
I decided to suck it up, take "Manual Installation" and
reuse the Debian partition for Ubuntu. The partition
editor was pretty Debian-standard, but was not interested
in letting me erase the Debian partition. I didn't know
what would happen, but decided to plunge on.
-
Continued installation: Having the timezone
configuration auto-locate me, presumably by IP, was a nice
touch: even Windows didn't do that.
Huh. The "Review Your Choices" panel pointed out that I
had forgotten to go back and mark the swap partition as
"swap" instead of "leave as swap". That's gross, but
OK. Unfortunately the partition editor then made me reset
everything else about the configuration, including stuff
it had initially auto-guessed. Ah well. I'm kind of used
to using a swap file instead of a swap partition for
flexibility, but this was chosen for me by the Debian
install and I decided to go along.
-
Installed installation: I pressed the
"Install"ifier. Started a copy of files off the USB
stick. Wasn't sure this was faster than from the Internet,
but hey. Started seeing a series of post-purchase ad
screens, including "Great for Gaming", which, well, yeah
but also had Windows on the box so…
-
Rebooted from SSD: Ubuntu came up as the first option in
the micro-menu, so I took it. Looked like Windows was
there also though, as expected. Logged in and there it
was: success! Went through a brief post-installation
dialog and was looking at a running system.
The total time for this step was about four hours. If
repeated, it would probably still be about two: there was a
lot of sit-and-wait, and a lot of menus to wade through.
Configuring Linux
The fun doesn't stop when the desktop boots. Oh no.
I needed to configure my machine for my use cases. How hard
could it be?
-
Installed a terminal: The startup had pointed out the
"App Center" icon in the hotbar. I opened it. Took me a
moment to realize that it was locked to "snap
packages". Ugh. Switched to "Debian packages". Nothing
under "terminal". Huh.
Found the "Show Apps" start menu thingy. Found a
"Terminal" and pinned it to the ~~hotbar~~
"dock". Apparently it's called a dock.
Ah! The battery-looking bar icon in the upper-left corner
took me back to the desktop. So yeah, things were just
borked earlier on.
I hoped "Terminal" was Gnome Terminal, my standard ride
and one that would make sense on a Gnome-based distro.
When I checked… it was! My old friend. Finally started to
feel a bit comfortable with this Ubuntu experience. A
shell prompt is the key to the world of fixing stuff.
Things were suspiciously slow on this very modern laptop. I
suspected something was wrong, but wasn't sure what
yet. Continued anyway.
At this point I was noticing huge lag spikes during typing
in the terminal. 10 or 15 repeats of a key would get
buffered up during a pause, which was really, really
annoying. Obvious starting point would be a reboot, but
wanted to do a couple more things now that I was SSH-ed in
from my desktop where things were more convenient.
It had been another hour. I took a break.
I should take breaks more often during this stuff. I just
want to power through it, though. It's frustrating to notice
how much needs to be done just to make things work.
--
Came back late in the evening, having slept the laptop (I
think?) unplugged for about six hours while I did other
things. Battery was down to 85%, which was not a good sign
if it really was asleep — needed to check that. Continuing
with the adventure, the battery seemed to be dropping really
fast. Was curious how the battery would perform in Ubuntu —
really needed to be minimum three hours for some of the
stuff I do.
Performance was garbage. Decided to reboot. Seems to have
fixed it for now. I don't know.
-
Set up Firefox: This involved a surprising number of
dialogs and options, and a password. But it seemed to work
fine in the end.
-
Enabled SSH: Hadn't said systemctl enable ssh
earlier, so needed to enable SSH and start it so it would
be available on future reboots.
Plugged the hard Ethernet back in. My current home WiFi
setup is kind of a mess.
-
Installed emacs: Specifically emacs-nox and
emacs-common-non-dfsg. Needed it, would keep needing it.
-
Set the DHCP client identifier: Added it to
/etc/dhcpcd.conf. Didn't appear to have changed
anything, though. Decided to figure out later how to
ensure that I got the right internal IP from DHCP.
-
Sent over my dotfile kit: I have built up an
infrastructure where I can run a package-dotfiles shell
script and have all my portable personal dotfiles,
scripts, etc to a tarball that can be copied to a remote
machine and extracted into my home directory.
Did this. Then realized I had accidentally done it as root
on the laptop and extracted into /root. Sigh. Redid it:
worked surprisingly well. Now I had my emacs
configuration, among many other things.
At this point, the laptop terminal was very difficult to
type in because of lag spikes and key repeating. Something
was clearly quite wrong.
Oh, also, since Wayland means no setxkbd I needed to
figure out how to set the Caps-Lock key to Control, or I
would go mad. Found this blog
post
which summarized why I had to switch to Wayland, and why I
really didn't want to, and maybe what to do about it. Left
it to explore later.
Oops. A warning popped up on the laptop: "Suspending soon
because of inactivity." Apparently being ssh-ed into the box
did not count as activity. Bleah.
-
Came back to DHCP: Discovered that Ubuntu uses "netplan"
to manage the network. Found /etc/netplan which
contained YAML files (ugh) to control stuff, which
explained why dhcpcd.conf was being ignored. Again left
it to explore later.
-
Set up SSH key: Used ssh-keygen to make an ED25519
keypair for my host to connect to my laptop. Copied the
public key over and set it up in authorized_keys. Worked.
Used ssh-add on the host to be able to avoid typing
passwords for a bit. Figured this would speed things up.
OK, power seemed better than feared. About 10% down in an
hour of moderate use.
-
Fixed up laptop sudo config: I have an… idiosyncratic
idea of how local sudo should work. A bit of visudo
later, and I had it how I wanted it. Gross but necessary
for peace.
-
Set a root password: Realized Ubuntu has no root
password by default. Admirable, but not OK: wanted it as a
backup. Fixed.
Figured I'd try the next one and then go to bed.
-
Installed Rust: Yeah, it's a critical use case.
apt-install rustup followed by rustup install stable
just worked. Zero issues. Nice.
After some messing around, installed my version of the
Programming Rust mandelbrot. Failed to link because
rustc was using cc by default? I thought we'd switched
to rust-lld. What version was this anyhow? Ah, the
default install didn't include llvm-tools —
fixable. Installed clang because wanted it anyhow, and
rebuilt. Build time was 17 seconds real, vs 15 for my
big fast home box. That was fantastic news! Runtime was
not so great: laptop 1.9 seconds vs home box 1.1
seconds. However, this is a benchmark that uses a lot of
cores: home box is 12-core/24-ht, laptop is 8-core. It's a
laptop: it will be fine. The compiles consumed about 1% of
power each. Fair enough.
Was bedtime. Power was at 70%. Left the laptop unplugged and
suspended overnight to see how it did.
2024-12-05
Got up after seven hours or so. Apparently the laptop hadn't
suspended. Power was down to 35%. Plugged it in and left it
for later. Wow, charging was fast. About 10% in ten
minutes, while running.
Oh, right. Made a list of things marked "deal with later":
-
Display font size final adjustment
-
Fixing keymap
-
Typing issues
-
DHCP client side
-
Sound(!)
-
rust-lld
-
Installed rust-lld: A weird side-effect of using the
Debian packaging of rustup is that I never got to set up
a "normal" Rust environment. cargo install rust-lld
worked, but still didn't have $HOME/.cargo/bin in my
necessarily in my path because no
$HOME/.cargo/env. After staring at it for a while, just
reinstalled rustup using curl, then apt install --reinstall rustup to make sure the one in /usr/bin was
current, then deleted the rustup in $HOME/.cargo/bin
to avoid confusion. There were still a bunch of
corresponding files between /usr/bin and
$HOME/.cargo/bin, but didn't seem worth playing with for
now.
-
*Set up "reverse" SSH:" Made a new SSH key on the laptop
and installed it on my host. Set up .ssh/config on my
laptop.
Except I didn't. I wiped out my SSH config on my host
instead, because screwup. Complete disaster. Backup time.
Hey, at least learned how to restore files on my new
backup system!
Tried again. Succeeded.
Suddenly, a wild failure appeared! The laptop popped up a
problem dialog. Looks like my dhcpcd screwing around earlier
left things borked? While dealing with this, my laptop
locked hard and needed to be "hard" powered-off and rebooted.
I became doubtful I was going to keep this thing.
-
Restored /etc/dhcpcd.conf: This was harder than it
looked: apt really didn't want to install a fresh copy
of the file. Finally fixed it by apt remove --purge dhcpcd-base
followed by reinstalling it and all the things that had
been removed by uninstalling it. Ugh.
-
Fixed the lid switch: Made the lid switch not suspend
the laptop when powered. Consensus of the internets was to
just edit /etc/systemd/logind.conf. Nice…
Tried disabling "disable touchpad while typing". Didn't seem
to fix the keyboard problems. top showed nothing
interesting. Laptop latency spikes continued and worsened.
Apparently installing Linux 6.12 will fix sound. Have to go
to work. Will return to it later.
2024-12-06
-
Installed the latest kernel: Spent a good hour trying to
figure out how to set up
https://kernel.ubuntu.com/mainline as an apt
source. Finally just gave up and clicked on the four
linux-*.deb files I wanted like a chump, then copied
them to the laptop and used apt to install Linux 6.13.0-rc1.
The kernel was not signed, so ultimately had to disable
Secure Boot in BIOS; then booted it fine. Made a mental
note to fix that in the indefinite future when a working
signed kernel became available. Would Windows boot without
Secure Boot enabled? Who knows?
Even with the newer kernel, sound still didn't
work. Surprising. Did find a Phoronix article saying this
kernel should fix the keyboard and mouse lag spikes and
whatnot I had been experiencing. Time would tell.
Time immediately told. Keyboard and mouse lag spikes continued.
Thought to look in the kernel log and found where the kernel
sound stuff was crashing with a null pointer deref. I love
C.
Tried again with Linux 6.12.3. Something hung hard
enough I needed a 60-second hard powerdown. Eventually
came back up. Seemed to work without kernel panics, so
decided to keep it for now.
Sound still didn't work.
-
Got sound working: Had found this
https://forums.gentoo.org/viewtopic-t-1171193-start-0.html
which mentioned getting Lunar Lake audio working. Having
gotten a new kernel, seemed like time to explore.
Unfortunately, looked like I probably maybe had all the
modules I needed.
Then went with this
https://forum.manjaro.org/t/no-sound-dummy-output-on-asus-zenbook-s14-lunar-lake-under-6-12-0-rc2/170460
. Went through the complicated process of installing the
latest Intel SOF firmware and… success! As I rebooted I
got sound.
The running Pipewire version is a little stale but functional.
Reviewed my to-do list.
-
Display font size final adjustment
-
Fixing keymap
-
Typing issues (lag spikes)
-
DHCP client side
-
~~Sound(!)~~
-
~~rust-lld~~
-
Fixed font sizes: The first item was easy. The display
font I chose was a little large even for the hidpi
display. Went back from 300% display scaling to 200%. This
still left the terminal font too small, so installed
Bitstream Vera Sans Mono and set it to a reasonable size
for 80×24.
If it weren't for the lag spikes, this thing would be
starting to feel like home. Had to believe that a kernel
update would catch that.
-
Fixed lag spikes(!), fixed grub boot menu size: Found
this https://bbs.archlinux.org/viewtopic.php?id=300155 in
my backlog, which suggested a kernel boot argument of
intel_idle.max_cstate=1.
While applying this by editing /etc/default/grub, also
updated GRUB's idea of the display resolution to something
more sane.
Both of these things seemed to work! Without the lag
spikes, this was probably a viable machine.
To-do list was now
- ~~Display font size final adjustment~~
- Fixing keymap
- ~~Typing issues (lag spikes)~~
- DHCP client side
- ~~Sound(!)~~
- ~~
rust-lld~~
This seemed manageable. Break time.
- Made the console usable: Ran
dpkg-reconfigure console-setup and picked the largest VGA font
offered. After much messing around, gave up on
making it even bigger.
Along the way, checked that Windows still booted. Yep. Yay.
Switched to X11 for a bit! This was as easy as finding the
little gear icon while signing in. Didn't work: system
experienced some failure almost immediately. But good to
know it should be on soon. Rebooted and went back to Wayland
for now.
-
Fixed CapsLock: After a bunch of messing around on the
internets, tried this
gsettings set org.gnome.desktop.input-sources \
xkb-options "['caps:ctrl_modifier']
and it immediately worked.
-
Set up my GitHub SSH key: Was fairly straightforward.
In the process, finally fixed the weird "command-not-found
database" error message I'd been having. Maybe.
apt install --reinstall command-not-found
Nope. Idk. Removed the package. That shut it up.
It was bedtime again. I'd made progress. Getting close.
2024-12-07
The laptop had lost 30% power in 8 hours in unpowered
sleep. Clearly sleeping was not a viable long-term
alternative until someone fixed something.
Boot time through BIOS and Ubuntu seems to be about 25
seconds, with most of that in BIOS. Ugh.
-
Fixed DHCP client id: That was exciting. Like several
excruciating hours of exciting. tl;dr…
nmcli con show
nmcli con modify f92bba01-5461-3e40-9d31-610788c0350f ipv4.dhcp-client-id bartcarbon13.po8.org
Then go set the dhcpd.conf host entry on the DHCP
server box to have
option dhcp-client-identifier "\000bartcarbon13.po8.org";
The \000 is a "type id", because dhcpd is kind of borked.
As far as I can tell, the GNOME NetworkManager GUI
provides no way to set the dhcp-client-id. (The XFCE
Network Manager GUI does provide this on Debian.)
Learn to love tshark.
shark -i ent0 -f 'port 67 or port 68' -w /tmp/packets
tshark -r /tmp/packets -V >/tmp/decode
Now some decoded DHCP packets will be in /tmp/decode.
-
Checked the Camera: Just worked right out of the
box. Really nice camera, too. Even has a hard camera cover
that also turns off the camera when you close it.
Great feature!
With that, I was done. I'd accomplished everything I could
think of that really mattered. My Dual Boot Notebook
dual-booted, and Linux worked well enough to use.
Conclusions
For all intents and purposes, Linux is not yet supported on
the Lenovo X1 Carbon Gen 13 Aura Edition. I've put myself
through a ridiculous amount of difficult fiddly diagnosis
and repair. Even following my instructions, which may not
work next week, it would be a big job to get this all up and
working.
That said, now that I have the laptop mostly working I am
rather fond of it. Assuming that the idle issues can be
fixed, the boot time improved a bit and the X server made to
work reliably, I think will be a great ride.
("A friend" who knows the insides of the X Server mumbled
something about "atomic KMS modesetting" when I told my
stories. Apparently there is a reasonable path to making X11
work if someone find the will.)
I found Ubuntu to be nice in a few ways, and annoying in
others. The install experience was pretty bad compared to a
Debian install, something I really did not expect. Ubuntu
doesn't seem to have the package depth of most
Debian-derived distros; I tried to install several things
that seemed like they should be there but weren't. On the
other hand, the polish of the UI and the really nice
documentation on the Ubuntu website were great. I'm not sure
whether internet searches for relevant information yielded
more or less than they would have with stock Debian: seemed
about even.
Anyhow, I'm going to pretend I have a working new laptop for
now, and start tackling issues lazily as they arise like I
usually do.
Thanks for listening.
2022-09-14 22:29:02 PDT
My wife and I have been watching The Rings Of Power. So
far, we haven't been terribly enthused.
-
There's too many storylines and characters: it's hard to
keep track of, and everything gets diluted. I haven't
found any plot line or character yet that I am really
excited to see more of, just a lot of barely-above-meh.
-
As someone who has read much of Tolkien's literary output
including The Silmarillion, I still don't understand a
lot of what happens in the show. It feels to me like a lot
of barely-disguised move-the-plot-along fridge logic. My
wife keeps asking me "why was that?" and I keep saying "I
don't know." Not a good sign.
One of the classic ways to try to hold interest in a serial,
one that goes way way back, is to have a Mysterious
Figure for the audience to worry about. We have not one, but
two here: "Meteor Man" and Halbrand. Of the two, Meteor Man
is the more interesting to me, which is to say I care a tiny
bit.
Sadly, I don't trust The Rings Of Power to have a
satisfying identity set up for Meteor Man at this point. My
suspicion is that it will be something stupid. Here's some
guesses about Meteor Man's "true identity" I've seen from
folks I watch on YouTube: I've ranked them in the order of
my belief, although I'm not yet enthused about any of them.
-
Gandalf: This is in some ways the obvious choice: a
Maiar Fire Mage, a really familiar and beloved character
who is known to be friends with the Hobbits.
This last was my initial reason for adopting this theory —
in the Tolkien Cinematic Universe, as in any CU, writers
can't seem to resist overexplaining trivial stuff from
characters' backstories. "You know why Gandalf likes
Hobbits so much, right? In the Second Age, one of them
helped him and then he befriended a Hobbit clan."
The problem with the Gandalf theory, as pointed out by
Robert at In Deep Geek (an excellent YouTube channel),
is that there's a bunch of hints that Meteor Man is
actually evil. There's the corrupted leaf in Lothlorien as
the meteor sweeps by. There's the whole "so evil the fire
gives no heat" thing (that as far as I know was invented
for The Rings Of Power and probably shouldn't have been,
as it doesn't fit at all with Tolkien and is
stupid). There's the dead fireflies, and Nori's dad
breaking his leg when Meteor Man breaks a stick.
Still, the problem with Meteor Man being evil is that we
are clearly expected to trust Hobbit girl Nori's instinct
that she should help him. Indeed, the writers set up a
second child character, Bronwyn's son Theo, as a kind of
bad counterpart of Nori who manages to steal some kind of
ultra-evil Morgoth dagger. While Nori ending up doing evil
and Theo doing good is exactly the kind of stupid
subversion I would expect from bad writers, I hope the
writers of The Rings Of Power are better than that.
-
A Balrog: This is Robert's suggestion, and it's a tricky
one. It's the kind of thing the writers might do, I guess?
See his video for some of
the justification for why it could be so.
However, I think there are some issues with this
identification. First, I am not aware that any Balrog took
human form anyhwere in Tolkien's stories; they are always
described as overt monsters. Second, it appears from
Tolkien lore that the Balrogs all came to Middle-Earth in
the time of Melkor: there is nothing to support any
falling from the sky for no reason at this point. Finally,
see the argument against a truly evil being above.
Still, as Robert repeatedly points out, we are promised a
Balrog by the previews of The Ring Of Power. I suppose
it could be this one. I just doubt it.
-
Sauron: I mean, why would Sauron come sailing in from
the sky and crash with no knowledge of who or where he
was? Why? Maybe I give the writers too much or too little
credit here. Perhaps there's some truly clever
explanation; perhaps the explanation will just be
handwaved.
Anyhow, Sauron is going to have to be charming and
deceptive enough at some point to convince the Elves
(Celebrimbor, probably) to forge The Rings Of Power.
This doesn't seem like a great start. Again, see the
argument above about pure evil.
-
A Blue Wizard. The Blue Wizards are really minor
characters from Tolkien that we know little about. Only
real arguments in favor are that they are known to go to the
South, where Nori et al are.
-
Radagast. Nope. Thought about it early on, because of
firefly powers. But nothing else would really make sense
here that I can think of.
-
The Witch-King of Angband. I found this suggestion
here.
-
Saruman. Not much fits here. Fire powers, the exact
opposite of beguiling speech, etc etc.
-
"The Man in the Moon Came Down Too Soon". This website
suggested this. It is both ingenious and
ridiculous. Hopefully not.
-
Tom Bombadil. Makes no sense. Not even worth debunking.
-
Some newly-invented character not mentioned by Tolkien.
No. Just… please no. If so, the writers better save the
reveal for the end, because I'm quitting the minute they
start adding major characters of their own invention.
-
Some character only from The Silmarillion. Basically
impossible, since Amazon would not have the rights to any
such character not also mentioned in The Lord of the
Rings or The Hobbit.
One clue that has been much bandied about is the only words
spoken by Meteor Man so far: "Mana Ure". Apparently Ure is a
Quenya Elvish word for something like "fire", "heat" or "the
sun". Mana is more complicated, but may be some sort of
interrogative like "where?" or "what?". My theory is that
"Mana Ure" is "Where's the fire?", a reference to all the
rushing around he's seeing. Or maybe "Ure Mana", "Your Momma".
The one thing I take away from all this is that the writers
have written themselves into a can't win situation for
me. Absolutely none of the above possibilities would be
anything but sad and ugly.
It would have been far better to just leave Hobbits and
Meteor Man out of this one. The Hobbits can't become too
famous without spoiling The Lord of the Rings anyhow,
since we're told they really weren't in the old accounts. If
Amazon's writers need a Meteor Man to keep the audience
holding on, the series is likely unwatchable. My curiosity
has certainly passed.
I'll leave you with my theory: Smaug. Someone once told me
that it is never a good to leave a live dragon out of your
calculations. Dragons are all about fire, they come from the
sky, they are magical, they are evil but not super-evil in
the same way as the other stuff in Tolkien.
This is a really stupid theory. But it's better than Tom Bombadil.
2022-09-06 22:31:50 PDT
I just spent a bunch of time cleaning up the image links in
the Markdown on this GitAtom blog. The images are now all
properly formatted according to the CommonMark
Github-Flavored Markdown (cmark-gfm) specification.
As I feared, it was about an hour of messing about without
doing much that was new or constructive or interesting.
-
I belatedly realized that I could probably leverage the
site's CSS to format the images in a way "good enough" for
my purposes. There wouldn't be much in the way of easy
customization, but meh.
So I went and figured out what CSS wanted me to do here,
and modified my CSS accordingly. Big fun. In case you're
curious, the new CSS looks like this:
/* https://www.w3schools.com/css/css_align.asp */
p img {
display: block;
margin-left: 3em;
margin-right: auto;
max-width: 50%;
max-height: 20ex;
}
CSS is nothing if not beautiful.
I copied that addition into GitAtom's default CSS
also. It's something most folks will want, I think.
I developed the new CSS on my development blogsite. Never
a great idea to work directly on the production
site. Seemed to work after a bunch of tweaking. Then I
copied it here.
-
I really wanted a CSS class tag for img elements to be
generated by the Python cmarkgfm package that GitAtom is
using for Markdown rendering. cmarkgfm's idea of a
"handy" image tag is like this:
[](/posts/dall-e-credit.html)
That is translated by the Markdown renderer to this HTML:
<p><a href="/posts/dall-e-credit.html"><img src="/media/0019-literal-genie.png"
alt="A Literal Genie maliciously granting a wish."
title="A 19th century etching of a Literal Genie
maliciously granting a wish." /></a></p>
I wanted HTML something like this:
<p><a href="/posts/dall-e-credit.html"><img src="/media/0019-literal-genie.png"
class="cmark_image"
alt="A Literal Genie maliciously granting a wish."
title="A 19th century etching of a Literal Genie
maliciously granting a wish." /></a></p>
See the dramatic difference? No. That's computing for ya.
But getting the second thing would allow changing my CSS
selector to
img #cmark_image
to ensure that the CSS didn't accidentally catch stuff on
this site that was not part of a blog post: for example the Feed
logo.
So I filed
an issue
against cmark-gfm. We'll see. I may end up contributing
a few lines of C code there.
-
I decided this was a good time to move all the images on
the site from the /posts directory where the blog posts
live to a separate /media directory. I had been planning
to do it anyhow, because reasons; since I was messing with
this stuff now was a good time.
I'm hoping to someday get GitAtom to be cleverer about
attached media, in particular in Atom feeds. In any case,
I'm not too comfortable with the idea that the images live
only in my site directory right now. Fixing it all will be
in the far future though — very low priority.
-
I next got to fix all the image links in my previous
posts. That's the problem with co-developing GitAtom with
FOB4: retroactive changes. I did a couple of posts by
hand, and got the hang of it. Then I decided to partially
automate the process for the rest of the links by writing
a sed script. A few minutes of fiddling around later, I
had this beauty:
s@<p align="center"><a href="\([^"]*\)"><img alt="\([^"]*\)" title="\([^"]*\)" src="/posts/\([^"]*\)" width="[^"]*" */></a></p>@[](\1)@
Sorry about the long line: sed has no great way to stick
line breaks in stuff.
But of course, it wasn't that simple. I had to yak-shave
by trying to get a sed mode installed for emacs. I
didn't find anything good, but I now get in a really
primitive sed mode when I open emacs on a .sed file.
Of course, after all that I realized that my fancy new
sed script was only good for auto-fixing exactly two
more links. Ugh. Even then, I had to wrap the HTML in the
Markdown so that it was all on one line, so that sed
could deal with it. Totally not worth it.
I hand-fixed the rest of the links, which were much simpler.
After all that, I wrote this post.
It's always like that. Things get very incrementally easier
after every little thing like this, of course. Still, it
definitely feels like pushing a boulder up a hill. Unlike
the canonical example, the boulder doesn't roll back down,
really. The hill is just endlessly high, and every time I
look back it doesn't look like I've come any distance at
all.
Enjoy my bespoke post on my bespoke blog. Otherwise I'll
just feel silly.
2022-09-03 00:45:35 PDT
I'm very much into Rust programming
(the language, not the video game) these days. The language
seems kind of for real, and has some nice properties.
Back in December 2016 I participated in
Advent of Code 2016. This
was my second time doing AoC, I think, and I did it in
Rust. This was about two years after Rust went 1.0, but it
was already a very viable language. I ended up with
this repository,
which has over the years become one of my highest-starred
Github repos.
Today I glanced at the repo for some reason and noticed that
Dependabot, Github's security checker, had scattered many,
many security advisories over my code. This is easy for
Dependabot to do with Rust, since the libraries used all
come from one place — crates.io — and security stuff is
tracked really well.
Even though a lot of these security warnings were redundant,
this was still a bit alarming. I decided to see what I could
do to bring my code up to 2022 standards, and eliminate the
possible security issues in the process.
The good news is that this was ridiculously easier than in
any other language I've worked with. Rust tools just
automate the heck out of it. I eventually ended up
shell-scripting most of the work. I brought all the code up
to 2022 Edition, fixed all the warnings, and replaced a
cryptography crate that was stale and vulnerable.
I also tried, as an experiment, just doing the minimum
automated upgrades to keep things going. That was even
easier, but of course I like the nicer result.
When I contrast this with my experiences with Haskell, Go, C
and C++, it's just night and day. Rust is really a nice
language.
2022-09-01 01:46:30 PDT
Welp. Blaugust is done.
It's been a great opportunity to get back into the blogging
swing. I've gotten my software stood up shakily, I've done
31 posts over 31 days (albeit not consistently). I've met
some more nice blogger people.
As I promised earlier, I'm going to scale back a little on
output. I'm also going to work more on GitAtom. I've got a
lot of projects to keep me busy, so it's the usual time
balance thing.
Thanks again to Belghast for running Blaugust, and to
Bhagpuss for inspiring me to give it a try.
In the unlikely event that you're reading this, hope you'll
keep reading along.
2022-08-31 01:26:03 PDT
In terms of content, the participants of Blaugust are about
games, music and geek media. So far, my blog has utterly
failed to fit in. But hey, I can write about these things
too. I really can!
Today I was trying to recall the last game I really played
hard. It doesn't happen all that often — I'm a pretty fickle
gamer. Turns out it was probably Breath of the Wild. So…
yeah.
I never did finish BotW. I finally beat the four thingummies
and finished most of the non-combat content in the game. I
spent countless hours exploring and poking around. I got the
DLC, then discovered it wasn't really for me.
The sticking point with BotW is that, while I dearly loved
the open-world exploration, I'm not much of a fighter. It
isn't that I can't do it, although I am objectively terrible
at it. I just don't like it. In terms of traditional gamer
classifications, I'm discovery then puzzles then meh.
The sad fact of the matter is that games are more and more
stuck on genre content. Worse yet, pretty much every genre
is either fighting, puzzling, crafting or some combination
of those. It's great to see some open-world exploration
games, but the game designers seem unable to get beyond the
idea that the purpose of a vast open world is to provide
things to fight, puzzles to solve, and industries to start.
Conservative genre-mining kind of makes sense for AA and AAA
titles. No taking extra risks with that kind of
money. Customers who are going to pay big and in large
numbers for a title want predictability and
familiarity. This is even more true for the free-to-play
titles: they need to be big and sticky to work at all.
Indie game devs don't have so much excuse. The phrase
"indie", which after all is only shorthand for
"independent", is a little weird here: Activision/Blizzard
is "independent". Presumably most small game devs want to be
A/B someday, or at least want that kind of money.
What I want is genre-breaking gameplay. In particular, I
want to get away from the toxic parts of genre tropes: no
murdering and violence, no frustrating IQ tests, no
dully addictive game loops. That leaves out a lot, right
there.
As a sometimes game designer myself, I've been thinking hard
about this. What space have I left myself?
I don't know. It's late and I don't have answers. Let's all
think about the question. There has to be something there
somewhere.
2022-08-29 22:24:01 PDT
Apparently this is Lessons Learned Week in Blaugust. Blaugust
is almost over: just a few more days.
Oh, right. Lessons learned.
-
I might as well give up on genre blogging. The things I
want to write about are all over the map. It's going to be
that way. I once got kicked from a blog ring about X
Development for being too off-topic about X Development. I
guess GitAtom needs tags and topic filters. Atom supports
tags, so there's that. I'll add it to the GitAtom
enhancements list. Holding your breath for anything on
that list would be really dangerous.
-
Co-developing blog software is a mixed blessing. Modern
freely-available blog platforms are pretty darn
sophisticated. Taking a student project to a usable state
while trying to do Blaugust was questionable at best. I'm
relieved to be a little on top of GitAtom now, but concerned at
how much I still want to do. To be fair, without this blog
GitAtom would have ended its life stale and forgotten.
-
I am not a social blogger. That's an OK thing not to
be. I think it would be silly to blog if I didn't want
people to read my content at all. However, there's no
urgency and no pressure for me there. I haven't engaged
at all on the Blaugust Discord. I will try to do that
here at the end, but it's probably too late. I can live
with this.
-
Schedule and size are a thing. I think I'll keep
blogging for sure, but probably not on a daily
schedule. That turns out to be just a little more than I
want to do. My goal after this month is 14+ posts per
month. I really am going to start building up a queue,
saving out some non-time-sensitive posts even though
they're ready to go. At some point soon I'll decide on a
regular posting schedule: that's a thing I've never done
before.
I want to quit with the tiny
"post-for-the-sake-of-posting" posts. I don't like them.
It looks like my most comfortable length so far is around
400-500 words. Not long by blog standards, but
substantial. I have a few longer posts covering a topic in
more depth. I feel like I can knock out 500 words in 20
minutes or so, usually. That's a fine amount of time to
spend a few times a week on this hobby.
I have some other aspirations for this blog as well. That's
a good topic for a future post. Another 500 words folks can
read or not on a random topic on my GitAtom mess. Riveting,
I'm sure.
2022-08-29 18:41:24 PDT
I wrote a couple of days ago about my use of DALL-E for blog
illustrations. My conclusions weren't so positive.
Today I discovered Stable Diffusion, an open(ish) source
project in the style of DALL-E that you can run on your home
computer.
Of course I did. The thing has only been available for a few
days, and already there are reasonably easy ways to use
it. My NVIDIA 2080 is barely powerful enough to run Stable
Diffusion's generator: but it works.
Here's my reaction, in parallel to what I wrote previously.
-
On Business Models and Creativity… Being able to run SD
at home means I just don't have to think about whether I
want to generate an image. It's about 20 seconds per
generated image on my box, which is fine.
-
On The Limitations Of 2022 AI… SD is quite comparable to
DALL-E. So far it seems to do better in some ways and
worse in others.
The thing everybody's excited about with SD is the
unclamping of limits on what can be generated. I guess
that matters: I can now ask for a picture of whatever
celebrity and get them. Meh.
One thing that is cool about the interface to SD that I'm
using is that it allows "image to image" transformations with
text guidance. So starting with my FOB logo image
I asked for it as a Mondrian
and as an Edward Hopper
These were reasonably successful. Other experiments went
pretty badly.
-
On GitAtom's Clunkiness And "Ease-Of-Use"… Because of
the way the SD interface I'm using locally generates
images, I can probably include them here a little faster
and easier. But that is offset by the hassle and time of
starting up SD in the first place.
-
On The Competition… No change. It's still just an alternative.
So… yeah. Progress marches on too fast to count.
Dinnertime. Peace, y'all.
2022-08-28 02:21:38 PDT
I am posting late today because I spent a long time being
involved with THE WISE CUP. I am spelling it that way
because it is a 10-letter backronym too convoluted to
repeat: I'll just go with TWC from here on out, though.
TWC is an annual event run by our next-door neighbors, for
the benefit of the folks on our street and friends and
associates thereof. Because we have that kind of
neighborhood.
TWC is a treasure-hunt-style game with geographic clues that
lead teams of 2-4 people to various landmarks in our small
but riche suburban town. At each stop, participants must
solve a puzzle of some sort and make some observations. At
the end, there is a quiz over the observations. Scoring is
based on successful completion plus the quiz score. There
are prize baskets for the top three finishers, plus a
literal trophy cup made by my neighbor, who is quite crafty
and does mosaicing. It's all a great deal of fun.
This is the third year of TWC. The first year, my wife, my
sister-in-law and I won, uh, very handily vs eight other
teams. Last year I was recovering from surgery during TWC,
so my friend and his son filled in for me. It was, uh, even
worse. This year I decided to sit out, because it seemed
reasonable to give the other teams a chance. The outcome was
quite a close call, but, uh, my wife + sister-in-law + son +
son's partner won again.
What can you do?
Looking forward to next year's THE WISE CUP.
2022-08-26 17:07:53 PDT
If you've been following this blog (why? how?) you'll know
I've been playing with the
DALL-E
AI art generation tool for blog illustration purposes.
I feel like I'm getting to the end of that
experiment. Here's a few thoughts on why.
-
On Business Models and Creativity… In the world of
modern computing an awful lot is premised on literally
"pay to play". Whether it's games themselves or creative
tools, organizations expect to cover their costs as well
as a healthy profit by charging. This seems quite
reasonable on the face of it.
The question of whether a creativity service charge is a
workable business model is thus premised on whether the
chargee values the service enough to pay adequately. I'm
grateful that DALL-E gave me a chance to get an answer for
free. The bad news is that I am concluding that I do not
value DALL-E that much.
Pay-per-image, first of all, is deadly for me. I've been
really careful with my 50 free images, as a gamer-inclined
person will be with most any resource. I have skipped
asking for illustrations I didn't really "need", and I've
never asked for a re-render of an illustration I was
unhappy with. I get to a spot where a picture was
mandatory, pick the best of the four results, and call it
good — regardless of whether I'm really happy with what
went down.
I'd much prefer an unlimited-use (or huge-cap use — say
5000 images annually) periodic fee model. But I'm really
skeptical they could charge small enough to make it work
for me on that basis. I guess I'd happily pay $10 per year
for effectively-unlimited access to DALL-E. I doubt that
would even come close to covering my share of the
infrastructure costs.
-
On The Limitations Of 2022 AI… The premise of DALL-E and
friends is just insanely aggressive. As an AI Professor, I
am more than aware. The fact that this bear dances at all
is nothing short of astonishing.
That said, once the astonishment wears off, the holes
become pretty apparent. The biggest problem with Magic
Neural Nets is that there is little that can be done with
small-scale engineering to uncover obvious systemic
limitations.
For example, since its inception (no pun intended) DALL-E
has liked to put "symbols that look more or less like
text" in its images. It does this the most when it is
confused about what is happening. It's "clever," but it
isn't something that's OK in an image that is meant to
stand on its own.
No one knows how to fix this, really. I'm not much
exaggerating here. OpenAI could retrain the net heavily to
get DALL-E to stop doing that. Mostly. But that big a
retrain would likely induce other follow-on problems. You
can't just go comment out the "generate texty stuff" code
— there isn't any. What you'd really like is to get DALL-E
to put real, sensible text in the places where it wants to
put text. That would be a whole 'nother
grand-challenge-grade AI project.
I look at this, at the failure to faithfully utilize the
art styles I've asked for, the confusion about the subject
— all of which are completely understandable given the
tech involved — and I think "Will I be ok with very slow
incremental progress in these areas?" and I feel like the
answer is no.
-
On GitAtom's Clunkiness And "Ease-Of-Use"… The friction
right now for getting a DALL-E image set up for my blog is
surprisingly high. Much of this is GitAtom's
fault. GitAtom doesn't have any real intrinsic support for
images beyond what is provided by the cmarkgfm Markdown
engine I'm using. It's not great. In particular, ensuring
that an image is rendered at a reasonable size pretty much
eliminates using Markdown-style image links, since the
width parameter of the image tag wants to be
specified. It's possible that with some CSS magic I could
make this smoother, but it would be a big project.
Further, I can't just drag-and-drop my generated DALL-E
image, for several reasons. I want to preserve the query
text I used to get the image as the image title, which
again means I'm stuck copy-pasting it into an <img>
element somehow. I need to get some alt text for
visually-impaired readers, which is different from the
title because DALL-E is just not that good. Finally, I
want the image wrapped to link to my DALL-E credits page
when clicked, which means some nested magic.
I would guess it takes me about 20 minutes to go from "I
want a DALL-E image here" to "OK ready to go." That's too
long.
-
On The Competition… But if not DALL-E images, where
would my blog pictures come from? Hopefully, this is not
too much of a mystery. I could do pretty much without
pictures altogether, as I basically am doing anyhow. I
could use good ol' photos, both freely-available stock
photos and photos I have taken myself. I can't really
afford to pay artists, but I can create my own art in my
own limited primitive way.
I ran a blog for years and years without DALL-E. I can
easily survive without it going forward. "Free is a very
good price." —Tom Peterson
It's been a grand experiment. I'm not saying I will never
use another DALL-E image. But I'm branching out. Thanks to
OpenAI for DALL-E anyhow. It's been an amazing trial.
2022-08-26 16:39:02 PDT
I got into a mild argument with someone I care about
today. I had a plan about how to do a thing. Other Person
thought it was a really bad plan, with too many risks. After
some argument, OP won, and I did it their way. That went
fine.
It reminded me, though, of a rule I've been working on
following for some time now. Whenever feasible, allow
others to fail.
That sounds like a horrible mistake. Let me clarify.
Let us say that I am a teacher (I am), and one of
my students has a bad plan. They've found a terrible way
to try to achieve an ill-thought-out goal.
As a teacher, I have an immediate obligation to try to help
them. I should absolutely try to work with them to clarify
their goal. I should absolutely try to help them see the
issues with their plan and suggest a better
alternative. Perhaps I will even need to discourage them
from proceeding at all, because I cannot see a good plan
even with their help. So it goes.
But I may get an argument. Or a bunch of argument. The
student may be convinced that I am wrong. They may feel that
the goal is clear, and that the plan will work in spite of
my objections. Of course, it is now my job to persuade them
otherwise… or is it?
Premise: People learn more from their failures than they
learn from avoiding failure. Real consequences are more
real than hypothetical ones.
Premise: I could be wrong. After all, I may be more expert
than a student, but I'm far, far from omniscient. Maybe the
terrible thing I've pointed out won't happen. Maybe the
student will be really happy in their goal state.
SO I should always state my objections and concerns
mildly, as observations and estimates. If my advice is
ignored, I should default to letting the advisee go on.
One of two good things will result: the advisee will learn,
or the advisee will be right. In either case I have won and
they have won.
The exception to this default, of course, is about
consequences of failure. If I can reliably determine
that a particular failure is both actually conceivable and
sufficiently devastating, I need to do everything in my
power to stop that. For example, dead advisees won't have
learned anything; those who have ruined their lives won't
appreciate the price of learning.
The good news is that if I have presented as a risk-tolerant
advisor — somebody who allows advisees to fail — my
occasional strong opposition will be taken much more
seriously. Advisees will know it's coming from a place of
goodwill and trust, not just an ego trip or
argumentativeness on my part.
So I try to practice caution and humility. I won't let
people go into failure blind, but I won't close most doors
in front of them either.
I guess what I'm saying is that OP should have let me
fail. Oh well. I was reminded of this lesson, and everything
came out fine. So it goes.
2022-08-26 13:24:55 PDT
OK, so after all that talking and caterwauling and whatever,
if you look at the upper-right corner of your browser you
should see a Feed Icon. If you paste the address there into
your Feed Reader as per usual, you should be experiencing
the joys of my new Atom feed.
The process of getting this to beta was as involved as
getting a major feature to beta gets. I ended up refactoring
most of the GitAtom codebase. This will make future
improvements easier, but yeesh. In the process of getting
the feed going, I closed some other critical issues.
There was also the usual
yak-shaving.
Notably, I wanted to include the Feed Icon as, well, an
icon. This led to the discovery of the previous-decade's
initiative for a standard Feed Icon, which I would have
thought would have led to a freely-licensed Feed Icon to
use. Sadly, I can't figure out the licensing terms for the
"standard" icons and whether they license both copyright and
trademark: it all seems to be under fairly fancy open source
licenses. I gave up, and drew my own CC0
Feed Icons. Hopefully
I won't have trademark issues with them — seems unlikely.
There's still likely some pretty bad bugs to be fixed
here. Some things are not yet tested, and nothing is
well-tested. Still, nice to be able to syndicate my site at all.
2022-08-24 23:58:35 PDT
Sometimes my motivation to blog is as simple as not giving
up.
The last couple of days have been weird. I've been made
tired and messed up by them.
Still, how hard is it to type a couple of sentences here?
I'm reminded of the biting lyric by the late 1980s Christian
songwriter Keith Green: "Jesus rose from the grave, and you
can't even get out of bed."
So I slog out some typing. I'm still a day behind. But it's
better than two days behind.
Talk to you again soon.
2022-08-22 22:31:25 PDT
I said I was going to add an Atom Feed to GitAtom
yesterday. And by the end of today, I almost have.
I mean, teknicully I akshually have an Atom feed now.
It just doesn't do quite what I want so I am refactoring and
rewriting part of it, and there are a number of bugs that it
has exposed that should still maybe be squashed.
My division of labor so far, as estimated off-the-cuff:
-
3 hours: acquiring, reading and understanding various technical
specifications around Atom, XML, MIME types, etc, to get
the implementation standards-conformant(ish).
-
3 hours: acquiring, reading and understanding a bunch of
Python and library stuff needed to get the implementation
right.
-
3 hours: refactoring the existing codebase into some kind
of usable shape.
-
3 hours: writing new actual code for the Atom feed.
-
2 hours: finding and fixing bugs related to the
implementation.
-
2 hours: building a dev instance of GitAtom and some
infrastructure to auto-update it.
-
2 hours: miscellaneous, including maintaining the GitAtom
repo and issues, prototyping stuff as needed, debugging,
etc.
So roughly 18 hours in two days, of which about 3 were the
actual implementation of the actual feature. I'm not quite
done yet, but the proporations should stay about the same.
Am I motivated to program like this because I'm blogging, or
motivated to blog about programming? I dunno.
Starting to burn out on this whole fire. Must finish soon.
2022-08-21 13:05:03 PDT
Yesterday I talked about a really great idea that I needed
to share. Today I've forgotten which idea it was.
Great.
It's now "Staying Motivated Week" in Blaugust. It couldn't
be more timely. Here's what's keeping me motivated in
blogging right now:
-
Getting GitAtom into a truly usable state. I have a
million things to do today, but instead I'm going to start
by finally adding a feed to the software.
-
Getting back into the swing of blogging. I enjoy blogging
quite a bit while actually doing it. I need to remind
myself of that by repetition. Humans are not one-trial
learners.
-
Getting things written down. There's an old adage in
academia, where I live, that a thing isn't real until you
write it down. It's a hard adage for me to live by.
I have a ton of content and content ideas that I want to be
up on the web in some semi-persistent form. A blog is kind
of a perfect way to do that: low effort, low bar for
quality, but still a better result than carrying ideas in
my head and telling them to my friends.
I'm going to get the future post ideas queue going again
today. It will be full of half-started blog entries. At
least it will remind me what my blogging priorities are.
I can't believe I forgot.
2022-08-20 21:54:48 PDT
I have a great blog post idea. It's a topic I have talked
about a lot in the past, and it deserves to be here.
What I don't have is the will to give the post the 20
minutes of careful effort it really deserves. It's an idea
that has to be got right and expressed right to be of value.
I'm tired. You get this post instead. I can't promise that
you will get the goodpost someday soon: I'll try.
I think this is a common blogging thing, really. The bloggers
I've followed express it all the time. With a daily blog,
pacing is everything. A recurring theme on my blog is that
we are all human, that I am especially human, and that
humans need to respect their limitations. I envy the people
who make everything they do great. I don't know how they do
it. I know that will never be me.
So enjoy this meta-post. It's what I have to give. Hope
you'll "tune in" (wow I'm old) going forward and see me at
my best. Hope my best is OK. I'll settle for OK.
2022-08-20 21:47:18 PDT
Turns out my last post contains an off-by-one error. I was
only three posts behind.
This is one of the most common errors in computing: a fact
surprising to non-computingists, I think. Computers are
supposed to be really good at counting things. They are. The
problem is that we humans need to let the computer do the
counting. When we try it ourselves, we inevitably get close
but no cigar.
Turns out that the manual blog-post-numbering I was doing as
I manually made Markdown files for my post was off by a bit
here and there. Fixing it turned into a half-hour mess of
renaming files and editing their contents to make GitAtom
happy again.
The obvious solution is to fix my GitAtom blog software to
do post numbering for me. That's hard, and I'll have to
think about (a) what I want to happen, and (b) how to make
it happen in the Python codebase. Again, maybe (a) is the
surprising part: it turns out that figuring out exactly what
we want the computer to do is arguably the hardest part of
software development.
The computer is a real-life
Literal Genie. The
computer will (software bugs notwithstanding) do the most
annoying version of exactly what we tell it to do. With
great power comes great failure, mostly.
For now, I'll just wade on manually and try to avoid
mistakes. Like that ever worked.
2022-08-20 21:16:15 PDT
I got my Amateur Radio Technician license about 20 years
ago, testing in along with a very good friend. The FCC knows
me as KD7SQH, but you probably do not, since I've barely
done any ham radio since then. I got the license for a
purpose — to communicate in the Black Rock Desert during a
rocket launch event, and once it served its purpose I set it
aside.
I'm now getting involved in an amateur radio thing, and so I
decided to upgrade to my General License. A couple of
Sundays ago my friend and I went down and passed that test:
my friend went ahead and passed the Amateur Extra test as
well. I will be taking that test shortly with every
expectation of passing.
With the upgrade, the next logical thing to do is to buy a
real radio setup for my home. My hand-held transceiver
worked for its purpose, but long-distance stuff requires
more than an HT.
The sad truth is that when I think about the cost and time
commitment of going there, I've pretty much decided to
forego this plan for now. I'm somewhat budget-constrained at
the moment: I'm also constrained by the hundred-foot fir
trees surrounding my house, which while beautiful and
wonderful make for unique setup challenges if I'm to get
anywhere.
The fact of the matter is that the last thing I need in my
life right now is to add another half-assed hobby to the
dozens of those I already have. I may try participating in
one of my local Amateur Radio Emergency Service groups in
some capacity — that is a fine and noble endeavor. But I
wouldn't need equipment for that right away: I can wait and
see what I need and what I want to do.
Oh for the funds and time. Maybe someday. Maybe.
2022-08-20 21:16:15 PDT
For the last few days, my life has been consumed by doing
final setup and then leading the
Rust-Edu Workshop. I'm
really happy with how it turned out. Who knew that
inviting a bunch of brilliant, creative and really friendly
people to work together on a common interest would go so
well? As a completely unbiased observer, I'd give the
event a 9.8/10: the 0.2 was all me.
That said, it looks like I am now four posts behind this
Blaugust. My grand ambition of maintaining a queue failed
early: it's now just a struggle to get back to parity again.
Please look forward to three extremely short blog posts,
even by my standards, as I try to maintain some semblance of
being able to blog "regularly."
I am exhausted and suffering from stress recovery, but I'll
be fine in a bit. Thank you for your patience.
2022-08-17 00:03:26 PDT
Bill Wurtz is a guy on YouTube.
Bill Wurtz is a remarkable creator on YouTube.
Bill Wurtz is most famous for
history of the entire world, i guess
(mildly NSFW). It is rightly celebrated.
Bill Wurtz makes short music videos like
old macdonald.
Bill Wurtz more commonly makes "normal length" music videos
like
Mount St. Helens is about to Blow Up,
which is perhaps my favorite.
Bill Wurtz writes all of his own music, performs all his own
instruments, does all his own animation.
Bill Wurtz is an international treasure.
Bill Wurtz is a favorite of
Charles Cornell.
Bill Wurtz may not be for you. If not, I don't understand
why.
I really like Bill Wurtz.
2022-08-15 22:18:47 PDT
Let's start this with a note I posted on an obscure Discord
back in February…
In 2006 I started following this
obscure webcomic that
finished in 2015. It was a cute romantic comedy: not the
kind of thing I usually read, but it was fun. Last week I
got an update from them to check out their upcoming movie
trailer. I thought it was a joke at first, but nope,
it was real.
That was my introduction to the AAA title linked above. I
ended up really enjoying the movie and can recommend it. It
was a weirdly successful cross between a Hallmark Channel
movie and an oddball webcomic.
I've been following webcomics since the web became a thing.
Arguably before that: I used to follow Dilbert on Usenet
through the Brad Templeton's Clarinet service back before
Scott Adams bailed on the fanbase that made him. (I
suggested "a clueless intern" to Adams as a character in an
email a month or two before Asok entered the strip. Probably
just a coincidence…)
I currently follow about 80 webcomics using
http://piperka.net, although most of those are not currently
active. A couple of my student friends created
http://comic-rocket.com/ with a bit of help from me: one of
them got me into webcomics on a much bigger scale 20 years
ago.
So all this hipster cred-building is my way of saying…
Thank you. Thank you to the creators that made and
continue to make webcomics. You folks are amazing. I have
been but a happy parasite, for the most part, on your
success.
Thank you. Thank you to the webcomic tool and
infrastructure creators that have made my webcomic
experience so smooth and special. Some of you are my
friends. All of you have my respect.
Back when I had a full-time blog before, I'd post my current
webcomic list every few years. Probably time to do that
again. This is edited both for taste and to show only
currently-running strips. It's enough.
I haven't included links, because exporting them is a bit
troublesome right now. Again, you can type titles at
Piperka or
Comic Rocket.
- The Bouletcorp
- Dead Winter
- Dicebox
- Dinosaur Comics
- Existential Comics
- Gunnerkrig Court
- Guthrum
- Magefront
- The Order of the Stick
- Outsider
- Skin Deep
- Spacetrawler
- Terminal Lance
- The Wandering Ones
- Widdershins
- XKCD
2022-08-14 23:26:15 PDT
I sat down tonight to figure out enough Bevy to be able to
participate in the upcoming Bevy Game Jam.
I failed. I failed to motivate myself sufficiently. Looks
like it would probably take me 10 or 20 hours to get to
where I'm comfortable with the framework, and I just don't
feel like spending that right now.
It made me think, here in Blaugust Creative Appreciation
Week, about the hells of complexity and weirdness that
modern digital creators put themselves through to get stuff
built. When I was a boy, the bar for creating on a computer
was so low, and any creative output was highly
regarded. Nothing is easy anymore, and expectations are so
high now.
Dozens of great games will be built for the Bevy Game Jam
this year. Each one will be many thousands of lines of
clever code, with crazy amounts of art, music, modeling and
other creative assets.
Thank you, those people! Wish I could be one of you. Maybe
someday soon.
2022-08-14 00:05:15 PDT
For many years I had a primary blog I self-hosted using the
Drupal CMS. It was called "Project Resolution" because it
started with a New Year's Resolution, and "FOB" for "Friends
of Bart" — a name with quite a bit of history.
My blog collapsed not so much because of lack of will on my
part as because the underlying blog framework collapsed. I
got wedged in the state where I couldn't keep blogging with
the existing Drupal because my Drupal version had become too
stale (security holes and software rot), couldn't manage to
upgrade Drupal to a newer version in spite of extensive
efforts, and couldn't manage to extract my content and move
it to a new platform in spite of efforts that included
writing a bunch of bespoke code for that purpose. All of
this provided the impetus for the creation of the GitAtom
platform I am using now.
I did manage to dig much of the content out of Drupal as
HTML or Markdown, but haven't yet posted it anywhere. I
should do this in the next day or two so that I know what's
up.
I have had other blogs as well. I had a Ghost instance up to
blog EVE Online stuff; I'm not even sure myself what the
current status of that content is. I think I blogged there
for about a year around 2018? I have had various blogs for
Google Summer of Code back when I was participating there,
although they were very light on content.
Notably, I have a super-secret blog. As far as I know, only
one very close friend knows of it. It doesn't have much
content, but it contains things that were on the one hand
sensitive enough that I was afraid to have them associated
with me (especially pre-tenure), but on the other ok enough
that it wouldn't be an absolute disaster if it got out.
Things that I decided I didn't want on the Internet at all
are squirreled away in that directory I talked about last
post. Thoughts that must never, ever be on the Internet are
not on any computer anywhere: I'm not silly.
You can also find many years of my comments on Reddit, or
even dig my old Usenet days out of the Usenet archives to a
certain extent.
So… yeah. I obviously like to write stuff and publish
it. I'm not sure why I let blogging go for so long. Good to
be back.
2022-08-13 00:02:35 PDT
A future blog post here will cover — as thoroughly as I can
manage — my old and dormant blogs. I have had a bunch.
I'm too tired to do a post that detailed and careful
tonight. Instead, I want to talk about a weird side thing
I've been doing.
One thing I learned long ago is to carefully read anything I
am about to post on the Interwebs to make sure it actually
belongs there. I think think twice and then often cut
once. Since 2006, I have saved some 440 files, 109,000 words
of text that I wrote and then "threw away". Most anything
complex is there.
109,000 words is a lot. I have no idea how it piled up like
that.
-
The longest single piece, an
Ingress leveling guide written
in HTML in 2013, is only about 3800 words, even using an
inflated notion of word length.
-
Nearly the same size is the second-place piece: a
transcript of a conversation on Hangouts with my friend
Sergey in September 2014 while his hometown of
Mariupol, Ukraine
was being shelled by Russians. Dammit. I hope Sergey is OK
in the current conflict. I know he got out of Mariupol
years ago, but last I heard his parents were still
there. So scary; so sad.
-
The third-place piece is a PDF draft, of all things, in
which I rant in 2008 about why I am quitting the
GPL. Spoiler
alert: I calmed down a bit and didn't actually quite
quit using the GPL. That said, I still stand by most of my
unpublished writing.
-
At the other end of the spectrum, a lot of these pieces
are just little snippets like this from August 2016:
I know, right? It's been a good seven years since the
SLC Police charged a gay couple with
public kissing.
Anyway, that could have happened anywhere in the US
in 2009. Right?
...Right?
I have no recollection what prompted me to write that. It
was probably in response to some
Reddit thing. Anyhow, I clipped it
instead of posting it, and there it is.
I keep all of this in a directory called blog. The intent
is that I go back and mine it for future blog posts.
Someday I'll do that. For today, just thought I'd point out
what might be a bit of a novel approach.
2022-08-12 00:13:20 PDT
The problem of commenting on blogs is bigger than many
non-bloggers realize, I think.
I wrote a blog for many years in the now-distant past. My
blog collapsed for technical reasons that I will cover in a
future post. (I have written many blogs. This was just the
big one.)
Perhaps the largest non-technical problem I had was dealing
with blog comment spam. I got a high enough pagerank back
then that I'd get on the average of a spam comment or two a
day. Real comments were pretty rare except on one vaguely
viral post.
The spam I was seeing looked like it had been generated by
an extremely low-paid human. I had enough captchas and
whatnot in place to make it hard-ish for a bot to comment,
and the comment content seemed to be vaguely customized.
For me as a casual blogger this constant drip of spam was
painful. I eventually shut off comments. Now I'm up again on
GitAtom, which lacks any comment facilities. What should I
do?
My cousin uses some free version of Disqus for blog
comments. I could conceivably set that up. I have no idea
how well it would cut the spam down; I have mixed feelings
about Disqus itself. There are various open source
alternatives around. I could look into those, I guess.
There's various friendzone / pre-approval things I could do.
I really do like the world to be able to legit comment
though.
I've thought about taking advantage of Gmail's decent spam
filtering. I could request that comments be sent by email to
some dedicated Gmail account, then either manually or
automatically forward them to GitAtom if they missed the
filter. A lot of work, but might be worth it.
What do you think? Post your answer below… Nah, just
kidding. You can always email me if you like. I'll try to
pass on the good stuff here.
2022-08-11 01:19:54 PDT
Apparently this is the week in Blaugust where we are
supposed to introduce ourselves. Indeed, this week is
perhaps almost over.
I'm dead tired and need to go to sleep. I will introduce
myself as briefly as possible: no stories, no extra stuff.
I can do this, I know I can.
I'm Bart Massey. I've lived most of my life in Oregon,
except for a couple of years in Tennessee when I was in
early grade school. I spent the first part of my life in Portland, and after the
Tennessee thing ended up in North Bend. Upon graduating high
school I spent a year at Oregon State University, then four
years at Reed College, graduating with a physics degree in
'87. I spent two years working full-time at Tektronix, doing
UNIX admin, open source tools and digital signal
processing. Then I went back to grad school at University of
Oregon, where I got my thesis MS CS in programming language
implementation doing concurrent logic programming, then my
PhD CS doing artifical intelligence. Slightly before
graduation I got a job at Portland State University, where
I've been a CS prof for over 20 years now. If you do the
math, you'll find I'm 58.
I have a loving wife who I've been with continuously since
high school, and one adult son who works as a software
engineer here in Portland.
My hobbies include reading, programming, making music (piano
and a little guitar and voice), playing poker, and too many
other things to list. I am low A Tier at trivia and
worthless at athletics and related pursuits. I am a poor
follower of Jesus, but not a participant in any religion; I
am not the least bit evangelical.
I like to explore and create. I am more than usually lazy
and disorganized, with few time management skills.
That is about as small a wall of text as I can
manage for now. I expect I'll be telling you more
regularly.
2022-08-09 22:49:04 PDT
I restarted blogging as part of
Blaugust. The
soft goal of Blaugust is to blog every day during the month
of August. That is an achievable schedule for me;
nonetheless, I already fell behind this month, though I have
now caught up.
I am also working ahead a bit. The conventional solution to
the problem of regularity in the web publishing world is to
build a "queue" or "buffer" of upcoming posts. A buffer
famously cannot match rates, but is great at smoothing
irregularities. Readers like regular posts, while writers
like irregular writing.
GitAtom doesn't currently have any explicit support for
queueing. Because of the way the platform works, it is
straightforward to write posts ahead and put them aside for
later. This is the main thing that is needed. However, the
process of pulling queue entries and posting them should
arguably be automated based on intended posting
frequency. If I don't have the time or will to write a post
on a given day, I probably also don't have the time or will
to interact with my blog at all that day.
Sigh. Added to the issue list.
2022-08-08 10:35:01 PDT
When I made the decision to
blog on GitAtom a week ago,
I knew that dogfooding GitAtom would be both a great way to
improve GitAtom and a giant pain. Both the improvement and
the pain have exceeded my expectations. I've posted a
half-dozen new GitAtom issues and closed a bunch of
them. I've engaged with some "hard" issues and emerged, if
not victorious, at least kind of satisfied.
Hopefully FOB4 has become easier to read as the result
of my efforts. It has also become easier to blog with, for
what that's worth. I'm afriad that FOB4/GitAtom remains more
creator-friendly than reader-friendly.
Adding an Atom feed is the penultimate can't-live-without-it
reader improvement on my list. I will try to find time in my
currently-insane schedule (more because of my laziness and
disorganization than because I have more than a person
should be able to do) to get a feed up over the next few
days.
(The ultimate must-have feature is allowing some kind of
commenting. More about that in a future blog post.)
Sadly, I think the whole GitAtom hairball is due for some
fundamental rethinking. I don't want to do that rethinking —
I just want to blog. I don't want to document the GitAtom
architecture extensively, re-architect it, document that,
and re-implement/refactor big pieces.
I would switch blog software in a second if someone told me
of the right platform. Unfortunately, I don't know of
anything super-close to what GitAtom provides for blogging.
Such are the woes of a geek who blogs, I guess. Thanks for
listening.
2022-08-08 00:28:44 PDT
Passed my Amateur Radio General Class examination today.
(My friend Keith passed both General and Extra. I'll do
extra soon too.)
I didn't do as well as I hoped on the test. Ah well, passing
is passing.
Should be doing voice on HF reasonably soon.
2022-08-07 23:29:19 PDT
At RustConf Friday I had dinner with a bunch of really cool
people. I especially enjoyed talking to a couple that was
seated with me; we chatted for several hours. One was a tech
geek like myself (except smarter and harder working, I
suspect). The other was a school nurse in a rough major
city. You don't get to meet IRL heroes that often. It seemed
like we had a lot of common interests and topics…
Ah, yes. I was talking about Jeopardy!, wasn't I? (The
bang [!] is part of the name, if you didn't know. Game shows.)
Somehow the topic came up, and I mentioned my "scoring
system" for playing along at home.
There is a standard scoring system used by those aspiring
to become Jeopardy!
contestants. Coryat Scoring
is a system developed for comparing contestant skill.
Reportedly many home players try to get some
minimum average Coryat score before trying to get on the
show.
I don't have any strong ambition to be a Jeopardy!
contestant. It would be pretty cool, but I'm just not
willing to put in the work. For me, trivia is supposed to be
relaxing fun. For someone aspiring to Jeopardy! greatness,
there's not so much fun to be had.
Unfortunately, Jeopardy! recycles a bunch of topics. A
lot. See how many episodes you go without seeing one or more
of the following:
-
A question that is easy if you have memorized the US
Presidents and Vice Presidents, their sequence numbers,
and their dates in office.
-
A question that requires you to know the capitols of the
50 US states, or vice-versa.
-
A question that requires you to distinguish between
Luxembourg, Lichtenstein, and Monaco.
-
A question about the life and works of Jane Austen and/or
the various Brontë sisters.
-
A question involving Robert Frost or Robert Burns.
-
A question asking about a European mountain range.
I could go on (oh could I), but you get the idea. To be
solid at Jeopardy, it's not enough to just know actual
trivia. You need to first survey this body of knowledge by
digging through gobs of old game records and trying to see
what the "Clue Crew" (who writes the questions) is up
to. You then need to memorize quite a bit of information to
cover this gap. Sounds like a lot of work for a lazy person
like me.
What I take pride in is my knowledge of actual "trivia
trivia". The kind of stuff that you would never be able to
predict or prepare for by study; you just have to know. I
know what a finial is, what Matthias Rust did, what Hanlon's
Razor says and who (probably) coined it. I didn't learn
these things by studying, but by learning and remembering.
Sooo… Here's how I score Jeopardy! when playing at home:
-
I may only score on questions that are not correctly
answered by the in-game contestants. This includes regular
questions not correctly answered by any of the three, and
Daily Double questions not correctly answered by the
contestant tasked.
-
I give myself one point for each such question that I get
correct. I do not subtract for those I get wrong: I allow
myself to guess freely.
-
If I answer before a player attempts a question, I may
change my answer after they fail.
-
Final Jeopardy is scored separately. I give myself an
"Ace" if I get Final Jeopardy and the other players do
not.
It is very rare that I score zero in a game. I would say my
average is around 3-4. The other night I scored 10 plus an
Ace.
Am I proud of that? Of course I am. But I'm also
concerned. The quality of contestants had definitely seemed
to slip during the last two years, for obvious reasons. But
I was expecting it to come back, and with a few notable
exceptions, I don't feel like it has. The clues seem like
they're getting easier, and yet we still seem to get a lot
more games with a lot of unanswered or incorrectly-answered
questions than we did a few years ago.
The quality of clue-writing has also seemed to me to be
declining lately. It is much more often that a clue seems to
be ambiguously or just poorly worded. It is much more often
that my wife and I stare at a wall-of-text clue hoping to
just understand what the question is. For a while, there was
a very strong reliance on things not interestingly related
to trivia questions (don't get me started on Celebrity
Before and After), although thankfully it seems to be
winding down a bit.
Anyhoowww… I was talking with this nice person at the dinner
and mentioned my scoring system and she looked at me
astonished and said "I though I was the only one who scored
like that!"
So that was cool.
A: It's the GOAT of gameshows, but also a course of constant
friction and confusion: dangerous people on a dangerous show.
Q: ?
2022-08-07 00:19:18 PDT
So I've had my last two days completely consumed by
RustConf 2022. In particular, I'm somehow leading something called
Rust-Edu which is intended to get the Rust programming
language into academia.
tl;dr: I've already missed a Blaugust blog post.
This is a blog post to backfill yesterday's void. Tomorrow I
will write one to fill today's void, and another for
tomorrow.
So it goes.
2022-08-04 18:39:02 PDT
Still fighting the technical demons here, but while I do
that I thought it would be good to say what this blog should
be about…
-
Technology: I am a technologist — a computer
scientist, software developer, and hobbyist. I sometimes
know things, and want to share them.
-
Creativity: I like to make and build interesting
things — writing, music, electronics, etc. Sharing that
seems fun too.
-
Opinion: As someone voted Most Opinionated in my
High School class (seriously), I sometimes want to share
my opinions with the world.
-
Miscellaneous: So much miscellaneous.
I hope you will enjoy some of it once I get good and rolling.
2022-08-03 19:53:55 PDT
This week my posts are kind of obsessed with process. Sorry:
it's a boring way to start Blaugust. But it is what it is: I
need to understand how to make my blogging process more
permanent, and I'd like to keep a record of successes and
failures.
So… much of yesterday was spent fixing
GitAtom issues.
I closed an issue or two and fixed some minor bugs. This
site seems usable now for blogging, if a little fragile and
weird.
I'm not yet sure whether choosing GitAtom was the right
choice. Something like Ghost
that I have used in the past might have been better. It
offers many of the advantages of GitAtom, along with a
fully-developed and polished experience.
GitAtom offers two things that I don't know how to get
otherwise:
-
Low-friction Git-backed Markdown blogging with remote
publishing. Lots of systems offer some subset of these
features. I know of none that offers the whole package.
-
Absolute zero lock-in. By maintaining blog content in
100% standard open formats, and code as fully open-source
extremely simple Python, GitAtom ensures that both
repairing the existing codebase and migrating content
elsewhere are easily achievable.
I have built code to extricate my old blog content from
the clutches of an ancient version of
Drupal when I could no longer
maintain or upgrade my
site. blog-escape
is incomplete and ugly, and does a poor job. I don't
want that experience again.
What GitAtom
doesn't offer
is an Atom feed.
Yes, I know. Being easily able to provide an Atom feed was
one of the big selling points of storing all the content in
Atom syndication format.
The code never got written. The Atom feed files being saved
by GitAtom appear
not to be RFC compliant,
which will need to be fixed before trying to generate a feed
from them.
So now I have two projects.
- Blog daily for Blaugust.
- Fix my blogging tool — in particular by adding an Atom feed.
Will admit to discouragement, but it has to be done. Onward.
P.S. — While trying to find blog-escape above I Googled
"bartmassey blog rescue". I got a hit for
this book,
which confused me mightily for a moment. Needless to say, I
am not the Bart Massey who wrote this book with an oddly
relevant keyword.
The interwebs are weird.
2022-08-02 19:49:47 PDT
A couple of decades ago, I had a bunch of students who had
all done substantial research work: I think about eight of
them? One or two MS and a bunch of undergrads. The
opportunity came up for the students to present at a
University-wide student research Poster Contest. I generally
don't like Poster Sessions; I think they're kind of a bad
cross between a presentation and an article. But I thought
it would be fun to flood the thing, so I brought the whole
bunch of 'em — each with a lovely poster. (Coincidentally,
so did one of our Physics profs. It was kind of hilarious,
actually. Between the two of us I think we had about half
the presenters.)
Anyway, if you're going to bring a team, you need a team
uniform. So I had hats made. I designed a "Friends Of Bart"
FOB logo and Keith Packard and I rendered it in SVG using
our Nickle programming language.
We looked ever so stylish.
That day the FOB "brand" was born. I've been using it ever
since.
2022-08-02 18:49:47 PDT
I have been using DALL-E to
generate some of the images for this site. These images are
captioned with the prompt I gave DALL-E to produce them: I
then selected the best of the four given choices.
Many thanks to OpenAI for the Beta DALL-E access. Hope this
will be fun for everyone.
2022-08-01 18:20:33 PDT
I decided to take a shot at
Blaugust 2022
this August. Sadly, I don't have a blogging tool I'm really
happy with at this point.
I'm going to try to dogfood
GitAtom as my
blogging tool. GitAtom was written by my students to make Keith
Packard and I happy. Sadly, it wasn't quite completed, and
needs quite a lot of work. Nonetheless, I'm going to see if
it can work for the month, and fix it as I go.
More tomorrow. Wish me luck!