*countable infinities only
kevin at scrye.com
Mon Jun 18 14:48:54 UTC 2012
On Mon, 18 Jun 2012 15:35:40 +0200
Reindl Harald <h.reindl at thelounge.net> wrote:
> Am 18.06.2012 15:30, schrieb Seth Johnson:
> > I stand corrected. Jay's point is that Microsoft will be in a
> > position to change policy, on either platform. That could happen
> > once it is in a position to do so.
> EXACTLY this is the problem
> and wre are playing them in the hands
> * NOW secure boot is optional on x86
> * we support it with the MS keys
> * the next HW generation my have it mandatory
> * the argument for make it mandatory may be "see, even free OS has no
> who can make sure that we get forever keys from MS?
Nothing in life is sure or forever. ;)
> if we take opensource and free software seriously we should not do
> anything to bring MS or any other single company in a position
> making us depending on their goodwill over the long
I don't understand this argument, as if/when MS changed their
certification (say for windows 9, as I think it's pretty much
impossible for them to change the windows 8 client certification at
this point), to require secure boot not be disable-able or disallow
client keys to be enrolled, we could simply at that point stop signing
our bootloader shim with MS'es key.
This is what some would prefer we do now, but right now since you CAN
disable secure boot and you CAN enroll your own keys, I think the gains
in supporting secure boot outweigh the small (and easily
workaroundable) loss in redistribution rights.
Additionally, I can't see what MS would gain by making the above
changes you posit, and in fact, it would be likely bad for them. IMHO
(IANAL), if secure boot was non disableable folks would have a much
better case for a class action suit. "This general purpose hardware I
bought doesn't work for general purpose computing". As it is now, they
could just say "disable secureboot".
We really can't know whats going to happen down the road, we can only
act on it as we know it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the devel