This page permanently redirects to gemini://gemini.techrights.org/2013/02/19/zareason-criticises-microsofts-uefi-restricted-boot-practices/.
Posted in GNU/Linux at 4:21 pm by Dr. Roy Schestowitz
=> ↺
Summary: ZaReason joins opposition to restricted boot, whereas others reluctantly adopt it
THE UEFI saga does not simply end… and that’s a good thing!
=> ↺ UEFI
According to some extraction work by Pogson, there is OEM pushback against what Microsoft was scheming:
=> ↺ by Pogson
She starts by pointing out that “SecureBoot” is a brilliant scheme by M$ to extend its control of hardware-suppliers. Eventually, the supply of machines that shipped “7″ without UEFI/Secureboot enabled will dry up and */Linux will have to deal with it. End-users tend not to want to disable a “security” feature. That it’s mostly a “security” feature for M$, not users.
A few days ago I recommended ZaReason to a person who was looking for a GNU/Linux (preinstalled) box. They seem like a decent business which antagonises restricted boot as everyone should.
=> ↺ ZaReason
As one person told me today:
Accommodating Restricted Boot is a fruitless task that only serves Microsoft Microsoft pretends to leave an escape route open only to lure more people into their trap which they can spring at any time for any reason. We must reject UEFI and restricted boot.
New coverage from London says that Fedora takes a step to eliminate restricted boot:
=> ↺ says
When users disable the security checks in the Shim Secure Boot bootloader, the latest Fedora 18 kernels will disable any restrictions that are caused by their Secure Boot support. This means that Fedora now offers a very simple way of neutralising any Secure Boot restrictions that can be used uniformly on all systems and doesn’t require users to disable Secure Boot in the UEFI firmware setup.
Here is another update from London:
=> ↺ another update from London
The Sabayon developers have released version 11 of the Gentoo-based Linux distribution. The 64-bit live images of Sabayon 11 can now boot and install on UEFI systems with Secure Boot enabled, as the Sabayon developers decided to adopt Matthew Garret’s signed-shim. A SecureBoot key is in the /SecureBoot directory of the live media and can be used on initial booting, while a SecureBoot keypair is generated during installation and can then be added to the firmware’s database, which allows users to sign their own binaries.
This is not a great solution because it leaves many distros out in the cold. Companies like Red Hat and Canonical, joined by fronts like the Linux Foundation, should have filed antitrust complaints. They didn’t. █
Share in other sites/networks: These icons link to social bookmarking sites where readers can share and discover new web pages.
Permalink Send this to a friend
=> Permalink | ↺ Send this to a friend
=> Techrights
➮ Sharing is caring. Content is available under CC-BY-SA.
text/gemini;lang=en-GB
This content has been proxied by September (3851b).