HN user

karaziox

104 karma
Posts0
Comments18
View on HN
No posts found.

They offer (extremely) discounted Claude prices but you have to go through their gateway. They subsidize part of that, and they get the low price by reselling unused Max capacity, there's been a few posts on that in the past months. People are apparently getting 90% discounts on their claude use this way, tradeoff is that you have two companies learning from your data, instead of just one. So people use the same tools they use normally, but get it for a lot cheaper

In your example the src would be the "machine that is behind a NAT". That's the one the peer relay enable access to. And then all your other devices (that laptop) can reach it through the peer relay.

I was also a bit confused on the meaning of src/dst in the grants. The naming didn't match my thinking.

Maybe Skip SHA-3 9 years ago

But NIST didn't make that clear. The thing they made clear is in fact the exact opposite and the OP mentions it. They called it SHA-3, saying to the world that this was a better SHA-2. If they wanted to make clear that SHA-3 wasn't to replace SHA-2, they should really have named it something else. Now everybody not knowledgeable to the details will sadly assume the 3 is better than the 2.

Because cloning the dependency is not the issue here. CocoaPods is keeping its index in a git repo that is updated by the user as a way to get the latest index. This is the repo that incur a lot of requests from everyone.

Go get on the other hand doesn't keep any index. It just uses the url to download the dependency because of the mapping "url==project name" that exists with go projects.

If you can't track the binaries you are running you have a bigger problem than recompiling some of them. Security issues aren't the one in a decade thing, if you can't easily locate which code has to be updated, you are in trouble already...

Well, the specification defines two negociation procedures. You are not forced to support both, you are not even forced to support one, but then how would you make use of it? And you are also free to negociate it another way should you decide to. The spec defines the protocol, not the transport on which it is used or the way the underlying communication is established. They could have put the two negociation methods in another RFC for what it's worth, since they don't affect the inner workings of the protocol itself.

Because this one involve checking duplicates and does a fair amount of logic. When the process is crashing, all bets are off and you may not be able to allocate memory for this processing. This is why they simply dump all there is to stderr and exit.

Go was never designed for "realtime". Also, 32 bits wasn't the main compiler focus, 64 bits was. This problem being mainly fixed with the 1.1 release, this is a non issue now. The memory model seems pretty well defined without being too restrictive, with the recent addition of the race detector.. Go looks well equiped for this kind of problems and some pretty interesting projects are there to prove it.

These benchmarks seems to rely heavily on math operations and the Go bench seems compiled with gc. I suspect that gccgo with the latest runtime (There was no release of gcc with the 1.1 runtime yet) can show prettier results with the use of the more mature gcc optimisations.

go func(){ channel <- data }()

Here, you will never actually block on your send since it runs on it own goroutine. I can't see an actual use case for this kind of thing but since you are using this argument over and over then.. :)