If you load an issue page, you'll see 1 failed request to:
/project/product/issues/<number>
And sure, that's what you care about, but consider the working requests to:
/in-product-messaging/copilot-budget-request-banner
/in-product-messaging/code-scanning-ai-findings-preview-banner
/github-copilot/chat
/_private/browser/stats
If page has 15 requests and needs data from all of them to work correctly, then with 20% failure rate you are suddenly close to 100% non-functional page from the user perspective.
A technique we've used to deal with this situation: in the overloaded backend (that has to reject some percentage of incoming requests), group the incoming requests by the parent request (the one with the 1:15 fan out) and reject according to the parent request. One way to put it, simply (though somewhat inaccurately), would be: reject 100% of traffic from 20% of users, rather than 20% of traffic across all users (causing essentially full failure for all users).
We typically implemented this by propagating an ID of the parent request down to the backend. I'm simplifying a lot in this description (e.g. have to deal with the parent requests landing on different backend tasks; also rotate the IDs gradually to introduce some fairness).
A nice technique to learn of this situation is to fail ("black hole") random resources in synthetic loads of the frontend. This lets you find out 'bout these single points of failure, and then you can start adding fallbacks.
It's easier to create a nice worst-case failure UX this way too. Rather than a page that sorta kinda loads but doesn't actually work at all you can unambiguously put up a "oops we're broken right now try again later" page whenever that top-level endpoint returns a non-retryable error.
But that of course begs the question--why is the frontend retrieving all these data from 16 different endpoints instead of just one? It would be less overhead (http, auth, serialization, compression) to just serve it all in one request even if the http layer needs to fan out 15 rpc calls... this is why we can't have nice things.
Shyeah, all those successful requests were really helpful for showing me a page, which then failed when I tried to do anything by clicking the buttons on the page. I was completely unable to merge things for hours, for no lack of trying. GH was down.
I personally find a prop to be a perfectly acceptable solution - you can define styles in your JS and share between components if need be. But I reckon there are folks who'd prefer passing class names to define their styles in CSS.
The "build quality" means it looks nice, but it sure isn't durable. If you spill liquid on an Apple, it's a dead machine. If you drop an Apple, it's also dead. Thinkpads can survive a hell of a lot more abuse.
Every time a friend or colleague asks why I use "that" I simply thrown my laptop to the floor, pick it up and continue working on it.
Then I ask them to try the same with their Apple laptop.
That normally makes them never ask such questions again.
I learned that from an IBM (and later a Lenovo) sales person when presenting the X series. It's designed and built to tolerate real use. And some abuse :-)
I've used laptops for the last 10-15 years, often 8+ hours a day. I have not once dropped a laptop during those years. I'm completely okay with having a laptop that disintegrates when dropped and is better in other ways (thinner, lighter, longer battery life) as a result of not focusing on resistance to drops.
I guess it depends on your laptop. I dropped Macbook once (it was closed and there was a big scratch on case), but otherwise I'm very careful with it. I didn't drop my iPhone either. But when I owned old indestructible Nokia phone, I dropped it few times a week, just because I didn't really care. If I would own indestructible laptop, I might drop it as well sometimes. If I'm laying on bed with laptop and I want to sleep, I have to carefully position laptop on the floor. But I would happily threw it away, if I could, it would be so much easier.
Definitely agree on "If you drop an Apple, it's also dead.", but "If you spill liquid on an Apple, it's a dead machine." hasn't been true for me: Spilled a whole glass of water on my MBA which was running and it immediately turned off. After drying it on the heater for half a day it turned back on without any problems or damage.
Check out Louis Rossmann's Apple repair channel on YouTube. The vast majority of boards he repairs are broken because of liquid damage (he does actual board-level repair using microsoldering, unlike Apple which merely replaces everything). It's definitely a huge problem.
I don't believe that I actually want improved performance. I just want a smooth laptop that is thin, has long during battery life, and is price competitive. Essentially a MacBook at a reasonable price.
That's maybe not a great comparison, it's a different class of product with worse battery life and much heavier. The MacBook Air has been optimised for a different use case.
The closest real comparison is the MacBook Pro to the Surface Pro, in which case the MacBook is better at every price tier(expect for the touchscreen which is totally useful).
Chrome-only and that's if there's no bug. I have the latest version of Chrome on Ubuntu but my GPU (GTX 960m, latest drivers) is blocked and the --ignore-gpu-blacklist flag doesn't work.
There are some design decisions in Brotli I just don't quite understand [1][2][3], like what's going on with its dictionary [2]. One of the Brotli authors is active in this thread, so perhaps they can talk about this.
Zstandard is pretty solid, but lacks deployment on general-purpose web browsers. Firefox and Edge have followed Google's lead and added or about to add support for Brotli. Both Brotli and Zstandard see usage in behind-the-scenes situations, on-the-wire in custom protocols, and the like.
As for widespread use on files-sitting-on-disk, on perhaps average people's computers, I think we're quite a few years and quite some time away from replacing containers and compressors that have been around for a long time, and are still being used because of compatibility and lack of pressure to switch to a non-backwards-compatible alternative [4].
This is some sort of misunderstanding. If one replaces the static dictionary with zeros, one can easily benchmark brotli without the static dictionary. If one actually benchmarks it, one can learn the two things:
1) With the short (~50 kB) documents there is about an 7 % saving because of the static dictionary. There is still a 14 % win over gzip.
2) There is no compression density advantage for long documents (1+ MB).
Brotli's savings come to a large degree from algorithmic improvements, not from the static dictionary.
The transformations make the dictionary a small bit more efficient without increasing the size of the dictionary. Think that out of the 7 % savings that the dictionary brings, about 1.5 % units (~20 %) are because of the transformations. However, the dictionary is 120 kB and the transformations less than 1 kB. So, transformations are more cost efficient than basic form of the dictionary.
Brotli's dictionary was generated with a process that leads to the largest gain in entropy, i.e., every term and their ordering was chosen for the smallest size -- considering how many bits it would have costs to express those terms using other features of brotli. Even if results looks disgusting or difficult to understand, the process to generate it was quite delicate.
The same for transforms, but there it was mostly the ordering that we iterated with and generated candidate transforms using a large variety of tools.
It is superior to Brotli in most categories (decompression, compression ratios, and compression speeds). The real issue with Brotli is the second order context modeling (compression level >8). Causes you to lose ~50% compression speed for less then a ~1% gain in ratios [1].
I've spoken to the author about this on twitter. They're planning on expanding Brotli dictionary features and context modeling in future versions.
Overall it isn't a bad algorithm. Brotli and ZSTD are head and shoulders above LZMA/LZMA2/XZ. Pulling off comparable compression ratios in half to a quarter of the time [1]. They make GZip and Bzip2 look outdated (which frankly its about time).
ZSTD really just needs a way to package dictionaries WITH archives.
[1] These are just based on personal benchmarks while building a tar clone that supports zstd/brotli files https://github.com/valarauca/car
What use case do you have in mind for packaging dictionaries with archives? There is an ongoing discussion about a jump table format that could contain dictionary locations [1].
> At peak, web/API error rates were approximately 20%, while archive and raw-content downloads reached approximately 50%.
https://www.githubstatus.com/incidents/zkxwbgr0cnmx