phire

You have a point... Alsop is saying that the destruction somehow made it "more clearly transformative" (which is not quite the same thing as "more transformative"), so it is something that could potentially impact the outcome.

I think what he is saving you can't argue the point of the scanning was to save space if you didn't destroy the original. And he concluded that "the mere conversion of a print book to a digital file to save space and enable searchability was transformative for that reason alone"

But my point is that you can't assume Anthropic would have lost if they didn't destroy the books. Alsop didn't rule on that, simply because he didn't need to. Judges hate ruling on things they don't need to.

In an alternative history where Antropic put the physical books in a warehouse after scanning, they could have argued the transformation about "minimising storage costs while increasing the easy of access" and IMO they probably would have won with that too.

Transformative alone isn't enough for a fair use defence. Nor is it required. It's simply one of the many factors a judge will take into account.

But it was an important factor in the google books case.

One of the other key factors is how it impacts potential sales of the original work. Turning it into an audiobook might be transformative, but when you sell access to it people will buy your audiobook instead of the original book. So it's almost certainly not fair use.

In the google books case, google scanned the books but didn't distribute the content of the books to the user. They only distributed the transformed ability to search books to users. The sales of the books weren't impacted negatively, because the user still had to acquire a copy of the book from somewhere else if they wanted to read the whole work. In fact, google books arguable increases sales of the original work in some circumstances.

The RIAA (and the wider copyright industry) were careful to never bring a case that might rule on the issue of "ripping data from CDs and converting to digital".

What they did was bring a case against Naspter, which ruled that ripping data off CDs AND THEN sharing it to millions of people over the internet was infringement. Not because of the ripping, but because of the sharing. The RIAA then somehow managed to twist public discourse to interpet the ruling as "ripping CDs is illegal".

They were careful, because the Sony Betamax case had already ruled that recording TV of the airwaves was legal, which is already a weaker case than ripping CDs you own. They knew such a case would likely rule against them, and they found the ambiguity to be much more useful.

And later cases like the google books case, and this Anthropic one provide even more evidence that the courts would likely rule that ripping CDs was legal if such a case was ever bought. (Though, it really depends on what you do with the digital copy)

I'm not aware of any cases where the RIAA sued people who ripped their own CD/DVDs/VHS for personal use.

Their MO was suing owners of internet connections which were seen sharing content on file sharing networks.

I've read through the order again. I can't find anywhere where Alsup says the destruction was required.

He cites three cases where a conversion from one format to another (without destruction of the previous version) was ruled to be fair use. Including scanning books with the google books case. (And referenced the Napster case, where a similar argument was rejected)

Then made the following comparison.

"Here, every purchased print copy was copied in order to save storage space and to enable searchability as a digital copy. The print original was destroyed. One replaced the other. And, there is no evidence that the new, digital copy was shown, shared, or sold outside the company. This use was even more clearly transformative than those in Texaco, Google, and Sony Betamax (where the number of copies went up by at least one), and, of course, more transformative than those uses rejected in Napster (where the number went up by “millions” of copies shared for free with others)."

So it wasn't transformative because of the destruction. The destruction only made it "even more clearly transformative" than those other cases.

Like, how can destruction be required if there were previous cases where it wasn't?

The key legal point is not that Anthropic destroyed the books, but the key fact was that Anthropic didn't distribute the scanned copies. Alsup keeps returning to this point:

"But what matters most is whether the format change exploits anything the Copyright Act reserves to the copyright owner. Anthropic already had purchased permanent library copies (print ones). It did not create new copies to share or sell outside"

"But again, the replacement copy here was kept in the central library, not distributed"

The conclusion of that section doesn't even mention the destruction at all.

arstechnica isn't exactly wrong, the quote also mentioned "and kept the digital files internally rather than distributing them". It just put way too much emphasis on the destruction, and not enough on the lack of distribution.

The other thing that arstechnica are missing:

Antropic didn't destroy the books because they thought it would strengthen their legal argument. They destroyed the because it's a lot cheaper and faster to scan books by ripping off their bindings and feeding the stacks of loose pages into a document scanner.

And since they literally destroyed the books (not just delete files, which would be copied), that made it transformative.

You have to be careful, just because the judge points a factor out as notable, doesn't mean that factor was required.

The destruction of source books makes Anthropic's fair use argument [2] especially air tight, but it would be a mistake to assume that act was required, or is what made it transformative.

In the previous google books case [1] (which this case cites), google borrowed books from libraries, scanned them, then returned them. They were not destroyed, google didn't even keep the physical copy.

Yet Google Books was ruled fair use, because it was transformative.

[1] https://en.wikipedia.org/wiki/Authors_Guild,_Inc._v._Google,....

[2] Note... This part of the ruling is still not about LLMs. This was about Anthropic's right to scan books and then keep a digital library of them.

This settlement has basically nothing to do with LLMs.

At least not as far as the courts are concerned. Alsup ruled [0] that feeding a book into an LLM is transformative and counts as fair use. Especially when they purchased a physical copy of the book, scanned it, and destroyed the original.

But if I'm reading the ruling correctly, Anthropic might have been fine even with feeding pirated books into their LLM (as long as they planned to eventually deleted them afterwards)

Where Anthropic ran into problems is that they put all their pirated books into a big central library (file on a server), and planned to keep those copies forever. Including copies they never actually fed into the LLM (a point that seriously worked against them).

Alsup ruled this central library of pirated books was copyright infringement. And it's this "pirated central library" that Anthropic are now paying a a 1.5B settlement for, nothing else.

The fact that the pirated books were also used to train LLMs is legally irrelevant. Though... I suspect a non AI company could have negotiated a significantly smaller settlement.

[0] https://copyrightalliance.org/wp-content/uploads/2025/06/Bar...

It looks like the previous hyprland config language was already getting close to being Turing complete;

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.

some of the complex load/store ops, which are usually cracked

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.

Well, cmov is absolutely possible without flags. You see such "select" instructions all the time on GPUs. Doesn't even require an extra instruction, cmp + cmov is two instructions, seqz + select is two.

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.

Huh, it does have CLZ on all ALUs (And CLZ can actually be used to reduce the cost of checking for all zeros).

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)

That allows the parallel execution of up to 8 instructions per cycle, even without register renaming

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)

I wonder if the issue is actually the cost of calculating the flags.

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.

True, and I wouldn't be surprised if modern x86 implementations need to do something a bit smarter.

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.

IMO, the "out-of-order performance/complexity" excuse is complete bullshit.

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.

Not really. Generally we use "Local Privilege Exploit" to describe an exploit that goes from a reasonably normal user privileges to root privileges.

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.

UHD bluray isn't really a new physical format. It's the exact same physical format as regular bluray. They didn't change a thing except move some previously optional parts of the bluray spec (like three layer discs, and 33GB per layer) to being compulsory.

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.

Yeah, it's much closer to SPI.

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

TBH, 100% offline gaming has been problematic since day-one patches became the norm in the PS3 era. Sure, you might be play version 1.0 of the game from the disc, but often the experience was pretty compromised without the patch, often very buggy, or sometimes even features missing.

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.

That's part of what I was thinking. The idea of digital-only must be very attractive for content owners, so I don't think they will put much effort into preventing that outcome.

With this news, I have to wonder how much longer bluray will live.

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...

There isn't really a minimum production run for silicon chips, they do small test runs all the time to test new designs.

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.

This transmitter doesn't really have the range for reliable global communication, it's optimised for covering the UK. For the global communication usecase, there are other networks of military transmitters (DHFCS) that are much better suited for the job, and they aren't being shut down any time soon.

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.

This floppy decompresses the entire initrd image into memory at boot, which "wastes" memory compared a proper install on a HDD. You can also lower memory requirements further by enabling swap.

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.

Apparently can’t in NZ either.

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.

Still are.

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.

PDP's lack of naming really confuses things, they essentially just numbered the computers by release date.

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.

They were most likely just bugs. Quite possibly really stupid bugs.

Not every bug results in the program doing the wrong thing, they often just make the program do the right thing very slowly.

And nobody notices, since it still produces the right result.

They side-step the issue:

"Schwitzgebel and Pober do not attempt to define consciousness. Instead, they proceed from the premise that it's a real and recognizable phenomenon, posing a narrower question: Must it be tied to the biology found on Earth?"

Basically, they are asserting that no matter how we define consciousness, it can't be unique to earth's biology.

The design of the exposed mechanism is explicitly about booting unsigned versions of MacOS. There is zero support for booting anything else, but no enforcement that it must be MacOS.

However, apple's justification for exposing this mechanism to users appears to explicitly include "booting linux" even if the mechanism has zero explicit support for booting linux.