Sam Trenholme’s blog
Grab bag
July 19, 2026
Some quick thoughts.
Writing code in 2026
A blog titled Why write code in 2026
has come out. I am glad I retired from
writing code just before human programmers were replaced with AIs; I
get to concentrate on interacting with people instead of machines today
and have a lot more deep meaningful friendships than I had when I was
making a lot of money writing code for countless companies, most of
whom are failed
and forgotten
today.
I still write code the old-fashioned way, by hand, here in 2026, but,
I do use AI to answer programming questions which I used to have to dig
through Stack Overflow arguments to find the answer to.
Daylight savings time
There is a bill running through congress right now
to make daylight savings time be
year-round; people in the US would no longer have the annoyance of
“spring forward” and “fall back”.
Mexico used to follow daylight savings time, having their clocks
change time when they did in the United States, but stopped observing
DST in 2022. So now central Mexico is, depending on the time of year,
in Mountain Daylight Time (during the summer) or Central Standard Time
(during the winter); should this bill pass the senate, then central
Mexico will always be in Mountain Daylight Time, which means its hour
will not shift relative to the US depending on the time of year.
People’s economic future
Well over one generation ago, I worked at a gas station (today’s blog
picture is a picture of me from this era). It was a lot of work, and I
had to work graveyard two nights a week (making doing anything during
the day, such as going to college, impossible), but I kept doing it
because I knew once I saved up enough for a car, I would be able to get
out of the trap and start a career path. And, indeed, that is exactly what happened.
In today’s generation, that does not appear to be viable anymore.
Back when I was working
at the gas station, the exit path was clear: Since I was very talented
with computers and the then emerging Internet, I just needed to start
working in Silicon Valley. And that’s exactly what I did.
AI has greatly reduced the number of jobs in tech, so the exit path I
had so many years ago is no longer viable. Indeed, I know people under
crippling student loan debt who just cannot make enough money
to chip away at their debt or even own a car, much less start a family.
Re-watching Terminator 2
July 11, 2026
I re-watched Terminator 2 today.
Rewatching Terminator 2
I saw “Terminator 2” when it first came out, and just re-watched it
in light of the fact that AI is now real. In the movie, they were about
25 years more optimistic about AI becoming real than what happened in
the real world; AI was viable in 1997 in the movie, but in real life it
didn’t become viable until 2023 or 2024, when people starting using
ChatGPT as a free therapist.
Also, AI was developed by the military in the movie,1
but while the military has helped fund AI development, it has been
created by and funded in the private sector.
Yes, this movie describes one risk of AI: It may decide to kill us.
Whether or not that is a real risk is still up in the air, but what
has happened is that AI is causing massive economic damage,
completely destroying the tech industry and highly paid computer
programmers.
I remember being a kid working at a gas station, slowly saving up
enough money to buy a car, and being on the internet for hours every
night, learning computers and technology to get out of the trap of only
being able to work in a gas station. Finally, I saved up enough to buy
an old car, had a friend of a friend who worked for a place that was
hiring, and got my foot in the door by working as tech support for the
then nascent internet industry in Silicon Valley. From there, I slowly
became a highly paid software developer.
With AI taking over everything, people these days no longer have that
opportunity. AI is eating away at the middle class, and today’s
generation of talented artists, musicians, and computer programmers are
having their jobs being taken away from them by AI agents, forcing them
to stay in low paying service positions.
Picture credits
The picture for this blog is a waxwork of the Terminator at
Madame Tussauds, London. The picture was taken by Daniel Jurena
from Prague, Czech Republic. The picture has been
altered (resized and cropped), and is CC-BY-SA 2.0
licensed.
Footnote
1: The details are more complicated, but in the interest in having no spoilers, this is a reasonable description of how Skynet was created.
Grab bag
July 9, 2026
Some thoughts I have had these last few days.
The Motte
I have decided to no longer contribute to The Motte. Like DailyKos
and a lot of other online spaces, it has become a place where people
think it’s OK to be rude to other people and not have basic respect and
dignity.
Its problem is this: The Motte suffers from the “Nazi Bar”
problem that Twitter (X) also suffers from. Since The
Motte is an online space that allows racists
and other bigots to post “reasonable” arguments, the place
has become dominated by right wing shills.
People not having basic kindness and decency in anonymous forums has
been a long standing issue in the technical community; Slashdot, while
not being racist, had had issues with kindness two decades ago and they
are prevalent to this day.
Fortunately, I have a network of friends who do have kindness, love,
and decency.
The Motte’s server code
While The Motte doesn’t link to this anywhere on their website, The Motte’s server code is available online as open source software.
The code is, as is typical for 2026, a lot of AI-generated slop, but
the code is out there and other people are free to make their own
version of “The Motte” for Reddit-style discussions.
GitHub is having
issues deploying pages
It’s well known in the hacker community that GitHub has reliability issues.
The issue I am dealing with is this:
GitHub pages. While the servers that serve the static pages are rock
solid reliable, the GitHub actions which convert Git code in to a
static web page is very unreliable.
GitHub pages are OK for pages which aren’t updated very frequently,
such as the MaraDNS home page
or my blog archive,
but they are not OK for pages which update
frequently, such as my current blog.
That in mind, I will self-host my current blog, and use GitHub for
the archive.
djbdns no longer compiles
With the post-C23 changes to the C specification, djbdns 1.05 (its
final release) no longer even compiles. Considering that, two
decades ago, djbdns advocates were well known online for being
obnoxious loud mouthed people, it’s telling that not one of them is
actively maintaining djbdns here in the 2020s.
I, on the other hand, am actively maintaining djbdns. My own fork of
a fork of djbdns, ndjbdns,
does compile, but one needs to type in this incantation to compile it:
export CC="c99 -D_DEFAULT_SOURCE"
./configure
make
The cc command these days, by default, tries to compile
C23, which is a distinctly different language than the C which
djbdns (and, yes, my own MaraDNS when I was starting
it) was written in. The above command, for now, instructs GCC/LLVM to
compile the program as if it’s using the current-for-2001 (i.e. the
year the final version of djbdns came out, as well as the initial
version of MaraDNS) revision of the C specification.
MaraDNS: Compiles as C23 code
I have updated MaraDNS to be C23 compatible code so it will still be
able to compile should C compilers ever stop supporting the C99
specification, even though I don’t think losing C99 will be an issue:
As I type this, not only do both gcc and clang
support the C99 specification, they also support the C90 spec that is
now some 36 years old.
The MaraDNS authoritative server, the Deadwood recursive server, as
well as the Lua/Lunacy-scripted coLunacyDNS servers all compile without
warning using a C23 compiler.
Lunacy standalone still emits warnings (but does compile)
when compiled as a C23 program, so my next project is to have Lunacy
compile without warning in a modern C23 compiler.
Lunacy 2026-07-05 released
July 5, 2026
I have released Lunacy 2026-07-05 today, and have done some updates
to MaraDNS.
Lunacy 2026-07-05
Lunacy is a scripting language I use in MaraDNS (both to process DNS
queries with the coLunacyDNS server and to generate the documents); it
is a security hardened fork of Lua 5.1.
The last time I bumped the version number was in late 2022 with the
2022-12-06 release of Lunacy. The 2026-07-05 release is by and large
unchanged; the only changes are:
-
It is now possible to set the compiler with CC when
using the Makefile and Makefile.editline
makefiles.
-
There are now no warnings when compiling with clang 20; there is only
one warning when compiling with GCC 16.
-
There is now a makefile to compile Lunacy using TCC 0.9.25 in Windows
-
The reference manual has added a note about not exposing the output
of pairs to untrusted parties, and includes a sorted
sPairs function, as well as noting popen2 arguments
should only come from trusted sources.
-
Since 2022, I have written a book about how to use Lunacy as a
scripting language like Ruby/Perl/Python. This book, and its source, is
now part of the Lunacy tarball.
The code is available on the Lunacy webpage.
Post 3.5.0038 MaraDNS updates
I have also updated MaraDNS so she generates no warnings when
compiled with:
Since MaraDNS here in 2026 compiles with no warnings, even when
-Wall is set, and since MarsDNS uses the -std=c99
flag when compiling programs, should MaraDNS not compile in the future,
it is almost certainly a bug in the compiler toolchain and not a bug in
MaraDNS.
The code is available on GitHub
as well as other repos.
MaraDNS 3.5.0038 released
July 4, 2026
In celebration of the 250
th anniversary of the United States being
created, I have released MaraDNS 3.5.0038. The main changes, compared
to MaraDNS 3.5.0037, is that MaraDNS now cleanly compiles.
Cleanly compiles
As I talked about extensively
yesterday, MaraDNS now cleanly compiles, and its build process has been
altered to ensure that MaraDNS will continue to compile for the
foreseeable future.
Tests updated
Since compilers have gotten more picky since I last ran the test
suite with MaraDNS, I have updated the test suite to run again. The OS
I currently use to run the test suite is a Docker container with Alpine
3.24; all tests pass in that environment.
MaraDNS’s future
MaraDNS is in deep freeze: The only changes I make at this point are
credible security updates (with the deluge of AI-assisted security
“reports” these days, I’m very picky about what makes a real security
issue) and updates to make sure MaraDNS continues to compile and run.
The 3.5.0037 release fixed a minor security issue; MaraDNS 3.5.0038
cleans things up and fixes issues found by newer and more picky
compilers.
As I get older—keep in mind MaraDNS has now existed for over 25
years—I change my outlook on life. Seeing my first wife and both my
parents die has made me think about my own mortality. While I hope to
live for many many more years, I am now thinking about what legacy I
will leave after I die. Yes, I do have a child, and yes I have a legacy
there, but I also want to have MaraDNS be something which outlives me.
This is why I have, by and large, moved MaraDNS from my personal domain
over to GitHub—my
personal domains will go down when I’m no longer in this
world and no longer babysit my servers and domain registrations, but
GitHub should outlive me, hopefully for a very long time. This
is why MaraDNS is on multiple public Git repos, so MaraDNS should still
be online if some Git repos go offline.
MaraDNS has been a lot of work, and it’s unfortunate I was never able
to effectively monetize MaraDNS to make a living from this program, but
it’s work which I believe will have an enduring and lasting legacy.
MaraDNS and POSIX
July 3, 2026
I made a
2026-07-03 tag for MaraDNS today. I will go
over the changes since yesterday. MaraDNS can now be compiled on a C99
and POSIX 2008 compatible system.
MaraDNS and POSIX
Since there have been issues where code which compiled without
warning when -Wall is set no longer compiling with newer
versions of the same compilers, I have finally made MaraDNS have the
option to be compiled using fully standards compliant code:
To compile MaraDNS in strict conformance with C99 and POSIX 2008:
./configure --strict-posix
CC=cc
export CC
make
cd coLunacyDNS
make clean
make -f Makefile.strict
However, in the interests of security, MaraDNS by default uses two
functions which are not part of the POSIX 2008 standard. Most of the
time, this is the correct way to compile MaraDNS:
./configure --strict-posix
CC=cc
export CC
make
cd coLunacyDNS
make -f Makefile.default
chroot
MaraDNS uses the chroot system call to, in case of a
security issue which allows MaraDNS to give an attacker a remote shell,
restrict that shell’s access to the underlying filesystem. While there
has, as of 2026, never been a remote shell exploit found in
MaraDNS—even though MaraDNS has been around for over 25 years—
chroot minimizes the impact should such a bug be found in the
future.
MaraDNS will run without chroot, but the security
implications would be more significant should someone ever be able to
get a remote shell with MaraDNS.
chroot is not defined in POSIX because “it was not useful to portable applications”
(page 258) since there
isn’t a way to make a usable chroot environment in the
POSIX spec.
The POSIX developers failed to consider the case of using
chroot as a portable and widely implemented way of putting an
application in a sandbox—there is no need to have an “environment in
which an application could run” in said sandbox, since MaraDNS is
started and loads configuration files before entering the
chroot jail.
setgroups
The setgroups call is also used to sandbox MaraDNS. Like
chroot, this minimizes the impact should one be able to
get a remote root shell via a security hole in MaraDNS (again, as of
2026, no security hole with remote shell access has ever been found in
MaraDNS, and it has been over 25 years).
setgroups is not defined in POSIX because it requires elevated privileges to run.
Both of these
calls are standard UNIX calls
Both chroot and setgroups, while not
formally part of the POSIX standard, have been used by MaraDNS for
decades. chroot and setgroups have been used,
with their API unchanged, by MaraDNS without issue since 2001—some 25
years ago. Considering these two function calls haven’t changed in 25
years, it is highly doubtful they will change in the future.
The chroot call used to be part of the POSIX standard
back when it was called the
“single UNIX specification”, and setgroups conforms to SVr4 and 4.3BSD.
These calls are included with
Linux, BSD, and pretty much any UNIX that exists (with rare exceptions;
there was a time when QNX didn’t support chroot, although it does now,
and the Win32 API doesn’t have chroot
either).
That in mind, MaraDNS will continue to support chroot
and setgroups unless one asks MaraDNS to compile in strict
conformance with POSIX 2008.
Looking forward
MaraDNS is now using the C99 standard to compile all programs, and
POSIX 2008 for all system calls, except for chroot and
setgroups (the Win32 port of MaraDNS uses Windows specific calls,
but Windows—despite its imperfections—has a rock solid unchanging API).
That in mind, if MaraDNS doesn’t compile in the future, it is most
likely a bug with the compiler and/or libc library, and probably not a
bug with MaraDNS.
MaraDNS is now more future proof—it is now very unlikely a future
compiler change will stop MaraDNS from compiling, especially since
MaraDNS sets the flag (-std=c99) to compile the code using
the C99 standard.
MaraDNS snapshot
July 2, 2026
I have made a
2026-07-02 tag of MaraDNS today. I will go
over the post 3.5.0037 changes.
MaraDNS 3.5.0037
MaraDNS 3.5.0037 was a security only update; it fixed an issue with
DNS-over-TCP in Deadwood, where a trusted client authorized to perform
TCP DNS queries could disable DNS-over-TCP with a denial of service
attack. Note that DNS-over-TCP enabled is a configuration Deadwood does
not enable by default, and no example dwood3rc files
supplied with MaraDNS have DNS-over-TCP enabled.
This was the first update since MaraDNS 3.5.0036, a 2023 security
bugfix, where a remote “packet of death” could disable the MaraDNS
authoritative server.
Post 3.5.0037
The changes I have made post 3.5.0037 are changes I am making, not
because MaraDNS’s code was broken, but because GCC (and to a lesser
extent, LLVM) decided to “update” their compilers to throw errors with
C code which could previously compile.
Most of the fixes are minor fixes, such as some minor changes to how
signal handlers are written. Yes, it only took me an afternoon to
update the code, but these are updates I would not have had to make if
GCC no longer updated their code. A C compiler should not be a moving
target.
Indeed, Joerg Schilling who is no longer with us made a lot of
updates to the code which generates ISO images to burn in CD players. I
maintain a fork of that code which mainly fixes gross bugs; and I had
to do a whole bunch of hacking
to get the code to compile again in 2026,
again because of GCC’s changes to the compiler.
What I have done is comb through the code and removed all warnings in
clang 20 and clang 21, and made sure all of the code can compile in GCC
15 and GCC 16—and without warnings in GCC 16 (at least in Cygwin) to
boot. So, right now in 2026, MaraDNS compiles just fine in GCC, and
compiles with no warnings, even when -Wall is set, in
clang 20.
Compiling to the C99 standard
In addition, to minimize changes to compilers breaking code which
compiles without warning here in 2026, I have gone to the effort to
compile all of the code with -std=c99 to make sure the
compiler conforms to the 1999 C standard (i.e. the version of C which
existed when I started writing MaraDNS back in 2001).
Since some files use system calls which are not part of the C99
standard, the current workaround is to, for those files, compile it
with the incantation -std=c99 -D_POSIX_C_SOURCE -D_DEFAULT_SOURCE
. Today, I have gone through the MaraDNS and Deadwood code, and made
sure that the only programs which get the
-D_POSIX_C_SOURCE -D_DEFAULT_SOURCE incantation are programs
which otherwise do not compile if -std=c99 is set.
Everything now compiles, in Cygwin, in Ubuntu 26.04, and in a recent
release of Alpine Linux (I use Alpine because it uses a very different
userspace than Ubuntu).
Looking ahead
The next project is to minimize the number of files in the
coLunacyDNS sub-tree which are compiled with the
-D_POSIX_C_SOURCE -D_DEFAULT_SOURCE incantation.
But that’s for another day.
