silver_sun

I think this comparison is interesting because it shows the difference between theory & practice, but it's a little inaccurate. The halting problem being undecidable just implies there is no single universal algorithm that can tell you whether any program at all will halt. In practice we are working in specific domains and can come up with heuristics which are "good enough" for a specific codebase / module, like the timeouts you mention. So the halting problem can be solved for some subsets of programs but not all of them, and the computer scientist would hopefully have realized this instead of treating the codebase generically as "any program".

Not infinite memory, a Turing machine only requires "unbounded" memory, which is a way of saying that it will not run out of memory while running its program with the given input. In other words it just needs to have enough memory to run the program with whatever inputs it was given, which is much less than infinity. And this situation is quite common in the real world -- the programs I use on a daily basis have all the memory / RAM they need to do what I want (almost by definition). So in practice I might as well view them as Turing machines.

I'll give you that, enforcement of the rules can sometimes fail. But scamming & malware is a global industry, definitely not limited to state-funded actors in those two countries (which is what I think you're referring to).

I don't think it does because of the workaround I mentioned upthread.

The perfect is the enemy of the good.

Isn't app data, photos etc. usually synced with the Google account? Besides, Google claims that the scammers are using social engineering to create a feeling of panic and urgency, so I think the victim would be willing to reset and log in to the accounts again in such a frame of mind.

Users don't have to wait 24 hours because Google Play store already has registered developers. Scammers can be held liable when Google knows who the developer of the malicious app is.

Allow a toggle with no waiting period during initial device setup

I like this idea in principle but I think it could become a workaround that the same malicious entities would be willing to exploit, by just coercing their victims to "reset" their phones to access that toggle.

Well maybe nothing ultimately changes. Maybe we end up in a world where Android users have to wait 24 hours to change a setting so that their devices will install any apps they want, from then on with no further delays. But this seems to me like a relatively low cost for a potentially huge benefit for victims.

I don't think it's fair to extend the analogy to what amounts to censorship of websites since that's not the system they're proposing. Also isn't the owner of a website already identifying themselves when they register their domain name and/or rent a server? I think this is not the same as downloading an app by an unknown developer.

From the article I understood this to be a one-time delay, as opposed to having to go through the same waiting process for every single "unlicensed" app I want to install (which I would not accept). I'm just waiting 24 hours once to permanently change my device into a mode where I can install any app I like without any restrictions/delays whatsoever.

It's a little inconvenient for someone setting up a new phone to have to wait a full day to install unregistered apps. But while I can't speak for others, it's a price I'm personally willing to pay to make the types of scams they mention much less effective. The perfect is the enemy of the good.

Google has a library of millions of scanned books from their Google Books project that started in 2004. I think we have reason to believe that there are more than a few books about effectively playing different traditional card games in there, and that an LLM trained with that dataset could generalize to understand how to play Balatro from a text description.

Nonetheless I still think it's impressive that we have LLMs that can just do this now.

They said it builds Linux 6.9, maybe you are trying to compile a newer version there?

this isn't just a matter of teasing out the compressed C compiler written in Rust that's already on the internet (where?)

A quick search brings up several C compilers written in Rust. I'm not claiming they are necessarily in Claude's training data, but they do exist.

https://github.com/PhilippRados/wrecc (unfinished)

https://github.com/ClementTsang/rustcc

https://codeberg.org/notgull/dozer (unfinished)

https://github.com/jyn514/saltwater

I would also like to add that as language models improve (in the sense of decreasing loss on the training set), they in fact become better at compressing their training data ("the Internet"), so that a model that is "half a terabyte" could represent many times more concepts with the same amount of space. Only comparing the relative size of the internet vs a model may not make this clear.

Their section on "Dataset limitations" says that the study "Only captures bugs with Fixes: tags (~28% of fix commits)."

Just worth noting that it is a significant extrapolation from only "28%" of fix commits to assume that the average is 2 years.

Interesting. Could you elaborate? Is there a specific reason that it doesn't do 100% of the work already?