these two emails are interesting. Thank you Yasha and Nico. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Nico Kadel-Garcia <nka...@gmail.com> wrote: On Thu, Oct 20, 2011 at 6:16 PM, Yasha Karant <ykar...@csusb.edu> wrote: > Any idea how to get persons such as Victor Helsing to understand the issue > here? -- this is NOT a rant. If we ignore it, we shall all be in the soup. It's a rant. By continuing to rant, you discourage people from paying attention to such issues where and when they *are* relevant, such as (hopefully) the material below. A discussion of the UEFI technology and its direct effects on Linux or Scientific Linux based hardware management might be useful. What are our favorite upstream vendor's plans? And ave you actually laid hands on the technology or attempted to use it, to see the implications of it. For example, it avoids the "63 block" DOS compatiliby chunk of space at the beginning of your available disk space, avoiding the 4096 byte block alignment problem for both real and virtualized hardware on more modern hard drives. And boot loaders have suffered from a great deal of awkwardness in backwards compatiblity requirements, for example with the 8 1023 cylinder limitation with earlier versions of LILO and motherboards, and with various other complex schema to work around legacy requirements. So a new, well defined boot loader architecture can make eminent sense. The problem is the lockdown features. It's completely understandable that people who buy computers, and maintain them, do *not* want arbitrary script kiddies or laptop thieves to be able to boot a live CD or USB stick and read everything off their drive. My Windows and other friends are *shocked* when I walk in with a live CD, including ones very like Scientific Linux's, and help them recover lost data or change relevant passwords. In general, if I can access your hardware, I own your data. The need for freedom and access to our own tools conflicts with this. Being able to change a kernel or OS freely is vital to developers, students, and people who need their tools modified for reasons software vendors don't agree with. It's also *vital* for anonymity. Too many systems record too much data. But this conflicts with desires for security. We've seen things like this play out with SELinux. The toolkit is powerful, flexible, and so unpredictable and poorly integrated and complex that most developers would actively *fire* me if I tried to make them work with it. I'll be very curious to see if UEFI's vaunted security features suffer from the same flaws in the long term. Support for UEFI *is* built into recent releases of grub and various virtualization technologies, so I don't anticipate it being too much of a Linux issue unless the lock down features are enforced.