IMHO this is way easier than without Nix in many cases as figuring out the upstream build process and getting it running can often be quite the chore. With Nix it is all set up for you.

I'm not sure if it is possible to solve this nicely in a generic way, but it does make it a bit ugly.

https://news.ycombinator.com/item?id=49824189

Comments URL: https://news.ycombinator.com/item?id=49824189

Points: 5

# Comments: 0

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.

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.

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

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.

Request amplification via retries is a different problem that causes large amounts of traffic (but it is generally more steady than spiky)

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.

The main downside is if you need to affect the dialog from "outside". For example data that refreshes and needs to update the form (although in most cases a changing form is an anti-pattern anyways). But also any form of dynamically updating data (a clock) or lazy loading (maybe for a dropdown that depends on others) you are going to want a full UI library rather than a one-shot declarative form.

When I used this I had a separate call to create the dialog and await the result. This way there is a handle you can use to update the data if you need to. But even then if you are using React it probably doesn't integrate as cleanly as a "regular" component would.

But still, I think in most cases this is what you need and the easiest way to get it. I wouldn't take a more complicated approach until you need to.