Yes, if the banking app refuses to run on Graphene, you can forget about Waydroid completely. Hell will freeze over before Waydroid passes play integrity.
The compiler can assume that the function will return, but it can also statically deduce that the function cannot return. That's a contradiction, so the compiler deduces that the function is simply UB when called, i.e. no need to emit an epilogue. It's the logical principle of explosion in compiler format, basically.
It's not even about optimizing some big tech codebase by 0.5%. The progress guarantees in particular are in place s.t. Nvidia can choose a certain implementation strategy in Cuda C++ that has "surprising" consequences for users (one thread getting stuck in an infinite loop that never yields can livelock its entire warp) but still get to claim "full C++ standards compliance".
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?
I mean that's what they did, and that's why there's that UB. All I'm saying is that this is the "weird platform behaviors exist and must be legalized by the standard" kind of UB and not the "we want a 0.5% win for benchmaxxing" kind of UB (the standard has plenty of both).
No, they didn't. UB is a cop out and inserting yield is just plain bad. Locking up one or more threads in an implementation defined manner would be the outcome of least surprise (I already know it's going to lock up at least the one thread).
The standards intended interpretation of UB was always intended to be something like "implementation defined, no documentation required" to allow for implementation weirdness, even unpredictable ones. It was compiler authors who decided do abuse this allowance to do really unintuitive things instead of weird platform weirdness.
Because one can bleeping see that that's what would happen. Locking up a thread isn't a good thing, but it's a lot better than UB. There was never a need to make this UB.
I don't see the issue. Just let wrong code do wrong things But let it do the expected wrong thing, rather than changing the code to something unexpected.
Isn't that the strategy for most of the stuff in C++? It's the common denominator of a wide variety of platforms. That's why numbers didn't have to be two's complement and characters didn't have to be ASCII for ages.
Well sure, but access to that compute is gated by simple credentials (like API tokens). Those can be hacked.
Imagine for example if a model hacks into ~every Linux computer on the internet using an 0day and steals their OpenAI, anthropic and openrouter credentials. It now has access to billions of compute and the only way to fully stop that is for multiple major providers to shut down services entirely. That's already well into "billions of dollars of damage" territory.
What would that even look like? What is "benign"? The browser environment already has pretty strict rules for what the JS can do. It's not allowed to read your files, see your webcam without permission, know about other tabs or windows etc.
The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?
To give an example that goes beyond what you already suggested:
You can prove that your code terminates (or rather responds to events in a finite time, even if the event loop itself runs forever.) Or you can even prove that your code reacts quickly, ie within some time limit. You can also prove memory limits.
> The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?
Defense in depth. And you can have competing implementations relatively easily for this, and another way to find and report bugs. Especially if the verifier is open source.
The verifier itself can be pretty simple: it's the prover that's complicated and needs smarts, but that's being run on the author's computer, not in the user's browser.
I'll believe this when it's done. Nothing I've seen so far indicates that this would be feasible.
As a practical counterexample, the Linux kernel has a verifier for eBPF code that is loaded by untrusted users. That is a much more constrained environment than JS, but they still constantly have verifier bugs. It's so bad that distros almost universally distrust the verifier and instead set things up s.t. only root can load any eBPF code.
There may well be some writing jobs that are safe for the reasons given in this post, but that doesn't help all the writers I know who have already lost their jobs and are struggling to find work.
It's not enough that humans can tell the difference and feel an ick, there also need to be enough organizations willing to pay money for that difference. From my vantage point, there are not. It turns out that for a ton of the writing produced by companies, the quality of the prose wasn't really "load-bearing" as Claude puts it. That writing is there to occupy a space and look professional at a glance, the same way elevator music is tolerable for the duration of an elevator ride.
I have worked in the publishing industry, translation and editing (got out to a more dependable career just in time), and what is astonishing is how even "load-bearing" text is not safe from the cost-cutting pressures. That is, even some respectable publishers for the last several years will publish a book one is expected to pay good money for, with minimal editing and proofreading compared to the old days, and if it is an originally foreign book, with machine translation and minimal post-editing.
I've got some heavy reader friends and they keep complaining that many of Spains's fantasy book translations are ridiculously bad and blatantly machine translated now: Senseless terms that require looking up the original to understand, e.g. "fall" translated as in falling when it meant autumn; proper nouns, including character names, sometimes translated sometimes not; and many sentences that mix up the grammatical gender because the machine wasn't given enough context to infer it.
But these publishers don't get punished because they keep licensing popular foreign franchises, which aren't quite fungible, so consumers don't want to miss out and thus don't vote with their wallets.
How is it possible? Even if you just put text to ChatGPT it'll translate it much better than that. And with actually decent harness, the translation should be quite good. Do they even save on tokens by choosing cheapest model or something?
It's impressive how bad it is even for machine translation, I've seen examples. You're imagining them using a good LLM and a decent harness, but I'd bet it looks more like an intern copy-pasting snippets through an LLM or even just Google Translate and cleaning it a bit.
Unfortunately the answer is no. Reading or just owning a book by a certain author can be a matter of fashion or prestige. That allows for really bad work still be published.
Since you can't really go buy the same work translated by a different publisher, voting with your wallet means boycotting it. I agree it would be the right option to punish publishers, but people find it frustrating to miss out on both the work they were hyped for and its fandom; the latter is a really big deal for those deep into reading subcultures.
I know, but really, in the 21st century, aren't there many substitutes for whatever pop-hype we're talking about? Not enough worlds with wizards, or swords, or dragons, or whatever you like?
As of a couple years ago, mmap actually has a MAP_SYNC flag that makes it durable in the DB sense. The caveat is that it requires DAX on the file and so comes with a whole bunch of restrictions w.r.t. filesystem, storage media and even CPU architecture.
You need to use your bank's app for Wero, and many EU banks' apps refuse to run on GrapheneOS for the same reasons as PayPal. This is sadly not a clear win for Wero.
The people who think everything is a group vs. group war naturally interpret everything as a move within that war, including non-participants' correct observation that it doesn't really exist outside of the minds of the small segment of paranoiacs choosing to engage it.
I'm ignoring the entire chess board, in fact, because the stuff that's going out outside of the chess game is much more important -- to me, and to most other people who aren't involved in the chess game.
Astronomical distances are vast, million trillion miles too far, that's over a hundred thousand light years. There are known stellar-mass black holes within just 2000 light years of the Earth. Heck, there might be a primordial black hole in the inner Oort cloud and not only would it not destroy earth, we'd have (are having) trouble detecting it.
reply