Comment by rlpb
9 years ago
Why is this Ubuntu's sole responsibility? Can you not get a UEFI firmware update from your vendor?
> I think it's a fair and tame adjective considering this is processor microcode we're talking about...
Processor microcode updates haven't, to my knowledge, ever automatically been applied by distributions in the past. In light of that, I don't see how it's reasonable to have an expectation otherwise.
> You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect, does it?
By being careful before pushing out an update to millions of users? I'd say that's a positive effect.
> ...what is it that they're trying to decide in the bug?
Whether to continue to let users have a choice, or by taking that choice away by doing things automatically for them. There are also packaging-based regressions to consider; not just the microcode ones. For example: if the wrong microcode is applied to the wrong processor because of a packaging error, who would you be blaming? Intel or Ubuntu?
> But I don't think Ubuntu could reasonably choose to skip all microcode updates for 1.7 years like it did in my case...
Ubuntu didn't "choose to skip" all microcode updates. Ubuntu didn't choose at all; pushing an update requires a specific effort.
In light of this issue, Ubuntu is now considering what to do about it, responsibly, for all users. Both for this particular issue, and for microcode updates going forward.
I don't think yours is a serious answer, what I said already refutes your points. Ubuntu has already made me waste a week and I don't want to waste any more, particularly when you can't or won't listen to what I say and look for irrelevant excuses like the availability of UEFI vendor updates. Just FYI Intel provides these updates for very good reasons and RHEL/CentOS/Fedora have been providing processor microcode updates for ages now and with relatively frequent updates (see the microcode_ctl RPM changelog). Bye now.
> RHEL/CentOS/Fedora have been providing processor microcode updates for ages now and with relatively frequent updates (see the microcode_ctl RPM changelog)
I wasn't aware of this, thanks. Though I searched, and I found that they've been causing their users problems by doing so: https://rhn.redhat.com/errata/RHBA-2017-0028.html
I think this backs up my point: care must be taken.