I don't think there is much here which wasn't known before for anyone who's been following this.. One can only hope that at some point in future Apple will share the documentation needed to natively boot linux. I read in this forum about Apple supporting PPC linux back in the PPC days. So its not completely unfounded. Regarding using the current M1 Macs for work, like many in these forums I am a server side developer and being able to test the applications on docker containers running locally is essential. I am still not clear if ARM or Intel based VMs will be available on M1 Macs or if it will even make that big a difference. Having a personal server to test applications which will be deployed on intel server is a workaround but not a convenient one. I am waiting to see how things will turn out. But given that there is large crowd of dedicated developer community I am sure Apple will come up with some workable solution.
If enough people let Apple know that they won't buy Apple Silicon computers if they can't boot another operating system, I am sure Apple will make that an option.
If enough people let Apple know that they won't buy Apple Silicon computers if they can't boot another operating system, I am sure Apple will make that an option.
LOL. No they won’t.
Of course they would, if "enough" people told Apple that they should. However, I don't think anywhere near "enough" people care for Apple to think it's worth paying attention to ahead of other priorities.
That's why I cannot use M1 Macs for work. I must have Intel compatibility to run VMs at near native speed. Unfortunately, I will have to buy Intel laptop.
This has nothing to do with virtual machines.
Yes it has. Show me how to run VirtualBox on Raspberry Pi for example so I could install other OS'es for Intel architecture. The only one VM result I achieved (and fooled some ignorants blocking me on Facebook for some short period) was running Android 7 on VirtualBox on Intel based macOS host system, but I bet Android 7 was ready to run x86 instructions because of Chromebooks. Just experiment. Usually it works with native instructions and emulates some parts of hardware.
That's why I cannot use M1 Macs for work. I must have Intel compatibility to run VMs at near native speed. Unfortunately, I will have to buy Intel laptop.
This has nothing to do with virtual machines.
Yes it has. Show me how to run VirtualBox on Raspberry Pi for example so I could install other OS'es for Intel architecture. The only one VM result I achieved (and fooled some ignorants blocking me on Facebook for some short period) was running Android 7 on VirtualBox on Intel based macOS host system, but I bet Android 7 was ready to run x86 instructions because of Chromebooks. Just experiment. Usually it works with native instructions and emulates some parts of hardware.
You wouldn't be able to run the Intel OSs natively either. That's the point, the OSs don't run on the architecture, so the fact that it doesn't run in a VM is barely relevant, except as a use case. Until the architecture or the OS is modified so it can run those OSs in an emulated or translated fashion, then VMs are a non starter. Unless the VM itself can do the emulation or translation, but I think that's a pipe dream. The people who make VM software aren't going to take on that task.
If enough people let Apple know that they won't buy Apple Silicon computers if they can't boot another operating system, I am sure Apple will make that an option.
Make what an option? Do you think Apple will abandon ARM processors and go back to selling Macs with Intel chips? I think it would require a near-complete boycott of the M1 architecture to convince Apple to do that, and that just isn't going to happen.
Or do you think Apple can somehow come up with a technology so an x86 VM can run on an M1 processor? If you think so, then you clearly don't understand what a VM is.
A virtual machine is not an emulator.
A virtual machine runs all software natively. The CPU executes the guest operating system the same way it executes the host operating system. The only difference (at a high level) is that the guest OS's access to hardware resources (memory, cores, I/O devices, etc.) is controlled by a piece of hypervisor software running on the host OS (or running directly on the CPU without a host OS, for some implementations).
In contrast, an emulator contains software to interpret or dynamically recompile software designed for a different (and incompatible) CPU instruction set, so it can run on otherwise incompatible hardware. This is how, for example, SheepShaver can run classic MacOS (using PowerPC instructions) on an Intel Mac. It is how VirtualPC could run x86 system software on PowerPC based Macs. And it is how Rosetta2 allows x86_64 Mac apps to run on Apple Silicon.
If your guest operating system is designed for a different CPU architecture from the hardware, then there is no possible way to use VM technology to run it. Only emulation will work there, and emulation is always slower than native code.
We are already seeing Linux VMs running on Apple Silicon, but these are running ARM builds of Linux. They are not x86 builds. Similarly, the current work to try and get Linux to boot natively on Apple Silicon is trying to make it boot ARM builds of Linux. Nobody is trying to natively boot an x86 operating system on Apple Silicon because the entire concept makes no sense.
This is the noose that turns Apple computers into Apple appliances. Without the freedom to run an OS or software of choice, these are no longer general purpose computers. I’m guessing regulators will also be looking closely at this as well.
This is the noose that turns Apple computers into Apple appliances. Without the freedom to run an OS or software of choice, these are no longer general purpose computers. I’m guessing regulators will also be looking closely at this as well.
That's complete nonsense. Nobody expects Apple or any other computer company to do the impossible.
You can't run PowerPC or ARM or SPARC or any other non-x86 system software on a PC without an emulator. And you can't run any non-ARM system software on Apple Silicon without an emulator.
As for deciphering the boot sequence to let ARM-based Linux run on a Mac, this is no different from earlier generations of Macs (68K, PPC and Intel) being able to run system software not approved by Apple. Apple has never supported this, but they have never explcitly tried to prevent it either. It's up to third parties to figure out how, and as we're seeing right now, the Linux community is coming pretty close to figuring that out.
The x86 PC is a unique example in the history of computing. It can run a variety of operating systems from a variety of sources because the hardware designers do not (in general) develop any system software, so they need to make sure their product are compatible with what others invent. But this is not and has not been the case for most other computer architectures. Nearly all other computers/workstations, current and historic (not just from Apple, but IBM, SGI, Sun, DEC, HP and others), are designed in conjunction with their system software and the manufacturers do not support the use of any third-party system software running on their hardware.
Very few people would consider all these computers to not be "general purpose" simply because they can't run x86 PC system software.
This is the noose that turns Apple computers into Apple appliances. Without the freedom to run an OS or software of choice, these are no longer general purpose computers. I’m guessing regulators will also be looking closely at this as well.
What alternative operating systems could you install on the classic Mac? And what purpose can you not achieve with software on an M1 Mac?
Patent nonsense, and regulators are not going to care when market share is barely double digit.
Weird headline indicates operating systems aren’t software, which is nonsensical on its face: operating systems are the quintessential software, upon which separate user space applications depend on to exist, as abstract libraries full of functions that allow users to interface between the physical hardware interfaces and the user space applications.
So, if you have more to worry about than adapting compiler toolchains, boot code, a little abstraction code for certain optimized APIs in the OS, and the HAL and device drivers, you’re doing it wrong.
The rest is mechanical in nature.
Point 1: good grief. People who have, you know, actually studied computer architecture and organization please speak up. In the meantime ... it has been common parlance for decades to refer to application software as software and systems software as the OS. And also to refer to both the kernel and the software that runs on top of the kernel but below the application software (conceptually) like the GUI as "the OS" when you really shouldn't, especially when it comes to Linux. So ... I don't get where you are going with this?
Point 2: "You're doing it wrong ... the rest is mechanical in nature." Ah. That is where you are going with this. The first is FALSE and the second is VERY FALSE. Clearly you haven't done this before. Let the people who have be the ones to talk about this because they are the ones who are actually qualified to do so. Go try to port a major application from x86 to ARM on the same OS (i.e. Linux or Android) and see how "mechanical" it is. Not even that ... merely port a 32 bit application to a 64 bit one. Done it before? It is neither easy or fun. But I guess it should have been "mechanical" and it was "being done wrong" eh? Goodness where do people like this come from?
Well, I go to clear out long-open tabs, and come back to this thread.
Guess what, I do this sort of thing for a living. I work in the bowels of a major OS, in the context of ALL the code, not just that which executes in user-space. Guess what? It’s exactly as I’ve described it as far as how things are abstracted! Also guess what? The OS provides LOTS of abstractions in libraries you link into your application for a huge number things to make your life far easier. Guess what? Yes, making a direct port between one machine architecture and another IS done by the Hardware Abstraction Layer of the OS for a lot of the things that need to be abstracted, a d there is ALSO an ABI (Application Binary Interface) standardized for each compatible processor that runs the same low-level code, in the case of Intel, how things are passed via the registers and the stack vary based on whether it is 32-bit or 64-bit. Sure, you could pass everything via the same ABI on 64-bit, but it has more registers to work with, so that’s something good to take advantage of.
Now, about the code in user-space applications: given the same source code, whatever the higher-level language, even if it is NOT perfectly “portable” (C/C++ have a huge number of things in the language specifications explicitly left to the vendors to specify, because they’re intended for use at the lowest system level for performance) and, this will clearly amaze you, to get perfectly correct translations from one CPU to any other CPU for anything at a level higher than native assembly language ABSOLUTELY has a mechanical transform you can make from code A to code B to achieve the same logical results. Things are a little more interesting when sizes of integers used from one CPU to the next, but despite all that, it is STILL very mechanical and straightforward to translate working code from one CPU to the next: this is very commonly done in C/C++ via macros and the preprocessor.
Comments
Regarding using the current M1 Macs for work, like many in these forums I am a server side developer and being able to test the applications on docker containers running locally is essential. I am still not clear if ARM or Intel based VMs will be available on M1 Macs or if it will even make that big a difference. Having a personal server to test applications which will be deployed on intel server is a workaround but not a convenient one. I am waiting to see how things will turn out. But given that there is large crowd of dedicated developer community I am sure Apple will come up with some workable solution.
Patent nonsense, and regulators are not going to care when market share is barely double digit.
Guess what, I do this sort of thing for a living. I work in the bowels of a major OS, in the context of ALL the code, not just that which executes in user-space. Guess what? It’s exactly as I’ve described it as far as how things are abstracted! Also guess what? The OS provides LOTS of abstractions in libraries you link into your application for a huge number things to make your life far easier. Guess what? Yes, making a direct port between one machine architecture and another IS done by the Hardware Abstraction Layer of the OS for a lot of the things that need to be abstracted, a d there is ALSO an ABI (Application Binary Interface) standardized for each compatible processor that runs the same low-level code, in the case of Intel, how things are passed via the registers and the stack vary based on whether it is 32-bit or 64-bit. Sure, you could pass everything via the same ABI on 64-bit, but it has more registers to work with, so that’s something good to take advantage of.
Now, about the code in user-space applications: given the same source code, whatever the higher-level language, even if it is NOT perfectly “portable” (C/C++ have a huge number of things in the language specifications explicitly left to the vendors to specify, because they’re intended for use at the lowest system level for performance) and, this will clearly amaze you, to get perfectly correct translations from one CPU to any other CPU for anything at a level higher than native assembly language ABSOLUTELY has a mechanical transform you can make from code A to code B to achieve the same logical results. Things are a little more interesting when sizes of integers used from one CPU to the next, but despite all that, it is STILL very mechanical and straightforward to translate working code from one CPU to the next: this is very commonly done in C/C++ via macros and the preprocessor.