What if the Clients are Smart
I've usually considered two levels of security for a network, a higher level for servers and a slightly lower for clients. For example, all servers might be on a Kerberos domain with AFS, etc. with a paid support version of UNIX like Ubuntu Pro as described in a previous post. Clients could be a random, "best effort" security collection of Linux, macOS, other BSD & Windows machines. But there's no particular reason for this split, especially if macOS & Windows are excluded (e.g. for computation sovereignty reasons). Every network host could have the same security configuration.
This has implications, e.g. I used to assume there was a requirement for a simpler filesystem layer making AFS look like a WebDAV share. But it may be better to just have everyone use AFS. This doesn't exclude use of end-user apps like LibreOffice.
How to set up a distributed Linux environment
However, there is still a need for a "bespoke app platform" kind of software. Obviously the world uses Web tech for this now, but unfortunately it has turned into something only programmable by professionals. There are a few ways to go from here. Also, the rest of this post is really for general office automation work. For (possibly domain-specific) software development, once you're working with source code a tool like Fossil is the right choice. This then brings up the question if a lot of GUI apps would be more efficiently expressed as source code, e.g. accounting->GNU Ledger; AutoCAD->OpenSCAD; Digital Audio Workbench->CSound; word processor->Markdown.
My favourite SCM tool
Local-first & Offline-first Apps
An explicit strategy to push such apps hard would, I suspect, actually satisfy a lot of customer requirements. Assuming an Ada shop, the standard library is quite complete so designs shouldn't require many dependencies beyond the florist & ncursesada libraries and SQLite. I'm assuming that RAM prices continue to increase forcing text user interfaces to come back in vogue, which ncursesada is fine for. The "Simple Components" library is the only possible exception here, it may be useful enough to pay for itself, especially its SQLite interfacing layer.
A simple object database built on SQLite
If collaboration over AFS (possibly with communication tools like IRC, email) is insufficient, we probably have to use one of the next two options.
Simplified Web Dev
This isn't my first choice, in particular it's difficult to see how it can work in a world of expensive RAM. Here are some ideas for how to do it anyway. I would tolerate slightly clumsy interfaces in return for ease of development. I hypothesize that a stack containing "missing", "htmz" and SQLite is easier. There are gaps here for the language to use for significant code in the browser *iff* this is required (Oberon?) and server (Ada?).
"The Missing CSS Stylesheet"
htmz, "a low power tool for html"
Oberon to Javascript translator
An Ada HTTP Server
LambdaMOO
Continue from the LambdaMOO design (but perhaps with a fresh implementation), with some MCP extensions. This is my preference for now, we'll wait and see how it goes.
"ToastStunt Programmer's Manual", a currently-supported implementation of LambaMOO
MCP Protocol Specification
MCP-GUI Package Specification
Again, if RAM continues to get more expensive it may make sense to only use that subset of the MCP-GUI package that can be rendered in a TUI (MCP-TUI?). This should correspond exactly to the Emacs widget.el library.
This Year's Hype Cycle
A widespread successful application of LLMs may make much of the above post moot, but I'm skeptical personally. I remember reading a rhetorical question some time back. macOS users are notoriously fans of native UI apps, they will pay for it. So you would expect all products with an Electron UI to have been automatically translated to SwiftUI or similar to earn money. But this hasn't happened.
Also, a running theme above is that a plan is needed to develop for machines with restricted RAM. This is solely the fault of LLM & advertising corporations.
Back to my gemlog