←back to thread

M4 Macs can't virtualise older macOS

(eclecticlight.co)
176 points Brajeshwar | 7 comments | 16 Nov 24 16:12 UTC | HN request time: 0.613s | source | bottom
Show context
doomlaser ◴[16 Nov 24 16:38 UTC] No.42157271[source]▶
Come on, Apple. What are you doing? I was thinking just the other day that Apple should virtualize older iPhones within the latest iPhone system software, so you could seamlessly open old apps and games (32-bit, anyone?) in their own containerized environments. I can't think why they haven't added this feature for any reason other than money grubbing.

You could even customize the containers to be completely closed off from the rest of the iPhone—no contacts, no Internet access (or high security Internet access), etc.

Come on, Apple. Do something good for once. Oh and bring back the headphone jack.

-Mark

replies(9): >>42157308 #>>42157317 #>>42157329 #>>42157337 #>>42157360 #>>42157361 #>>42157383 #>>42157388 #>>42157560 #
jsheard ◴[16 Nov 24 16:51 UTC] No.42157360[source]▶
For better or worse it's never been Apples MO to keep software working forever, that's Microsoft's schtick. PPC OSX software is gone, x86-32 OSX software is gone even on hardware that could still run it natively, AArch32 iOS software is gone, and if history is any indication it's only a matter of time before x86-64 OSX software is gone too.
replies(7): >>42157430 #>>42157509 #>>42157547 #>>42157562 #>>42157653 #>>42158015 #>>42160196 #
TaylorAlexander ◴[16 Nov 24 17:15 UTC] No.42157509[source]▶
One time I had to run a very old version of Eagle CAD on Linux and it turned out that even tho I had a native Linux version, it was easier to run the windows version in wine! I guess stable interfaces have their advantages.
replies(3): >>42157639 #>>42157778 #>>42158952 #
1. IshKebab ◴[16 Nov 24 17:35 UTC] No.42157639[source]▶
Linux (the ecosystem; not necessarily the kernel) is actively hostile to binary software.
replies(2): >>42158050 #>>42165348 #
2. nullpoint420 ◴[16 Nov 24 18:24 UTC] No.42158050[source]▶
It baffles me as to why. I think it’s hilarious how Linus is so careful to not break user space (for good reason) and all the user space libraries break every week.
replies(2): >>42158198 #>>42159028 #
3. Daishiman ◴[16 Nov 24 18:40 UTC] No.42158198[source]▶
Because every distro runs it’s compilers with a variety of flags and safety features and library versions and ABI quirks that make supporting stable ABIs a pain in the butt.
4. 6SixTy ◴[16 Nov 24 20:27 UTC] No.42159028[source]▶
Distribution maintainers pretty much do whatever they want with the OS level ABI. That on top of whatever those user space libraries want to do anyways makes native application ABI stability basically impossible.
replies(1): >>42165657 #
5. JackSlateur ◴[17 Nov 24 17:14 UTC] No.42165348[source]▶
Of course

Source software is the way to go (compiled specifically for one version of thé targeted OS, you sont have many issue)

Distribution opaque binaries are indeed not the best way, even if you can do it easily with static linking

6. nullpoint420 ◴[17 Nov 24 17:58 UTC] No.42165657{3}[source]▶
Again, how do Windows and macOS (to an extent) solve this? It’s possible, just not incentivized. Show me the incentives and I’ll show you the outcomes.
replies(1): >>42166167 #
7. IshKebab ◴[17 Nov 24 19:04 UTC] No.42166167{4}[source]▶
I think the main thing is that it's common for apps to bundle their dependencies. The default for Linux is to use the system libraries for everything - not just glibc but also things like zlib, libpng, etc. As a result you have to go to significant extra effort to make a portable binary app, e.g. linking against musl.

That's one of the attractions of Go, and to a lesser extent Rust; it's way less work than C to get a portable binary.

I think 90% of the problems I've encountered are due to glibc. They could easily fix all of them by adding a GCC flag that would allow you to compile against old glibc versions.

They'll never do that though because they are ideologically opposed to it.