Firmware you can flash
Prefer hardware with a supported OpenWrt target, documented recovery mode and a serial header. If you cannot get back in after a bad image, it is not yours.
1024 text colours
1024 of them — 128 families × 8 weights: 1 is the strongest, 8 the softest. Each one is solved for the background it is used on, so it stays legible on white and on black. The list is in four sections: Neutral, Spectrum, Named and Flat.
1024 colour schemes
1024 of them — 128 families × 8 depths: depths 1–4 are light pages, 5–8 dark ones, and the family called Plain is white, greys and black. The Spectrum families are thirty-three evenly spaced stops around the hue circle, the Named ones are the everyday colours between them, and the Flat ones — tinta unita — are those same colours kept at full strength, mixed with nothing but white or black. A scheme’s colour is the same hue at every depth, only lighter or darker.
1024 typefaces
1024 typefaces — as many as the colour schemes, and chosen the same way: a long list rather than a short one, ranked by how much the web actually uses them. Every one is self-hosted, latin only, one file each, and open source. They are sorted into five sections — Sans Serif, Serif, Display, Handwriting and Monospace — and each row draws itself in its own face only once it is on screen, so opening this panel costs nothing and a typeface can never slow a page down.
Track 01 · Networking
Consumer routers hide everything behind a glossy app; enterprise kit hides it behind a licence. The open path sits in between: OpenWrt on replaceable hardware, standard routing daemons, WireGuard where the link is untrusted, and queue management that keeps latency low while the link is saturated.
Principles
Everything below follows from these. When a product violates one of them, we look for another product.
Prefer hardware with a supported OpenWrt target, documented recovery mode and a serial header. If you cannot get back in after a bad image, it is not yours.
One plan, written down, applied everywhere. VLAN per trust level, not per device. Static where it is infrastructure, DHCP with reservations for everything else.
Throughput benchmarks hide queueing. Shape the uplink with CAKE so a large upload does not turn a video call into a slideshow.
Encrypt across any network you do not own. Overlay routing between sites beats trusting a hotel, a venue or a carrier CPE.
Open hardware
Networking is where open hardware pays off fastest: a router is a small computer, and a small computer with published schematics, a mainline kernel target and a recovery header can stay in service for a decade. The alternative is a sealed box that stops receiving updates while it is still perfectly capable of routing packets.
The first router board designed by the OpenWrt project itself, built with Banana Pi. Published design, a mainline OpenWrt target, and recovery designed in so a bad image is an inconvenience rather than a brick.
Open hardware from CZ.NIC with an OpenWrt-based system, automatic signed updates and a modular layout. You can move the radios to a different position than the CPU, which is a genuine engineering advantage.
Fanless x86 with published schematics, coreboot firmware and multiple independent NICs. No Wi-Fi and no case included, which is exactly why it is a good router rather than a good appliance.
Dual and triple Ethernet single-board routers with published designs. Excellent value, provided you confirm the kernel version and how many firmware blobs a given board actually needs before you commit.
Prefer radios with open drivers — mt76 and the ath family —
and be aware that many Wi-Fi chips need a firmware blob. Fully blob-free operation
is possible, but check the model, not the brand.
Open Compute Project switch designs paired with open network operating systems. Loud, deep and power-hungry, but a real switch you can rebuild and reflash instead of a sealed appliance.
| Platform | Class | How open | The catch |
|---|---|---|---|
| OpenWrt One | Wi-Fi 6 router board | Published design, mainline target, recovery built in | Two ports; it routes, it is not a switch |
| Turris Omnia / MOX | Wi-Fi router / modular node | Open hardware, open OS, signed automatic updates | Higher price, limited regional supply |
| PC Engines APU | Fanless x86 router | Schematics published, coreboot, three GbE ports | No Wi-Fi, no case, needs a radio card |
| Banana Pi BPI-R3 / R4 | SBC router | Design files published, mainline support varies by revision | Confirm blob count and kernel support for your revision |
| LibreRouter | Outdoor mesh node | Open hardware plus LibreMesh firmware | Low-volume supply; plan spares |
| Wedge / Edgecore with SONiC | Datacentre switch | OCP hardware, open network OS | Noisy, deep, drawn from a different league of power |
| Intel i210, Mellanox ConnectX | Server NIC | Free drivers in mainline, public datasheets | Auction-site cards are frequently counterfeit |
1. Are the schematics published? 2. Is there a mainline kernel or OpenWrt target, and which version? 3. How many firmware blobs does it need, and for what? 4. Can you reach a recovery console without a proprietary tool? 5. Does the vendor still ship security updates, with a verifiable policy? 6. Will the optical or PoE ports accept third-party modules, or is there an EEPROM allow-list?
Reference build
A fanless x86 or ARM router, a managed switch with PoE, a UPS that reports its own state, and a patch panel with labels that survive a decade. This is the smallest setup that still lets you segment traffic, run services and survive an outage.
Two or more independent network interfaces, a supported OpenWrt target, and enough RAM for your routing table. Avoid USB Ethernet for the WAN side.
Define the VLANs first — management, trusted, wireless, services, guests. The switch configuration is a consequence of the plan, never the other way around.
Same identifier at patch panel and device. Document the port map in the repository, not on a sticky note on the rack door.
Connect the UPS over USB and expose it to your monitoring. An outage you learn about from the graph is an outage you can explain.
A backup you have never restored is a hypothesis. Wipe the router, restore the archive, confirm the network comes back.
Anything that requires a cloud account to complete setup, any router whose recovery path is a proprietary Windows utility, and switches that cannot report per-port counters over SNMP or a documented API.
Planning
Use a private range wide enough for room to grow, and encode meaning in the third
octet. The example below assumes 10.20.0.0/16 as the site prefix.
| VLAN | Name | Prefix | Gateway | What lives here |
|---|---|---|---|---|
| 10 | mgmt | 10.20.10.0/24 | .1 | Switch, router, UPS, BMCs — no internet except updates |
| 20 | trusted | 10.20.20.0/24 | .1 | Workstations and laptops you administer |
| 30 | services | 10.20.30.0/24 | .1 | Servers, NAS, backups, monitoring |
| 40 | wireless | 10.20.40.0/24 | .1 | Phones, TVs, appliances — treated as untrusted |
| 50 | studio | 10.20.50.0/24 | .1 | Audio and video endpoints needing stable latency |
| 99 | guest | 10.20.99.0/24 | .1 | Visitors, isolated, rate-limited |
| — | transit | 10.20.255.0/30 | — | Point-to-point links and overlay endpoints |
A one-page text file in version control beats an evening of guessing which address is free. Include the DHCP reservation list, the firewall intent per VLAN, and the date you last verified that the running configuration matches the document.
Budgeting
Latency budgets are how you decide whether a problem is the network's fault. Measure each hop, write the number down, and compare against the budget instead of against a feeling. The figures below are typical orders of magnitude, not promises.
| Segment | Typical added latency | Dominant cause |
|---|---|---|
| Wired LAN, idle | under 0.3 ms | Switch store-and-forward |
| Wired LAN, saturated | 1–20 ms | Bufferbloat without shaping |
| Wi-Fi, good signal | 2–8 ms | Contention and retries |
| WireGuard over WAN | 0.5–3 ms | CPU encryption cost |
| Metro fibre | 1–5 ms | Propagation plus switching |
| Cross-continent | 60–150 ms | Speed of light in glass |
Configuration
# /etc/config/network (OpenWrt) — overlay between two sites
config interface 'wg0'
option proto 'wireguard'
option private_key 'REDACTED'
option listen_port '51820'
list addresses '10.20.255.1/30'
option mtu '1420'
config wireguard_wg0
option description 'site-b'
option public_key 'REDACTED'
option route_allowed_ips '1'
list allowed_ips '10.20.255.2/32'
list allowed_ips '10.21.0.0/16'
option persistent_keepalive '25'
Keep MTU below the tunnel overhead; 1420 is a safe starting point on a
1500-byte path. Persistent keepalive is only needed behind NAT on one side.
# Keep the uplink responsive while saturated.
# Set the bandwidth to ~85-95% of the measured uplink.
tc qdisc replace dev eth0 root cake \
bandwidth 90Mbit \
dual-dsthost dual-srchost \
nat \
diffserv4 \
ack-filter
# Verify what the kernel actually installed:
tc -s qdisc show dev eth0
Shaping only helps on the bottleneck link you control. Shape the uplink on your router and, if your ISP supports it, borrow their downstream shaper via RFC 8289-style tags or a supported AQM profile.
Open audio over IP
Audio over IP is the place where the networking and sound tracks meet. The good news is that the open route exists and interoperates: AES67 describes how to move uncompressed audio in RTP with PTP clocking, and open implementations are available on Linux today. The catch is that networked audio is unforgiving — clocking, latency and multicast are not optional refinements, they are the whole problem.
| Approach | Status | Clocking | Open implementation | Best for |
|---|---|---|---|---|
| AES67 | Open interoperability standard | PTP, IEEE 1588 | PipeWire RTP modules, module-rtp-sap |
Mixing brands of professional gear on one wire |
| RAVENNA | RTP-based, AES67-compatible | PTP | Reached from Linux through AES67 mode | Broadcast, high channel counts |
| AVB / Milan | Open IEEE 802.1 standards with TSN | gPTP, IEEE 802.1AS | Partial Linux support; needs AVB-capable NIC and switch | Deterministic layer 2 in installed venues |
| Dante | Proprietary ecosystem | Vendor PTP profile | None; interop only where a device offers AES67 mode | The commercial default — plan an exit path |
| NetJack | JACK-specific, not a standard | JACK transport | jackd -d net, GPL |
A quick LAN link between two JACK machines |
| Snapcast | Open, purpose-built | NTP-style sync | GPL server and clients | Multiroom playback, not low-latency work |
| SRT | Open protocol, MPL-2.0 | Timestamps, retransmission | libsrt, FFmpeg, GStreamer |
Contribution over a lossy WAN link |
| RTP-MIDI | Open standard, RFC 6295 | Session timestamps | rtpMIDI, jackrtpmidi |
Control and MIDI across the network |
| NDI | Proprietary SDK | Not applicable | No open implementation of the core | Video-first workflows where the ecosystem decides |
Method
PTP provides the reference; do not let every device free-run and hope. If your audio hardware also has a word-clock input, keep that hierarchy consistent with the PTP hierarchy instead of creating two competing authorities.
Software timestamping adds jitter that no buffer setting can remove. Check with
ethtool -T and pick a NIC that reports hardware transmit and receive
timestamping.
Put audio in a dedicated VLAN, mark it DSCP EF, and make the switch trust those markings. Never let a backup job share a queue with a live stream.
AES67 is comfortable at about 1 ms of network latency at 48 kHz — 48 samples per channel — and many devices also offer 125 µs to 250 µs packet times. Decide the target, then size buffers to meet it rather than guessing.
Use a loopback measurement, not your ears. jack_iodelay reports
actual round-trip latency, and pw-top shows whether the graph is
keeping up or quietly dropping cycles.
Configuration
# Clocking. One grandmaster, everyone else slave-only.
ptp4l -i eno1 -f /etc/ptp4l.conf -m # grandmaster
ptp4l -i eno1 -s -m # slaves: -s = slave only
phc2sys -s eno1 -c CLOCK_REALTIME -w -m # align the system clock
# Confirm the NIC timestamps in hardware, not in software.
ethtool -T eno1
# Energy-efficient Ethernet adds latency and drops packets.
ethtool --set-eee eno1 eee off
# ~/.config/pipewire/pipewire.conf.d/20-aes67.conf
# Argument names have changed between PipeWire releases —
# check the module documentation for the version you run.
context.modules = [
{ name = libpipewire-module-rtp-sap
args = {
local.ifname = "eno1"
sap.ip = "239.255.255.255"
sap.port = 9875
net.mtu = 1500
sess.latency.msec = 1
audio.format = "S24LE"
audio.rate = 48000
audio.channels = 8
source.ip = "10.20.50.10"
source.props = {
node.name = "aes67-output"
node.description = "AES67 8-channel output"
}
}
}
]
Restart the PipeWire daemon, then confirm the node appears with
pw-link -o or pw-cli ls Node. If the stream is silent,
check multicast group membership and the switch's IGMP snooping configuration before
touching the audio settings.
You rarely get to choose the whole ecosystem. Many commercial audio-over-IP devices offer an AES67 mode precisely so they can be bridged, which makes the open standard your practical escape hatch: keep the proprietary gear where it already is, and bring your own machines in over AES67 rather than buying into a parallel proprietary stack. Document the mode, the latency setting and the clock role for each device, because that configuration is exactly what gets forgotten after a firmware update.
Toolchain
All of it is open source, packaged by mainstream distributions, and replaceable.
A full Linux distribution for routers, with an image builder for reproducible firmware. Config lives in text files, so the whole router is version-controllable.
Routing daemons that speak BGP, OSPF and IS-IS the same way the big routers do. Useful the moment you have a second uplink or a second site.
Small, fast, auditable, and in the mainline kernel since 5.6. Route-based tunnels mean you use the ordinary Linux routing table instead of a custom stack.
Queue management that keeps latency bounded under load. One line of tc fixes the most common complaint about home and studio uplinks.
Layer-2 mesh for buildings where cabling is impossible. Design for wired backhaul first; treat wireless backhaul as the compromise it is.
Scrape SNMP and node exporters, alert on what matters: link errors, queue drops, UPS on battery, certificate expiry.
Wireless throughput claims are almost always measured under ideal conditions with a single client. Treat marketing numbers as a ceiling, expect roughly half in a real building, and measure your own environment before designing around a figure. Likewise, a VPN adds CPU load: on a small router, run a throughput test with the tunnel up before you commit to routing all traffic through it.
Next
Once the transport behaves, the interesting problems move up the stack: keeping clocks aligned for audio, and keeping colour consistent for graphics.