Semi-related: Firefox 142 was released a few days ago and is now using CRLite[0], which apparently only needs ~300kB a day for for the revocation lists in their new clubcard data-structure[1].
> You’ve asked us, “A hundred products is a lot. Can you please be more
> prescriptive?” and “Can you make your pricing more straightforward?”
>
> We heard that feedback loud and clear.
Every single package on the plans page[0]: "Contact Sales". ;)
In the context of snooping on the SNI extension, you definitely can.
The SNI extension is sent unencrypted as part of the ClientHello (first part of the TLS handshake). Any router along the way see the hostname that the client provides in the SNI data, and can/could drop the packet if they so choose.
In order to function, CDNs have to act essentially as giant opt-in MITM services. When you setup a CDN in front of your site, you will either need to give them your cert, or let them issue a cert (e.g. via let's encrypt).
If they can serve your site with https normally, they can serve any content they want under it.
This is about CFs public DNS resolver though, and not every domain they're ordered to stop resolving will also happen to be served though their own CDN. In this case it was, which explains how they're able to serve a 451 error over HTTPS, but that won't always be the case as the article implies.
In some other cases I suppose they could downgrade the connection to HTTP in order to show their 451 page, but if the domain is HSTS'ed then that wouldn't work either. That'd have to just black-hole the query like Google does.
I'm not sure why it would be different from any other hosting provider. They do clarify what they consider abuse / forbidden content, and their operational policies though:
At a prior job (fairly recently, past ~5 years), we still used ColdFusion MX7 for some internal apps and reports. They had been around for a long time, so don't break what works I suppose. :)
The biggest issue with them was that _some_ feature (cfform IIRC) was generating flash .swf input forms, which broke after the flash player EOL. Switching it directly to the plain html version wasn't compatible, so we had to manually fix a bunch of code.
Is there something in specific that makes this easier to use in Rust projects compared to the Lua wrappers/bindings like mlua[0]? Or is it just an overall ergonomics thing?
Genuine question, as I don't have any prior experience embedding any scripting language into a Rust project.
> By default mlua uses pkg-config tool to find lua includes and libraries for the chosen Lua version. In most cases it works as desired, although sometimes could be more preferable to use a custom lua library.
The fact that Rhai builds with just 'cargo build' shouldn't be underestimated - a Rust project with all pure-Rust dependencies is much easier to maintain / support / distribute across a wide variety of hosts!
Then mlua will statically build with the Lua sources it bundles itself and no need to link the system Lua or do anything other than "cargo build" like normal.
Zig is first and foremost a C compiler with cross-compilation being first class citizen so you can't really compare the two.
> Rather than developing and increasingly insular (navel-gazing?) ecosystem, it might be better to work on the root problem.
Every language has its own development budget and must focus on what makes more sense. Zig has great cross-compiling story and C is first class, Rust has a stable language, a compiler that doesn't crash and emits readable error messages, one has to set its priorities.
The good thing with zig is that you can use the zig compiler within Rust project to cross-compile C code (cargo-zigbuild IIRC) so you can have a cake and eat it too.
This is a very uninformed take. It's not a Cargo or Go problem, it's a C problem. It only works well with Zig because Zig goes to insane lengths to hide the problem.
In fact it's so much of a C problem that lots of people even cross-compile their pure C code with Zig, because Zig handles all of the C mess!
Perhaps instead the more constructive path would have been to try and defend why one (cargo, rust) cannot do what another (zig) can.
So far, all I can infer is an acceptance of how compiling C code is hard and rather messy. I am no more uninformed on this than this literally being a daily fact of my paid life, but do go on, tell me how I've missed the point.
The condescending tone started with you calling projects "deficient" for not handling problems well they don't want to handle. Yes, a C compiler is good at C things. It's not "deficient" if that C compiler sucks at integrating BASIC code.
Yes, it is designed for Rust, so the actual interop with Rust is very good. You can pass Rust types in and out with very little work, and they are represented in Rhai in a logical way.
Even something like a `Vec<u64>` is likely to be a right pain with Lua.
My frame: I would say that embedding in rust is hard, unless you are already thinking in rust. Mostly ownership things, which I see distinct from safety.
If you are thinking in rust already, why would you go to an FFI c solution?
(Source: have been prototyping DSLs in rust with most of my life force for about a year)
I'll concede on the joylessness front. However, I assure you that all the posts on my personal blog are 100% artisanal human-made joyless posts! No AI needed.
Yeah, I should probably update my Hugo theme to include the date (not that I ever write anything on there anyways TBH). Also, the I changed domains not too long ago, so that probably added some more confusion.
[0]: https://www.aljazeera.com/economy/2025/9/17/china-bans-tech-...