As with many things, "It's complicated" but effectively, yes
Such system firmware is generally provided by AMI / Insyde / Phoenix and similar.
There are a few vendors who decide to go their own way (notably google using a fork of Coreboot for their chromebooks), but it's generally list of vendors that you can count on a single hand.
If it means anything I'm pretty sure AMI provides A/B updates on most products i've used with their stuff.
But that's always been the case. Phoenix and AMI have been the dominant BIOS providers for over 30 years. Both have always provided modular tookits for OEMs to customize their own ROM images, write their own ACPI tables, etc. UEFI gives even more control to the OEMs. If Framework isn't doing that properly, that's on them.
It appears that Framework contracted out the development of their (Insyde-based) firmware to somebody who, to put it mildly, does not treat them as a priority. Either way, Framework’s firmware is really bad, and that’s entirely on Framework; you can look around on the forums for the horror stories in the (open) EC code around power delivery for instance.
As another example of a vendor low-key screwing Framework in a way that I think it’s entirely appropriate to blame Framework themselves for, the first couple 13-inch models could charge off 5V chargers. The newer ones still have the necessary hardware, but whoever they get their power circuitry from cut that bit from the firmware on a newer chip version, and Framework obediently went “welp, guess we don’t have that feature anymore”.
In addition to no longer charging off 5V chargers (their first laptop could literally charge off a USB type A with no USB-PD), on the AMD 7040 I've got ~10% chance every time I plug it in to my dock that it will simply not start charging. Everything else will connect (display, USB) but power won't flow. Resolving that is as simple as unplugging and replugging in my laptop but if I don't notice until I'm in a video conference then it is a problem because my webcam, microphone, and headset are also going over that cable. Oh how I miss the OG 11th gen framework charging.
I heard a lot of talk about porting to coreboot (they even sent some motherboard to some coreboot developers I think).
Not sure what is stalling there, but sounds like a priority.
For the EC, I feel like a team of a single developer could arrange something there?
Just remove the A record, and nearly all the scrapers disappear. :-) (And then you get one email per month or so that “your host does not resolve in DNS”.)
Google is having a real issue with LLMs using it for search. As in, real load issues. Unless you're running a publicly accessible search engine, and the top one at that, the LLM traffic you're seeing is not representative.
> We have hired outstanding individuals who did not attend or complete university. If this describes you, please continue with your application and enter ‘no degree’.
Because SCION is mostly said as a joke in the more serious carrier world.
SCION is practically speaking proprietary, and has 1 and maybe a half implementations. I have a laundry list of real problems with SCION but SCION feels like one of those entities that would get quite legal-ey if discussed publicly.
For inbound traffic, they're completely fine. This is only looking at the route servers. You can almost certainly receive 50/50 traffic ratios if you do bilateral peering. This post only covers the " automatic peering " services that IXs offer
About 58% of all of the email my company sends out of it's outbound relays is to IPv6 MXs. I've never really had to deal with discoverability issues related to v6
reply