> The Windows on Arm devices [...] are not locked down.

https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-c...

"[...] But for ARM devices, Custom Mode is prohibited: “On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enable.” [sic] Nor will users have the choice to simply disable secure boot, as they will on non-ARM systems: “Disabling Secure [Boot] MUST NOT be possible on ARM systems.” [sic] Between these two requirements, any ARM device that ships with Windows 8 will never run another operating system, unless it is signed with a preloaded key or a security exploit is found that enables users to circumvent secure boot."

This is for 32-bit Arm, back in the Windows RT and Windows Phone days.

This never applied to ARM64 Windows, ever.

Arm Macs are kinda locked down, but that's just for now. We'll see over the next year or so what the community comes up with as far as natively installing Linux goes.

They are not. Locked down = Apple explicitly prevents it through code signing.

Here, Apple doesn't prevent it in any way, and drivers can be developed. (drivers not present in Linux is not and will never mean that a device is locked down, don't stretch things please)

I see, and having to reverse engineer drivers to be able to run anything else on it to you somehow means that it's open?

Not locked down and open aren't the same things, don't conflate matters/deflect to another thing please.

You're the one who's conflating things. The fact that you somehow think that someone _no longer_ locking you out of their bootloader is now considered open just shows how far we've gone off the rails.

By that definition 99.99% of devices are open because you can just swap out the rom. All you need to do is figure out the pin and wiring and the serial protocols involved in communicating. My ducky keyboard is NOT open even though I replaced the firmware with my own.

What kind of insane logic is that?

And the fact that you and the other person here keeps conflating ANY documentation about ANY part of the hardware as contributing to Linux is even more ridiculous.

There were no claims of openness, because the opposite of “locked down” is not “completely open and here are the spec sheets”. Apple silicon devices let you boot your own code, which means they are not locked down, like say your iPhone is.

FWIW, the person you’re responding to is contributing to Linux for this hardware, so I wouldn’t grill them on conflating things ;)

I've contributed to linux for the Mac EFI myself, so that argument is moot. We clearly have different understandings of openness. I also wrote a savage driver for mplayer in the early 2000s but just because it was possible to write a driver for it, that doesn't mean the hardware was open in any reasonable sense of the word. Again, just because they decided to allow you to disable secure boot on those devices, probably mainly to drive adoption of their arch, doesn't mean it is any more open than a lock you can pick with your own lockpicking set.

The irony is that the jailbreaking crowd has spend so much time trying to break into apple devices that in comparison this now seems open.

EDIT: Also can we stop pretending that english isn't english and the opposite of locked isn't unlocked/open?

Nobody brought "open" into this discussion other than you. The claim was that this hardware is not locked down, and it is not. I don't think there is much more to say because this computer is literally the definition of not locked down because they give you the key to the lock.

Fair enough, but the GP actually did no mention of locked down. He said kinda locked down. Then your jailbreaking buddy defined that as "it's only locked down if it is a secure boot device where no third party access". When it's clear that that's not what the GP meant, not to mention that is english the opposite of locked is open/unlocked. Since we're still speaking english, "not locked" means open.

Not to mention that apple can silently overwrite this at any point in time with a MacOS update. As they have done so before leaving plenty of macs bricked because of broken SPI flash[1].

I share the excitement for the M1 chip, but you would have to be blind not to see this as troubling for the future of open computing.

[1] https://apple.stackexchange.com/a/395032

For a very long time, that was the position Linux was in on the desktop. Manufacturers providing drivers, or sufficient info to write them, for Linux, is pretty new, and still not exactly universal.

Windows on Arm devices don't allow you to disable secure boot last time I checked.

That's "locked down" if I can't run a kernel I compile.

What?

Every single one of them does. Just switch to the UEFI Setup and disable Secure Boot.

Note that I'm talking about Arm 64-bit Windows, and not the earlier Windows RT which is dead. Details for Linux for the best-supported Windows on arm64 laptops on that front at: https://github.com/aarch64-laptops/build

As of 2017, they both didn't allow UEFI Secure Boot to be disabled, and didn't allow UEFI Secure Boot to be switched into Custom Mode.

It looks like they walked some of that back at some point.

They did. Every single Windows on Arm64 system since release allowed Secure Boot to be off.

That limitation only applied on 32-bit Arm systems (Windows RT & Windows 10 Mobile, ARM != ARM64)

Then that's not "every single one of them", because there are Windows on ARM devices that aren't ARM64.