3 ms·

> If you looked at pre-EFI BIOS, they were exclusively written in very size-optimised and elegantly clever Asm; now it's just the usual bloaty compiler output y

> If you looked at pre-EFI BIOS, they were exclusively written in very size-optimised and elegantly clever Asm; now it's just the usual bloaty compiler output you can find everywhere else, which makes me a bit sad. As a person who cares way more about software reliability than cleverness, I am unreservedly happy about this change.

wtallis 7y ago
The extra firmware capacity and the programming productivity it has enabled wasn't spent on improving reliability. It was spent on adding a silly GUI to the firmware. My experience is that annoying motherboard firmware bugs are just as easy to find today as they were in the early 2000s when ACPI was being implemented in assembly.
- tormeh 7y ago
  I think this can be generalized. Computer programs always seek a minimum floor of cognitive demand on it's programmers. Whenever the cognitive load is lower than the floor, features will be added until it reaches the floor. Let's call this floor "The Floor of Pain". At this point, the program is sufficiently challenging to maintain and extend that the developers are barely able to add any new features. Any tools/languages/etc that help developers handle more complex programs therefore leads to more features to be added in the application until it reaches The Floor of Pain, simply because it is a manager's job to fill the feature pipeline with work, and maintenance does not fully occupy the programmers yet. It follows that when Rust replaces C, the kind of programs that are now written in C will have their complexity grow dramatically.
kjeetgill 7y ago
I don't think most people find UEFI more reliable than BIOS. Sometimes clever code is also just attention to detail.
JohnStrangeII 7y ago
However, as a rule of thumb, larger and more complex systems tend to have more bugs than smaller and simpler ones.
- marcosdumay 7y ago
  They are harder to read too. The trick is to create large and simpler systems, instead of larger and more complex ones. That's hard to do for user facing software, but there is no reason firmware had to be those monsters we have now.

wtallis 7y ago

The extra firmware capacity and the programming productivity it has enabled wasn't spent on improving reliability. It was spent on adding a silly GUI to the firmware. My experience is that annoying motherboard firmware bugs are just as easy to find today as they were in the early 2000s when ACPI was being implemented in assembly.

tormeh 7y ago
I think this can be generalized. Computer programs always seek a minimum floor of cognitive demand on it's programmers. Whenever the cognitive load is lower than the floor, features will be added until it reaches the floor. Let's call this floor "The Floor of Pain". At this point, the program is sufficiently challenging to maintain and extend that the developers are barely able to add any new features. Any tools/languages/etc that help developers handle more complex programs therefore leads to more features to be added in the application until it reaches The Floor of Pain, simply because it is a manager's job to fill the feature pipeline with work, and maintenance does not fully occupy the programmers yet. It follows that when Rust replaces C, the kind of programs that are now written in C will have their complexity grow dramatically.

kjeetgill 7y ago

I don't think most people find UEFI more reliable than BIOS. Sometimes clever code is also just attention to detail.

JohnStrangeII 7y ago

However, as a rule of thumb, larger and more complex systems tend to have more bugs than smaller and simpler ones.

marcosdumay 7y ago
They are harder to read too. The trick is to create large and simpler systems, instead of larger and more complex ones. That's hard to do for user facing software, but there is no reason firmware had to be those monsters we have now.