Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apple Silicon M1 Mac Native Release? #338

Closed
danielktdoranie opened this issue Jan 19, 2022 · 20 comments
Closed

Apple Silicon M1 Mac Native Release? #338

danielktdoranie opened this issue Jan 19, 2022 · 20 comments

Comments

@danielktdoranie
Copy link

Hi, will a Apple Silicon M1 Mac Native Release of Raspberry Pi Imager be forth coming? The current Mac release is not a "Universal" binary, doesn't have Apple Silicon M1 Mac native support and requires Rosetta 2 to run (Rosetta 2 is the Intel binary translator and will eventually be discontinued by Apple, as it isa only meant to provide developers with a period of time to transition to releasing a Universal binary with Apple Silicon support.)

I don't run Rosetta 2 on my Apple Silicon Mac as it is a battery and resource hog.

Thanks!

@maxnet
Copy link
Collaborator

maxnet commented Jan 19, 2022

Main problem is that if we switch to universal build releases that would require dropping support for the older Mac OS X 10.13 edition.
And there may still be users using that.
Not everybody can shelve out $ 2000 for the latest MacBook Pro.

I don't run Rosetta 2 on my Apple Silicon Mac as it is a battery and resource hog.

Do you have figures to back that up?

I do not have a M1, but the task manager screenshot in the other thread suggests a CPU usage of just 4,2% when Imager is run under Rosetta 2: #235 (comment)

@danielktdoranie
Copy link
Author

danielktdoranie commented Jan 19, 2022

Main problem is that if we switch to universal build releases that would require dropping support for the older Mac OS X 10.13 edition.

So the easy solution have separate builds and post them in the release section, that is what other devs do.

And there may still be users using that. Not everybody can shelve out $ 2000 for the latest MacBook Pro.

My M1 MacBook cost about half that, not that it’s at all germane to my original post: Raspberry Pi Imager should work on every available platform feasible. There also may be many users who want an Apple Silicon native build as well.

I don't run Rosetta 2 on my Apple Silicon Mac as it is a battery and resource hog.

Do you have figures to back that up?

I would suggest doing a search on Google for reviews on Rosetta 2. I no longer have it installed on my Apple Silicon Macs as if I wanted to run Intel/x86 code I’d own a computer with an x86 chip. Given that the Raspberry Pi ALSO uses an arm chip this shouldn’t be considered a radical position I wouldn’t think.

Instead of running native arm code on our Raspberry Pis let’s just emulate Intel code instead.

I do not have a M1, but the task manager screenshot in the other thread suggests a CPU usage of just 4,2% when Imager is run under Rosetta 2: #235 (comment)

@maxnet
Copy link
Collaborator

maxnet commented Jan 19, 2022

So the easy solution have separate builds and post them in the release section, that is what other devs do.

You can grab an UNTESTED (beyond compiling) universal build from the other thread linked if you really want it.
I don't envision it becoming an official build any time soon though.

@tkircher
Copy link

I do not have a M1, but the task manager screenshot in the other thread suggests a CPU usage of just 4,2% when Imager is run under Rosetta 2: #235 (comment)

I have an M1 Max and my own testing confirms that Rosetta 2 imposes a significant performance penalty beyond the ideological issue of running anything in emulation.

It's fine if the RPi project doesn't want to support the M1. Since it's open source, I'm sure there are plenty of other people who will, and will remember the animosity.

@danielktdoranie
Copy link
Author

danielktdoranie commented Jan 29, 2022

So the easy solution have separate builds and post them in the release section, that is what other devs do.

You can grab an UNTESTED (beyond compiling) universal build from the other thread linked if you really want it. I don't envision it becoming an official build any time soon though.

The “untested” imager for M1 works perfectly well.

@danielktdoranie
Copy link
Author

I have an M1 Max and my own testing confirms that Rosetta 2 imposes a significant performance penalty beyond the ideological issue of running anything in emulation.

It's fine if the RPi project doesn't want to support the M1. Since it's open source, I'm sure there are plenty of other people who will, and will remember the animosity.

I sure will remember. Ever since Apple Silicon came out haters in the FOSS community have just acted ridiculously, like toddlers throwing tantrums. These people go on and on about how evil Apple is but more than happy to buy products from companies like Pine64, the break if you look at them.

I can say Rosetta 2 SIGNIFICANTLY impacts battery life. Let’s remember it’s not gonna be supported or even available forever: is a temporary solution.

@tkircher
Copy link

I sure will remember. Ever since Apple Silicon came out haters in the FOSS community have just acted ridiculously, like toddlers throwing tantrums. These people go on and on about how evil Apple is but more than happy to buy products from companies like Pine64, the break if you look at them.

I do find it deeply ironic that RPi came out with an ARM64 module with 8GB RAM more than a year ago and it isn't even officially supported yet. (In the sense that there isn't an official Raspbian release that supports 64-bit)

@maxnet
Copy link
Collaborator

maxnet commented Jan 30, 2022

I have an M1 Max and my own testing confirms that Rosetta 2 imposes a significant performance penalty

Measured what way?

Can you share task manager screenshots of the CPU usage of the official Imager release, and the M1 build posted in the other thread?

@tkircher
Copy link

I have an M1 Max and my own testing confirms that Rosetta 2 imposes a significant performance penalty

Measured what way?

Can you share task manager screenshots of the CPU usage of the official Imager release, and the universal M1 build posted in the other thread?

First, there is no Task Manager on Mac or Linux. That's Windows only. The Activity Monitor is also not a reliable way of gauging system performance. Applications and system performance must be profiled.

I'd be happy to share all my profiling data, including CPU, memory, SSD, and network penalties, and the overall performance difference, as soon as I have assurances that an official native M1 build will be released and supported.

@maxnet maxnet closed this as completed Jan 30, 2022
@melyux
Copy link

melyux commented Jun 7, 2022

This isn't completed so it shouldn't be closed. Even if you don't intend to support the latest versions of Apple devices, for whatever reason.

@ashtoncowie
Copy link

ashtoncowie commented Jun 12, 2022

Not everybody can shelve out $ 2000 for the latest MacBook Pro.

Just leaving a reply to point out how unprofessional and unsavory this attitude is. I know it was meant as a dismissive exaggeration, but a used M1 Mac mini is about 1/4 of that price.

@maxnet
Copy link
Collaborator

maxnet commented Jun 12, 2022

I know it was meant as a dismissive exaggeration, but a used M1 Mac mini is about 1/4 of that price.

I rented one of those (well, its "developer transitioning kit" cousin) from Apple for a while, and it ran Imager under Rosetta fine.

Mainly it are Macbook users that are claiming to have problems.
E.g. that have read somewhere that running under emulation affects battery life. Which is naturally not an issue Mac Mini users will have, it being plugged in.

And there may or may not be an issue with the internal SD card reader that is only present on the Macbook Pro 14"/16" models. (Related to: #270 (comment) )
That one does start at 2249 EUR (2365 USD) in my country. Which is quite a bit of money for an issue I may or may not be able to reproduce with it.

@melyux
Copy link

melyux commented Jun 12, 2022

These are all personal issues, not project issues. The project issue, porting the software to the newest hardware, exists and shouldn't be closed.

@tkircher
Copy link

To follow up on the last comment, there are fundamental reasons why you always want all applications to be native to a given architecture. If anyone wants to argue about the fundamental concepts of computer science I'm sure that's always fun, but maybe in a different thread. Successful emulation is never sufficient, though in the case where a particular hardware architecture doesn't exist any more or is intractably hard to find or use, emulation is basically all you have. Like a SNES emulator. In this case, the M1 is just as widespread as Intel and AMD at this point and suggesting it shouldn't be supported because the emulator is good enough is hilariously incorrect.

@maxnet
Copy link
Collaborator

maxnet commented Jun 12, 2022

To follow up on the last comment, there are fundamental reasons why you always want all applications to be native to a given
architecture.

The majority of applications on the Windows platform are still compiled as x86 as well (Imager included).
Even though that is not native either if you are running the amd64 Windows edition on a 64-bit CPU.
The reason is simple, offering multiple editions and risking that users download the wrong one gives more problems, than the performance gains it gives.

That is not that dissimilar to one of the issues here.
If we switch to universal builds, those will not work for Mac OS X 10.13 users.
Offering multiple editions gives support issues.
While our current build does run for all users including those still running Mac OS X 10.13...

@tkircher
Copy link

The majority of applications on the Windows platform are still compiled as x86 as well (Imager included). Even though that is not native either if you are running the amd64 Windows edition on a 64-bit CPU.

That's just factually incorrect.

@holta
Copy link

holta commented Jun 12, 2022

“The law, in its majestic equality, forbids rich and poor alike to sleep under bridges, to beg in the streets, and to steal their bread.”

When the wealthiest corporation on the planet (AAPL, Apple Inc.) decides to support the poorest schools on the planet with M1 and M2 and M3 CPU's — that will be an incredible day. The very next day, a volunteer will likely be found to feed these hungry minds, bridging the gold-plated Apple Inc. ecosystem with the ground truth of 8 Billion Human Beings. She'll probably be 10 years-old from Malawi — and she'll deserve a Nobel Prize — for truly investing in all people. How do we get there?

  • Is the Raspberry Pi ecosystem (a very small social enterprise, at its core) already being pressured to become yet one more play-toy for the entitled wealthy in every country?

  • Or should the Raspberry Pi ecosystem invest in African kids and other children — who've been completely shut out of modern learning opportunities at almost every level?

The New Frontier: https://youtu.be/tIp251KCz6k

@melyux
Copy link

melyux commented Jun 12, 2022

Then there should be an official build for Apple silicon alongside the Intel one. No one's saying stop supporting obsolete versions or turn the Mac app into a universal one. Just add an official build for the modern version.

@tkircher
Copy link

* Is the Raspberry Pi ecosystem (a very small social enterprise, at its core) already being pressured to become yet one more play-toy for the entitled wealthy in every country?

* Or should the Raspberry Pi ecosystem invest in African kids and other children — who've been completely shut out of modern learning opportunities at almost every level?

The Pi foundation itself has already answered this question. They have been shipping all of their manufactured boards to their corporate customers, then whatever is left over, if anything, is made available for sale to the rest of us. They are currently making and shipping 500k boards per month.

@raspberrypi raspberrypi locked as too heated and limited conversation to collaborators Jun 12, 2022
@ghollingworth
Copy link
Contributor

As already discussed, we're not going to support yet another architecture release. If you feel you need to build a native version, you can do that and release your own version. This is open-source code after all.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants