They open sourced the whole .net framework and porting it to Linux is on the way. This may be a first step.
As for UEFI, I admit I have not followed things too closely on that side. I can understand the need for protection from rootkits and I think that’s why they want to require UEFI to accept only signed executables. However, I wouldn’t be surprised if someones offers to sign things for open source projects. I would be uncomfortable if such signing is in the hands of Microsoft, and I would prefer that UEFI manufacturers provide a way to manage security keys…
It will be most probably again like it is now: Users can disable the option in the BIOS. UEFI is really a mess in this regard. Nice idea but the way it is done it’s (A) monopolizing and (B) not working as expected. I always disable UEFI first everywhere I come since it’s just a mess.
And UEFI requirements will affect everyone in 2020 adversely, except of course, Microsoft. This is relevant because even though Microsoft != SB, they are a large part of what OEMs choose. Only Windows, and the Big Linuxes like RHEL and Canonical are guaranteed to survive.
Yup, which is why I’ve slowly converted much of my personal computing world over to little ARM boards, which it seems to me will probably always be available in open versions for hobbyists. There’s not just one source, but many sources from S Korea, China, etc. And those boards are getting more powerful all the time. For most things my Odroid equals my AMD.
Well, I don’t think ‘standard’ 64-bit architectures can be avoided altogether – or at least not until an open source ARM board can not only reach, but reliably sustain, the same level of performance that a normal PC can. And also one of the other reasons to stick with a standard PC is Haiku, which boots and runs on most x86/amd64 hardware so far. I do encourage anyone buying new PCs to support AMD, though, as they seem to be better than Intel in terms of fostering open support and help beat back the monopoly. Personally speaking, the only machines I have left running Intel processors are my vintage stuff and Intel-based Macs (and hopefully Mac will switch to something ARM-based in the future as speculated in some places).
But I can’t mention enough that I am worried about the future of UEFI on consumer machines and lockout, as the option to use legacy BIOS/CSM will most likely be deprecated. And I hope that’s not the case, but if it is, it seems to go back to ‘he who controls the bootloader’ all over again. I do support using Raspberry Pi and have a 2 and 3+, but Haiku can’t run on it, and I have no low-level skills to contribute to porting and Haiku’s focus is on x86… so it continues to run Linux and BSDs. But in any case, back on topic, I do hope Microsoft is truly changing from who they were.
Just a precision: UEFI by itself does not prevent from booting other OS. It is a welcome upgrade of the legacy BIOS, which left us with hacks such as MakeBootable, active partitions, and other similar things.
SecureBoot is the part where UEFI requires the bootloader to be signed with a known key. Either it should be possible to disable this altogether (but then you are vulnerable to rootkits), or it should be possible to manage the list of allowed signatures (and then you could self-sign your bootloader, or just add Haiku’s key to the allowed list, for example). But then you are vulnerable to “smart” rootkits which would sneak in their own key there. So there is a compromise to make between security and flexibility, as usual.
True. I never mentioned it (by or of itself, that is) would prevent it; the MacBook, afaik, was one of the first consumer machines to mass ship with an EFI (extensible firmware interface) implementation, and in business, machines like the Itanium and HPCompaq/EliteBook notebooks had it. Everything from diagnostic tools to whatever one could write in that space was possible. And Tianocore remains free to study. Whether it’s welcome or not, though, depends on who is asked.
Yes, as of right now, per spec 2.3. I’m not worried about what is happening right now, where keys can be enrolled into the system manually or where there is a switch to turn it off (and to turn CSM on) but the upcoming spec. No need to lecture me on this; in Gnu/Linux, we can create and provision keys for a SB system, like on my Pavilion. It seems everyone here keeps mentioning present-day.
The freaky question is this: Will the upcoming changes restrict Secure Boot further? I don’t know, and until the rumors become more clear as the date gets closer, we won’t know. That’s what scares me. The only thing I do know so far is that CSM is being deprecated in favor of booting using UEFI mode only. When this happens (rumored to be 2020) — that is when I’m worried that an improved Secure Boot will be in place. Have you ever tried to boot anything other than Windows 8 on some tablets? I have. Fedora or Ubuntu is the only other thing I have found that will boot on those, where compatibility modes aren’t an option. And as much as I like Apple, it really stinks that iPad can only boot iOS for the same reason. One of my side projects is to at least write a shell over the browser that will allow running apps in it, but that doesn’t remove the fact it’ll still be running iOS.
I can’t repeat it enough — locked up devices is the future I’m scared of. Only time will tell whether or not this fear is founded or not. It could all be nothing. Because I’m only speculating. And could be wrong.
We are well into getting Haiku to boot from UEFI devices without needing a BIOS. In fact it already works, but it is not integrated into our distributed images because we didn’t get it to blend with the other parts of the “anyboot” image. So I’m not worried about UEFI, as long as we can get past the signing/keys part one way or another.
The biggest blocker is nobody has yet to figure out how to build the both the BIOS and EFI loaders in Jam. It was written assuming one bootloader per platform.
Why is having both options in the image a blocker? In my humble opinion, I truly think that two years, if this goes the way things are slated to go, the 64-bit edition/build of Haiku should focus on UEFI, which will be default everywhere by then. Save BIOS for 32-bit/legacy boards with CSM built < 2020.
I’m immensely grateful for the EFI support Haiku has. I think the big concern is the signing and secure boot, as I’ve kept mentioning, because (U)EFI is the future.
While I applaud the new MS stance on open source, and though my interactions with them have always been good and I think they do a lot of great research and have a lot of great people, in terms of entrusting them with data, as a company I believe they have shown that they absolutely cannot be trusted. They have been shown to share personal user data with security agencies, almost certainly illegally, behind users backs, while denying it. How can you trust them with your data after that? I will remove my projects from GH, although at my own pace…
(They did also try to destroy everything open source for a very long time, using rhetoric that likened it to cancer and other things. Which, you know, was not really nice. They are embracing it now, since they lost that battle, and these days it suits them - i.e. is profitable).
I still remember the tweaks that the GNU/Linux distros done to boot on UEFI computers. Microsoft is the same, but with another approach to get manpowered people. They are a company that uses floss to have profit, not to empower the people or so.
I think the big concern is the signing and secure boot, as I’ve kept mentioning, because (U)EFI is the future.