Re: Latest generation laptops with Windows 8 preinstalled, EFI mess..
Quoting Sam Varghese (sam@gnubies.com):
Rick, if you read this guy's article carefully you'll notice that he makes mention that his installation did not involve secure boot.
Ah, good catch. You know, fundamentally, a computer with UEFI Secure Boot enabled _if_ it provides no means in the BIOS to disable that function is just basically not a general-purpose computer, but rather a locked-down single-purpose appliance. If you buy such a thing, you are assuming the risk that your intended repurposing of the machine may be impaired or prevented by the technical measures to prevent unauthorised code running in kernelspace. My own preferred way of dealing with that would be to either (1) replace the BIOS with coreboot, or (2) sell off the offending hardware and get something more suitable. However: Matthew Garrett's shim bootloader and similar solutions provide ways to make UEFI Secure Boot an asset rather than a liability for Linux/BSD/etc. systems, so that's another way around the problem. Anyway, I _still_ continue to think that dual-booting is generally a solution to the wrong problem, and that running alternative OSes (such as MS-Windows ;-> ) in a virtual machine session gives vastly superior operational results. That is, in my experience, users who think they will get good usage out of a dual-boot setup are overly optimistic, and have not stopped to consider how disruptive of one's computing it is to shut everything down and reboot. In the long term, I've noticed, they stay 99.9% of the time in one OS and ignore the other. Which means they've wasted their time and effort. By contrast, a VM approach (given adequate RAM and CPU to make both OSes comfortable) allows and encourages concurrent use of both operating systems.
On 14/12/12 09:56, Rick Moen wrote:
You know, fundamentally, a computer with UEFI Secure Boot enabled _if_ it provides no means in the BIOS to disable that function is just basically not a general-purpose computer, but rather a locked-down single-purpose appliance.
An x86 system like that should not pass the Windows Logo testing as it requires that it be possible to disable secure boot. <irony> So a non-Windows8 Logo'd x86 system could lock you out, but a Logo'd one shouldn't. </irony> Another reason to support vendors who supply Linux based systems, e.g. ZaReason, System76, LinuxCertified, LinuxNow (who are Melbourne based), etc... Of course on ARM you're out of luck as secure boot must be locked on for Logo certification. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Chris Samuel <chris@csamuel.org> wrote:
<irony> So a non-Windows8 Logo'd x86 system could lock you out, but a Logo'd one shouldn't. </irony> Of course on ARM you're out of luck as secure boot must be locked on for Logo certification.
What best explains the different policies? Anti-monopoly laws? The ARM and x86 competitive situations are different. For x86, Linux would be rightly seen as the main competitor in market terms, which is what matters for the anti-monopoly regulations. For ARM-based tablets there are several competing systems, with none dominant as yet - and therein we find the fundamental divide between the ARM and x86 scenarios (leaving aside x86 on servers, which is not relevant to this discussion and where Linux is widely used). Thus it seems plausible that MS didn't want to risk potential regulatory difficulties in connection with the desktop market.
On 14/12/12 10:50, Jason White wrote:
What best explains the different policies? Anti-monopoly laws? The ARM and x86 competitive situations are different.
Not sure, though when secure boot was first mooted there were fears that it would be locked on x86, so MS then said they would be requiring it to be possible to disabled it. My understanding though is that Windows 8 on ARM is not purchasable separately, you can only get it preinstalled on a device. Given that any ARM devices are locked down already without secure boot it's probably harder to make the argument that MS should do things differently there. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On 14/12/12 13:31, Chris Samuel wrote:
Given that any ARM devices are locked down already
Oops - typo, that should be:
Given that many ARM devices are locked down already
s/any/many.. -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
At 09:56 AM 12/14/2012, Rick Moen wrote:
Anyway, I _still_ continue to think that dual-booting is generally a solution to the wrong problem, and that running alternative OSes (such as MS-Windows ;-> ) in a virtual machine session gives vastly superior operational results. That is, in my experience, users who think they will get good usage out of a dual-boot setup are overly optimistic, and have not stopped to consider how disruptive of one's computing it is to shut everything down and reboot. In the long term, I've noticed, they stay 99.9% of the time in one OS and ignore the other. Which means they've wasted their time and effort. By contrast, a VM approach (given adequate RAM and CPU to make both OSes comfortable) allows and encourages concurrent use of both operating systems.
I agree totally. The last time I dual booted for any reason other than temporarily loading Windows when getting an Optus cable moved or contacting their tech support (an operation done only 2-3 times!) would be in the order of 10 years ago, and even the last aforementioned "Optus test" would have been 8-9 years ago. And it is precisely for the reason you stated above. I found the hassle of rebooting to switch OSs, even while sharing diskspace between them and having a number of applications configured so they could run under different OSs (where possible) on the same data, was simply too time consuming. In 2003 or 2004 I purchased a copy of VMware Workstation (the only viable option at the time), and I never looked back. I still have a VM (running Windows 2000) from that era, though now it runs under VMware Fusion on a Mac. It's done the rounds of host OSs, Linux, Windows and OS X. :) For me, virtualisation has proven to be a vastly superior solution to dual/triple booting, except in rare circumstances, such as one soundcard based data comms application, which doesn't run well under VMware (a problem which will be solved by using a hardware TNC, rather than the software one, when funds permit). Interestingly, another soundcard based data comms application which uses a much more sophisticated software modem runs flawlessly in a VMware VM. Go figure... 73 de VK3JED / VK3IRL http://vkradio.com
participants (4)
-
Chris Samuel -
Jason White -
Rick Moen -
Tony Langdon