HN user

floober

104 karma
Posts2
Comments27
View on HN

And yes, in finance, the correlations between asset classes shoot up toward 1 in periods of crisis (black swan event) . Hence, the research for tail-hedging strategies...

Related to what you said here, I was surprised there wasn't a comparison with Vine Copulas in the paper or thread! But this is pretty far outside of my realm of expertise, so maybe it shouldn't be surprising.

So they set out to describe it as „an accident“ because „blameless post-mortems“ are something people really like?

As someone who has operated bug bounty programs, understanding what processes might have prevented things from going off the rails _in spite of_ internal actors with different motivations is very helpful to me. Placing all of the blame on an individual removes the opportunity to improve things.

This looks fantastic! I'm working on a desktop app and I've been struggling with the extensibility story in the back of my mind for a couple of weeks now.

Thanks for building this!

edit: For what it's worth, the use case and value of something like this was immediately apparent to me.

For me, I use the simple stuff (Semigroup, Monoid, Monads, Functors, ..) the most. Often times I'll be reasoning about a problem I'm working on in Haskell and realize it is a monad and I can reuse all of the existing monadic control structures. It is also helpful the other way, where you start working with someone else's code and seeing that it is a e.g. Monad immediately tells you so much concrete info about the structure, where in a less structured language you might need to reed through a bunch of docs to understand how to manipulate some objects. The "killer app" is all of that extra structure shared throughout all of the codebases.

Right? Also these companies probably hired a lot of folks during the pandemic, and also relaxed their performance criteria while everyone was adjusting to remote work... So this just sounds like some folks are being caught off guard by the fact that yes, there are real performance expectations and you might not be meeting them.

Agreed. If you're an individual who wants to work this hard, hopefully you can find a team of like-minded folks who will work hard with you and make sure that it is structured in a way that you all reap the benefits.

Flask is a multi-threaded server, so while only one thread can execute Python code at a time (due to the GIL), you still get concurrency with respect to IO. Not to say that e.g. FastAPI won't get you more RPS, but it may or may not be as dramatic as you would expect.

I definitely had some uncanny valley vibes watching it, but I think it might be a combination of the camera's perspective (distorting distances away from center) and the footage being sped up/slowed down.

In the physical world there are folks who design bridges, dams, buildings, telescopes, furniture, and a million other things. All of those have unique requirements and skill sets. In software, we also make a huge number of categorically different systems each with its own skill set, but we call all of it 'software engineering.'

There are folks who are great at their job (called "software engineering") and their work never invokes their knowledge of algorithms. There are also folks who spend day in and day out tuning and designing new systems and deep knowledge of algorithms is essential (we also call this "software engineering").

It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason);

I assume this is so a relay can't manipulate your messaging by picking and choosing which messages to forward; they'd have to forward messages [0-N].

Edit:

sig: <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>

Signed hash rather than a mac - might be vulnerable to an extension attack

I don't have an Oculus or even Facebook, but I remember a decade ago that my older relatives were hostile toward the idea of Facebook and moving aspects of their daily lives online. That all changed very quickly and has been very profitable for FB. I don't know if it will be brought about (in part) by Facebook, or if it will even happen anytime soon, but something akin to a "metaverse" seems almost probable to me at this point

I agree that it doesn't improve things at the service interface level. What I have found is that I often have several internal libraries, and a monorepo ensures that I know if a change to my library breaks another service because they're all in one build. Keeping things consistent across services is very useful in my experience.