I read the current Starlink system has a limitation where if you move outside of your assigned service "cell", you lose service. Guessing this is still the case.
I wasn't implying that wildcard records are something entirely incompatible with DNSSEC, more that certain nameserver implementations could potentially have trouble with them.
> This indicated there was likely a problem with the ‘*.slack.com’ wildcard record since we didn’t have a wildcard record in any of the other domains where we had rolled out DNSSEC on
I'm not going to stick my hand in either camp for the sake of this discussion,
but dynamic/wildcard DNS records are exactly the type of thing I'd suspect DNSSEC to have trouble with
This. Some standards bodies (arguably) made a big deal about client certificates some time ago to reliably pin client identities for client->server connections (whether it worked is a different story), and I certainly think having functionality for the reverse (pinning server identities) should exist too.
Doesn't have to be Gemini even, but I think getting buy in from browser vendors after the removal of HPKP is going to be a problem...
> Except they already do. Also, AMD announced SmartShift ("shifts power inside your laptop for the optimal performance for a given task") support for Linux a couple of days ago. They're more than usable nowadays.
Interesting, thanks!
> Probably a popular opinion here, but any display with a higher res than 1440p (1600p if it's a 16:10 display) is a waste on a laptop. I'd rather have a 1080p one over a 4K one, personally.
I don't disagree that 4k is a little nuts on a ~15" laptop LCD, but it seems until recently you're options for decent >1080p displays on laptops for the most part were a) Macbooks (2880x1800 at 15.4"), and b) 4k PC laptops
> This all makes me think there is some other microcontroller somewhere that controls the bios flashback process, which would almost certainly be an extra chip.
I believe they just have some sort of extra microcontroller wired to a USB port and the SPI flash chip that stores the BIOS, probably with some sort of switch to ensure the host can't touch the SPI flash when the external microcontroller is attempting to flash it.
> Another issue is motherboard firmware. Even though AMD supplies the memory init code, the configuration can be tweaked by motherboard vendor, and they might simply break ECC support accidentally (even by something as simple as making a toggle default to false then forgot to expose it in configuration menu).
I think some Gigabyte boards are infamous for this in certain circle
OTOH: Gigabyte might have a Threadripper PRO motherboard (WRX80 chipset) coming out in the future
IBM POWER9 supports some memory ordering instructions that (as I understand) would in theory be useful for x86 emulation, but a) I'm unsure if anyone actually uses them and b) They are removed from POWER10
Documented cases don't seem to be common, but what comes to mind is the Debian "weak keys" scandal (2008), and the VLC "libeml" vulnerability (2019)[1]
Some people claim Gigabyte X570 motherboards in theory have the traces needed for UDIMM ECC, but the (hardcoded) BIOS settings cause the memory to not initialize in ECC mode.