This is indeed sad. We are/were a customer, and one of the earliest edge computing customers. For a long time they've been the only provider truly offering the ability to run native code at the edge. But they've not really taken advantage of their early lead, so others have caught up. Also, reliability and capacity problems have become very commonplace in the past year or so. Hope the team has a safe landing elsewhere.
Great write-up! One question I had was around the use of keepalives. There's no mention in the article of whether keepalives were used between the client and reverse proxy, and no mention of whether it was used between the reverse proxy and backend.
I know Nginx doesn't use keepalives to backends by default (and I see it wasn't setup in the optimised Nginx proxy config), but it looks like Caddy does have keepalives enabled by default.
Perhaps that could explain the delta in failure rates, at least for one case?
That 15Mb/s figure for 4K is out of date by a couple of years. They previously targeted a fixed average bitrate of 15.6Mb/s. They now target a quality level, as scored by VMAF. This makes their average bitrate for 4K variable, but they say it has an upper bound of about 8Mb/s.
See https://netflixtechblog.com/optimized-shot-based-encodes-for...
The same author has been reporting diligently on Pollen, and has said he will do a write-up on the collapse there. I will be very interested to read that.
I'm not so sure. If I load a saved map in Google Maps (e.g. someone has saved a route with markers and shared it with me), and then I go offline whilst viewing it, Google Maps on Android will show an error after a while and I'll lose the route and markers entirely. This occurs even if I've marked the area as an offline map. I guess it's just a case that they treat the saved routes in a different way. But it's really annoying for my use case (which is finding crewing points for long distance running events in the middle of nowhere with no mobile coverage).
There isn't an "official data source" for RDOF evaluation. ISPs are required to carry out measurements in the markets where they've accepted funds. Measurements are carried out on a sampled subset of their customers, and a large set of frequent measurements has to be produced from each customer. Measurements have to be conducted to servers in specific locations (you can't just test to a server two miles down the road inside the ISP's network). The requirements are pretty rigorous and not straightforward to meet (e.g. if a customer switches their router off for a day, then that can disqualify their measurements entirely - you need a sample every hour, every day for at least a week in the quarter). They need to submit these measurements to USAC at the end of the quarter, to demonstrate that at least X% of measurements met the target of Y (it varies by metric).
Generally speaking, crowdsourced measurements (whereby you have loads of users but each running very few tests) aren't well suited to these requirements.
My experience with Paypal is the opposite. On multiple occasions I've had someone send me money on Paypal, but then it gets held up in checks and verification for 2-4 weeks, during which time I cannot access it. Sometimes it is instant though. There seems to be no pattern to it. This lack of certainty discourages me from using Paypal to receive payments in the future as I now consider it as a risky, slow, last-resort option.
I've been using Gen1 eeros since they were first released in around 2016. They're still getting software updates and they're still rock solid.
I'll be first in line to purchase a new set if they offer a model that supports PoE here in Europe.
Disclaimer: I've done a bunch of work with the Eero team from 2015/2016 til present day. Their team has an extremely high concentration of very smart and talented people, they are great to work with.
For what it's worth, we run "edge compute" with two separate mid-sized CDNs and pay about $0.005 per GB. This required a bit of negotiation, but has no minimum commitment and is on a monthly term. Yes, even lower fees can be had if you build your own infrastructure and pay for bandwidth on a CDR, but this is a fairly apples-for-apples case where we are not doing that.
So yes, AWS, GCP, Azure bandwidth pricing is very high. Oracle is, amazingly, the outlier with lower bandwidth pricing.
Filtering out the spam results is only half the problem. In my experience, a legitimate site's content is cloned by a spam site, and that one appears in a Google search and the legitimate one does not. The example that keeps hitting me is GitHub Issues.
Filtering out the spam only removes the clones; it doesn't get the good results back in.
I also haven't received one. Checked spam too. My server is a 61 EUR/mo, and is a Xeon E5-1650v3 with 256GB RAM. It was only provisioned a few weeks ago.
Enjoyed reading your bio on your website. Sub 24 hour at Leadville is super impressive! (Coming from someone who has not managed 24 hours at Western States... Yet...)
I hadn't heard of Tom Lane before. But his prolificness in contributing led me to search for him. And wow. He has quite a history. Co-author or the PNG spec. Major contributor to JPEG's success. Not to mention postgres. At 66 years old and still so actively involved! Very impressive
> I would still rather work with Postgres AND have to juggle a connection pooler
Is this comment relating to the overhead of idle connections, which has historically necessitated the use of a pooler in front of PG? If so, I believe this is resolved in postgres 14
We use the excellent gdnsd (https://github.com/gdnsd/gdnsd), mainly for its geo-DNS configurability. Have been using it for probably 5-6 years now, handling hundreds of millions of queries per day, and never had an issue with it.