3 ms·

That exists already - it's called the MacBook Air with M1, which has 256GB/512GB storage options and 8GB/16GB RAM options as you wished for. It's got Linux bein

That exists already - it's called the MacBook Air with M1, which has 256GB/512GB storage options and 8GB/16GB RAM options as you wished for. It's got Linux being brought-up for it by @marcan42 and already can boot from a mainline kernel (though hardware support is still coming along, but they've already nearly got an OpenGLES GPU driver less than a year after launch). Also Apple went out of their way to make Linux and other OSs able to boot on it, so don't expect Apple to take away what they worked hard on. What's novel about this Linux Laptop though is the low cost, $200. But you get what you pay for. And the M1 is, a year from now, probably going to have better (if not completely) upstream hardware support.

freedomben 5y ago
Please don't buy an M1 thinking it will be a good linux machine. There is still a lot of work that needs to be done. Get A Framework (frame.work) laptop or a Lenovo ThinkPad T series instead. Dell has some nice ones too but I haven't used any in a couple of years.
- gjsman-1000 5y ago
  I respectfully disagree. @marcan42 is doing the development work and firmly believes that, once completed, the M1 machine will provide a superior experience to Intel machines. Also, while there is a ways to go, a shocking amount is fully completed: I2C, UART, Power Management, GPIO, Display Controller, USB, Thunderbolt, NVMe storage, the works. Hector says he is just rewriting a few drivers from other folk, going to merge it upstream, and then really only the GPU is remaining. But he has a friend working on that and less than a year later and despite not being the primary focus, they're nearly at OpenGLES, which has shocked people for how fast the GPU drivers are coming together.
  - DarylZero 5y ago
    Sounds like you agree there is work to be done before it's suitable to buy.
sofixa 5y ago
> Also Apple went out of their way to make Linux and other OSs able to boot on it, so don't expect Apple to take away what they worked hard on. Do you have more details? I was under the impression Apple did nothing and haven't published any documentation, making a Linux port an exercise in reverse engineering every little bit. If Apple really wanted Linux to be able to run on M1s, they could have upstreamed patches / sponsored the development required. Instead people are volunteering their time to do that without any help (direct or just documentation or tooling), hoping Apple won't pull the rug from under them.
- gjsman-1000 5y ago
  Sure - you can ask @marcan42, but it basically goes like this: Apple could have just copied-and-pasted the iPhone boot process, and that would have been extremely easy to do because M1 Macs and iPhones and iPads all share the same system for booting (being all Apple Silicon chips), that is, iBoot. Apple could have just thrown in iBoot but with signature enforcement for macOS instead of iOS and called it a day. Nothing but macOS would boot, but would Apple really care? However, Apple went out of their way to not do this, but extended iBoot with Boot Policies, also referred to as the LocalPolicy. Apple documents this themselves at: https://support.apple.com/guide/security/boot-modes-sec10869885b/web https://support.apple.com/guide/security/boot-modes-sec10869... https://support.apple.com/guide/security/contents-a-localpolicy-file-mac-apple-silicon-secc745a0845/web https://support.apple.com/guide/security/contents-a-localpol... Along with the Permissive Security mode at https://support.apple.com/guide/security/startup-disk-security-policy-control-sec7d92dc49f/web https://support.apple.com/guide/security/startup-disk-securi... With the LocalPolicy, every partition and OS install gets their own Security Policy, which is another area where Apple goes above-and-beyond other systems. On Windows computers and Android devices, a device would typically be marked as "Secure Boot Enabled" or "Secure Boot Disabled" (no signature enforcement), on a chip/system-wide level. With this Boot Policy system, every OS can have their own secure boot mode, meaning you could have a fully-secure MacOS install alongside a (unsecured) Linux install, no problem. You might wonder, if every OS can just have their own secure boot settings, how come a thief couldn't just replace a secure boot MacOS partition with a Linux no-secure-boot partition. Apple managed to prevent this with an extremely complicated "ownership" system that prevents a third-party hacker or a thief from being able to clear those BootPolicies without the owner's permission, as documented at: https://eclecticlight.co/2021/07/18/last-week-on-my-mac-the-perils-of-m1-ownership/ https://eclecticlight.co/2021/07/18/last-week-on-my-mac-the-... Again, if Apple only cared about letting macOS run, copying-and-pasting regular iBoot would have worked fine. Instead, they had to tack on Permissive Mode, code signing from the Secure Enclave (for custom kernels), "ownership," and Boot Policies. A lot of work to just pull out the rug, right? As if just enabling it with all of these otherwise-unnecessary add-ons wasn't enough, there are other signs of Apple being more... permissive about things. For example, unlike almost every other ARM chip which makes a huge mess of things, Apple has implemented their drivers in a way that means the same driver can handle different chips with the same core designs without almost any rewrites. An example of this is that, imagine the high-performance Firestorm cores on the M1. Marcan can just write a driver for Firestorm, and it will just work on the M1, M1 Pro, and M1 Max without rewrites for each chip that contains it (other than updating the device tree outside the drivers). That's unheard of for other ARM chips and makes future maintenance a breeze. And, yes, Apple didn't provide and still does not provide much public documentation about their chip, but there is an extra grace: MacOS, apparently, has the ability to run under a lightweight hypervisor with hardware passthrough with no flak or patching necessary on the M1 chip (amazing considering how few ARM chips have virtualization, let alone this well implemented?) This meant that even though the hardware is undocumented, Marcan could write a small hypervisor called m1n1, run MacOS within it, and document all of the hardware calls and commands completely transparently. It didn't need to be that-well implemented. Maybe that's Apple doing a good job, or maybe it's them giving a less-obvious help.

freedomben 5y ago

Please don't buy an M1 thinking it will be a good linux machine. There is still a lot of work that needs to be done. Get A Framework (frame.work) laptop or a Lenovo ThinkPad T series instead. Dell has some nice ones too but I haven't used any in a couple of years.

gjsman-1000 5y ago
I respectfully disagree. @marcan42 is doing the development work and firmly believes that, once completed, the M1 machine will provide a superior experience to Intel machines. Also, while there is a ways to go, a shocking amount is fully completed: I2C, UART, Power Management, GPIO, Display Controller, USB, Thunderbolt, NVMe storage, the works. Hector says he is just rewriting a few drivers from other folk, going to merge it upstream, and then really only the GPU is remaining. But he has a friend working on that and less than a year later and despite not being the primary focus, they're nearly at OpenGLES, which has shocked people for how fast the GPU drivers are coming together.
- DarylZero 5y ago
  Sounds like you agree there is work to be done before it's suitable to buy.

sofixa 5y ago

> Also Apple went out of their way to make Linux and other OSs able to boot on it, so don't expect Apple to take away what they worked hard on. Do you have more details? I was under the impression Apple did nothing and haven't published any documentation, making a Linux port an exercise in reverse engineering every little bit. If Apple really wanted Linux to be able to run on M1s, they could have upstreamed patches / sponsored the development required. Instead people are volunteering their time to do that without any help (direct or just documentation or tooling), hoping Apple won't pull the rug from under them.

gjsman-1000 5y ago
Sure - you can ask @marcan42, but it basically goes like this: Apple could have just copied-and-pasted the iPhone boot process, and that would have been extremely easy to do because M1 Macs and iPhones and iPads all share the same system for booting (being all Apple Silicon chips), that is, iBoot. Apple could have just thrown in iBoot but with signature enforcement for macOS instead of iOS and called it a day. Nothing but macOS would boot, but would Apple really care? However, Apple went out of their way to not do this, but extended iBoot with Boot Policies, also referred to as the LocalPolicy. Apple documents this themselves at: https://support.apple.com/guide/security/boot-modes-sec10869885b/web https://support.apple.com/guide/security/boot-modes-sec10869... https://support.apple.com/guide/security/contents-a-localpolicy-file-mac-apple-silicon-secc745a0845/web https://support.apple.com/guide/security/contents-a-localpol... Along with the Permissive Security mode at https://support.apple.com/guide/security/startup-disk-security-policy-control-sec7d92dc49f/web https://support.apple.com/guide/security/startup-disk-securi... With the LocalPolicy, every partition and OS install gets their own Security Policy, which is another area where Apple goes above-and-beyond other systems. On Windows computers and Android devices, a device would typically be marked as "Secure Boot Enabled" or "Secure Boot Disabled" (no signature enforcement), on a chip/system-wide level. With this Boot Policy system, every OS can have their own secure boot mode, meaning you could have a fully-secure MacOS install alongside a (unsecured) Linux install, no problem. You might wonder, if every OS can just have their own secure boot settings, how come a thief couldn't just replace a secure boot MacOS partition with a Linux no-secure-boot partition. Apple managed to prevent this with an extremely complicated "ownership" system that prevents a third-party hacker or a thief from being able to clear those BootPolicies without the owner's permission, as documented at: https://eclecticlight.co/2021/07/18/last-week-on-my-mac-the-perils-of-m1-ownership/ https://eclecticlight.co/2021/07/18/last-week-on-my-mac-the-... Again, if Apple only cared about letting macOS run, copying-and-pasting regular iBoot would have worked fine. Instead, they had to tack on Permissive Mode, code signing from the Secure Enclave (for custom kernels), "ownership," and Boot Policies. A lot of work to just pull out the rug, right? As if just enabling it with all of these otherwise-unnecessary add-ons wasn't enough, there are other signs of Apple being more... permissive about things. For example, unlike almost every other ARM chip which makes a huge mess of things, Apple has implemented their drivers in a way that means the same driver can handle different chips with the same core designs without almost any rewrites. An example of this is that, imagine the high-performance Firestorm cores on the M1. Marcan can just write a driver for Firestorm, and it will just work on the M1, M1 Pro, and M1 Max without rewrites for each chip that contains it (other than updating the device tree outside the drivers). That's unheard of for other ARM chips and makes future maintenance a breeze. And, yes, Apple didn't provide and still does not provide much public documentation about their chip, but there is an extra grace: MacOS, apparently, has the ability to run under a lightweight hypervisor with hardware passthrough with no flak or patching necessary on the M1 chip (amazing considering how few ARM chips have virtualization, let alone this well implemented?) This meant that even though the hardware is undocumented, Marcan could write a small hypervisor called m1n1, run MacOS within it, and document all of the hardware calls and commands completely transparently. It didn't need to be that-well implemented. Maybe that's Apple doing a good job, or maybe it's them giving a less-obvious help.