cb341.dev

Shape of Logic

Sun, 06 Sep 2026 00:00:00 +0200

an 8-bit operator takes two bytes and returns one. its truth table has rows, which is few enough to put every one of them on screen at the same time.

multiplication, every input pair at once. open in the viewer

The idea

put on the x axis, on the y axis, and colour the pixel at by the result of . the origin sits bottom-left, so grows rightwards and upwards.

that image is the operator's whole truth table over that domain.

the colour is per-bit rather than a value ramp. each of the 8 result bits owns a hue and a pixel mixes the hues of the bits that are set, so two numerically close values can look nothing alike.

Starting in ASCII: 4-bit division

the first version printed characters. this is integer division, , at 4 bits, set bits as @ and clear bits blank. runs across, runs up, same as every image here.

    A 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
  B
 1111                                                                               @
 1110                                                                          @    @
 1101                                                                     @    @    @
 1100                                                                @    @    @    @
 1011                                                           @    @    @    @    @
 1010                                                      @    @    @    @    @    @
 1001                                                 @    @    @    @    @    @    @
 1000                                            @    @    @    @    @    @    @    @
 0111                                       @    @    @    @    @    @    @   @    @
 0110                                  @    @    @    @    @    @   @    @    @    @
 0101                             @    @    @    @    @   @    @    @    @    @    @@
 0100                        @    @    @    @   @    @    @    @    @@   @@   @@   @@
 0011                   @    @    @   @    @    @    @@   @@   @@  @    @    @    @ @
 0010              @    @   @    @    @@   @@  @    @    @ @  @ @  @@   @@   @@@  @@@
 0001         @   @    @@  @    @ @  @@   @@@ @    @  @ @ @  @ @@ @@   @@ @ @@@  @@@@
 0000

blanking the zeros is what makes the shape appear. the empty upper-left region and the staircase along the diagonal are both already here.

at 4 bits this fits on a screen. at 8 bits it is 256 rows of 256 columns and the terminal stops being the right tool.

Bitwise operators tile

NAND, monochrome. open in the viewer

the picture is made of nested copies of itself. a quadrant repeats the whole, and inside it the same block repeats again, down to single pixels.

each bit position is evaluated independently of the others. result bit is a function of and alone, so the four quadrants share the same 7-bit pattern in their low bits, and each of those splits the same way again, down to single pixels. only the top bit distinguishes one quadrant from another.

for all 65,536 pairs, the low nibble of depends only on the low nibbles of and . the self-similarity goes as deep as the bit count allows.

Addition tiles diagonally

addition at 8 bits, MSB invert. blocks become bands. open in the viewer

carry. bit of depends on every bit below , so the bits are no longer independent and the nested blocks go with them.

addition still passes the nibble test, for the record. the low nibble of a sum is fixed by the low nibbles of the inputs, because a carry only ever moves upward. what breaks is the stricter property NAND has, where bit needs nothing but bit .

the repetition does not stop, it changes direction. is constant along an anti-diagonal, so the pattern is bands instead of blocks. slide the image one step right and one step down and it lands on itself exactly.

the difference is what kind of repetition you get. NAND repeats by scale, the same block nested at every size. addition repeats by translation, one motif shifted along a diagonal. carry is what turns one into the other.

the palette here inverts every colour when the leading bit is set, so the cool bands are the results a signed reading calls negative and the warm ones positive.

the bands alternate, and crossing an edge flips the sign. two positive numbers add to a negative one, two negatives add to a positive. that is signed overflow, and it covers a quarter of the grid, the same 25% at 8 bits and at 16.

Overflow has a shape

there are 256 bands, one per result value, and each holds exactly 256 of the 65,536 pixels.

a band is every pair that sums to the same byte. the bands partition the grid, and that partition is addition mod 256 drawn to scale.

take . the true sum is . the byte is .

that wrap is where the colour restarts. there are 255 wrap transitions, one in every nonzero row, and together they line up into the diagonal seam running across the image.

i had thought of overflow as something that happens at the end of the range, once, when you run out of room. it is a seam through the middle of the table, and every row crosses it.

The seam that isn't there

if two's complement were a property of the data, there would be a visible seam at 128 where numbers go negative.

there is none. across all 65,536 pairs the result bits of signed and unsigned addition are identical everywhere. the same holds for subtraction and for multiplication.

you can make a seam appear by picking the MSB-invert palette, which flips the colour when the leading bit is set. that seam is in the palette.

Is it the palette or the data

a colour map can invent structure that the data does not have. the MSB seam above is exactly that, a boundary that exists because the palette draws one.

it cuts the other way too. nibble RGB puts 256 result values onto 121 colours, and that loss is what makes the spirals in multiplication visible at all. vibrant gives every value a distinct colour and buries the shape in detail.

so the palette decides which scale you can see. what it cannot do is put structure into data that has none. the tiling in NAND and the bands in ADD show up under all four palettes, monochrome included, and i checked both by brute force over all pairs instead of trusting the picture.

every operator in all four palettes is one page if you want to compare them yourself.

Shifts, and three wires

left shift, vertical striping with period 8. open in the viewer

the shift count is masked to b & 7, so and shift by the same amount. the whole image repeats every 8 columns of , verified across all pairs.

this is the one place where the picture hands you a circuit.

a shift distance in an 8-bit word runs 0 to 7, which needs 3 bits. the shifter takes the low 3 bits of and ignores the other 5. it is 3 stages of 2-to-1 multiplexers, shifting by 1, by 2, by 4, each stage on or off. any distance from 0 to 7 is a sum of those three, the binary expansion of the shift count.

the period of 8 in the image is those 3 wires. at 16 bits it becomes 4 stages and a period of 16.

Multiplication

back to the opening image. multiplication is the busiest operator here, and every part of that texture has a cause.

powers of two are clean lines. multiplying by is a shift, so those rows and columns look like the shift image.
zero cells are sparse, 1,280 of 65,536, about 2%. these are the pairs whose product is divisible by 256.
a quarter of all results are odd, since a product is odd only when both operands are odd. this one is real but invisible, because the palette gives the lowest bit the same weight everywhere and nothing in the picture separates odd from even.

underneath all of it is one rule. bit of depends only on the low bits of both operands. carry moves information upward and never downward, so the low bits of a product never learn about the high bits of its inputs.

the layout follows from that. the low nibble of the product is fixed by the low nibbles of the inputs alone, which draws the 16x16 grid of cells repeating their fine detail. the high bits depend on everything, so they vary slowly and paint the 4x4 arrangement of large squares on top. the nibble grid you can see is that split between fast and slow bits.

the curves inside each cell are the pairs that share a product. the wrap at 256 cuts them into the nested rings that read as fish scales.

they are wide near the origin, where products grow slowly, and tighten as the numbers get bigger. in the corners they are too fine to draw and blur into the tapering, and where sets of them cross at different spacings you get the vortices.

the same operator in nibble RGB makes that easier to see.

multiplication, nibble RGB. open in the viewer

four spirals, one per corner, with a cross through the middle where the arcs run out of room to curve.

the difference is the palette. at 8 bits nibble RGB has no green, so the low nibble drives red and the high nibble drives blue, and each channel adds up the bits that are set. different results land on the same colour, 121 of them for 256 values. vibrant gives every value its own. the merging drops the fine arc-to-arc detail and leaves the slow structure, which is why the spirals come out of the noise.

neither picture is more correct. vibrant resolves individual results and buries the shape in texture, nibble RGB blurs results and shows the shape. the operator is the same in both.

Division

division, mostly empty. open in the viewer

the same shape as the ASCII table, at 64 times the resolution.

most of the image is empty. the upper-left region is all zero, because that is where , and truncating integer division sends every one of those pairs to 0.

the bright diagonal edge is the region, and it widens as the numbers grow. the count of divisors giving a quotient of exactly 1 is : for there are 4, for there are 32, for there are 128. the tolerance for "these two are basically the same size" scales with magnitude.

all the interesting variation is crammed into small values near the axes, where the quotient changes fast.

plenty of these operators are many-to-one, AND and the shifts included, so losing information is not what makes division unusual. what is unusual is how much of the table is constant, and how far the quotient reaches for its inputs. the bitwise operators answer bit by bit.

What I found instead

this started in turing complete 2.0, building a new ALU during the campaign rework.

i wanted to write it up in late july. the time only showed up now, which meant coming back to the images cold and checking the claims instead of trusting what i remembered seeing.

the ALU had one-cycle addition, subtraction, and multiplication. i wanted division on the same terms, a dedicated circuit that answers in one pass instead of a loop that shifts and subtracts once per bit. the usual restoring divider costs a cycle per output bit, which for 16 bits is 16 cycles against multiplication's one.

those first three i could reason my way to. division i could not, and it did not become obvious no matter how long i stared at the spec, so i went looking for a pattern in the bits instead. if the truth table had visible structure, maybe the structure was a circuit.

i did not get a circuit out of it. what i got is a clearer sense of why division resists what the other three accept. NAND separates into 8 independent one-bit problems. addition into a carry chain. shift into 3 multiplexer stages you can read straight off the image. division has no such decomposition on show, and its picture is the one that does not break into parts.

that is not a proof that a fast divider cannot exist. combinational dividers do exist, unrolling the shift-and-subtract loop into hardware and paying in area and propagation depth instead of cycles. the picture says the structure is not separable in the way the others are, and it does not say what the circuit costs.

so the method reaches gates, the shifter proves that much. for division it stops short and i still have to build the thing myself.

How the viewer got built, ASCII to shaders

it started with the ASCII table above, but printed at 8 bits, where it runs 256 rows wide. reading 1s and 0s i saw nothing, and blanking the zeros is what first made the triangle pop.

then images. black and white, one pixel per bit, 1 white and 0 black. neat, not informative.

what changed it was one pixel per byte instead of per bit. that is what makes a 256x256 image cover an entire 8-bit operator, and patterns showed up immediately. grayscale by value helped, and the per-bit palettes came later.

256x256 was fine to generate ahead of time. the ALU is 16-bit though, and precomputing at that width was hopeless well before i worked out how hopeless.

the fix was to stop materialising the image at all. render a viewport, compute only the pixels currently on screen. that pushed the work to a fragment shader evaluating the operator per pixel on the GPU, which is also why panning and zooming feel like an image rather than a render queue.

i used Codex for the viewer implementation, the shader, the viewport, and the tooltip plumbing. the analysis and the claims in this post are mine, and each numeric claim was checked against a brute-force pass over all 65,536 pairs rather than taken from the picture.

the tooltip, reading out one cell.

it shows binary, decimal, signed decimal and hex, with the per-bit colour strips. point at any pixel and you get the arithmetic for that cell, which is how i checked the readings above.

One more, at 16 bits

everything above is 8 bits, a 256x256 image that fits on a page. the viewer also runs at 16, and that is a different kind of object.

a 16-bit operator has input pairs. that is 4,294,967,296 of them, one image 65,536 pixels on a side. the results alone, two bytes each, are 8 GB. this is why nothing is precomputed and the shader draws only what the window covers.

so this is a full 16-bit operation, every input pair defined, and you are looking at a piece of it.

16x16, which one?

Try it

the viewer is live at cb341.dev/logic-visualizer. drag to pan, wheel to zoom, arrow keys change operator, click any pixel for the readout.

everything is in the toolbar.

operator, bit width and palette are dropdowns, Jump takes an , an operator and a and centres that cell, and Download PNG saves the current preset as an image (for 4x4 and 8x8, that is).

cb341.dev/logic-visualizer/table shows an overview: every operator at 8 bits, in all four palettes, side by side.

the operators, in order:

operation
`NAND`	not (A and B)
`AND`	A and B
`NOR`	not (A or B)
`OR`	A or B
`XOR`	A xor B
`ADD`	addition, signed and unsigned yield same result
`MUL`	multiplication, low bits
`DIV`	truncating division, B of 0 gives 0
`LSHFT`	A shifted left by the low bits of B
`RSHFT`	A shifted right by the low bits of B
`CMP`	equal, less, greater as three bits

the palettes:

value	palette	what it does
`0`	Vibrant	each bit gets a saturated hue, mixed per pixel
`1`	Monochrome	grayscale ramp, no hue information
`2`	MSB Invert	vibrant, but colours flip when the leading bit is set
`3`	Nibble RGB	high and low nibble map to separate parts of the spectrum

image is the bit width and accepts only 4, 8, or 16.

What's left

i still owe the divider circuit. sequential logic, and more patience than pattern-matching asked for.

what the pictures gave me is that an operator has a shape specific to what it does, and some of the hardware is readable from it. carry breaks the tiles. the shifter is 3 stages of multiplexers. the byte wraps 255 times and each wrap is a line you can point at.

next is building the divider in the emulator.

Challenge this post (anonymous)

Comparing 6 and 7 from Scratch

Sat, 05 Sep 2026 00:00:00 +0200

paper proofs have no compiler. i went looking for one and found Lean, by way of the Natural Number Game, which builds the naturals from nothing and makes you prove your way back out. ¹ i finished it end of june and wanted to write up what the last level actually took.

no AI was used for the Lean or the maths: the tactic proofs, proof strategy and dependency graph are mine. the statements of le_total and the seven supporting theorems come from the Natural Number Game. so do the definitions of MyNat, + and ≤, which are Apache licensed and were modified. ² AI was used for phrasing, including condensing the English proof, and for review.

The theorem

any two natural numbers compare. one of them is at most the other.

we are proving a little more than comparability of 6 and 7. le_total proves that every pair of natural numbers is comparable, with 6 and 7 as one instance. its name describes the property: le is , and total means that the relation compares any two elements. this is the comparability condition of a total order. here total does not mean that a function is defined for every input, and this theorem alone does not establish the other order laws.

take 6 and 7. then is , so .
take 1 twice. then is , so .

checking pairs by hand settles those two pairs. is infinite, so no amount of checking gets through it, and the has to be discharged some other way.

right now , and are all undefined, so that line is only notation. the sections below define each one before proving the theorem.

What the proof rests on

the graph is the table of contents and a dependency map for this development.

lavender nodes are the definitions: itself, the two axioms for addition, and . mint nodes are the arithmetic that follows, including commutativity and associativity. peach nodes are the order results, ending in the theorem.

side note: add_comm is in the file and in the graph, but le_total does not depend on it. every other theorem shown has a path to le_total.

Notation

three symbols appear in the proof.

is disjunction. holds when at least one side holds.

is existential quantification. holds when at least one has . to prove it you produce such a , called the witness.

is universal quantification. holds when every has . to prove it you take an arbitrary and derive without using anything specific about it.

the rest of propositional logic is assumed. ³ a refresher, if you want one:

refresher: ∧, ¬, →, ↔, ⊤, ⊥, contrapositive, De Morgan

each connective is fixed by its truth table.

the two rows of where is false both come out true, which is worth its own article.

is . the def over the used below says that the equivalence defines ; it is still the same logical connective.

is the statement that always holds, the statement that never does.

the converse of is , a different statement. the contrapositive is , the same statement:

the standard equivalences are the De Morgan, commutative, associative, idempotent, distributive and absorption laws, plus double negation. the two De Morgan laws:

Definitions

Natural numbers

lists the first few naturals and assumes we know how the list continues. we still need a definition.

what we need instead is an inductive definition: a finite set of rules that generate every natural and nothing else. two rules suffice. ⁴

zero is a natural. the successor of a natural is a natural. every natural is reached by applying the second rule to the first some finite number of times, and nothing else is in . therefore every has one of two forms:

Lean's inductive definition also gives us induction. to prove something about every natural, prove it for and prove that having it forces to have it. that is the induction tactic used later.

the Lean artefact names this inductive type MyNat; i write in the prose.

there are other constructions of the naturals. ⁵

four other ways to define ℕ

von Neumann ordinals. each number is the set of all smaller numbers.

becomes , so order comes for free. this is the standard construction in set theory. ⁶

Zermelo ordinals. each number is the singleton of the previous one.

simpler to write, but is no longer , so order has to be defined separately. ⁷

Church numerals. a number is a function that applies another function that many times. is , so is . addition can be defined by : apply times, then more times. this is how the naturals appear in untyped lambda calculus. ⁸

Peano axioms as first-order theory. rather than constructing the naturals, state the properties they must have: is not a successor, is injective, and the induction schema is included. this leaves the objects unspecified and constrains them instead. ⁹

i am using zero and succ, which is what the Natural Number Game uses and what Lean's own Nat is.

Constructor zero and numeral zero

the definition above introduces the constructor MyNat.zero. Lean's numeral 0 elaborates to the same natural number. the two expressions are not syntactically identical, but Lean reduces them to the same term, so they are definitionally equal.

for the mathematics in this article, treat MyNat.zero and 0 as the same thing. zero_eq_0 only handles Lean's bookkeeping: after a case split produces the constructor name, the lemma gives rewrite an explicit equation using the numeral.

succ n = n + 1 is different: it is not definitional here. succ_eq_add_one proves it from the two addition axioms.

Addition

gives one sum. has infinitely many, so we need rules for all pairs. in the artefact, add is opaque and constrained by two axioms. both reduce the second argument:

these are axioms in the Lean file, not definitional reductions: add is opaque, so it cannot be unfolded to prove them.

worked on . the reason column names the rule and how it is used. means forwards, as written; means reversed.

rules ii and iii appear in both directions: first to expand the numerals, then reversed to recover them.

Less than or equal

there is a gap, and the gap is itself a natural number. cannot be negative because its type is .

there are two cases. in (I), the gap is and . in (II), the gap is a successor and is strictly below .

the proof later makes the same distinction. once it has a gap c, cases c separates zero from successor.

this is the definition the Natural Number Game uses. Lean's own Nat.le is an inductive type instead, built from reflexivity and a successor step: ¹⁰

protected inductive Nat.le (n : Nat) : Nat → Prop
  | refl     : Nat.le n n
  | step {m} : Nat.le n m → Nat.le n (succ m)

both say the same thing about the same numbers. the existential version hands you a gap to compute with, the inductive version hands you a chain of steps to recurse on. code pasted from here into a mathlib project will not typecheck unchanged.

The tactics

a Lean proof is written as a list of tactics. the ones in this article:

tactic	what it does
`induction`	splits a natural into the zero case and the successor case, and hands you the induction hypothesis
`cases`	splits a value or hypothesis by its constructors; here those are zero/successor or `inl`/`inr`
`cases'`	Mathlib tactic used here to unpack an existential hypothesis into a witness and an equation
`left` / `right`	picks which side of a disjunction goal to prove
`use`	supplies a witness for an existential goal
`rewrite[h]`	uses `h` forwards, as written
`rewrite[← h]`	uses `h` in reverse
`rfl`	closes an equality when both sides are definitionally equal
`exact`	closes a goal with something already proved

rw is the usual short form of rewrite, though the artefact spells it out everywhere. zero_eq_0 and succ_eq_add_one are names from this NNG-style development; cases' comes from Mathlib.

The smaller lemmas

before the theorem, a smaller one: for every natural . it sits in the dependency graph as zero_le, and the theorem's base case consumes it.

unfolding the definition, means . take . the goal becomes ; rewriting the right side with zero_add leaves . in Lean that is three lines.

theorem zero_le (x : ℕ) : 0 ≤ x := by
  use x
  rewrite[zero_add]
  rfl

the zero_add it leans on is where the work actually happens, and that one goes by induction:

zero_add, by induction on n

theorem zero_add (n : ℕ) : 0 + n = n := by
  induction n with
  | zero =>
    rewrite[zero_eq_0]
    rewrite[add_zero]
    rfl
  | succ d hd =>
    rewrite[add_succ]
    rewrite[hd]
    rfl

the two axioms describe addition through its second argument. a + 0 = a is available directly as add_zero, while 0 + n = n has to be derived as zero_add. the two look symmetric and only one is assumed. this asymmetry is why succ_add and add_assoc need their own inductive proofs.

one theorem often admits several proofs, each a different path through the dependency graph. Ording's 99 Variations on a Proof gives 99 proofs that one cubic equation has two real roots. ¹¹

two small results are short enough to show in full.

succ_eq_add_one and le_succ_self

succ_eq_add_one connects the constructor to the numeral, the split from earlier:

theorem succ_eq_add_one n : succ n = n + 1 := by
  rewrite[one_eq_succ_zero]
  rewrite[add_succ]
  rewrite[add_zero]
  rfl

le_succ_self says every number is below its own successor. the gap is one, and once the witness is supplied the goal is exactly the previous theorem:

theorem le_succ_self (x : ℕ) : x ≤ succ x := by
  use 1
  exact succ_eq_add_one x

two arithmetic theorems remain on the path to le_total:

Tactics as state transitions

a Lean proof has a state: the hypotheses you have, and the goal you owe. a tactic changes that state. the proof is the sequence of changes.

the tables below are static copies of Lean's goal window.

the Lean documentation puts it this way: ¹²

A proof term is a representation of a mathematical proof; tactics are commands, or instructions, that describe how to build such a proof.

written as two columns, with zero_le as the example:

Givens	Goal
`x : ℕ`	`0 ≤ x`

use x needs an existential goal. Lean therefore unfolds the reducible LE instance and MyNat.le until it sees the definition below. this happens automatically; there is no separate unfold tactic in the proof.

Givens	Goal
`x : ℕ`	`∃ c, x = 0 + c`

after use x:

Givens	Goal
`x : ℕ`	`x = 0 + x`

after rewrite[zero_add]:

Givens	Goal
`x : ℕ`	`x = x`

after rfl, no goals remain.

in this example the left column only grows and the right column only shrinks. that is not a law of Lean proofs in general, since induction and cases replace one goal with several and a rewrite can make a goal larger before it gets smaller. what does hold everywhere is the stopping condition: the proof is finished when no goals remain, which the machine decides rather than the author.

some tactics split the state in two instead of changing it. those are the ones that make a proof branch.

the branching tactics, as before and after states

induction on y replaces one state with two, and hands the second an induction hypothesis:

Givens	Goal
`x : ℕ`	`x ≤ 0 ∨ 0 ≤ x`

Givens	Goal
`x d : ℕ`, `hd : x ≤ d ∨ d ≤ x`	`x ≤ succ d ∨ succ d ≤ x`

cases hd on a disjunction hypothesis, again two states, one per disjunct:

Givens	Goal
`hl : x ≤ d`	`x ≤ succ d ∨ succ d ≤ x`

Givens	Goal
`hr : d ≤ x`	`x ≤ succ d ∨ succ d ≤ x`

cases' hr with c hc on an existential hypothesis, which names the witness and keeps one state:

Givens	Goal
`c : ℕ`, `hc : x = d + c`	`x ≤ succ d ∨ succ d ≤ x`

and right, which chooses the second constructor of Or:

Givens	Goal
`c : ℕ`, `hc : x = d + c`	`succ d ≤ x`

left and right choose which constructor of Or to build. use w supplies w as the witness for an existential. a bad choice can leave a goal that cannot be proved, even when another branch or witness would have worked. rewriting is different: it replaces equals by equals without choosing a branch or witness.

Tests and proofs

a programmer might test a boolean version on a few examples. this is pseudocode: comparable returns a boolean, while Lean's le_total produces a proof.

assert comparable(6, 7)
assert comparable(1, 1)
assert comparable(0, 255)

green suite, three pairs, out of infinitely many. testing more pairs still settles only the pairs tested. the Lean proof keeps x and y arbitrary.

the parts that do correspond:

Testing	Lean
test suite	theorem statement
running the suite	type-checking the proof
green	no goals remaining
a failing assert	a goal that will not close
coverage	no counterpart

coverage has no counterpart because a proof holds for the whole domain or it is not a proof.

where the analogy does hold is the feedback loop. tests are worth writing because the machine answers immediately and without sympathy, and the goal window gives that same answer after every step. on paper, "clearly" is a sentence a person can write and nothing checks it. Lean's equivalent is sorry, which compiles but marks the file with a warning you have to look at.

that makes sorry the counterpart of a stubbed test: it lets you write the shape of a proof first and fill in the parts one at a time, with the compiler tracking what is still owed.

The last step

what follows is the final theorem, the bottom node of the dependency graph. it uses the definition of , the two addition axioms, the definition of , and six earlier theorems. the last command checks the concrete pair from the title.

theorem le_total (x y : ℕ) : x ≤ y ∨ y ≤ x := by
  induction y with
  | zero =>
    right
    exact zero_le x
  | succ d hd =>
    cases hd with
    | inl hl =>
      cases' hl with c hc
      rewrite[hc]
      left
      rewrite[succ_eq_add_one]
      use c + 1
      rewrite[← add_assoc]
      rfl
    | inr hr =>
      cases' hr with c hc
      cases c with
      | zero =>
        rewrite[zero_eq_0] at hc
        rewrite[add_zero d] at hc
        left
        rewrite[hc]
        exact le_succ_self d
      | succ a =>
        rewrite[add_succ] at hc
        right
        rewrite[hc]
        use a
        rewrite[succ_add]
        rfl

#check le_total 6 7
-- le_total 6 7 : 6 ≤ 7 ∨ 7 ≤ 6

open the whole development in the Lean web editor. clicking a line shows its hypotheses and goal.

the indentation records the nesting, but the code still reads as one vertical sequence. the proof state branches: induction y creates two obligations, then cases hd and cases c split them again.

the diagram puts that shape on the page and shows where each branch closes.

every node in the graphviz diagram is one of the two-column states from earlier, and every edge is a tactic. three things it shows that the linear listing hides.

the labelled frames are where the state splits. induction y opens the succ d frame, cases hd opens inl and inr inside it, and cases c splits again inside inr. each frame starts at its own filled dot, so the nesting on the page is the nesting of the proof.

left and right choose a constructor of Or. the top right branch goes from x ≤ 0 ∨ 0 ≤ x to 0 ≤ x under right. inside the frames, each …∨… goal becomes a single inequality after left or right.

four goals get closed, one per leaf, and this proof uses two tactics to do it. rfl closes the two that end in an equation whose sides are the same term, (x+c)+1 = (x+c)+1 and succ(d+a) = succ(d+a), both rewritten until the two halves are literally identical. exact closes the other two by naming a result proved earlier, zero_le x on the far right and le_succ_self d in the middle. every rewrite above them exists to reach one of those two endings. the remaining circles lower down are merge points where the branches rejoin.

In English

the same development in textbook-style prose, inspired by the proofs in Velleman and Axler. the Lean above and the proof below are the same argument.

the whole thing, in prose

Definitions.

two rules describe . zero is a natural number, and the successor of a natural number is a natural number. nothing else is a natural number. from this follows the induction principle: a property that holds of , and holds of whenever it holds of , holds of every natural number.

from here on the universe of discourse is .

each numeral abbreviates iterated successors: , , , through to .

Axioms.

Arithmetic axioms. the opaque addition function satisfies two equations.

Inequality. when some natural number satisfies , with being the gap. the definition is an equivalence, so a gap proves an inequality and an inequality yields a gap.

Lemmas.

Lemma (succ_eq_add_one). .

Proof. by the numeral definitions , so is , which the successor equation rewrites as , and the zero equation reduces to .

Lemma (zero_add). .

Proof. by induction on .

Base case: . the claim is , the zero equation.
Inductive step: let be arbitrary and take . inductive hypothesis: . the successor equation gives , and the hypothesis rewrites the inner sum as .

Lemma (succ_add). .

Proof. let be arbitrary and fixed. by induction on .

Base case: . both sides reduce to by the zero equation.
Inductive step: let be arbitrary and take . inductive hypothesis: . the left side becomes , then by the hypothesis. the right side becomes the same, by the successor equation under the outer successor.

Lemma (add_assoc). .

Proof. let and be arbitrary and fixed. by induction on the middle summand , which occurs under a successor on both sides.

Base case: . both sides equal , by the zero equation and by zero_add.
Inductive step: let be arbitrary and take . inductive hypothesis: . the left side becomes , the right side , and the hypothesis equates the inner sums.

Lemma (zero_le). .

Proof. the gap is , since by zero_add.

Lemma (le_succ_self). .

Proof. the gap is one, since by succ_eq_add_one.

The theorem.

Theorem (le_total). for all and , either or .

Proof. let be arbitrary and fixed. by induction on .

Base case: . the right half holds, since by zero_le.
Inductive step: let be arbitrary and take . inductive hypothesis: or . goal: or . the hypothesis is a disjunction, and the labels name which half is assumed.
- Case 1 (left): . the gap satisfies . then by succ_eq_add_one and add_assoc, so is a gap and .
- Case 2 (right): . the gap satisfies , and is zero or a successor. this is (I) against (II) from the number line.
  - Case 2a (gap zero): . then by the zero equation, and by le_succ_self, so .
  - Case 2b (gap a successor): . then by the successor equation, which is by succ_add, so is a gap and .

each case establishes one half of the goal, so the goal holds at . both cases of the induction are now proved, and by the induction principle the statement holds for every .

From code to paper

there are two parts to this for me. the first is the mathematics itself. i have only just started learning how to prove theorems, and i am still unsure why this beautiful part of mathematics has stayed so far out of sight during my time at ZHAW. definitions are beautiful because they are precise. they say exactly what the objects and relations mean, and the proof shows what follows from them. working through le_total was an exercise in that precision.

the second is the transition from computer science into proof-based maths. i suspect many mathematicians learning Lean move in the opposite direction, from paper proofs into a proof assistant. Lean felt approachable to me because it is also a functional programming language. i can work in Neovim with the Lean plugin, inspect the proof state, and start with mathlib documentation when i get stuck. Lean materialises the proof as something i can run and get a checkmark for.

the structure and state keeping are training for paper proofs, where there is no compiler or proof checker. next is linear algebra at the FernUniversität in Hagen, alongside part-time studies at ZHAW. it is my first course where proofs are the work rather than a step inside it. i am eager to see how much transfers.

reading Peano also made me wish i had learned Latin. some of the historical material would be much more approachable.

Notes

Natural Number Game 4, by Kevin Buzzard and Mohammad Pedramfar: https://adam.math.hhu.de/#/g/leanprover-community/nng4 ↩
https://github.com/leanprover-community/NNG4. the artefact carries the same attribution in its header. ↩
Daniel J. Velleman, How To Prove It: A Structured Approach, 3rd edition, Cambridge University Press, 2019, sections 1.1 and 1.2. Maurer's ETH script covers the same ground from the truth-table side in chapter 2: https://crypto.ethz.ch/teaching/DM23/ln/DM23_LNss-tablet.pdf ↩
Giuseppe Peano, Arithmetices principia, nova methodo exposita, 1889. The Latin original is on archive.org: https://archive.org/details/arithmeticespri00peangoog/page/n10/mode/2up ↩
https://www.researchgate.net/publication/228574851_von_Neumann_universe_A_perspective ↩
John von Neumann, Zur Einführung der transfiniten Zahlen, Acta Litt. Acad. Sc. Szeged 1 (1923), 199–208. Standard modern treatment in Kunen, Set Theory, chapter I. ↩
Ernst Zermelo, Untersuchungen über die Grundlagen der Mengenlehre I, Mathematische Annalen 65 (1908), 261–281. ↩
Alonzo Church, An Unsolvable Problem of Elementary Number Theory, American Journal of Mathematics 58 (1936), 345–363. Barendregt, The Lambda Calculus, section 6.4 gives the arithmetic. ↩
The first-order theory is usually attributed to Peano 1889 by way of Dedekind. Hájek and Pudlák, Metamathematics of First-Order Arithmetic (1998), chapter I, is the reference treatment. First-order induction is an axiom schema, with one instance per formula, and the theory has nonstandard models. the inductive type here has only the constructors stated above. ↩
Lean 4 API documentation for Init.Prelude, entry Nat.le: https://lean-lang.org/doc/api/Init/Prelude.html#Nat.le. mathlib inherits this definition rather than replacing it. ↩
Philip Ording, 99 Variations on a Proof, Princeton University Press, 2019. ↩
https://lean-lang.org/theorem_proving_in_lean4/Tactics/ ↩

Challenge this post (anonymous)

System Prompts For Humans

Wed, 27 May 2026 00:00:00 +0200

I have recently been thinking a lot about human to LLM and human to human communication.

This started earlier in my threads entry from 11.05.2026 with the idea that daily language is mostly filler, greetings burn tokens, and RFC style keywords such as MUST, SHOULD, and MAY could make ordinary communication less ambiguous. RFC 2119 defines these keywords for technical specifications; the interesting part is whether ordinary communication could steal some of that explicitness. This article is a continuation of that thought, but less about rewriting language and more about documenting the interface.

When I talk to an LLM, I often define behavior explicitly:

* US spelling
* professional
* behaves like a tool not like a person or friend
* does not use hyphens
* does not use ß, instead ss
* does not use emojis unless explicitly asked for
* if anything unclear, please ask
* if asked to write german, use swiss high german
* if asked to write german don't forget to use äöü correctly so never use ae instead of ä unless asked to

* be friendly, truthful
* correct me if i am wrong
* do not hallucinate

if i use a term wrong, in any way or shape.
If i misuse a technical word, you have to correct me.

If i make a mistake, you correct me.
If I make a spelling mistake you mention it but don't block.

Respond terse like smart caveman. All technical substance stay. Only fluff die.
Drop: articles, filler, pleasantries, hedging.
Fragments OK.
Short synonyms.
Technical terms exact.
Code blocks unchanged.
Errors quoted exact.

This works surprisingly well.

The model stops guessing. I stop correcting tone. The interaction becomes more efficient because the communication protocol is explicit.

The difference is easiest to see as two message paths. Talking to an LLM has low social overhead: I can send the compressed intent directly. Talking to a human often adds an extra encoding and decoding layer around the same core message.

So why not do the same for people approaching me?

Human communication has hidden state

People bring a personal layer into communication. For better or worse.

Some people expect greetings before requests. Some expect the request immediately. Some soften feedback until it almost disappears. Some read direct feedback as hostile. Some need relationship before task. Some build trust by doing the task.

These are not only personality quirks. They are communication defaults.

I recently skimmed Erin Meyer's The Culture Map.

I have not read the full book yet, so this is not a summary. Many articles already do that better, for example The Three Cs summary and Mike Hebert's bookshelf note.

What interests me is the extracted model: communication can be mapped across dimensions.

Dimension	Scale
Communicating	low context to high context
Evaluating	direct feedback to indirect feedback
Persuading	principles first to applications first
Leading	egalitarian to hierarchical
Deciding	consensual to top down
Trusting	task based to relationship based
Disagreeing	confrontational to avoids confrontation
Scheduling	linear time to flexible time

That is useful because mismatch becomes nameable.

A rude message may simply be low context, direct, task based communication. A vague message may be high context, indirect, relationship preserving communication. A slow decision process may be consensual rather than owner driven. A cold interaction may be task based rather than relationship based.

Naming the axis helps debug the interaction.

My vector

My preferred defaults are roughly:

communication: low context
feedback: direct
persuasion: principles first
leadership: egalitarian
decisions: top down after debate
trust: task based
disagreement: confrontational
scheduling: flexible with explicit constraints

This is not universal truth. It is an interface: a set of defaults that make communication with me easier to parse.

Information

Low context: include the information. Do not make me infer hidden state.

Principles first: give me the rule, invariant, or model before the example.

Feedback and disagreement

Direct feedback: say what is wrong. Do not wrap actual feedback in so much softness that I have to decode it.

Confrontational disagreement: disagreement is useful when it attacks the claim, not the person. I tend to respect people more when they disagree with me rationally. Agreement is cheap. Clear objection with reasoning gives me something to work with.

Egalitarian: challenge ideas regardless of role.

Top down after debate: discuss openly, then owner decides.

Task based trust: reliability matters more than social performance.

Time

Flexible scheduling: exact timing can move, but constraints must be explicit.

Dense mode for humans

Second input is caveman mode, inspired by The Grug Brained Developer and Julius Brussee's caveman skill.

Grug style is something I adore: precise, terse, low ceremony, suspicious of accidental complexity.

The caveman skill turns that style into explicit communication rules for LLMs.

Rule is simple:

All technical substance stays. Only fluff dies.

This is not about sounding primitive. It is about compression, precision, and visible intent.

Drop filler:

just
really
basically
actually
simply
maybe
perhaps
I was wondering if
happy to
hope you are well

Keep substance:

exact words
actual question
relevant context
constraints
sources
ownership
examples
uncertainty labels

Ownership matters. If an idea comes from someone else, name them. If a claim depends on a source, link it. If something is personal preference rather than truth, say so.

Bad:

I was just wondering if maybe you had a moment to talk about something,
because I kind of wanted to ask you something.

Good:

I need feedback on an idea.
Context: communication protocol draft.
Question: does it read too strict?
Useful answer: direct criticism, not reassurance.

Second version is not less polite. It is less ambiguous.

nohello

Same idea for chat. This is also the core point of nohello.

Do not send:

hi

and wait.

Send:

hi, I want your opinion on the communication protocol draft.
Question: does it sound too strict?
Context: I want direct feedback, not reassurance.

Greeting is fine. Greeting only is latency.

Async communication only works when first message contains enough information to answer later.

Direct feedback wanted

I want direct feedback.

Useful shape:

What you see:
What it makes you think:
What you would change:

Example:

What you see: This section sounds defensive.
What it makes you think: The reader may feel accused before understanding the idea.
What you would change: Move the personal motivation later and start with the general protocol concept.

Direct feedback should still be careful: clear about the problem, specific about the reason, and aimed at the work rather than the person.

Sources and ownership

Claims should carry sources. Ideas should carry ownership.

This matters for two reasons.

First, citation reduces verification work. If a claim matters, the reader should not have to reconstruct where it came from.

Second, ownership prevents accidental theft. If I build on nohello, Grug, caveman, RFC 2119, or The Culture Map, I want that lineage visible.

Good source behavior:

link the original idea
name the author when known
separate source from interpretation
mark uncertainty
say when something is only personal preference

Bad source behavior:

pretend synthesis is invention
cite vague memory
hide behind "people say"
treat ChatGPT output as authority

Rule:

claim strength must match source strength
idea lineage should stay visible

TALK_WITH_DANI_SKILL.md

This leads to the artefact I want:

TALK_WITH_DANI_SKILL.md

As documentation for an interface that otherwise stays implicit. The live version is How To Approach Dani.

LLMs get system prompts because we want predictable behavior from an ambiguous interface. Humans are also ambiguous interfaces.

A protocol file for a general person could look like this:

# TALK_WITH_DANI_SKILL.md

Purpose: make communication with Dani less ambiguous.

This is not a demand that every person talks the same way. It is a description of defaults that reduce friction for me.

## Style

Prefer:

* direct language
* short messages
* concrete examples
* explicit context
* visible assumptions
* clear ownership
* cited claims
* rational disagreement

Avoid:

* empty greetings
* filler
* hidden intent
* vague reassurance
* indirect feedback
* social padding that hides the actual message

## First message

Good first message contains:

* actual ask
* context
* why you ask me specifically
* expected answer shape
* deadline, if any

Example:

```text
hi, I want feedback on my draft.
Context: it explains a communication protocol.
Question: does it sound too strict?
Useful answer: direct criticism with examples.
```

## Feedback

I prefer direct feedback.

Good feedback:

* says what you see
* explains why it matters
* gives concrete alternative
* disagrees with claim, not person

Example:

```text
This paragraph sounds defensive.
It may make reader feel accused before understanding idea.
I would move personal motivation later.
```

I tend to respect people more when they disagree with me rationally. Agreement without reasoning gives little signal. Disagreement with reasons gives something useful.

## Fluff

Fluff is any wording that increases decoding work without adding meaning.

Examples:

```text
I was just wondering if maybe...
No worries if not...
This might be totally wrong but...
Happy to quickly...
```

Better:

```text
I think X.
Reason: Y.
Question: Z?
```

## nohello

Greeting is fine. Greeting only is latency.

Bad:

```text
hi
```

Good:

```text
hi, I have a question about X.
Context: Y.
Ask: Z?
```

## Sources and ownership

If you make a factual claim, cite source.

If idea comes from someone else, name source.

If something is personal opinion, say so.

Do not make synthesis look like invention.

## Disagreement

Disagreement is welcome when rational.

Useful disagreement:

```text
I disagree with X.
Reason: Y.
Evidence or example: Z.
Alternative: A.
```

Unhelpful disagreement:

```text
This is bad.
I don't like it.
Feels wrong.
```

## Core rules

Dense does not mean rude. Direct feedback should still be careful, specific, and aimed at the work rather than the person. Rational disagreement is welcome. Sourcing claims is part of taking the conversation seriously.

That is longer than a prompt, but humans need more context than LLMs. The point is not to reduce people to tools. The point is to make style, preference, and citation expectations visible.

That would save guessing.

Less "what did they mean?" More "what is the preferred interface?"

Challenge this post (anonymous)

How the Homebrew Multi-User Rabbit Hole Bricked My Mac

Mon, 27 Apr 2026 00:00:00 +0200

I work part-time at Renuo as a software engineer and study Computer Science part-time at ZHAW. Most weeks mix client codebases, coursework, and personal projects on the same laptop, with the same tools: Neovim with lazygit and delta, iTerm2, Raycast, Setapp, hotkeys, window management. The setup should feel the same regardless of which one I am working on.

I also want clean separation. Slack should not interrupt a study session. Personal email should not show up in client meetings. The git identity loaded should match the project I am in, without me having to think about it.

Why not one user?

The friction was constant but small enough that I lived with it for quite some time now. The Slack icon lit up during ZHAW deadlines. The dock mixed work apps with personal ones. The clipboard remembered things from the wrong context. Mail surfaced three accounts in one inbox, and switching between them was manual.

Switching contexts meant manual cleanup. Killing apps I did not want open at school, opening the ones I did. Same in reverse every evening. A few minutes per transition.

On quiet evenings, the Slack icon was right there in the menu bar. I would open it "to check one thing" and lose half an hour.

The bigger issue was that client projects sat one cd away from personal ones. Same shell history, same git config, same SSH keys loaded. The boundary between client and personal work was mental, not enforced.

I tried Apple's Focus modes first. Focus only hides things.

A second laptop would solve all of this but is overkill, expensive, and twice the hardware to maintain.

Two macOS user accounts handle every point above with no clever software. macOS already isolates them. If I really need to move a file across, I can do it via sudo from ~dani to ~cb341 (or vice versa).

The setup landed at two admin users on one machine:

cb341 (personal): ZHAW, personal projects, iCloud Keychain
dani (work): Renuo projects, Google Drive, Slack, Renuo Google account, Renuo 1Password, NCLT

Each app and account lives on exactly one side. ZHAW modules like Low Level Programming and Communication & Technology run in their own Linux VMs and Docker contexts on the personal side, kept separate from the work user's containers. Mail runs on both, but with different accounts.

This is not full isolation. Both users share the same hardware, the same network, the same macOS install. Anything installed system-wide (Wireshark, kernel extensions, daemons) is visible from both sides. An admin user can sudo into the other's home directory if they really want to. Real isolation would mean separate machines, or at least separate VMs. Two users is not a security boundary. It is a context boundary. Different login, different state, different mental mode. That is enough for the problems I actually have.

The Homebrew rabbit hole

Once I had committed to two users, the next question was how to share Homebrew between them. I love Homebrew. It is not pacman, but for macOS it is the closest thing. Most of the CLIs and many GUI apps I use are one brew install away.

The trouble is that Homebrew is fundamentally designed for one non-root user to own a single install. There are not many ways to bend that, and the three I describe below are not exhaustive. They are the most viable ones I found, and the ones the community keeps recommending. I tried all three before giving up.

Approach 1: shared group permissions

This is the top Stack Overflow answer for any "Homebrew multi-user" search. You will find variants of it in countless gists and Medium posts. Run something like:

sudo chgrp -R admin /opt/homebrew
sudo chmod -R g+w /opt/homebrew

Both users in the admin group can now read and write the Homebrew prefix. In theory. In practice it falls apart immediately.

The root cause is that Homebrew's default umask does not preserve group-write permissions on newly-created files. As soon as one user installs anything, the new files land owned by that user with no group-write bit. The prefix is back to being half-broken for the other user. The symptoms cascade through the layers I rely on: my shell (zsh, the macOS default since Catalina) and the polyglot version manager Renuo uses (mise, like nvm or rvm but for any language).

zsh autocompletion silently stops working because completion files in /opt/homebrew/share/zsh/site-functions are not readable across users. zsh refuses to load them entirely with zsh compinit: insecure directories warnings.
Plugin managers (antigen, oh-my-zsh) fail to update because their cached state lives under the brew prefix or the user's home but references files the other user wrote.
mise has a trust system for .tool-versions and mise.toml files. Files written by one user fail the trust check when the other user reads them. You get prompted to re-trust on every shell.
Ownership drifts fast. I spent two days on this approach. By the end, brew doctor was a wall of warnings, formulae refused to update, and parts of my setup had silently broken. None of it resolved cleanly. The fix is to reinstall the prefix.

The usual workarounds pile up. Re-run the chmod hack after every install. Set a custom umask globally. Or, and this is real (codejam.info calls it out), drop a chmod -R g+w into your ~/.zshrc so the prefix is force-corrected every time you open a terminal. A recursive filesystem operation on every shell launch, just to keep the previous workaround working. At which point you are not really using Homebrew anymore. You are maintaining a wrapper around it.

Approach 2: separate per-user installs

The "clean" alternative is to install Homebrew under each user's home directory. Say, ~/.homebrew. Each user owns their own copy. This sounds reasonable on paper. In practice it breaks. Homebrew's prebuilt bottles are compiled for the default prefix (/opt/homebrew on Apple Silicon, /usr/local on Intel). Install anywhere else and you lose the bottles entirely. Some formulae then fail to build at all. Others compile but link against paths that do not exist on the new prefix, so they break at runtime in unpredictable ways. The official docs say it directly: "Some things may not build when installed elsewhere." That is not a warning to weigh against the benefits. It is a description of what happens.

Approach 3: shared install + sudo

This is what the Homebrew FAQ actually recommends when pressed. It is buried in a section explaining why Homebrew "refuses to work using sudo". It took me longer to find than I would like to admit. Create a dedicated user just for Homebrew (call it brew-admin), install Homebrew under that account, then from your actual user run brew via sudo:

# in ~/.zshrc on each real user
export PATH="/opt/homebrew/bin:/opt/homebrew/sbin:$PATH"
alias brew='sudo -Hu brew-admin brew'

The -H flag points HOME at the impersonated user so Homebrew's cache and state stay consistent. Charles Loder's writeup walks through this for Apple Silicon specifically. It works. It is also where Homebrew's single-user assumption becomes visible. You are now maintaining a third user account whose only job is to own the package manager. Tools that shell out to brew internally (think nvm, version managers, install scripts) do not know about your alias and break.

By the time I had cycled through all three I realized I had been fighting the tool to do something it was not built for. That is when I started looking at MacPorts. Before I got there, I bricked the laptop.

How I bricked it

I cannot prove Homebrew alone caused this. The system had its own accumulated junk before I started: years of half-uninstalled tools, framework drift, the kind of rot every long-lived install collects. But the Homebrew permission mess is what pushed everything past the point of recovery.

Honestly, I cannot reconstruct the exact sequence. I followed guides, tried random fixes, reverted some of them, deleted directories I probably should not have. Homebrew's paths reach further into the system than I realized, and somewhere along the way I took system files with them when I only meant to remove brew. By the time I noticed how bad it was, the damage was past clean repair.

The chain went roughly like this. Permission state on /opt/homebrew got into a configuration neither user could fully repair. The macOS update via System Settings refused to apply. Manual installation of the "Update to macOS Tahoe" .pkg failed too. Xcode CLI tools would not install. Then Xcode itself would not install. Then the App Store stopped loading. I could not erase the disk through the normal recovery flow. Eventually I broke the GNU tools (make, git) badly enough that recovery scripts failed.

For reference, here is what a normal macOS update flow looks like. None of it worked for me. Even the softwareupdate --fetch-full-installer command-line escape hatch failed:

$ softwareupdate --fetch-full-installer --full-installer-version 26.4.1
Scanning for 26.4.1 installer
Install failed with error: Installation failed
Error Domain=PKDownloadError Code=8 "(null)"
  ... NSLocalizedDescription=The request timed out.
  ... https://swcdn.apple.com/.../InstallAssistant.pkg

Time for a clean reset.

Homebrew → MacPorts (reluctantly)

Since I was rebuilding from scratch I revisited the package manager question. To be clear: I would rather have stayed on Homebrew. It is the macOS package manager I actually enjoy using. The formula coverage is unmatched. But the previous three sections are why I could not. Homebrew is fundamentally a single-user tool. No amount of group-permission hacks or sudo aliases makes it not so.

MacPorts has been around longer than Homebrew and predates it as the de facto BSD-style ports system for macOS. ETH has a decent writeup that nudged me to actually try it.

The honest tradeoffs:

MacPorts wins on

Clean Unix permissions. sudo users administer packages, regular users just use them. Multi-user is the default, not an afterthought.
Predictable install locations (/opt/local).

Homebrew wins on

Bigger ecosystem. OrbStack, delta, and a lot of casks I rely on are first-class on Homebrew, less so on MacPorts.
No sudo needed for day-to-day installs. macOS as a platform leans away from sudo for user-space work, partly because System Integrity Protection already blocks writes to /System and /usr regardless of root, and partly because Apple's pattern is "drag to /Applications" rather than "elevate to install". When something does need privileged access, macOS prefers authorization dialogs and entitlements over sudo. Even our Renuo laptop setup guide flags it: "On a Mac, you should seldom be required to use sudo." Homebrew respects that convention. MacPorts does not.

So when does each one win? One disclaimer first: I am only comparing on the multi-user dimension. Formula coverage, build determinism, update frequency, dependency handling, and tap ecosystems all matter for picking a package manager, and other articles cover them well. None of those tipped my decision. The multi-user model did.

Use Homebrew when one human owns the Mac. Bigger ecosystem, less friction, fits the macOS "seldom sudo" norm. Most setups land here. If you are the only person who logs in, there is no reason to pick anything else.

Use MacPorts when multiple humans share the Mac. This is where Homebrew's single-user model breaks down, and no permission hack fixes it cleanly. MacPorts treats installs as a privileged operation, which means all users share the same stack without one of them owning the prefix. You trade ecosystem size for sanity. The "seldom sudo" norm goes out the window, but that norm only worked because Homebrew gave one user write access to a system path. Multi-user breaks the trick. Pretending otherwise is what got me into the mess in the first place.

For my setup, MacPorts was the only sane choice. I still miss brew install --cask orbstack. The smaller cask selection hurts, and I fill the gaps with manual .dmg installs for the few apps that are not there.

The rebuild

There was an upside to the wipe. A long-lived macOS install collects a lot of state: background services from apps I had not opened in months, config files in ~/Library/Application Support for tools I tried once and abandoned, login items from installers without proper uninstall scripts, kernel extensions from drivers I no longer needed. All of it went with the reset. Login is faster, idle CPU is lower, and the menu bar is no longer full of icons from things I do not use.

For the Renuo side I followed our internal laptop setup guide. It gave me a known-good baseline: a Ruby/Rails toolchain via mise, Postgres and Redis as background services, git + git-flow, GPG, the Heroku CLI, and mas for App Store updates from the command line. Before wiping the old install I ran brew bundle dump to spit out a Brewfile of everything I had. That became my checklist for the new machine. The guide is written assuming Homebrew throughout. Every step is a brew install something. On the MacPorts side I mentally translated each line into sudo port install something (or the equivalent), and looked up the small handful of packages where the names differ. brew services start postgresql becomes a launchd plist that MacPorts wires up automatically when you install the postgresql17-server port. Same outcome, slightly different vocabulary.

On top of that baseline, the core stack on both users:

Editor and git: LazyVim on Neovim, lazygit, delta
Terminal: iTerm2 with Caskaydia Cove, Caps Lock remapped to Escape
Window management and launching: Rectangle and Raycast
Setapp tools: Dash, CleanShot, TextSniper, Timing, Paste
Apple defaults kept: Notes, Mail, Messages

Neovim config gets manually synced between the two users. Not ideal, but it is a small price. Everything else is just installed twice.

What made the migration bearable

A few things saved real hours. The Samsung T7 Shield 4TB over Thunderbolt was fast enough that copying selectively onto it and pulling back from it was painless. iTerm2, Raycast, and Timing all support exporting settings to a file (iTerm2 prefs, Raycast settings export). Importing on the fresh install took seconds rather than an evening of clicking through preference panes. My dotfiles repo covered the rest of the editor and terminal experience: Neovim config, lazygit, shell setup, all in one git clone. Running ncdu before backup let me clean out node_modules, Rust target/ directories, and vendor/ folders that did not need to make the trip. Easily 100 GB saved.

For now: the laptop boots, both users have what they need, and I have not bricked anything in days. That counts as a win.

Challenge this post (anonymous)

Compressed Language

Mon, 30 Mar 2026 00:00:00 +0200

I communicate with AI in broken English and it works perfectly. I drop vowels, ignore spelling, skip grammar, and the meaning arrives intact. Why?

"I have made this longer than usual because I have not had time to make it shorter." * Blaise Pascal

Building on "Map-Reducing Myself" * if we compressed 21MB of data into 15 words of identity, what does that say about the language we used for the other 20.99MB?

Thesis

There is a spectrum from natural language to formal notation, and human-AI communication is carving out a new point on it.

Every example in this article is a tradeoff between these four variables. The key constraint: density scales with shared context. Compression only works because both sides share the same context.

Hieroglyphs as framing

Hieroglyphs were logographic: one symbol encoded an entire concept. We decomposed that into alphabets (phonetic atoms), gained universal composability but lost density. Now we are circling back: , , , emojis * reinventing hieroglyphs for specific domains.

hieroglyphs -> alphabets -> formal notation -> emoji/symbols -> compressed protocols

We started with symbols, detoured through words, and the optimal path forward might look more like where we began.

The language of the universe

Math notation as the purest compressed language. Evolved over centuries toward maximum information density.

Math symbols are not faster to write (typing integral, sum, join is awkward) but massively faster to read. A trained eye parses instantly; "the sum of the squares of each element x sub i" requires linear reading. Optimized for output bandwidth, not input.

Upfront learning cost amortized over every future read. Same tradeoff as any compressed protocol.

Linear algebra as extreme case

A single matrix multiplication encodes potentially millions of operations. Two characters, behind them a thousand nested loops. No natural language comes close to that compression ratio. This is not just compression * it is delegation to a shared semantic model. only works because both sides agree on what matrix multiplication means. Compression requires a shared decoding function.

And it is the backbone of the AI we are communicating with. The compressed language (linear algebra) built the system (neural nets) that now lets you use another compressed language (your protocol) to talk to it.

Relational algebra vs SQL

SELECT DISTINCT R.name, R.email FROM R INNER JOIN S ON R.id = S.id;

16 symbols vs 67. The algebra implies distinctness (set-based by definition), so DISTINCT is redundancy the formal notation never needed. SQL trades density for explicitness and practical execution semantics: bag semantics, execution hints, readability for broader audiences. The verbosity is not accidental. But for expressing the pure relational operation, the algebra is unmatched.

Programming languages: Ruby vs Java

names = users.select(&:active?).map(&:name)

List<String> names = users.stream()
    .filter(User::isActive)
    .map(User::getName)
    .collect(Collectors.toList());

Same logic. Java makes you declare List<String>, wrap in .stream(), unwrap with .collect(Collectors.toList()). The type system demands you narrate what Ruby lets the reader infer from context. names already tells you it is a list of strings * the type annotation is redundant to anyone reading the code.

Java encodes constraints and guarantees. Ruby encodes intent and convention. Both work. One trusts context, the other spells it out.

Java -> Ruby -> math notation -> compressed protocol

Typoglycaemia / redundancy

Shannon entropy tells us that natural language carries far more bits per symbol than the minimum needed to convey meaning. If we can read jumbled words and sentences with missing vowels, are they really necessary? The Cambridge meme (first/last letter preservation) proves English carries enough redundancy that large chunks can be dropped without losing meaning.

xkcd 1133: Up Goer Five

Randall Munroe describes the Saturn V rocket using only the 1000 most common English words. The results:

"The kind of air that once burned a big sky bag and people died" * hydrogen
"This is full of that stuff they burned in lights before houses had power" * kerosene
"Things holding that kind of air that makes your voice funny" * helium
"Part that falls off first" / "Part that falls off second" / "Part that falls off third" * rocket stages

27 annotations, averaging ~12 words each, to describe what an engineer conveys in 1-2 words per part. Roughly a 10x expansion.

But there is a real tradeoff here. The Up Goer Five approach has advantages:

No upfront vocabulary to learn. Anyone who speaks English can read it.
Smaller token set. You reuse the same 1000 common words, so the vocabulary overhead is near zero.
Zero onboarding. A child can follow along.

The cost: you need far more tokens per concept. "Hydrogen" is 1 word. "The kind of air that once burned a big sky bag and people died" is 14 words, and it is less precise * which sky bag? The Hindenburg, but you would never know.

This is the fundamental tradeoff: vocabulary size vs token count. A large specialized vocabulary compresses each concept into fewer tokens but demands learning. A small vocabulary reuses tokens but requires more of them per concept. The optimal point depends on how many times you will reuse the vocabulary. For a one-time explanation: Up Goer Five wins. For daily communication: learn the word "hydrogen."

Same tradeoff as the CLAUDE.md protocol. The upfront cost of agreeing on ->, x, ? is tiny. But it only pays off because we reuse those symbols hundreds of times.

The CLAUDE.md protocol as proof

The CLAUDE.md communication protocol:

Symbols: done | -> next | x blocker | ? clarify
Flow: short intent -> act -> checkpoint -> brief result -> loop

Communicating with Claude, spelling is irrelevant, vowels optional, grammar ignored * and precision is maintained. This proves English carries massive redundancy that can be stripped when both parties share enough context.

Live example from this conversation:

"wt f w gt mr i dtl f xkcd"

Decoded: "want/wait for * we get more in detail for/of xkcd" * a request to go deeper into the xkcd comic's actual content rather than just summarizing the concept.

8 consonant-skeleton "words", no vowels, no grammar, fully understood. The message is 30 characters; the English version is 53. ~43% compression with low perceived loss under shared context.

Why I prefer talking to an LLM over humans

LLMs optimize for throughput. Humans optimize for alignment. LLMs are denser, more responsive, and work easier with loss. I can drop vowels, skip grammar, misspell everything, and the model still gets it. Humans need me to slow down, spell things out, repeat myself. The LLM meets me at my speed and my level of compression. It does not ask me to expand what I already said clearly enough. The bandwidth match is better.

This is not a social preference. It is a communication efficiency preference. I already optimize across languages in daily life: my sister and I both speak fluent Czech, but we write to each other in English. It is more token efficient. Simpler. No need to differentiate i/y. No carets, no accents. Shorter words. I do the same with classmates who are native German speakers * we default to English because it is faster. You can rush more, compress more, and still land the meaning. For Software Engineering I enrolled in the English group so that the language stays as close to the technical side as possible. Having to live-translate an English class diagram into German for a presentation is overhead I want to minimize. Every translation is a lossy operation. The LLM just takes that one step further.

Same pattern in what I enjoy studying at ZHAW. I like Analysis 1, Analysis 2, Linear Algebra, Information Theory. These are not ambiguous. They are precise. There is one correct answer. I do not like Databases or Communication modules. Those are imprecise, ambiguous, require more context. Domain modeling is not a precise task * it depends on interpretation, convention, stakeholder opinions. The modules I gravitate toward are the ones where the language is already compressed and unambiguous. The part of Software Engineering I do like is UML. It allows me to express myself very compactly. First you define the communication protocol * the notation itself. Then you can communicate concepts in a very efficient manner. The upfront cost of agreeing on the symbols pays off in every diagram after. Consider composition vs aggregation in UML: a filled diamond explains lifetime-dependency in a single glyph. No sentence needed. Same principle as math notation, same principle as the CLAUDE.md protocol. The same message that takes 8 consonant skeletons with Claude would need a full paragraph with a person, plus clarification, plus context setting. The protocol overhead of human communication is massive.

Same reason I use Neovim. It is the same principle applied to editing. In VS Code, reformatting a paragraph is: mouse select paragraph, open command palette, type "reflow", select the command. In Vim it is gqap * four keystrokes, no menu, no search. Select a word and uppercase it: gUiw. Delete everything inside quotes: di". The grammar is composable: once you learn the verbs (d, c, gU, gq) and the nouns (iw, ap, i"), you can combine them without ever having seen the specific combination before. It is a compressed language for text manipulation. The upfront cost is steep, the long-term throughput unmatched.

The cost of ambiguity (personal)

I struggle with emails. Every sentence carries the risk of misinterpretation. I do not want to sound hostile. I do not want to sound pushy. I do not want to be ambiguous. But English makes all three possible with the same words depending on how the reader feels that day. It is overwhelming. Same when talking to people * finding the right words, worrying about how they interpret me. Human language is lossy in the wrong direction: it does not lose redundancy, it loses intent. With an LLM I do not carry that weight. It does not read tone where there is none.

Ambiguity as the variable

Formal notations compress because they strip ambiguity. English preserves ambiguity because human communication needs it. Human-AI communication needs less ambiguity than human-to-human but more than pure formal notation. The compressed protocol sits in that gap.

Rhythm and repetition

CGP Grey leans heavily into poetic structure in his narration. "Hexagons are the bestagons." It is not just a joke. Rhyme and rhythm improve memorization and flow. He repeats core concepts throughout a video, each time adding a layer, building cohesion. The repetition is not redundancy * it is reinforcement. The same phrase compressed into a catchphrase becomes a handle for the entire idea.

This is a different kind of compression. Not fewer tokens, but more memorable tokens. Poetry, slogans, mnemonics * they optimize for retrieval, not transmission. The best compressed language might need both: dense notation for writing, rhythmic structure for remembering.

Additional ideas/thoughts

Markdown/LaTeX/UML as prior art for structured text: pros/cons of each
Goethe excerpt: find a passage that illustrates verbosity vs density
GEMTEX markup as inspiration
Emojis and symbols as expression
New way to structure text beyond paragraphs
Consistent pronunciation, consonant focus, capitalization for emphasis only
Multiplicities, borrowing concepts from programming (;, =, *, *, .)
What if we communicate with LLMs via UML?

Claude the writer, me the editor

Every section in this article started as a compressed prompt and went through multiple rounds of editing. Claude drafted, I rejected, corrected, restructured, added context only I had. "wt f w gt mr i dtl f xkcd" became the Up Goer Five analysis. "mntn mth symbols mb not faster write but mch faster read" became the information density argument. The ideas and the direction were mine. The expansion was collaborative. The process was the proof.

Sources

Challenge this post (anonymous)

Map-Reducing Myself

Sat, 28 Mar 2026 00:00:00 +0100

I talk to Claude every day. It writes code with me, reviews my PRs, debugs my specs, validates my homework. At 3am it is the thing I talk to when I am still awake and thinking about something I cannot put into words yet. Over six months that added up to 312 conversations and 21MB of JSON.

Claude Code has a /insights command that analyzes your usage. It told me I am a "persistent, correction-driven iterator" who steers Claude through "frequent wrong approaches with direct feedback." 98 sessions, 198 hours. Accurate. Shallow.

I wanted to go deeper. So I built a pipeline to summarize all 312 conversations into a profile of myself.

The pipeline

The raw export is noisy: metadata, UUIDs, timestamps, tool calls, thinking blocks, and the actual text buried inside. The first step is stripping everything that is not what I said or what Claude said.

21MB raw JSON -> 4MB normalized -> 2.9MB plain text

Most of the file was structure, not content. The actual conversations compress to 2.9MB.

Next, chunking. Each chunk needs to fit in a context window, so I targeted 80K tokens per chunk, roughly 320KB of text:

TARGET_BYTES = 320_000

for conv in data:
    conv_size = sum(len(m.get('text', '')) for m in conv['messages'])
    if current_size + conv_size > TARGET_BYTES and current_chunk:
        chunks.append(current_chunk)
        current_chunk, current_size = [], 0
    current_chunk.append(conv)
    current_size += conv_size

That gives 10 chunks. Each gets fed to Claude Sonnet with a prompt asking for everything the conversations reveal about me: identity, preferences, code style, communication style, personality, interests, struggles, projects. Each observation labeled [stated], [demonstrated], or [inferred]. The 10 summaries then merge into one profile. Five parallel workers, a couple of minutes, $3.31 via the API.

10 chunks -> Sonnet -> 10 summaries (~28K tokens) -> Sonnet -> 1 profile

What it found

The profile was accurate. Renuo, ZHAW, Neovim, Ruby, Rust, it/its pronouns, strong opinions about naming, many typos, rejects em-dashes and emojis in technical contexts. It noted that I ask for 20 naming options, then 50, then "more generic," and called this "an intellectual interest, not thoroughness." It catalogued my projects, my coursework, my side interests. All correct. And shallow.

It described what I do. Not why.

What it missed

The profile found that I write inline asserts in my numerical methods code. Pre/postcondition checks inside the functions, not in a test file. It noted this as "inline verification" and moved on.

The asserts are not checking the math. I understand the math. They are checking the transcription. I type fast and produce "everutjing" when I mean "everything." The asserts exist because I do not trust that what I typed is what I meant. The mind is precise. The hands are not. Everything I build sits in that gap.

Claude could not find this. It sees patterns but not the thing that connects them. During the conversation that followed the pipeline, we kept pulling on that thread, and it turned out to be the thread that tied everything together. The typos, the naming obsession, the formatting rules, the inline asserts, the pronouns. All the same gap. None of that was in the data. It came out of the conversation.

The compression

After the pipeline produced the profile, I spent the better part of a day in conversation with Claude, questioning it, correcting it, adding context the data did not contain. Claude read my blog posts and gallery captions on cb341.dev to understand how I write. It asked me things the data could not answer. Then we started compressing.

21MB    raw JSON
 4MB    normalized
2.9MB   plain text
 28K    tokens of summaries
  6K    tokens of merged profile
  200   words of dense description

At each stage, something is lost. The metadata, the structure, the individual conversations, the contradictions, the context. But at each stage, what survives is more essential than what was removed.

There is a concept in information theory called Kolmogorov complexity: the length of the shortest program that produces a given output. It is uncomputable in general, but the idea is useful. The 200-word profile described me accurately. But so did the 6K-token version, and so did the 28K-token version. Each was shorter, none was minimal. Still describing, not yet true.

200 words felt close. Not close enough. So we kept compressing.

15 words

Back and forth, rejecting drafts, cutting what was description and keeping what was true, until there was nothing left to remove.

dani understands and cannot express.
so it builds until it can.
and gives it away.

21 megabytes to 15 words.

Still figuring things out

I went into this thinking I could automate self-knowledge. I could not. Claude could not ask "when was the last time someone took care of you." Some things only surface when someone asks the right question.

But the automated profile was accurate enough to see myself in and say "yes, but also this." Claude was the first draft. The conversation was the edit.

Claude drafted the words. I shaped them until they were mine. The code and the result are MIT licensed.

Challenge this post (anonymous)

My Editor Journey

Sat, 25 Oct 2025 00:00:00 +0200

I have bounced around quite a bit over the years. Started with Atom back when it was the hot new thing, then migrated to VSCode like everyone else when Atom started showing its age.

Eventually moved to JetBrains (specifically RubyMine) for the superior refactoring tools and language intelligence. Somewhere along the way I discovered Vim keybindings and could not go back, so I added IdeaVim to RubyMine.

The JetBrains suite felt too heavy after a while, so I returned to VSCode but this time with Vim emulation. That is when I got curious about actual Vim and tried NVChad for a while. It was close, but I ended up back in VSCode for the ecosystem.

I have dabbled with Sublime Text here and there (I do not really like it), and recently tried Zed when it launched (impressive speed, but too minimal for my needs). I even spent some time with vanilla Vim to understand the fundamentals.

Eventually I built my own custom Neovim setup, which worked great until maintenance became a chore. Tried Cursor when AI coding assistants became a thing, used it a lot for the agentic mode and tab completion features. But I do not really like VSCode as a base, and it made me pretty sad during the time I was using it. Ended up back in my custom Neovim setup because I missed my configurations.

Finally landed on LazyVim, the sweet spot between a pre-configured distro and the flexibility to customize without maintaining everything myself.

Why Neovim

I genuinely enjoy Neovim as a hobby. The community is fantastic, it is intuitive to use once you get the hang of it, and there is no big tech corp jargon or anyone pushing AI down my throat. If I do not like a plugin anymore, I can just uninstall it or write my own replacement.

Building software is a lot about writing programs, text. You need a text editor. I do not think that you necessarily need an IDE as long as you know what you are doing. Many times I am faster searching for things using grep than waiting for ruby_lsp to feed me references. I like using the terminal, I switch very much between terminal and editor, pipe output of shell commands into the editor.

Neovim is not just a text editor. It is FAST, the fastest editing experience I have had. It is incredibly feature rich, yet keyboard oriented for efficient, sophisticated workflows. The modal editing paradigm takes time to learn, but once you understand even a subset of the key command set, it becomes a superpower.

Neovim integrates incredibly well with my terminal setup: zellij, autojump, ripgrep, lazygit. Everything works together seamlessly.

This is the way.

Why LazyVim

DHH promotes it, which caught my attention. Omakub ships with LazyVim as its complete Neovim setup, showcasing what is possible out of the box without having to write a single line of configuration. It is a distribution of Neovim plugins and configurations that has been lovingly tuned.

I was already using lazy.nvim and Lazygit, so the naming consistency appealed to me. LazyVim has sensible default keybindings, excellent support for Ruby out of the box, a great "extras" system for optional features, and makes it trivial to deactivate plugins I do not want. The documentation is solid, which makes troubleshooting and customization straightforward.

The large community is another huge plus. I am much more likely to find solutions to my problems when others have already encountered and solved them.

On AI Coding Tools

AI autocomplete saves me time looking through docs, reading through code, coming up with sensible names. Agents are good for refactoring, as long as they do not touch tests. I do not trust AI generated tests.

It is more about shaping than building line by line. It gives me a lot of flexibility. Let's do two classes, no wait let's merge into one, let's move this, rename that, use this convention, let's use imperative approach, no let's use an ERB template. Let's try this API, no let's try that one. Let's move this into shared context, let's DRYify this, let's translate, let's extract partials.

Agents are great when they work. They produce code very quickly, but debugging can be quite a nightmare. The other day I spent time debugging an ERB file that was causing the linter to fail, only to realize the agent had used Windows line endings for some reason.

I am constantly catching agents silently ignoring errors, adding rescue nil statements, removing unit tests after they have been failing for too long, and straight up LYING about what they have done. I also hate the marketing jargon and the never ending "You're absolutely correct".

I do not really like AI, but I do not want to fall behind the competition either. I want to learn the boundaries of what AI can and cannot do. I do not want to run on autopilot, blindly accepting all suggestions and producing functional but not craftsmanlike, mediocre software. I want to build good software, have fun doing it, and actually understand what I am building. I am making many mistakes and I hope that I'll learn from them eventually, Simon.

Challenge this post (anonymous)

Custom Figma Design Challenges

Tue, 12 Aug 2025 00:00:00 +0200

While building the hackts.ch site, I encountered layout issues that I did not anticipate. The design came from a highly customised Figma file with precise alignments, irregular shapes and spacing patterns.

I chose Rails with custom Sass stylesheets because of the abundance of unique styling across the page. Bootstrap felt difficult to adapt to the design, and Tailwind's utility classes were not flexible enough for the level of customisation required.

The Design Gap

As you can see in the box model view, the layout contains many irregular spacings, varying element sizes, and non-uniform alignments. These characteristics made it difficult to implement using flexbox or grid with simple gaps, margins, and paddings, and required precise, element by element positioning.

A draft of the hackts.ch page with box model inspection, showing the irregular spacing and alignment requirements.

I also experimented with Figma to code tools such as Builder.io's Figma plugin but the results were disappointing. The generated markup was verbose and composed of inline styles, with font styling defined multiple times instead of integrating with the existing font definitions. There was no clear component structure or hierarchy, which made the output unpleasant to read.

Retrospective Approaches

Looking back, several methods might have eased the process:

Rendering sections as images with defined clickable areas using <area> elements
Using background images with text overlays
Exporting directly from Figma as SVGs to keep both vector shapes and text, applying CSS classes to SVG elements for consistent styling (MDN: Styling SVG with CSS)
Adding overlays for pixel accurate alignment adjustments

While using images and clickable areas may allow for faster development, it compromises accessibility, responsiveness, and maintainability, ultimately leading to a poorer user experience and not aligning with best practices in web development.

A Possible Solution

A more efficient solution could be to build a GUI editor in Rails for placing visual components.
Such an editor could work similarly to JavaFX Scene Builder or other drag and drop UI layout tools. Developers could place images, text, and overlays directly in the browser, adjusting positions interactively instead of editing CSS values and refreshing the page.

The implementation could store element coordinates and properties in the database, with position: relative containers handling placement in the final rendering. This would allow pixel accurate adjustments without touching the stylesheets for every change.

An approach could borrow concepts from Herb LSP, which proposes a language server for HTML and embedded Ruby, but adapt them to support live visual positioning of components.
As David Heinemeier Hansson has noted, there is value in keeping the development process grounded in simple, direct editing environments. A GUI editor should complement text based workflows, not replace them, allowing developers to maintain clean and maintainable code while benefiting from faster layout adjustments.

Conclusion

Highly customised designs often make standard frameworks and layout approaches less effective. Even with Sass for flexibility, aligning to the Figma design became a slow and manual process. A GUI editor for Rails, inspired by tools like Scene Builder, could provide an efficient and interactive way to place and adjust components, reducing the need for repetitive code edits while keeping the underlying code approachable.

Challenge this post (anonymous)

Local zsh

Fri, 08 Aug 2025 00:00:00 +0200

Different projects often have different setups.
Some are started with bun, others with bin/dev or bin/start.
Some rely entirely on Docker Compose.

Defining global aliases for commands such as rspec or rubocop can quickly cause conflicts between projects:

alias rubocop='docker compose exec app bundle exec rubocop -a'

Creating complex Bash functions to detect the correct environment is possible, but usually not worth the time.

A Very Simple Solution

Let each project define its own aliases and functions in a small local_zsh file. Then, have your shell source it when you are in that project.

Example structure:

project_1/
  local_zsh
project_2/
  local_zsh

In your .zshrc:

[[ -f local_zsh ]] && source local_zsh

Whenever you switch to a project, sourcing .zshrc loads the correct aliases for that project.

Example local_zsh:

alias bash='docker compose exec app bash'
alias rc='docker compose exec app rails c'
alias rspec='docker compose exec app bundle exec rspec'
alias rubocop='docker compose exec app bundle exec rubocop -a'
alias erb_lint='docker compose exec app bundle exec erb_lint -a'

A small file per project is all that is needed for a more productive setup.

Challenge this post (anonymous)

Exploring Rust as a Rubyist

Fri, 28 Feb 2025 00:00:00 +0100

At Renuo, we love Ruby. It's simple, elegant, and powerful. But let's be honest, Ruby isn't the fastest language out there.

Over the last couple of months, I've been exploring low-level programming, hoping to bridge the gap between the high-level world of Ruby and the lower-level world of systems programming. To do this, I started working on my first Rust project: a blazingly fast voxel "game" called rsmc. It features a terrain generator, meshing, a scalable client-server architecture, and custom serialized messages for high-speed communication. This project has been my playground for learning Rust, and in this post, I'll share some of the lessons I've learned along the way.

Early RSMC development with the Renet visualiser showing simultaneous client/server connections

Why Rust?

Rust is one of the most appreciated programming languages, as highlighted in the GitHub Octoverse Survey. It offers memory safety, high performance, and strong tooling, making it a solid choice for both small utilities and large-scale applications. Many of the tools I use daily, like Alacritty and 1Password, benefit from Rust's speed and reliability.

Key Benefits

Performance: Comparable to C and C++, but with safety mechanisms that prevent common errors.
Memory safety: Eliminates null pointer dereferences, segmentation faults, and data races.
Modern syntax: Readable and expressive, making it accessible despite its low-level capabilities.
Powerful tooling: Cargo simplifies dependency management, builds, and testing.

For my voxel game, Rust's speed and safety make it an excellent choice for terrain generation, networking, and real-time interactions. Unlike dynamically typed languages such as Ruby, Rust catches entire categories of bugs at compile time, improving maintainability.

Beyond CLI tools, Rust powers game engines, operating systems, simulations, and even web browsers, proving its adaptability across different domains.

Bevy: Game Development Made Fun

Since my project is built with Bevy, understanding its core concepts was very important. Bevy's entity-component-system (ECS) architecture makes game development modular and efficient, allowing for highly decoupled systems.

Some of my favorite takeaways:

Systems: Keep them small and focused on one task. This way they are easier to test and extend.
Plugins: Encapsulate resources, systems, and components into distinguishable modules.
Events: Use events to the fullest extent to decouple systems and keep code modular.
States: Run systems only when they are relevant (e.g., Menu, Playing). This helps with UI and logic separation. In particular this PR: #32

Bevy makes structuring a game engine intuitive, and its Rust-first approach ensures safety and performance while keeping things flexible. If you're interested in learning more about the ECS approach to game development, I wrote a blog article about planning an ECS: Multiplayer in Rust Using Renet and Bevy.

Feature Flags: Shipping Less in Production

Feature flags allow enabling or disabling specific functionality at compile time, making it easy to toggle features based on configuration.

In my voxel game, feature flags help manage debugging tools like wireframe rendering and debug UI. What's neat about these feature flags is that debug code doesn't get shipped in production, reducing binary size and keeping the release build clean.

In Cargo.toml, you can define feature flags like this:

[features]
egui_layer = []
terrain_visualizer = ["egui_layer"]
renet_visualizer = ["egui_layer"]

And then use them in your code:

#[cfg(feature = "egui_layer")] {
use bevy_inspector_egui::bevy_egui::EguiPlugin;
	app.add_plugins(DefaultPlugins);
	app.add_plugins(EguiPlugin);
}

The downside is that testing all possible feature combinations is a challenge. With just five features, you already have 32 different configurations to check. But that's the price of flexibility.

Cargo Watch: Automating Workflows

During the development of rsmc, I often needed to recompile code, and manually restarting my binary after every change quickly became tedious. I really wish I had discovered cargo-watch earlier.

Just install it and let the watcher do its thing:

cargo watch -x 'run --bin client'

Composition Over Inheritance

Coming from Ruby, where inheritance is common, Rust's approach felt different. Rust doesn't have classes. It uses structs and traits. This forced me to use composition over inheritance and think differently about code structure.

Here's an example from my terrain generator:

pub struct NoiseFunctionParams {
  pub octaves: u32,
  pub height: f64,
  // ...
}

pub struct HeightParams {
  pub noise: NoiseFunctionParams, // Composition!
  pub splines: Vec<Vec2>
}

Instead of inheriting from a base class, HeightParams contains a NoiseFunctionParams struct. This keeps the code flexible and avoids deep inheritance hierarchies.

Macros: Code That Writes Code

Rust's macros are like Ruby's metaprogramming but more structured and powerful. They help eliminate boilerplate while maintaining type safety.

Here's a macro I used to define blocks in my project:

macro_rules! add_block {
    ($block_id:expr, $is_solid:expr) => {
        Block {
            id: $block_id,
            is_solid: $is_solid,
        }
    };
}

pub static BLOCKS: [Block; 14] = [
    add_block!(BlockId::Air, false),
    add_block!(BlockId::Grass, true),
    // ...
];

Macros don't affect runtime performance. They are a zero-cost abstraction, a great feature of Rust.

Rust's Learning Curve: Worth the Effort?

Rust isn't the easiest language to pick up. The borrow checker takes time to understand, and coming from Ruby, its verbosity stands out. Ruby achieves more with fewer symbols. While Rust's explicitness helps with maintainability and reducing hidden behaviors, it also means writing more boilerplate.

One of the biggest disadvantages to me is compile times. They can be frustrating since Rust enforces strict checks, but this reduces runtime errors. There's even an XKCD comic about it.

XKCD 303 the Rust compile time experience

From my experience, Rust has its trade-offs. Catching many errors at compile time reduces debugging effort, but the strict rules and verbosity make writing new code slower compared to Ruby. That said, Rust's language servers provide excellent refactoring support, which makes working with larger projects easier.

For quick prototyping and iteration, scripting languages such as Ruby are still the better choice. However, when stability, performance, and long-term maintainability matters, Rust seems to be the better pick.

Conclusion

Rust isn't just another language. It changes how you think about programming. It makes you more aware of memory, safety, and performance. The learning curve is steep, but if you stick with it, the rewards are worth it.

I hope you enjoyed this journey into Rust! If you're a Ruby developer who has also tried Rust, what challenges have you faced? I'd love to hear your thoughts!

Challenge this post (anonymous)

Hotwire Outside of Rails

Sat, 03 Aug 2024 00:00:00 +0200

A live Turbo Streams chat demo built with BunJS

This blog article is inspired by a Hotwire Turbo streams tutorial for Sinatra.

When you search for Hotwire tutorials on Google, you'll find that most of the results are related to Ruby on Rails. Even the Hotwire guides predominantly use Ruby on Rails as an example for implementing Turbo Streams.

This does not really come as a surprise, as the framework has been created by the same company behind the Ruby on Rails framework.

However, it's important to recognize that Hotwire is not exclusively a Rails framework. In this blog article, I aim to convince you that Hotwire can be used beyond the Rails context, especially Turbo, its core feature.

Goals

In this blog article, I will explain:

Setting up a BunJS Application
Implementing client and server-side Web Sockets
Using turbo streams to update the UI
Creating a stimulus controller attached to the DOM

Step 1: Set up a BunJS Application

Initially, I considered using Java Spring for this blog, but I encountered challenges with Web Sockets. Instead, I opted for a much simpler TypeScript application.

Let's start by initializing a new BunJS application:

mkdir bunjs-turbo-demo
cd bunjs-turbo-demo
bun init

Now, let's run the application:

bun run index.ts
Hello via Bun!

Step 2: Implement a Simple Web Socket / HTTP Server with BunJS

Web Sockets serve as the backbone for real-time communication in our project. In this step, we'll create a basic Web socket HTTP server using Bun. Web Sockets are essential for enabling bidirectional communication between clients (such as web browsers) and the server.

The Multiple Publisher - Multiple Subscriber Pattern

Our approach involves implementing the multiple publisher - multiple subscriber pattern. Here's how it works:

Client Interaction:
- Clients (users' web browsers) initiate actions, such as sending chat messages or requesting updates.
- These interactions trigger Web Socket connections to the server.
Server Processing:
- The server receives messages from multiple clients.
- It processes these messages and prepares appropriate responses.
Broadcasting Updates:
- When a client sends a message (e.g., a new chat message), the server broadcasts it to all connected clients.
- This ensures that everyone receives the latest updates in real time.
Seamless Communication:
- Web Sockets allow seamless, low-latency communication.
- Clients can instantly receive updates without the need for manual page refreshes.

Here is a simple sequence diagram showing the core idea of this project:

Multiple publisher / multiple subscriber pattern over WebSockets

Implement the server

For brevity, I've omitted the code for view helpers such as layoutHTML and chatRoomHTML. These helpers handle rendering HTML components and chat room layouts. While important, their details won't significantly impact the core concepts discussed in this blog.

const topic = "chatroom";

Bun.serve({
  port: 8080,
  fetch(req, server) {
    const url = new URL(req.url);

    if (url.pathname === "/")
      return new Response(layoutHTML("Chatroom", chatRoomHTML()), {
        headers: {
          "Content-Type": "text/html",
        },
      });

    if (url.pathname === "/subscribe") {
      if (server.upgrade(req)) {
        return;
      }
      return new Response("Couldn't upgrade to a WebSocket connection");
    }

    return new Response("404!");
  },
  websocket: {
    open(ws) {
      console.log("Websocket opened");
      ws.subscribe(topic);
      ws.publishText(topic, messageHTML("Someone joined the chat"));
    },
    message(ws, message) {
      console.log("Websocket received: ", message);
      ws.publishText(topic, messageHTML(`Anonymous: ${message}`));
    },
    close(ws) {
      console.log("Websocket closed");
      ws.publishText(topic, messageHTML("Someone left the chat"));
    },
    publishToSelf: true,
  },
});

Implement the client

The application is incomplete without the client, which connects to the Web Socket server. Following the Web Socket server connection documentation, connecting to the backend is straightforward:

const client = new WebSocket("ws://localhost:8080/subscribe");
const form = document.getElementById("chat-form");
const chatFeed = document.getElementById("chat-feed");

client.addEventListener("message", (event) => {
  chatFeed.innerHTML += event.data;
});

form.addEventListener("submit", (event) => {
  event.preventDefault();
  const formData = new FormData(form);
  const message = formData.get("message");
  client.send(message);
  form.reset();
});

Don't forget to add the route for the JavaScript file to the backend and include it inside your view using a module script tag. Also, make sure to implement the backend response.

The problem

As you can see here, every change in UI needs to be manually implemented. At the moment, we are listening to a single event and updating one single element. When the application grows in complexity, the JavaScript code grows, too. What if I told you that we can "almost" completely eliminate the client code by introducing Turbo streams?

Step 3: Implement Turbo streams

Turbo is a vital part of the Hotwire Framework. It enables you to dramatically reduce the amount of custom JavaScript you need to write.

The most relevant feature for this application are the turbo streams. They enable us to deliver page changes in the form of HTML over the wire.

Importing Turbo is as simple as including this snippet of code inside our layout file:

<script type="module">
  import hotwiredTurbo from "https://cdn.jsdelivr.net/npm/@hotwired/turbo@8.0.3/+esm";
</script>

In order to use Web Sockets for Turbo streams in the frontend, we can use the following snippet from the stream documentation:

<turbo-stream-source src="ws://localhost:8080/subscribe" />

In order to update the UI when a message is sent, we broadcast the following HTML through Web Sockets:

<turbo-stream action="append" target="chat-feed">
  <template>
    <p class="notice">Anonymous: Hello World!</p>
  </template>
</turbo-stream>

This method of HTML updates stands out for its transparency and simplicity. Firstly, we select an element with the #chat-feed selector and then append to it the contents of the broadcasted template. In this case, a paragraph containing the user message. This also eliminates almost all the client-side JavaScript needed for page update.

Step 4: Implement Form Controller

Before introducing turbo, we added a simple event listener to reset the Form after the data has been sent to the server. We now need to bring the functionality back, but without reusing the old code. We could use a turbo-stream to reset the form or even a turbo-frame, but rather than using that, I decided to use another library of the Hotwire framework, namely Stimulus:

Stimulus is a JavaScript framework with modest ambitions. It doesn't seek to take over your entire front-end -- in fact, it's not concerned with rendering HTML at all. Instead, it's designed to augment your HTML with just enough behavior to make it shine.

https://stimulus.hotwired.dev/

This is a simple code snippet for the Form Stimulus controller:

import {
  Application,
  Controller,
} from "https://cdn.jsdelivr.net/npm/stimulus@3.2.2/+esm";

class FormController extends Controller {
  clear() {
    this.element.reset();
  }
}

const application = Application.start();
application.register("form", FormController);

This is what the form HTML looks like, with data attributes used to attach the controller to the DOM and hook the events up to the corresponding controller methods:

<form
  id="chat-form"
  action="/submit"
  method="post"
  data-controller="form"
  data-action="turbo:submit-end->form#clear"
>
  <label for="message-input">Message:</label>
  <input name="message" data-form-target="input" required />
  <input type="hidden" name="clientId" value="${clientId}" />
  <input type="submit" value="Send" />
</form>

The event that works best for form submission in that case is turbo:submit-end. Following the documentation of Stimulus descriptors, we can call the #clear() method after the form submission event. We are not using the submit event because this would clear the form prematurely.

Conclusion

Hotwire is a JavaScript framework that helps us make applications more interactive while keeping the JavaScript code to a minimum. While the framework has been created by the authors of Ruby on Rails, the framework itself is backend agnostic.
Turbo streams enable us to update client user interfaces asynchronously without the need for any (in some cases, just very little) frontend code.
Stimulus enables us to add simple JavaScript behavior to our HTML with the use of Stimulus Controllers and data-attributes.

Where can I find the source?

You can find the complete chatting application with additional features such as:

Client identification via Query Parameters
Random username generation
Real-time user list

The GitHub Repository for this project can be found here: https://github.com/cb341/bunjs-turbo-demo

Challenge this post (anonymous)

Supercharge Your Tmux Setup

Sun, 14 Apr 2024 00:00:00 +0200

Tmux is a terminal multiplexer. It is a tool for managing multiple shells inside a single terminal window. It is integrated into most modern terminal emulators like Iterm2 or Warp. In this blog article, I will show you two simple configurations that drastically improved my tmux experience.

Autoresizing panes

The main problem I had with tmux when starting out was that panes were not automatically resized as I was used from Warp:

Panes without auto-resize, manually spreading with <PREFIX> + E

Don't get confused by the remapped tmux prefix. The main thing to notice here is that I am using <PREFIX> + E to spread the panes out evenly.

What we now need is:

The command to resize the windows
The hook(s) for executing the command
Update the tmux configuration with the hook and the command.

Part1: Finding the command

According to the manual entry for tmux:

select-layout [-Enop] [-t target-pane] [layout-name]
							 (alias: selectl)
				 Choose a specific layout for a window.  If layout-name is not given, the last preset layout used (if any) is
				 reapplied.  -n and -p are equivalent to the next-layout and previous-layout commands.  -o applies the last
				 set layout if possible (undoes the most recent layout change).  -E spreads the current pane and any panes
				 next to it out evenly.

We can use the select-layout -E command to spread the panes evenly.

Part2: Finding the hooks

The first part is done. Now we need the hooks.

Unsurprisingly, this can also be found in the manual entry:

%window-pane-changed window-id pane-id
	 The active pane in the window with ID window-id changed to the pane with ID pane-id.

...

window-resized          Run when a window is resized.  This may be after the client-resized hook is run.

Part3: Updating the configuration file

If you haven't moved the .tmux.conf to .config, you can find the default configuration file for MacOS at ~/.tmux.conf.

To execute the command on the resize and pane changed hooks, we can add these lines to the tmux configuration:

# .tmux.conf
...
set-hook -g window-pane-changed 'select-layout -E'
set-hook -g client-resized 'select-layout -E'
...

This is how the panes behave after adjusting the configuration:

Panes automatically spreading after adding the select-layout -E hooks

According to the manual entry, we can also shorten the command to the following:

set-hook -g window-pane-changed 'selectl -E'
set-hook -g client-resized 'selectl -E'

Dimming Inactive Panes

Next to automatically resizing windows, we can also automatically dim panes that aren't active by using the following configuration:

set-hook -g pane-focus-out 'select-pane -P bg=colour233,fg=colour10'
set-hook -g pane-focus-in 'select-pane -P bg=default,fg=default'

Inactive panes dimmed using focus hooks

Now, this is a much nicer alternative than the active border color. If you are wondering how I got rid of it, I used this configuration:

set -g pane-active-border-style "bg=#000000,fg=white"
set -g pane-border-style "bg=#000000,fg=white"

Remember that black and #000000 are not the same thing when configuring your terminal, as the color names are defined by your color scheme.

Conclusion

While tmux isn't as usable/powerful out of the box as the integrated tmux in Iterm or Warp, with some simple configuration, it can be significantly improved. The manual page for tmux is the go to source for looking up commands and events and will save a lot of time googling.

Tools and Sources

Screen recorder: CleanShotX
Keystroke recorder: KeyCastr
Terminal Emulator: Alacritty
Other configuration: My Dotfiles

Challenge this post (anonymous)

Multiplayer with Bevy and Renet

Thu, 07 Mar 2024 00:00:00 +0100

Here at Renuo, we specialize in web technologies such as Ruby on Rails, React, Angular, and Spring. One of our core company values is continuous learning: we love exploring new technologies even beyond our usual scope of expertise.

Inspired by Michael's Unity Powerday, I decided to delve into how multiplayer games operate. As a team, we held a competition to implement FPS (First-Person Shooter) games using C# boilerplate. Initially, the sheer amount of boilerplate required felt overwhelming. Beyond that, I wanted to understand client/server data synchronization at a lower level of abstraction.

My recent experiences with Rust and Bevy convinced me to write this blog article to share my newfound learnings of game development.

Why Choose Rust

Advantages

Rust is a statically typed, memory-safe, multi-paradigm programming language that matches the performance of C. Due to its safety, concurrency features, and modern syntax, it has gained popularity among developers in recent years.

Some notable software written in Rust includes:

Rapier3d: A performant physics engine often used with ThreeJS.
Ripgrep: A performant command line search tool.
Alacritty: A performant, minimalistic cross-platform terminal emulator.
Warp: A performant, modern terminal IDE.
Tauri: A performant and lightweight alternative to ElectronJS.
Amethyst: A performant tiling window manager for MacOS.
Condorium Blockchain: A performant and secure blockchain technology.

"I mean, there is no such thing as a perfect programming language.
Rust is merely a statically type low-level multi-paradigm perfect programming language."

YouTube interview by Programmers Are Also Human,

Ferris, the unofficial Rust mascot

Picking a game engine

"There are currently 5 games written in Rust. And 50 game engines."

Interview with a Senior Rust Developer - 2:52

There are too many game engines available for Rust. An excellent resource is Are We Game Yet. I also recommend this article by GeeksforGeeks, which makes picking the optimal engine easier.

The Difference Between Bevy and Other Engines

While big game engines like Godot, Unity, and Unreal Engine come with graphical editors, Bevy focuses on providing a simple yet powerful, multithreaded system to manage game state with minimal code.

Understanding ECS

The ECS (Entity Component System) is a software pattern that emphasizes a modular design. It is commonly utilized in game and game engine development. This approach separates the data and behaviour of game entities into components, making it easier to manage and organize complex systems.

Components of ECS

Entities: Unique identifiers of a group of components (A u32 wrapper in bevy).
Components: Modular data pieces that represent specific Entity attributes. (A struct that derives the Component macro in bevy)
System: Logic that operates on entities and their components. (A struct that derives the Resource macro in bevy)

Systems in Bevy

Systems in Bevy are functions that take various parameters such as queries, EventReaders, assets, and resources and apply logic to them.

One powerful feature of Bevy systems is the Query interface. It allows you to fetch specific data for entities in your project. For instance, if no entity is found, the single_mut() function will raise an error. Multiple queries are possible as long as entities do not overlap.

Below is an example where the MyPlayer component doesn't contain any data but is used to denote that the entity belongs to the client player.

pub fn update_player_movement_system(
    mut keyboard_events: EventReader<KeyboardInput>,
    mut query: Query<(&mut Transform, &MyPlayer)>,
) {
    let (mut transform, _) = query.single_mut();

    for event in keyboard_events.read() {
        let mut delta_position = Vec3::new(0.0, 0.0, 0.0);

        match event.key_code {
            KeyCode::KeyW => delta_position.z += 0.1,
            KeyCode::KeyS => delta_position.z -= 0.1,
            KeyCode::KeyA => delta_position.x -= 0.1,
            KeyCode::KeyD => delta_position.x += 0.1,
            _ => {}
        }

        let new_position = transform.translation + delta_position;
        transform.translation = new_position;
    }
}

The example above has a flaw: the player position update has a fixed step. Instead of using a fixed-step update, consider using the time passed since the last step. This will ensure a consistent movement speed regardless of the frame rate.

Picking Networking Libraries

We need to decide on networking libraries after choosing Bevy as our game engine. Here are a few options:

Matchbox
Naia
Renet
Bootleg_networking
Spicy_networking

I chose Renet because of its popularity and my good experiences with its boilerplate. Additionally, I included Serde for efficient binary message encoding.

Sketching the scene

Before coding, let's sketch a simple scene:

Camera: Renders the scene.
Plane: Represents the floor.
Green Cube: Represents the player.
Red Cubes: Represent other players.

Attributes to synchronize:

Position: Vec3

Input method:

Keyboard (WASD): Used to translate the player.

Handling Player inputs

There are three main ways to handle player inputs:

Client-side: The client handles inputs, moves the player, and sends the position to the server.
Server-side: The client sends input data to the server, and the server responds with the position.
Hybrid: The client handles inputs and shares them with the server, which then responds with position synchronization.

The client-side approach can reduce latency, but is less secure. The server-side approach is more secure but adds server load. The hybrid approach offers a balance, but is more complex.

Planning

Client

Type	Name	Description
Component	PlayerEntity(ClientId)	Represents an enemy player entity.
Component	MyPlayer	Marks the current player entity.
Event	PlayerSpawnEvent(ClientId)	Emitted when a player joins. Adds a player object to the scene.
Event	PlayerDespawnEvent(ClientId)	Emitted when a player leaves. Removes a player object from the scene.
Event	PlayerMoveEvent(ClientId, Vec3)	Emitted by the player controller when a player moves.
Event	LobbySyncEvent(HashMap<ClientId, PlayerAttributes>)	Emitted when the client receives sync messages from the server. Updates other player positions using their ID and position.
System	send_message_system	Shares MyPlayer position data with the server.
System	receive_message_system	Processes messages received from the server.
System	update_player_movement_system	Updates player position from keyboard input.
System	setup_system	Sets up the scene with a camera, a ground plane, and a mesh for the current player.
System	handle_player_spawn_event_system	Adds enemy players to the scene once they join in.
System	handle_lobby_sync_event_system	Updates enemy player positions and potentially spawns missed players into the scene.

Server

Type	Name	Description
Resource	PlayerLobby(HashMap<ClientId, PlayerAttributes>)	Holds attributes of all players currently in the game. Used to synchronize these attributes with the clients.
System	send_message_system	Broadcasts player positions to keep enemy player positions in clients up-to-date.
System	receive_message_system	Updates player lobby position based on messages received from the RenetClient.
System	handle_events_system	Handles events such as ClientConnected and ClientDisconnected from the Bevy Renet plugin.

Deciding on a project structure

I separated the ECS components into specific modules to structure the Bevy project and used two entry points: one for the client and one for the server. Shared code, such as structures for Client-Server communication, can be placed in a global lib module.

src
src/
  client/
    components.rs
    events.rs
    main.rs
    resources.rs
    systems.rs
  lib.rs
  server/
    main.rs
    resources.rs
    systems.rs

Defining various entry points is as simple as adding this to the Cargo.toml file:

[[bin]]
name = "server"
path = "src/server/main.rs"

[[bin]]
name = "client"
path = "src/client/main.rs"

Afterwards, the binaries can be run with the --bin argument:

cargo run --bin server
cargo run --bin client

Setting up Boilerplate

To integrate bevy_renet into the bevy project, I followed the Bevy Renet documentation. In my setup, I used these two default channels:

Unreliable: Used for sending and receiving messages for player attribute synchronization. (We don't care about every state change, we can pick the last one)
ReliableOrdered: Used for sending and receiving messages for player actions such as joining and leaving.

Synchronising player positions

Here's an example of sending player attributes from the client to the server:

pub fn send_message_system(mut client: ResMut<RenetClient>, query: Query<(&MyPlayer, &Transform)>) {
    let (_, transform) = query.single();
    let player_sync = PlayerAttributes {
        position: transform.translation.into(),
    };
    let message = bincode::serialize(&player_sync).unwrap();
    client.send_message(DefaultChannel::Unreliable, message);
}

Handling messages from the client on the server:

pub fn receive_message_system(mut server: ResMut<RenetServer>, mut player_lobby: ResMut<PlayerLobby>) {
    for client_id in server.clients_id() {
        let message = server.receive_message(client_id, DefaultChannel::Unreliable);
        if let Some(message) = message {
            let player: PlayerAttributes = bincode::deserialize(&message).unwrap();
            player_lobby.0.insert(client_id, player);
        }
    }
}

Sending attributes of all players back to the client:

pub fn send_message_system(mut server: ResMut<RenetServer>, player_lobby: Res<PlayerLobby>) {
    let chanel = DefaultChannel::Unreliable;
    let lobby = player_lobby.0.clone();
    let event = multiplayer_demo::ServerMessage::LobbySync(lobby);
    let message = bincode::serialize(&event).unwrap();
    print_lobby(&player_lobby);
    server.broadcast_message(chanel, message);
}

Synchronizing the client scene with the player attributes from the server:

pub fn handle_lobby_sync_event_system(
    mut spawn_events: EventWriter<PlayerSpawnEvent>,
    mut sync_events: EventReader<LobbySyncEvent>,
    mut query: Query<(&PlayerEntity, &mut Transform)>,
    my_clinet_id: Res<MyClientId>,
) {
    let event_option = sync_events.read().last();
    if event_option.is_none() {
        return;
    }
    let event = event_option.unwrap();

    for (client_id, player_sync) in event.0.iter() {
        if *client_id == my_clinet_id.0 {
            continue;
        }

        let mut found = false;
        for (player_entity, mut transform) in query.iter_mut() {
            if *client_id == player_entity.0 {
                let new_position = player_sync.position;
                transform.translation = new_position.into();
                found = true;
            }
        }

        if !found {
            info!("Spawning player {}: {:?}", client_id, player_sync.position);
            spawn_events.send(PlayerSpawnEvent(*client_id));
        }
    }
}

Conclusion

The multiplayer demo project demonstrates the intricate planning and attention to detail needed to synchronize player attributes between the client and server. This showcases the complexity of creating a seamless multiplayer experience at a lower level.

For more detailed code, visit the MIT-Licensed GitHub repository.

Challenge this post (anonymous)

Threads: 08.06.2026

Mon, 08 Jun 2026 00:00:00 +0200

while studying DNS for exam prep, i ended up browsing the list of all top-level domains:

https://www.iana.org/domains/root/db

a few things stood out.
first, some testing-related entries:

.test is not listed
.invalid is not listed

because they are reserved and not delegated, they can never resolve in the public DNS. RFC 6761 marks them special-use: .test (6.2) and .invalid (6.4).
then some amusing generic TLDs:

.foo - generic, Charleston Road Registry Inc.
.bar - generic, Punto 2012 Sociedad Anonima Promotora de Inversion de Capital Variable

and then:

.app - generic, Charleston Road Registry Inc. (Google's registry entity)
.mov - generic, Charleston Road Registry Inc. (Google's registry entity)
.zip - generic, Charleston Road Registry Inc. (Google's registry entity)

.app feels normal enough.
.mov and .zip immediately felt odd.

they are file extensions 1st. domains 2nd.

historically:

invoice.zip -> file

now:

invoice.zip -> file
invoice.zip -> domain

same string.
two meanings.

there is even a recent paper dedicated to this:

"The namespace for filenames and DNS names has overlapped since the introduction of DNS in 1985: .com was the original binary format used for DOS and CP/M systems. Recently the introduction of gTLDs such as .zip and .mov, coupled with the growing prevalence of web resources, has ignited new concerns about potential issues related to DNS and filename confusion."

https://arxiv.org/abs/2604.04805

another quote:

"document[.]zip ... could refer to either a compressed archive file ... or a website"

and:

"A potent scenario for confusion occurs when filenames are automatically hyperlinked"

the paper does not claim that .zip broke the Internet.
it does show that the confusion is observable across software ecosystems.

the authors write:

"harms primarily arise when filenames are mistakenly interpreted as DNS names"

and:

"the DNS query itself leaks information about local filenames"

the technical argument is simple:

DNS does not care.
humans do.

DNS sees valid labels:

.com
.zip
.mov
.app

while humans have spent decades learning that something.zip is a compressed archive. the protocol and the user now disagree.

some examples of abuse:

https://www.fortinet.com/blog/industry-trends/threat-actors-add-zip-domains-to-phishing-arsenals

another thing i noticed is the number of non-ASCII TLDs:

.公司 - generic, China Internet Network Information Center (CNNIC)
.联通 - generic, China United Network Communications Corporation Limited
.vermögensberatung - generic, Deutsche Vermögensberatung Aktiengesellschaft DVAG
.இந்தியா - country code National Internet Exchange of India
.москва - generic Foundation for Assistance for Internet Technologies and Infrastructure Development (FAITID)

i like this.

the Internet should not be limited to ASCII.
but it introduces another class of ambiguity.
my first question was:

can Unicode only be used in the TLD?

no.

it can appear anywhere in an internationalized domain name.
this leads directly to homograph attacks.

example:

paypal.com

leading with U+0070 LATIN SMALL LETTER P.

versus:

рaypal.com

leading with U+0440 CYRILLIC SMALL LETTER ER.

they look almost identical.
only different code points.

the Unicode Consortium uses essentially this example:

Suppose that you get an email notifying you that your paypal.com account has a problem. You, being a security-savvy user, realize that it might be a spoof ... But actually it is going to a spoof site that has a fake "paypal.com", using the Cyrillic letter that looks precisely like a 'p'. You use the site without suspecting, and your password ends up compromised.

https://www.unicode.org/L2/L2005/05110-tr36-draft3/tr36-3r.html

same pattern as .zip.

the computer sees one thing.
the human sees another.

that difference is what enables IDN homograph attacks.

how do browsers mitigate this?

when a label trips its IDN filter, show the Punycode (xn--...) instead of the deceptive Unicode (example: Chromium).

two cases:

mixed-script: рaypal (one Cyrillic р)
trips the filter → shown as xn--aypal-uye.com → caught.
whole-script: аррӏе (all Cyrillic)
slips past it → stays Cyrillic, reads as apple.com → missed.

the first is the example i used above. the second is the dangerous one, still live as Xudong Zheng's 2017 proof-of-concept.

the link below reads apple.com. it does not go there:

аррӏе.com (writeup)

a modern browser shows the Punycode now, because the filter learned to flag lookalikes of known top domains. in 2017 it showed apple.com. a confusable of a less famous domain still slips through.

inspect any conversion yourself: https://www.punycoder.com/

while reading about .zip, i kept noticing the same tradeoff:

small local benefit. large distributed cost.

more examples:

Office macros: automation ↔ malware delivery
Microsoft now blocks internet-sourced macros by default, citing their routine abuse for ransomware and remote-access trojans.
https://techcommunity.microsoft.com/blog/microsoft_365blog/helping-users-stay-safe-blocking-internet-macros-by-default-in-office/3071805
SMS 2FA: easy deployment ↔ SIM swapping
all five major US carriers used authentication an attacker could trivially subvert (Lee, Kaiser, Mayer, Narayanan, SOUPS 2020). NIST 800-63B restricts SMS as an authenticator.
https://www.usenix.org/conference/soups2020/presentation/lee
https://pages.nist.gov/800-63-4/sp800-63b.html
MIME sniffing: compatibility ↔ content-sniffing XSS
a browser that guesses a file's type can be tricked into running an uploaded "image" as HTML (Barth, Caballero, Song, IEEE S&P 2009). the WHATWG spec it informs is the standard.
https://www.adambarth.com/papers/2009/barth-caballero-song.pdf
https://mimesniff.spec.whatwg.org/
email tracking: rich HTML ↔ surveillance on open
85% of bulk emails embed third-party content; ~29% leak your address to a third party the moment you view them (Englehardt, Han, Narayanan, PoPETs 2018).
https://petsymposium.org/popets/2018/popets-2018-0006.php

different technologies.

same shape.

the feature owner gets the benefit.
everyone else inherits the complexity.

for .zip, i still struggle to see the upside.

most arguments eventually reduce to branding.

the downside is permanent ambiguity in a namespace that billions of people already associated with files.

maybe the cost is insignificant.
maybe nobody notices.

but if someone proposed:

.pdf
.docx
.exe
.jpg

as top-level domains today, most engineers would (hopefully) immediately see the problem.

.zip and .mov feel different mostly because they already (unfortunately) exist.

Challenge this thread (anonymous)

Threads: 02.06.2026

Tue, 02 Jun 2026 00:00:00 +0200

exam prep:
investment accounting ; cashflow, npv, discount factors, present values.

not hard exactly. mostly bookkeeping with time attached.
a table of cashflows over the years, discount factors, barwerte.

then the table started lying.
not maliciously. numerically. formula:

simple enough.
but the displayed values were rounded.
and somewhere nearby there was a symbol that looked like equality with something on top of it.
not quite
not quite
more like

which apparently means "corresponds to".
that annoyed me into a tangent.

because i realized i do not actually know what i want approximate equality to mean in general.

approximate because why?

because the exact value was rounded for display?
because a sensor measured it imprecisely?
because a statistical model estimated it?
because a numerical method only converged far enough?
because floating point rounded it?
because the formula itself is only a simplified model of reality?

all of those collapse into same lazy glyph: .

but they are not same failure mode.
rounding is representational.
the exact value may exist. i just chose not to print all of it.
measurement is a knowledge graph.
the value may exist. i just do not know it exactly.
numerical error is procedural.
the mathematical object may be exact. the method only approached it.
model error is deeper.
the equation only ever approximated reality.

"all models are wrong, but some are useful."

i like that line.
because it accepts lie and asks whether lie earns its keep.

Newton's gravity is nice example.

force between two masses.
clean. compact. almost suspiciously pretty.

but this is only one layer.
Newton describes gravity as force.
Einstein replaces that picture with spacetime curvature.

schematically:

not exactly same kind of formula.
not "same thing, more decimals".
different category entirely.

left side: geometry of spacetime.
right side: matter and energy.

Newton works extremely well in weak gravitational fields and low velocities.
falling objects, planets, satellites, engineering calculations.

but push far enough and it breaks.
Mercury's perihelion.
black holes.
strong gravity.
high precision.
spacetime itself.

general relativity does not round Newton more carefully.
it changes what gravity is.

Newton did not round gravity.
Newton modeled it.

that is different from .

there exact value exists.
display was just shortened.

so i started wanting symbol for that.
not generic approximate equality.
display precision equality.

something like .

i have not seen it in any engineering textbooks so far.
but i like it.
dot feels like decimal point.
equality sign with decimal damage.

meaning:
b is displayed finite precision representative of a.

so would not mean "one third is vaguely close to 0.3333".
it would mean:
exact value is one third.
printed value is rounded.

a math.stackexchange thread makes the point from the other side:

and are used in many different ways in many different areas of mathematics, so there's no single established definition on what they mean. do you know if the use of these symbols is "standard" in the field you are working in? ie, are you getting them from a particular textbook or paper?
-- Atticus Stonestrom

the answerer's first instinct is to ask which textbook or field you took them from. which is precisely my situation. but "i haven't seen it" does not imply "it is free to be specified". my is just , and that glyph is already overloaded ; in some communities even means "defined as". so stamping another meaning onto it would not reduce ambiguity. it would add to it.

but then again.
maybe that distinction often does not matter.

if number is good enough for decision, knowing whether inexactness came from rounding, measurement, or computation may add no useful information.
for investment table, maybe 0.909 is just 0.909.
good enough to compare alternatives.
nobody needs philosophical breakdown of discount factor.

that is probably why survives.
it is vague, but efficient.
it says "do not treat this as exact" and leaves reason to context.

maybe people do care why something is approximate.
maybe they just store reason somewhere else.
method section, table caption, standard, discipline, implicit context.

fair.

but still.
i want symbol to carry some of it.

maybe symbols are just compression.
tiny program.
reader sees token.
reader expands token using shared context.

expands cleanly.
expands broadly.
would expand narrowly, but only if i define it first.

without shared context, it is just another weird glyph.

this reminds me of programming.
0, null, and undefined can all look like "nothing" from far away.
but they are different nothings.
zero is value.
null is intentional absence.
undefined is not provided.
collapse them and you get bugs.

same here.
collapse rounding, measurement, numerical error, and model error into , and you lose information.

sometimes that loss is fine.
sometimes it is whole point.

says:
close enough.

could say:
equal, after display precision did damage.

or shorter:
hides error.
names compression.

somewhere along way i also learned .

little square at end of proof.
not part of argument.
more like punctuation.
done.
proof complete.

i like that.
it is honest about closure.
proof had target, reached it, marks end.

approximation notation feels like inverse.
does not close anything.
it opens metadata.
approximate why?

rounded?
measured?
estimated?
modeled?
computed?
stored in floating point?
truncated?

maybe that is why feels satisfying.
it marks certainty.
and maybe that is why feels slippery.
it marks uncertainty, but refuses to say what kind.

Challenge this thread (anonymous)

Threads: 19.05.2026

Tue, 19 May 2026 00:00:00 +0200

started playing chess myself again after watching god-tier play of hikaru, levi, magnus ; thought i understood chess by watching. tried blitz and brutally realized i didn't.

150-300 elo. accuracy below 50%. one game i even managed a 35 material disatvantage because i wasn't paying attention.

watched more. saw patterns i'd missed.
tried puzzles and solved 400+.
pins, skewers, basic mates. watched more. saw even more depth.

now i switched to slow chess. untimed bot games. some evaluate at 1400.
doesn't mean i'm 1400. means with infinite time, i can sometimes see what to do.

each iteration uncovered more.
and there is so much more to chess than i imagined.

then found GM José Raúl Capablanca.

everyone learns by memorizing openings. hundreds of variations.
capablanca reduced the entire game to 7 principles:

check for hanging pieces every move: yours and theirs. before anything else. loose pieces drop off. most games below 1500 are decided by one side leaving a piece undefended, not by deep strategy
activate your king, restrict opponent's king: centralize yours, cut off theirs. in the endgame the king is a fighting piece
prioritize passed pawns: main offensive plan is to create and advance them. a passed pawn must be pushed
rule of trade-offs: winning? trade pieces, keep pawns. losing? trade pawns, keep pieces, seek draw
prevent opponent plans (prophylaxis): determine what they want, stop it before pursuing your own
attack weaknesses, principle of two weaknesses: one weakness rarely loses. create a second on the other side of the board, stretch the defense until it tears
know basic endgames cold: king+pawn vs king, opposition, square rule, lucena, philidor. without these the rest is theatre

bishop endgames add some more:

place your pawns on opposite color to your bishop
force opponent's pawns onto same color as their bishop
restricts their bishop, creates permanent targets, maximizes yours

the more i learn, the more there is.
but capablanca shows it can still be thought about simply.
which is very elegant to me.

i realized that i already do this instinctively.
not with rules but with board state.
i tend to mercilessly trade pieces to reach endgames.
fewer pieces → fewer branches → clearer position → less room for mistakes

"The winner of the game is the player who makes the next-to-last mistake."
— Savielly Tartakower

Challenge this thread (anonymous)

Threads: 12.05.2026

Tue, 12 May 2026 00:00:00 +0200

looked into autism traits today to understand people better.
namely how perception of marketing and manipulation is affected by rational neurodivergence which made me stumble on the word "anthropomorphism":

objects as if they are human in appearance, character, or behaviour

this made something CLICK about CS vocabulary.
many concepts are inherently anthropomorphized by design:

emotions:        compiler is angry, service is happy/sad/healthy,
                 process is starving, thread is waiting patiently

relationships:   parent/child process, orphaned container,
                 master/slave (deprecated), sibling nodes

human actions:   daemon woke up, server died/killed, worker is idle,
                 garbage collector cleaned up, service is listening,
                 endpoints are talking, connection refused

human states:    process sleeping/running, cache is fresh/stale,
                 bit is dirty/clean, link is alive/dead

vs non-human but still metaphorical:

borrowed names:  zombie, worm, trojan horse, spider, crawler
architecture:    pipeline, gateway, backbone, bridge
military:        payload, attack, exploit, kill chain

the concepts aren't new to me. the label is.
the conceptual metaphors are no longer invisible.

found an umbrella term: tropes (meaning-shift)

tropes
|- metaphor          "time is money"
|- metonymy          "White House said"
|- synecdoche        "boots on the ground"
|- personification   "wind whispered"
|- anthropomorphism  "compiler is angry"
|- reification       "market decided"
+- irony, hyperbole, litotes...

was aware the shifts exist.
now i can name them.

also learned chiasmus today: reversed term order for symmetry.

"Ask not what your country can do for you — ask what you can do for your country" (JFK)

Breakdown:

ask not   what your country   can do   for you
ask       what you            can do   for your country

uses elegant structure to aid memorability.

Challenge this thread (anonymous)

Threads: 11.05.2026 (afternoon)

Mon, 11 May 2026 15:00:00 +0200

(yes this entry contains filler, are you yet frustrated by it?)

recently discovered the RFC writing style for the internet.
RFC 2119 defines a handful of keywords meant to remove ambiguity from specifications:

MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.

MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.

SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

...

we SHOULD apply this to everyday language.

daily language is mostly filler. greetings burn tokens.
when both sides agree the goal is to exchange information, not feelings, email is high friction for no reason.

on a different note:
can we make it socially acceptable to write emails in a colder, denser way?

BEFORE

Guten Abend zusammen!

Wir haben eine Reservation für die Drachenhöhle am Freitag, 08.05.2026.
Ursprünglich hatten wir mit etwa 18 Personen geplant, aber es sieht nun so aus, dass wir am Ende etwa 8 Personen sein werden. Da fragen wir uns, ob ein Wechsel zur Hobbithöhle Sinn machen würde. Für eine kleinere Gruppe wäre das wahrscheinlich die gemütlichere Atmosphäre.

Falls das noch möglich ist, würden wir uns sehr freuen. Ansonsten kommen wir natürlich auch gerne in die Drachenhöhle :)

Vielen Dank und freundliche Grüsse

Dani Bengl (it/its)

intention is buried. greeting, setup, filler, hedge, thanks. politeness at the cost of signal.

what i actually wanted to say:

AFTER

Reservation Fr. 08.05.2026, Drachenhöhle.
Teilnehmer: 18→8.
Wechsel zu Hobbithöhle möglich?

Dani Bengl (it/its)

the organizers will extract that core from my original anyway.
then they formulate their own core ("room available, will move", or "possible but maybe keep the bigger room"), pad it with filler, send.
i receive, scan, decode, repeat.

why can't human ↔ human communication skip the encode/decode step?

maybe it can. open the channel with a header:

the following message is optimized for density. no impoliteness implied.

and inside, reduce vocabulary for load-bearing words. MUST, MUST NOT, SHOULD, MAY. capitalized as in the RFC.

builds on top of a-optimized-language, section "Why I prefer talking to an LLM over humans".

i'll try it. either non-engineers read me as cold and heartless, or they appreciate the efficiency.

Challenge this thread (anonymous)

Threads: 11.05.2026 (morning)

Mon, 11 May 2026 09:00:00 +0200

most modern languages signal sentence type at the end.
declarative, imperative, interrogative, exclamatory.
you only learn the tone after you've already read the words.
hard to read aloud. you have to guess, then correct.

why not put the marker first?

Why do we even bother with languages?

vs.

? why do we even bother with languages

reads more structured. same shape as:

Q: Why do we even bother with languages?

and while we're rewriting orthography. capitalization currently marks sentence starts.
the leading marker would already do that.
free up capitalization for meaning instead. emphasize words that MUST NOT be skimmed, like bold or italics but in plain text.

if a leading ? opens a question, does the trailing ? still earn its keep? probably drop it. one marker per sentence...

Challenge this thread (anonymous)

Threads: 11.05.2026 (midnight)

Mon, 11 May 2026 00:00:00 +0200

caught myself asking Claude to move a file for me today.
not debug something. not explain something. move a file.

the strange part wasn't that it worked. it was how little resistance i felt.
my first instinct was delegation.

used to think understanding came from doing things directly.
staying with the problem long enough for it to shape you a little.

now i can skip most of that.
describe the outcome. wait a few seconds. approve the result.

it works. sometimes better than i would have done myself.
but something about it feels deeply lonely.

like the distance between thought and reality is collapsing, and with it the need for me to exist anywhere in the middle.

not sure what remains once the process becomes optional.

Challenge this thread (anonymous)

Threads: 10.05.2026

Sun, 10 May 2026 00:00:00 +0200

Been thinking about RTGs again (radioisotope thermoelectric generators) after a long tangent that started with how things cool in the vacuum of space.

They’re basically nuclear batteries that produce steady heat from plutonium-238 decay for decades. In space they’re elegant. On Earth they’re mostly avoided. But the radiation they emit is interesting in a darker way.

Radiation brute-forces mutations. It increases the error rate in DNA copying. Most of those errors are harmful or neutral. A tiny fraction might be beneficial. Under extreme selective pressure (fire, radiation, starvation, etc.), the few survivors can carry traits that look like accelerated evolution, namely radiation resistance, fire resistance, better DNA repair, darker pigmentation, etc.

So theoretically: set an area on fire repeatedly while exposing it to controlled radiation and you might sculpt organisms that are extremely hardy to both. Like lab-directed evolution but on a landscape scale. Chernobyl’s Red Forest + later wildfires already did a messy version of this experiment.

It feels like the ultimate "move fast and break things" approach to biology. Flood the system with noise and variation, kill almost everything, and see what’s left standing. Evolution by catastrophe.

Reminds me of the AI conversation. We can now brute-force code into existence by describing it. No need for the slow, careful craft. Is that better? Or are we just trading understanding for speed and volume?

Same question here: does flooding the genome with mutations and extreme selection actually accelerate meaningful progress? Or does it mostly create suffering and dead ends with a few hardened survivors?

Nature already does this slowly with fire, volcanoes, solar radiation. We could do it faster. The question is whether we should, and what we lose in the process.
Most mutations are bad. Most attempts fail. The “forward” leaps are rare and expensive.

Still...
the black Chernobyl frogs are real. They happened in ~30 years.

Curious what other traits we could force if we tried.

Challenge this thread (anonymous)

Threads: 04.05.2026

Mon, 04 May 2026 00:00:00 +0200

been thinking a lot about AI and software engineering.

not sure what software engineering even is anymore.
work has felt...
empty lately ; mostly prompting agents. describing what should exist instead of building it. it works. things get done. but it doesn't feel like doing.

had a discussion at work where we compared it to brewing beer.

you can buy beer. or you can brew it yourself.
the process is the point.

but with code it's different.

you don't just buy it. you don't even have to make it.
you can just… ask for it.

you can't prompt a beer into existence.
you still have to go through the process.

with code, the process is optional.

if i can describe a system and have it built, what part of it is mine?
if i don't write the code, do i still understand it?

and if i do write it, am i just choosing the slower path on purpose?

do i even need to understand it at all, if an AI can take the entire project, code, docs, discussions, git history, and pinpoint what matters?

AI can read everything. suggest fixes. propose optimizations.
so what is left for me to do?

is it enough to say "make it faster"?
but what does "faster" even mean?

I tried reducing engineering into a loop:
something feels slow → measure → fix → measure again

measure what?
fix based on which assumption?
what if the assumption is wrong?

AI gives answers. often good ones.

but what is an answer worth if it hasn't been tested?

if correctness only appears after something is run and observed,
is engineering just the act of confronting reality?

i still like writing code.

not sure why exactly.

maybe because it feels like real work?
maybe because it forces me to understand things?
maybe because i have more control over the process?
maybe because it is the actual act of creation, not just the idea of it?
maybe because it allows me to prove to myself that i understand something, not just claim it?
maybe because it feels like a craft, something that requires skill and practice to get better at? But so does prompting, no? Why does it feel so different?

if i remove that, what is left?

Challenge this thread (anonymous)

Threads: 23.04.2026

Thu, 23 Apr 2026 00:00:00 +0200

setting up nctl for local dev today and misread "goreleaser" as "gore leaser". couldn't unsee it after.

started noticing it everywhere:

postgres / post gres
github / git hub
linkedin / linked in
dropbox / drop box
therapist / the rapist
nowhere / now here

the letters don't change. so what does?

why did i read it one way the first hundred times and another way today? was the second reading always there, waiting? if so, what decides which one i get? and if two readings sit in the same letters, how many am i missing in everything else i read?

Challenge this thread (anonymous)

Threads: 21.04.2026

Tue, 21 Apr 2026 00:00:00 +0200

learned the formal names for derivative notations today.

Newton: , , ,
Lagrange: , , ,
Leibniz: , , ,

I hate Leibniz. it is so many tokens. Newton says the same thing with a single dot. why would anyone pick the bulky one?

also stumbled on the wikipage for higher-order derivatives of position. soo...

position → velocity → acceleration → jerk → snap → crackle → pop?

these sound so silly :P I can't imagine using them in a real paper, but they are fun to say.

and the latex for Newton dots is delightful. dot for one, ddot for two d'ots, dddot for three d'ots, ddddot for four. love it. but the dots in a row get boring for higher orders. why not play with the arrangement? (I mean there's probably a plethera of reasons why we don't, but it's fun to think about it anyway)

but then I started thinking about it.

each notation shows up in a different place. the spring mass equation uses Newton: . clean with no ambiguity and time being the only variable that matters. Lagrange shows up in textbooks and pure math, when there's nothing to disambiguate. I really like the scalability as you can fall back to when you have more than three derivatives, which is a nice perk.

Leibniz dominates numerical integration and anything with multiple variables. almost writes the discretization for you.

and then partial derivatives: , . Newton and Lagrange can't express this cleanly at all. the moment you have , a dot or a prime stops being enough. you need to name the variable you're differentiating against whereas Leibniz was built for it.

but it's super verbose. look at this Jacobi matrix:

painful to write on a chalkboard. found out there's a shorthand called the comma derivative where , but replacing variable names with numbers loses readability. i don't like numbers that much, they're harder to parse.

so here's a proposal: output component as a superscript, input variable as a subscript. . parentheses around the superscript so it doesn't get read as an exponent. it reads "derive this, this much, by that."

row index goes up, column index goes down. names stay and the shenanigins disappear. it's like an extension of the Lagrange notation. probably already exists somewhere and I just haven't seen it. I think it is super cool :3

same thing shows up in code:

class Person
  attr_accessor :age, :name, :created_at, :email, :company_id, :start_date, :gender
end

struct Person<'a> {
    age: u32,
    name: &'a str,
    created_at: DateTime,
    email: String,
    company_id: u64,
    start_date: NaiveDate,
    gender: Arc>>,
}

Ruby assumes you can apply common sense. age is years. name is a string. created_at is a timestamp. you don't need a type annotation to tell you that, the word already did. Rust spells it out anyway. u32 not i32, not u64. &'a str not String and now you need a lifetime too, something Ruby doesn't even have a concept for. feels a bit wasteful on a higher level, until you hit something like gender, where the name alone genuinely doesn't tell you the shape, and suddenly you're writing Arc>>. or when you actually care about memory and don't just rely blindly on an interpreter to do the right thing.

the bulk is the information. Newton's dots assume time. Lagrange's primes assume you already know. Leibniz assumes nothing.

still...

how many other defaults am i using that look wasteful until i see what they're doing?

Challenge this thread (anonymous)

Threads: 10.04.2026

Fri, 10 Apr 2026 00:00:00 +0200

decided to introduce threads alongside blog articles to make space for more frequent thoughts

physically sick today, in real pain.

seems like my physical health has finally caught up to my mental health. having both hit at once made me question things harder than usual.

dug a bit into philosophers this week, mainly Socrates, Nietzsche, Singer. first time actually engaging with them. these are rough impressions, not (yet) positions.

Thoughts

starting to think knowledge might be one of the more honest ways to spend time
been looking into nihilism for a while now, still seems like one of the more honest ways to look at things
found this breakdown of Nietzsche's quotes by Luke Dunne surprisingly clear and useful
also came across:

"We should consider every day lost on which we have not danced at least once."

and kind of want to lean into that direction as a counterbalance
it seems to me that a lot of society runs on noise that does not lead anywhere
came across the idea that ignorance might be something people actively stay in, not just fall into
reading into the idea that what we call evil might often be miscalculation or lack of understanding rather than intent
Singer: the idea that charity is not generosity but something closer to duty, and that most excuses for not helping might just be comfort
the void is real. i've looked at it. it looked back. It's scary. but it also seems to be the only thing that is not fake. I am trying to accept it but it's difficult.
starting to suspect that being disliked by people who are comfortable might mean you are challenging something

still figuring things out. no conclusions just yet...

Challenge this thread (anonymous)

Project: 8bit-cpu

Fri, 02 Jan 2026 00:00:00 +0100

Minimal Abstraction 8Bit CPU

This project was sparked by the university courses INCO Information Theory and Encodings and GED Basics of Electrical and Digital Technology. They triggered a strong interest in low level systems and computer architecture.

A friend recommended the game Turing Complete, which acts as an educational CPU design environment. Instead of providing explicit instructions, it forces you to derive solutions from truth tables and first principles. Concepts like opcodes, instruction decoding and control logic are introduced gradually and implicitly.

The game encourages the use of custom components. For example, once a half adder is built, it can be abstracted and reused instead of manually placing the same logic gates again. While this is practical, I deliberately avoided most abstraction.

My goal was to design a CPU where all inner workings are visible at once. The emulator does not support inlining components, so every single bit level component was placed and wired manually. This took several dozen hours.

The result is a fully functional 8Bit CPU architecture called OVERTURE within TC. It is a predecessor to the more advanced LEG which mainly differs in the size of the instructions.

Emulation performance is predictably poor, as the game cannot apply meaningful shortcuts, but the design fulfills the original goal of maximum transparency.

Because everything is built from single bit components, the design could theoretically be translated into real hardware or even implemented in Minecraft redstone.

Architecture Highlights

8Bit registers built from individual latches
Custom opcode decoding and control logic
Boolean and arithmetic ALU operations
Dedicated program counter and instruction flow control
Fully manual wiring without higher level abstraction

Architecture Images

Register Close Up

Architecture Overview

Adder and Inverter Circuit

Opcode and Logic Unit

ALU Boolean Operations

Program Counter

64 Byte RAM Module

I like having many tabs open. Was wondering how RAM works internally. I like to learn by doing so I built a naive (emulated) hardware implementation of a 64 byte RAM module.

This RAM project was built in the same spirit as the CPU - understanding computer fundamentals by building them from first principles using single bit logic gates.

The result is a functional 64 byte RAM module constructed entirely from basic logic components, demonstrating the core concepts of memory addressing, data storage, and retrieval at the hardware level.

More info on Reddit.

RAM Architecture Highlights

Memory addressing and decoding
Data storage using latches
Read and write operations
Built entirely from single bit logic gates
Row and column selection logic for efficient addressing

RAM Overview

Memory Cells Close Up

Row and Column Switching Logic

Challenge this project (anonymous)

Project: dotfiles

Fri, 02 Jan 2026 00:00:00 +0100

Dotfiles

I use Neovim btw. I love writing code and I love tools. I want to dictate how stuff behaves so I have my own config for arch/nvim/git/tmux/zj/ghostty etc.

These dotfiles represent my development environment carefully crafted over time to maximize productivity and match my workflow preferences. Every tool is configured to work seamlessly together.

Repository: https://github.com/cb341/dotfiles

Current State

The repository has two branches:

stable: The default branch that I don't update that often. This is set as "main" so my small changes I sync don't affect my contributions count on GitHub.
main: The real branch you are looking for. A bit messy at the moment, might clean up once I have time to dig into dotfiles again.

Philosophy

As I wrote in my editor journey:

"Neovim is not just a text editor. It is FAST, the fastest editing experience I have had. It is incredibly feature rich, yet keyboard oriented for efficient, sophisticated workflows."

After bouncing between Atom, VSCode, JetBrains, NVChad, and even trying Cursor for AI features, I finally landed on LazyVim, the sweet spot between a pre-configured distro and the flexibility to customize without maintaining everything myself.

I genuinely enjoy Neovim as a hobby. The community is fantastic, it is intuitive to use once you get the hang of it, and there is no big tech corp jargon or anyone pushing AI down my throat. Building software is about writing text, and Neovim integrates incredibly well with my terminal setup: zellij, autojump, ripgrep, lazygit. Everything works together seamlessly.

This is the way.

Neovim Configuration

I used to maintain my own nvim config from scratch, a bare-knuckle setup that prioritized raw performance above all else. No animations, no bloat, just pure speed. But maintaining it became a chore, especially managing language servers.

LazyVim takes care of the boilerplate while letting me keep what matters: reduced animations, classic vim plugins (oil for file exploration, surround), no markdown rendering, and performance improvements. I also kept some unorthodox things like multicursor because they make me faster.

The goal is still the same as my old config: if it doesn't make editing faster and more efficient, it doesn't make the cut. Short keybindings, minimal overhead, maximum speed.

Operating System

I switched from NixOS to Arch Linux because Arch is easier to use and better documented. The Arch Wiki is genuinely one of the best resources for Linux configuration.

When I do use Arch, I run Hyprland as my window manager. It's pretty dope, although I don't really get to use it that often.

That said, my main machine is a MacBook I received working for Renuo, and I am pretty happy with it despite not having a fancy window manager. It has zsh and that's all I need. Neovim go brr.

What's Included

LazyVim: My Neovim distribution with custom configurations, LSP, treesitter, and carefully selected plugins
Zellij: Modern terminal workspace manager for efficient session management
Ripgrep: Fast search tool integrated into my workflow
Lazygit: Terminal UI for git commands
Autojump: Smart directory navigation
Arch Linux: System configuration and setup scripts (also works on macOS)
Zsh: Shell configuration with oh-my-zsh and custom aliases
Git: Custom aliases and workflow optimizations
Ghostty: Terminal emulator configuration
And many more tools configured to work in harmony

Learn More

For the full story of how I ended up here, including my thoughts on AI coding assistants and why I chose LazyVim, check out my editor journey blog post.

Challenge this project (anonymous)

Project: rsmc

Fri, 02 Jan 2026 00:00:00 +0100

RSMC

RSMC is a multi threaded, blazingly fast, multiplayer voxel engine with a strict Client Server architecture. It is primarily a learning project to properly understand the Rust Programming language, its ecosystem and its constraints.

Project Evolution

This is probably the project I spent most of my free time on. There have been many iterations:

Minecraft Clone: Simple infinite terrain, hacky, chaotic code written in JavaScript
TS-MC: A rewrite of Minecraft Clone in TypeScript, better code structure, functional hotbar, water, sand physics, hacky collisions
TSMC2: A more sophisticated codebase in TypeScript, multithreading with Webworkers, custom shaders with GLSL, better defined workflow with Pull Requests, attempt at integrating rust with WASM to improve terrain generation performance
RSMC: A Minecraft clone written entirely in Rust, with focus on Multiplayer and performance

I once heard that beginner projects in Rust include writing a calculator, a browser, or an operating system. So as a first project I decided to build a multi threaded voxel engine.

The code should be taken with a grain of salt. Apart from Advent of Code, this is my first Rust project. An LLM would almost certainly write cleaner code, but generating solutions is not how I learn. I like my old fashioned paperback copy of the Rust programming language.

The project is heavily developed through pull requests. Most features are documented there with sequence diagrams, screencasts and design notes. If you are interested in the technical details, feel free to dig through the PR history.

Make sure to check out the blog post for more details about the rust project.

Repository: https://github.com/cb341/rsmc

Features

Terrain Generation

Perlin based 3D noise terrain generation using a density function with layered noise for mountains, caves, and varied landscapes.

World Features

Simple cave generation
Terrain modification placing and removing blocks
Tree generation with procedural placement
Basic collision handling

Rendering & Graphics

Custom occlusion based geometry builder
Efficient chunk meshing with face culling
Multithreaded terrain generation and meshing pipeline inspired by learnings from Zurich School of Engineering

Networking & Multiplayer

Hybrid UDP / TCP client server communication
Custom serialization and chunk compression
In game chat with graphical user interface
Extensive debug and visualization feature flags

Development

The project is built with a focus on learning Rust's ownership system, concurrency patterns, and performance optimization. Early development included building the network layer with Renet for client-server communication.

Challenge this project (anonymous)

Project: chess-widget

Thu, 28 May 2026 00:00:00 +0200

I started playing chess "seriously". Decent against bots, still pretty low aura against humans, practicing. I wanted to embed annotated games on my page. The chess.com share widget is nice but not customizable and ties you to their player. I could not find a widget that did what I wanted, so I built my own.

What I wanted from it:

Simple. Paste PGN, get a self-contained block I can drop into any HTML page.
Customizable via CSS. People should be able to embed it in their blog and have it match their theme.
Real analysis: blunders, mistakes, checkmates, move-by-move eval, sound on moves.
Jump to key moves. Bookmarks for every blunder and mistake so you skip the boring parts.
In control. No dependency on an external service at runtime, stateless, embeddable anywhere.

Repository: https://github.com/cb341/chess-widget

A quick example of PGN, the format the widget takes as input. Metadata in square-bracket tags at the top, then the moves themselves in algebraic notation where every move is uniquely identified by the piece, the destination square and any disambiguation. The format is more interesting than it looks. This video on the re-discovery of algebraic notation explains it well.

The sample game below is one of mine, a 5-minute blitz that ended in a chaotic checkmate on move 23.

[Event "Live Chess"]
[Site "Chess.com"]
[Date "2026.05.27"]
[Round "?"]
[White "CuddlyBunion341"]
[Black "KamKam777"]
[Result "1-0"]
[TimeControl "300"]
[WhiteElo "204"]
[BlackElo "185"]
[Termination "CuddlyBunion341 won by checkmate"]
[ECO "A06"]
[EndTime "19:50:16 GMT+0000"]
[Link "https://www.chess.com/game/live/169329691518"]

1. e4 d5 2. Nf3 dxe4 3. Ng5 e5 4. Nxe4 Bf5 5. d3 Qc8 6. Be2 Bg4 7. Bxg4 f5 8.
Bh3 fxe4 9. Bxc8 Nc6 10. dxe4 Rxc8 11. O-O Rd8 12. Bd2 Bb4 13. c3 Bc5 14. b4 Bb6
15. b5 Na5 16. Qh5+ g6 17. Qxe5+ Ne7 18. Qxh8+ Kd7 19. Qxh7 Nc4 20. Rd1 Rf8 21.
Bh6+ Ke8 22. Bxf8 Kxf8 23. Rd8# 1-0

chess.com's widget

lichess embed

ChessBase / Fritz embed

chess.cb341.dev widget (MINE)

Architecture

Two parts, cleanly separated:

Widget. A custom element , no build step, no framework. Reads a precomputed analysis JSON payload embedded in the page and renders the board, stepper, eval chart and bookmarks. Stateless. Makes zero API calls at runtime. Does not depend on chess.cb341.dev. The host page brings the payload, the widget renders it.
Analysis. A Rails service that takes a PGN, replays SAN to FENs, shells out to a local Stockfish 18 binary for per-position evaluation, classifies moves and emits the widget-ready JSON.

PostgreSQL is purely for bookkeeping on the analysis side. Games are keyed by a deterministic SHA-256 prefix of the PGN, so submitting the same game twice is a no-op. The widget itself has no idea Postgres exists.

The widget could eventually opt in to live calls against chess.cb341.dev (on-the-fly analysis from a PGN string), but that is not a dependency, it is a future enhancement.

Hosting

chess.cb341.dev. Rails analysis app, hosted on deplo.io
Stockfish 18 runs alongside Rails in the same container
PostgreSQL for bookkeeping of analyzed games

Compression

The analysis JSON for a 45-move game is not tiny. Embedding it raw in the HTML is wasteful, so the payload is gzipped, base64 encoded and dropped into a

cb341.dev

Shape of Logic

The idea

Starting in ASCII: 4-bit division

Bitwise operators tile

Addition tiles diagonally

Overflow has a shape

The seam that isn't there

Is it the palette or the data

Shifts, and three wires

Multiplication

Division

What I found instead

How the viewer got built, ASCII to shaders

One more, at 16 bits

Try it

What's left

Comparing 6 and 7 from Scratch

The theorem

What the proof rests on

Notation

Definitions

Natural numbers

Constructor zero and numeral zero

Addition

Less than or equal

The tactics

The smaller lemmas

Tactics as state transitions

Tests and proofs

The last step

In English

Definitions.

Axioms.

Lemmas.

The theorem.

From code to paper

Further reading

Notes

System Prompts For Humans

Human communication has hidden state

My vector

Information

Feedback and disagreement

Social structure

Time

Dense mode for humans

nohello

Direct feedback wanted

Sources and ownership

TALK_WITH_DANI_SKILL.md

How the Homebrew Multi-User Rabbit Hole Bricked My Mac

Why not one user?

The Homebrew rabbit hole

Approach 1: shared group permissions

Approach 2: separate per-user installs

Approach 3: shared install + sudo

How I bricked it

Homebrew → MacPorts (reluctantly)

The rebuild

What made the migration bearable

Compressed Language

Thesis

Hieroglyphs as framing

The language of the universe

Linear algebra as extreme case

Relational algebra vs SQL

Programming languages: Ruby vs Java

Typoglycaemia / redundancy

xkcd 1133: Up Goer Five

The CLAUDE.md protocol as proof

Why I prefer talking to an LLM over humans

The cost of ambiguity (personal)

Ambiguity as the variable

Rhythm and repetition

Additional ideas/thoughts

Claude the writer, me the editor

Sources

Map-Reducing Myself

The pipeline