What do you mean by “not optimized enough“?
Binaries created with Free Pascal Compiler are very small, compilation time is super fast and runtime performance was never an issue for the typical system/userland programs. I think in many ways on par or ahead of other mainstream system programming languages.
You are not alone - my first thought was 'oh, HN is trying to bring back the disappointed hackers'. All this AI hype over every little model update fart is so exhausting and boring …
It was common knowledge, though not for most of those (with some exceptions like legacy gaming fans) coming into the PC world much after the early 2000s.
Terminate but Stay Resident was the original DOS function call to allow a utility program to exit but stay in memory waiting for interrupt signals (it will have hooked into those interrupts before calling TSR) to respond to. Utilities that operated in this manner (mouse drivers, and many other useful things) became collectively known as TSR programs and then just TSRs.
There were later other methods of leaving code resident, implemented by various memory managers for background tools that needed to use RAM outside the first 1MB (which in reality meant outside the first 640KB because of how the PC memory map was arranged), but the name TSR stuck to cover them generally.
DOS programs generally were like command line apps today (but simpler, obviously). They did a thing, then exited. Or they showed their "TUI" (as we'd call it today), and when you told it to exit, you got back to the DOS prompt to start the next program.
TSRs were a special kind of program, that instead of telling DOS "I'm done, here's my memory back", said "I'm done for now, but don't unload me", so their memory stayed allocated/used. And you got your command prompt back immediately to continue your work.
TSRs usually hooked into an interrupt like the keyboard interrupt, intercepting a hotkey to re-activate the program (so you could browse your address book while you were in your (text mode) word processor; "kind-of" multitasking), or they offered a service to other programs (like the mouse and CD-ROM drivers).
There were all kinds of things that ran as TSRs. Virus scanners (hooking into disk write/reads), modem tools (showing "RING" in the corner of the screen when the modem detected an incoming call), note-taking apps, address books, you name it.
To expand upon this - the TSR programs stayed in memory after being loaded. Typical use were drivers, for example mouse driver. It loaded, hooked itself in the interrupt table and then exited back to DOS prompt. And this gave you mouse support for other programs.
it'll all be centralized models justifying their capability against local inference in, maybe 3 years or less
once we have a bit more memory fab capacity and the insane bottomless investment in AI giants realizes there is a bottom, local hardware will catch up with model performance to the extent that centralized inference will be downgraded to special cases or for orgs that find it cheaper than buying expensive hardware
but really most power users are going to have 1 TB unified RAM and local models that will do well enough
for light office use you can still have a cheap laptop and a claude subscription
This is really astonishing. Are there no checks and balances in place for design decision in such a critical system component? What were the thoughts of all the major distros when they decided to go with systemd then?
systemd was funded and implemented by the biggest commercial distro, Red Hat, first. Other distros were influenced by its decision (RH has always had a lot of influence on distro direction generally) and followed suit.
I’m not sure Red Hat ever had a lot of database design expertise internally and that probably explains the design and outcome. As I said earlier, the design was not subject to public scrutiny before it was implemented.
reply