91–100 of 161 posts
It seems like this is a bug, apple went through the trouble to allow something like asahi to be possible in the first place. I doubt they're purposely trying to break it.
if going through trouble means "doing less shit to lock their systems down", then yes.
Apple ultimately dgaf about linux.
Earlier quoted context omitted.
It's Apple's bootloader. They were the ones that chose to use iBoot and not implement UEFI-style booting like prior Macs.
...why would they, this is a strict improvement with less surface area
The onus is on Apple to not make iBoot suck, they don't get a free pass for Microsoft-level boot volume ignorance.
Sadly both main ARM platforms (Apple silicon and Qualcomm) are a mine field for Linux
Most computers have been like that, FOSS got lucky that IBM failed to secure the PC for themselves, thus the PC clones. When folks say Intel and AMD are done, and we should all be on ARM, or RISC-V, beware of what to wish for. Yes there are device trees now, however someone has to keep them up to date, and that is only part of what makes a motherboard.
Earlier quoted context omitted.
Apple designed a bootloader for Apple Silicon Macs that allows you to run an unsigned OS without degrading security when you boot into MacOS. This wasn't an accident. Macs have always allowed you to run another OS. iDevices have always had a locked bootloader. People shouldn't confuse the two.
If they allowed something similar on iphones, I'd switch to an iPhone the day an alternate os worked well enough for daily use.
I think it would be nice if we could run unsigned apps on iOS (in the US), but booting your own OS on an iPhone is a whole different story
Earlier quoted context omitted.
> M series macs are weird More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over? > Can't help but to think the goal of this wasn't to actually allow third-party OSes Apple has explicitly stated that allowing third party OSes is exactly the purpose of the new bootloader.
Yes, more weird than that. x86 PCs have fairly standardised boot and autoconfiguration (UEFI and ACPI). ARM based systems, including the Apple M series, don't. You just have to know what's there (device trees), and Apple isn't going to tell you. Hence why it's difficult to make another OS run on it, because you first need to find out what hardware's even there, and how to talk to it. It's initialised by Apple before…
You're thinking of old SBCs, most likely. ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included) have +/- same level of auto-configuration and hardware resource discovery as x86 PCs.
Sadly both main ARM platforms (Apple silicon and Qualcomm) are a mine field for Linux
Most computers have been like that, FOSS got lucky that IBM failed to secure the PC for themselves, thus the PC clones. When folks say Intel and AMD are done, and we should all be on ARM, or RISC-V, beware of what to wish for. Yes there are device trees now, however someone has to keep them up to date, and that is only part of what makes a motherboard.
I agree with the ARM/RISCV stance that we should be cautious with what we ask. I have seen some RiscV providers in China are starting to push for a BIOS compatible boot system which is great to see, but there is no guarantee that it will be adopted or it will last for long.
Earlier quoted context omitted.
As an aside: > ... copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin ... This should be your hint that UNIX certification is more of a box-checking exercise than a real test of functionality. UUCP has been functionally obsolete since at least the mid-1990s; it's surprising that macOS even bothers shipping its binaries, an…
It doesn't look like the certification requires those UUCP binaries to be in /usr/local, that's just where you have to put them on macOS to be able to `chmod +s` them, which is what the certification actually requires. Less arbitrary, but even more clearly obsolete and bad practice for a modern OS.
Anyways, "real UNIX systems must implement UUCP" is still extremely silly.
Earlier quoted context omitted.
Yes, more weird than that. x86 PCs have fairly standardised boot and autoconfiguration (UEFI and ACPI). ARM based systems, including the Apple M series, don't. You just have to know what's there (device trees), and Apple isn't going to tell you. Hence why it's difficult to make another OS run on it, because you first need to find out what hardware's even there, and how to talk to it. It's initialised by Apple before…
>ARM based systems, including the Apple M series, don't. You're thinking of old SBCs, most likely. ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included) have +/- same level of auto-configuration and hardware resource discovery as x86 PCs.
Either this is untrue or misinterpreted - the SystemReady DeviceTree band (the only one Macs could possibly fit into, given they don't implement ACPI) still requires that devices implement EBBR, which requires that devices implement UEFI. Macs don't, and so are very much not SystemReady compliant.
Earlier quoted context omitted.
I don't know about Intel ME but AMD PSP is basically the equivalent of Apple's Secure Enclave, so there's that.
You should probably do do some reading on the subject to gain a bit more understanding: > This puts [Apple Silicon Macs] somewhere between x86 PCs and a libre-first system like the Talos II in terms of freedom to replace firmware and boot components; while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME an…
AMD PSP is little more than an embedded TPM. The capabilities are significantly different vs. Intel ME.
It’s a beta… Apple is very pro Asahi
I don't believe that Apple has ever acknowledged the project at all, let alone promote it. Apple is neutral towards their work as far as I can tell.