I'll put short writings that don't deserve an entire page here.
Generally, plants have common names that accurately reflect their classification. However, this doesn't always hold. A couple examples that grow near me are the Box Elder, which is a maple, not an elder, the Jerusalem Artichoke, which is neither an artichoke nor from Jerusalem (It's a sunflower native to North America, grown for its edible tuber), and the Eastern Redcedar, which is actually a juniper. However, my favorite has to be the Tulip Poplar, which is neither a tulip nor a poplar. It's actually in the magnolia family. It has large flowers reminiscent of a tulip, and unique, four-lobed leaves that look like the cross-section of a blooming flower, and is one of the tallest trees in the Eastern US.
Recently, I've noticed an odd bug with the systemd suspend service. I use a debian laptop,
and suspend my system frequently. Upon suspend, my system occasionally exhibits strange
behavior. Initally, everything seems fine, but the computer activity light doesn't switch
to the pulsing pattern it adopts upon sleep. When I wake the system, my networking is
disabled, and I am unable to fix this. If I try to reboot or power off, I am brought to
the sign in screen. If I try to reboot or power off from the command line, I am informed
that a poweroff event is ongoing, and nothing happens. For a while, I just had to force
shutdown the system to make it usable again. Eventually, though, I discovered that by
restarting systemd-suspend.service using systemctl, the problem is fixed. Restarting this
service makes the system sleep and wake a couple times, but once it's done, everything
works fine again.
This behavior only began fairly recently. Maybe it's due to me closing the laptop's lid
before the suspend is complete, or maybe it's due to a bug in the latest version of
debian. Either way, it's preferrable to the prior suspend bug I had, where the display
manager would occasionally refuse to start back up upon wake.
Around a month ago, I had to replace the keyboard on my laptop. It had been slowly deteriorating in performance over the previous several months, and was at the point where about ten
of the keys just didn't work anymore. So, I replaced it. Maybe three weeks later, My windows key stopped working. I use i3 as my window manager, and have the Windows key mapped as the
i3 modifier key. Periodically, it would just stop working. I thought it might have been my keyboard breaking again. Whenever this happened, I had to restart my computer. Eventually,
though, I decided to look up the problem to see if anyone had a solution. It turns out that I had been accidentally pressing Fn + Win, which activates the Windows Lock. All I had to do
to fix it was press Fn + Win again, and my problem would be solved. After I figured this out, I remembered that the Windows key has a little insignia depicting a lock containing
the letter 'W'. It seems obvious now that this was trying to tell me about the windows lock toggle.
I never expected the solution to be that simple.
Due to technical difficulties, this site was down for an unknown amount of time. I thought I'd write about the problem and how I fixed it, in case anyone runs into it as well.
This site is self-hosted on a Raspberry Pi, interfaced with via ssh. A couple of months ago, I found that ssh was refusing to connect. I chalked it up to a transient network issue, and
ignored it. Last week, I tried to connect again, through my local network. It still refused to connect. Even after I tethered it via ethernet, it still wouldn't connect. The next day,
I hooked it up to a display and keyboard, and found that the machine was failing to boot. Specifically, fsck failed when run on the root partition. The error stated that fsck was
unable to set superblock flags. After plenty of research, I determined that the problem was with the SD card. Apparently, when certain SD cards begin to fail, they trigger a failsafe
read-only mode to preserve the data. Despite the card being in read-only mode, the system doesn't realize that it is. With sudo, data can apparently be written. However, no actual write
occurs, and the data is unchanged. When fsck checks and ext4 filesystem, it writes data to the superblock indicating the process. When it reads the superblock back, however, these
flags are reset. This is an abnormal state, and fsck panics, causing the boot to fail.
To fix the problem, I had to buy a new SD card and image the new one with the contents of the old one. During the imaging, the read speed was capped at 6 MB/s. I'm not sure if the card
or the adapter was the cause of this bottleneck, but it was annoying nonetheless. This painfully-slow read meant that transferring the contents of the ~24GB root partition took more than an hour.
Now that the transfer is complete, though, the server is fully operational again. Hooray!
I'm working on overhauling how cutscenes work in my game engine, stellar-enigma. Along with changes to function, I decided to change how they are
stored externally. Previously, they used the `explor format', a relic from a previous project. The explor format consists of a series of integer fields, delimited by backticks. Each
line corresponds to an entry (i.e. cutscene event, entity, texturemap entry). Each of the fields is assigned to an attribute of the entry, but no headers or labels are included, which
makes editing the files a real pain. To make this somewhat easier, each file contained a commented line explaining what each field did.
This format is awful to work with, so I decided to migrate to json. I rewrote the cutscene loader functions to read the new format, and eventually got it to load properly. However, when
I tested cutscenes in-game, they weren't properly playing. This confused me, as I hadn't modified the cutscene player functions at all. Only the loading functions had any changes.
Using a debugger, I eventually tracked down the problem - The first event of each cutscene was being skipped. (Both in-game cutscenes are two events long, with the first event being the
noticeable part). This was perplexing. I hadn't changed the cutscene player logic at all, so the diverging behavior seemed illogical.
Eventually, I realized what was going on -- The old code was also skipping the first event. I went through the old code once again, and found that it handled comments in an unintended
way. When a parsing a cutscene file, an unitialized event is created, then a comment is checked for. If the line is a comment, the line is never parsed into an event, but nothing else
is skipped. However, at the end of this procedure, the event is appended to the event list regardless of if the line is commented or not.
My helper comments at the top of each file were leading a garbage event to be added to the beginning of each cutscene. This would then be skipped when the cutscene loaded.
As each cutscene had exactly one comment, in the exact same place, I never noticed that garbage events were being created.
The only reason this bug flew under the radar was because the problems with the cutscene player & file loader happened to perfectly intersect with a quirk in how I commented my
asset files.
I guess the moral of the story is to test your code more rigorously. If I would have tested the cutscene reader on a more varied set of files, I could have fixed the comment bug. This
would have made the cutscene player bug obvious far earlier in development.
Seemingly innocent design decisions, such as comment placement in an asset file, can have significant ramifications for a project's code quality.
In this case, the only problem was erratic behavior in a tiny game engine (that no-one but me will likely ever use).
In a more important piece of software, however, serious consequences could result.
A couple of years back, a coding mistake in a java logging library led to an Arbitrary Code Execution bug in the best-selling video game of all time, Minecraft. (Log4Shell) Before that,
an oversight in OpenSSL, the library used to secure a significant portion of encrypted internet traffic, enabled bad actors to read confidential information from a server's memory.
(Heartbleed)
Stupid bugs can have serious consequences. Test your code. Check how it responds to unexpected input. Especially if it has access to important information.