Iris Webb

TTF Font Rendering on Rust ESP32's for EPaper

Thu, 20 Aug 2026 00:21:10 -0500

Most embedded graphics libraries can’t directly render TTF fonts, instead, they convert bitmap fonts (usually bdf fonts) to a binary format. Since there is no consensus on what this format is, what it allows, and what generates it. The tooling for embedded fonts in any language, much less TTF ones in Rust, is shaky and at times dysfunctional.

The pipeline between common font formats and rusts embedded_graphics text renderer

There are many things a font can be, all with special performance optimizations.

Monospace bitmap fonts require the least overhead, usually just being a large array.
Proportional bitmap fonts require storing metrics for each glyph.
Scalable fonts require a TTF parser and a rasterizer.

For small, embedded displays, stylized fonts aren’t much use in a small display size, and computation time is expensive. So it makes sense to only support fonts in the first or second category. However, for large, low refresh rate displays (epaper), there is much more time to compute between refreshes, and much more space for stylized text.

Memory is the limiting factor of whether or not we can render ttf fonts on an embedded device. The size of the libraries (and data) in the flash memory, and data structures on the stack/heap.

From here, we can take any rasterizer from the many that exist, and attempt to use it in conjunction with embedded_graphics. I chose fontdue as the starting point. Mainly because it has a predefined way of positioning glyphs (which is needed for embedded_graphics)

# Optimizing Non-Embedded Libraries for Embedded?

Since computation cost is almost free for low-refresh rate devices, memory is the only thing that matters. I am working with an ESP32S3, with the following memory budget:

Stage	Flash	Stack	Heap
Budget (ESP32S3)	12000KB	32KB	220KB

This will vary wildly even on the same chip since these settings can be changed. I am representing all numbers in KB to show that flash memory space is essentially free compared to stack and heap. What matters is that if sum of all the stages of processing get close to or above the memory budget, the program panics and fails.

Fontdue, what we are basing this test off of, has a 3 stage pipeline between TTF font data in storage and glyphs being drawn to a display. Parsing with ttf_parser before laying out and rasterizing glyphs using its own internal code.

Using a custom allocator to monitor heap usage, and mem::size_of for data structure size/stack usage, running fontdue on a 100KB Latin font, we get the following:

Stage	Flash	Stack	Heap
TTF Font Data	100KB	0	0
Library Data	~50KB(?)	0	0
`ttf_parser::Face`	0	1.5KB	0
`fontdue::Font`	0	~0	3100KB
`fontdue::layout`	0	~0.5KB(?)	~1KB(?)
Cost	~150KB	2KB	3100KB
Budget (ESP32S3)	12000KB	32KB	220KB

Unideal.

# Optimizing Heap Usage by at Least 15x (or 150x)

2KB of stack usage¹ is also unideal for more constrained chips, but that can be turned into heap usage with Arc. The more interesting problem is that it’s allocating 30 times the ttf data size on the heap… why?

Looking at the source code, there are four culprits:

glyphs: A vector of all glyph geometry.
char_to_glyph: A hashmap from unicode characters to glyph index numbers².
horizontal_kern: A hashmap of kerning values.

The last, and biggest culprit, is the fact that there isn’t a ttf_parser::Face structure in the fontdue::Font structure, which means all the data from the font is being stored in the fontdue::Font structure.

Including the ttf_parser::Face structure, which we have already wrapped in Arc to prevent stack overflows, makes the font much more flexible (allowing for variable fonts, for instance) and gives us a more memory efficient way of accessing data. It makes every method of generating data used during struct initialization available on the fly, more particularly this 20 line lambda function.

By moving that lambda out of the function, changing vertical bars to parenthesis, and replacing references into the glyphs vector with it, we can run our tests again to get the following table:

Stage	Flash	Stack	Heap
TTF Font Data	100KB	0	0
Library Data	~50KB(?)	0	0
`ttf_parser::Face`	0	1.5KB	0
`fontdue::Font`	0	~0	19KB
`fontdue::layout`	0	~0.5KB(?)	~1KB(?)
Cost	~150KB	2KB	20KB
Budget (ESP32S3)	12000KB	32KB	220KB

Ideal!

# Even Better?

For what it’s worth, there is more to do from here, core_float_math and portable_simd can make the renderer noticeably faster compared to its x86-only optimizations. And less caching can get 20KB down to 0, so that instead of caching all the time, there’s an optional cache which can be used when memory is less important and speed is slightly more important.

The biggest thing this is missing, when compared to full-featured font stacks, is shaping. And the first-class way to do shaping with rust is… with a different font stack? That’s maintained while ttf_parser isn’t?³ Even enough tooling uses the old one that cosmic_text has both in its dependency tree?

In the future, I’ll look at parley’s memory budget. But since I have gotten TTF text rendering to work natively on an ESP32, I will look at it another day.

femtofont, running on an epaper display

This is because ttf-parser keeps a large amount of table data in a similarly large data structure after initial parsing. ↩︎
For many reasons, ttf fonts store their glyphs in a large table with a cmap look up table translating unicode codepoint numbers to indexes in that table. ↩︎
Ughhhhhhh. ↩︎

Approximating the Position of Space Probes with Minimal Code

Mon, 27 Jul 2026 03:00:00 -0500

Information about the Parker Solar Probe or the Voyagers can be as interesting as info about the Moon or Saturn. However, generating that info is significantly harder, the libraries that can generate data about them are few and far between. And even when generating that data is possible, it’s difficult and cumbersome to actually do in a program. This is enough that Stellarium, XEphem, and KStars don’t generate data on interplanetary probes.

This is because generating this data involves either:

Running an n-body gravitational simulation.
Looking up the data in an extremely large interpolated table, generated by the previous method.

Neither of these are desirable for code that needs a small footprint and quick runtime. So tools that aren’t an n-body simulator like GMAT, ephemeris reader like CSPICE, both like JPL Horizons, or don’t want to prepackage megabytes of data for each probe, usually choose to omit space probes entirely

# The Difference Between Planets and Probes

There are fast, low footprint, accurate ways to generate the positions of planets. Extremely Large Interpolated Tables still exist and are used for exact accuracy. But for smaller utilities, Medium Sized Tables or Smaller can do the same nearly as well.

The accuracy error in VSOP97 nano, over the years 2000 BC to 2500 AD (source: celestialprogramming)

The orbits of planets are consistent and periodic, and since the main influence in their orbits is the Sun, they closely follow the laws of Keplerian Motion.

Keplerian motion, in this context, models a 2-body orbit of something around a fixed point, since the path the orbit traces is unchanging and inertial. It can be calculated to whatever precision is needed, at any epoch, with basic trig. Only 6 parameters are needed to describe an Keplerian orbit, although these 6 change based on what type of orbit is specified.

JPL Horizons, can be used to return 12 elements from any object (including space probes!) at any time, although in practice half of these are needed, and some can be derived from others:

Parameter	Symbol	Describes
Eccentricity	e	How non-circular an orbit is
Periapsis dist.	q	The closest approach of an object
Inclination	i	Deviation of the orbit from a 2d plane of reference, into 3d space
Longitude of the Ascending Node	Ω or ☊	Where the orbit deviates from the 2d plane of reference
Argument of Periapsis	ω or w	Where the closest approach is
Time of Periapsis	T_p	When the object has, or will, come to its closest approach
Mean motion	n	The approximate angular speed of the object
Mean anomaly	M	The amount of the objects orbit it has completed, at epoch
True anomaly	v	The location of the object along its orbit at epoch
Semi-major axis	a	The average between the Periapsis and Apoapsis
Apoapsis distance	r_ap	The farthest approach of an orbit
Orbital Period	P	The time it takes for the object to complete an orbit

Planets don’t follow Keplerian orbits exactly though, other objects influence their trajectories slightly. Jupiter and Saturn are large enough and exert enough force on each other for their positions to be several degrees off from what Keplerian orbits predict. This has to be accounted for explicitly.

As a rule:

The more external influence there is on an object, the more that objects trajectory will differ from a Keplerian orbit

For most planets, asteroids, comets, and even interstellar objects like Oumuamua, this is a small problem that can be corrected for. But a space probes trajectory is defined completely by other objects gravity. Through gravity assists, capturing into orbit around objects, correction maneuvers, etc. Which means the entire trajectory of a space probe can’t be modeled by one set of Keplerian elements.

# The Life of a Space Probe

Any object in interplanetary transfer (not on the surface, or in orbit of anything, except the sun) will spend almost all its time waiting. The closest approach to a planet could last days, part of a larger observation period, where data is collected and its future trajectory is fine-tuned. But these periods are separated from each other by years, where the probe is too far away from anything to take pictures or collect useful data, it hibernates and nothing happens.

The force gravity imparts on an object grows quadratically, inverse to distance. A space probe passing 1,000km from a planet will be affected by it 4 times more than it would at 2,000 km. This also means that a space probe 0.1 AU away from an object will be affected ~22,000x less than it would at 100,000km. Outside of gravity assists, a space probes trajectory is affected by other objects, but this affect is far, far smaller compared to being slingshot around a planet.

JPL Horizons confirms this:

Generating an “Osculating Elements” table for the Parker Solar Probe and graphing any orbital element that doesn’t normally change, Jolts in orbital parameters clearly indicate gravity assists with Venus.

Since these elements are unchanging, they accurately model the trajectory of the Probe until a gravity assist, external perturbations, or something else changes them.

Although the entire trajectory of a space probe is still not calculable, individual sections are:

Any section of a space probes trajectory subject to little external influence can be accurately modeled by Keplerian Motion.

We have as rules:

The more external influence there is on an object, the less accurate Keplerian Motion can model it.
Since space probes encounter extreme external influence, their full trajectory is not modelable using Keplerian Motion.
Space probes encounter external influence in extremely short bursts, between long, inertial sections of waiting without much external influence.
Any section of a space probes trajectory subject to little external influence can be accurately modeled by Keplerian Motion.

# Segmenting Sections

Instead of keeping a large table of XYZ positions, or a single set of Keplerian orbital elements. A small table of Keplerian Elements can be kept, each entry having a start time and being a different section of the probes trajectory. And the individual sections in it can be turned into coordinates using the same algorithms used to calculate the position of asteroids and comets. So that finding the position of a probe at a certain time is just searching through the table for the right section then calculating its position the same way as an asteroid.

As a test, I used this method to calculate the trajectory of Voyager 1. Since Voyager’s Jupiter/Saturn encounters are relatively close together, instead of cherry-picking sections, I chose to periodically generate them.

Using JPL Horizons (Osculating Elements, AU and days, CSV format), I generated 3 tables, then combined them:

1977 -> 1979: Orbital elements every 90 days
1979 -> 1981: Orbital elements every 30 days
1981 -> 2020: Orbital elements every 5 years

The final table is about 40 entries long, storing all 12 elements and the start time in double-precision floats¹, it’s about 4500 bytes of binary data, and 700 lines of code.

This method is also very fast, running a small script to generate a table of positions to compare against JPL Horizons, it only takes 200 milliseconds to generate 18,000 positions, this averages out to a single calculation only taking 10 microseconds.

Comparing the data against official data from JPL Horizons, we can tell that the maximum error is about 0.3 degrees, and that the average error is much lower, plotting error against time we get the following graph:

There’s an anomaly here in the days immediately after the Jupiter gravity assist, going out to around 20 arcminutes (2/3 of the moons diameter). This could be fixed by generating more sections immediately around the area of the encounter with Jupiter, and is a consequence of periodically generating sections instead of hand-picking them. Zooming past this:

Sudden jolts in accuracy can be seen starting immediately after 1981, the first 5-year long section being particularly wobbly. But slowly getting less severe with time.

I can’t confirm this, but the consistent wobble between 1986 and 2006 lines up with the 11 year orbit of Jupiter. Although far away, it might still have enough influence to change its course by several arcseconds.

# Even More Accurate?

Looking at the chart above, the long-term errors when compared against JPL Horizons usually slowly tend towards a certain direction. Interpolating² between sections would:

Make the trajectory continuous
Improve accuracy by anywhere between several arcseconds and several arcminutes

However, even though long term errors tend towards a certain direction over a long time. Short time errors (i.e. the anomaly in the first graph) very much don’t, they quickly jolt to a different set of orbital elements and stay that way afterwords. If every section were automatically interpolated, it would run the risk of large and sudden changes happening over months, causing large errors in those parts of the trajectory. To prevent this, sections where a small amount of change happens would have to be separated from sections where a large amount of change happens.

Regardless of exact accuracy, 1 arcminute is good enough for almost all non-scientific use, and provides fast, malleable code for use in other tools.

A plot of the trajectory of Voyager 1, along with the orbits of Jupiter and Saturn

# See Also

The code used in these tests

The least space-efficient way of storing it, since double-precision floats and all 12 orbital elements aren’t needed. ↩︎
As opposed to a step function ↩︎

The lack of information-density is crazy

Thu, 05 Feb 2026 16:54:29 -0600

The following is from the CachyOS homepage:

CachyOS is designed to deliver lightning-fast speeds and stability, ensuring a smooth and enjoyable computing experience every time you use it. Whether you’re a seasoned Linux user or just starting out, CachyOS is the ideal choice for those looking for a powerful, customizable and blazingly fast operating system.

This block of text tells me nothing. No information can be extracted from this. I know exactly as much about CachyOS after reading this than I did before. The litmus test for this is seeing if another, different project would deny any claim made by the offending text.

Here is the pitch for the Operating System CachyOS contrasts itself with:

NotCachyOS is designed to deliver crawling-slow lag and instability, ensuring a rough and miserable computing experience every time you use it. Whether you’re a seasoned Linux user or just starting out, NotCachyOS is the ideal choice for those looking for a heavily restricted and extremely slow operating system.

CachyOS does have legitimate benefits and selling points. Kernel-level fine tuning for speed being the main one, and it does describe them later on in the page, which makes the lack of information in their introduction even more confusing to me. This introduction could be written in a way that tells me what makes it different:

CachyOS is designed for speed by optimizing its core packages with BORE scheduling and LTO that drastically increase performance. Harnessing the full power of modern machines. Its GUI live-images will make using CachyOS enjoyable for all types of linux users, beginner or experienced, looking for a preformant and customizable operating system.

This is still marketing-copy, using description as a mechanism for advertisement. But it is geared towards people who would actually want to use CachyOS, it tells someone why they would want to use the operating system by showing how it is different from other ones.

Implementing an efficient malloc in 50 lines of C

Sun, 31 Aug 2025 00:00:00 +0000

The smallest C libraries will just mmap each allocation, storing the length immediately before and assume any value passed to free is valid. But this leaves plenty of room for optimization and correctness.

The way libc’s typically keep track of allocations is with a linked list or other data structure, keeping multiple small allocations on the same page.

This brings the question:

In linux on x86_64, how can you implement a correct (standards compliant) malloc() and free() in as little code as possible, whilst still optimizing to some extent?

Generalizing printf in C

Wed, 20 Aug 2025 10:25:12 -0500

In ANSI C89, there are 6 printf functions:

printf
sprintf
fprintf
vprintf
vsprintf
vfprintf

Other C versions add more:

dprintf
snprintf
asprintf
vdprintf
vsnprintf
vasprintf

The sole difference between these functions is the format of input and the source of output. It would make sense to generalize this class of functions in an implementation of printf. Ideally down into one function that constructs and outputs the formatted string which the 12 functions can wrap around or be based upon.

Some simple optimizations can be made already, all printf functions wrap around their variadic forms, which cuts the list in half. printf and dprintf can both be thought of as wrappers, which reduces the now 6 functions needed into 4:

vsprintf
vfprintf
vsnprintf
vasprintf

sprintf was a bad idea for the same reason gets was (in fact, GCC will throw a warning if it detects the use of either of those in almost every case). snprintf is theoretically different because it needs an output limit, but the behavior of sprintf can be replicated by setting that limit to SIZE_MAX or similar.¹

The 3 functions left are vfprintf, vasprintf, and vsnprintf. There is a straightforward way to reduce these down into one function, to vasprintf a dynamically allocated string, output it with memcpy or fputs, then free it.

The problem with this approach is that it is inefficient. Even if using a vector that doubles in size when expanding to be O(log n), there are redundant allocations. If the formatted result is especially large, it will take up a large amount of memory. Trying to generalize printf functions that outputs the string as its constructed is a harder and more interesting problem.

# Transmutation and Opaqueness

C89² defines qsort as:

void qsort(void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *));

The first 3 arguments are the parameters for an array, with the last being a function to pass the elements to (often a wrapper around strcmp, the comparison operator, or similar).

This function employs function pointers to modularize code, and the fact that it has no information about the array it is given besides its size and element size. Because of this:

Transmutation is required to use it
Which makes use of the function much more volatile since it is harder to check if the types being given or interpreted are valid

Consider the two arrays:

long long a[] = {0, 0, 0, 0, 0};
char *b[] = {"b", "a", "c", "d", "e"};

Both contain 5 8-byte elements³. But they both cast to a void pointer when passed into qsort. And the information about the type is lost until it is recast presuming it’s the desired type. The compiler won’t throw a warning if you sort the first array with a wrapper around strcmp. Nor will it warn you if you give a wrong number of elements or element size.

In our printf implementation, we can pass in both a file and a buffer to write to, along with an output function and the needed format string and list of arguments:

static int _vfsprintf(FILE *stream, char *buffer, size_t size, int (*submit)(char *, char *, FILE *), const char *format, va_list va);

Since the FILE stream, the buffer, and the size are only used inside the submit function, they can be set to null and ignored in the output handlers.

If you could write a static or dynamic buffer in multiple distributed steps using a function pointer and a pointer to the start of the buffer alone, this and a few wrapper functions would be the end of it. Unfortunately, doing this in C requires state.

# OOP in C

Writing a buffer in multiple steps with a function requires you to continue from where you left off. Keeping track of where you left off is trivial:

struct bufinfo {
	int idx;
	size_t len;
	char *buffer;
};

This needs to be carried with you the entire time you’re writing to the buffer. Which can be done by passing in a void pointer in containing the state that the output function needs:

static int __submit_vfprintf(FILE *stream, char *str, int (*submit)(char *, FILE *, char *, void *), const char *format, va_list va, void *initstate)

The pointer initstate is passed to the output function, which uses it to write to the buffer then modifies the information inside it for the next time the function is called. This is a way of keeping state that is neither local nor global.

static int vfp_strapp_submit(char *str, FILE *ignored, char *ignoredalso, void *bufferinfo) {
	struct bufinfo *bi = bufferinfo;
	size_t len = strlen(str);
	size_t left = bi->len - bi->idx;
	if (len > left) {
		return 0;
	}
	memcpy(bi->buffer+bi->idx, str, len);
	bi->idx += len;
	bi->buffer[bi->idx + 1] = '\0';
	return len;
}

Thus, an implementation of vsnprintf (and by extension sprintf and snprintf) can be made with a few lines of boilerplate code:

int vsnprintf(char *s, size_t n, const char *format, va_list arg) {
	struct bufinfo bufinfo;
	bufinfo.buffer = s;
	bufinfo.len = n;
	bufinfo.idx = 0;
	return __submit_vfprintf(NULL, NULL, vfp_strapp_submit, format, arg, &bufinfo);
};

An alternate solution for perfectionists would be to make both functions a wrapper around one core function that takes a boolean of whether or not to look at the output limit. ↩︎
Later versions of the C standard may make use of typeof or other modern features ↩︎
A more realistic example might be sorting an array of 64-bit numbers using the comparison function that sorts 32-bit integers ↩︎

A Visual Tour of IAU SOFA

Wed, 16 Jul 2025 00:28:55 -0500

(Click on the image to make it fullscreen)

Bitmap Images in 1965 - Mariner 4

Sun, 25 May 2025 11:56:07 -0500

On July 14th, 1965, the Mariner 4 spacecraft flew by Mars, the first to ever reach the planet successfully. In the scientific data it recorded, it took 21 pictures, similar space probes built for the moon or earth would usually transmit image data back in an analog format of continuous scan-lines (similar to a TV broadcast). But for clarity across interplanetary distances, This probe had to record and transmit its data back in a digital format.

The clearest image from Mariner 4, with pixel boundaries visible

# .bmp-1965

Image data from this was transmitted back as a series of bits, with a 6 bit number per pixel. Weirdly enough, the highest number (63, 0b111111) represented black whilst 0 represented white, the opposite of how its represented today.

The first image from Mariner 4, white parts showing gaps in transmission and highlighting pixel boundaries.

These pixels would be transmitted continuously to send a 200x200 image.

# Digitizing This Format

From here, these pixels would be recorded as dots on a tape, this tape would be scanned to imprint the image onto film, and finer restoration work would be done to perfect the picture. This is an example of an early dot-matrix image printer.

With modern computers and image formats, this data format does not have to be imprinted onto tape to be viewed. Converting this to raw RGB data is fairly easy, and from there, you can convert that to png/jpg/etc using tools like XPM or farbfeld (which is just 16-bit ARGB). The only hard part of this process is that Mariner 4 image data works with 6 bit pixels, which means that you have to work with chunks of 4 pixels (3 bytes) at a time.

Doing bit the manipulation needed to pack the image data efficiently, any 200x200 image can be converted and viewed as if it came from the antenna of a 1960’s space probe.

# See Also

Appointment on the Moon by Richard S. Lewis - Information in the chapter “No Hiding Place” was the inspiration for this article.
My converter for this format: mar4-ff

Astronomy and Earth: Coordinate Distances

Sat, 24 May 2025 19:07:58 -0500

You might have heard the phrase “dig to china” before, or talked about digging a b-line through the earth to some far off land jokingly. But how much distance would you actually save by digging through the earth instead of traveling along the surface?

Since coordinates on a sphere are 2 dimensional, lets think of a simpler problem. On a unit circle where both locations positions can be represented by one angle, what’s the difference between going through the circle versus traveling along its circumference?

Well, we need to get the difference between these two angles, which is just another angle that you can get by subtraction, from here crd (2*sin(0.5*x)) can do the work trivially.

Extending this problem into 2d, what can we do?

Well, any two points on a sphere form a great circle. This immediately reduces the problem back into the first 2d one. We can get the angle between the two points on the great circle using:

arccos(sin(long1) * sin(long2) + cos(long1) * cos(long2) * cos(lat1 - lat2))

Multiplying the resulting chord by the earths radius, we can approximately get a distance calculation for digging through the earth between any two coordinates.

# How Does This Relate to Astronomy?

When calculating the phase (illuminated fraction and bright limb position) of planets, you work with a “phase angle” that is the angle between the Earth, that planet, and the sun. With ((1-cos(x))/2), you can turn this number into an illuminated fraction.

How is this angle calculated? Imagine a triangle between the sun, earth, and planet. The length of the Earth-Sun line is trivial (1AU within a rounding error for these calculations). And the length of the Earth-Planet line can be calculated easily.

You need the sun-earth-planet angle to have enough info to use the law-of-cosines for the desired result. And if you have the coordinates of the sun and planet (which should be trivial to find at this stage), you can take the angle between these two coordinates on the celestial sphere. And finally have enough info to get the phase angle from coordinates and distance alone.

Practical Astronomy with Your Command Line

Fri, 23 May 2025 17:02:40 -0500

About a year and a half ago, I was trying to put the current moon phase in my status bar, Simultaneously I was trying to make other projects that would show the sunrise and sunset time. There are many open-source tools that can generate astronomical info on Linux:

Stellarium is easily the most extensive astronomy tool out there, acting as a full planetarium and astronomer toolkit.
Stellarium Web - a slightly clunkier version of stellarium for browsers (To picture the level of degradation, think old desktop Google Earth (flight sim included) vs the web version).
Celestia is a simulator in a similar style to stellarium.
JPL Horizons is a highly modular data generator that you can telnet into.

Looking to more specific purpose tools:

wttr.in/moon - a curl service that includes a moon phase generator based off a python rewrite of phoon.
phoon - a unix moon phase viewer based off the code for moontool.
moontool - GUI moon phase viewer.
sunwait - sunrise/sunset calculator.
plan9 astro(1) - astronomical info generator, largely exclusive to plan9.

As cool as all these tools are, there still exists a specific niche in shell scripting that I still couldn’t fill. To properly script/embed these tools in the spirit of classic UNIX. There should be a clear way to render the info in plaintext, ideally without sending HTTP requests or using a GUI. There are a lot of things which can do that, but most of them aren’t general purpose enough to generate things like moon phases/sunset times/planet positions all at once.

# How Easy Is It to Make Something like That?

Let’s lessen the scope for a moment, to… lets say moon phases. Which I couldn’t find a straightforward way to get info about without revving up an awk interpreter to strip out text from other things, using inaccurate approximations, or curling information from the internet.

A year ago, I was looking at pyphoon, and found the astronomy code from it was a rewrite of C code written almost 40 years ago.

Instead of dividing the current date by twenty-some days and working off the value that returns, this code could give accurate information about the phase of the moon centuries into the future and past. Along with information such as angular diameter and distance. And it could do that parsimoniously in around 400 lines of C (before refactoring).

Stripping out all the GUI code (which would not compile on X since it uses SunOS specific libraries (think 1987 when color monitors running X are the hot new thing)), that code could easily be refactored into a CLI tool.

mprintf -h
# mprintf [-h] [-t TIME] [FORMAT]
# -f formats:
# %a Moon Age      %J Julian Day
# %e Emoji         %s Emoji of phase (Southern Hemisphere)
# %p Phase Name    %P Illuminated Percent
# %% Percent Sign  %n Newline

mprintf "%e %P %p"
# 🌘 13.3 Waning Crescent

I later transpiled this to lua and rust. But… how did the original code get the moon phase, and how did they come up with the algorithm?

In the header of that code, the book Practical Astronomy with Your Calculator by Peter Duffett-Smith is mentioned. Which explains not just the algorithms behind astronomical calculation, but many aspects of astronomy itself, very well. This book is actually simpler to transcribe code from than similar books for BASIC/FORTRAN/Forth/C/PASCAL, since the books algorithms are usually just arithmetic, exponentiation, and trig functions.

# How Accurate Can We Be?

TL;DR: Accurate Enough.

Hyper-Accurate Astronomy is… hard. Often times it is impossible without information that can’t be queried from the user reasonably.

In most astronomical algorithms, you will see approximations for slightly varying factors given in the form of a polynomial of centuries since some epoch. Even though those formulas diverge to infinity, they are “good enough” for a range of a few thousand years.

Generally, most “constants” wobble by some small amount over a large period of time due to a large amount of effects.

The moon is half a degree in the sky (30 arcminutes)
An arcsecond is the angular diameter of a dime viewed from 2.5 km
The Hubble Space Telescope has a resolution of around 0.1 arcseconds
The Gaia telescope can pinpoint star locations down to 7 microarcseconds

Effect	Predictable	Caused By	Max Change in Accuracy
Precession	Yes	Wobble	~1°/century
Parallax	Yes	Distance Changes	1 degree (lunar), less than 1 arcsec (everything else)
Refraction	Yes¹	The Atmosphere	Up to 30 arcmin (near the horizon)
Perturbation	Yes	Newtonion Gravity	Up to 1.5 degrees
Proper Motion	Yes	Star Movement	Less than 5 arcsec per year
Nutation	Yes	Wobble	~10 arcsec/20y
Polar Motion	No	???	~0.1 arcsec/year
Extinction	No	The Atmosphere	Varies (effecting visual magnitude)
Aberration	Yes	The Earths Orbit	Up to 20 arcsec
Apsidal Precession	Yes	General Relativity	Less than 1 arcsec per century

Not all these effects are worth accounting for to the level of picoarcseconds. Many are not worth accounting for at all in a parsimonious info generator. Some only matter for historical dates or dates far in the future. At the same time, there is a noticeable difference caused by parallax, refraction, and pertubation.

Correcting for precession, perturbation, refraction, and parallax gives results that are “good enough” for telescope pointing, observation scheduling, and most real-world uses.

# Algorithms and Plumbing

Practical Astronomy with Your Calculator is a very useful source of information, but there are other collections of algorithms that are just as useful:

Astronomical Formulae for Calculators by Jean Meeus covers most of the same topics, with slightly more accurate algorithms and slightly less explanation on why they work.
https://www.celestialprogramming.com/ provides much more accurate algorithms, in easy to transpile javascript. Along with things like rotation matrix code, although with little to no explanation of the algorithms themselves.

As for the plumbing, we can generally break down any calculation into the form get [PROPERTY] from [OBJECT] assuming [TIME/LATLONG]². Creating a table of properties of an object over time is called ephemeris. Using this model, we can make a simple interface to these algorithms for a command line:

deskephem -l 45s,0 moon phase
# 🌘 Waning Crescent (8.0%)
deskephem -E now,5d,+3w saturn distance
# ===================================================
#          Date                   Distance
# ===================================================
#  2025-05-24T13:45:27  10.00 AU
#  2025-05-29T13:45:27  9.92 AU
#  2025-06-03T13:45:27  9.84 AU
#  2025-06-08T13:45:27  9.76 AU
#  2025-06-13T13:45:27  9.68 AU

Additionally, output can be added for JSON and CSV, to make parsing data with tools much easier.

# The result?

Let’s say you want to graph the distance between the Earth and the other planets in the inner solar system. Doing this entirely inside the command line with conventional tools is normally a painful process. But using CSV output, you can generate ephemeris for the 3 other planets (and the sun), and put the distance columns into your data analysis tool of choice (gnuplot, python, etc…).

It is easy to see why Mercury is the “mostest closest” with this graph. You can also see the slight eccentricity of Earth’s, and Mercury’s orbit as wobble in the line of the sun, and a more substantial difference in the wave of Mercury’s orbit.

This tool only has 1500 lines of rust (astronomical algorithms included), with 0-dependencies aside from std. And the algorithms are universal enough to be rewritten to anything with trig functions and floating point math.

The ephemeris generator that came from this research: deskephem

Truly Accurate Predictions require temperature, pressure, and altitude measurements, but even without these refraction can be approximated. ↩︎
Generally, the latitude and longitude is only important in some parallax calculations and in conversion to horizontal coordinates. ↩︎

Astronomy: Time is an Angle

Tue, 20 May 2025 16:08:15 -0500

The time of day as an idea needs no introduction.

But what does it represent, really? Well, it represents a fraction of a rotation (the Earth’s), which makes it an angle.

In many astronomical calculations, angles in coordinates are represented as a time to make certain conversions easier. For example, the horizontal coordinate of Algol is 03:08:10.13 (Usually written 03h08m10.13s).

If you disregard the fact that this is a coordinate and treat it as a time of day, it can be converted to local mean sidereal time. Which contains the hour angle (also written as a time), the location on the celestial equator relative to the observer. Or rather, how much the celestial sphere has rotated in comparison to the prime meridian.

Since in astronomy, angles are sometimes represented as time, why not represent time as an angle?

# The 360 Hour Clock, the 2π Hour Clock, and the 1 Hour Clock¹

In 4 minutes, the earth rotates 1 degree around its axis, and in about 4 hours, it rotates one radian. This can provide a vague idea of how much objects will move in the sky. The sun takes up about half a degree of view in the sky, so a sunset will take a minimum of two minutes.

Venus takes up about 1/60th of a degree of view. So it could only take 4 seconds to move its own diameter in the sky… Good to know for telescope adjustment (“If I leave my telescope alone, I’ll be able to see X for at least Y amount of time”).

Using degrees in place of hours on a clock, or using “turns” (the fraction of the day) gives results that are interesting, but don’t deserve much commentary.

# The Tangent of Time

Why radians? For trig functions, of course!

Whilst taking trig functions on your coordinates can yield interesting results (the cosine of your latitude is how long your line of latitude is compared to the equator). These don’t seem to map to anything interesting and non-obvious.

This makes sense because the term “12-hour clock” is valid even though it describes a 24 hour day ↩︎

Mathematical Data Representation (ADT) Explained

Thu, 27 Feb 2025 00:00:00 +0000

In C, primitive types are just numbers.

printf("%d, %u, %f, %x", '\0\0\0A', -35, 0.5, "string");
// 65, 4294967261, 0.500000, ce1c2008

Some are signed, unsigned, floating point, or pointers. But all of them are numbers of a certain width. Floats and pointers support a subset of the operations integers do, but all primitive types in C support some level of arithmetic.

printf("%d, %x, %ld", true * 6, argv[0]+3, 0.6);
// 6, 4303b661, 99179430350296

Compound types are either a collection of terms of different types (struct), of the same type (arrays), or a list of aliases to a singular place in memory (union).

struct response {
    char abbr[3];
    enum {SUCC, ERR} tag;
    union {
        int succ;
        char err[4];
    };
};

Unions are usually annotated with a tag of which alias is in use. Doing this in C requires explicit thought and attention, even though this behavior is needed in most contexts.

In this spirit, enumerations are interchangeable with integers.

enum {A, B, C} x = 630;
enum {D, E, F} y = A;
y == D; // True

All of this allows for transparent memory management. The price paid is that it’s a lot harder to cleanly represent data with C. The programmer has to be constantly paranoid about invalid states whenever handling data.

Instead of modeling data based purely on its representation in memory. We can model data types more abstractly and mathematically.

# Algebraic Description of Types (ADT)

Using ADT, a type is just a set of terms. Values outside of these terms are unconstructable.

enum Boolean {
    True,
    False,
}

The mathematical notation for type theory often works with the number of terms in the type. For example, the boolean type is commonly called 2 in mathematical contexts.

We can combine types into larger types using product and sum types.

A product type combines types in a similar fashion as a struct in C.

struct Person {
    Name(String),
    Age(u32),
}

The number of terms in a product type is equal to the product of the number of terms in the two combining types.

A sum type is analogous to a tagged union, representing either one value or another.

enum Response {
    Succ(u32),
    Error,
}

The number of terms in a sum type is equal to the sum of the terms in the combining types.

Types that represent functions with one argument are also possible, reducing down to the exponentiation.

A function with multiple arguments is possible via currying, returning a function with one less argument.

> x = (+ 2)
> x 3
5

# Now, Prove That Numbers Exist.

No, seriously. Do it. Or less ambiguously, name a valid number.

5, TREE(3), perhaps 3,735,928,559? Congratulations, you have proved that numbers exist!

Now, prove that the type returned by rusts exit function exists. Or less ambiguously, name a valid term the exit function returns.

…

No answer? That is because the type exit returns (in rust) has no valid term. And therefore this function cannot return since it isn’t capable of returning a valid value.

The obvious consequence of this is that the noreturn “type” in C can be replaced by a null type. But this has a deeper implication of being able to express statements in a type and prove they are true if the type is inhabited.

Similarly, proving that Result<A,B> exists proves that A or B exists (aka. A + B != 0). And (A, B) proves that A and B exists (aka. A * B != 0).

# See Also:

Rethinking the C Time API

Wed, 05 Feb 2025 10:25:12 -0500

Out of all the components of C, its time API is probably the one most plagued with legacy cruft. To the point almost every regularly used element of it has some design decision that’s been obsolete for decades.

As an example, here is some code I use to print the current time for my status bar:

#include <stdio.h>
#include <time.h>
#include <unistd.h>
int main(void)
{
  char buf[40];
  time_t now = time(0);
  while (1) {
    strftime(buf, 40, "%a %b %d %T", localtime(&now));
    puts(buf);
    fflush(stdout);
    sleep(1);
    now = time(0);
  }
}

time() unnecessarily takes a pointer argument to write to
strftime() has to write to a string of a fixed length it can not dynamically allocate (This is less legacy than it is bad design)
localtime() needs the pointer to a timet value _even though it does not change it because of register size concerns on PDP-11’s
sleep() cannot sleep for sub-second amounts of time, usleep() is deprecated and it’s alternative nanosleep() requires you to define variables

This is possibly the simplest real-world use of the C time API. And even then the legacy cruft and bad design makes this code significantly less organic.

For comparison, here is the corresponding Lua code

while true do
	print(os.date("%a %b %d %T"))
	io.stdout:flush();
	if not os.execute("sleep 1") then return 1; end
end

The library I describe in this article was not made because I expect it to have widespread use. But as a proof of concept of what could’ve been, and to illustrate some of the subtler design flaws of the time library.

# Scope

I will be using the functions described in Eric S. Raymond’s Time, Clock, and Calendar Programming In C as a boundary for the C time API. These forty-something functions can be classified as:

Alarm/Timer (alarm(), ualarm(), the timer_ group)
Getting the current time (time(), clock_gettime(), getttimeofday(), ftime(), timespec_get())
Setting the current time (settimeofday(), clock_settime())
NTP correction (adjtime()/adjtimex())
Converting system time to calendar format (localtime(), gmtime(), and their variants)
Converting calendar time to system format (mktime(), timegm(), timelocal(), and their variants)
Sleeping (sleep(), usleep(), nanosleep())
Converting a time to a string (asctime(), ctime(), and their variants, as well as strftime())
Converting a string to a time (getdate() and strptime())
Timezone handling (tzset(), and the Berkeley timezone API)
Clock handling (clock(), clock_getres())

The only function that doesn’t fit here is difftime(), which is just a subtraction.

Out of these, clock handling, system level APIs for setting the time, Alarm/Timer handling (which has as much to do with signals as it does time), And NTP correction are out of scope. This leaves:

Getting the current time
Converting system time to calendar format
Converting calendar time to system format
Converting a time to a string
Converting a string to a time
Timezone handling
Sleeping

The main types of the C time API (that matter to us) are:

time_t, which in practice is a 64 bit signed integer of seconds since 1/1/1970 00:00:00 UTC.
struct tm, a broken down (both literally and figuratively) representation of calendar time.
struct timespec, a representation of fractional time in seconds and nanoseconds.
timezone_t, a BSD exclusive opaque timezone type.

time_t and struct timespec are used almost exclusively in kernel-level functions. Whilst struct tm is used almost exclusively with conversion of time to and from strings.

# Nanoseconds, Floating Point Precision, and the Y2262 Problem

It would be awfully convenient to represent time in nanosecond form everywhere all the time. It’d give strftime and strptime the ability to print milli/micro/nanoseconds. And it’d remove the need for the timespec struct used in a lot of system-level time functions.

A floating point number is able to store values up to 2^{mantissa_length} with integral precision. Actually, calculating floating point precision loss is surprisingly easy. For a number n; Any number below 2ⁿ will have at least 2^{n-mantissa_length} precision.

As an example, Lets consider a long double that represents seconds. We lose nanosecond level precision when 2^n-63 is 10^-9. Which means we lose precision at around ~2³³ seconds.

$ date -d "@$((2**33))"
Wed Mar 16 07:56:32 AM CDT 2242

If this long double were to represent nanoseconds, we’d lose precision at 2⁶³ nanoseconds (Around 2262 (The 20 year difference is due to the fact that 10^-9 is actually around 2^-29.8)).

Using some go code I was able to generate the following table:

Type/Resolution	float (23)	int (31)	double (52)	long/x87 long double (63)
1 ns	1970-01-01T00:00	1970-01-01T00:00	1970-02-22T02:59	2262-04-11T23:47
-1 ns	1969-12-31T23:59	1969-12-31T23:59	1969-11-09T21:00	1677-09-21T00:12
10 ns	1970-01-01T00:00	1970-01-01T00:00	1971-06-06T05:59	4892-10-07T21:52
-10 ns	1969-12-31T23:59	1969-12-31T23:59	1968-07-28T18:00	-0953-03-26T02:07
1 us	1970-01-01T00:00	1970-01-01T00:35	2112-09-17T23:53	294247-01-10T04:00
-1 us	1969-12-31T23:59	1969-12-31T23:24	1827-04-16T00:06	-290308-12-21T19:59
1 ms	1970-01-01T02:19	1970-01-25T20:31	144683-05-23T16:29	292278994-08-17T07:12
-1 ms	1969-12-31T21:40	1969-12-07T03:28	-140744-08-10T07:30	-292275055-05-16T16:47
1 s	1970-04-08T02:10	2038-01-19T03:14	142715360-12-06T03:48	292277026596-12-04T15:30
-1 s	1969-09-25T21:49	1901-12-13T20:45	-142711421-01-25T20:11	292277026596-12-04T15:30

Looking at this chart alone… 64 bit integers don’t seem much worse than long doubles. But keep in mind that integers support One precision, and there’s a trade off between resolution and the bounds of your epoch. Floating point values support all precision’s, there is no such trade off.

For this reason, date_t is a long double floating point value of seconds since the epoch.

# “Broken Down Time”

Now that we have a base time type, there should be some way to convert between human friendly to machine friendly values. I.e. getting the year, month, and day. In the spirit of “100 functions for 10 data structures vs. 10 functions for 1 data structure”, Unless a functions job is to handle human-friendly time values, it will use date_t.

The way this is done in C is with struct tm , which contains many problems.

Almost always handled in statically allocated pointers that get overwritten (gmtime())
No way to represent sub-second time.
tm_mday starts at one instead of zero (as the rest of the struct values do) for no reason.
tm_wday and tm_yday make it harder to construct completely valid structs
mktime(), being the main way to convert back into time_t, changes the struct that is passed in.

Creating our own calendar structure to fix these problems:

struct cal {
        uint32_t nsec; // 0..1E9
        uint8_t   sec; // 0..60
        uint8_t   min; // 0..59
        uint8_t  hour; // 0..23
        uint8_t   day; // 0..30
        uint8_t month; // 0..11
        date_t   year; // Since Epoch
};

With 4 functions to handle them:

extern struct cal tocal(date_t d);
extern int wdayof(date_t d);
extern int ydayof(date_t d);
extern date_t   fromcal(struct cal cal);

This fixes several problems with the existing struct tm:

Fractional Time
Day of month starts with 0 instead of 1
Years over INT_MAX possible
Smaller than the struct tm
Any value where the fields are within range corresponds to a unique valid time.

“Why no timezones in the struct?”: The date passed into tocal() is ideally already adjusted to a certain timezone with the api later described in this article. The timezone api deals with date_t, not calendars on matter of principle and practicality.

# The Tragedy of tzset()

The timezone handling code in libc isn’t outdated, that would imply it was once sufficient for timezone handling. tzset() and localtime() are the only ways to handle timezones in libc, and both of them have a insane relationship with each other and the process environment:

A timezone in use is essentially a number of seconds to adjust with, and a name which can be printed (note that this is different from the name you would use to load the timezone. I.e. America/New_York vs. EST). Neither of these things are constant, with daylight savings time and other various adjustment, it does not make sense to give a constant number of seconds or a name for a timezone. (Even with DST variants)

localtime() respects this. And gives one zone name and one offset that are dependent on time in a tm struct (the struct variables that store this are non-portable, but it’s the only way to properly handle timezones without parsing tzdb files).

Thus, get a proper timezone offset and name, we have to:

Set TZ to the timezone name
Call tzset() (which secretly provides good data to localtime)
Give the time_t form of the time to localtime_r (so the global variable localtime keeps doesn’t get overwritten)
Get tm_gmtoff and tm_zone (On musl, tm_zone is overwritten whenever a new timezone is loaded, which means the string has to be duplicated and therefore it must be the users job to free it)
Set TZ back to whatever it was

Creating three base functions and two convenience functions to work with:

int      tzoffat(date_t d, char *tz); // Seconds east of UTC
char   *tznameat(date_t d, char *tz);
const char *mytz(void);

date_t      intz(date_t d, char *tz); // d+tzoffat(d, tz)
date_t    inmytz(date_t d);           // intz(d, mytz())

# Why Weekdays in the Time Structure are Bad

strptime() is special because it uses uncertainty as a tool. It wont touch anything in the calendar structure that isn’t directly correlated with a formatting specification. This is as much of a asset as it is a liability, it’s useful because you can read time with a set of presumptions (i.e. read mm/dd as the current year and not 1970). But it’s a liability because you can unintentionally read time with a set of presumptions (i.e. read mm/dd and then print a wrong weekday because strptime() did not correct the weekday).

Date String	Makes Sense?	strptime result?
Thursday February 16 1978	Yes	Thur. 2/16/78
Febuary 16 1978	Yes	?? 2/16/78
Febuary 1978	Yes	?? 2/??/78)
Thursday February 1978	No	Thur. 2/??/78
Monday February 30	No	Mon. 2/30/??

This is not a problem if the weekday is inferred from other information

# Formatted Time

strftime() formatting has worked its way into many programming languages and applications, this is because it is the easiest, sometimes the only way, of getting time to string conversion to work in many environments. It has also been standardized since C89. Making the formatting of an analog of it a superset of the functionality would provide the benefit of compatibility. Since strftime formatting strings are often passed in from user input. However, the mnemonics for strftime are poor and do not allow for easy extension.

We can free up space for more formatters by using multiple letters in the variations of other formatters.

s - seconds

Us - microseconds
Ns - nanoseconds

m - minutes
h - hours

ch - clock hours (12-hour time)
ih - indicator for hours (AM/PM)

d - Month day
w - Full weekday

aw - Abbreviated weekday
nw - Number of weekday

M - month name

aM - Abbreviated month
nM - Number of month

y - year

Dy - day of year
Cy - Century

z - zone name

oz - zone offset
nz - index name of zone (i.e. America/New_York)

# In Defense of libc…

The time library in C is largely terrible because it is made entirely out of non-tessellating ideas and hacks, and has constantly resisted improvement by standardization. Many components in the library were developed decades apart. Many more were designed without the idea of internationalization in mind. The result of this is something that is “complete”, but not pleasant or elegant to use, and which leaves many pitfalls for bugs.

And as other languages try to improve their own time libraries, looking at the mistakes of C, It is interesting to think of ways C itself could’ve improved its own time library looking at these same mistakes.

The GitHub project for this time library (Partial WIP): https://github.com/iriswebb/newtime/

The Oldest Binary on a Mint System

Thu, 19 Sep 2024 21:59:45 -0500

Simple question with a simple answer: What is the oldest binary on a Linux mint ISO (modification time)? I was playing around with the stat command more than a year ago when I asked this to myself. Running a quick shell pipeline stat -c "%Z %z %n" /bin/* | sort -rn. The oldest 5 binaries you get are all older than 2011, these are (from oldest -> newest):

dirsplit - A perl script with little online documentation and unknown use within the distro.
search4files - A wrapper around 3 programs, none of them installed by default.
mplayerdvd - Which requires mplayer-gui, not installed by default.
vlcdvd - Which persists on the system after you remove VLC.
Thunar-daemon - Which is on systems even where thunar is not installed.

While that does answer the question, it also brings up a much greater question; Why are these scripts and wrappers installed on my system when they probably aren’t used anywhere anymore?

# Lets compare

Comparing this with the GUI version of the Gentoo livecd (Which contains a full KDE-plasma environment), the 5 oldest binaries are all from after 2020, and the 5th oldest one is from 2024, these are:

pram - A tool for managing GitHub PR’s.
symtree - A simple tool for tracking symbol information.
g-lensfun-update-data - A half-dozen line shellscript for a program about photography.
could-init-per - A shell script wrapper for a python utility.
pa-info - A bash script for pulseaudio.

It also should be noted that the Gentoo GUI livecd provides a much more extensive environment than the mint livecd ISO.

# Replication

The real answer to the question of why “search4files” is on the mint livecd is that some Debian or Ubuntu or Mint developer in the mid 2000s put it on there to manage another GUI application. And it was forgotten about and left on years after it ceased its usefulness. And that Mint, or Ubuntu which mint is based off of is a massive pile of enterprise software with cruft and out of date parts.

This also means there is probably no formal process for replicating a Mint or Ubuntu ISO. Gentoo users build there entire system from the ground up, arch users have pacstrap and know the core packages they need. debian has debootstrap. And if I would want to I could theoretically replicate these tools to create my own bootstrapped for those distros, then I could modify it to truly customize my distribution.

Why I Don't Like GNU

Sat, 17 Aug 2024 00:00:00 +0000

This list does not mention the [Richard Stallman controversy]<Link to Drew DeVault article here>. Nor his squabbles related to glibc because:

Most-everybody knows about it
These are related to RMS specifically, not his broader actions to influence the GNU project.

# 1. “Linux was developed for the GNU tools” is False

From https://www.gnu.org/gnu/linux-and-gnu.html:

its users looked around for other free software to go with it, and found that (for no particular reason) most everything necessary to make a Unix-like system was already available. What they found was no accident—it was the not-quite-complete GNU system.

In Linus’s book Just For Fun, the GNU project plays little to no role in the creation of Linux. Linux grew out of comp.os.minix, not anything related to the FSF or GNU project. Additionally, The FSF was still advocating for Hurd until well after Linux was popular.

From The Hurd and Linux (1997):

But we did start the Hurd, back then, and now we have made it work. We hope its superior architecture will make free operating systems more powerful.

The FSF’s push for hurd died out sometime in the early 2000’s, when Linux was commonplace and Hurd was completely abandoned.

From A interview with RMS in 99’:

Yes. Unfortunately, progress right now is very slow. We don’t have anybody working on it full time, and I wish we did.

# 2. For years, the GNU project was not directly maintaining most of their popular projects

For several years in the ’90s and ’00s, GCC, Binutils, GDB, and other FSF projects were being maintained by a external company called Cygnus.
The GCC compiler died and forked into EGCS, which then reunited into GCC and is now controlled via committee.
The de-facto libc on linux for years was a fork of glibc, called Linux libc (more commonly refereed to as libc5/libc4).

The FSF, to this day, still does not have direct authoritative control over the GCC compiler.

# 3. The FSF intentionally makes code less modular to spread itself

The reason why GCC didn’t become a platform for compiler development like LLVM or qbe is because the FSF intentionally kept it back from being so.

From https://gcc.gnu.org/legacy-ml/gcc/2000-01/msg00572.html:

Anything that makes it easier to use GCC back ends without GCC front ends–or simply brings GCC a big step closer to a form that would make such usage easy–would endanger our leverage for causing new front ends to be free.

The FSF is a political movement that engages in intentional obfuscation to spread itself.

# 4. glibc’s feature test macros are designed so that people would mark their code with the GNU projects name

feature_test_macros are a opt-out, functionality removing, non-portable feature that was largely pioneered by glibc.

glibc gives you a few test macros by default (which most of the base functions are under). But If you wanna include something like strptime() you need to #define _XOPEN_SOURCE (which is against POSIX), except if you do that it turns the default ones off.

However, if #define _GNU_SOURCE, all feature test macros are implicitly defined. So the most convenient way to deal with this opt-out “feature” is to mark your code with the GNU projects name.

The dup3() system call is neither written by GNU or even in the “GNU Operating System’s” Hurd kernel. And even though this is not GNU you still have to #define _GNU_SOURCE to get it.

# 5. GNU code sucks

The true command (which is only supposed to return 0) in most other utility implementations is 1 line of code (i.e. int main(){}), GNU true is 80 lines

(Note: the –help text support is actually a bug and possible security issue, because /bin/true --help > /dev/full returns 1 instead of 0)

GNU cat is 813 lines of code, Busybox cat is 217 lines.
glibc can take up to 3 days (See end of pg. 34) to build on low-end hardware
Many GNU libraries such as glibc and glib do not support static linking for no good reason

I could point out more examples, but the message is conveyed that where a programmer might need 10 lines of code to do a job, a GNU programmer would need 100. I have yet to find someone who favours the GNU syntax style. And GNU code is filled with ifdefs, unneeded indirection and complexity, etc (read some yourself, pick a GNU project, any GNU project).

# 6. GNUs obsession with portability adds copius amounts of complexity and helps no one

The terminfo/termcap databases contain support for thousands of different terminals and terminal emulators no one uses (You can try this out now, set TERM=vt100 and run some ncurses programs). Terminal escape protocols have been more or less standardized since ANSI escape codes.
The reset command waits one second to support physical terminals that fell out of favour for emulated ones in the early 90’s. It does not contain a check for whether or not the terminal is emulated, and will sleep regardless.
Portability concerns for “old versions of csh on System V” are still included in the bash manual, and the autotools still check for portability concerns from the ’80s and ’90s

For more examples of this, lets look at the configure scripts for some of the GNU programs.

The 23,000 line bash configure script contains portability checks for a bash version released in 1997 within the first 100 lines., further down it has checks for a version of System V released in 1988, and “pre-3.0 UWIN ksh” which from my searching became outdated in 2002.
The 13,000 line gawk configure script (Along with containing about half the portability checks from bash) contains checks for Solaris 7 (released in 1997) in the first 50 lines, Someone running a 386/AT Machine apparently had a issue. Oh no! IRIX 5.2 (1993) doesn’t support -lsocket. This entire comment block needs no introduction.

This matters in the modern world of software how?

I note that I picked these 2 at random and I’m not searching hard. These are everywhere and I’m sure I could find many more, No one is building modern versions of bash or the version of gawk from 2021 that Github mirror provides on System V machines, nor IRIX, Solaris, 386, AIX or even Hurd.

# 7. The FSF fractured the Open Source world for no good reason

Nothing is wrong with the GPLv2, there aren’t any loopholes in it. And most of the people I see using the GPLv3 (including myself for a while) just used it because “The number is bigger therefore it must be even more free than last time” and/or they want compatibility with other GPLv3 code.

If you ask someone to explain the general tenants of the GPLv2 and GPLv3, 90% of the time they come up with identical answers (“Permitted source code distribution with no non-GPL forks”). Yes there are reasons why GPLv3 was created such as DRM and Torrenting, but there wasn’t large spread exploitation of the GPLv2 to spread proprietary software in the same way that MINIX became the infrastructure for spyware with the IME.

However, The split between the GPLv2 and GPLv3 was infinitely more harmful to the FOSS world than anything it was conceptually supposed to prevent. The days of codesharing between open-source code without checking the license to make sure it isn’t illegal to do so are gone.

A benefit of open source over proprietary software is code-sharing between projects. And this isn’t as effective when there are multiple incompatible open source licenses that can’t legally share code.

# 8. GNU pushes incessantly for texinfo, a format no one likes or uses.

GNU info was designed to solve a problem nobody had, and in their push for it they made man pages worse, which did create a problem, and when people who didn’t wanna use GNU info, they created their own solutions.

GNU info is not portable to other operating systems like man pages, nor well used even by most GNU projects, nor is the browser you need to get a benefit out of its format pleasant to use. Nor is it liked even within the GNU project. This does not change the fact GNU help2man by default refers to info pages in its output.

The reason why most man pages don’t contain examples is because the GNU project insisted on putting them only in texinfo pages and not converting them to man pages. And the normalization of this makes man pages worse for everyone.

Writing a UTF-8 Safe AWK

Fri, 26 Apr 2024 00:00:00 +0000

One of the things the toybox project prioritizes is unicode handling for its applications. This has kept things like the fully GNU compatible tr from being promoted from the pending/ directory for years because they wish to break compatibility by making tr unicode safe. Toybox’s plans for awk are no different story.

Fortunately for any awk implementation attempting to get into toybox; Awk works with strings, while tr works with characters. Awk does not regularly index into the strings it works with, and when it does it only happens in a few functions. This means that if we want to handle UTF-8, we can divide and conquer.

# What a UTF-8 Safe awk Beeds

The gawk(1) man page says these 4 functions work on “characters, not bytes”:

substr()
length()
match()
index()

The second addition awk book also mentions these:

printf %c [STRING]
printf %c [CODEPOINT]
\u[CODEPOINT]

And finally, these work internally by indexing the string:

toupper()
tolower()

That’s “divide” out of the way, now let’s conquer.

# Implementing a UTF-8 Awk

A reminder that we are trying to add in UTF-8 support to a existing awk, not make a new one with UTF-8 support.

In a awk that is UTF-8 safe, all strings are indexed by a number of UTF-8 characters. While in C, all strings are indexed based off of bytes. This means that for substr(), length(), match(), and index(). We need a way to convert between the two. This can be done by two functions, one which counts the bytes in a utf8 string, and another that counts the characters in a C byte string. This work was originally done by me with 2 functions that acted as analogs to mbrtowc() and wcstombs() from libc. And Ray Gardner de-over-engineered these functions.

As long as you have the ability to turn unicode codepoints back into strings, \u[CODEPOINT] is a easy fix too. While the current digit you are reading is a valid hexidecimal character, read that digit into a buffer. Then strtol() to turn that buffer into a codepoint, then convert that codepoint back into a string. There are printf format escapes that print 1 utf8 character of a string. Which in practice makes printf %c easier. The tolower() and toupper() problem is more complex, but fundamentally involves taking a string, running though it and running towlower/upper() on it, expanding it when needed. You can look at the actual code which does this, as that will explain it better than I could.

FS/split() say that if the field separator is more than one character, it will be treated as a regex. This in practice does not matter, since a multi-byte unicode FS will never contain any special regexp syntax character.

Writing in UTF-8 support into a already existing awk is a lot simpler than it seems. wak needed less than 100 lines to make itself UTF-8 safe. Most of the hard part is figuring out what needs unicode handling.

Replacing Neovim With Vis

Wed, 17 Apr 2024 00:00:00 +0000

Lately, I’ve been unhappy with neovim and it’s bloat. vi is a simple and beautiful tool by itself, but it’s most popular deviation vim has been bloated to the point of being unmanageable the same way perl took the design of awk or C++ took the design of C and destroyed it.

Neovim remedies this, but not by much. And in place it adds more bloat. And it’s decision on removing build configuration means that it can’t be de-bloated in the spirit of tiny vim builds.

And the worst part of this, some of the bloat is actually useful. Bloated software has the problem of “Everyone only uses 20%, but it’s always a different 20%”. This makes the minimal vi implementations hard to use. I want syntax highlighting and colorization, I want the ability to batch process data with ex commands. I want the ability to select things with visual mode. This disqualifies implementations like nextvi, nvi, and busybox vi.

What does this leave? There is apparently one editor called vis that’s minimal, has a large amount of vim-isms, and is written in pure C with configuration able to be done in lua. It only takes up a couple megabytes of space, while vim takes up 60 and neovim takes up 40. It lacks things like the s, g, and v ex commands in favor of multi-cursor editing.

vis also has inbuilt syntax highlighting, with a selection of themes to use. vis has inbuilt options for line numbering (including relative line numbering), tab to space conversion And autoindenting (Although, Not very good autoindenting). It also has a semi-customize-able status and keybindings bar via the lua API.

Here are some features that aren’t in vis by default:

“gf” motion
Leading whitespace detection
Some way to spellcheck/auto-complete

Let’s look at these individually and see what vis can achieve.

There are a lot of plugins to do these things:

vis-goto-file: for the “gf” motion,
vis-highlight: for leading white-space detection.
vis-spellcheck: for spellchecking.

There are also lua plugins I didn’t even know I wanted until now, like the ability to auto-format and edit markdown tables with vis-tables. And backups that are stored in a reasonable place with vis-backup.

That is not to say, vis is not without problems. For example, it is convenient to have the cursor show up as a bar on insert mode, but show as a block on normal mode, so that you can tell what mode you are in without looking at the status bar. This would normally be a simple print statement on changing of modes. But for whatever reason (I think due to the fact that there is multiple cursor support in vis). This does not change anything.

If you do not like how bloated and large vim and it’s forks are. But find the features that vim provides useful, Vis includes many but not all vim-isms while still being elegant and versatile.

Making a Static Site Generator with `make`

Sat, 13 Apr 2024 00:00:00 +0000

There are a variety of tools that can be used for static site generation, which is analogous to ahead of time compilation. Jekyll is the one GitHub endorses, it is also written in Ruby, which means that I’d have to pull in megabytes of extra dependencies and slow the building process down for something that ultimately takes away control from me.

What I need is something that is efficient, customizable, and fast. And above all, simplistic. This is where make comes into the picture.

make reads a “makefile” that contains a list of rules. Each rule has a list of commands to run. On the command line, you can run make rule to execute the commands in that rule. If you specify multiple rules for make to run in the command line, it will run all of those rules. If you specify no rules, it will run the first rule defined in the makefile (commonly, this rule is called “all”)

$ cat Makefile
foo:
    echo bar
baz:
    echo foo
$ make foo baz
echo bar
bar
echo foo
foo

Make will print the commands it runs as it executes them, and will abort if a command returns nonzero. Printing the command it executes can be disabled by placing @ at the start of the command. And aborting on failure of a command can be disabled by placing - at the start of the command

Additionally, you can refer to environment variables in your makefile, and assign them on the command line or in your makefile.

$ cat Makefile
BAZ=123
foo:
    @echo $(BAR) $(BAZ)
baz:
    -false
$ make baz foo BAR=abc
abc 123

This allows for macros and quickly running commands without manually typing in the build commands. But this is not the main reason why make is useful.

A rule is not just a name for a macro that you type in on the command line, it is a pattern. And more importantly, it is a filename unless said otherwise. You can specify prerequisites for running a rule. So in your makefile you can write a: b c, which means that rule b and c have to run before a. You can define that a rule is not a filename by defining a “phony” rule, .PHONY: [rule1] [rule2] .... Means that rule1 and rule2 will always run when called.

Finally, if a rule:

Is the name of an existing file
Has prerequisite rules that are all files
All prerequisite files “last changed” date are older than the main file’s

The rule is considered completed, and no commands from it are ran.

This makes ahead of time compilation with object files much faster. Since you can change one file, and it will detect that the other “object files” are newer then their respective source files except the one you have changed. And it will automatically build only that changed file.

But having a rule for each source file seems excessive, right? This is why rules are patterns. The character % means “anything” and is analogous to * in shell globbing, this allows us to create a rule for all .c files

But how will we refer to the source file in the build command? This is why there are special variables in make; You can use $< to refer to your first item in the list of prerequisites, and $@ to refer to your rule name. Note this is not the pattern that the specified rule matched, it is the rule that matched the pattern.

%.o: %.c
    $(CC) $(CFLAGS) $< -o $@

If you run make main.o, make will:

Detect that “main.o” matches the pattern rule “%.o”
Check if the file “main.c” is there.
- If it is not and there is no rule that matches “main.c”, it will not know what to do and will fail.
Check the modification dates of the files “main.c” and “main.o”
- If the file “main.c” is older than the file “main.o”, it will assume no changes have been made and there is therefore nothing to be done.
Execute the build command, referring to the variable CC (By default “c99”), passing in the flags CFLAGS, and running this on the prerequisite files name “main.c” outputting to our rule name, the file “main.o”.

This is the essence of make’s functionality, and is the useful stuff POSIX specifies. But there are other things in GNU make, like the ability to add a prefix to all items in a list with the addprefix function, or the wildcard function to get all items and put them in a list. Functions are specified in variable definitions and arguments are separated by commas. So that evaluating $(addprefix 123, a b c) will return “123a 123b 123c”.

Since the problem of turning markdown files into HTML files is similar to the problem of turning source files into object files, we can create a simple rule that does 99% of our work.

%.html: %.md
    $(MARKDOWN) $(MDFLAGS) $< >> $@

But markdown compilers don’t usually generate HTML boilerplate, and we might want to import a stylesheet, and maybe save to a “dist” directory. So that if we have a “index.md” file, it will compile to $(DIST)/index.html, this is no issue for us.

$(DIST)/%.html: %.md
    cat $(TEMPLATES)/begin.html > $@
    $(MARKDOWN) $(MDFLAGS) $< >> $@
    cat $(TEMPLATES)/end.html >> $@

Notice how % goes after the $(DIST) prefix, which means that referencing it in our prerequisite list will not add it as a prefix.

We have our workhorse rule, but, “how do we put this together?”, we can specify variables for our markdown compiler (in this example, I used lowdown), and scan for files in a source directory using the wildcard command. Making them valid rule names by substituting .md prefixes with .html ones, and adding the prefix $(DIST)

DIST=dist
TEMPLATES=templ
MARKDOWN=lowdown

PAGES=$(wildcard pages/*.md)
PDEST=$(addprefix $(DIST)/, $(patsubst %.md, %.html, $(PAGES)))

# ${VAR} breaks down VAR into a list of rules
all: ${PDEST}

$(DIST)/%.html: pages/%.md
    cat $(TEMPLATES)/begin.html > $@
    $(MARKDOWN) $(MDFLAGS) $< >> $@
    cat $(TEMPLATES)/end.html >> $@

From here, as much customization as is desired can be added through conditionals, rules, variables, and shell scripts.

Additional Resources:

Iris Webb

TTF Font Rendering on Rust ESP32's for EPaper

# Optimizing Non-Embedded Libraries for Embedded?

# Optimizing Heap Usage by at Least 15x (or 150x)

# Even Better?

Approximating the Position of Space Probes with Minimal Code

# The Difference Between Planets and Probes

# The Life of a Space Probe

# Segmenting Sections

# Even More Accurate?

# See Also

The lack of information-density is crazy

Implementing an efficient malloc in 50 lines of C

Generalizing printf in C

# Transmutation and Opaqueness

# OOP in C

A Visual Tour of IAU SOFA

Bitmap Images in 1965 - Mariner 4

# .bmp-1965

# Digitizing This Format

# See Also

Astronomy and Earth: Coordinate Distances

# How Does This Relate to Astronomy?

Practical Astronomy with Your Command Line

# How Easy Is It to Make Something like That?

# How Accurate Can We Be?

# Algorithms and Plumbing

# The result?

Astronomy: Time is an Angle

# The 360 Hour Clock, the 2π Hour Clock, and the 1 Hour Clock1

# The Tangent of Time

Mathematical Data Representation (ADT) Explained

# Algebraic Description of Types (ADT)

# Now, Prove That Numbers Exist.

# See Also:

Rethinking the C Time API

# Scope

# Nanoseconds, Floating Point Precision, and the Y2262 Problem

# “Broken Down Time”

# The Tragedy of tzset()

# Why Weekdays in the Time Structure are Bad

# Formatted Time

# In Defense of libc…

The Oldest Binary on a Mint System

# Lets compare

# Replication

Why I Don't Like GNU

# 1. “Linux was developed for the GNU tools” is False

# 2. For years, the GNU project was not directly maintaining most of their popular projects

# 3. The FSF intentionally makes code less modular to spread itself

# 4. glibc’s feature test macros are designed so that people would mark their code with the GNU projects name

# 5. GNU code sucks

# 6. GNUs obsession with portability adds copius amounts of complexity and helps no one

# 7. The FSF fractured the Open Source world for no good reason

# 8. GNU pushes incessantly for texinfo, a format no one likes or uses.

Writing a UTF-8 Safe AWK

# What a UTF-8 Safe awk Beeds

# Implementing a UTF-8 Awk

Replacing Neovim With Vis

Making a Static Site Generator with `make`

# The 360 Hour Clock, the 2π Hour Clock, and the 1 Hour Clock¹