rbranson

As it turns out, not everyone who works in tech in SF is an opportunist. There are plenty of kind folks who just want to make a life for their family, but like any boom, it also attracts a multitude of people who are just here for the money and don't give a damn about the city or region.

> The fact that you're white and a tech worker isn't the problem. It's that you had the opportunity to move to San Fransciso for work due to the tech boom, and now you're trying to pull the ladder up so others cannot do the same.

This is quite the ad hominem. I may have missed it, but I'm not sure where OP said anything about density or housing. Is there something wrong with not wanting the city that you love to be invaded by the human version of a swarm of locusts?

Segment employee here. Our Kafka runbook looks 100X cleaner after this tool was rolled out by Ben and folks. One of my favorite parts is how it makes dangerous things harder :)

This is the correct take. Generally speaking, the prices set by Epic before this stunt likely approximated the highest price which didn't reduce aggregate spending.

The whole point of having the prescription drug system is so that patients can be provided with safe, monitored access to potentially dangerous drugs. The entire purpose of a doctor being involved in the system is to prevent the outcome we are experiencing, otherwise they'd just sell these things over the counter.

An investor taking credit for founder's work is probably NOT the way to build an iconic company.

https://twitter.com/rabois/status/1260257254957215749

Apple's history is mostly using older designs for the lower end devices. They are completely different chips, not just a lower frequency version of the same part.

I don't think binning is as big of a deal as it's made out to be. What does Apple do with the "low-bin" A13s, for instance?

Windows 2000 came out before Windows ME.

Author here. This should not have included INSERT. I updated the post to reflect that. Thanks for picking this up.

The new SFO arrangement is a huge improvement. At peak times it used to take 10-15 minutes for a ride share to make it from the entrance to Terminal 3. Now it takes 2-3.

How so? I’ve never seen a gigE port that didn’t also support 10/100.

I am extremely excited about this development. Less so getting everything that assumes x86 in the stack supporting a “parameterized” platform.

(Hi Michael!)

Oh brother. Silicon Valley deserves to be dragged for a lot of garbage... truly... but calling the whole SoftBank funded clusterfuck the “Silicon Valley Economy” is just nakedly intellectually dishonest.

Does the contemporary New York Economy connect people around the world and put all the worlds knowledge at your fingertips? Oh no, they just wreck the economy as a whole and feed us garbage like how they create value through “liquidity.”

How about the Washington DC economy? You know, the old joyful military-industrial complex that sucks in taxpayer money and converts it into dead civilians in the Middle East.

Or maybe the other geographically centralized titan of the US, The Texas Economy? You know, the one responsible for many of the major geopolitical conflicts in recent history that is also a huge part of what is turning the only planet we have into an unlivable hellscape.

And as far as I can tell the whole SoftBank funded fake tech masquerade thing is starting to melt down, so?

FBIDs are complicated because the number space includes legacy IDs, but the modern space have a 24-bit shard ID prefix and a 38-bit autoincrement identifier. Two of the bits are “thrown away.” Timestamps aren’t involved.

EDIT: ugh. Still early for us slackers on the West coast to do basic math.

The ID generation code doesn’t use hashing and has nothing to do with Facebook. The blog post was published afterwards but the sharding code predated the acquisition.

Python 2.7 will be forked in...

AWS has always had high margins. And I don’t care if they are in a market position to dictate the short-term price, I believe it’s bad business over the long term. Charging more for the same thing is certainly not customer obsession.

Oh, and thanks for the middle school economics lesson.

RDS is a value-add on top of EC2. Therefore its actual price is the extra premium.

If a food delivery company doubles their fees from 10% to 20% and the restaurant cuts its price proportionally, do you really say the delivery price is the same?

The total cost remains the same but the value the customer receives from the delivery service per dollar spent has been cut in half.

As much as AWS wants you to believe otherwise, the actual price of RDS as a value-add is its premium on top of EC2 pricing.

Not saying it’s a bad deal. RDS is a great service. I’m saying that suddenly doubling the cost of a service is not a good look unless the value delivered is also doubled. As a customer, in what situation would you find this acceptable?

The RDS premium % is the same across the entire instance class. The pricing is all public. It’s simple math.

I’d buy the fixed cost argument if the premium % decreased as the instance size increased. It doesn’t.

My guess is that this is on-demand DynamoDB wrapped with a Cassandra-compatible frontend. Just based on the pricing and stated characteristics. It would be really hard to provide on-demand capacity for compute and storage using anything remotely similar to off-the-shelf Cassandra. The pricing looks like DynamoDB on-demand + a bit extra to cover the cost of operating the frontend.

EDIT: confirmed by an AWS employee here https://twitter.com/_msw_/status/1201924979647905792

By default Django closes PostgreSQL connections after handling each web request. I’m not certain but what we’re probably seeing here in latency is mostly the substantial overhead in setting up a PG connection. Redis will still be faster but I’d guess the gap would be significantly tighter with persistent connections enabled.

40,000 people per day? Seems a little high.

The order-of-operations is that it checks RocksDB first, writes to Kafka, and then writes to RocksDB.

If the write to Kafka fails, it re-positions itself in the input topic stream based on the offset annotation in the output topic's last message. The write never went to RocksDB, so it won't be considered a duplicate.

Recovering from a failed RocksDB write is more complicated. The output topic's last message will have an offset that will effectively be beyond the accumulated state in RocksDB. Transactionally the last input topic offset for each committed message is written to RocksDB alongside it. The recovery process uses this offset as a starting point when consuming the input topic. During this process, messages aren't published into the output topic until the offset read from the output topic is reached.

A counterpoint is our ingest-time deduplication system at Segment: https://segment.com/blog/exactly-once-delivery/

It's done at ingest time because Segment has a completely different use case. Message data fans out over multiple downstream systems, some of which distribute this data to systems outside of our control. However, if I were in Mixpanel's shoes, I'd probably do it how they're describing it here.

Citus is a completely different animal. This is just vanilla PostgreSQL with a different storage backend. No PostGIS either because just like RDS, no custom native extensions.

Someone is going to have to put up the money to buy the fleet of autonomous vehicles.