appreciated

An Introduction.

A discussion of a variety of works that this author appreciates follows. They are presented here with the hope that they spark some interest in a prospective reader. This document is written with the expectation that a reader has some experience and interest in software development.


cat-v.org

cat-v.org introduced me to the potential beauty of a well-written program. Much of my study of programming and otherwise arts is now dedicated to the pursuit of that beauty.

The first of multiple sections of the site, I found harmful.cat-v.org's software section. I initially found it curious that staples such as bash or PDF may be considered bad or wrong. Near the bottom of the index page, it is written: “At the moment a detailed rationale is not provided for most of this, so figuring out why some things are considered more or less harmful than others is left as an exercise for the reader. Here is a hint: complexity is the bane of all software, simplicity is the most important quality.” Deciding to take upon myself this curious challenge, I slowly became educated upon what it means for a set of software to be, in a vague and aesthetic sense, good. Supplied in tandem with regular exploration of software that caught momentary fancy, the text available provided me some guidance.

A later discovered section of the site, quotes.cat-v.org, provided me with philosophical food for thought. Those that have impacted me, the person, have been re-sourced from their origin, then written below.


litcave.rudi.ir

I discovered this site some months previous to discovering cat-v.org. Perhaps I had found it when searching for vi implementations, for there was a time during which I searched for text editors for the sake of exploratory enjoyment. In any case, the software developed by this site's owner, Ali Gholami Rudi, continually amazes me.

Foremost, his implementation and partial port of Joseph Ossana and Brian Kernighan's troff is excellent. I use it for most documents that need be more glorious than a UTF-8 text file. This typesetting system enables me to create beautiful documents, and its usage continually sparks my interest in font design and data presentation. On a technical level:

Each of the features above are useful in practice, with an article of my school work serving as a real example of a document benefitting from the above features applicable to the Latin alphabet.

His C compiler suite, featuring an assember, linker, standard libraries, and a compiler, for Linux operating systems running on either ARM or x86 architecture, is both small and largely standard-compliant. Admittedly, too much of the world's code is designed around GNU's compiler suite for this compiler suite to act a drop-in replacement in a majority of C projects, however it is in and of itself very usable.

Ali Gholami Rudi uses Linux, and does not use Xorg. Restricting himself from conventional graphics support, he develops tools that make his predicament more pleasant. He maintains a program that wraps around existing document viewing programs so as to view PDF and EPUB documents within the Linux framebuffer. He regularly develops a terminal emulator that allows for the usage of TrueType fonts in the Linux framebuffer. He's come to use vi, and so he maintains his own vi implementation, that which is small, POSIX portable, and designed for UTF-8. His admirable efforts often have useful and interesting results.


alpinelinux.org

Intrinsically, Linux is a problematic and error-prone hodgepodge of conflicting designs, even if driven by good intentions. Linux comes to mind not for being a clean or ingenious Unix clone, but instead for being a popular and messy operating system backed by large corporations.

Disdain aside, there are examples of good design among the mess, and Alpine Linux is one such example. Importantly, GNU's software is largely averted, with dependence falling upon their library only for the surprisingly portable binutils and GCC, those which a compilation environment is often comprised of, even if POSIX need be brought along with it. The C standard library used is musl, that which is standards-compliant, small, and otherwise strives for correctness, even when that pursuit leads to incompatibilities with GNU's libc. The usual Unix-borne utilities are provided by busybox. Though busybox's code is less than glamorous – see the ending minutes of this presentation given by its previous maintainer – it is small and mature, and certainly more usable than the usual selection, GNU's coreutils. Alpine Linux's installation images are generally less than 200 MiB in binary size, allowing for RAM booting to be a sane default. The software packages available in the repositories are numerous, and the package management software is expedient. Though the distribution-specific documentation does have some rough edges, it is extensive.

There are multiple Linux distributions that try to do better than GNU's libc and coreutils, however Alpine is the only one I've noticed to put each of Linux's many pieces together so that the system works well in practice. In particular, Alpine Linux is the only Linux distribution that does not use glibc that I've been able to wrangle into running Xorg. The mess of KISS Linux's many split repositories and sparse documentation causes more woes than required of a minimally bootstrapped operating system. Oasis Linux is amazingly ambitious, particuarly for preferring cproc over GCC or clang, yet too underbaked to feel useful. TinyCore Linux boots to RAM, and its modern incarnations boast smaller size than any other Linux distribution. Unfortunately, a lack of good documentation averts me from its use, despite having tinkered with it for many hours. The gap between toy and ready product may be bridged by good documentation. A move away from glibc would be ideal, however secondary to the documentation issue. As a side note: I imagine glibc is one of the greatest causes of increase in binary size from release to release, for it is famously inflationary. What was once 11 MiB – TinyCore Linux 3.0 – is now 21 MiB – TinyCore Linux 13.0.

Linux is messy, and improvement is extra messy, which has done well to feed Debian and Red Hat's popularity; Debian and Red Hat are mature, and rarely change, and so the same quirks mastered years ago continually apply, for better and worse. Though there are many distributions that try to do better, and occasionally do achieve betterment, a majority of such distributions are generally too malleable or obscure to be reliable. Alpine Linux appears to be the only Linux distribution in any position to upset the frequency of use of GNU's C standard libraries and system utilities in actual practice, being both well-documented and mature.


bellard.org

I found Fabrice Bellard's web site during the year 2021. I was amazed by how much could be accomplished by someone both dedicated and creative.

Fabrice Bellard started what has become the media encoding software, ffmpeg. A subset of ffmpeg, libavcodec, has become a core part of many pieces of software, with there being a long list of such software, maintained by wikipedia contributors. On a personal level, ffmpeg has served as software for recording video, recording audio, the otherwise encoding of images and video and audio, and in particular for encoding animations from images. If not for it, I doubt the current existence of a suitable replacement.

Fabrice Bellard also started the Linux emulation software, QEMU. QEMU paired with KVM is a go-to when needing to emulate an operating system with native-ish performance. People who tinker use it quite a bit, and I imagine there are some businesses whose infrastructure depends upon QEMU.

An entrant into The International Obfuscated C Code Contest built upon, tinycc has become a mature C99 compiler. It is about an order of magnitude faster than GCC, and produces reasonably optimal code. C code can be either compiled or interpreted, with the interpreter functionality being baked well enough to be actually useful during development. When using either Windows AME, Alpine Linux, or OpenBSD, this is my first choice of C compiler.

Some lesser known however extremely impressive examples of his programming prowess are listed at the index of his site. Some particularly eye-catching ones include


other.stanleylieber.com

I found other.stanleylieber.com after traversing web sites regarding 9front, the foremost being cat-v.org and 9front.org. I first encountered it during the year 2022. This site encourages the best kind of doom scrolling. Image after image, chances are good that one of every few images strikes interest. That sort of consistent quality buys trust, and that trust may be spent in continued viewer attention. It's a sort of magic that I'd like to capture.


openbsd.org

Having mentioned above that Linux is a mess, it feels suitable to now explain a Unix derivative that is not. OpenBSD split from NetBSD 1.0 in 1995, which in turn was based upon 4.4BSD-Lite, which in turn was based upon twenty-odd years of development upon a Unix Version 6 installation performed at University of California, Berkeley. In the time between 1995 and now, OpenBSD has become an operating system that is stable, secure, and excellently documented. The manuals are concise without erring on being terse, the system defaults are sane and secure, and things do not break often.

Glittering generalities presented, some real examples may provide some validity to the claims given. Each program purpose-written for the distribution has a man page written in a consistent style, featuring English that is appropriately formal, a unique feature among Unix clones. Linux in particular often features man pages that are too long to grok and poorly written – commonly those written for GNU's software – or too little more than a list of options – most notably busybox. On OpenBSD, for those external programs that may be included in an installation by way of file sets, packages served by the repositories, or the ports tree, all documentation is included, that much being the best that can be reasonably expected. The programmer's documentation – so as to be explicit, this is one such page – is sincerely better written than any other set I've encountered.

Options that don't make sense to be enabled by default are not enabled by default. Audio recording is disabled, video recording is disabled, and daemons installed are not suddenly marked to run at boot. This last point may feel obvious, however I distinctly remember Debian Linux exhibiting the opposite behavior. There was a time during which a younger and less aware version of myself had apache starting upon each boot of my laptop PC.

Never has OpenBSD presented me with an issue that feels arbitrary. Installation makes sense, post-installation makes sense, with wifi setup being particularly well documented, and regular usage makes sense. These are vague qualities that describe general feelings, with those general feelings being my focus. There is a sense of comfort that eludes any Linux distribution I've used. It's a boring comfort, a stable comfort, a good one.

POSIX conformance completes this operating system. It is not a forgotten toy, or a promising dream, but a real and maintained product, compatible with real programs. A list of some that I value follows.

The programs that come with the distribution and are developed by the distributors are mature. ed and sh are each designed for human use, as opposed to busybox's maimed ed implementation, or Debian's Almquist Shell. The vi implementation handles UTF-8 unicode, while also not taking 20 or more MiB of binary space. This is not the norm on modern Unix; usually, either the very large Vim or the Unicode-mangling busybox vi are used. For those who crave emacs, there is an original micro emacs implementation included with the distribution. So as to prevent carpal tunnel caused by repeated use of CTRL on an ANSI or ISO PC keyboard, I recommend remapping CAPS LOCK to the left CTRL key, as documented here. For those who have content to host, OpenBSD has its own HTTP server, and its own SSL implementation to match it. OpenBSD has its own sound system, its own man page programs, its own kernel-resident virtual machine software, and most famously, its own SSH implementation. Not only do these implementations mark past creative effort, for their development is ongoing. Recent releases are announced first by mailing list, which are then often re-announced on the web. Development is consistently constant.

There was a single feature that cemented my decision to stick with OpenBSD. Aside from Xorg's installation being largely automatic, the touchpad driver worked. When using Debian, the default touchpad driver was … awful. I found a singular alternative driver, that which worked about as awfully. Despite haggling with xinput, it never felt good to use. Months after the fact, I found some magic words which work to better the behavior of one of those drivers, Synapics: synclient AccelFactor=0, and for those who like tap-to-click, synclient TapButton1=1. I suffered the same issues on Alpine Linux, and have now confirmed similar behavior on CRUX Linux. And yet, upon installing OpenBSD and then starting Xorg, and then moving the mouse, it felt good! There was no choppiness; the movement was smooth. Though there was some mouse acceleration I did not like, that was simple enough to disable via xinput, after which the touchpad behavior has been perfect, far better than anything I've found before or since.

OpenBSD provides my best preferred digital work environments, both on laptop and desktop hardware. For many months, a 12-or-so year-old laptop – of this make and model – dual booting between Alpine Linux and OpenBSD by means of GRUB has performed gracefully – they really don't make laptop keyboards the way they used to! On a desktop PC, a dual boot between Windows AME and OpenBSD by means of rEFInd serves well.


Envisioning Information

I found this book after having read about its author, Edward Tufte, in the 9front documentation. Having come to love 9front's text editors – sam and acme, I felt inclined to read some of the inspirational work. Understanding that sam and acme's designs were products of the 1990s, I was drawn towards Envisioning Information, the work that Edward Tufte published in 1990. I obtained a digital copy, transferred it to a 2013 iPad, and over the course of some weeks, read.

What I found within the pages continually earned my attention, and then earned my earnest thought. A majority of the pages feature examples of either excellent or poor data presentation, along with discussion and analysis of the given examples. A purely textual excerpt that particularly struck me follows.


What about confusing clutter? Information overload? Doesn't data have to be “boiled down” and “simplified”? These common questions miss the point, for the quantity of detail is an issue completely separate from the difficulty of reading. Clutter and confusion are failures of design, not attributes of information. Often the less complex and less subtle the line, the more ambiguous and less interesting is the reading. Stripping the detail out of data is a style based on personal preference and fashion, considerations utterly indifferent to substantive content. … So much for the conventional, facile, and false equation: simpleness of data and design = clarity of reading. Simpleness is another aesthetic preference, not an information display strategy, not a guide to clarity. What we seek instead is a rich texture of data, a comparative context, an understanding of complexity revealed with an economy of means. … But, finally, the deepest reason for displays that portray complexity and intricacy is that the worlds we seek to understand are complex and intricate.
— Edward Tufte, Envisioning Information, page 51


After reading and thoroughly enjoying this book, I found myself trying an essay of his, titled The Cognitive Style of Powerpoint: Pitching Out Corrupts Within. I found myself enamored in a way similar to my recent experience with Envisioning Information, though focused on a new topic upon which I was also uneducated. It is here that I came to understand the value of real paragraphs. A trifecta of excerpts follows.


In the reports, every single text-slide uses bullet-outlines with 4 to 6 levels of hierarchy. Then another multi-level list, another bureaucracy of bullets, starts afresh for a new slide. How is it that each elaborate architecture of thought always fits exactly on one slide? The rigid slide-by-slide hierarchies, indifferent to content, slice and dice the evidence into arbitrary compartments, producing an anti-narrative with choppy continuity. Medieval in its preoccupation with hierarchical distinctions, the PowerPoint format signals every bullet's status in 4 or 5 different simultaneous ways: by the order in sequence, extent of indent, size of bullet, style of bullet, and size of type associated with various bullets. This is a lot of insecure format for a simple engineering problem. The format reflects a common conceptual error in analytic design: information architectures mimic the hierarchical structure of large bureaucracies pitching the information. Conway's Law again. In their report, the Columbia Accident Investigation Board found that the distinctive cognitive style of PowerPoint reinforced the hierarchical filtering and biases of the NASA bureaucracy during the crucial period when the Columbia was damaged but still functioning … At the same time, lower-level NASA engineers were writing about the possible dangers to the Columbia in several hundred emails, with the Boeing reports in PP format sometimes attached. The text of about 90% of these emails simply used sentences sequentially ordered into paragraphs; 10% used bullet lists with 2 or 3 levels. These engineers were able to reason about the issues without employing the baroque hierarchical outlines of the original PP pitches. Good for them.
— Edward Tufte, The Cognitive Style of Powerpoint: Pitching Out Corrupts Within, 2nd Edition, page 12

Gerstner's blunt action shutting down the projector suggests that there are better tools for doing business analysis than reading aloud from bullet lists: “Let's just talk about your business.” Indeed, Gerstner later asked IBM executives to write out their business strategies in longhand using the presentation methodology of sentences, with subjects and predicates, nouns and verbs, which then combine sequentially to form paragraphs, an analytic tool demonstratively better than slideware bullet lists. “Let's just talk about your business” indicates a thoughtful exchange of information, a mutual interplay between speaker and audience, rather than a pitch made by a power pointer pointing to bullets. PowerPoint is presenter-oriented, not content-oriented, not audience-oriented. PP advertising is not about content quality, but rather presenter therapy: “A cure for the presentation jitters.” “Get yourself organized.” “Use the AutoContent Wizard to figure out what you want to say.”
— Edward Tufte, The Cognitive Style of Powerpoint: Pitching Out Corrupts Within, 2nd Edition, page 4

At a talk, paper handouts of a technical report effectively show text, data graphics, images. Printed materials bring information transfer rates in presentations up to that of everyday material in newspaper sports and financial pages, books, and internet news sites. An excellent paper size for presentation handouts is A3, 30 by 42 cm or about 11 by 17 inches, folded in half to make 4 pages. That one piece of paper, the 4-pager, can show images with 1,200 dpi resolution, up to 60,000 characters of words and numbers, detailed tables worthy of the sports pages, or 1,000 sparkline statistical graphics showing 500,000 numbers. That one piece of paper shows the content-equivalent of 50 to 250 typical PP slides.
— Edward Tufte, The Cognitive Style of Powerpoint: Pitching Out Corrupts Within, 2nd Edition, page 30


It is through these paragraphs and others that I came to realize the inappropriacy of deeply heirarchical lists, that realization having prompted me to rewrite this page of appreciations. For the sake of comparison, a copy of the previous iteration, last touched 2023 march 31, is kept.


Advent of Code

Advent of Code has taught me how to use a struct, why and when data structures should be calloc'd instead of dumped on the stack, how to use free, what “Dijkstra's Algorithm” is, and a lot of little details in-between. Participating has closed the gap between theory and practice, and for that I am very thankful. Linked here is a video snippet of an eventual solution after three hours of attempt.


miscellany