Linked by Thom Holwerda on Sat 3rd Feb 2018 14:15 UTC, submitted by Drumhellar
Mac OS X

When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall.

This is good. I would prefer other companies, too, take a more aggressive approach towards deprecating outdated technology in consumer technology.

Permalink for comment 653542
To read all comments associated with this story, please click here.
RE[7]: Comment by ssokolow
by fmaxwell on Mon 5th Feb 2018 20:33 UTC in reply to "RE[6]: Comment by ssokolow"
Member since:

Or, to stick with your analogy: a car stereo manufacturer choosing to support MP3 & WMA, but not OGG.

True. And not including code to debug and play .ogg, .au, .ape, .flac, .tta, and so on makes sense because each implementation is yet another place for bugs to creep in and more code to support.

And, unlike a computer, a car stereo head unit generally doesn't have issues with remotely exploitable security flaws exposing your valuable data and personal information, so my analogy is getting stretched thin.

I'm not sure if you knew this but MS actually does support Linux binaries on Windows 10

My fault for being sloppy. I was referring to GUI apps rather than command line, character-based. But good link.

Hypothetically users could provide their own 32bit libraries even if apple does not, however this could only work if apple did not take steps to block 32bit software from the application loader.

We could have 32 bit dynamically linked libraries, or DLLs, that app installations could place in system directories! No need to worry about namespace collisions or versioning, since we can trust the app developers to 'do the right thing.' I think we have a winner!

IMHO there is a more fundamental problem for users than 32bit versus 64bit, which is being dependent on proprietary software that cannot be updated/ported to new architectures in the first place.

My first personal computer (disk-based) was a CP/M-80 system. Although I had source for most of the software on it, I can't think of any that I've ported to my current system or even the systems in-between. To cite one example, I don't really need the source code to the programmer's text editor I use -- I just need a viable alternative on the platform on which I will be working.

I suspect that's the case for many people. If the elimination of 32 bit app support on MacOS means that they can't play the Donkey Kong knock-off that they bought from some kid in Latvia in 2007, I'm okay with that.

Reply Parent Score: 1