nove.dev

katamari architecture

2026-09-23T21:30:00-07:00

or, how to build a star out of mud

User marginalia^[1] on lobste.rs compared the output of poorly-directed software development LLM agents to the "katamari" from Katamari Damacy: a video game in which you roll a clump of miscellaneous objects around, sticking everything you can find to the outside. It's an apt comparison; agentic development tends towards feature addition without attention to composition - they take the shortest path to accomplish the prompt. It has all the worst qualities of an underpaid and short-on-time human engineer. However, I think the analogy does a disservice to Katamari! The spirit clod is carefully crafted (algorithmically, sure, but the algorithm was carefully crafted) to appear thrown-together and unplanned, but the method by which they made the ball naturally round has enough complexity that they thought it warranted a patent. By contrast, LLMs don't have the sense required to determine how to properly add whatever new feature their prompter desires, it's just stuck on at random (modulo a probability distribution). Despite that, katamari architecture is a catchy-enough buzzword that I hope it "sticks" around!

Katamari architecture is here, but it's not a hopeless problem. Let's see if we can learn from prior work.

The obvious comparison is the Big Ball of Mud architecture. Foote and Yoder argue that several "forces [...] conspire" to create BBoMs - time, cost, experience, skill, visibility, complexity, and scale. Considering driving forces is a good way to understand a phenomenon: steelman Chesterton before slandering his fence. LLMs of course run roughshod over the metaphor, since they send fences zipping across vast expanses for no intelligible reason, moving them around at random as they sycophantically make bullshit replies to your incredulous questions. But I digress; can you build a katamari from the same impulses as mudballs?

Time: LLMs have plenty of time. Ostensibly they can work far faster than any human developer, 24/7 and over weekends and holidays. Time is not the issue.
Cost: Many companies have unlimited token budgets, whence tokenmaxing. If LLMs were any good at architecture, cost would be no object. The entire pitch of LLMs is that they're cheaper than humans to do the same work; cost isn't the issue.
Experience: Frontier LLMs are trained on (more-or-less) the sum total of all software ever written, along with all books, blogs, and forum posts ever written. There is no architectural process that LLMs are unfamiliar with, even though the nature of the beast means LLMs don't bring up anything besides the middle-of-the-road, lowest-common-denominator ideas without being, uh, prompted. Experience isn't the issue.
Skill: Debatable. LLMs exhibit inhumanly "spiky"^[2] intelligence, similar to other automated systems. They're impossibly good at some tasks (underspecified search through a large corpus of text) and hilariously bad at others (any number of publicised LLM epic fails, e.g. strawberry syndrome, car-wash transportation, considering a vending machine metaphysically impossible). As anyone who has to review LLM output for a living knows, the mistakes they make are not the same mistakes a human would make, and they're much harder to spot. Lack of skill is probably contributing to katamari architecture.
Visibility^[3]: LLMs excel at generating vast swaths of code as far as the eye can see - which is part of the problem. No one is going to perform a close reading of a +6,000/-400 sloc PR - it's exhausting, and it's not going to change anything. The more LLM-generated a codebase, the worse visibility becomes. Andrej Karpathy doesn't even read the code anymore. As Foote and Yoder put it, "[i]f the system works, and it can be shipped, who cares what it looks like on the inside?" That's the mantra of the modern vibecoder to a T. Just surrender your cognition, embrace the clod!
Complexity: Most software has quite little essential complexity, and at this scale Conway's law isn't relevant. Complexity may explain some BBoMs, but not the LLM-generated katamaris. I imagine a plurality of truly complex domains still have mostly hand-authored software, though it's a downward spiral at this point.
Change: Human effort is a natural brake on the pace of change. Automatic coding accelerates change; LLMs make implementing a new change as easy as requesting it (with some rather heavy asterisks). Unlike human change, though, LLM-effected change tends to agglomerate onto the existing architecture (such as it is) rather than cut through the heart. A heavily LLM-affected katamari codebase often has a well-designed (human-designed, typically) core, obscured by layers of stylized household objects. An agent may decide to redesign the entire system, but rarely does it have the wherewithal; a redesign or rewrite is rightly feared by software artisans as complex, painful, and interminable. LLMs going for a redesign on their own are doomed to failure.
Scale: Foote and Yoder's point (unless I've misunderstood - the original is a little unclear to me) is that otherwise-skilled designers struggle to find elegance when faced with massive projects. I don't find this applies to agents all that well, they have mediocre performance even in the small. They don't get any better at working at a large scale, though.

Context compacted

The main contributors from this list are skill, visibility, and change. LLMs are simply not very good at writing code relative to a skilled human, they're a whole new level of invisible code, and they axe the aerodynamic drag that keeps otherwise-muddy projects from collapsing into slop, ten 15,000 sloc PRs at a time.

The visibility one is getting stuck in my craw. It wasn't bad enough that users couldn't see the horrible mud inside the application, now not even the developers are reading the code? we're so cooked chat

what is to be done?

LLMs are the accelerationist dream realized. Burn the coal, poison the well, kill the open web, hack the planet (starting with the rainforests). Weed out anyone with latent schizophrenic tendencies. Obsolete trust. Flood the internet with the unspeakable. Hope we come out the other side with infinite renewable energy, infinite compute, secure and performant software, abolished copyright and universal leisure. Cure all the diseases while we're at it. My anarchist utopia sure isn't going to happen as long as the billionaires hold the keys, though. If jyn has any idea what they're talking about, we'll all have Astra-class models on our phones in a few years. Seems unlikely on the face of it.

Hard though it may be to believe, I'm no doomer. Vibecoders are way off, but it's apparently possible to use these accursed orbs to build better software. I also don't claim to have a magic spell capable of bending the cthonic entities to our wills, but non-generative applications have the most promise. LLMs are evidently capable of finding legitimate bugs in carefully written code. Like fuzzing, it burns oodles of compute for this privilege; like fuzzing, hyperscalers are happy to send some ~~alms~~ free compute to keep their pet OSS debugged.

One idea I've seen floated is that of an arms race between slopmeisters and software maintainers: "you cannot use LLMs to contribute to this codebase, unless I can't tell that you used an LLM." I like this - it gives overburdened maintainers carte blanche to send any sloppy PRs to the shadow realm, for one, and in Eliza's words, "the act of rewriting the model-generated code to not Look Like That forces the person who generated it to actually read and understand it thoroughly."

Foote and Yoder eventually conclude that BBoMs are a cynically optimal choice - software changes so rapidly under our feet that "expedient, slash-and-burn, disposable programming is, in fact, a state-of-the-art strategy". I disagree with them, and I assert that katamari architecture is no better. BBoM and katamari architectures are coping mechanisms, wrought from the trauma of disillusioned practitioners being compelled to deliver endless vanity features while blowing past delivery's cosmetic deadlines. Software ate the world, and now it's eating us. We don't need damn-the-torpedos full-throttle break-neck speed, we need care and attention.

I want smaller software with less bugs made by people who are paid more to work less^[4] and I'm not kidding!

Author of the excellent smallweb search engine marginalia ↩
Spikes are relative to "human standard", which means neurodivergence (especially autism and ADHD) is often classed as spiky. In no way am I describing LLM intelligence as akin to autistic intelligence - the spikes are not aligned. There's only one way to be normal, but a variety of ways to be abnormal. ↩
A deeper visibility problem, that doesn't fit with the rest of this polemic - LLMs are more-or-less black boxes (notwithstanding some fascinating attempted brain surgery). We have no idea what's going on inside there. Explainable AI is as much a pipe dream as it was in SOPHIE's (recommended listening) era. ↩
Worker-owned co-ops might help. ↩

how to not fall for scams in the age of AI

2026-09-10T10:40:00-07:00

it's now roughly free to send a personalized, grammatically-perfect email from an account that seems to belong to a human. gone are the days where princes from a country on the other side of the world would drop apostrophes when trying to disburse millions of dollars to internet strangers. the most suspicious emails and texts we receive on a regular basis are legitimate communications from delivery companies attempting to coerce us to pay them for tariff paperwork. the old world is dying, and the new world struggles to be born.

the best way to avoid losing all your money is to stay calm in the face of uncertainty and fear. the second best way is to establish an independent mode of communication. the third best way is to be skeptical of too-good-to-be-true offers.

in general, emails and texts can be ignored for a few hours or a day without much consequence. that's plenty of time to come back down to your emotional baseline.

if you're contacted by someone claiming to be your bank or credit card provider, hang up. there should be a phone number on the back of your card; call that number, wait in line, and tell the nice receptionist what happened. if there is really something happening, they will know about it; if not, you've avoided being scammed and can feel glad about your safe practices. the same goes for a delivery company, cloud storage provider, internet provider, and whoever else. hang up / close the email, google the name of the company, and contact them directly. if you don't recognize the company, you can generally ignore it.

clicking on a link is very safe, browsers like chrome, firefox, and safari put immense effort into making sure of that. the main danger is that you are tricked by the webpage pointed to by that link - maybe it looks like your bank and asks for your password, maybe it says you have malware and asks you to run a program, maybe it looks like a two-factor authentication or anti-bot captcha. it takes technical savvy and alertness to discern a real webpage from a scam. it helps to use a password manager with autofill - if your password doesn't autofill, it might not be safe. if you're uncertain about something, it's always best to contact someone you trust that's good with computers. they'd much rather help you out than have you fall for a scam.

what is to be done about web hosting in 2026?

2026-09-03T21:40:00-07:00

so far, my web infrastructure has been mostly hosted on cloudflare. they offer a reliable, feature-rich, and fast free tier. however, i've been gradually souring on their business practices and general m.o. as a company. the question is, what alternatives exist? i'm not opposed to paying a nominal fee if i have to (like, maybe $5/mo in total?), but my needs are so modest that i'd really prefer not to if possible. i definitely do not want flexible billing, at least without a limit (that scared me off fastly). if there is the possibility of waking up to thousands in egress fees, i am not interested. i do pay google for cloud storage for my family, and i pay a friend to host a fediverse instance for me on her colo.

static site hosting

this service is free, or nearly so, at many service providers. i currently use cloudflare pages, i used to use github pages, there are options from vercel and others last i checked. none of those are interesting to me at this point. i like the idea of grebedoc - community-driven web hosting led by an entity i've been following for a long time and whose technical and personal opinions i usually am aligned with. however, it's far from battle-tested, and (imo) carries a higher risk of shutting down prematurely due solely to its recency. still, it's not like you're locked in to a static host. i like grebedoc.

domain registry

commodity web service that costs a pittance each year. i used to use google domains until they shuttered and i relocated to cloudflare. i have heard good things about porkbun, but honestly the name is distasteful to me and i'd rather not. is njalla any good? more research here is needed.

cronjob compute

i have a service, <watertable.nove.dev>, that needs to wake up every night, crunch a bunch of time-series data in python, render and upload a website, and shutdown until tomorrow. so far i've been using cloudflare pages' build step to crunch the data and a cloudflare worker on a crontab to trigger the rebuild. it works quite well! this is not a service that i see offered for free from very many other providers. i could leech off of the ci compute of my git host (e.g. tangled, or just github actions (🤮)). i suppose i can self-host the crontab as well. i am somewhat averse to anything involving self-hosting for this particular service, though, because people that aren't me trust and rely on it for accurate and up-to-date information. maybe i will need to get some uptime monitoring service. is that free? hmm.

email routing

my email is hosted on gmail, and that's not likely to change any time soon. i have been using <wildcard>, at, <my.domain> (obfuscated in a futile attempt to ward off scrapers) email addresses for a while, though, so i need to keep a wildcard redirect / mx record, or whatever, plus all the dkim/spf/dmarc nonsense. not everyone does this for free, as far as i know. i used to know all the details of email. i should do some more work on our hobby smtp server :)

call to action

what do you use for these? do you know any good options here? do you host some of these yourself? please let me know! i have a wildcard email record on this domain and love getting emails from humans :)

advent of code 2025

2025-12-01T12:06:00-08:00

last year i never did any aoc, though i've been retroactively working on some of the problems. this year i'll do it!

i always aspire to complete the whole month and get stymied partway through. hopefully this year will be different :) i will show more persistence and do more background research on the compsci fundamentals; maybe i'll write some abstracted algorithms or data structures to do frequent tasks. the recommended reading below is mostly for myself!

i'm putting my solutions on tangled, writing in rust, using jujutsu for version control, and a nix flake for a dev environment. it's a good mix of low-friction while still using new tools that i want to be better at. plus, i don't use rust at work much anymore, so i need to keep the proverbial rust off.

thoughts on the latest cloudflare outage

2025-11-21T20:06:00-08:00

against my best instincts, i will put forward my opinion on the recent cloudflare outage. you should probably read their postmortem for context.

intro and background

tl;dr is that a quarter of the internet went down because a database change caused oversized config files to be propagated to a critical component of their core proxy. this component used a fixed amount of preallocated memory as an optimization, and nothing validated the size of the config it was parsing. when the oversized config was loaded, the application crashed, which translated into an http 500 server error, which blocked all traffic attempting to traverse that component. in other words:

cloudflare: i would like to parse dynamic config generated by an external service
        me: fair enough
cloudflare: i would like to restrict the size of this config, for performance
        me: fair enough
        me: what will you do if the config is too big?
cloudflare: die instantly
        me: ah.

spooky scary sloppy rust code

the snippet of code provided in the postmortem is as follows:

pub fn fetch_features(
    &mut self,
    input: &dyn BotsInput,
    features: &mut Features,
) -> Result<(), (ErrorFlags, i32)> {
    features.checksum &= 0xFFFF_FFFF_0000_0000;
    features.checksum |= u64::from(self.config.checksum);
    let (feature_values, _) = features
        .append_with_names(&self.config.feature_names)
        .unwrap();

the problematic part is that last line: .unwrap(). in rust, errors are handled using sum types, namely, Result<T, E>. this Result object can then be dealt with in various ways: either explicitly with match, if let, or let ... else; automatically with ? or .unwrap_or_else(); dangerously with .unwrap(); or unsafely with .unwrap_unchecked(). here's how each would have looked; don't mind the owl references, we'll get to it:

//we don't know the actual return type of .append_with_names(), 
//so this is a guesstimate:
let res: Result<(Vec<FeatureValues>, Unknown), AppendError> 
    = features.append_with_names(&self.config.feature_names);

//handle the error directly
match res {
    Ok((feature_values, _)) => /*do whatever you needed to do here*/,
    Err(error) => {
        log_error!(error, "failed to append features when loading config");
        //draw the rest of the owl
    },
}

//find a safe default
let (feature_values, _) = res.unwrap_or_else(|error| {
    log_error!(error, "failed to append features when loading config");
    (vec![], Default::default()) //draw the rest of the owl
});

//bubble it up - let the caller draw the rest of the owl
let Ok((feature_values, _)) = res else {
    log_error!("failed to append features when loading config");
    return Err((ErrorFlags::AppendError, 120)) 
    //who knows what this error return should be
};

//another way to bubble it up, more conveniently but without a local log 
//(assuming the error type is convertible)
let (feature_values, _) = res?;

//the bare minimum - cloudflare's actual solution.
//crash the program if you can't append
let (feature_values, _) = res.unwrap();

//more or less equivalent to the above, with slightly better debuggability
let (feature_values, _) = res.expect(
    "there should be a max of 200 feature values"
);

//abdicate all responsibility. perform undefined behaviour if you can't append. 
//here there be memory corruption. summon the nasal demons.
//thankfully cloudflare had the sense not to do this
let (feature_values, _) = unsafe {
    res.unwrap_unchecked()
};

what's wrong with unwrapping

unwraps are to be used in one of two^[1] scenarios:

you do not care about your code very much. if it crashes, who cares
the error is believed to be completely impossible. there is an invariant being upheld that rust's type system is insufficiently smart to prove. if the value is an error, something has gone catastrophically wrong and no assumptions can be made about the state of the program. the only safe response is to panic, unwind the stack and kill the entire thread. we can only pray that is enough.

this unwrap falls in neither of these. cloudflare's core proxy is critical infrastructure and thus must make every effort not to crash, eliminating the first point. the second is where cloudflare-positive discourse seems to have placed them - the engineer and code reviewer must have believed it impossible to fail here. i disagree - in a situation where you are parsing input provided from an external system, generated by a database, across a network boundary, no assumptions can be made. operate as if it is, if not actively malicious, at least highly suspicious.

cloudflare's core proxy code should probably have zero potential panics in it. this makes it more difficult to write rust, i understand that. if they must write panicking code, at the very least it should have safety-style comments above each potential panic indicating why the engineer believes a panic is impossible.

additionally, this component of the core proxy was a filter designed to keep llm scrapers and other (semi-)malicious bots from accessing a client site. in the event of a catastrophic failure like this, the component should obviously fail open - bot management is not a reliable security boundary, and increasing load / visibility is far superior to taking the website off the internet altogether. present one of those horrible little javascript challenges on each page load if you must (i'm thinking of ticket-sellers looking to avoid being bought out by bots), but don't break the web. different components have different threat models; i'm sure e.g. their zero trust product would prefer failing closed.

crux

the core of the issue is an unstated, unvalidated assumption - the config will never exceed 200 features. rust did its best to warn the coder about this issue; the coder responded by explicitly ignoring the concern, and this outage is the result. a sufficiently conscientious programmer and reviewer would have looked at this Result, thought "how might i handle this properly", and pursued a proper solution.

now we finally return to "draw the rest of the owl"; it is not obvious what this solution should have been. i have several ideas: there could have been a validator in the config generator or distributor, plus a //SAFETY comment immediately before this unwrap; that would have prevented the outage. i'm hesitant about this, though - if the validator fails, we're back where we started. the solution could have also been a configuration manager that stores past versions, so the proxy could revert to a previous known-good config in the event of a misconfiguration like this.

how i would have fixed this

configuration is about defining a point in multidimensional space. this point is fed to your program to define its initial state and rules about how it handles input and output. if configuration fails, a critically important program should continue to work at all costs, in this case by statically choosing an acceptable default point in the state-space, inhabiting it, and logging a maximum-severity error message. ideally, such a message would trigger an alert and page an on-call engineer to fix the problem immediately, but until then, nothing is fundamentally broken. for this program, the sensible static default is "allow every request through".

postscriptum - response to "this is rust's fault"

if this had been c, cloudflare would have failed to check the error code and proceeded to perform undefined behaviour. whee, memory safety cves! if this had been java, javascript, python, go, haskell, c#, kotlin, lisp, etc., this program would have been ripped out and rewritten in rust; if cloudflare is so memory-constrained as to only allow 200 entries in an array, a garbage-collected language would have been right out. if this had been c++, it would have thrown an unchecked exception, same as the panic, and the outage would have been exactly the same. maybe zig solves this; i haven't written any zig.

rust is not a perfect language. the naming of .unwrap() is suboptimal; error handling in tutorials and educational work is often brushed under the rug with it. maybe in rust 2.0, which will never happen, we can rename unwrap. until then, it is the professional responsibility of engineers, at least those who create programs which must have extremely high reliability, to understand the language in which they work and not litter their code with potential crashes.

there is a third^[2], false option: if you handle panics with catch_unwind or a panic hook, and you will convert the panic into an error 500 or something. cloudflare probably had this, it's common in web frameworks. this is not something you want to rely on. panic catching is dangerous; if you panic within a panic (either in a Drop implementation or the panic handler) it hard-aborts your program immediately. also, responding with a 500 is not actually the correct response in this case! as i said above, this filter should have failed open, not responded to every request with a 500. listen to the rust documentation: "it is not recommended to use this [...] for a general try/catch mechanism" ↩
another, even less defensible idea: you are allowed to panic if there is no sensible way of responding to such an error. i disagree with this - in a webserver, you want to respond to the client no matter what; in a user-driven app with a gui, tui, or cli, splatting a panic stacktrace is not a friendly user experience; in a library you should really never panic but always return some indication of failure, etc. ↩

on correctness

2025-11-17T13:00:00-08:00

correctness should be the baseline in software. luckily, correctness is a mathematical property of an algorithm, and thus we can use computers to help humans build correct software. millions of lines of code have been written for the express purpose of helping humans prove subsets of correctness. i'm thinking of (ranked by how much assurance they provide, in decreasing order): formal verification, type systems, linters, property testing, unit testing, fuzzers, autoformatters, and syntax highlighters.

formal verification is the highest standard of correct software. i do not have direct experience with it. to my understanding, it converts many programming errors into much fewer specification errors, which tend to be easier to solve.
type systems, when implemented kindly, are the best tool for correctness. they enable local reasoning, tooling support, invariants. when implemented with the sharp edge against the programmer, the programmer learns to hate them. the difference between a kind type system and a sharp type system is how the programmer feels about the type system. if the programmer writhes in its grasp, flailing against the oppressive all-seeing eye of "computer says no", the type system is not helping achieve correct software. if the programmer uses the type system as a tool, sketching their software out in broad strokes, knowing with certainty the potential states and being assured of the correctness of composition, it's good.
1. i have a distaste for gradual typing systems, as the flow goes something like this: working, highly dynamic program -> overlaid type system incorrectly proclaims incorrectness -> programmer develops hatred for type systems
linters are a good way to soften the blow of a compiler error. moving from "computer says no" to "computer says you're wrong, but here's an escape hatch labelled 'do not use'". the downside of this approach is obvious, however: programmers are creatures of infinite creativity and chaotic alignments. when deadlines are imposed, the programmer is burnt out, or years of useless lints have jaded their saliency checker, lints are ignored and software is built incorrectly. equally, escape hatches allow lint writers to be more careless about false positives, pushing the vicious cycle one step further
property testing is interesting to me. i have used it but lightly, and never in anger. from my perspective, property testing gives you 80% of the assurance of formal verification with 20% of the effort. of course, an 80% correct program is rarely good enough. the core conceit is to formalize properties about your functions, formalize ways of generating input to said functions, and machine-checking the whole shebang.
i have described unit testing suites as brittle exoskeletons attached to the nerves of a program. with the slightest twitch, a change to a program can shatter its exoskeleton to dust while self-inflicting great pain. the result of this, and thus the purpose of unit testing systems, is to disincentivise change of any kind. have fun migrating off .net 6.
1. however, i have had the immense displeasure of refactoring a complicated program with no test suite whatsoever. combined with the total lack of documentation, hyrum ensured that any minor modification would break something with no warning. therefore, i consider unit testing to be something of a necessary evil, and keep hope that a better world is possible.
2. property testing suffers from the same problem in theory, yet in practice the properties are sufficiently abstract as to allow for enough program movement so as to not atrophy.
fuzzers are a reduced form of property testing applied to an entire program, usually with some level of codepath-aware analysis to minimize breadth-first-search-itis. the exoskeleton is kept at a safe distance from the slithering muscles beneath, which allows for major refactors that don't change the basic api. however, they don't check correctness. fuzzers can root out memory safety bugs, edge case crashes, and input mishandling, for which they are invaluable, but a fuzzer on its own isn't good enough.
autoformatters, like type systems, are best when they are human-focused and not impositional. an autoformatter offloads mental effort from the programmer by keeping a program in a consistent style - the writer doesn't have to fuss about indentation and the reader can load the program into their mental approximation without being distracted by a format different from the one they use. it serves the same purpose as typesetting rules at a scientific journal. the formatter has to be universally applied. it must be consistent and disrespect programmer intentions to be valuable, but its style must be smart enough to not cause anger.
1. autoformatters can also catch errors themselves, usually by papering over language-level problems. goto fail, while indicative of a half-dozen problems with the c language (unreachable code is legal, if statements don't require braces, goto in general, rampant mutability, error codes), would have nevertheless been caught by a human reviewer if the code was autoformatted.
syntax highlighting instantly catches syntax-level errors without requiring a full compiler pass or linter run. it's the fastest feedback we have available - misspelled a keyword? it's the wrong colour, your brain knows something's wrong before you can consciously respond to it. i consider consciousness a slow and error-prone^[1] method of cognition, and short-circuiting it lets you write better code faster.

this requires some explanation. when you're doing your best work, you "lose yourself" in it. no one considers a self-conscious or self-aware coding style any good. our consciousness lies, makes up narratives, and generally runs interference. of course, preconscious cognition is much less sophisticated, and so conscious composition is indispensable. for a longer-form meditation on consciousness as a liability, try reading blindsight ↩

software engineers don't exist

2025-11-14T21:10:00-08:00

my employer calls me a software engineer. i disagree.

i think software engineering is a misnomer, not because what we do is materially different from what engineers do, but because we lack the professional and legal institutions engineers have. when a software developer can refuse to write unsafe code, whistleblow to an oversight agency, and be free from fear of retribution, then they can call themselves an engineer. when the legally enshrined organization pairs new grads with experienced mentors, with whom they must work for multiple years before they receive a government-recognized certification, then we can call what we do engineering. when we base technical decisions on scientific data instead of vibes and shoddy undergraduate studies. when our field reads and understands our own history instead of chasing vc whims and riding bubbles.

i spent a couple years in an engineering program at university. i have no misconceptions that "real" engineers are any more ethical than software developers. in my first year, we received a lecture on engineering ethics from a man who worked on weapons programs for the u.s. department of "defense", which disillusioned me from the entire discipline. but i still believe a better world is possible, and until software stops killing people we need to move slow and correct things.

update 2025-11-18: i recently encountered this article from the acm, whose area is rather relevant to the subject at hand. recommended reading

update 2026-01-19: found another recommended post!

update 2026-01-19: i also like rain's take; just because we aren't engineers doesn't mean we shouldn't act like them, and our obsession with building our own tools should be cherished

catalogue of personal computation

2025-11-14T20:41:00-08:00

my desktop is a decommissioned compute server that my old employer was giving away after they got acquired and the new parent pushed everything into aws. it has a 48-core threadripper and 256gb of ram, 128 of which is in a drawer of my desk because it makes my overclock unstable. it's wildly overkill 95% of the time, underpowered 10% of the time (single-core performance was never threadripper's strong suit, and the state of the art has gotten a lot better since zen 2), and very appreciated 5% of the time: i was repeatedly recompiling ffmpeg the other day and task manager claimed i hit 101% cpu usage. it runs windows because elden ring holds me hostage; all my development is done in a wsl2 vm running either nixos or arch. i think nixos solves more or less all linux problems and replaces them with nixos problems, which is a mixed blessing. i use lix instead of cppnix for ideological reasons.

i have a pair of b&w passive bookshelf speakers and a b&w active subwoofer, which i power with a fosi audio v3 amp. i recommend all of these very highly; i listen to a lot of music on them. i plan to get a dac, headphone amp, maybe microphone setup someday.

my home server is composed of extremely sketchy hardware, notwithstanding the redundant zfs storage pool. the side panel won't go back on ever since i swapped the motherboard for one with a hyper 212 evo, which is too tall for the micro-atx case. the power button hasn't worked for 5 years; i use a screwdriver to bridge the pins on the motherboard. two of the four hard drives are failing, which is why i have the other two. the psu fan failed in 2025, so i cannibalized my old gaming pc for its evga (rip) psu and swapped it in. honestly i'm impressed that the 400w psu cooler master included with its bottom-of-the-line case in 2018 lasted 7 years without lighting on fire. the server's main purpose is to run the unifi controller, which i manage with a bizarrely bulletproof bash script, and act as an smb server. i haven't had any issues with the software in years. i ran freenas as a kid but got annoyed with freebsd software availability, then i ran truenas scale but got annoyed by the unfinished betaness of it all, so i gave up on semicustom distributions and installed ubuntu server lts.

my personal laptop is a lenovo yoga i got in 2019 when i was starting my degree, for which it was perfect. it has a touch screen, stylus, and 360 degree hinge with an i7 and 8gb of ram. power use while sleeping is abysmal, performance is terrible when using modern software, 8gb of ram is no longer enough. it can still run wsl2 with arch and a text editor, so i try to use it mostly for that. the speakers and fingerprint reader do not work in linux. the drivers are not open source and no one has managed to reverse engineer them, otherwise i would have put arch on it years ago. eventually, i see myself getting a macbook air.

my work laptop is a macbook pro 16" with an m3 pro and 36gb of ram. battery life and performance are very good, though i think my desktop can still beat it in a multicore drag race.

i have a raspberry pi collecting dust in the closet. i used to have an arm vm on oracle's free plan. it ran a minecraft server for a while, then the backend for a web toy i made, and nothing since they closed it for inactivity in 2024.

blogpost about static site generation

2025-11-14T19:40:00-08:00

as is tradition, now that i've stripped my old website to the bones, my first post must be about the technology that made the new website. if i am to follow in my priors' footsteps, this will also be the last post on this blog. i endeavour to not.

both this site and my old site use the zola static site generator. my old site was laden with plenty of custom css, unpopular ideas about fonts, and altogether too much self-importance. this current site uses the stock terminimal theme with no adjustments, so hopefully i can actually write posts instead of screwing around with css. ~~at least i've kept the theme colour~~ nope, green looks better.

aside

i originally used pure CMYK magenta, on the hubristic idea that one day my resume would be printed on a colour printer. i don't think that has ever happened, and it's weird for a computer professional to have a dead-trees-focused resume. it also was (is) too bombastic. after i'm happy with this site, i'll rewrite my resume in typst with a basic theme. it'll be linked here, eventually.

aside aside

i lightly wish terminimal had asides. i'm not convinced they work on mobile, at all - it requires a certain width of reading area that mobile lacks completely. still, they work in a similar way to my brain. this is a nested aside, not that it renders that way. i'm polyfilling with details tags. i wonder how i expect a doubly-nested aside to work

zola's pretty good, if a little obtuse with its sections-and-pages systematization. it could use better error messages, but it really didn't take too long to refamiliarize myself with after not touching it for years, and now it's mostly staying out of my way. i like the terminimal theme, partially from association with other blogs i respect. i appreciate the lack of javascript.