Matthew GarrettLooking at the reports of some systems failing to boot after the latest UEFI DBX update and wondering whether it's another case of https://mjg59.dreamwidth.org/22855.html
We ended up writing some hilariously crappy workarounds for Linux to prevent this kind of thing, where firmware fails to boot if the UEFI variable store is too full. We check whether the write would leave under 5KB of free space (as reported by the firmware), and refuse the write if it would. Easy! Except some firmware would never actually increase the available space count if a variable was deleted, so after a while we'd just never be able to write any more variables
I can't remember how I figured this out, but the affected machines would trigger garbage collection if we tried to create a variable bigger than the available space, so Linux just tries to create a giant variable and then deletes it again to force the firmware to actually update the free space counter
Fucking computers, man
Cassandrich@mjg59 Fucking UEFI. The ring -1 (or is it -42 now? does anyone even know or care?) shit nobody asked for.
Demi Marie Obenour@alwayscurious @mjg59 Device tree solves that problem. UEFI and ACPI both address a much larger-scope problem (which a lot of us don't want) of having a persistent layer under your trusted OS that you also have to trust, that continues execution after control was supposed to be passed to the OS, and that the OS is forced to interact with to access important functionality.
@alwayscurious @mjg59 Sorry, I wasn't clear. I don't mean it's a way you can do things right now. I mean the problem of "booting same image on diverse hardware" is a much smaller-scope problem domain than what UEFI and ACPI do ("abstraction layer/runtime under your trusted OS kernel"). And some of us are very very unhappy that we're expected to accept the latter in order to get the former.
Irenes (many)@dalias @alwayscurious @mjg59 yeah we've had enough ACPI problems in recent years that we're starting to see that as a serious problem
@dalias @alwayscurious @mjg59 ACPI was a big barrier to Linux compatibility back in the 90s, because manufacturers only cared about Microsoft so Linux had to reverse-engineer every single thing and figure out how to do it in an open context
@dalias @alwayscurious @mjg59 then everyone basically got their shit together and there wasn't a ton of new stuff that was actually critical, for about twenty years
@dalias @alwayscurious @mjg59 ... but just last month we ran into a problem where Linux is compatible with a motherboard and an m.2 card, but not when they're used together, because this new super-ACPI thing has them talking directly to each other in opaque, non-standard ways and Intel and AMD are at war
amy tech (bones)@ireneista @dalias @alwayscurious @mjg59 when I started seeing ACPI errors again, on 2023 machines, I was like "did I time travel what the fuck I thought we were past this"
@amy @mjg59 @dalias @alwayscurious yeah there's some new spec we've forgotten the name of, which lets devices other than the mobo get in the game as well. it seems fantastically ill-advised to us.
@ireneista @mjg59 @dalias @alwayscurious
Interesting. I agree that seems .. bad. I wonder if it's at all connected to Intel's new bizarre webcam stuff where the webcam no longer pre-processes frames and the processing is done in userspace. This is fine on windows where they can rampantly fuck with machines but Linux has been ... mm. bad.
Interesting. I agree that seems .. bad. I wonder if it's at all connected to Intel's new bizarre webcam stuff where the webcam no longer pre-processes frames and the processing is done in userspace. This is fine on windows where they can rampantly fuck with machines but Linux has been ... mm. bad.
@amy @mjg59 @dalias @alwayscurious oh, wow, fascinating. we remember when that happened with modems back in the day...
@amy @mjg59 @dalias @alwayscurious there was never really a satisfying solution to the "winmodem" problem. modems stopped being things people used directly; everyone learned how Fourier transforms work; and CPU speeds increased, so the problem went away but the market forces that led to it weren't addressed.
@amy @mjg59 @dalias @alwayscurious (from what we can tell it really is true that the free software community at large understands Fourier and wavelet transforms a lot better today than back then)
@amy @mjg59 @dalias @alwayscurious we wouldn't necessarily object to offloading image processing to the CPU; what we object to is having that process governed by the camera
@ireneista @mjg59 @dalias @alwayscurious yes - a standard interface to allow many different kinds of user space image processing on CPU. I think Intel has made lip service to this idea but it's doubtful they'll make good on actually making it happen.
@amy @mjg59 @dalias @alwayscurious they have near-zero commercial incentive to make it happen, yeah :/
@ireneista @amy @mjg59 @dalias and apparently lots to not make it happen, judging by the reluctance of various vendors.
@alwayscurious @amy @mjg59 @dalias it costs money and corporations in general would prefer not to spend money. as far as we can tell, that's the most significant factor. there may be other reasons too.
@amy @[email protected] @mjg59 @dalias @alwayscurious oooooooh I hate, hate, hate that new webcam crap. Like congrats, you messed up the one reliable thing on Linux, thanks.