On 05/31/2012 10:52 AM, Chris Adams wrote: > Once upon a time, Gregory Maxwell <gmaxwell@xxxxxxxxx> said: >> Under this model there will be two classes of distributor: One which >> loads easily on systems, and one which requires the additional effort >> of disabling secure boot or installing user keys. (And ARM will be >> even more interesting...) > The basic fact is that Microsoft drives the desktop x86 PC market. > Nobody else has the power they do, and that isn't going to change any > time soon. They are creating the two classes you describe. The > hardware is coming (like it or not), and Fedora can either change to > deal with it or not. > > If Fedora does nothing different than is being done today with F17, it > will always be in the second class, requiring the user to disable secure > boot. Even getting to the point where the user can generate/install > their own key requires more work. > > Once the work has been done to support signing with a user-generated > key, it isn't that much more of a step to get the Fedora-provided > binaries signed with a key that allows the distribution to step up to > your first class, where it will load easily on systems. > This is the crux of the issue at hand. It's that the rights and freedoms available to the original distribution will not be transitive to the users themselves, which, until now, has always been the case. This will exclude a whole class of usages that are currently available to Fedora users, such as the ReSpin projects that Fedora Unity used to produce from stock Fedora packages as well as any other downstream projects that build on Fedora. This is not something affecting only a limit set of cases. It's a major change to the ecosystem around Fedora. More importantly, it's a direct attack on the principles of the Fedora project. Fedora has always taken a strong (almost the strongest) stance on not including non-free software, and this stance has resulted in an amazing amount of work put into free-and-open alternatives to otherwise closed options, such as drivers, applications, and otherwise. This stance has ensured that the freedom that the Fedora Project enjoys transfers to everyone using Fedora downstream, whether an individual user, a developer, or an entirely different project. By caving before this really becomes an issue, the "pain" involved will not be felt as deeply, and thus work to get around the technical barriers presented by the secure boot initiative to freedom will be stifled at a much earlier stage. More importantly, this sets the tone that the right way to deal with this is to cave to the more powerful market forces rather than come-up with a more freedom-friendly alternative that provides as good or a better solution to the problem at hand. This is a matter of principle, and to look at it in any way different is to undermine the operating premises for many that Fedora is really about. I'm not in a position at this point to provide a specific solution to this, but Windows 8 is not even out yet. Fedora, Red Hat, and others may still have the option of putting pressure on either Microsoft or other entities (hardware manufacturers) to change how this is implemented to prevent the lockout that the key requirement causes in its current state. But announcing support for it before it's even in real systems widely is premature only serves their interests, not ours. -- Libre Video http://librevideo.org -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
