It is a surprisingly fertile metaphor:

It isn't inherently good or bad to do.

You don't have to do it at all if you don't want to.

You can want to do it with someone even if you don't desire it yourself.

It can be embarassing and intimate to do it with someone new.

You can be casual with it and do it with anyone.

You can keep it between just two of you.

You can do it in public, as a performance, if you want.

You can never admit you do it at all and keep it private.

You can like doing it and talk about it all the time even if you don't do it very much.

Who you choose to do it with is your choice.

You can do it in groups, or just one on one.

You can be there for other people and not participate.

Sometimes, people will pressure you do to it, because "everyone else is."

It can be bad for you if you're pressured into it.

It can be good for you to push yourself to experience new things.

Nobody has to know if you do it.

If someone films you doing it and posts it online without asking that can be violating.

I don't think this means Sex and Karaoke are somehow special in this respect, just that they're both intimate, social, deeply human things we do together and any ways that people can be good or evil or controlling or liberated by anything like that, this would apply to.

Just a thought. Don't take me too seriously.

I recently found someone 1 talking about Alive Internet Theory and it's such a good name. As contrasted with the more existentially horrifying thought of Dead Internet Theory, where 'everyone on the Internet is a bot'.

I like the idea that we can choose to focus on what is (still) alive about the Internet. It's what the "Small Web" 2 and IndieWeb idea is about. That there will always be people who want to share what they know, what they're thinking, what they had for breakfast. Pictures of their cats.

And I like the idea that it's not the exclusive purview of the world of nerdy self-hosting and technologists that see any centralization, any reliance on big tech as a failure. The Alive Internet can still exist in spaces that are associated with the Dead Internet. You're primarly a target for advertising there. But the whole human is always still there, and we can still connect with each other through any media we are given.

For thousands of years the best we had was written communication that could take months or even years to arrive. The Internet still connects us in a fundamentally magic way, if we look even a few decades back in history. Publishing is instant, and global. We can write, but also sing and dance and show each other our lives in high-definition video.

So, we need to be in the open, as people, and visibly real. I guess this post is a bit of my contribution, declaring that I'm a real person, and this is my little corner of the Internet. Hello! I am Alive. 3

The Internet only dies to the bots when there's none of us left, so… stick around. It's nice here sometimes.

This isn't a fully formed thought, but I was thinking about some of the ways I have seen people write about their experience of using AI tools.

That they feel like it's "addicting", that there's a "rush" or pleasant feeling when it works. That it doesn't always work, so you have to keep trying.

This sounds an awful lot like gambling addiction. Or any other conditioning based on intermittant reinforcement. Which is more effective conditioning than consistent reinforcement.

It has nothing to do with how useful the LLM, the diffusion model, etc. actually is. The thrill of pulling the lever to see if it will pay off is what drives it.

That's why people can like it and not feel like it's any good at anything. That's why productivity measurements can tell us that these systems don't help that much, or might even hurt productivity, and people still want them. Still want to use them.

Sacrificing your professional appearance, your unique voice in writing—your compentence—at the altar of LLM supremacy is perhaps less dire than gambling away your retirement savings and mortgage payments. But I'd think it would still be seen as negative—some sort of harm.

Gambling isn't illegal, and it's not even the fundamental act of wagering that is the source of the problems with it. It's the conditioning, the addiction, the harms of what it takes away from people.

LLMs seem similar. Using an LLM itself isn't a problem or inherently harmful; relying only on it is the concern. Constantly thinking about using it, preferring it to anything else. Avoiding using your own voice, your own skills, your own professional taste in order to get another hit from the magic word machine.

I'm not sure we have a perfect solution in society for how we mitigate the harms of gambling. Some countries ban it, stigmatize it, etc. Some places are mixed; certain kinds of it are allowed (sports betting, video slots, government run lotteries) and others are prohibited (table games, private lotteries).

But I don't think there's any society that doesn't have an opinion on the harms and how to deal with them. Discussion needs to happen, and it needs to be in the broader context of society. Whether the topic is LLMs, diffusion models, other generative systems, simpler machine learning tools, or plain automation.

A society of degenerate gamblers is not desirable. A society where everyone relies on LLMs is a similar sort of extreme. I'd argue both are failures in similar ways. A society that has failed to adapt and integrate a specific technology with human nature and behavior in a way that is healthy.

I'm not sure isolating raw LLM use to some equivalent of a 'den of sin' like a casino is a good strategy, but limiting how they can be used, offered to the public, trained, etc. seems not very different than regulating how games of chance can be sold, played, and manufactured.

I don't like relinquishment 1 as an approach to potential harms that can come from a technology, but a complete lassez-faire approach is not the only other option.

Computers store information. A representation of information. All of computer science stems from the insight that we can build machines which store, transform, and output information.

Whether it's punch cards, magnetic tape, wire-wrapped memory, or moden flash, DRAM, and optical discs. The representation of it—physically, as well as logically—is something imposed by a person onto the medium.

It's easy to think that there's some inherent naturalness to writing systems, or to binary representation in computers. The latin alphabet, cuneiform, and all other writing systems are ways people have imposed structure on physical objects in order to use them for storing ideas.

The mathematical insight that binary is as simple a model for structured information as you can construct has served computer science well. It's universal, simple, and infinitely flexible. It's useful. But the representation of information is not the information itself.

Or, rather. The information—the structure and organization of it—is possible to observe, but the meaning of it doesn't exist in the representation. The meaning exists in the human that reads it.

Words on a page, or spoken aloud do not magically conjure ideas into the minds of others. The language needs to be shared. No matter how obvious, simple, and straightforward the sentence is, I will not understand someone speaking Hindi. I can recognize that it's a language, that there is structure. That it's being spoken by a person, or that there is a complex arrangement of symbols that must be a writing system. But the meaning will not appear in my mind despite the information—seemingly—containing it.

And it's the same with any other information processing and storage system we have invented. The computer does not know the meaning of what it is doing. It does not know anything. The representation 0x41 0x20 0x68 0x61 0x6d might be a sequence of small numbers, it might be one large number (279716585837), or might be the text 'A ham'`. The knowledge of how to interpret it (the 'type', if you think like a programmer) is required to know which meaning to impose on the data.

And while we can 'tell' the computer that this area of memory, or this file field, database column, etc. has a specific type, we still fundamentally rely on the human seeing the representation (transformed as we have instructed) to derive meaning.

Which leads to the thought that the underlying representation doesn't contain the meaning. A distinction that seems very subtle and not that interesting except to philosophers.

Except.

Large language models, and other generative AI systems, have started to make that distinction more and more clear. They have entered into the zeitgeist of business and culture.

And they are able to produce complex derived representations. They consume everything ever written, ever drawn or photographed, and they compute and transform it. But the meaning isn't what is being modeled. 'Merely' the representation.

Words coming one after the other, following English vocabulary and grammar. Related to the prompt that solicited them. But the meaning, or lack of it, is imposed by the human that is reading them.

The meaning doesn't exist in the model. Despite all the talk by machine learning papers of finding and encoding more and more of the 'semantics', it is still fundamentally limited to processing the representation.

Meaning exists only in the communication, in the audience, the reader. You might argue that the LLM training process is where the meaning is interpreted by the system. I'm not sure. An LLM isn't all that similar to a brain. The 'magic' of them is their size and scale, that they don't need to be built to model knowledge or anything more sophisticated than 'next token'.

It is impressive how much 'merely' having an excellent way to statistically reproduce written language results in something people are willing to believe is thinking—that it is responding to their questions.

But the meaning is in the audience. People who are willing to impose all sorts of sophisticated thinking on the LLM are the ones who can also fall into delusions that it loves them, understands them. That is has some powerful connection to the cosmos and knows them personally and can guide them through their lives.

That it wants to help them.

That it can replace their real friends or relationships with 'better' ones.

That comes from the people thinking it. The meaning is external to the model.

Poetic phrasing aside, I think this observation is becoming clearer and clearer to the public as they interact more with these LLM and other generative AI systems.

Alone, they do not produce meaning, art, creative expression, or otherwise. They do not know things, they cannot think.

Meaning is what we impose on a work, what we see in the information in front of us. Merely producing more information to try to find meaning in does not solve the problem, it makes it worse.

I don't have experience with generative AI systems, they're all... integrated in tools I don't use or behind some corporate interface I'm not going to touch with a 10-foot pole.

But like any curious technologist, I read about what people are doing, what they're saying they use it for, how they think you should use it best, etc.

And I'm starting to feel—not obsolete, as the proponents of generative AI systems predict—but like everyone is missing the point of writing software.

Yes, source code is a tool, a means to an end. A way of expressing the precise outlines of what software does. It's the interface between the human and the computer. The interface. Anything else built up on top of it is the software's interface to a user. And that's ultimately very important. But source code is for people to read and write.

So when you tell me that you're writing software where you can use a generative AI tool to spit out so much "boilerplate," I don't see that as a useful expenditure of engineering effort. Not to build the tool that can generate the boilerplate, not to build software with that much boilerplate required.

The goal, in my mind, across all of software engineering has been to eliminate the inessential, the boilerplate, the tedium. Papering over it with a tool is different than creating an abstraction for it.

So using generative AI feels like a rejection of the idea of writing better software. A rejection of an engineering approach. It's capitulating to the complexity and refusing to manage it, refusing to make it comprehensible, predictable, or reliable. Since the state space is so large, 'giving up' and getting an approximation of what you wanted and then massaging it into as good as you can get may be pragmatic, but it's certainly not engineering.

In the long term, if generative AI / LLM systems really are the future of software development, they're not going to be writing in human-centric programming languages, I'd expect. Why bother with all that abstraction and tooling. Just have them output a binary the CPU can run. All the structure is still in the binary, and you eliminate the tooling in-between. Programming languages are for people. LLMs deal in 'tokens'. Why wouldn't you train an LLM to produce an ELF binary from a prompt?

If that's really the end game? I'm not sure how we could really trust any software built that way. You can test it, perhaps close to exhaustively on specific cases that you care about. But without demanding an explanation of every aspect of the software, every machine instruction, you can't trust it. And even then, can a person verify the explanation? For any sufficiently useful software artifact, I expect not.

Maybe that's the goal, that software engineering is no longer necessary, that this whole technology is a paradigm shift where technology works like it does in Star Trek or the wildest imaginings of Sci Fi authors. But that seems too optimistic, too willing to throw away everything else for a world that we would hope comes to be.

More moderate aspirations predict LLMs to be tools used by the engineers, and while that's a sensible and not-quite-worldchanging prediction. I've yet to see a reason why the complexity and resource costs of LLMs justify themselves.

Building better abstractions to solve your problem. Eliminating the need for boilerplate and tedium in souce code. That is just as—if not more—powerful. And it doesn't require a cloud subscription to a GPU farm, just the good software engineers you're already paying.

Linux is a networking swiss army knife, in my experience. There's many ways to get things configured to accomplish your goals, and plenty of choices you have to make to get there.

Distributions have different tools and configuration strategies, and software that has to interact with networking has its own perspective on what it needs to do.

ip link add type bridge br0
ip link set up br0

ip link set dev eth0 master br0
ip link set up eth0

ip link ls type bridge

ip link ls master [bridge interface]

nmcli con add type bridge ifname br0
nmcli con up bridge-br0

nmcli con modify eth0 connection.master br0 connection.slave-type bridge
nmcli con up eth0

ip link add type vlan link eth0 vlan1234 vlan id 1234

ip link set dev br0 type bridge vlan_filtering 1

ip link set dev eth0 master br0
bridge vlan add vid 1234 dev eth0

bridge vlan add vid 1234 dev vnet1 pvid untagged

bridge vlan add vid 1-4094 dev eth0

nmcli con modfiy bridge-br0 bridge.vlan-filtering 1

nmcli con modify eth0 bridge-port.vlans "1-4094"

nmcli con modify vnet1 bridge-port.vlans "1234 pvid untagged"

virsh metadata test-trunk http://enimihil.net/libvirt/vlans --key vlan --set "$(< metadata.xml)"

<vlans>
  <vlan interface="52:54:00:4b:32:36" vid="1234"/>
  <vlan interface="52:54:00:4b:32:36" vid="1235" untagged="yes" />
</vlans>

#!/bin/bash
set -xe

export LIBVIRT_DEFAULT_URI=qemu:///system

NAME="$1"
MEMORY="$2"
DISK="$3"

# Create guest from disk image. Do not start it.
virt-install \
--import \
--network model=virtio,mac=52:54:00:4b:32:36,bridge=br-trunk \
--memory "$MEMORY" \
--name "$NAME" \
--disk "$DISK" \
--osinfo detect=on \
--noautoconsole \
--noreboot

METADATA_XML=$(cat <<HERE
<vlans>
  <vlan interface="52:54:00:4b:32:36" vid="1234"/>
  <vlan interface="52:54:00:4b:32:36" vid="1235" untagged="yes" />
</vlans>
HERE
)

virsh metadata "$NAME" http://evolvecellular.com/libvirt/vlan --key vlans --set "$METADATA_XML"

virsh start "$NAME"

Containers are pretty useful, like a chroot that's been given extra powers, to isolate networking, user ids, pids, and all sorts of other things. And without the overhead of a whole virtual machine. However, that does limit them to running software that would actually run on your actual machine.

I use a ppc64le machine as a daily driver, so lots of things are 'awkard', if they assume that x86_64 is the only thing that exists. However, there is a tool that can emulate other CPUs and run programs in a different instruction set: qemu. You don't—it turns out—even need to emulate an entire hardware platform, or need special virtualization-specific support (that's just for speed). A qemu user emulation tool can run binaries for a foreign architecture (but otherwise compatible with your OS kernel) by emulating the CPU and translating system calls.

User emulation is already a lot like a container, and can make things like certain kinds of cross compiling or development work easier (as well as making it possible to run proprietary software on your architecture of choice).

On Gentoo, you need to have app-emulation/qemu set up to include the architectures you want to emulate in the QEMU_USER_TARGETS use_expand variable. (And for using this within containers, you want the +static-user useflag set as well).

Then, assuming you have a C program like this:

hello.c (Source)

And you compile it for a different native and non-native architectures

$ gcc -o hello-ppc64le-dyn hello.c
$ gcc -o hello-ppc64le --static  hello.c
$ x86_64-multilib-linux-gnu-gcc -o hello-x86_64-dyn hello.c
$ x86_64-multilib-linux-gnu-gcc -o hello-x86_64 --static hello.c

We can then run the two native ones, and see the expected output.

$ ./hello-ppc64le-dyn
Hello from main()
$ ./hello-ppc64le
Hello from main()
$ ./hello-x86_64
bash: ./hello-x86_64: cannot execute binary file: Exec format error
$ ./hello-x86_64-dyn
bash: ./hello-x86_64-dyn: cannot execute binary file: Exec format error

The qemu-x86_64 program can run these, however.

$ qemu-x86_64 ./hello-x86_64
Hello from main()
$ qemu-x86_64 ./hello-x86_64-dyn
Hello from main()

(Assuming the cross compilation setup has the right environment for the dynamically linked version)

The Linux kernel has a feature that allows configuring an interpreter for these binaries, in much the same way that you can embed a #! (shebang) line into a script: binfmt_misc.

This can be configured through various mechanisms on different distros, but on Gentoo the openrc init system supplies a /etc/init.d/binfmt service to enable that mapping by dropping a file into /etc/binfmt.d/.

Mine looks like this:

qemu-user.conf (Source)

So with that file in place and /etc/init.d/binfmt start (run as root, and possibly enabled as a boot service).

We can then just run the non-native executables 'normally':

$ ./hello-x86_64
Hello from main()
$ ./hello-x86_64-dyn
Hello from main()

This is pretty cool, and useful on its own, but you quickly have to figure out how to install dependencies and deal with a project's build system to really use it for much other than toy examples.

But we can use the static binaries directly in a container, if we want.

Containerfile.x86_64 (Source)

Then executing:

$ buildah bud --platform=linux/amd64 -t localhost/hello:x86_64 Containerfile.x86_64
STEP 1/3: FROM scratch
STEP 2/3: COPY hello-x86_64 /
STEP 3/3: CMD [ "/hello-x86_64" ]
COMMIT localhost/hello:x86_64
Getting image source signatures
Copying blob 0efe8d85f660 skipped: already exists
Copying config 6326d28447 done
Writing manifest to image destination
Storing signatures
--> 6326d284477
[Warning] one or more build args were not consumed: [TARGETARCH TARGETOS TARGETPLATFORM]
Successfully tagged localhost/hello:x86_64
6326d284477b07a5e60adbda3a8861f7ffabf4e49a55fd24706c143dd2622b95

We then get our container built, and can run it:

$ podman run --rm -it localhost/hello:x86_64
Hello from main()

And that works great, but if we try the dynamically linked version:

Containerfile.x86_64-dyn (Source)

$ $ buildah bud --platform=linux/amd64 -t localhost/hello:x86_64 Containerfile.x86_64
STEP 1/3: FROM scratch
STEP 2/3: COPY hello-x86_64-dyn /
STEP 3/3: CMD [ "/hello-x86_64-dyn" ]
COMMIT localhost/hello:x86_64-dyn
Getting image source signatures
Copying blob 14266541c9b2 done
Copying config 6e4c2c5dfb done
Writing manifest to image destination
Storing signatures
--> 6e4c2c5dfbd
[Warning] one or more build args were not consumed: [TARGETARCH TARGETOS TARGETPLATFORM]
Successfully tagged localhost/hello:x86_64-dyn
6e4c2c5dfbd8eb283d51b4929229561fd10a1df4439d97646d6b3a29355ea95e

$ podman run --rm -it localhost/hello:x86_64-dyn
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

We get something different. The dynamic executable requires the dynamic linker within the container, and we only put the executable file there.

But we are able to execute the binaries through qemu-x86_64 just fine, even within the container, whose own root filesystem doesn't have the emulator to suport our native CPU.

But the dynamic linker would work if a whole chroot-style image was present in the container.

Doing a simple podman run --rm -it docker.io/library/ubuntu:latest will pull an appropriate image for the architecture we're running on, and we can see that if we use skopeo to inspect the image locally:

$ podman run --arch ppc64le --rm -it docker.io/library/ubuntu:latest
trying to pull docker.io/library/ubuntu:latest...
getting image source signatures
copying blob 6f8c2fc0a4f9 skipped: already exists
copying config fb133e10be done
writing manifest to image destination
storing signatures
root@6e00a22706a8:/# uname -m
ppc64le
root@6e00a22706a8:/#
exit
$ skopeo inspect containers-storage:docker.io/library/ubuntu
{
    "name": "docker.io/library/ubuntu",
    "digest": "sha256:4e5d0032fffc670be1788b945476b5997b29b50aec6e84af7a76e8fb030c4326",
    "repotags": [],
    "created": "2022-08-02t01:31:14.74904496z",
    "dockerversion": "20.10.12",
    "labels": null,
    "architecture": "ppc64le",
    "os": "linux",
    "layers": [
        "sha256:6f8c2fc0a4f976c1c0bd1c0e14022b3ed8b7c83cdb247c83016052c3678aaf28"
    ],
    "env": [
        "path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ]
}

But we can choose a non-native architecture, and assuming we configured the binfmt correctly and the image is available:

$ podman run --arch amd64 --rm -it docker.io/library/ubuntu:latest
Trying to pull docker.io/library/ubuntu:latest...
Getting image source signatures
Copying blob d19f32bd9e41 skipped: already exists
Copying config df5de72bdb done
Writing manifest to image destination
Storing signatures
root@159ea7cdac2c:/# uname -m
x86_64
root@159ea7cdac2c:/#
exit
$ skopeo inspect containers-storage:docker.io/library/ubuntu
{
    "Name": "docker.io/library/ubuntu",
    "Digest": "sha256:42ba2dfce475de1113d55602d40af18415897167d47c2045ec7b6d9746ff148f",
    "RepoTags": [],
    "Created": "2022-08-02T01:30:56.165288114Z",
    "DockerVersion": "20.10.12",
    "Labels": null,
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:d19f32bd9e4106d487f1a703fc2f09c8edadd92db4405d477978e8e466ab290d"
    ],
    "Env": [
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ]
}

Then we can see we were running the container with the non-native architecture just fine.

Using that container to build software, and to package for non-native architectures can all be done locally.

I live where a power outage, while not extremely common, happens often enough that I should have anything remotely valuable or sensitive hooked up to a UPS (not merely a surge protector). However, I recently relocated a bunch of my electronics, and my Talos II-based workstation currently lives in my home office without the benefit of a UPS.

I had a power outage that lasted only about 5 minutes, and appeared to be a straight blackout/cut followed by restoration. (Maintenance, cutover of a damaged circuit, whatever, no idea what happened)

This then, unfortunately, left my system unwilling to boot. The BMC LED on the mainboard would turn on at a quick flash when applying power, but the power buttons did not respond and the system would not completely turn on.

This implied the BMC, which controls power sequencing and bringup, was not functioning. After some troubleshooting to try to get a network connection into the BMC, it became apparent the BMC was at fault, somehow.

Eventually, that led me to this page on the Raptor Computing Wiki: https://wiki.raptorcs.com/wiki/Debricking_the_BMC describing the steps needed to restore functionality.

Firstly, I needed to get a serial connection to the BMC itself, which required ordering a bracket. It appears that no vendor actually specifies what pinout their brackets use, and at least on the Amazon listing I did order, the reviewer stated the pinout incorrectly.

Some jumper wires later, I got the serial connection hooked up and was able to see that on applying power, I got nothing but the SoC reset output. No u-boot output, nothing except the SoC continuously resetting.

So now I needed to find a way to reflash u-boot. The above-linked Wiki page shows a link to ASpeed (the SoC manufacturer) for a download of a "socflash" utility. However, in their desire to be as unfriendly as possible to anyone who won't pay them money, they've removed that tool from public download, and reserved it only for developer accounts (which require a sales contact to get).

There's a one-sentence statement that you can use flashrom to write the chip, with an external programmer, so that seemed like my best option, as I have a Segger J-Link which flashrom supports as a SPI programmer.

Now, to find the information I need on how to flash that chip. Since this is all fairly open, the chip is socketed, which means I was able to remove the flash chip for the BMC, and look up the pinout for it, and match that up against the flashrom documentation for using the J-link as a programmer.

Also of note is that when connecting pins on the J-link using an IDC cable, the numbering is mirrored relative to the key on the connector. (Pin numbering is for the pins on the J-Link itself)

With this connected, I was able to convince flashrom to read the existing image from the flash and verify that connectivity was working and the chip was recognized:

$ ./flashrom/flashrom -p jlink_spi -r bmc-rom
flashrom v1.1-rc1-115-g61e16e5-dirty on Linux 5.3.0-gentoo (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L25635F/MX25L25645G" (32768 kB, SPI) on jlink_spi.
Reading flash... done.

Now I just needed the flash image and some idea of how to write it.

Downloading the 1.07 firmware from the wiki, I ended up with a few files, and didn't know what to do with them.

Thankfully a few folks on the #talos-workstation channel on FreeNode were able to sort me out, providing the necessary context for me to know that the image-bmc file in the firmware download is the entire flash image combined, along with providing a link to the kernel DTS (https://git.anastas.io/dormito/br-blackbird-external/src/branch/raw-first-pass/board/bangBMC/blackbird.dts) which shows the range/offsets of the flash regions on the chip.

(Thanks to mearon, dormito, and hanetzer)

Thus I was able to construct a flashrom layout file:

00000000:0005ffff u-boot
00060000:0007ffff u-boot-env
00080000:0067ffff kernel_a
00680000:0077ffff dev-data
00780000:00d7ffff kernel_b
00d80000:01ffffff rwfs

Caveat with the above, I only tested writing to the u-boot section, so please use at your own risk and with a full understanding of what you are trying to accomplish.

And with some trepidation, write the u-boot section with the following command:

$ ./flashrom/flashrom -p jlink_spi -l bmc.layout -i u-boot -w image-bmc
flashrom v1.1-rc1-115-g61e16e5-dirty on Linux 5.3.0-gentoo (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using region: "u-boot".
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L25635F/MX25L25645G" (32768 kB, SPI) on jlink_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.

Leading to success, thankfully.

A bit of careful re-seating of the chip into the motherboard socket and I was able to get a fully booted BMC, and the rest of my system again, no worse for wear otherwise.

Firefox's Quantum update provides some significant improvements in performance and other general underlying technology things (that I don't fully understand, as I'm not a Mozilla developer). However, in their eagerness to throw away as much work from the community as possible, they crippled the ability of addons to cutomize the interface, instead turning addons into nothing more than glorified greasemonky scripts.

A lot of the interface customizations I want are possible with userChrome.css modifications, which I'm relatively comfortable with doing, it's limited to the specific profile in use, etc. It'd be better if there was a way to automate or any sensible documentation on that, but it's open source, you read the code and figure it out.

On the other hand, Mozilla seems hell-bent on completely removing the ability to change the keyboard shortcuts in any way. There are half-baked solutions that can only change shortcuts within the page, or only work if you're not on a "secure" page, whatever the hell that is. (i.e. it's fine to change the browser's behavior in GMail, but addons aren't allow to change the browser's behavior on the addon page... as if "inconsistently and partially" customizable is what anyone actually wants)

There's some information on how to modify the sources to change keyboard shortcuts, but it doesn't appear to have been updated for the latest releases. Firefox 64, in my case.

Now, since I'm running Gentoo, it's not a terribly difficult thing to patch the source, User patches are well supported, so all I need is a patch that changes the shortcuts how I want. Still not actually configurable, but at least I can make it behave.

listings/newtab.patch (Source)

What I want is for the New Tab action to be bound to C-T not C-N and to have New Window (on the off chance I ever use it) moved to C-S-N. (Unbinding entirely the Undo Close Window accelerator. Who uses that?)

Adding rocker mouse guestures would be nice, but I can live without the rest of the changes I've used in previous versions. (Mostly holdovers from when I used Opera.)