Hacker News Reader

Comment by _j0r5 | Hacker News Reader

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

View on HN

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.

You make a good point. It was kind of the breaking point for me when Apple killed 32-bit executables, because it meant even old steam stuff couldn't run.

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.)

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.

Linux (the ecosystem; not necessarily the kernel) is actively hostile to binary software.

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.

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.

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.

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.

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.

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

the community has been joking that win32 is the most stable Linux api

I have a half-joking, half-serious thought: has anyone written a desktop environment for Linux that uses the Win32 API? Since Win32 is much more stable than Qt and GTK, it would be easier to target that API. The side bonus is API compatibility with Windows.

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.

ReactOS comes to mind, although it's not Linux.

> has anyone written a desktop environment for Linux that uses the Win32 API?

No, but window managers who use Xt, Xaw or Motif are ok.

> 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?

In the Linux desktop world, there is no single entity in control over the entire software stack ranging from the kernel all the way up to the desktop environment. In a typical Linux distribution, you have the Linux kernel (run by Linus Torvalds), various command-line tools written by many different developers and managed by different projects (some of them are part of the GNU Project, but others aren't), some type of display system (this used to be solely X11, but Wayland is growing in popularity these days), one or more GUI toolkits (Qt, GTK, some custom ones), and a desktop environment (typically KDE or GNOME, but others exist). The goal of a Linux distribution is to take these disparate parts and present a coherent system to the user.

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.

Back when IDA Pro for Linux & macOS was finally released, they decided to make every OS a separate license purchase. The net result of this was that every single person I knew who used it just kept buying Windows licenses and using it under WINE when they wanted to use it on their other computers.

Interesting juxtaposition against yesterday's front page: Valve updates Half Life 2 for 25th Anniversary.

If the requirements are still accurate, it will run on XP with 512MB RAM.

Maintaining the build artifacts and pipelines and testing backward compatibility for a long-lived project like HL2 must be pretty difficult, I would think? That’s a great example and counterpoint.

In addition to this, Steam provides an option for developers to expose the older game versions to the players, which Valve themselves make an active use of. So if you have a specific old mod that’s not compatible with the new update, or don’t want to deal with the update in a middle of playthrough, you don’t have to upgrade

Yeah, that's just their MO. I think it's easier to run old windows games on a mac than to run old mac games.

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.

I think it's likely x86-64 support (via Rosetta) will continue for quite some time.

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.

Perhaps there will be an intermediate step where they drop support for x86-64 executables, but retain support for x86-64 virtualization. That would still let Apple slim down the macOS system frameworks to a single architecture like they did previously when they dropped the x86-32 frameworks.

There is no support for x86-64 virtualization on ARM Macs. Do you mean dropping support for Rosetta for macOS apps but keeping support for Rosetta for Linux VMs (which run ARM Linux kernels and use Rosetta to support x86 userspace software)?

Maybe I'm missing something but I run SQL Server in Docker under Windows WSL2 at near native speed.

What's the competitive advantage here?

I suppose allowing developers targeting x86_64 Linux to still use Macs and the power efficiency of ARM CPUs, since I don’t think (maybe wrong) that ARM Windows machines support emulation inside WSL.

But that’s more feature parity with x86 Windows machines, not an advantage.

How is feature parity not an advantage? If it were to be removed, the lack of it would be a disadvantage.

Using macos rather than windows.

Having tried both, I would in fact say that WSL is a huge advantage for Windows over the Mac in many cases. Sure, the Mac is a *Nix, but there are lots of small differences from Linux that cause issues. WSL runs very, very well.

It's definitely for the worse that they've gone so far in that direction.

32bit ARM and aarch64 are wildly different instruction sets. 32bit ARM may as well be x86 or MIPS as far as running it on aarch64 hardware, it is going to require just about the same level of emulation(memory models may be similar which would help, but that's about it).

Unlike x86/64, the 32bit silicon is entirely gone in most aarch64.

I wonder why Intel and AMD still keep the 32 bit and even 16 bit parts. Are there people still running many legacy apps?

Yes

Intel has proposed dropping 32-bit and 16-bit support in the future.

https://www.intel.com/content/www/us/en/developer/articles/t...

The proposal doesn’t remove 32-bit user land or (I think) virtualization.

X86S allows 32-bit ring3 (userland) but even VMs are stuck in long mode and only support 32-bit code for userland. Booting a VM for a 64-bit OS that has a legacy bootloader with 16-bit or 32-bit code would require software emulation of that code.

As a consumer, yes. Old steam games are a big deal.

In business... not where I work, but I hear stories of shops that still have lots of old 32-bit COM stuff, etc.

32-bit applications are still pretty ubiquitous, including Office add-ins, and there is no particular benefit on x86 in removing support for 32-bit on the application side.

On windows, a lot of installers are 32-bit even if the application they're installing is 64-bit so that they can fail gracefully on 32-bit OSes.

Why would you care that the installer fails gracefully?

It's helpful for the users

The OS already throws a specific error message, and it is the OS that should be responsible for this.

This gives you no opportunity for a customized product-specific upgrade UI!

Choosing to install the 32-bit version could also be an option I suppose.

>32bit ARM and aarch64 are wildly different instruction sets

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.

Apple does a lot of good stuff, But remember that their whole business model is selling hardware. They have no financial interest in making it easy to continue to use old phones.

For some value of 'old' perhaps.

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.

Or any interest in reducing the incentives to buy their $200 Bluetooth headphones.

Old phones no, but old apps yes. If a developer has abandoned an app and hasn't been investing in the update treadmill, but end users still care about it, that can make people feel negatively about Apple.

> Old phones no, but old apps yes. If a developer has abandoned an app and hasn't been investing in the update treadmill, but end users still care about it, that can make people feel negatively about Apple.

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 know it's not the Apple approach, I'm just pointing out an interpretation that it isn't particularly focused on end user needs in this area.

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.

They have to maintain a balance that still incentivizes current purchases. Otherwise it’ll be a constantly trend of “don’t buy now, support might not last.”

This isn't as true as it used to be, now that Apple is getting increased revenue from subscriptions. If your old iPhone continues to work well, then Apple has a better chance of selling you Apple Music, Apple TV, etc. etc.

In this case, they only broke their newest hardware.

> 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

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.

Speaking of headphone adapters. It’s crazy to me that something like an iPod released in 2005 will output better audio when playing a lossless file than the most state of the art $2,000 iPhone with Apple’s most state of the art $549 headphones in 2024.

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.

> remarkable thing is that 90% of listeners don’t seem to notice

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.)

Of course to make this strawman argument you have to ignore the previous comment that says you can do wired connections just over a different port type.

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?

And they’re listening on AirPods or whatever stuck on their ear. I have AirPods 2 Pro and sure, they sound nice. Less sweaty on the treadmill. But even a $100 DJ headset from a $200 streamer blows it away.

That’s a bit apples to oranges because you’re comparing different form factors completely.

Form has a huge impact on acoustic properties and comfort.

You’d want to compare them against IEMs.

>I have AirPods 2 Pro and sure, they sound nice. Less sweaty on the treadmill. But even a $100 DJ headset from a $200 streamer blows it away.

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.

Sure they are quite good. My DJ headphones are Sennheiser HD25s (so $125). Night and day difference. The bass is completely different.

Yeah.. Those aren't as good or as accurate as the Airpods Pro 2. They are very bass heavy and muddle mids and highs where the Airpods Pro 2 are much more neutral in sound signature.

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.

Ha ha. Bollocks. I mean they are good for little things you stick in your ears, but ha ha.

Believe what you want, but I dare you to state your opinion in r/headphones and see how that goes for you.

I mean, if you need the backup, you do that and I’ll get popcorn. I’ve never seen anything on Reddit get agreement. Even r/FuckTedFaro had someone arguing he was just misunderstood.

What streaming service even does 128kb/s? Youtube is the only one that comes to mind and that's for free usage only. Paid accounts get 256kbit AAC

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

Tidal, SoundCloud, Deezer, and Bandcamp offer lossless support.

>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.

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.

iOS dropped 32-bit support because the CPU itself no longer supports AArch32. Virtualization won’t help.

I don't think almost anyone actually want a headphone jack anymore. Just the consumer reality in 2024. I do obviously, but it's clearly too rare for them to bother with.

Yes people seem happy to buy not only new phones every couple of years but new accessory devices as well. I don't understand it but it's quite apparent.

I find it very practical with small Bluetooth earbuds, but I agree on the consumption aspect of it. I really don’t like that I can’t change the batteries in my AirPods. I would even be semi-okay with having to hand in them to a technician for battery exchange, for a reasonable cost. But the current battery exchange for airpods is just another name for buying new earbuds. And the third party solutions that actually change the batteries cost about as much as new buds.

Why do you want a headphone jack? Not a rhetorical question, just genuine interest. Is it about audio quality, avoiding batteries or something else?

I would find it so cumbersome to use a cable on a handheld device nowdays. But different things for different people! :)

Not who you are replying to but my $30 wired Apple earbuds (came with my 6S) have outlived all of my co-workers half dozen $160 AirPods. That’s reason enough for a lot of people.

For $8.99 you can buy a high quality USB-C (or lightning) DAC with a 3.5mm output directly from Apple.

It's tiny and lightweight. I keep one in the back of my headphone case.

There are never enough USB-C ports.

Yeah I agree, that is a very valid reason by itself.

You can buy Apples wired earbuds with the lightning connector for $18. Or the lightning to 3.5mm adapter (that’s what I have because I also still have my decade old original earbuds).

I don't daily drive my phone for commuting anymore, but the trade-offs aren't exactly new: - battery frustrations - cost of a dozen cheap but good quality headphones vs a wireless equivalent - easier to lose wireless headsets when you put them down somewhere (wired too, but way cheaper so less big deal) - audio quality? Who knows

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.

My wired Shure in ear monitors have much better sound quality, and battery management on AirPods is pretty annoying. Even when they’re not running out mid-trip, it’s just unnecessary mental overhead to keep another thing charged.

For me it’s because

- 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

Easier to store vs bulky charging case and charger and charger cable etc. The wired solution is more portable, believe it or not.

Simpler interface to debug and fix than bluetooth.

Someone would have to maintain all the old OS versions that would be required to run those old apps, and keep those OS versions reasonably secure. That sounds like a maintenance nightmare to me.

No, the old versions would not have access to anything else, so the only thing that needs to change is the part running the container. Present one folder as the whole disk drive to the old. Send touch screen input to the old. That's about it really.

If you're trying to play older 32-bit games, chances are you'd like to have sound, too.

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?

yeah it's much better to lose access to games you've paid for. this is why I stopped buying apps on Android - if it's not open source, I'm not interested. I also don't buy DRM stuff unless I know I can remove the lock.

It's probably worth finding out whether this is a bug or an intentional decision before making assumptions.

For Apple Hanlon's razor rarely holds, they're both too competent and anticonsumer for this sort of thing to not be intentional malice in an attempt to sell more stuff. Maybe not, but very unlikely and even if it's a bug they'll probably call it a feature and keep it.

Reply on news.ycombinator.com