1,160 karma · joined August 28, 2025
As for practical use, sure there are some rough corners (this is true for every Linux distro), but I don't think there's any horrible showstoppers. In fact it's particularly well-suited for use by organizations (as opposed to private individual use) because it's great for making highly customized but reproducible setups.
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.
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.
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?
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.
In this case, the ICC has jurisdiction because the alleged crimes were committed in the territory of a signatory (Palestine) and because Palestine indeed found itself unable to prosecute them.
To do this in brick-and-mortar, you'd have to use remotely programmable price tags and detect who is looking at what, which seems doable, but then you still run into all kinds of tough questions with no good answers. If I happen to see the price tag change from $3.49 (perhaps set for the person in front of me) to $4.49 and I put that item in my cart, which price am I getting charged at the register? And did a legal sale even occur if I wasn't aware what I would be paying? I don't think it's going to work.
You do ideally want your own /24, though even that's not a hard requirement. And it can be provider-assigned space as long as your provider is willing to sign an LOA for you.
As for competitors, there are a few that start in the low 4 digits per month for similar services. That's not to say Cloudflare doesn't have anything unique to offer though, they're great at scale and standardization.
This may tell you something about how keen Cloudflare are to handle traffic they themselves cannot decrypt.
I'm not pjmlp but I can explain this for the case of Rust, where this works a bit like C but with a few interesting differences.
Mainly, in Rust there is not a concept of a "memory object" per se in the runtime semantics. Memory is made of allocations and allocations are made of bytes. Unlike C, bytes are guaranteed to be 8 bits in size. Every byte of memory can hold integer values (0x00 to 0xff), pieces of a pointer or be uninitialized. That means there is nothing like strict aliasing, and therefore no need to have special rules for byte-level access. You can alias any type as any other type, so long as you avoid all the other sources of UB (out-of-bounds access, uninitialized memory access etc.).
The way to practically access this is much the same as in C. You can do things like cast pointers between different types and project a pointer to a struct to a pointer to one of its fields. It should be noted that, unlike with major C implementations, structs do not have a stable, well-defined layout, so if you do manual pointer math you need to put #[repr(C)] on the struct to get C layout rules (which might still yield platform-dependent field offsets, e.g. size_t is not the same size everywhere).
Note also that these are the dynamic rules of Rust, you need to follow these when writing unsafe code to avoid UB. The static rules of safe Rust are much more restrictive and don't allow much at all. It is possible to write unsafe code that exposes safe abstractions for this, one example is the "bytemuck" crate. It provides macros that can parse a type definition to check certain properties (e.g. well-defined layout, no padding) and then provide you with safe functions for byte-level access. Since there is no strict aliasing, for certain types you can also get safe functions for access at other granularities. For example:
#[repr(C)] struct Foo {
x: u32,
y: u16,
z: u16
}
#[repr(C)] struct Bar {
x1: u16,
x2: u16,
y: u16,
z: u16
}
NixOS by contrast takes the entire Linux userland and makes it an immutable, dead compiler artifact. So it is to debian like C or Rust are to Lisp.