On 2013/03/05 15:32, Tom H wrote:
On Sat, Mar 2, 2013 at 11:09 PM, jdow <j...@earthlink.net> wrote:
On 2013/03/02 15:18, Tom H wrote:
On Fri, Mar 1, 2013 at 11:15 PM, jdow <j...@earthlink.net> wrote:
On 2013/03/01 09:26, Tom H wrote:
On Thu, Feb 28, 2013 at 7:08 PM, jdow <j...@earthlink.net> wrote:
On 2013/02/28 11:56, Tom H wrote:
On Thu, Feb 28, 2013 at 2:38 PM, Robert Blair <r...@anl.gov> wrote:
On 02/28/2013 01:35 PM, Tom H wrote:
I wouldn't be surprised if SB became "un-disable-able" in the next
few years. We'd then have to use an MS-signed shim to boot, as is
now the case with the default Fedora and Ubuntu SB setups.
Maybe I've missed something here. If a generic "MS signed shim" is
available what value does this add? Wouldn't such a shim make booting
anything alternative possible?
I'm sorry. It's not as generic as I made it look. AIUI, the shim is a
basic stage 1 (or maybe stage 0.5) bootloader whose signature's
validated against an MS key in the computer's ROM. Grub and the kernel
(and its modules in Fedora's case but not in Ubuntu's) are then
validated against a Fedora key in the shim.
Which is the end of compiling your own code.
You mean "compiling your own kernel without spending a one-time fee of
USD
99."
A difference which makes no practical difference is no difference at all.
Of course there's a difference. It's grub and the kernel and its
modules that you can't compile without signing.
You missed the point, Tom. To a retired person a $100 bill is a serious
amount of eating that has to be traded off with it. If that cannot be
afforded without sacrifice then it might as well not exist as an option.
That is the difference that makes no practical difference.
The Microsoft extension to the issue is essentially the locked cellphone
situation under which I could not code up any new assistive technology
for myself and use it. It becomes me paying to have Microsoft own my
device. And I'd have to pay them to use my own work on a machine I have
every right to regard as my own machine.
If Linux is going to systematically support that kind of a model in any
way, I'm outahere.
You're "outahere" to where?! As long as you can turn off SB, you're OK
using whatever you want to use. If we get to a point where we can't
turn off SB on x86, you'll have to use a non-x86, non-ARM processor.
If I get locked out - why should I ever consider Linux for a desktop?
It would still make a useful if frustratingly non-functional server.
I didn't consider the USD 99 because I didn't think it relevant.
Compiling your own SB-compatible kernel's a luxury. Your computer
isn't non-functional without doing so.
There is a feature I must compile in on the kernel if I need to use
it that gives me access to some archival data from a file system that
supports names incompatible with NTFS but compatible with Linux, barely.
Anyway, I found out today that my SB knowledge's out of date. The shim
now supports MOKs (Machine Owner Keys) and is distributed with a
"MokManager" program. So you can generate keys with openssl, sign your
EFI binaries with them, and enroll your MOK certificate with
"MokManager".
That seriously alleviates my worries. Thanks for pointing that out, Tom.
That one thank you and one "you're still not on the right page with
your assumptions." Damn few people need AmigaDOS access. Even fewer
need access via one of it's lesser used but more advanced filesystems.
I'm one of them. And I had to get at the data for some serious searches
a some months ago. It's a shame that compile is out of date already. But,
better security holes patched than keeping an old kernel for a seldom
used purpose. And I like this access rather than emulator access because
someday the emulators may stop working for one reason or another. They
live on a machine retired several years ago at the moment.
{^_^}
