I think you know this, Jake, but just to clarify for everyone here, while WebP lossy and lossless are basically completely separate things, JXL’s VarDCT mode (the lossy JPEG-like mode) heavily relies on its Modular mode (the FLIF/FUIF-like mode). The original JPEG has a lossless method of compression, which applies after the DCT step, but it really sucks. Really basic prediction for DC values based on previous DC values, run-length encoding, and of course Huffman. JXL also has to losslessly compress stuff after the DCT step, and since it has a high quality lossless codec built in, it of course uses it where-ever applicable. So it’s kinda like how Opus has two modes, but they’re heavily integrated and work together.

(If I recall correctly, AVIF’s lossless mode is basically like JPEG’s lossless step. Its primary purpose is to compress the data after lossy encoding, so while it was repurposed for lossless pixel compression, it doesn’t work well for that use case.)

And of course there’s the fun patches feature, where the encoder can notice repeating elements like font glyphs and encode them separately on a sprite sheet to be inserted into the main lossy image. Oh, and another bit of trivia is that the Modular mode supports lossy operation. Obviously there’s the classic trick of tweaking your pixel values to have lower prediction residuals, but Modular mode actually has (imagine a drum roll) wavelets! Sort of. It can do a Haar-like transform. Actually, often when used with lossy VarDCT, often some of the associated Modular mode frames will be encoded this way.

score 1 · canonical

I don’t understand what you’re trying to say. Active vs passive is just two bits of grammar in English and other languages. One thing you can do with the passive voice is to not say who did something, yes, but the sentences above are simply communicating different things. One is not the passive version of the other.

There are many ways to obscure blame without using the passive voice. “ended up under” and “died” are both active, not passive.

Saying Hailey’s version in the passive would look like

Two young women were ran over [by him], and one was killed [by him].

It would be hard to add the detail about this being related to him driving home without the blame being very obvious, so the passive voice doesn’t work for obscuring blame in this case. So the author chose the active voice with a different choice of framing and different verb choices to obscure the blame instead.

It’s bad! I recoiled when reading it. It’s just that it’s bad for reasons unrelated to the passive voice.

score 1 · canonical

That’s not even passive vs active, that’s saying two completely different things.

score 1 · canonical

Does anyone know how to get Factor running with Musl Libc on Linux? I’m the sort of funny person who runs Alpine on their desktop.

score 1 · canonical

I wrote this last but decided to put it up front rather than at the end: despite all the arguing, I do find Fil-C to be pretty cool, and I hope you’re successful with it! I’m just skeptical, and disagree with your thoughts on CHERI.

If you try to compile an allocator that isn’t safely implemented on CHERI, it’ll just work - you might not even notice.

If you try to do it with Fil-C, you get a runtime error.

Nothing prevents you from enforcing something similar under CHERI. Fil-C has a single blessed alloc, and prevents other allocs from being implemented. This presumably also means blocking all system calls that might be used to implement an alloc. Ultimately, my point is that since Fil-C is software, and CHERI simply adds additional HW features, anything you can do with Fil-C, you can definitely do with CHERI. And any time you figure out how to leverage CHERI to do one of the things you want to do, the hardware is now helping enforce it.

CHERIoT has a shared heap between all compartments, and a single allocator. It enforces quotas, and gives you full spatial and temporal memory safety. As someone in the embedded space, I find it incredibly compelling.

That’s true! CHERI means you don’t need a type safe language to get some kind of safety.

But you need special hardware, which makes it kinda impractical.

But it also means that Fil-C isn’t memory safe in practice, since any Fil-C code will surely often interact with code that isn’t Fil-C. That’s one thing I like about CHERI; memory safe languages may be safe within their own specified semantics, but that falls apart as soon as any external factor may violate the invariants of the safe language. With CHERI, you can know that your nice and safe OCaml program won’t be screwed up by some C++ library you needed to use. Like, I’m a huge Rust fan, but I got to admit, CHERI plugs a big hole that currently affects all safe or semi-safe programming languages.

And idk how practical it would be to replace all not safe code. Fil-C helps a lot with some of it, but far from all.

Right! That’s the key difference between CHERI and Fil-C:

• For CHERI to be successful, the CHERI folks have to convince at least one vendor to ship it, and that vendor had better do a good job of it or it’ll taint the whole project. Yeah, ideally they’d convince all the vendors.

• For Fil-C to be successful, I just have to either (a) convince one person to make a useful thing on top of Fil-C or (b) port some useful thing to Fil-C, where that thing becomes much more useful with the added security and not much less useful due to the perf overhead. So, the adoption bar is inherently lower. Sure, it means code changes that CHERI won’t require.

Note that CHERI is shipping later this year in a microcontroller. And if I recall correctly, at least one other microcontroller vendor is also designing a CHERI chip. So it’ll be able to prove itself in the real world soon. Of course, there are a lot of differences between the world of embedded and the PC / server space. If the standard is “make one useful thing on top of”, then I think CHERI will succeed :)

You may be surprised, but CHERI already has a decent amount of momentum. Couple hundred million invested, a good number of companies, mostly in industries where safety is important, doing CHERI things. A few governments even recommend CHERI already, even though no hardware is generally available yet.

Also, I’m curious, you’ve mentioned that you’ve found it to be pretty easy to port C projects, but what about all the code that isn’t in C? There’s tons of C++ and Rust out there, which CHERI would make safe, but as far as I can tell, Fil-C would not. So regardless of all else we’ve talked about, CHERI casts a much broader net. Personally, I’d prefer to never write C ever again, even if it was to be made entirely safe. So in any situation where I need a “low level” language, it’d probably be Rust, possibly with some unsafe {}. So from my point of view, while both CHERI and Fil-C promise to help with (some of) the code we already have, only CHERI promises to help with new stuff.

score 3 · canonical

If I understand your comments elsewhere correctly, this would stop working as soon as the user tried to store something of another type there? Like storing a pointer, and then replacing it with an int, and then replacing the int with a pointer, and so one.

I should not have been writing comments at 1 AM, because with not tired eyes I see that you were obviously talking about boxing integers in pointers, apologies.

score 1 · canonical

Because int-to-ptr casts work, that code would work in Fil-C so long as the store operation knows it’s storing to a ptr.

If I understand your comments elsewhere correctly, this would stop working as soon as the user tried to store something of another type there? Like storing a pointer, and then replacing it with an int, and then replacing the int with a pointer, and so one.

Also, I just don’t understand your claim that Fil-C is safer. If the user can choose to do things that makes CHERI less useful, surely they can just choose to not use Fil-C? If “can’t make your own alloc” is acceptable, that’s very easy to enforce on a CHERI system. All of Fil-C’s properties depend on user choice and implementation. And if you pre-suppose good user choices and implementations, then CHERI does not have the drawbacks that you claim. CHERI also has something Fil-C does not. Relevant quote:

If you wanted to call between Fil-C and C# then you wouldn’t compile the C# runtime with Fil-C. Ditto for Java/Rust/JavaScript/etc.

This means that Fil-C must simply trust that everything else in the same address space is not doing anything bad. That every Rust unsafe is definitely correct, that the JS implementation has no bugs that would allow writes elsewhere on the heap. CHERI on the other hand can allow safe single address space sharing that is also totally safe.

You probably have to do that and then some, because you’re trying to convince people to buy hardware that they dont want.

I’m pretty sure they want all vendors, such as Arm, Apple, Intel, and so on, to add CHERI to their products. So there would be no need to convince people to buy special hardware.

score 5 · canonical

In terms of language semantics, CHERI doesn’t really enforce anything on its own. When you target CHERI, you choose how to use its primitives to enforce whatever properties you want to enforce. CHERI allows ptr->int->ptr because C mandates it.

For example, because CHERI allows ptr-to-int-and-back “transmutations”, you could write code on top of CHERI where you have a custom alloc and all of your pointers end up having enormously powerful capabilities. (Plz correct me if I’m wrong.)

I don’t quite understand this. Even without ptr->int->ptr casts, an alloc implementation could certainly choose to return very powerful capabilities, as powerful as whatever the allocator itself has access to. But you’d probably choose to use an alloc implementation that doesn’t do that, just as one can choose whether to use Fil-C or not.

score 1 · canonical