HN user

NovemberWhiskey

8,299 karma

You can email me at novemberwhiskey.hn@protonmail.ch

Posts2
Comments2,513
View on HN

The real problem is that sticking an idempotency key onto an operation doesn’t make it idempotent.

It may improve efficiency where a protocol doesn’t assure exactly-once delivery of messages, but it cannot help you with problems other than deduplication of identical messages.

Creating a payment is not an idempotent operation. If the economics of the operation can differ when the “idempotency” key remains the same then you’ve just created a foot-gun in your API.

You can document that you’re going to ignore “duplicate” requests that share an idempotency key but that’s just user-hostile. The system as a whole is broken as designed.

The real world is full of relationships that may or may not exist. What’s the referent of “my spouse” if I’m unmarried?

Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

I mean, the fundamental premise of formal methods is that assurance of correctness is achieved through unambiguous specification/modeling and mathematical proof. The extent to which you're dependent on dynamic testing of actual code to achieve assurance does speak to the extent to which you're really relying on formal methods.

Things can only be used securely if they have properties that can be reasoned about and relied upon.

This is why we don't usually have critical processes that depend on "human always does the right thing" (c.f. maker/checker controls).

"Soft" realtime just means that you have a time-utility function that doesn't step-change to zero at an a priori deadline. Virtually everything in the real world is at least a soft realtime system.

I don't disagree with you that it's a realtime problem, I do however think that "just" is doing a lot of work there.

I am not sure that static analysis is ever going to give answers to those questions. I think the best you can hope to do is surface knowledge about the tacit assumptions about dependencies in order to explore their behaviors through simulation or testing.

I think it often boils down to "know when you're going to start queuing, and how you will design the system to bound those queues". If you're not using that principle at design stage then I think you're already cooked.

Outside of a very narrow range of safety- or otherwise ultra-critical systems, no-one is designing for actual guarantees of performance attributes like throughput or latency. The compromises involved in guarantees are just too high in terms of over-provisioning, cost to build and so on.

In large, distributed systems the best we're looking for is statistically acceptable. You can always tailor a workload that will break a guarantee in the real world.

So you engineer with techniques that reduce the likelihood that workloads you have characterized as realistic can be handled with headroom, and you worry about graceful degradation under oversubscription (i.e. maintaining "good-put"). In my experience, that usually comes down to good load-balancing, auto-scaling and load-shedding.

Virtually all of the truly bad incidents I've seen in large-scale distributed systems are caused by an inability to recover back to steady-state after some kind of unexpected perturbation.

If I had to characterize problem number one, it's bad subscriber-service request patterns that don't provide back pressure appropriately. e.g. subscribers that don't know how to back-off properly and services that don't provide back-pressure. Classical example is a subscriber that retries requests on a static schedule and gives up on requests that have been in-flight "too long", coupled with services that continue to accept requests when oversubscribed.

Lithium-ion is an umbrella term that properly includes common cell chemistries like lithium iron phosphate (LFP), lithium nickel manganese cobalt oxide (NMC) and lithium nickel cobalt aluminium oxide (NCA).

It doesn't make sense to compare LFP vs. lithium-ion, because the first is a sub-type of the second.

I think this depends very much on how you use the tools.

My experience with email is that people have subject lines, email explicitly identifies to and cc recipients; email is threaded; email often has quotes/excerpting/highlighting from prior parts of the thread.

On the other hand, most chat usage I see is dependent on temporal aspects for threading (people under-utilize platform features for replies etc), tagging is generally only done to ping people to attract attention, chat groups are frequently reused for multiple different purposes.

Leaping to a point-in-time within a chat stream is often a bad user experience, with having to scroll up and down through unrelated stuff to find what you’re looking for.

Stuff in email is just massively more discoverable for me.

That's transparently obvious if you read the press release: Trump analogizes his own personal treatment by the Justice Department with that of Ulbricht c.f. "weaponization of the justice system".

Bernie Ebbers and Jeff Skilling both got more than 20 years for Enron. The CEO and co-owner of NCFE got 30 years and 25 years respectively for their role in a securities and wire fraud relating to that business.

Pray tell, what is the difference between operating an electronic market where people can buy drugs and operating a physical one (say, a street corner) where people can do the same?

We punish people all the time for non-violent, white-collar crime; often very severely. Bernie Madoff got sent to prison for 150 years and died there and, as far as I know, he never solicited a murder for hire.

I don’t think anyone is disputing that changes to diet and exercise are required.

Based on people who I know have been taking these drugs, they make it much easier to reduce calorie intake by promoting satiety. That’s the benefit.

Doing the rest of your life while you feel hungry is not fun, and willpower is not infinite.