@rl_dane my 11th gen Intel CPU laptop does indeed not have BIOS compatibility
The project may be CSMWrap: https://github.com/CSMWrap/CSMWrap
I've been meaning to try it out, but if you don't have a hardware support, the emulated VGA BIOS apparently isn't suitable for games and such
Yes, that's the one.
It sucks that hardware makers think that Windows and MacOS (oh, and occasionally major Linux distros) are the only operating systems out there.
We're addicted to overcomplexity.
💯
I mean, I'm not saying we should be chained to 1980s BIOS forever. But something a little more elegant, mayhap?
I think I have almost all my machines in compatibility mode, but that of course doesn't mean it's using BIOS.
Well, this goes back to several previous debates I've had about why ARM is a _terrible_ flatform, and x86 is better.
Imo, x86 is the _only_ architecture worth even considering, because it's the only one with a common BIOS. With the removal of BIOS compatibility from UEFI, x86 is loosing that. Computers are going from the closest thing to an open platform we've ever had, to just as locked down and worthless as everything else. This is, from a tinkerer's perspective, _the end_
FPGAs. Look at the C64U and Bunnie Huang's Precursor.
I mean... virtue? Doing something good? Not being a moneyslut? Am I speaking Martian? Oh, I'm in America, of course I am. 🤦♂️
(I know I'm preaching to the choir)
People want to buy $1,500 phones every 8 months?
Well, clearly, I guess, given that's the paradigm we've ended up with. And actually, I don't even know why I asked, given that I've had people yell at me for _not_ buying top of the line phones every time they come out, and for even suggesting that people should have the option of _not_ doing that
It made a lot more sense when there was more change every year (think 1998-2015), but now it's just stupidpants.
I swear, by 2040 it will be normalized to have authentication dongles inside the human body or something. That's the only way things could possibly get more invasive.
lol that's cursed. XD
Oh my god do _NOT_ challenge them.
It's already bad enough you've gotta submit your credit card, phone number, email, home address, backup email, back up phone number, mailing address, face, finger prints, social security number, driver's license, GPS location, and install an app with permissions even _you_ don't have, just to use modern services.
I had to enter my (cell) phone number to set up my new router yesterday.
Utterly cursed.
It was a freebie, and it's decently powerful. 🫢
I think after I gave up trying to resist blasted #BindingArbitration agreements, I got kinda lazy.
Also, I have some decent mitigations on my #Android phone against spywareish apps, now. 🤷♂️
That, yes, perhaps a little.
But UEFI itself is incredibly complex vs. BIOS or even other types of firmware.
@OpenComputeDesign @rl_dane
Okay no, UEFI absolutely does need to exist, it makes low level development go from rawdogging interrupts to just writing C code with the efi stdlib. Is the UEFI (edk2) code good though? No, hell, absolutely not. It feels like the code was made by a bunch of random university students without much of a coherent thought on anything.
I've attached two images of the VFR compiler source code (part of EDK2 BaseTools that I've been fighting with for the past couple of days), it's horrid. The styling is all over the place, barely any comments, a BUNCH of codegen (that happens to be incorrectly implemented so if you use more than 1 build job, you create a race condition with modifying the source *as it's being processed by the compiler* from which you get build fails once every 10 or so attempts that are HELL to debug without knowing what is happening), CRLF + NL mess (why do text editors on Windows even do this?!), dependencies from the freaking 90's with support for SGI workstations and more.
Oh yeah, if you've noticed, all of this was just for the VFR compiler, just a single dependency of EDK2. Onto EDK2 code itself - it's actually pretty decent!... as long as you only look at the base and not at edk2-platforms...
I see...
But, kernels and bootloaders not only already exist, but there are many more for BIOS than for UEFI. So even if it's _easier_ on UEFI, it really just means you have to rewrite everything that was already working, from scratch.
And I also feel like, it's not really reasonable to throw all your users under the bus for arguably more elegent programming
@OpenComputeDesign @rl_dane
Okay also about the *good* side of UEFI, it makes the code actually portable!
If you make a bootloader for BIOS, it'll be stuck with only one option of x86/x86_64 and even if you got some sort of a BIOS on a platform like ARM, you'd have to rewrite a ton of it since, well, the communication with BIOS is... mostly assembly.
With UEFI you can just write C and then compile it for x86, ARM, Risc-V with minimal/no changes
😂
Ok, that was a very silly/unhelpful response, but it hit my funny bone just right.
R.L. Dane 
🍵 
Sijmen 🧑💻
Pete Orrall
Guy who's trying his best :(
kabel42
Alexey Laurentsyeu (9vlc)
DHeadshot's Alt