I am an enthusiastic tinkerer, focused on embedded software and system integration. Generally everything I do as a hobby is open source. You can find more information about my personal projects on this website, as well as on my GitHub profile.

Contact Information

My usual online handle is smaeul, a permutation of my first name.

The best way to reach me directly is through email at samuel@sholland.org. It is the common communication medium that practically everyone shares, and it has a vendor-independent mechanism for push notifications, so most of my other contact methods get forwarded there anyway.

I do not participate in walled-garden social media.

My background

I come from the American Midwest: the land of corn, cows, and Google Fiber. I started reading books on programming from a young age, first on C++, and then on x86 assembly. My hobby was playing with DOS programs and boot sectors written in assembly until I got to university and started writing POSIX-flavored C in earnest.

My first introduction to Linux was Red Hat 8, installed from a pair of scratched CDs in the back of a book checked out from my local public library. These were the days of HAL, and Kudzu, and out-of-tree Fast Ethernet drivers. Having no Internet connection at the time, it wasn't terribly useful, but I remember fondly the KDE desktop and the sample songs that shipped with Kmid.

The first public project I released was a "BuildSkin", a tool to customize skins for The Lord of the Rings Online (an MMORPG). It allowed users to combine XML fragments from various sources; most "skins" were expanded or rearranged versions of a single in-game window. It also provided an engine for resolving mathematical expressions in the X/Y/Width/Height of UI elements. This made life easier for skin developers, who no longer had to do the math by hand, and no longer had to ship a separate copy of their skin for each supported screen resolution.

To me, the beauty of free and open source software is that it is as flexible as your imagination! When a proprietary program doesn't work the way you want, you're out of luck. But if you want to make an open-source application behave differently, all you have to do is write a patch.

I avoid having unused or excessively complicated programs and libraries on my computing systems. I refer to this principle as "minimizing the problem space". Simply put, fewer lines of code provide fewer places for bugs to hide. This principle led me first from Debian to Arch (to rid myself of the mess of Perl wrapper scripts that Debian adds to everything), and then to Gentoo (to reduce the number of library dependencies).

At the time (2015), I had several other reasons for choosing Gentoo. For one, its use of keywords provided more stability than what was available on Arch. Second, I had a growing number of patched or custom packages on Arch; Gentoo's overlay facility and /etc/portage/patches made these much easier to manage. And finally, Gentoo was one of three distributions that had musl support, which I wanted to use as soon as possible.

Nowadays, the ecosystem around musl is much more mature. I still write a lot of patches, but they are mostly trivial. So I made things more challenging by switching my workstation to a big-endian CPU archicture (powerpc64).