speedstyle

or Tinfoil [0]? They serve open models with container integrity attested by Nvidia/AMD enclaves. Every cloud provider offers this of course, but not usually in a way that can be shared between distrusting users for economical inference. It still relies on the open-source containers being secure, and there's probably hardware sidechannels and stuff, but personally (ie privacy not liability) I trust it more than a contract

[0] https://tinfoil.sh

Would they disagree, new toolchains work great with old code? And even add 95% of the features to older editions, just not new keywords or inference defaults. I think in C++ people complain about the effort to migrate --std, rather than having to learn variants or concepts. It does add to the complexity of course, and it's useful to agree on a consistent style, I just mean Rust doesn't have the particular issues with everyone having to migrate in lockstep, or anyone needing to for new tools

Every 20k miles in the Porsche emits as much as producing a typical EV. Maybe 50k miles in an old hybrid. And it's not just emissions, significant resources and labour go into finding, extracting, refining, transporting fuel, compared to burning half as much in a CCGT, let alone renewables.

Obviously it would be even better to keep one EV longer (hard to say how much better, they do displace ICE vehicles in the used market) but they're almost certainly consuming less than you.

If you send someone `key xor X`, they can reply with `key xor X xor Y`, and you can recover `X xor Y` – without them having a clue what X is.

Hopefully then it's not too hard to believe you can build an encryption scheme and operations where `dec(enc(X) ⊞ Y) = X + Y` and `dec(enc(X) ⊠ Y) = X × Y`. If these operations can also be composed, i.e. homomorphism, then they're Turing complete! You can turn any function f(X) into a ciphertext version `dec(F(enc(X))) = f(X)`. It can't leak any information about X, because you only ever provided enc(X). For example you transform 'branching' code to something which traverses every path, and paths which do nothing will still appear to randomize the ciphertext, because you can't invent operations that distinguish which path is taken, because it's a secure ciphertext.

Modern homomorphic encryption uses more complex encryption schemes and primitives, to achieve thousands/hundreds rather than millions of times slower than f. Nonetheless it's impossible for the provider to gain a single bit of information about X.

I use Ente photos [0] without logging in, just as a local gallery. Since their backup solution is E2EE, it does everything on-device – face/object search, map view, memories

[0] https://ente.com

That says contracts about activities which are unlawful under State law, not contracts which are unlawful. Sports is legal, even if sports betting is regulated

It is difficult for parents to do this today! You can either have a limited set of apps with no general internet access (fine for younger kids), or domain-list filtering which takes significant work to set up, has many false positives and negatives, ie it's both a chore to request/allow useful things, and easy to get around. Lawmakers have been convinced the solution is opt-in, so websites can self-categorize and nothing needs to be configured on device – and I agree that websites need to self-categorize, but then this would make it very easy to reliably filter on device.

I think the most useful flexibility is for parents to do more specific categorization, eg allow violence on netflix but not youtube, block some game that would be allowed, request access to something that wouldn't, set time limits and times of day, etc. It's easier to enforce this stuff on the client than try to send the relevant parts to an app or site, but yes there are times you want the latter too.

I know, but I think the reality would change if it took 10 seconds to reliably block everything. It would also be the default if you enter an age below 16 at setup (tap a second device or scan a distinct face id to act as guardian). It should also be enforced in schools (and made possible to enforce by schools) as part of their filtering of explicit/harmful content, maybe they can even deploy their own policies eg blocking most phone use during school hours.

Are you saying parents would choose not to block it, or children would get around it? Like you say people want to block it, but currently it's very hard while allowing access to Google and other resources, or it's easy to get around. Why does this require server verification?

For example, all devices could require your ZKP ID attestation to be usable unfiltered. Then the relevant apps/sites would be equally inaccessible to children. And then you remove the ZKP ID attestation because the device owner (parent, school, etc) already knows when the user is a child.

You could make it easy to ban on children's devices, rather than having websites do it. At the moment you either have a small set of allowed applications, which is fine for younger kids, or domain-list filtering which is unreliable, hard for parents to set up (and not that hard for kids to get around). There are many ways to improve the situation – I think websites should have to attach metadata about the content being served, browsers should use this to apply a device policy, and devices should make it easy to configure basic rules on first setup. People aren't asking specifically for hardware-attested facial scanning

It doesn't have to be sent anywhere, websites should send a flag when serving various types of content, so parental controls has the information it needs for filtering. Websites could still infer what's being filtered of course, but doing the decision on the client allows for much more granular/extensible categories of content, as well as allowlisting, time limits, etc. Some sites/proxies won't be marked properly, but 99% self-categorizing would help a lot, and it's not like making them do ID checks or attestation is easier than setting an HTTP header or something

Client-side filtering solves the problem, because children's clients are owned by their parents. We should mandate that websites and apps send metadata about the content being served (eg extending the Rating: RTA header from 20 years ago) and mandate that OSs/browsers allow filtering to be easily configured at setup. This is a more private but also much more granular/useful solution, it's only difficult today because of a lack of coordination

A .app isn't a file, it's a folder. There's no good way to download a folder, you have to use zip, tar, dmg. I do like single binaries though, you certainly don't need a whole installer stage like Windows apps. Open package managers are even better

Yes sorry, dominant means strictly better in some sense, but may be equal in many objectives.

> Every solution in the Pareto front set dominates every solution not in that set

Not quite – for each solution not in the set, there exists a solution in the set that dominates it. For instance a front with (0,2) (1,1) (2,0) would not have (1,0). While (0,2) doesn't dominate (1,0), something else does.

If you click Show details, the LLM explains

> This module is not malicious and contains no IO or exfiltration. It contains unsafe code that is likely incorrect: `unsync_load` reinterprets the in-memory `AtomicU16` struct as a raw `u16` via a pointer cast and `ptr::read`, invoking undefined behaviour and breaking atomic concurrency guarantees.

This is wrong: the function documents its safety conditions, and its few callers are either single-threaded or guarded by a mutex. There seem to be cases where it is concurrently read without a mutex, but this is allowed https://doc.rust-lang.org/1.97.0/std/sync/atomic/#:~:text=pe...

The latter. Every solution not in the set is 'dominated' (outperformed in every objective) by some specific point in the set.

They never said it was the only Pareto run? Just a new one, improving the overall Pareto front

To your virtual memory comment, the kernel can only do as it's told, but allocators can indeed tell it to shuffle pages around in virtual memory. On Linux that's `mremap` [0], and `realloc` implementations [1] use it for large enough Vecs (apparently 128kiB for glibc and musl). macOS' libmalloc will try to map new pages that extend large allocations in-place, but memcpy elsewhere if existing virtual mappings are in the way. I don't think Windows' HeapReAlloc does either, but they might reserve a larger virtual region and incrementally commit it or something to similar effect.

[0] https://man7.org/linux/man-pages/man2/mremap.2.html

[1] https://git.musl-libc.org/cgit/musl/tree/src/malloc/mallocng...

Yes, this is noticeably worse than the original. The first sentence is rhythmically stilted and carries less impact. "is" to "acts" is not stylistic, we're no longer discussing the nature of the object but its behaviour. 'squeezing into a generic shape' is a transformation, each piece of writing stamped into conformity, whereas 'forcing into the same generic shape' must be pulled from a grammatical reading where all writing is being packed into one box. I think "writing produced by a lazy prompt from someone" is a wash, depends if they want to further detach the writer's agency from the result (and it still isn't produced by the prompt); I do prefer "unwilling" for the original tone; but it's certainly blander writing overall. If I came across it I'd even discount some of the metaphors and choices that are still present – since it's clearly written by AI, or a marketing copywriter, I'd guess they were "polish" rather than attempting to convey any particular connotation or nuance.

They commissioned 78 GW of new capacity in 2025, but actual coal-fired generation fell slightly (by 90 TWh, ie 10 GW). It might rise again, but it's expected to peak by 2027–28. And of course they added 440 GW of renewable capacity, 64% of global installations.

I certainly agree there's other motives (renewables even net them significant trade, like EVs) but it's not as though 'caring about' climate impacts requires selfless virtue, they stand to lose $trillions/year like everyone else.