Oh yeah, totally. I, too, have solved chess. Haven't we all? I totally get what you're talking about.

Scraping is legal

Have you been following any of the court battles involving LLMs lately?

The New York Times suing OpenAI. Getty Images suing Stability AI. Sarah Silverman and George R.R. Martin suing OpenAI.

All of those cases involve data that has been scraped. (In the latter two cases, the memoir/novels were scraped from excerpts and archives found online).

It's too late to say with complete certainty that it's all legal (the appeal processes haven't all been finished yet), but at this point it looks like using scraped and copyrighted data in training LLMs is legal. Even if it's going to turn out not to be legal, it's very clear that nobody's shying away from doing it, because we have the courts showing as a statement of fact that it's been happening for years.

Everything you've written is just fantasy. We have a lot of reality which contradicts it. Every LLM company has been primarily relying upon scraping data (which we know to completely legal) and has been incorporated copyrighted and scraped data in its data sets (which is still legally a grey area, but is happening anyway).

??? Google didn't display its first ad until 2000. What kind of advertising/marketing company doesn't display a single ad for 2 years?

Whoa whoa slow down with this new-fangled fad ideas. Next you'll try and tell me every user process doesn't run in ring 0.

Awful headline.

Somewhat surprising results, though. They took a fraction of pig blood plasma and injected it into rats over the course of 8 days. Some organs in the older rats showed a lower epigenetic age, and the older rats also performed quicker in cognitive tests. The results are more extreme than they predicted they be (especially the liver and heart), so we'll see what happens when someone tries to replicate the results.

Any speculation about applicability to humans is just science fiction, of course.

Yeah this part of it isn't getting enough attention. Take down his videos? Totally normal. Make him pay for some damages? Sure, I guess. Put him in prison? What the fuck?

Yes, which is literally what OP is asking about. They mention system calls, and are asking, if a userland program can do dangerous thing using system calls, why is there a divide between user and kernel. "Because the kernel can then check permissions of the system call" is a great answer, but "hopefully you can't harm your computer with userland programs" is completely wrong and misguided.

dd if=/dev/zero of=/dev/sda is a userland program, which I would say causes harm.

It's a website that's managed by a community of pirates. It's invite-only (meaning you have to be invited by an existing user) and you will have your membership revoked if you don't follow certain rules (mostly about seeding). The .torrent files you get from them are specific to that private tracker, so no one who's not also a member of the same site can see which files you're seeding.

When you power on a computer, before any software (any operating system) has a chance to run, there's "firmware" (kind of similar to software, except stored directly in the motherboard) that has to get things going (called "Platform Initialization"). Generally the two jobs of the Platform Initialization firmware: (1) to detect (and maybe initialize) some hardware; and (2) to find the operating system and boot the operating system.

We have a standard interface for #2, which is called UEFI. But for #1, it's always been sort of a mysterious black box. It necessarily has to be different for every chipset/every motherboard. Manufacturers never really saw much reason to open source it. The major community-driven open source project at doing #1 is called "coreboot". Due to the fact that it requires a new implementation for every chipset/motherboard and they are generally not documented (and may require some reverse-engineering of the hardware), coreboot has very very limited support.

So what AMD is open sourcing here is a collection of 3 C libraries which they will be using in all of their firmware, going forward. These libraries are not chipset/motherboard-specific (you still need custom code for each motherboard) and do not implement UEFI (you would still need to implement UEFI/bootloader on top of it), but they're helper functions that do a lot of what's needed to implement firmware. I just took a cursory look through the source code, but I saw a lot of code in there for detecting RAM DIMMs (how much RAM, what kind of RAM, etc.), which is useful code. (Edit: I just read through the Wikipedia article on coreboot and it says "The most difficult hardware that coreboot initializes is the DRAM controllers and DRAM. In some cases, technical documentation on this subject is NDA restricted or unavailable.". So if they can make use of AMD openSIL's DRAM code, that could be a very big win!!)

The fact that AMD is going to use this in their own firmware, and also make it available for coreboot under an MIT licence, means that coreboot may* have a much easier time in the future supporting AMD motherboards.

* we will see