M4 Macs can't virtualise older macOS
eclecticlight.co
eclecticlight.co
In my opinion, Rosetta should be more heavily gated* to push everyone from Adobe to Steam to build for aarch64. Countless "Apple Silicon native" claiming tools require Rosetta under the hood for dependencies or even (bless their hearts) only their installer.
* Like right-click to open packages or install not-from app store, except Rosetta dialog should note that once it's installed any other old software not made for this system will run without warning. Turns out avoiding Rosetta is a great way to ensure not just apps but your CLI tools are all up to date... Alternatively, make Rosetta sandboxed with apps, and/or let it be turned off again more reasonably than the safe-mode surgery required now.
Honestly I see game developers simply abandoning MacOS (more than they already have) if they need to do more work on their back catalogues. Nobody at Adobe cares if CS3 doesn't run on the latest MacOS, it's no longer a revenue source for them. EA would care a lot more if all their games older than 4 years needed work to run on MacOS, there's a lot more long tail revenue in games (but a lot of that is over aggregated back catalogues where the revenue per title is pretty low even if they sum up to a significant amount) than there is in the more typical B2C cloud SaaS attached apps that the App Store model is designed to serve.
Use Windows for games.
At the time, there was a decent number of non-gaming cross-platform applications that relied on OpenGL for rendering. OpenGL wasn't perfect (especially compared to DirectX 9) but it was a good-enough solution for simpler apps and games that wanted the write-once-run-anywhere treatment.
> If you’re already writing a Mac-specific backend, why not just write directly for Metal instead of OpenGL?
Because a lot of people don't write Mac specific backends in the first place. Unless the app was designed to be Mac native from the start (a rarity in the professional world), there is very little impetus to rewrite everything to work with Metal and/or AArch64 targets. OpenGL suggested a future world where this would be unneccesary, and people liked it. With Metal as the only option now, a lot of people feel like Apple slammed the door on people that wanted to write cross-platform apps supporting Mac.
> Or, at the least, write for Vulkan and use a translation layer like MoltenVK?
MoltenVK is too slow for games (compared to DXVK it is an utter slouch) so most people don't even bother. There are a few apps that you can run in it, but for the most part it is a toy that rightfully isn't relied upon to deliver industry-standard experiences.
I have seen a huge downtick in games with Mac releases too… even for stuff where it seems like it would be possible with an extra platform export.
Apple seems to care about gaming for about 15 minutes every year, and one day they will figure out it can work on their stuff if they’re willing to accept that their platform will be nobody’s priority.
But what about MoltenVK?
I think it's more plausible that Valve decides to make a Proton for Mac using the D3D to Metal translation layer from Apple's Game Porting Toolkit—but that would be going against Apple's intended purpose for the toolkit.
At least with USB-C Apple "donated" their designs.
What do you mean? I've always thought that it was designed jointly by the same standards committee as the previous iterations. The first USB-C device I know about and have used was the Nexus 6P. This was early enough in the standard's life that no one had any USB-C cables (or had any idea that it's a thing) so I had to carry my own one at all times in case I wanted to charge my phone. Apple started putting USB-C ports into MacBooks a year or so later, iirc.
This was just stuff I heard though. Vaguely, many years ago.
It's ok for older games but those would be very unlikely to receive a native port anyway, and for anything new GPT just sucks...
Not happening. The other commenters are right - many developers are content letting their apps get abandoned if the choice is between Universal binary or x86. A lot of software, particularly legacy software and older games, don't even have the opportunity to build for aarch64. The moment Apple put an expiration date on Rosetta they were confronting you with the inevitability that your software would one day die. There is no convincing some people - for christsake, four generations of Apple Silicon came and went and Steam is fine leaving their client x86 only. They know all their MacOS users are playing through Game Porting Toolkit's Windows version anyways.
From where you're standing, it must feel like an 18 carrot run of bad luck. Truth is, the game was rigged from the start.
13.4 was released on May 18, 2023. That's actually not very far into the past.
Anyway, what would be the most common use cases for this? And how common are those?
Case in point: I built a macOS app that implements Google's Nearby/Quick Share (an AirDrop-style file sharing thing on Android). Multiple people tried running it on Catalina and were disappointed that it wanted a newer OS. So I did end up backporting it to Catalina.
Citation? I use Monterey at work and every app I need works on it still.
https://reverseengineering.stackexchange.com/questions/6043/...
I've first tried recompiling the Keychain app, but it had too many dependencies that were not trivial to build, so, using an older Mac, in that case, was the easiest way to get the private key from my own keychain.
Macs are the best at virtualizing macs.(look up hackintosh to see how many hoops must be jumped through on non mac hardware)
so i wonder whether apple will consider this a bug...
but when the bug report is regarding supporting a software version which they don't support themselves anymore, personally i don't think they will give it any priority
Then it turned out Rosetta does not support that, so those docker images can no longer run on developers' mac laptops, so we have to revert it back. This is why we can't have nice things (we don't use any arm server so we never bothered to build multi-platform docker image).
Were those supposed to have been included? What of those is not emulated by Rosetta?
I'm struggling to understand the chain of following how this results in us not having nice things?
Iiuc, paraphrasing, sounds like go made an assumption about user requirements, that turned out to not be true when the arm macs came out? Wouldn't the arm mac users of go prefer to have docker images that dont need to be emulated anyhow?
amd64 v3 are instructions included in CPUs starting from 2013, so basically any modern amd64 cpu supports all of them. As mentioned there on the Wikipedia page, QEMU 7.2 also implemented all of them. Those are more efficient instructions, thus "free performance boost".
But Rosetta doesn't. Which instruction(s) it doesn't implement doesn't really matter (I can't remember either). What matters is that when it runs an instruction it doesn't implement, it will throw an illegal instruction error and the code hard crashes.
So because of Rosetta, we can't build code with amd64 v3 enabled, and cannot have free performance boost (nice things).
You could still build programs for 10.3 -- but you needed the latest version of Xcode and the compilers for that, which Apple only shipped for 10.4 and up. So you had to set Xcode for 10.3 compatibility mode and then you could build your app.
If you develop for Apple's platform, you need to be running the latest version, period, end of statement. If you aren't, there's no telling what may break.
My guess is that they do this because their development processes only assure that the macOS version shipped with the hardware works on that hardware. And the virtualization layer is really thin.
They see no reason to spend the extra QA time, but rather have everyone upgrade to the latest macOS version their hw support.
How do you know? Maybe it's in the mentioned bug report 15774587; I tried to look at it, and was sure I could log into Radar at some point, but now I can't seem to dig up any valid login.
Are you sure? I'm pretty sure that I have in the past, and even that it used to be standard practice when discussing an ignored Radar report to ask other sufferers to go to the bug and do whatever the "me too" action for Radar is (I don't remember). Certainly there is a login at https://radar.apple.com, although that doesn't prove that it's meant for outsiders.
to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
Also, if you want to cross-compile in Linux instead of run a container: https://github.com/shepherdjerred/macos-cross-compiler
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
This might not have been viable 25 years ago when KDE and GNOME were in their infancy, but WINE has come a very long way since then. Standardizing on Win32 would eliminate the churn of dealing with Qt and GTK major version revisions.
What makes it so hard to write a GUI toolkit that is long-term (say for 25 years) backwards compatible. If Microsoft is capable of doing this, why can't open-source developers?
The problem, though, is that because the Linux desktop is made up of disparate parts from separate teams that have separate, often competing visions for their roles in the Linux ecosystem, often major changes are made with little regard to how they affect the system as a whole. This is the essence of the lack of control over the entire software stack. Thus, the developers of X11/Wayland, Qt, GTK, and other infrastructure can make breaking changes, and application developers relying on those subsystems have to either adapt or lobby for forks. Thus, the churn.
By comparison, Microsoft is in full control over Windows, and Apple is in full control over macOS. Even the BSDs are in full control over their base systems (for example, OpenBSD isn't just a kernel; the OpenBSD team also has control over the command-line tools that make up the base system), though I'm not aware of any BSD (besides macOS) that is in full control over GUI environments. It's not to say there is no churn in these environments; indeed, macOS does not prioritize backwards compatibility like Windows does and thus there's some churn macOS developers need to deal with in order to keep up with the latest releases. But there seems to be a lot of churn at the GUI level in the Linux desktop ecosystem.
No, but window managers who use Xt, Xaw or Motif are ok.
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.
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
But that's a casual consumer viewpoint. It's valid to buy them if they solve your problems in the here-and-now. (I used one for a year at work and it was a bad experience, but a lot of that was having x86 libraries I had to use, so... Bad choice for here-and-now.)
If the requirements are still accurate, it will run on XP with 512MB RAM.
Rosetta is giving Apple a competitive advantage by being able to run x86-64 binaries in VMs (Linux or maybe even Windows) at near-native speeds. This enables doing cool things like running MS SQL Server in a Docker container - which enables developing on a full local .NET stack on a Mac.
What's the competitive advantage here?
But that’s more feature parity with x86 Windows machines, not an advantage.
And architecture aside, at one point I had to install an old version of iWork (I thin it was '09) to update a file so the latest iWork could read it. They had code on hand that could read those older files, but decided not to integrate it. They don't prioritize backwards compatibility.
Unlike x86/64, the 32bit silicon is entirely gone in most aarch64.
In business... not where I work, but I hear stories of shops that still have lots of old 32-bit COM stuff, etc.
https://www.intel.com/content/www/us/en/developer/articles/t...
Choosing to install the 32-bit version could also be an option I suppose.
Maybe for the CPU implementation, but having written a lot of ARM2 assembly, the disassembly of Aarch64 is far more readable than x86_64 to me.
In terms of length of official support, and aftermarket value, Apple is at the top of the game. Those strike me as the most important metrics here.
And while you might think that once official support is over, that's the end of the story, this is far from true. Those phones end up in developing markets, where there's an entire cottage industry dedicated to keeping them going. Jailbreaking is getting harder, so that might stop being an option eventually, but so far it's viable, and that's what happens.
On the other hand, it is well within the standard Apple approach to say "here's how we want people to use our hardware. We are well aware that this is not consistent with how some potential and past users want to use the hardware, but we are comfortable with losing those customers if they will not adapt to the new set-up."
I feel like it's mostly an attitude about where to focus engineering resources, which is very "inside baseball", but people have post hoc justifications that it's really what end users want anyway.
What is the practical, broad use case for this? (And can't you virtualize older iOS version on a Mac?)
> bring back the headphone jack
The article is about Macs. If you want a headphone jack, get a 3.5mm:USB-C converter.
The remarkable thing is that 90% of listeners don’t seem to notice.
Their reference point is a lossy 128kb/s file from a streaming service double transcoded over bluetooth so that must be what music sounds like. Who would have thought technology would progress backwards.
Spotify uses OGG Vorbis codec and streams at 160 kbps at standard bitrate and 320 kbps at high quality
In addition to AAC, the entire Apple Music catalog is now also encoded using ALAC in resolutions ranging from 16-bit/44.1 kHz (CD Quality) up to 24-bit/192 kHz
Amazon Prime Music at 256 kbps
That's about 99% of the streaming music market people actually use
That's not a remarkable thing, it's the reason.
(And out of the remaining 10%, a good fraction may notice but prefer the new convenience. Those who remain can find the difference between most and all, or go corded.)
The only major streaming service that doesn't do lossless is Spotify.
Further just about no one is going to be able to tell the 256kb/s AAC that the iPhone sends to headphones across bluetooth from the lossless audio file.
Also, portable headphones have progressed leaps and bound since 2005 and they'll all basically sound better playing over bluetooth than the portable headphones that were out in 2005.
Let’s also ignore any understanding of the DAC quality between older iPods and newer iPhones, where even the dongle Apple sell are considered a high quality DAC.
Let’s also ignore any advances in Codecs in that time, or advances in audio hardware itself.
Let’s also ignore that most iPod users would have bought low quality MP3s or medium quality AACs at the time. Not to mention that most customers use streaming today so wouldn’t even be able to take advantage of the higher quality codecs today.
Finally let’s ignore customer preferences and what niche set of customers would have bought high end enough audio equipment and have the hearing to appreciate and also not want wires today to even fall into your narrow band description.
Who would have thought that if you ignore all aspects that are inconvenient to an argument that you could make any argument you want?
Form has a huge impact on acoustic properties and comfort.
You’d want to compare them against IEMs.
Doubt. Doubt. Doubt. Airpods Pro 2 are actually decent headphones worth the amount of money they are. They are most definitely better than $100 DJ headsets.
Now if you like it that way, great! But that doesn't mean the headphones are objectively better than the Airpods Pro 2. It just means you like those ones better.
I would find it so cumbersome to use a cable on a handheld device nowdays. But different things for different people! :)
It's tiny and lightweight. I keep one in the back of my headphone case.
- I already have high quality earphones, same set for many years
- they don’t require charging
- audio quality is great
- they’ll work on any device with a 3.5mm jack, no proprietary lock-ins
- I have never lost a set of earphones and if I did replacement wouldn’t break the bank
For people that demand noise cancelling, you need an active power source, but I personally hate noise cancellation and always turn them off. Maybe valuable in a plane with lots of engine noise.
Who is going to develop the virtual audio device drivers (for each OS) that are required to virtualize sound? Who is going to run all the tests needed to make sure that the guest-side 32-bit iOS 7 (and 8, 9, 10) drivers are going to play well with the host-side driver?
Who is going to accept the risk that someone takes over the guest VM after exploiting one of the well-known and unpatched kernel-level vulnerabilities present in iOS 10? What happens if malware finds and exploits a bug in that new audio driver virtualization pipeline so it can escape the VM and then compromise the host iOS?