matsur

Thinky has a potential answer in Tinker — give away the weights and charge for the SFT (and maybe RL down the line) to make the model more capable for specific tasks.

Plot here is quite thick. SF selling power to PG&E to distribute was found illegal/in violation of the Raker Act by the US Supreme Court in 1940 in United States v. City and County of San Francisco.

SF shifted to "wheeling" instead of selling power to PG&E and is tenuously in compliance now, but the current set up was never intended when the federal government ceded water and power rights from Yosemite to SF.

Firetiger | Product Engineer | San Francisco | Full time, on-site

Firetiger is building self-driving software operations. We believe the future of DevOps isn't better dashboards (like Datadog), but autonomous agents that monitor, investigate, and remediate issues based on high-level business goals. We are backed by Sequoia Capital and founded by Rustam and Achille, former leaders from Cloudflare and Segment.

We are looking for a Product Engineer to build the interfaces between humans and AI agents running software on behalf of those humans. More here: https://jobs.ashbyhq.com/firetiger/f5d4ba4b-29c8-4f77-bae8-8...

People were saying the same thing about AWS vs SaaS ("AWS wrappers") a decade ago and none of that came to pass. Same will be true here.

I've used it quite a bit/have vibe coded quite a few "real" things with it in various languages. It's a really nice complement to Cursor-style and claude-code style interaction modalities.

The amount of work required to stand up 330 well connected locations and then operate infrastructure to filter traffic at that scale profitably is more than "tossing" cabinets at problems.

This is on the level of BrandonM's famous comment on Dropbox. https://news.ycombinator.com/item?id=9224

Congrats on the launch. A small nit re: your pricing: you're charging for data transfer (bytes transferred over a long period of time), not bandwidth (bits transmitted at a point in time).

Both.

Very possible there were creds etc accessible in Servicenow that could have been used to move laterally from there. Conjecture, obviously.

eg "Hans Jansen" is <hansjansen162@outlook.com>

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

Major outages are periods of intense stress and extremely difficult to operate in. The folks troubleshooting may be many things, but careless and incompetent are unlikely to be among them.

You have no contact info listed!

"L" has a red ring and everything!

This is the real question. Mountaineers use scales, not calipers, when packing.

Sport vs trad grades outdoors are very different animals.

This is not theoretical — Slack had a domain wide outage recently. https://slack.engineering/what-happened-during-slacks-dnssec...

https://tax.thomsonreuters.com/blog/are-employees-taxed-on-t...

ICMP response time not useful for “locating” an anycasted address, some of which have logical location associated with them. See https://blog.cloudflare.com/icloud-private-relay/ for an example

A lot has changed (grown) in the 5+ years since that was published.

Quoted airfares are required by law to include taxes in the US.

You can still ask US passport control for a stamp if you really want one.

Or use a ziploc bag. Works fine.

This is a problem in theory. In practice (and through experience) we see very little routing instability in the way you describe.

The ferry in the video uses cable based propulsion.

We have some data :) I’ll see if we can get a blog together.

QUIC doesn't imply BBR as congestion control. eg. Our (Cloudflare's) QUIC implementation supports multiple algorithms. https://blog.cloudflare.com/cubic-and-hystart-support-in-qui...

This is not how any of our VPN or VPN like products behave today. There was a time when this was true for our consumer WARP app

Amusing to see “check if the handle opens the door” as an explicit step called out multiple times.

You still have to worry about head-of-line blocking across streams with H2. HTTP3 promises to really really fix these issues.

We use a phased rollout process for all routine changes (like this one). Once a change has passed peer review and the "dry-run", changes are rolled out to progressively larger slices of our production environment, with monitoring systems and engineers watching for adverse effects.

The specific network locations that were impacted by this change were amongst the last to see the change rolled out. One deficiency in our deployment strategy (which we will correct) is that no network locations in the affected "MCP" configuration received the change early in our rollout process. If that had been the case, we would have found the problem much earlier and the incident's impact would have been much reduced.