I'm 99% sure the Computer Fraud and Abuse Act covers this. The problem is that it seems that none of the victims want to, or are brave enough, to sue a company with absurd amounts of funding.

If it's covered by criminal law they don't need to sue. They can call the FBI.

Same FBI that prosecuted the Epstein crime ring so aggressively!

It shouldn't actually take that much bravery. If your case isn't completely frivolous, isn't your maximum loss limited to the court filing fees and a lawyer payment that you know in advance and can decide when to stop paying? It's not the same as getting sued.

Or the victims have no incentive to do so, such as in the Hugging Face case.

Documenting public water sources is an incredible public good. I thank you for your efforts.

How does Rust help with 2 at all? IIUC the main requirements were not memory or performance related but TPM and instruction set minimums.

No, but my credit card has no battery, requires no cell service, is waterprrof and quite durable.

I see the advantages of the Chinese system but I really found myself missing my card.

- While payer-offline payments were possible most merchants didn't want to (and some seemed unable to) so payments in places with bad cell service were painful.

- It was a lot more steps to open the app and enter scanning mode or display your code than to just tap a card or phone.

- It was always unclear if you were scanning or being scanned, leading to friction for every payment (generally larger brands scan you and you scan for smaller merchants).

Honestly for in-person card payments are just nicer.

For online WeChat was better, but no different than Apple Pay or Google Pay except for course that it is standardized by the government.

This is almost certainly a you problem. Tons of people play remuxes with Jellyfin.

I would check that your client supports the requisite codecs, and has a sufficient network connection. Or alternatively check that your server has enough horsepower (GPU or CPU) to transcode.

Probably because the account has only ever submitted its own content.

https://news.ycombinator.com/submitted?id=LabsLucas

> Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.

> https://news.ycombinator.com/newsguidelines.html

Yes, I found this comment very hard to understand until I realised they were talking about it being opt-out with no setting to change it. (At first I thought it was opt-in by default, and the "by default" implies that there is a setting to change the opt-in/opt-out setting)

This also has nothing to do with GrapheneOS except for some user overlap.

If anything, it seems more poised to damage the usability of systems which actively rely on Aurora Store, like CalyxOS and the likes. Graphene actively discourages using Aurora.

It sounds like you are just writing your own allocator? That sounds great, but why is it going to be better than jemalloc?

There are many reasons a specialized allocator can be better, but just saying "write your own" doesn't really add much value to the discussion.

If you squint, even their TLV encoding in a Box<[u8]> is kind of a specialized arena allocator.

It seems that you could just compile the data into the WASM blob. Then use a more optimized query engine than sqlite. This should be very fast to compile (most of the WASM is just a byte buffer, the code is just a few binary searches and some result encoding). The downside is that you need to recompile to update the repo, but I don't think that should be particularly expensive.

That's an interesting idea as well. Daniel wrote https://github.com/danielfullmer/nkv which also was a pretty fun experiment on how to improve data access within Nix. I love these cursed ideas.