Virtualbox Mac m1

Yes, they should inform about which is popular app is being used since long. Moreover I as a user won’t go to each and every third party app to check whether apple m1 will work or not. This is not user’s job. I spending **** lot of money in apple products and they are solely responsible to circulate these info on their release notes. This is simply hiding the information and cheating the people and making money.

Abhi1640 wrote:

Yes, they should inform about which is popular app is being used since long. Moreover I as a user won’t go to each and every third party app to check whether apple m1 will work or not. This is not user’s job. I spending **** lot of money in apple products and they are solely responsible to circulate these info on their release notes. This is simply hiding the information and cheating the people and making money.

I'm afraid you have this totally backwards. It is the responsibility of the third party app developer to keep their app compatible with whatever system they want their app to be used on. It is the responsibility for users to check that their third party apps will continue to work when upgrading a system. It would be impossible for Apple, Microsoft , or any other computer company to keep track of the millions of users and third party apps in use. You are asking these computer companies to keep their systems compatible with third party apps. Never going to happen.

dangoulet1 wrote:

ARM processors aren’t typically used in high performance applications and Apple has really created the best ARM chips of all time, it’s quite an achievement. But look at high performance server systems and you won’t see ARM there.

Don't be so quick to say that; there are more than a few server companies investigating ARM for the same reason Apple did - better performance with lower power consumption and Intel's roadmap is way behind.

dangoulet1 wrote:

ARM processors aren’t typically used in high performance applications and Apple has really created the best ARM chips of all time, it’s quite an achievement. But look at high performance server systems and you won’t see ARM there. Lol. People that develop software for these backends don’t need ARM desktops they need the same configuration.

If you want and need x86-64 clients, by all means purchase and use x86-64 clients. Use what works best for your needs.

As for high-performance servers running Arm, here’s one:

https://www.arm.com/company/news/2021/06/arm-powered-fugaku-supercomputer-claims-1-spot-on-top500

“Lol” indeed.

VMWare Fusion doesn’t run x86, neither does Parallels man. You left out the most important part on that.

Docker doesn’t really work, it sort of works. If it doesn’t run x86 images then no, it really doesn’t work the same.

Btw, I’m not really certain if you’ve been doing any dev lately, but many python libraries require native libraries, usually written in C. Things written in C aren’t always able to target other CPU’s. This goes for lots of development stuff, not sure what tools you’re using.

Have you ever done any ML? Most people do small bits locally on their laptops to build it and deploy to the cloud to scale it and do the training. How else would you do this? Run it in the cloud and pay per hour? Geeez.

Most developers including massive companies only target x86, that’s why we’re talking about this. Most companies do not target ARM, except for Android, iOS and a few things like rpi. If you’ve ever tried working on an rpi or anything like that you’d know this.

dangoulet1 wrote:

VMWare Fusion doesn’t run x86, neither does Parallels man. You left out the most important part on that.

So did you in your post complaining they didn’t run.

Docker doesn’t really work, it sort of works. If it doesn’t run x86 images then no, it really doesn’t work the same.

Wow, if they don’t run x86, it’s useless.

Again, news to them:

Docker Desktop for Apple silicon also supports multi-platform images, which allows you to build and run images for both x86 and ARM architectures without having to set up a complex cross-compilation development environment. Additionally, you can use docker buildx to seamlessly integrate multi-platform builds into your build pipeline, and use Docker Hub to identify and share repositories that provide multi-platform images.

Btw, I’m not really certain if you’ve been doing any dev lately, but many python libraries require native libraries, usually written in C. Things written in C aren’t always able to target other CPU’s. This goes for lots of development stuff, not sure what tools you’re using.

That is very, very wrong.

C compilers exist for virtually every architecture ever designed, either native, via cords-compilation or both.

I personally most frequently use gcc, and it supports most everything.

Have you ever done any ML? Most people do small bits locally on their laptops to build it and deploy to the cloud to scale it and do the training. How else would you do this? Run it in the cloud and pay per hour? Geeez.

I haven’t done ML, but neither have most developers not specifically doing ML.

How to handle local development? Have a local machine developers share? Most machines have a way of running via a virtual console, and most developer groups even in smaller companies have a lab hosting a handful of machines they share or a way to spin up virtual instances on a bigger machine of the proper architecture. For many developers their local machine only runs an editor and they ssh into the machine they test on.

Most developers including massive companies only target x86, that’s why we’re talking about this. Most companies do not target ARM, except for Android, iOS and a few things like rpi. If you’ve ever tried working on an rpi or anything like that you’d know this.

That is changing, fast. Windows runs on ARM. Web apps are largely processor agnostic. Again, most anything targeting macOS doesn’t care about the CPU. I get your specific use case does, but increasingly, many do not.

Even embedded systems like large storage appliances are starting to think of moving off Intel to ARM for performance increases and power savings.

I get it, your environment is x86-specific, but the world at large is less so every day.

You are not Apple’s target audience. Except for developers writing for Apple products, no developer is Apple’s target audience.

Apple targets Consumers that DO NOT work in the computer industry.

All their marketing and advertising is aimed at Consumers, and the professionals they do target, are the video, photo and audio segments.

The one time they spend any money talking about developers, is WWDC, and even then it is about developing software for Apple products.

They do not care if anyone uses Macs to develop for other platforms, because that market segment does not earn them much money.

If you can use a Mac to develop for another platform, great, Apple will sell you its products. If not, you deed to look for another way to do your job. Maybe get an intel box with Linux or Windows and Ssh, vnc or rdc into the box to test your code.

As those of us using Macs to write software for other platforms (me included), Apple is not going to take our needs into consideration, and will not cater to us. We just do not earn them enough money for them to care.

Unfortunately you can’t just read a companies website trusting what they say is true. Many of the articles I’ve found on docker and x86 has a horrible experience of things running real slow or crashing a lot. Using the ARM equivalent doesn’t cause this, if there’s an ARM equivalent

gcc, our best friend will target your app to a specific architecture of your choosing, if and only if you don’t use any libraries that only target one, such as x86. Back to python, have a look at things like numpy, pillow and you’ll see these things do not work or require lots of effort to get them working properly.

My use case to develop software that runs on servers for SaaS products only targets x86 as why would I attempt to move all of these things over just to use a new mbp.

Your arguments aren’t really helpful.

People need to understand the gotchas when upgrading. I don’t believe there should be gotchas but there are plenty real world examples where this isn’t going to work or performance will be degraded.

Thank you, you’re right.

Now, it would be helpful if Apple mentioned some of what you said.

Most of the developers I work with prefer macOS and MacBook Pro’s, I’m a huge fan and I don’t like losing capabilities.

That's why I am still on a 2015 MacBook Pro running MacOS Catalina10.15.7. 2,8 GHz quad core i7, with HDMI, USB-A, ethernet through a Thunderbolt 2 adapter, SD Card Reader, external Super Drive.

A month ago I placed Ubuntu 20.04 LTS on the second newer 1TB SSD, placed it in the DMZ, and have the makings of a home server.

Have an older Toshiba laptop running Debian 11 with LXCE desktop, with everything now working.

Just gave my wife's niece my 2017 MacBook Air i7 8GB RAM with 500GB SSD for her birthday and college in the fall.

Transferred all my files from iCloud to pCloud.

New Proton email address.

Still have and iPhone and iPad but looking at Linux phones for the future.

My exit plan, to easier programming and better privacy, is set.

I'll miss Textmate and rmate, but there is always Sublime Text and rsub.

[Edited by Moderator]

juula wrote:

I guess I just threw 3000 dollars out of the window. Nice.

This is what you can expect if you don't check the computer specifications before purchasing. Did you not confirm that the computer would meet your computing requirements before purchasing?

Maybe you can return it for a refund.

Let's not go into nostalgia mode and believe System 6 wasn't glacial compared to the speed of even a base Intel Mac Mini.

I still have a PowerMac G4 I fire up from time to time and I can't believe how slow it is compared to modern hardware.

Ahmedalaa28 wrote:

Has anyone tried or had any success running Primavera P6 using parallels on M1 Mac?

Thanks,

Primavera P6 requires an Intel CPU. Unless Oracle releases an ARM64 version it won't run on an M1 Mac.

I can t run VirtualBox on my Mac air its an error with 64 bit architecture