levineuwirth.org/content/colophon.md at 866001ba7d5fbf5da76d3cd6f6d12f467f0f5d94

17 KiB

Raw Blame History

title

date

modified

status

Typography

::: dropcap You are reading this sentence in SPECTRAL, which is not only a font with particular personal importance to me, but also an exceedingly pleasing font to read. [OpenType]{.smallcaps} features — smcp, onum, liga, calt are used throughout the website, which necessitates our self-hosting setup.^[Google Fonts strips OpenType features during subsetting for bandwidth. Self-hosting with pyftsubset preserves smcp (small capitals), onum (old-style figures), liga (common ligatures), and the full optical size range. The difference is visible: old-style figures sit on the baseline rather than hanging above it, small capitals are drawn to match the x-height rather than being shrunken full caps, and ligatures prevent collisions in letter pairs like fi and fl.] :::

The UI and headers are Fira Sans. Variation is good, and moreover, humanist sans are rather ubiquitous (we have Frutiger to thank for this fact!) - perhaps I am making some type of statement by not choosing one of the more corporation variations of it, like the dreaded Calibri and Tahoma you might recognize from Microslop (formerly known as Microsoft) products. Code uses Jetbrains Mono, which is simply the font that I use within my editor. Code should look like code, simple as that.

The monochrome palette is an application of restraint grounded in my studies of Tools for Thought. Color is often used to do work that typography should do, such as demonstrating hierarchy, creating emphasis, etc. When those functions are handled by weight, size, and spacing instead^[Color and saturation/hue are actually well known to be less effective than other means of distinguishment. I refer you to Tufte's The Visual Display of Quantitative Information for more.], color becomes available for the things it cannot be substituted for — and on a site with no data visualizations requiring color encoding, those things turn out to be very few.^[The one exception is the heatmap on the statistics page, which uses a four-step greyscale scale. Even there, the encoding is luminance rather than hue.]

The Build

This is a Static Website. For the purposes of this website, though the content is highly dynamic and iterated upon, the medium of expression is rather stable. There are numerous advantages to using a static webpage, many of which are focused at the Hetzner box from which this webpage is served. I use Hakyll for reasons of performance, extensibility, and, of course given the underlying language Haskell, elegance! I had been wanting to do a project in Haskell ever since I took my undergraduate programming languages course,^[The programming languages course at Brown, somewhat infamous, is taught entirely with Racket, which is essentially a dialect of Lisp. The course itself is extremely focused within the functional paradigm as far as implementations go. I am aware that Racket itself, curiously, has some means by which static webpages can be built - the course infrastructure was produced this way, and this website has in a few places taken minor inspiration from it!] and Hakyll was more extensible and thus suitable than the alternative I was looking at most strongly, Hugo (in Go, a language with which I am intimately familiar). The philosophy of a static website is that the website is a program and the content is the source code^[Source code here chiefly distinct from mere markup language, like HTML.]. The step of compilation present in Haskell, which is outlined below, means that what you have here received in your browser is not merely a runtime rendering decision, but rather a deterministic artifact. By this step of compilation, the Markdown in which I write these webpages is transformed to exactly what you currently see.

The AST we use is heavily customized and modified. The chain is roughly markdown -> pandoc -> citations -> wikilinks -> preprocessing -> sidenotes -> smallcaps and dropcaps -> links -> images -> math. Mathematics with LaTeX requires a second pass and is rendered at build-time with KaTeX - no math rendering occurs in your browser. Samples from music are displayed as SVGs, generally typeset with Lilypond through some helper scripts I wrote to automate the process.

The semantic search model is a particularly intriguing aspect of the website. The model used is self-hosted, with weights served from the same origin. There are NO external API calls when you use this, in contrast to just about every other similar feature on other websites. This is essential for the privacy model that this site strives to achieve - see Design Decisions for more.

A full accounting of what this build process has actually produced is available at the Build page. It is generated automatically at each compile: corpus word counts, length distributions, tag frequencies, link analysis, epistemic coverage, repository metrics, and build timing — all computed from the same source tree that produces the content. Think of it as the build system reporting on itself.

The Computing Environment

::: dropcap Every tool I use was chosen rather than accepted. This distinction matters: the default path through the software ecosystem, particularly for developers, routes through choices made by convenience, employer mandate, or inertia rather than deliberation. I have consistently refused that path — not out of contrarianism, but because I find that the tools one uses become constitutive of the work one produces. This site is downstream of those choices in every particular. :::

Desktop

My primary desktop is a rig I built myself, running Gentoo Linux with Hyprland and a custom shell, Levshell, implemented with Quickshell. The reasons for Gentoo are worth stating explicitly, since the choice is frequently met with bewilderment:

Compiling software from source delivers measurable performance increases — not marginal ones.
It provides fine-grained control over software configuration via [USE]{.smallcaps} flags, linking options, and the like. This matters for a machine tuned to a high degree of specificity.
It is, in my experience, the best-maintained Linux distribution I have ever used.
The community is phenomenal.

I have strong hardware preferences to match: [AMD]{.smallcaps} processors and graphics throughout. This is not tribal loyalty — I have used multiple distinct products from each major vendor and formed the preference empirically.

Laptop

For mobile computing, I use a [P]{.smallcaps}-series ThinkPad running Arch Linux — the same Hyprland environment, the same Levshell, the same muscle memory, but without the compilation overhead. Gentoo is impractical on battery-constrained hardware: compilation times are simply too long, and running the compiler continuously on battery is not a reasonable tradeoff. Arch is a sound alternative. Portage is better than pacman, but pacman on a laptop is entirely correct.

The Hyprland environment runs identically on both machines. This is deliberate — I do not want to maintain two workflows. Every keybinding, every visual detail, every tool behaves the same. The continuity is itself a productivity commitment.

Editor

Everything on this site — every word of prose, every line of Haskell, every [CSS]{.smallcaps} rule — was written in Emacs. I use Emacs for the same reason I use Gentoo: it is configurable to a degree that other editors treat as pathological. Running make watch alongside an Emacs buffer gives something close to a [WYSIWYG]{.smallcaps} experience for this workflow: save the file, the Hakyll watcher recompiles, the browser updates. The loop is tight enough that the editor and the rendered output feel nearly continuous.

Privacy-First Computing

My email and [VPN]{.smallcaps} are self-hosted; I use Thunderbird as a client for the former. For browsing I use LibreWolf, not Firefox: the Chromium monopoly and Mozilla's evident incompetence at browser development are, to me, equally concerning developments, and LibreWolf is the most coherent response to both. My phone runs GrapheneOS — the only reasonably secure and private option for a mobile device, and one whose restrictions are, frankly, a feature rather than a limitation.

The principle underlying all of these choices is the same one underlying the site's No Tracking policy: privacy is an architectural decision, not a settings toggle. You build the infrastructure first. Bolting on privacy after the fact, whether in a browser or on a website, is not privacy — it is the appearance of privacy.

[AI]{.smallcaps} and This Site

::: dropcap I will never use AI to write, whether for my personal communications with anyone or for pieces on this website. I take this extremely seriously - writing is religious in severity to me. The writing on this website is wholly human and wholly my own, to the extent that any writing can be. :::

Much of the code that comprises the build system of this website was created in collaboration with AI. Rather than "vibe coding" proper, this was the result of an intensive engineering process where AI and I were equals in collaboration. Notably, all of the major architectural choices, design decisions, idiosyncracies, and elements of the tech stack were chosen entirely by me, and AI systems were only used to automate production of some (but not all) of the code that was required.

The commit history, of course, is available for you to view and licensed accordingly - see No Tracking for more.

Design Decisions

Sidenotes

The sidenotes are provided by a JavaScript file that was forked from the website of Gwern Branwen and authored by Said Achmiz; I have simplified the script to fit the needs of this website and made some minor modifications.

No Tracking

The site has no analytics, no visit counters, no fingerprinting, and no third-party scripts.^[This is enforced at the nginx level via [CSP]{.smallcaps} headers, not just by omission. The Content Security Policy prevents any script not explicitly whitelisted from executing. The whitelist is short.] The Hetzner VPS that provides this content runs only open source software, and my machines use almost exclusively^[It is nearly impossible to run an entirely free system, but in approximation, it is actually wonderfully easy.] the same. The code is licensed under MIT and hosted on a public repository at this domain with a GitHub mirror; you are welcome to inspect it, fork it, or, more broadly, do whatever you please with it.

Living Documents

The dominant convention of academic and professional publication is that a document, once released, is finished. It carries an implicit claim: this is what I think, full stop.^[This is particularly problematic in academia, where there is a long tradition of researchers whose work was eventually disproven taking an extreme defensive stance, usually rooted in confirmation bias.] I find this convention dishonest in proportion to how seldom it is actually true. Thinking is continuous; positions shift; evidence accumulates; people change their minds and rarely say so in public. This site operates under a different premise, one that I strive to operate all of my life under.

Every essay and post on this site carries an epistemic footer — a structured block that reports my current relationship to the work. The footer only appears when a status field is set in the document's frontmatter; standalone pages and very short items omit it. The full set of fields:

Status — a controlled vocabulary describing where the work stands: Draft, Working model, Durable, Refined, Superseded, or Deprecated. A document marked Working model is not just unfinished — it is a position I currently hold but would not stake much on. A document marked Durable is something I expect to hold up. Superseded means I wrote a better version; Deprecated means I no longer endorse it.
Confidence — an integer from 0–100, representing my credence in the central thesis. Not false precision: a rough honest assessment is more useful than no assessment at all. When a confidence-history list is present, a trend arrow (↑ ↓ →) is derived automatically from the last two entries — so you can see not just what I think but whether I am growing more or less confident over time.
Importance — how much I think this matters, on a 1–5 dot scale (●●●○○). Useful for orienting a reader who has limited time.
Evidence — how well-evidenced the claims are, on the same 1–5 scale. An essay with high importance and low evidence is a speculative position and should be read accordingly.
Overall score — a single 0–100 integer derived automatically from the three quantitative fields above: confidence weighted at 50%, evidence at 30%, importance at 20%. It appears adjacent to the Epistemic link in the top metadata row and is not entered manually.
Scope, Novelty, Practicality — optional qualitative fields in the expanded footer. Scope ranges from personal to civilizational; novelty from conventional to innovative; practicality from abstract to exceptional. These are not ratings — they are orientations.
Stability — auto-computed at every build from git log --follow. The heuristic: very new or barely-touched documents are volatile; actively-revised documents are revising; older documents with more commits settle into fairly stable, stable, or established. This requires no manual maintenance — the build reads the repository history and makes the inference.

The version history block, directly above the epistemic footer, uses a three-tier fallback: authored history: notes when they exist (written by me when the git log alone would not convey what changed), then the raw git log, then the date: frontmatter field as a creation record. make build auto-commits any changed content files before the Hakyll compilation runs, so the git log is always current.

The point of all this is simple: when you read something on this site, you should know what kind of claim I am making. The date a document was last modified is not decorative. A 40% confidence rating is not self-deprecation. The system is an attempt to make explicit something that most writing leaves implicit — where the author actually stands.

Influences

The amount of influences on this website is immense, and cannot be detailed in the fullest extent. Every other webpage that I have visited, whether beautiful or pitiful, has evoked some type of reaction or response in me, and that response has played some role, even if minute, in the design of this website. I can point to Tufte's influence on many of my design choices, and for the introduction to Tufte, I am thankful to CSCI1377 at Brown. I am thankful to the many other courses I took in my undergrad that influenced how I interact or ideologically view visualizations, networks, systems, etc.

The tradition of the personal website is one that is built on a sense of community and interaction. I am thankful to everyone else who has a personal website and shares their content with the world. I am also particularly greatful to the open source and broader open culture movements, who have given me and the world so much. This website would not exist without you - and I wouldn't be the person I am without your influence - what a role model!

The Future

This site is unfinished. Several portals have no content yet. The annotated bibliography is sparse. I am in the progress of migrating content, so stay tuned!

The colophon itself is a living document. When the site changes substantially, this page will change with it. The git history functions as an authoritative record; this page is my personal annotated summary.

17 KiB Raw Blame History Unescape Escape