Recently, I implemented a RISC-V simulator and assembler in AWK: awk-riscv. This started as a joke, evolved into wanting to prove a point (namely, that AWK being a Turing-complete language, can compute anything which is compute-able) , and ended up being a lot of fun. I will provide a narrative overview of the riscv.awk program, and also discuss more broadly the basics of writing a CPU simulator.

Even if you don’t know AWK, but want to learn about CPU simulators, you’ll probably be able to follow this article. AWK is an interpreted, record-oriented language with a C-like syntax, and I think you will agree that most of the code is quite readable to anyone with experience in C-like languages. Writing a CPU simulator is a great learning experience, and I think every programmer should do it at least once.

Polling sucks, but inter-process communication (IPC) is hard. Sometimes you have two programs that need to coordinate, and you just want a simple way for one to tell the other “hey, new information is ready, go look at it”. Here’s a trick I picked up from xidle(1)… I’m sure other programs have used it, but this is where I got the idea.

You may be familiar with UNIX signals (see signal(3) on OpenBSD, and signal(7) on Linux), which allow one program to interrupt another. Most often, this is in the form of a SIGKILL or SIGSTOP to halt a misbehaving program. What we’re interested in today is SIGUSR1, which is one of two signals set aside for user-defined use.

Those that know me will know that I generally prefer to run OpenBSD when I have a choice. However, I found myself needing to run a number of Linux-specific software packages. As Ubuntu is the most common (or at least among the most common) Linux distribution, I settled on that – most commercial software that targets Linux specifically sports Ubuntu. It’s taken a lot of trial, error, and scouring the internet to collect the required information to build a usable (by my standards) desktop experience based on Ubuntu 18, so I thought it might be helpful to others to document what I’ve figured out so far.

Over winter break, some friends and I decided to spend a week working on a programming project. One challenge was playing music - deciding whose computer to use, which person’s music library to use, and so on. To make it easier for everyone to play the tracks they wanted, we set up a spare laptop as a jukebox.

A simple shell script which we’ll discuss below served as a server - people could send it a URL (such as a YouTube video) via netcat and it would automatically play each link using mpv one at a time in a first-come-first-serve order.

Sometimes you just can’t get around needing to run an interactive program for an extended period of time; game servers are frequent culprits - remaining as interactive foreground processes which require input from the console to be operated. In this article, we’ll see how to run an interactive program (in this case a Bash shell) as a background daemon using a systemd unit file.

# Background

In principle, the procedure we are about to employ would have worked decades ago on even relatively early versions of UNIX - all we really need is POSIX jobs, redirects, and named pipes (FIFOs). As a simple example, consider the following shell command:

As regular readers will have noticed by the time this article is posted, cdaniels.net is no longer running Jekyll. Instead, it is generated by a new, fully custom static site generator which I have written as a day project during Thanksgiving Break.

This new static site generator offers a number of advantages:

• It produces more visually appealing output (in my opinion)
• It is easier for me to maintain
• It requires less dependencies to run (no more Ruby, just make and sh)
• cdaniels.net no longer uses any JavaScript, at all
• cdaniels.net now renders correctly in non-mainstream browsers (in particular, it’s now entirely usable in Links)
• It has reduced page weight by about half

Perhaps most entertainingly, for my use case, I have fully replace Jekyll with a 44 line Makefile, a couple of small shell scripts, and a fairly brief CSS file.

In this guide, I will discuss how you can go about running a headless factorio game server on your FreeBSD server. My server is an AMD64 system running FreeBSD 11-RELEASE, although to my knowledge nothing in this guide is specific to this version of FreeBSD. In particular, this guide will cover:

• Installing and running the Factorio standalone server.
• Writing a FreeBSD rc.d script to run the Factorio server as a system service.
• Configuring the Factorio standalone server.
• Managing the Factorio standalone servier via RCON.

This guide assumes you are familiar with the basics of UNIX server administration, and the UNIX shell. You must own a legitimately licensed copy of Factorio to run the game server.

In this article, you will learn how to use the Make build system to compile software projects. This article is targeted at those who have experience programming, but are not deeply familiar with the shell or commandline build systems. However, this article does assume you have basic familiarity with the UNIX commandline.

I decided to write this article because, in my experience observing my peers, and in 2 semesters of TAing an intro to UNIX class, Make seems to perpetually be a sticking point for new users. This article is in particular targeted at my peers and students who have often completed one or more semesters of a computing degree, and are competent programmers, but have not had the benefit of UNIX experience.

As a computer scientist, Physics Lab seemed like a great way to practice my LaTeX skills - every week, each student in Physics 211L had to produce a formal lab report covering that week’s experiment. This post details my experience developing a LaTeX template, as well as discovering and selecting tools and methods for processing data and producing figures.

NOTE: This webpage uses MathML, which is supported by most modern browsers.

A little known tool baked into OSX is autofs, also available for Linux, which automatically mounts filesystems when they become available. This is useful for several reasons. Namely, it saves you from having to open the terminal and type a mount command, or mounting through finder’s connect to server dialog. Additionally, autofs should make OSX more fault tolerant in the event that the device becomes unreachable, although I have yet to test this in real world applications.