JoshTriplett

> The lie has been heavily sold to the maker community that you are "wasting your time if you make something yourself" since it is cheaper to offshore even small 3d prints and machining projects.

I've seen what people go through when they operate 3D printers. The impression I have is that they still make 2D inkjet printers look like paragons of reliability.

It absolutely can be.

Suppose you're trying to reverse-engineer some proprietary tool, for instance. If you're doing that with human experts, you pick experts who haven't seen the code of the tool, or any disassembly of the tool, or any potentially tainted non-clean-room analysis of the tool.

Even if you have two separate AI instances do the RE and the reimplementation (which most people don't), the AI you use may well have been trained on the proprietary source code, or on any number of disassemblies/analyses/reimplementations/etc that aren't clean-room.

That's doubly true when people do ridiculous things like AI reimplementations of publicly available GPLed source code, where the AI definitely was trained on the GPLed implementation.

Can't believe how right we were, too.

The word for that is "crux".

Also a great way to disagree collaboratively. If you can collaboratively find the crux of each others' arguments, you now know both know exactly what would change each others' minds, and you can find that information together and know what's correct.

This is true of code, as well. LLMs have a strong tendency to make suspiciously prompt-shaped comments and code. "This deliberately does not do X". "This is kept in its own module rather than put in module M because". They act like they're responding to a conversation that's no longer there.

> Have it rewrite your terrible first draft.

> Have it fix your grammar.

> Have it make your argument clearer.

> Have it turn your 2,000-word ramble into something people can actually read.

Please don't do this, and then try to "put some of yourself back into it".

By all means, use AI to find bugs. But don't let it write a single word. Let it tell you what's wrong, then you can fix it and iterate.

Anything done with an LLM is not a "clean room".

> Illicit access as defined by Google / Apple?

No, illicit access as defined by a user who doesn't want anyone but themselves to have access.

Remember the iPhone jailbreaks where you visited a website and the website exploited the phone and installed a jailbreak? That was a remote security exploit, and any other site could have done that too and used it less benevolently.

Users should have full control over their devices. They shouldn't have to get it via exploits, and it's a good thing when those exploits are fixed, because they're security holes that can be used to harm the user.

The author works at Anthropic, so probably idle capacity in Anthropic's datacenters.

I remember the days of DOS and getting a direct pointer to video memory. And I've enjoyed the long history of video game exploits and even arbitrary code execution. But at the same time, I'm also glad that era is over. The same bugs that help you jailbreak a phone can also be the bugs that help you gain illicit access to one.

Preparing a derivative work, and distributing that.

> replace whole-file hashes

BLAKE3 has a whole mechanism for this, and as an added bonus it'd be substantially faster.

The mistake was declaring infinite loops to be UB in the first place.

The comment you're replying to was implying that some ciphers are sufficiently flexible that you could make up a key to make the cipher decrypt to a nearly arbitrary plaintext.

In this case, though, that seems unlikely from the fact that the key used was an actual key documented as being used for other messages.

Yes, the courts are leaning towards creating the exception that I said should not exist, giving an advantage to AI companies over the humans that created the work they've trained on. That is not surprising, but it's still harmful.

> Consider the full current date, including the day of the week; does it have a 'y' in it?

leaning no 0.41

Probabilities won't make an AI stop hallucinating.

> Is the port number of this website between 400 and 500?

probably no 0.16

> Is blueberrry spelled correctly?

probably yes 0.89

> Do the probabilities in the responses to these questions have plausible confidence, rather than being made up after the fact as justifications?

leaning no 0.39

> Is this a silly question?

leaning no, probability 0.33, subject "silly"

> Will Jev become the most successful AI model?

probably no 0.10

I was utterly unconvinced that the original infinite-loop UB gave the compiler any important performance optimization, and I'm unconvinced that this is providing useful value to compensate for its surprise. If I wanted a yield in my infinite loop, I'd add one.

I expect an infinite loop to be compiled into, for instance, a jump instruction jumping to itself. The OS, if there is any, is welcome to interrupt and context switch. I don't expect code that has no function calls at all to have a system call inserted into it.

So let it livelock the entire warp when someone writes an infinite loop. Should we start replacing integer division by zero with INT_MAX so that people aren't "surprised" by their program crashing?

You said "Real experts can explain their position plainly.". The experts have explained their position plainly. If you disagree, you should be able to explain your position plainly; "feels like vibes to me" is not an explanation, it's a feeling.

If you want to argue that there's something invalidating the arguments, by all means do. But it's really tiring to get many variations of "nobody's made the case for it!" or "there's no evidence for it!" or "vibes!".

"Emitted in inappropriate contexts" is very much one of the shapes I would expect unpleasant surprises to take, yeah. If you're writing code in C, you often need a lot of control over exactly what's happening. You might, for instance, be writing a .so for use with LD_PRELOAD, where it's important that you know everything being called so you can't accidentally recurse. You might be writing code for a sandbox, where you have an allowlist of permitted syscalls.

If you're arguing for abolishing copyright, I'm all for it.

But as long as copyright exists, AI training should not get any exception to it. That creates an asymmetry, where AI gets to rip off our work and use it to compete with us, while we don't get to do the same with proprietary works (e.g. software).

I don't want a world in which AI can rip off all of my Open Source code and not respect its license, but I can't take macOS and virtualize it and not care what Apple thinks of that.

> When both conditions are met, the loop body is replaced with a call to std::this_thread::yield().

Insert screaming here.

An infinite loop, with no library calls whatsoever, gets a system call inserted. That's a horrible surprise waiting to happen.

The entire concept of the "forward progress guarantee" is broken. An infinite loop should compile to an infinite loop. Nothing more, nothing less.

Imagine actually asking permission to use other people's work to train AI. Imagine respecting the answer of "no".

There are already widespread attempts, by both red and blue proponents of AI, to paint opposition to AI as being from the other side. Hopefully those ad-hominem arguments will peter out as it becomes clear that opposition is bipartisan.

It's not just you.

I would personally expect so, but your mileage may vary. Controlling for the fact that you didn't find the former persuasive, my first thought would be that the latter might help. Among other things, it is much more specific and detailed in various ways, not least of which being informed by an additional 11 years of history. The former was not written in a world of pervasive AI, or with current AI architecture in mind; the latter has that context.

That's a fascinating assumption, and I wonder how you got to it, because it doesn't match anything I've ever seen. Most groups look more homogeneous from the outside than the inside. You are assuming their belief is religious and axiomatic, rather than very carefully reasoned about for decades, iterated on, discussed, debated, tested, and refined.

> Real experts can explain their position plainly. That has not happened here.

It has, over, and over, and over. There is literally a book on it. https://ifanyonebuildsit.com/

In fairness, while there was definitely Mozilla mismanagement, there was also a massive monopolistic marketing/bundling campaign by Chrome. Google search and other properties pushed Chrome, Google paid application publishers to bundle Chrome the way they bundled adware, and so on.