Even if it's just the build server, it's really hard to defend just having 1 physical server for a project that aspires to be a core part of the software distribution infrastructure for thousands of users.
The build server going down means that no one's app can be updated, even for critical security updates.
For something that important, they should aspire to 99.999% ("five nines of") reliability. With a single physical server, achieving five nines over a long period of time usually means that you were both lucky (no hardware failures other than redundant storage) and probably irresponsible (applied kernel updates infrequently - even if only on the hypervisor level).
Now... 2 servers in 2 different basements? That could achieve five nines ;)
So, product idea: A powered "cold storage box" for M.2 SSDs. 2 to 8 M.2 slots. Periodically, an internal computer connects one of the slots, reads every byte, waits for some period of time, then powers off. Maybe shows a little green light next to each drive when the last read was successful. Could be battery-powered.
Doing this DNS in the browser in real-time would be a performance challenge, though. PSL affects the scope of cookies (github.io is on the PSL, so a.github.io can't set a cookie that b.github.io can read). So the relevant PSL needs to be known before the first HTTP response comes back.
These days, if you're just wiring to a single workstation in a nearby next room, 50 meter active optical Thunderbolt 3/4 cables can carry 5K+ DisplayPort video passthrough and data from your USB peripherals.
(It's "passthrough" and not "uncompressed" because DisplayPort may use DSC depending on the resolution and frame rate.)
US$500 for an optical cable can be a lot cheaper than paying for HDMI extender sender and receiver boxes.
With a locked screen, key presses go to the password field. I have twice caused my user account to become disabled due to too many password attempts while cleaning my keyboard.
Yes. Most of the major apps play this review game, and there's no way to compete if you don't play it too.
The major apps typically exploit selection bias to solicit 5-star reviews. They will wait until the user meets some criteria for "having a good experience" and show an app review prompt at that moment.
Then, having amassed thousands of 5-star reviews, they will turn up the threshold so that only a trickle of the most likely 5-star reviews keep on trickling in to negate any negative organic reviews.
There's a related practice of "pre-prompting" where the app first asks the user whether they are satisfied and only solicits a real app review from those who pass the screening question.
It's all quite shady and makes it hard to trust app reviews. But until the app stores solve this, app developers need to play the game.
The state of the art here is really Parsec, Moonlight, and Apple's "High Performance Screen Sharing" [0]. All three of these use hardware-accelerated HEVC in some UDP encapsulation. Under the right network conditions, they achieve very crisp text, 4K60 4:4:4 with low latency.
Are you suggesting that HEVC can adapt its compression for different regions of the same frame similar to JPEG-XL? I don't think this is possible but I would love to be proven wrong.
Yep, this is achieved using slices, which can be arbitrary regions of the frame. Each slice can have its own quantization parameters (ranging from highly lossy to perceptually lossless). Each slice can also switch between intraframe prediction (more like still image encoding) and interframe prediction (relative to prior frames).
So, with this, you can have high-quality static text in one region of the frame while there is lossy motion encoding (e.g. for an animating UI element) in another region of the frame.
If you were forced against your will to aid in this type of fraud, might you not intentionally include a subtle error in your work that reveals its illegitimacy to a careful observer?
E. Goldstein wins with 51.2HELPIMTRAPPEDINANELECTIONRIGGINGBUNKER% of the vote!
One would have to take care with the analysis because humans are actually trapped in vote counting bunkers (or local sports halls more likely) in legitimate elections. Any analysis that simply concludes votes were subject to the foibles of hand counting wouldn’t be very useful.
The build server going down means that no one's app can be updated, even for critical security updates.
For something that important, they should aspire to 99.999% ("five nines of") reliability. With a single physical server, achieving five nines over a long period of time usually means that you were both lucky (no hardware failures other than redundant storage) and probably irresponsible (applied kernel updates infrequently - even if only on the hypervisor level).
Now... 2 servers in 2 different basements? That could achieve five nines ;)