Dave,
Here's a further thought, extending on the analogy with closed
graphics hardware which requires proprietary drivers. We _could_ have
made life easier for users who had the misfortune of purchasing closed
hardware. We could have tied ourselves in knots and promulgated a
stable kernel ABI, so that Nvidia and ATI/AMD could more easly inflict
proprietary binary blob drivers just like they do for Windows. We
chose not to screw ourselves over that way, even though it meant that
some users had a harder time of it.
Remember, before Intel came out with their graphics chips, for a while
it seemed that there were very grahpics options with decent
performance available that didn't require propietary drivers. There
was a while when things looked pretty bleak. Yet we didn't cave, and
eventually, life got better and more open options came on the scene.
Yet in the case of Secure Boot, everyone is assuming that Windows 8
will be a success, and that Microsoft will continue to dominate x86
client machines, and there will be no significant numbers of machines
that won't be locked down to Microsoft whims. And so, we should run
up the white flag of surrender, and do everything that Microsoft
_might_ possibly require lest they capriciously and arbitrary decide
to revoke Linux distro's keys.
Linux distributions can do whatever they want, including locking down
kernel ABI's like they did for enterprise kernels (and I don't need to
tell people how painful that was for Linux distros). But we didn't do
that for upstream kernels; instead, we pushed for open source device
drivers, and open hardware. It took years, and we're still not 100%
successful, but we've made incredible progress, to the point where
we're no longer stressed out about device drivers any more; we just
avoid the proprietary crap, and it's not so hard to do that.
Maybe there's a lesson to be drawn from that which can be applied to
the Secure Boot mess.
Regards,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
