Mike (VK1OMG) 🏴☠️
Ah crap, Raylib update. On a Friday. Before a long weekend.
What could go wrong?
- **AI-generated code and cognitive debt**: Discussions on AI tools like Claude Code and GitHub Copilot generating low-quality or insecure code, leading to "cognitive debt" and technical debt in software projects. - **Updates to programming tools**: Releases like TypeScript 7.0 Beta (10x faster), HTMLview.mcc 13.6 for Amiga, and ham_convert 1.12.2 for Amiga HAM format conversion. - **Retro computing and niche tools**: Open-source projects like HTMLview for Amiga, ham_convert for graphics, and Windows 9x Subsystem for Linux gaining attention. - **AI agents and automation**: Tools like Zed’s parallel agents, Broccoli (one-shot coding agent), and Open Coding Agents for repo adaptation being shared and discussed. - **Linux and open-source updates**: Ubuntu’s adoption of uutils coreutils, Debian dropping GHDL builds, and NetBSD’s ongoing development and bug fixes. - **Conferences and events**: LinuxFest Northwest (LFNW), DjangoCon US, PyCon Sweden, and ElixirConf EU announcements and recaps.
Updated:
Ah crap, Raylib update. On a Friday. Before a long weekend.
What could go wrong?
Does anyone know of any #FOSS or open web adjacent conferences in the #UK this year that are looking for people to give talks? I'd love to do a talk about my #11tyCMS project! #Programming boosts welcome!
Day 1/90: C++ setup & environment
Today's note was about getting a clean C++ toolchain into place before the codebase gets complicated. I kept coming back to the same checks: compiler choice and standard flags, editor or IDE integration, and a build command that works every time.
The failure mode worth watching is treating the toolchain as disposable and relearning the same compiler setup every week. If that happens, the implementation starts looking busy while the actual boundary is already gone.
Programming using llms feels extremely sad and lame; once you figure out how to use them correctly, instead of mindlessly vibecoding you split a problem into small modules, solve the logic yourself and only let the model solve one function at a time, it actually can build a program correctly.
But any sense of achievement is gone, it feels like participating on a running marathon using a motorcycle, you reach the goal but you are cheating, instead of coding the job turns into only been a supervisor, "this part is right" "this part is wrong", copy and paste, repeat. Boring, why are we doing this? what's the point of everything? why should I even work at anything if stuff can now solve itself, and it's only getting worse, the future looks bleak
Reflection on coding with LLMs
i no longer have a phlog. too webby.
gopher started like a library software. menus as shelves, card
catalog at the door. that's the idea
wrote bartleby to use it that way. drop .bcard files next to your
stuff, it walks the directory and builds a catalog for gopher.
no markdown, no templates, doesn't mess with your text
gopher://gopher.someodd.zip/1/library/
Software project description
Day 1/90: Rust setup and cargo basics
Today's note was about getting the Rust toolchain and Cargo workflow into a repeatable state from the first run. I kept coming back to the same checks: toolchain installation and versions, cargo commands that form the daily loop, and crate layout that will survive later refactors.
The failure mode worth watching is treating the Cargo layout as disposable and rebuilding the same skeleton every week. If that happens, the implementation starts looking busy while the actual boundary is already gone.
TorchTPU: Running PyTorch Natively on TPUs at Google Scale
L: https://developers.googleblog.com/torchtpu-running-pytorch-natively-on-tpus-at-google-scale/
C: https://news.ycombinator.com/item?id=47881786
posted on 2026.04.23 at 16:53:27 (c=0, p=5)
[PT-BR] #Kubectl: boas práticas
Boas práticas para usar o #kubectl de forma eficiente e segura: Use contextos e namespaces de forma... https://dev.to/cedon/pt-br-kubectl-boas-praticas-462j
Kubernetes best practices article
Day 1/90: Go setup and first program
Today's note was about building a Go workspace that is small, predictable, and easy to run from day one. I kept coming back to the same checks: keep the module layout simple enough that package boundaries stay obvious, use go run, go test, and go mod commands as part of the daily feedback loop instead of as afterthoughts, and treat the project shape as something future features must survive, not something to redo every week.
The failure mode worth watching is treating project shape as disposable and rebuilding the same skeleton every week. If that happens, the implementation usually looks busy while the actual service boundary is already gone.
❌ Tried to figure out 1 clean format to use for MySQL and MariaDB to cleanly backup and restore all new backups and there is no clean way lol
✅ Found the cause for a long-standing local development issue where apt and apk package downloads where failing - its was my VPN
✅ Did a lot more research and planning about how to cleanly and consistently name and store the new backups with the signature and manifest file
🩹 Health
❌ Skipped my walk
Backup issues, package manager debugging
2026 Development Log 68 🚀
👨🍳 Core Coolify Development
✅ Continued my backup PR development and finalized the new Postgres backup and restore commands
✅ Finished reading over 4+ Postgres docs pages covering all backup options and which newly available options we should also include
✅ Read over all MySQL and MariaDB docs pages for all backup options and which new options we should use for all future backups, and it is a mess
Database backup development log
Day 1/90: C# setup and .NET environment
Today's note was about getting the .NET workspace into a repeatable state from the first run. I kept coming back to the same checks: solution and project layout, repeatable build and test commands, and defaults that future code can live with.
The failure mode worth watching is treating solution shape as disposable and rebuilding the same skeleton every week. If that happens, the implementation starts looking busy while the actual boundary is already gone.
doc: CHANGES-2026
morr: doc: Updated editors/vim-share to 9.2.0390
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/doc/CHANGES-2026.diff?r1=1.2549&r2=1.2550
editors/vim-share: PLIST distinfo version.mk
morr: Update to version 9.2.0390.
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/editors/vim-share/PLIST.diff?r1=1.86&r2=1.87
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/editors/vim-share/distinfo.diff?r1=1.230&r2=1.231
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/editors/vim-share/version.mk.diff?r1=1.166&r2=1.167
[PT-BR] Kubectl: boas práticas
Boas práticas para usar o kubectl de forma eficiente e segura: Use contextos e namespaces de forma... https://dev.to/cedon/pt-br-kubectl-boas-praticas-462j
kubectl best practices for developers
Day 1/90: Java setup & environment
Today's note was about getting the JDK, IDE, and build workflow into a repeatable state from the first run. I kept coming back to the same checks: module and package layout, repeatable build and test commands, and defaults that future code can live with.
The failure mode worth watching is treating solution shape as disposable and rebuilding the same skeleton every week. If that happens, the implementation starts looking busy while the actual boundary is already gone.
Day 1/90: TypeScript setup and first types
The useful shift today was making the TypeScript setup pay off immediately. I kept the lesson tied to three checks: turn strictness on for a reason and know which category of bug each flag is buying down, separate source layout, build output, and path aliases before the project gets busy, and keep the toolchain small enough that a new teammate can explain it without opening six config files.
The mistake worth catching early is treating tsconfig like a bag of copied defaults instead of engineering policy. Once that slips through, the type layer usually becomes descriptive instead of protective.
So... today I discovered #Jython. And I found out you can make applets with it.
:thonk: 🐍
It's bed decades since I last wrote anything in #Commmodore assemby, and the first time I wrote one on the #Commmodore16 / #Plus4. Amazed it worked, even if it only used standard kernel routines.
The economics of software development have flipped. Anirudh Ramanathan explains why producing code is now fast, but validating it through CI remains a constraint teams can’t ignore.
Economics programming article