Already has variable substitution and math, it seems to falls short of Turing completeness only because I don't see any form of recursion. But recursion is something it could accidentally gain if someone decided to add templating to the language.

Besides, looks the config files can call out to external executables, which absolutely are Turing complete. And moving to lua might actually simplify configs by allowing more things to be done inside the config system, rather than calling out.

Ah, cracking. Another thing the RISC-V ISA will try to avoid at all costs.

> I don't think they would've added 3r1w if it wasn't for the complex load/stores.

Agreed. The complex load/store addressing is one of the fundamental parts of the original ARM design, and IMO the only one that really survived into AArch64 unscathed.

It actually needs to be 3r2w so that it can writeback both the updated base register and memory value for indexed loads.

And if you already need 3r2w (or to emulate it via cracking), might as well add other instructions to take advantage of it.

> I think it's a fine way to design an ISA

Really depends on what the design criteria are. If the goal is to create a "better MIPS" or "Easy to implement ISA, great for education" or "Optimised for low-transistor classic-RISC pipelines", then avoiding flags is a great idea.

And a good idea to avoid cracking, it just adds complexity and pushes you away from that "RISC purity". TBH, I'm a little surprised they got rid of branch delay slots, but I guess they really confuse people writing assembly (or compilers).

In many ways RISC-V is a great ISA, the extendability and openness is unparalleled and it does actually deliver on scaling all the way from ultra-low transistor designs, all the way up to high-performance out-of-order cores.

But if the design criteria is "An Open ISA optimised for the modern era", then I think RISC-V falls short. And the choice to avoid flags is one of the many minor issues that add up to making RISC-V sub-optimal for higher-end μarches.

But it does require three input registers. One for a control value, plus the two options. And RISC-V has a thing about not requiring three input registers.... Yeah, I'm not a fan of RISC-V.

One of the other major advantages of flags is it allowed for a cheap third input to certain instructions (like cmov, adc, ccmp), without requiring a full 3R1W register file.

The fact that it's possible to design a viable ISA without flags is really neat, it was absolutely worth trying. But MIPS already proved it was possible, and showed all the downsides, it did not need to be tried a second time with RISC-V.

So it must be something about limiting the complexity of the flags register file and/or its bypass network.

> But I hadn't considered the ISA design option of only carry flag, no seperate cmp and branch, before.

Well, RISC-V does have a decent point: Most of the time you simply don't need flags. The only area this approach falls apart is detecting overflow or add-with-carry.

So, why not just cover that flaw by adding a carry/overflow flag.

The counter-argument is that as soon has you "ruin the purity of the design" by adding one flag, you might as well add the complete set of all four. Then you can simply branch instruction encodings, and use the extra bits for something else (like seperate set-flags versions of all the ALU instructions)

Though, PowerPC implementations (like the PowerPC 750) do have renaming of condition registers, which allows them to speculatively execute CR write instructions (though the PowerPC 750 can't speculatively read a CR, it can only speculate one branch at a time).

But I suspect other justification for renaming CRs, is that register renaming is actually how the PowerPC designs from that era handled hazard detection and result forwarding (and maybe why such designs only a few renaming registers, six GPRs and six FPRs on the 750)

N and C are basically free (copy of bit 63, and it's carry out), V is an extra gate or two, but Z requires a full 64-bit wide NOR gate.

Or it might be about making the register file holding the flags smaller (only 3R3W, instead of 6R6W), along with simplifying the associated bypass network and routing (the first three ALUs are also the only units that can consume flags).

When I say ooo cpus get flag handling for "essentially free", I'm only actually talking about the complexity of tracking "implicit state", and that it can be done without extra latency. You still need to spend transistors to support renaming flags, and to actually calculate and storing the flags.

I can see an argument for an ISA that got rid of the N and Z flags, but kept C/V (potentially merged into a single flag). You can trivially reconstruct N/Z from the result register, but not C/V.

But if you are designing a new ISA for the modern era (the purported selling point of RISC-V), you just don't implement any such instructions. Only implement clean instructions that update all the flags or none. ARM and PowerPC already did this 35-40 years ago.

Out-of-order pipelines actually have a really elegant way of handling flags, they just store a copy of the flags register on every ROB entry. During renaming, instructions that consume flags just gain an extra implicit input pointing to the ROB that will contain the correct flags.

Such pipelines already need deal with so much serialised state. The flags are actually one of the easier things to deal with, they basically get support for free when they implement register renaming.

It's actually the "classic RISC" style in-order pipelines where flags are annoying to deal with. They pipelines don't need to do any register renaming, so they don't have a free solution to handle flags. And the RISC-V ISA is very much optimised for these simpler pipelines.

And we don't usually worry about them, because an application with normal user privileges can already to so much damage.

But this exploit can be triggered from inside a tightly sandboxed process, such as firefox's isolated browser process. Which means the attacker now only needs to chain two exploits together: One javascript exploit to get local code execution in an isolated sandbox, and this one to jump all the rest of the way to kernel mode.

Which means, you should update both firefox, and your linux kernel.

I don't think we have ever seen something like it before. A new media format that breaks backwards compatibility, yet uses the exact same physical medium as the previous version. Some people did attempt it with HD movies on DVD, but the attempt failed so badly I don't think it even counts.

Its very existence was a very strong signal Bluray would be the last optical disc format. And the launch of the PS5 without a new optical confirmed it.

The reason why they both follow the same naming scheme is that Philips Semiconductor (now NXP) made both.

And the PS5 is meant to be able to play digitally downloaded while disconnected (at least the ones you own, not the PS+ games). It's just the implementation is little buggy, it sometimes breaks for some people and you get a bunch of vocal people complaining about how it doesn't work.

So IMO, you aren't losing much there. The digital-only experience isn't that different from needing to have internet to download a day-one patch.

It's the used game sales that are the biggest loss from this move.

Will we continue seeing new bluray releases of movies and TV shows for decades, or are their days numbered?

The loss of console gaming presumably removes a guaranteed revenue source that was keeping Bluray pressing plants alive.

Sales of DVDs and Bluray have been declining for years [1] [3]. Some people have been excited pushing the news that UHD bluray sales increased in 2025, [2] but that ignores the fact that the total optical sales still dropped.

[1] https://www.flatpanelshd.com/news.php?subaction=showfull&id=...

[2] https://www.flatpanelshd.com/news.php?subaction=showfull&id=...

[3] This article has a more complete graph: https://www.statsignificant.com/p/the-rise-fall-and-slight-r...

At least not from a practical perspective.

From an economic perspective, stopping after a single small run is just wasteful. The upfront design costs are so high, and the per wafer costs are so slow that you might as well make a lot extra. Maybe you can find a use for them, or sell them to someone else.

What it did provide was a simple but reliable way to maintain emergency broadcast to general public within Britain. And it probably should have been kept online just for that reason.

A floppy distro (especially one relying on a compressed initrd) will inherently require more memory. And I suspect the maker of this distro is using a different definition of "minimum" than we would have used back in the 90s (closer to "recommended").

However, it looks like modern linux kernels just require more memory; The kernel binary is certainly larger, floppinux is spending an entire 888KB on it's very stripped down modern linux (doesn't even have networking enabled), while older floppy distros using 2.2/2.4 kernels keep it under 512KB (with networking, and a bunch of other features.

There was a scheduled test last weekend, and I disabled the single “emergency alert” option in my iPhone’s settings. But it didn’t work, I still received the alert, complete with the heart attack inducing sound.

The latest IBM z/Architecture mainframe (released in 2024) will natively run binaries compiled for the original IBM System/360, released 62 years ago.

The original architecture has been expanded to 64 bits and can (or should) run linux with older code in virtualization.

However, those mainframes are extremely high performance, high reliably, and high cost. Complete overkill for many companies, who can get away with much simpler/cheaper emulations of the System/360 from 3rd parties, or source code ports to more modern architectures.

There are like 3-5 completely different family trees of computers in their numbering scheme (depending on how you count), all of them are notable in some way.