revertts

I think you’re understating how many quic implementations exist. Google, Apple, F5, Facebook, Fastly, Cloudflare, Microsoft, AWS all have separate implementations servicing significant production traffic, most of them open source. That doesn’t even count the smaller, language-specific implementations. Searching for quic interop tests is a good way to discover the various implementations.

Failures while communicating to the external systems (the kv store and elastic in your example) are usually where this falls down. It's easy to build a system that's consistent ~90% of the time, but if you want to build a system where things like failures during snapshot write or failures during export to elastic are handled properly it starts getting complex (you will need to find ways to recover and retract data, or build smarts into the consumer to query around aborts, or find a way to do a 2PC-esque dance with the external system a la Kafka's transaction support, etc.). Getting to full consistency isn't easy.

It's very hard for Kafka Connect plugins to maintain consistency in all scenarios - both because of the semantics of some upstream databases, and because of the guarantees the connect API itself offers. Hopefully KIP-618 will eliminate more of the edge cases though.

IRC is excellent, and located around the Bay Area (there are usually at least a few people carpooling down from Oakland) - https://www.insightretreatcenter.org

It's the retreat side of IMC (https://www.insightmeditationcenter.org). You might listen to some of their talks or read some of Gil's writing[1] to see if it's what you are looking for. It's in the Vipassana tradition, though a number of the teachers had affiliation with the SF Zen Center.

[1] https://www.insightmeditationcenter.org/books-articles/natur... is a potentially interesting article

Were the amazon purchases all from the same amazon account?

Term coined by Jay Kreps, see https://www.oreilly.com/radar/questioning-the-lambda-archite...

That link's a 3min clip for non-subscribers, but the full talk is here https://www.youtube.com/watch?v=Bz2EXg0Fy98

Previously msvc's position was to not support newer C standards and instead focus on C++. This was stated publicly at least as far back as 2011 https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

So any movement on C11 is a welcome change.

Allen Webster, the creator, was recently interviewed on the Handmade podcast. I thought it was a good discussion - touched on text editors, performance, and some interesting programming language ideas. https://handmade.network/podcast/ep/14a5407e-5f73-4c59-a422-...

Many of the current users, including the creator, are in gamedev. Being extensible in a language they’re already intimately familiar with is a selling point.

This is done by some apps today, though the motivation was typically network perf (http2 and then QUIC support). The stacks are large - on iOS it's difficult to take over a portion of networking without rebuilding a substantial amount of it, so you'll have TLS, a full http stack, plus all supporting logic for connection pooling, etc. The closest thing to an open-source, drop-in option like this is cronet, the networking core of chromium packaged as a standalone library. Last I looked it was multiple megabytes in size, which is still a substantial cost for iOS apps. They can also be quirky to use because they fight against the system's defaults in some areas and can cause other inefficiencies (typically outweighed by the network improvements).

I believe Uber talked publicly about adopting cronet, and Facebook gave a talk about mobile proxygen (though it is not open-source). If you pop open the Netflix and Youtube apps, you will likely see the same.

I read their point as “information hiding is not a concept exclusive to OO.”

Whether or not the original quote meant to imply that I’m not sure, but do see how it could be read that way.

I think the small upside (a single 5-star rating contributes very little to app ranking) is outweighed by the potential downsides (it can be a turnoff if the user sees that because it strikes of astroturfing, which seems a hot topic these days; it violates app store guidelines, though there's a close to zero chance of that being enforced).

To me it seems like unnecessary risk for little benefit.

Edit: And product reviews are not the same as voting. :)

It looks like there's a single 5-star review by "Benedict B." Did you review your own app?

Ah! I'm sorry, I had misinterpreted your original comment.

I agree, HashMap is unnecessarily hamstrung because the API requirements push it into a bucket chained implementation (C++ also made this mistake and is one of the downsides of std::unordered_map). And you can definitely write a faster implementation with an array based hashtable.

But I still stand by "you can only do so much being a reference heavy language." Unless you stick to purely primitive types, implement the hash table off heap, or Project Valhalla bears fruit, it's hard to get the data layout you'd want for a really good implementation. So I agree it can be better, but it's going to be hard to get to best - hence my comment.

There are cases where you need them, but it's relatively rare, they definitely shouldn't be your first choice.

I'm fuzzy on all the current Linux use cases, but do remember one of the main users of rb trees was CFS. It's a neat scheduling algorithm.

Java 8 specifically: HashMap is implemented with linked list chaining. This is already not very performant, but you can only do so much with Java being a reference heavy language. RB trees are used if the bucket chain grows excessively long - so it's addressing an edge case, speeding up some worst case scenarios.

Dense hash tables based on open addressing outperform bucketed chaining. Look also at abseil's swiss table or folly's f14 if you want to see how they've further advanced to take advantage of the hardware.

In general: flat, dense, linear structures are king for performance.

What's the best way to keep an eye out for that TR? Periodically checking http://www.open-std.org/jtc1/sc22/wg14/ ?

I can't ever tell if I'm looking in the right place. :)

> Put everything in a bowl

Care to share your measurements? I’m aiming for something similar, but having trouble getting my ratios dialed in.

How strange - OpenDNS/Cisco Umbrella seems to flag the domain and gives me a 403 Forbidden.

It's a net win for the ISP due to cost savings from not having to haul that traffic across their network/to the Internet.

You're right that powering racks isn't free either though: if the cache operator doesn't utilize the rack well and isn't offloading enough traffic to it, the ISP will give them the boot (as in, "we wheeled your rack out to our docking bay, come pick up your piece of junk if you want it back"). It's uncommon since _most_ of the orgs running these racks are competent, but does happen from time to time.

Also, even though it's a net win for the ISPs, there are still cases where the operator ends up paying them a fee. This has less to do with the economics of edge caching within an ISP network and more to do with the bargaining power certain ISPs have. The 2014 Netflix/Comcast peering agreement is a good example of how those things sometimes pan out.

That's correct - 'revokation' in this case would likely involve rolling the DNS name to something different. Since these racks tend to have precise targeting (ie. not dns gslb) and non-user facing names, there's more flexibility.

The delegated creds draft that regecks mentioned is also relevant. That will make issuing lighter weight, so this sort of 'burn the cert and roll the DNS name' procedure becomes significantly cheaper operationally.

RE: NSDI - Is the Firecracker paper available somewhere, or not yet?

Edit: I'm an idiot - https://www.amazon.science/publications/firecracker-lightwei...

Yup! Some of the names on that draft were people who have previously worked on building these sorts of edge racks, so their experience with this infra helped shape the proposal. It'll be great once it's broadly supported, but that's going to take awhile (or depending on your client mix, an eternity).

The problem isn't with terminating SSL, it's with keeping your keys safe on exposed infrastructure.

A single domain name and DNS to route is uncommon because it doesn't give you fine-grained control of load - you need to be mindful of the rack's capacity, and you also need to make sure that most of that ISP's customers go to the rack/people who aren't that ISP's customers don't go to it.

Anycasting isn't going to be great for traffic management or long-lived TCP conns, and if you can avoid the complexity of each rack needing a bgp session into the ISP's network you're going to be much better off.

Typically this is going to be directly routed to the rack via a unique DNS name after some form of service call.

It's a very good question! Figuring out security for these remote racks is one of the hardest parts. For some CDNs their larger POPs will be locked cages with security cameras and all, but these small deployments are significantly more exposed.

Exactly how SSL is handled (or not) varies by provider, but one thing I'll mention is that these will typically never have a cert so important that it can't be easily revoked, and the most important data will likely not be flowing across them - exposure is very limited. Using video streaming as an example, one option is to only do TCP termination for example.com (or to not even terminate that domain on the local cache, but back at your main datacenter), then use subdomains with individual certs for the local cache (eg. isp1.cache.example.com). In that case, service calls like login, retrieving the manifest, etc. are secured by the certs you're keeping in your primary dc, then the manifest has a set of https://isp1.cache.example.com URLs pointing to the local cache only for video segments.

Another tricky aspect is making sure that your main network treats them as untrusted so someone with local access can't use it to get a foothold into the rest of your infra.

Yes, but the peering/traffic teams are the ones that generally manage these embedded cache deployments, hence why related info are on the same pages as peering details or in PeeringDB. All the ones I linked do actually have edge cache racks, not just peering arrangements.

Completely right, it would've been more correct to say "saves money" and not specifically call out transit.

Qwilt and similar products are really neat, but I don't think they've entirely panned out. The idea to do transparent caching at the network edge was hurt by the move to TLS everywhere, and there's a lot less cost incentive when things like Open Connect exist (eg. if Netflix will give me a rack that offloads XX% of my total traffic, how much additional traffic do I need this transparent cache to offload before it's cost effective for me?). Without transparent caching the economics get trickier.

It seems like their niche is as an easy to deploy, more traditional looking CDN that can run out in the RAN, which does still have value.

There are some facility and org requirements depending on the various company's rack setups, but most of that's standard.

The main requirement is how much traffic you need to be doing with the peer before they give you a rack - Apple states 25Gbps; more mature programs like Netflix are 5Gbps. Sometimes that's negotiable and they'll hand them out for even smaller traffic amounts (I've heard less than 1Gbps for some of those listed, though won't mention which ones). Like most things in this area of networking, there's a lot of variability and personal contacts involved.