lambdaone

I would have thought that those participants who are published in peer-reviewed journals could be be used as a trust anchor - see, for example, the Advogato algorithm as an example of a somewhat bad-faith-resistant metric for this purpose: https://web.archive.org/web/20170628063224/http://www.advoga...

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety.

If 32-bit x86 support can be dropped for pragmatic reasons, so can these architectures. If people really, really want to preserve these architectures as ongoing platforms for the future, they need to step up and create a backend for the Rust toolchain that supports them.

People are absolutely part of an ISA's ecosystem. The ISA is the interface between code and CPU, but the code is generally emitted by compilers, and executed in the context of runtimes and operating systems, all designed by people and ultimately dependent on their knowledge of and engagement with the ISA. And for hot code in high-performance applications, people will still be writing directly in assembler directly to the ISA.

If only someone had a way of automating this! Say perhaps using some kind of digital computer...

All the more reason to make it portable. I wonder if this can be implemented via LLVM?

You may see a mixture of sodium and lithium batteries in grid storage; one for providing very short-term grid stabilization of the order of seconds to minutes, the other for long-term large-scale storage, which is by far the largest application. Possibly both within the same battery farm.

You can also put internal heaters within the battery compartment itself, as with current EV batteries, and have the batteries manage their own temperature automatically.

They also produce much less harmful combustion products when they do catch fire.

I can't stress enough how big a development this is in the process of making renewable energy not just the cheapest form of power, but one of the most reliable, something that will drive decarbonization in general, which will in turn drive world politics.

This article leads to a paywall where I am, making it of no use. Perhaps someone else has done a better job of summarizing the paper elsewhere, and that should be posted instead?

We are lucky it's even a duopoly. All it would take is the demise of Firefox, and the entire web would be defined entirely by the implementation of Chrome/Chromium.

Servo is very welcome; a third leg to the stool makes real diversity possible again.

Grounding programming languages in mathematics like this is essentially the goal of Strachey and Scott's denotational semantics, which has been very influential in programming language theory:

https://en.wikipedia.org/wiki/Denotational_semantics

I had a client with a system just like this. EBS, S3, RDS, Cognito, the lot. It cost $00s per month under almost no load, and was a maintenance nightmare - which was the real problem, not the cost, as it stopped working altogether eventually. A bit of hacking later, it all fits on a single VM that costs ~$10/month to run and is far easier to build, deploy and maintain.

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?