The cost is pretty comparable to the Ampere eMAG AArch64 system in the OP, which costs about $3k. It's an unfortunate fact of low volume production, though.
If you want a non-x86 desktop, but not AArch64 in particular, I'd recommend looking at the Talos POWER9 systems instead. I have a Talos II Lite, and my only two complaints (less pcie slots with only a single socket, and no built in sata) were solved with their new Blackbird motherboard. It's gotten closer to the desktop experience than any AArch64 computer I've tried, and in some ways it's even better (petitboot is awesome).
Note the two binaries are downloaded for two different reasons. OpenH264 is actually free and open source software in terms of copyright, the binary is simply downloaded from Cisco's servers rather than Mozilla's to comply with the H.264 patent license. It's worth noting that in general, Debian disregards patent licenses - they ship ffmpeg with many patent encumbered formats enabled, for example.
On the other hand, Widevine is actually proprietary DRM.
The original Apple II sold at an adjusted 2019 price of $5,476, and it sold millions. I would say there are plenty of consumers with that much buying power. Of course, that doesn't mean most consumers need that many cores - but that's still true even if it cost $100.
I think the issue is not the hardware needed but simply the cost of the extra compute. Linux doesn't have an "official" CI server but relies on third parties running it, and none of them want to spend $ on compute for an architecture they will never use.
Most modern enthusiasts replace dried-up capacitors and retune the bias/constrast and focus voltages, which brings them back to stock condition as long as the tube isn't too heavily worn (a rejuve will sometimes fix that as well)
They are also somewhat popular with enthusiasts (especially the rare 4:3 models) but they frequently have software processing and scaling that adds the lag back.
VR headsets do this. They are one of the most common applications due to how important tracking motion is, and also because they refresh at a higher rate by design - for content at lower refresh rates (60hz for a game) the flicker is very noticeable. If you've used an Oculus Go, some games run at only 60hz and the backlight flicker becomes quite noticeable.
I run a previous-generation 2990WX (320W TDP) and the largest Noctua air cooler is easily sufficient at a low fan speed. If it's in your garage and you don't care about fan speed, you should be able just to blast the fans faster and have a well-ventilated case before resorting to water cooling.
The cores start to throttle at 70C, which is far hotter than even the hottest garage.
The open tools also work on ECP5, which goes quite a bit bigger than the Cyclone 10 chip on the Arduino and is also pretty cost effective. In fact it's big enough that you can usually dispense with the separate microcontroller - I built a ulx3s which can boot Linux on the ECP5-85.
I think the mandatory phone service if you get Sonic FTTN (aka resold AT&T FTTN) is also a result of that regulation. DSL is Title 1 but phone is Title 2, or something like that.
I'm pretty sure that's not literally true. For example, take a CRT, with its built in power law voltage-to-intensity response (the original gamma correction). If the eye didn't compress red, you'd see large shifts in the color of a white color ramp.
The underlying HEIF container is unfortunately super complex, but the AVIF specification is based on the subset known as MIAF, which makes it a lot saner to implement.
Interesting design, though I think if isolation isn't needed, you would do much better with just a buck topology - half the fets, and no output diodes. Or a surplus supply as other comments mention.
Their own variation of HLS. Note that except for Safari, browsers don't implement HLS directly, but rather websites do, through HLS.js etc. So you can implement whatever low latency version of HLS you want (assuming it is constructed of HTTP primitives that JS can access).
It is not an IETF standard - those have RFC numbers. It is just a personal draft - any IETF member can upload one of those, regardless if it's useful. I'm happy that it has a specification - but it's just a one-man project, not something that has gone through the IETF standards process.
I wonder if they could have used something like petitboot? That way they don't depend on Pi4 firmware for netbooting. It does require a sd card, but it's read only and tiny.
Right click the video and choose Stats for Nerds. If Codecs shows something starting with "av01", it's AV1 (confusingly, av1c is H.264). It seems to be chosen for nearly every video for 480p or below, and a few for higher resolutions.
You could add this to the standard library in the future. There is already the 1d version of this (slices). But you don't need to - it would be perfectly fine to live on its own.
It's a permanent magnet motor. It's an IPM design so some amount of the torque comes from reluctance, but the majority of the efficiency is from the permanent magnets providing the field rather than having to burn energy through the induction motor's copper bars to provide it.