HN user

eep_social

921 karma
Posts5
Comments488
View on HN

when Amazon was first established, one of the largest loopholes that they had used..

I thought for sure you were going to mention USPS “media” rates which allowed Amazon to ship books very cheaply.

Interop standards for this like Open19 are not widely deployed and without interoperability it’s a dead end since you need the hosting provider to give you the drop to your rack or cage. Hyperscalers I don’t know, but I’d guess they don’t deploy rack density that calls for liquid cooling yet.

SFO Gate Explorer 3 months ago

I have also flown out of that airport. The early flights maximize viable onward connections but the logistics are a real pain.

If you tap into the address bar, start typing your search, type enough for it to be specific enough that autosuggest crap clears, and “On this page” appears. Wildly undiscoverable in practice.

In a similar vein, I remember encountering a site where the frontend enforced basic complexity requirements ala “use at least one number and one symbol” but the system would silently drop all non-alphanumerics when it saved (presumably in some kind of failed conversion on the way into the backend DB). So setting a password like “foo_bar4!” would become “foobar4” which was surprising. What blew my mind though was when I figured out the stripped password worked to log in, which was how I eventually figured out what was happening, escaped the reset flow, and generated a compliant password.

based on my experience, I suspect the latter

similar, user-hostile behaviors I have found include:

- wifi network passwords are persisted through a system wipe and reinstall in recovery mode - a phone home is required by an activation step during installation - bluetooth is always re-enabled after an upgrade

in high scale stateless app services this approach is typically used to lower tail latency. two identical service instances will be sent the same request and whichever one returns faster “wins” which protects you from a bad instance or even one which happens to be heavily loaded.

I wasn’t in C++ style land but my recollection is that distilled experience would be backed up by extensive mailing list discussions. in case of contention the discussion might extend into case studies or other quantitative techniques atop google3. It’s difficult for me personally to describe the impact (outsized)of a super-resourced monorepo for this kind of thing. also as gp mentioned, it was sometimes possible to automate changes to comply with updated guidelines.

I think six dev teams is small in terms of kube. I wouldn’t be surprised if that’s close to the perfect size to move onto kube and create and adopt a standard set of platform idioms.

at orgs significantly larger than that, the kube team has to aggressively spin out platform functions that enable further layering or risk getting overwhelmed trying to support and configure kube features to cover diverse team needs (that is, storage software doesn’t have the same needs or concerns as middleware or the frontend). this incubator model isn’t easy in practice. trying to adopt kube at this scale is very challenging because it requires the kube team to spin up and out sub-teams at a very high rate or risk slowing the migration down to a crawl or outright failure and purchasing e.g. off the shelf AWS because teams need to offboard their previous platform.

always been another group to move in and take up the abandoned land

Completely agree with your points, but I think it’s worth mentioning that the collapsing populations may not have been aware of this depending on their level of isolation and cultural view on outsiders.

seems well coordinated with the recent escalation of aggression around google accounts without a cell phone number attached “to help make sure you don’t lose access to your account.” complete horseshit, but they can get away with it.