lambdaone

Exactly. You don't need to really know how to program to use web frameworks, and web programmers are much cheaper than systems engineers. It's a no-brainer in short-term business terms. But there's a always a price to be paid for decisions like this, and this overhead is it.

Experience of similar tradeoffs tells us it will only get worse over time, and LLM-generated web programming will make the whole process get even worse even faster.

It's not a spacecraft issue. Encryption can be done at the ground stations, and mandated as part of the standards for interfsce equipment, just like with DOCSIS. There's nothing, physically, to stop you passing unencrypted traffic down your DOCSIS cable, if you wanted to make a nonstandard modem and send unencrypted traffic on your local physical segment of the network. But the rest of the network will refuse to talk to it.

The same could have easily been mandated for satellite links - no encryption, your packet won't get forwarded to the internet at the ground station, and any packets sent to you from the internet will be sent to you encrypted. And all this can be implementd without needing to touch the satellite itself, which will continue to forward what it sees as unencrypted traffic without any design changes. It could even have been implemented incrementally on existing running services, with old and new equipment working side-by-side, but all new ground stations required to support encryption, and with a sunset date for old equipment, and a rolling upgrade program.

DOCSIS got this right in 1999; the satellite industry has had 25 yeqrs to catch up.

It's absolutely jaw-dropping. Either no-one at these companies was capable of understanding the problem, or no-one cared enough to do something about it.

Absolutely mind-boggling that this is a thing; not just that satellite links aren't per-user link-encrypted, but also that people are still using unencrypted protocols to exchange sensitive information on the public internet in 2025.

Apple had a go at doing this with iCloud, but clearly there was enough consumer pushback (a friend lost all their files after cancelling iCloud, thinking it was a backup service, not realising it deleted the original copies on their machine) that they stopped the enshittification there.

At this point, Windows has jumped the shark. It's clear Microsoft now see the future of their company as cloud services, with the desktop gateways just as an endpoint for that, and the progressive enshittification of the Microsoft ecosystem has reached the point at which it is no longer the sensible OS for the mainstream, but is now a gamified mess like pay-to-play gaming.

Fortunately for most of us, Linux and MacOS exist. But companies that have built their entire IT infrastructure on Windows really have no clear way out other than to follow Microsoft down the rabbit hole - which is, of course, the whole point of these recent changes.

This really reads like AI-generated, or at least AI-polished, text.

A competent programmer should be able to at least conceptualise every level from the transistor up - not necessarily completely understand, but at least know roughly what it does, and what it rests on, and what rests on it. Transistors, gates, logic, state machines, instruction sets, assemblers, parsers, compilers, interpreters, operating systems, memory allocation, graphics, browsers, that sort of thing. Not at all unreasonable for someone with a decent computer science degree, surely?

Of course, you don't have to know any of that to grasp how to bang a page together with today's web frameworks; but you end up with the resource-hogging unmaintainable security disaster that is the modern web in the process.

As an example of this, I had to build a management interface for the backend of the project I was alluding to above; itself a web app in its own right. Written entirely in Python, with HTML templates, CSS and JS and a bit of SQL with no "web frameworks", no other dependencies except nginx to proxy requests to it. Easy and quick to develop (a couple of days), and very unlikely to suffer from software rot, unlike a web-framework based system - Python (at least since the Python 3 debacle) has excellent backward compatibility, and basic HTML, CSS and JS likewise.

What it did lack, though, were fancy widgets and other decorative bells and whistles. But is it worth the cost of pulling in the vast overhead of "modern" frameworks, and their resulting complexity and maintenance problems, just to have those?

Once you give up any hope of understanding the inner workings of the frameworks you are using, you're no longer a programmer, you're a cargo cultist. Now compound this a dozen levels deep, with systems piled on systems built by people who don't understand the other systems they are building on top of, and you have the current mess.

When you write "The complexity is inherent to modern web development" you are describing the problem, not a requirement. When you are pulling in a thousand npm packages just to make a simple transactional website that is a wrapper over a database and a few SQL queries, you're doing something wrong.

I agree with the article; web programming is an absolute disaster of snowballing complexity. I think much of this is driven by a combination desire among web programmers to see themselves as "software engineers" and the need to constantly track the most fashionable trends and frameworks so they can one-up their peers.

I recently had to rescue a complex web-framework based system that was an absolute clusterfuck full of basic programming mistakes - the most glaring of which was a complete lack of database transactions in the node backend - but what it did have was every fashionable bell and whistle installed, and extensive reliance on the AWS ecosystem, as if it was designed for millions of concurrent users, whereas a single simple VM running about about 1% load would have done the trick.

And yet all this complexity actually did very little - a simple Rails-based-app would have done it all, at a fraction of the complexity, with far fewer dependencies.

Or indeed methane generated via the Sabatier reaction using hydrogen generated from renewables - higher energy density, easier to handle, store and distribute. And it can be fed to existing gas peaker plants, a known technology.

That makes a really interesting case for large-scale thermal storage at high temperatures (inefficient, cheap, enormous capacity, slow response) as a complement to solar generation (cheap, intermittent), and batteries (efficient, instant response, not enough capacity).

Lifting heavy weights with a crane (or up a hill with a train) is unfortunately a very expensive way to store energy compared with pumped-storage hydroelectricity, which does effectively the same thing but with far lower cost and greater scalability.

This can be seen from the fact that while lifted weight storage is ridiculously easy to build with existing technology - it's a train or a crane, after all! - it has never caught on as an economically fieldable system, whereas pumped-storage hydro has wide adoption.

I'm quite aware of the existence of compilers, having worked on bootstrapping a production LISP compiler in the past. My point being that this would be an interesting experiment to do this "naïvely", given how close C is to (for example) PDP-11 assembly code.

Amazing, and you could see how this could be translated into perhaps a couple of thousand lines of assembly code to boostrap Scheme almost from the bare metal, similar to the early IBM 709 LISP.

A thought: I wonder if an LLM would be up to the job of writing the assembly code from this?

There are all sorts of crazy ways of getting data out of even air-gapped machines, providing you are willing to accept extremely low data rates to overcome attenuation. Even with million-to-one signal-to-noise ratio, you can get significant amounts of key data out in a few weeks.

Jiggling disk heads, modulating fan rates, increasing and decreasing power draw... all are potential information leaks.

DWDM per-wavelength costs are way, way lower than that, and, with the optional addition of encryption, perfectly secure and fast enough for disk replication for most storage farms. I've been there and done it.

Right now email is true One True SSO. I suspect that the root of trust for the digital identity of most people here is something like a Gmail account, unless you have gone to vast efforts to secure personal digital sovereignty in terms of having entirely self-hosted domain, email, DNS etc. The question is: in the long run, do you trust your government more than Google?

That might sound facile, but it's actually a great idea. Being able to ignore commits based on regexes would be even more powerful.

"ready for production", "fully working" and other Claude-isms come to mind

None of this is remotely new or interesting. I was doing IP-over-laser-light at Ethernet speeds over kilometer distances using free-space optics thirty years ago, and even then it wasn't a new technology.

Wouldn't a Scheme to WASM compiler in Scheme make more sense, providing the capability to do something like Gerbil Scheme?

Yes, that's exactly what the poster above was saying, just not in those words. The idea that we are one and all on a high-minded journey of self-actualisation is hopelessly naive; most people are indeed flailing around at the bottom of the Maslow's pyramid, and that's how we got to where we are today politically.

Yog-Sothoth has heard your plea, and will be along to help you shortly.

At this point, the benefits of an official governmental digital ID system exceed the drawbacks; the argument against digital identity documents died a long time ago with the total loss of privacy due to the amalgamation of all existing systems combined with the ubiquitous tracking of physical and online presences; that horse has bolted, and trying (and failing) to shut the stable door now won't help.

The current battle for digital personal rights is the right to private communication and data storage, and thanks to encryption and open source software, that one's not lost yet.

What's needed is something that is simple for humans to read and write, has a stable definition, and a clear and unambiguous syntax and mapping to data objects.

None of the systems I've seen achieve all those goals at once.

YAML, while at first sight a good idea, is irredeemably broken and should be deprecated for further use.

JSONC (https://jsonc.org/) is backwards-compatible with JSON, and a good target for long-term future migration.

.INI format works well as a structured subject-predicate-object tuple store for simple use cases.

We're probably going to have to live with that indifinitely, until someone comes up with a proposal that is better.

Combining generative ML (and other heuristic methods) with formal methods is the most promising way forward for systems design. Without formal methods (and other constraints such as limiting systems complexity) we are going to vibe-code ourselves to chaos.

Think of it as representing something like the letters actively 'creeping' and giving off tendrils of darkness. Does this help?