Hacker News Reader

Comment by userbinator | Hacker News Reader

Indeed, compilers are still very easy to beat on size optimisation, and the whole (U)EFI monstrosity was largely enabled by higher capacities of BIOS EEPROMs, which were in the 128/256KB range for a long time before multiple-MB ones became available. Now that motherboards with 16 and even 32MB(!) EEPROMs are available --- this is more than the entire RAM of regular PCs throughout the 80s and early 90s --- firmware has bloated considerably. In contrast, the original IBM PC had an 8KB BIOS.

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.

View on HN

> 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.

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.

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.

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

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

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.

To be fair to the modern BIOS, there is a whole lot more hardware to initialize than in 80s and 90s, the added ROM space isn't consumed only by bloated compiler output. Some motherboards store a second pristine copy of the BIOS image for fail-safe upgrades.

> and elegantly clever Asm

I personally miss returning boolean result in C (carry) flag.

Reply on news.ycombinator.com