> Bull. They QA their own BIOS and firmware. The whole point of firmware-BIOS-OS separation is that the operating system never even speaks to the BIOS directly. BIOS runs the bootloader, bootloader loads the OS, OS proceeds according to a standard for how PCs are run.
The complexity here is that the firmware updates shipped for Linux may well take a different QA path to the firmware updates shipped for Windows, as the distribution channels are different. Further, manufacturers usually try to unify (to some level) firmware updates for different systems into fewer actual binary blobs to reduce release engineering workload.
What keeps a complex system such as this working smoothly is QA. Dell cannot reasonably be expected to spend effort on QAing combinations they clearly do not support.
While the fact that your system was bricked is likely a bug that should not have happened, nevertheless I think it's unreasonable to blame Dell for this as viciously as you are doing because they do not support or QA that combination and cannot be expected to do so. That they're fixing it is the most I think you can reasonably expect.
I understand that you've accidentally ended up having a poor experience here. But you can't reasonably expect that to reflect on the experience others might get following a path Dell actually supports and can reasonably be expected to actually QA.
>The complexity here is that the firmware updates shipped for Linux may well take a different QA path to the firmware updates shipped for Windows, as the distribution channels are different.
Assuming that they're all still Dell-made firmware blobs, I don't see why they'd be different at all. Anything that Ubuntu can "do to them" ought to ruin the signature. Only an authentic Dell firmware blob should actually make it through the BIOS' checks to installation.
It's like saying, "look, you opened our cryptographically signed file under our system, sure, but you downloaded it through an unsupported channel."
> The complexity here is that the firmware updates shipped for Linux may well take a different QA path to the firmware updates shipped for Windows, as the distribution channels are different.
No, the update content in different OSes is identical. The firmware is being updated by UEFI capsule; the only differing part is what puts the capsule content into it's space. There's actually a third way how to do an update: straight from UEFI.
The complexity here is that the firmware updates shipped for Linux may well take a different QA path to the firmware updates shipped for Windows, as the distribution channels are different. Further, manufacturers usually try to unify (to some level) firmware updates for different systems into fewer actual binary blobs to reduce release engineering workload.
What keeps a complex system such as this working smoothly is QA. Dell cannot reasonably be expected to spend effort on QAing combinations they clearly do not support.
While the fact that your system was bricked is likely a bug that should not have happened, nevertheless I think it's unreasonable to blame Dell for this as viciously as you are doing because they do not support or QA that combination and cannot be expected to do so. That they're fixing it is the most I think you can reasonably expect.
I understand that you've accidentally ended up having a poor experience here. But you can't reasonably expect that to reflect on the experience others might get following a path Dell actually supports and can reasonably be expected to actually QA.