delta_p_delta_x

> Trains shouldn’t even be manually driven in 2026

Potentially, but the point is that signallers should physically be unable to allow trains to proceed, and drivers should physically not be able to override them. British signalling from the 1800s has physical interlocks; this isn't a matter of manual versus automatic train operation. It is clearly systemic.

> whether you could put a train from 1845 on a modern track

This quite literally happens all the time in the UK. There are heritage railways, and steam rolling stock regularly shows up on various routes as part of heritage rides.

On the other hand, I ride almost daily on a track bed that was laid almost 180 years ago, and through tunnels and on viaducts that are equally as old. The rails, sleepers, signals, and rolling stock have all changed, no doubt, but the base infrastructure is old hat.

The oldest bits of the London Underground are from 1863. The tunnels are exactly the same, the stations and stairways, and even some of the sign boards completely unchanged from then.

Railways are the epitome of forever infrastructure.

Cheers; we try, but I wish we didn't have a memory crunch to get this effort going. I suspect at the end of all this we will have more memory-efficient code.

> try promoting Claude to profile

Oh, the irony. Claude is itself an Electron app and lags horribly.

At this point, all these agent apps—Claude, Copilot, ChatGPT—are just calling remote APIs. Why not train them on the native toolkits for each OS (Win32/WinUI3, Cocoa/SwiftUI, GTK, Qt, Jetpack Compose), and make the experience better for users?

The app data directory on Windows is quite literally a subdirectory of the user directory; `%APPDATA%` == `%USERPROFILE%\AppData\Roaming`.

> I will never understand paying $50 for a font.

I will never understand people who expect fonts for free. They don't grow on trees. Font development is extremely involved, and I am happy to die on this particular elitist hill: the overwhelming majority of free fonts are absolutely rubbish, including the Liberation family, which is available by default on most Linux distros.

Any font that is free and is still reasonably good is almost certainly designed by a type foundry for a megacorp's branding and user interface (so, things like SF Pro, Segoe UI, Open/Noto Sans, Roboto, JetBrains Mono, IBM Plex, Source Sans, Fira Sans, Inter, etc), or are historic properties of the type foundries themselves, like Garamond, Helvetica, Didot, Minion, etc.

ASCII isn't the only set of characters. Just the LGK (Latin, Greek, Cyrillic) set of glyphs alone including combining marks, diacritics, contextual alternates and ligatures alone amount to several thousand glyphs, each of which has to be individually tuned for different weights, hinted for different display resolutions, hinted for RGB/BGR subpixel rendering, and more.

> our software would be written to deal with that

I work at a place which offers a well-known operating system and also sells hardware which runs said OS. This is exactly what we have done, because the hardware releases this year have had to come with a quarter less memory. There is an internal effort to reduce memory consumption by a quarter at all levels of the platform, from the kernel, to the drivers and user-mode libraries, to the toolkits and user-mode applications. This has been remarkably successful.

By 'impossible', I mean it in a very strict sense of blitting full-screen frames directly into the framebuffers provided by HDMI or (e)DP representing a visible surface. This is still kind of possible in Windows when games are properly full screen and not 'borderless full screen', but the OS still does compositing in the background, and the GPU is still involved to some extent.

Of course, offline rendering is a different story.

Indeed. Personally I am quite old-school, I like MSAA (despite the performance hit) and subpixel morphological AA (SMAA, used to great effect in Crysis). DLSS is interesting but I cannot unsee the artifacts.

> If you mean that this style can be achieved with graphics hardware

I really ought to have been more specific with my first sentence to ward off any hair-splitting.

The author claimed to love software rendering, but the examples given to highlight the supposed positives of software rendering can all be achieved on GPUs. If the author had instead highlighted the ability to easily debug and inspect the inner workings of the rasterisation pipeline with a software renderer, that might have been a much more relevant argument.

I've mentioned this elsewhere, but nowadays, anything you see out of an HDMI/DP/eDP cable comes out of a GPU. Modern OSs make it impossible to do 'software rendering' any more; it's just that much faster and that much more efficient, even if it is harder to program directly. Even IPMI BMCs have a tiny GPU doing stuff.

This isn't software rendering, it's called turning off spatial anti-aliasing. You can still do that in the modernest of modern games. Software rendering went out of the window because the CPU tends to have other things to do whilst playing the game besides only multiplying 4x4 matrices, which was shifted to the shader cores of GPUs. The look-and-feel that the author is discussing including shadow and texture LUTs can also be done on GPUs by passing the tables in to shaders as constant read-only storage buffers; that is not specific to software rendering. It bears mentioning that many modern software renderers (LLVMpipe/Lavapipe, OpenSWR, WARP) are basically full D3D/OpenGL/Vulkan devices in their own right, including shader compilers.

Also, modern spatial anti-aliasing works by multisampling within a pixel (or even neighbouring pixels) and taking the average, rather than filtering across singly-sampled pixels, which massively reduces the quality. Not to mention temporal and machine learning AA techniques including DLSS, XeSS, FSR, and all the TAA implementations in many games.