3 ms·

Computers being more complicated has nothing to do with a dynamic module loader that is designed to be able to override installed code modules with newer versio

by pgeorgi 11y ago

Computers being more complicated has nothing to do with a dynamic module loader that is designed to be able to override installed code modules with newer versions at runtime. That's just architecture astronauts with too much exposure to COM designing a firmware API.

Someone1234 11y ago
Fine, but that's not what I replied to. Someone said they forgot the "B" in BIOS (with uEFI), I am saying the BIOS hasn't been close to a basic in a very long time due to the complexities of x86-like systems. The BIOS was a giant bloated mess before uEFI. uEFI's modular design is a single attempt at keeping it simplier and removing unneeded code.
- pgeorgi 11y ago
  > UEFI's modular design is a single attempt at keeping it simplier and removing unneeded code. That's why with the introduction of UEFI, flash parts finally grew in size again? (not that I complain, that's quite useful to burn coreboot + Linux on them, to have a _real_ OS around to drive the boot process) UEFI is _much_ larger than BIOS, conceptually and in terms of code size. It's also _much_, _much_ larger than coreboot based solutions implementing the same purpose (my tests indicate that UEFI takes 6 times the LOC over coreboot for a minimized code base that provides a boot menu and the ability to load a signed Linux kernel from disk)
  - Someone1234 11y ago
    > That's why with the introduction of UEFI, flash parts finally grew in size again? Assembly programs are typically smaller than ones written in C. No surprise there. > It's also _much_, _much_ larger than coreboot based solutions implementing the same purpose (my tests indicate that UEFI takes 6 times the LOC over coreboot for a minimized code base that provides a boot menu and the ability to load a signed Linux kernel from disk) And does 1/6th the amount of "stuff." If you drop a bunch of uEFI features, of course you won't use as much code. Is that controversial? There's a reason CoreBoot is so infrequently used, it doesn't do many things that people take for granted with uEFI.
    - pgeorgi 11y ago
      > And does 1/6th the amount of "stuff." I disabled all capabilities that weren't required for the task, then killed all source files that weren't required for the build, in both trees. I believe it was a fair comparison.

by pgeorgi 11y ago

Someone1234 11y ago

Fine, but that's not what I replied to. Someone said they forgot the "B" in BIOS (with uEFI), I am saying the BIOS hasn't been close to a basic in a very long time due to the complexities of x86-like systems. The BIOS was a giant bloated mess before uEFI. uEFI's modular design is a single attempt at keeping it simplier and removing unneeded code.

pgeorgi 11y ago
> UEFI's modular design is a single attempt at keeping it simplier and removing unneeded code. That's why with the introduction of UEFI, flash parts finally grew in size again? (not that I complain, that's quite useful to burn coreboot + Linux on them, to have a _real_ OS around to drive the boot process) UEFI is _much_ larger than BIOS, conceptually and in terms of code size. It's also _much_, _much_ larger than coreboot based solutions implementing the same purpose (my tests indicate that UEFI takes 6 times the LOC over coreboot for a minimized code base that provides a boot menu and the ability to load a signed Linux kernel from disk)
- Someone1234 11y ago
  > That's why with the introduction of UEFI, flash parts finally grew in size again? Assembly programs are typically smaller than ones written in C. No surprise there. > It's also _much_, _much_ larger than coreboot based solutions implementing the same purpose (my tests indicate that UEFI takes 6 times the LOC over coreboot for a minimized code base that provides a boot menu and the ability to load a signed Linux kernel from disk) And does 1/6th the amount of "stuff." If you drop a bunch of uEFI features, of course you won't use as much code. Is that controversial? There's a reason CoreBoot is so infrequently used, it doesn't do many things that people take for granted with uEFI.
  - pgeorgi 11y ago
    > And does 1/6th the amount of "stuff." I disabled all capabilities that weren't required for the task, then killed all source files that weren't required for the build, in both trees. I believe it was a fair comparison.