On Tue, 3 Sep 2024 19:51:43 -0400 Steve Litt <sl...@troubleshooters.com> wrote:
> >It also brings cross-architecture portability; > > I'm not sure in what way it does this, but I'm sure it could have been > done in a much simpler way. The principle being that your UEFI code will run on ARM, AMD64, IA64, or whatever other CPU architecture. A consistent API (or is it ABI?) across architectures is needed. I don't disagree that there are simpler ways to do this than UEFI if this were all that it did. > Which isn't as important now that small NVMe drives are so darn cheap. At the time they weren't. > Haven't we been doing this since Knoppix came out? Or am I > misunderstanding you? I think you misunderstand. This isn't the OS booting and loading its filesystems to a ramdisk. It's creating an OS on a ramdisk and booting from it. Since the ramdisk is created at the firmware level it survives reboots which is *very* useful for turnkey upgrades which require multiple reboots to apply, and being RAM based it is many times faster than USB or optical media. It matters when I have to apply upgrades to dozens of servers. It's how Red Hat's Leapp utility works: similar to Sun's miniroot on swap mechanism but with a ramdisk. The Ventoy tool does something very similar with ISO images. > Yeah, chain loading was never fun. But these days multi-boot isn't as > essential because we have VMs. That's a matter of opinion particularly when performance is a high priority. > I didn't know about Lenovo going John Deere on us. That's disgusting. Yup. I don't know if they still do it, but during the 2010s they used device signing to lock out third party PCIe cards on some of their tower systems. -- \m/ (--) \m/ _______________________________________________ Discuss mailing list Discuss@lists.blu.org https://lists.blu.org/mailman/listinfo/discuss
