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.
> 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.
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)
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 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.
Thundering herd is different. Thundering herd is when a lot of clients trigger requests at the same time. Common situations being a specific time, some other event just occurred or synchronize on other parts of your infrastructure (such as readers queuing behind a R/W lock that then get unblocked at the same time to continue to make a bunch of requests at the same time.
Request amplification via retries is a different problem that causes large amounts of traffic (but it is generally more steady than spiky)
Sandboxing the process only works well when the malware requires more capabilities than the software itself.
So if your software needs to make HTTP requests and read the filesystem then the malware will be able to make HTTP requests and read the filesystem, which is enough for a ton of malware. Sure, maybe you can limit the directories it can access a bit and possibly some sort of network filtering, but it isn't a silver bullet.
Capability security in-language would make a huge difference, because the more granular you "sandbox" the less likely it is that the compromised component has the access it wants. For example if the HTTP client library is compromised maybe it can't access the filesystem so can't steal your cookies. Or maybe like in this case no permissions were needed at all and despite the process having enough capabilities for malware this malware can at worst return bad values and try to chain this to an exploit which is far more difficult than just running it itself.
(as I and others have mentioned in the thread): The attacker can just move the malicious code from build.rs to lib.rs (ie. build-time -> test/execution-time).
Then the problem is the language, as the grandparent observes.
reply