When will I stop receiving onscreen messages telling me 3rd Party Software installed on my Mac won’t be compatible with a future version of Mac OS and to contact the developer? It’s not the customers job to remind the developer to update their software to be compatible.
Never. Apple will do this to you again and again.
It would be trivial for Apple to support 68k software in System 11. It would be trivial to support 68k, PowerPC, 32-bit Intel, and ARM software at the same time. The only programs that truly couldn't handle it would be things like disk utilities.
But in the next few years you can expect that Apple will again f you over when they intentionally break 64-bit Intel software, just as they did for every previous architecture.
I'm done. No M1 for me. Xubuntu is looking really nice these days, and it'll run on standard x86 hardware for the foreseeable future. Hardware that also doesn't make me get new dongles for every new port that comes along because it still includes the old ports. And with just a tiny hack, I can run x86 Mac software in VMware Workstation. I can even get it to run Apple's last really good version of Mac OS X, 10.6.
For now, I'm telling my clients to buy Intel Macs while they still can, avoid the M1 garbage like the plague it is. That'll get them at least 5 years of reasonable functionality, then we can move on to what's next, which at this point isn't likely to be Apple.
Microsoft OSs suck. But did you know you can still run some 16-bit Windoze 1 software on current Windoze 10 20H2? You can.
Intentionally breaking compatibility is insane.
That backwards compatibility comes at a cost - a huge increasingly complex OS that has numerous issues because developers took shortcuts that make going to the next level. Look at the horrid performance of Microsoft's x86 emulator vs Apple's translator. Like it or not x86 has likely reached the end of the road of how it can be improved without getting into the 'doubles as a space heater' jokes again. Nearly everybody (even AMD) has seen that ARM is the future be it Opterron (and the M1 competitor AMD is rumored to be working on) or the M1. Hanging on the dying past is why Sears, Blockbuster, and dozens of other business are either walking undead are all but dead.
I can run a World Builder, a 32-bit 68000 assembly program from 1986 via emulation on a modern Mac. If you want to run old software there will be a market for emulators. If their isn't a market not enough people really care about act old software...otherwise there would be emulators QED.
It’s interesting to me while DarkVader says Microsoft operating systems suck, Apple is f-ing over people by blowing away backwards compatibility.
The engineering tradeoff is there ain’t no such thing as a free lunch: for DarkVader he wants the backwards compatibility Windows is famous for, despite claiming the OS sucks, while saying Apple sucks for not having it. Well, here’s the thing: all that backwards compatibility is what causes the perception of it “sucking” as an OS as it absolutely has a HUGE amount of overhead in maintaining/fixing/updating/adding features for the OS, not to mention system performance. Backwards compatibility exists in Windows to a large degree because of something called shims, which accounts for various applications and groups of applications expecting the OS to behave in some particular internal-detail method that it no longer does: this is what shims are for. If applications only use APIs as formally documented, there’s lots of backwards compatibility with zero efforts.
Windows over time has had major changes as hardware capabilities have changed (SMP, multiple sockets, sound hardware, GPUs arriving, etc.) and natural performance characteristics of underlying hardware has changed assumptions that made sense in the past, but remember: Microsoft focuses on big enterprise customers, and they loathe rewriting applications that have no functional need to change, as that’s huge money: enterprises tend to be tied together with a lot of custom applications designed only for them, paid for only by them: Microsoft Office updates are cheap by comparison. New sets of APIs are created also when it’s figured out there are better ways of doing things.
Apple doesn’t care about backwards compatibility beyond a handful of years. They keep rewriting a lot of things and changing them out entirely, and any given software will usually work fine without major changes just as long as the support lifespan of any of their sold machines, which is fine for most non-enterprise consumers. This has a logical result in a lot less resource usage, and increases the chances of having cleaner code in the OS with far fewer odd special cases as well to account for third-party application software or device drivers (which, btw, Windows has a HUGE array of what’s supported compared to every other OS, especially MacOS for a mainstream OS).
Windows and MacOS are close to being mirror opposites of each other in how/why they are what they are: you don’t get a sleek minimal-resource-using OS with backwards compatibility, it can’t be done. You can’t get a sleek OS with maximal device driver support for the same reason.
For now, I'm telling my clients to buy Intel Macs while they still can, avoid the M1 garbage like the plague it is.
In some professions this could be considered malpractice.
I have a new Intel MacBook Air provided to me by my work. I got my mom an M1 MacBook Air.
Her M1 MacBook Air **crushes** mine in speed, battery life, fan noise (none versus lots), and temperature. Its absurd how much better it is. She tells me every couple days she can’t believe how great it is. And I have serious envy bc it’s improvements make it dramatically better than mine.
You have some serious sour grapes issues w Apple. Save your anger for Intel bc they’re stuck in the Stone Age. That’s the real problem. Even Intel investors are pissed at Intel. They’re down a path that peaked 10 years ago and seem utterly lost.
When will I stop receiving onscreen messages telling me 3rd Party Software installed on my Mac won’t be compatible with a future version of Mac OS and to contact the developer? It’s not the customers job to remind the developer to update their software to be compatible.
Never. Apple will do this to you again and again.
It would be trivial for Apple to support 68k software in System 11. It would be trivial to support 68k, PowerPC, 32-bit Intel, and ARM software at the same time. The only programs that truly couldn't handle it would be things like disk utilities.
But in the next few years you can expect that Apple will again f you over when they intentionally break 64-bit Intel software, just as they did for every previous architecture.
I'm done. No M1 for me. Xubuntu is looking really nice these days, and it'll run on standard x86 hardware for the foreseeable future. Hardware that also doesn't make me get new dongles for every new port that comes along because it still includes the old ports. And with just a tiny hack, I can run x86 Mac software in VMware Workstation. I can even get it to run Apple's last really good version of Mac OS X, 10.6.
For now, I'm telling my clients to buy Intel Macs while they still can, avoid the M1 garbage like the plague it is. That'll get them at least 5 years of reasonable functionality, then we can move on to what's next, which at this point isn't likely to be Apple.
Microsoft OSs suck. But did you know you can still run some 16-bit Windoze 1 software on current Windoze 10 20H2? You can.
Intentionally breaking compatibility is insane.
That backwards compatibility comes at a cost - a huge increasingly complex OS that has numerous issues because developers took shortcuts that make going to the next level. Look at the horrid performance of Microsoft's x86 emulator vs Apple's translator. Like it or not x86 has likely reached the end of the road of how it can be improved without getting into the 'doubles as a space heater' jokes again. Nearly everybody (even AMD) has seen that ARM is the future be it Opterron (and the M1 competitor AMD is rumored to be working on) or the M1. Hanging on the dying past is why Sears, Blockbuster, and dozens of other business are either walking undead are all but dead.
I can run a World Builder, a 32-bit 68000 assembly program from 1986 via emulation on a modern Mac. If you want to run old software there will be a market for emulators. If their isn't a market not enough people really care about act old software...otherwise there would be emulators QED.
It’s interesting to me while DarkVader says Microsoft operating systems suck, Apple is f-ing over people by blowing away backwards compatibility.
The engineering tradeoff is there ain’t no such thing as a free lunch: for DarkVader he wants the backwards compatibility Windows is famous for, despite claiming the OS sucks, while saying Apple sucks for not having it. Well, here’s the thing: all that backwards compatibility is what causes the perception of it “sucking” as an OS as it absolutely has a HUGE amount of overhead in maintaining/fixing/updating/adding features for the OS, not to mention system performance. Backwards compatibility exists in Windows to a large degree because of something called shims, which accounts for various applications and groups of applications expecting the OS to behave in some particular internal-detail method that it no longer does: this is what shims are for. If applications only use APIs as formally documented, there’s lots of backwards compatibility with zero efforts.
Windows over time has had major changes as hardware capabilities have changed (SMP, multiple sockets, sound hardware, GPUs arriving, etc.) and natural performance characteristics of underlying hardware has changed assumptions that made sense in the past, but remember: Microsoft focuses on big enterprise customers, and they loathe rewriting applications that have no functional need to change, as that’s huge money: enterprises tend to be tied together with a lot of custom applications designed only for them, paid for only by them: Microsoft Office updates are cheap by comparison. New sets of APIs are created also when it’s figured out there are better ways of doing things.
Apple doesn’t care about backwards compatibility beyond a handful of years. They keep rewriting a lot of things and changing them out entirely, and any given software will usually work fine without major changes just as long as the support lifespan of any of their sold machines, which is fine for most non-enterprise consumers. This has a logical result in a lot less resource usage, and increases the chances of having cleaner code in the OS with far fewer odd special cases as well to account for third-party application software or device drivers (which, btw, Windows has a HUGE array of what’s supported compared to every other OS, especially MacOS for a mainstream OS).
Windows and MacOS are close to being mirror opposites of each other in how/why they are what they are: you don’t get a sleek minimal-resource-using OS with backwards compatibility, it can’t be done. You can’t get a sleek OS with maximal device driver support for the same reason.
Backwards compatibility could in theory be offered in other formats than what we usually think it means.
For instance, in many cases I could setup a virtual machine that would run an operating system just as if it'd been a regular hardware computer; and then run my choice of operating system on top of that. So I could run most software from most eras.
So in theory Apple could allow backwards compatibility simply by running some sort of loader that analyses the app you're trying to run, and then downloads the correct (walled) environment for it (meaning virtualisation from the hardware and up). So none of the mess of every version of the OS having to "natively" handle every API and whatnot of every earlier version.
So you could in theory have a situation where you just click on anything, and at most the OS give you a warning about potential license fee, if it is a huge download, and whether or not your current hardware will be able to run the environment at 1x speed or not. It wouldn't matter if it'd be software for Windows, NES, Jaguar, Linux, Mac, iOS, or anything else.
However, that wouldn't allow much of an integration between those environments, nor between them and your host OS; and there would be a huge hit in perfomance (which wouldn't matter with older stuff, but might be crippling with more modern environments).
The point being that as this separates the environments you would have the benefit of a lean OS to develop with new features, at the same time as you can offer more complete (but different) style of backwards compatibility. So a new style of backwards compatibility might be reasonable to pursue for a business like Apple; because it could allow whole back catalogs of software to without any effort at all be sold in Apple's AppStore.
And… as far as the comment about Apple not caring about backwards compatibility beyond a handful of years… Well, I don't think I've ever gotten less than 5 years of running the latest and greatest on any Mac that I've bought; and I think I in two cases hit 9-10 years before the hardware had to be retired. That's actually really good, and great value.
When will I stop receiving onscreen messages telling me 3rd Party Software installed on my Mac won’t be compatible with a future version of Mac OS and to contact the developer? It’s not the customers job to remind the developer to update their software to be compatible.
Never. Apple will do this to you again and again.
It would be trivial for Apple to support 68k software in System 11. It would be trivial to support 68k, PowerPC, 32-bit Intel, and ARM software at the same time. The only programs that truly couldn't handle it would be things like disk utilities.
But in the next few years you can expect that Apple will again f you over when they intentionally break 64-bit Intel software, just as they did for every previous architecture.
I'm done. No M1 for me. Xubuntu is looking really nice these days, and it'll run on standard x86 hardware for the foreseeable future. Hardware that also doesn't make me get new dongles for every new port that comes along because it still includes the old ports. And with just a tiny hack, I can run x86 Mac software in VMware Workstation. I can even get it to run Apple's last really good version of Mac OS X, 10.6.
For now, I'm telling my clients to buy Intel Macs while they still can, avoid the M1 garbage like the plague it is. That'll get them at least 5 years of reasonable functionality, then we can move on to what's next, which at this point isn't likely to be Apple.
Microsoft OSs suck. But did you know you can still run some 16-bit Windoze 1 software on current Windoze 10 20H2? You can.
Intentionally breaking compatibility is insane.
That backwards compatibility comes at a cost - a huge increasingly complex OS that has numerous issues because developers took shortcuts that make going to the next level. Look at the horrid performance of Microsoft's x86 emulator vs Apple's translator. Like it or not x86 has likely reached the end of the road of how it can be improved without getting into the 'doubles as a space heater' jokes again. Nearly everybody (even AMD) has seen that ARM is the future be it Opterron (and the M1 competitor AMD is rumored to be working on) or the M1. Hanging on the dying past is why Sears, Blockbuster, and dozens of other business are either walking undead are all but dead.
I can run a World Builder, a 32-bit 68000 assembly program from 1986 via emulation on a modern Mac. If you want to run old software there will be a market for emulators. If their isn't a market not enough people really care about act old software...otherwise there would be emulators QED.
It’s interesting to me while DarkVader says Microsoft operating systems suck, Apple is f-ing over people by blowing away backwards compatibility.
The engineering tradeoff is there ain’t no such thing as a free lunch: for DarkVader he wants the backwards compatibility Windows is famous for, despite claiming the OS sucks, while saying Apple sucks for not having it. Well, here’s the thing: all that backwards compatibility is what causes the perception of it “sucking” as an OS as it absolutely has a HUGE amount of overhead in maintaining/fixing/updating/adding features for the OS, not to mention system performance. Backwards compatibility exists in Windows to a large degree because of something called shims, which accounts for various applications and groups of applications expecting the OS to behave in some particular internal-detail method that it no longer does: this is what shims are for. If applications only use APIs as formally documented, there’s lots of backwards compatibility with zero efforts.
Windows over time has had major changes as hardware capabilities have changed (SMP, multiple sockets, sound hardware, GPUs arriving, etc.) and natural performance characteristics of underlying hardware has changed assumptions that made sense in the past, but remember: Microsoft focuses on big enterprise customers, and they loathe rewriting applications that have no functional need to change, as that’s huge money: enterprises tend to be tied together with a lot of custom applications designed only for them, paid for only by them: Microsoft Office updates are cheap by comparison. New sets of APIs are created also when it’s figured out there are better ways of doing things.
Apple doesn’t care about backwards compatibility beyond a handful of years. They keep rewriting a lot of things and changing them out entirely, and any given software will usually work fine without major changes just as long as the support lifespan of any of their sold machines, which is fine for most non-enterprise consumers. This has a logical result in a lot less resource usage, and increases the chances of having cleaner code in the OS with far fewer odd special cases as well to account for third-party application software or device drivers (which, btw, Windows has a HUGE array of what’s supported compared to every other OS, especially MacOS for a mainstream OS).
Windows and MacOS are close to being mirror opposites of each other in how/why they are what they are: you don’t get a sleek minimal-resource-using OS with backwards compatibility, it can’t be done. You can’t get a sleek OS with maximal device driver support for the same reason.
Put me firmly in the group who believes in backwards compatibility.
If you ship an OS with bugs - fix them.
No major release should ever be the solution for bugs in a previous major release.
If you are eliminating features, be very, very upfront about it.
Shipping incremental updates and then cutting off further fixes in a rush to the next major release just one year later creates a culture of chasing the next release. When it arrives, users are nagged senseless to upgrade to it and a swathe of new bugs.
First advice is always 'update to the latest release'. That is a hoop you absolutely must jump through most of the time and is in itself a cause of problems unless your hardware/software just happens to be relatively modern. Often you get zero warning of the (often hellish) problems that result from jumping through that hoop. But you are just told to jump anyway.
I've been there in a classic situation: old MBP, new iPhone, iTunes.
Even going to a retail Apple Store, explaining my concerns (borne out of years of experience in Apple's failed compatibility problems) didn't stop me from getting snagged.
The guy at the front end just wants the sale. Any resulting problems will be dealt with after the sale. No amount of pushing will change anything. You get smarmy smiles and told there shouldn't be anything to worry about.
Then the problems begin. This iPhone needs a newer version of iTunes. Download and install (that itself is fraught with issues - every iTunes update I've ever done has sent something to hell!). Open iTunes, connect the phone. This now needs a newer version of the OS.
A newer version which will break applications that have nothing to do with the new iPhone or iTunes. But Apple wants you on the newest x.0 release (itself full of bugs) so I say, nooooo! I'll go for an older, more stable release which is nowhere to be found (easily) at Apple because they are hellbent on you going to the latest version, no matter what!
To the point of stealth updating your machine unless you read everything very clearly.
Can you see a pattern forming here? Yearly major updates, changes everywhere, applications that get lobotomised (I'm looking at you Disk Utility) applications that fall apart under their own weight but are left to wreak havoc on users. iTunes should have been broken up looooong before it was. It was Apple that turned it into a monster.
The list is endless.
Resources? Overheads? Complexities?
Apple has the resources available. So many cash reserves it doesn't even know what to do with them!
I had told the Apple Store employee about my concerns. They were shoved aside and I was left with a erased iPhone (trade in) and a backup on a perfectly valid Mac that the iPhone couldn't talk to and three smiley Apple people charged with setting up the phones, all scratching their heads. Solution: make an appointment with tech support and come back another day. 120km round trip. Nope. I even tried to contact Apple via web because the information I needed wasn't visible anywhere. To do that you needed the serial number of the machine, then you get shoved into a paywall for a tech related consultation that requires a payment. I was looking for basic compatibility information. Nothing more.
The story is longer and more complex than I'm relating here - and I fixed it myself in a more traditional 'old school' way but is a perfect example of what I'm saying and the massive irony of the situation is that if I were in exactly the same situation but on Windows, I wouldn't have run into any of the problems because of backwards compatibility.
Siri should be able to eliminate ALL the possible conflicts the user might need to know of. AI is perfect for this stuff. Why support issues of this kind aren't available through Siri is a mystery.
I did not need for a smug Apple employee to tell me I shouldn't run into issues. A machine could have put the brakes on the whole process but that would have stopped the sale in its tracks but that, of course is sacred. After the sale it is up to the back end guys to resolve problems. The same guys who many of which have never seen a 'vintage' mac in their lives.
It was always crazy that Apple didn't let you backup your iDevice 'universally'. Throwing up messages informing users that this or that will or won't be backed up depending on which type of backup (local/remote) you choose is not user friendly.
File format support? This should be baked in law. As we are now firmly entrenched in a digital age no one should have to lose access to their documents due to format issues. Saying a format is 20 years old and the app is long gone is NOT a valid answer especially when it's an old Apple application that came with the system. The problem here though needs a legislative focus.
Slowing down release schedules would greatly improve compatibility and the bugginess of the system and related applications. Better planning would also go a long way. The migration of applications like Pages to 'apps' was a disaster from a user perspective. In fact, Pages and its cohorts is a classic example of Apple releasing a major application and letting it rot until the next major OS update suddenly sees it get some love. In between bugfixes are a lot less than they should be.
The original Rosetta was dropped way earlier than it should have been and is one of the reasons I shied away from later updates.
When will I stop receiving onscreen messages telling me 3rd Party Software installed on my Mac won’t be compatible with a future version of Mac OS and to contact the developer? It’s not the customers job to remind the developer to update their software to be compatible.
Never. Apple will do this to you again and again.
It would be trivial for Apple to support 68k software in System 11. It would be trivial to support 68k, PowerPC, 32-bit Intel, and ARM software at the same time. The only programs that truly couldn't handle it would be things like disk utilities.
But in the next few years you can expect that Apple will again f you over when they intentionally break 64-bit Intel software, just as they did for every previous architecture.
I'm done. No M1 for me. Xubuntu is looking really nice these days, and it'll run on standard x86 hardware for the foreseeable future. Hardware that also doesn't make me get new dongles for every new port that comes along because it still includes the old ports. And with just a tiny hack, I can run x86 Mac software in VMware Workstation. I can even get it to run Apple's last really good version of Mac OS X, 10.6.
For now, I'm telling my clients to buy Intel Macs while they still can, avoid the M1 garbage like the plague it is. That'll get them at least 5 years of reasonable functionality, then we can move on to what's next, which at this point isn't likely to be Apple.
Microsoft OSs suck. But did you know you can still run some 16-bit Windoze 1 software on current Windoze 10 20H2? You can.
Intentionally breaking compatibility is insane.
That backwards compatibility comes at a cost - a huge increasingly complex OS that has numerous issues because developers took shortcuts that make going to the next level. Look at the horrid performance of Microsoft's x86 emulator vs Apple's translator. Like it or not x86 has likely reached the end of the road of how it can be improved without getting into the 'doubles as a space heater' jokes again. Nearly everybody (even AMD) has seen that ARM is the future be it Opterron (and the M1 competitor AMD is rumored to be working on) or the M1. Hanging on the dying past is why Sears, Blockbuster, and dozens of other business are either walking undead are all but dead.
I can run a World Builder, a 32-bit 68000 assembly program from 1986 via emulation on a modern Mac. If you want to run old software there will be a market for emulators. If their isn't a market not enough people really care about act old software...otherwise there would be emulators QED.
It’s interesting to me while DarkVader says Microsoft operating systems suck, Apple is f-ing over people by blowing away backwards compatibility.
The engineering tradeoff is there ain’t no such thing as a free lunch: for DarkVader he wants the backwards compatibility Windows is famous for, despite claiming the OS sucks, while saying Apple sucks for not having it. Well, here’s the thing: all that backwards compatibility is what causes the perception of it “sucking” as an OS as it absolutely has a HUGE amount of overhead in maintaining/fixing/updating/adding features for the OS, not to mention system performance. Backwards compatibility exists in Windows to a large degree because of something called shims, which accounts for various applications and groups of applications expecting the OS to behave in some particular internal-detail method that it no longer does: this is what shims are for. If applications only use APIs as formally documented, there’s lots of backwards compatibility with zero efforts.
Windows over time has had major changes as hardware capabilities have changed (SMP, multiple sockets, sound hardware, GPUs arriving, etc.) and natural performance characteristics of underlying hardware has changed assumptions that made sense in the past, but remember: Microsoft focuses on big enterprise customers, and they loathe rewriting applications that have no functional need to change, as that’s huge money: enterprises tend to be tied together with a lot of custom applications designed only for them, paid for only by them: Microsoft Office updates are cheap by comparison. New sets of APIs are created also when it’s figured out there are better ways of doing things.
Apple doesn’t care about backwards compatibility beyond a handful of years. They keep rewriting a lot of things and changing them out entirely, and any given software will usually work fine without major changes just as long as the support lifespan of any of their sold machines, which is fine for most non-enterprise consumers. This has a logical result in a lot less resource usage, and increases the chances of having cleaner code in the OS with far fewer odd special cases as well to account for third-party application software or device drivers (which, btw, Windows has a HUGE array of what’s supported compared to every other OS, especially MacOS for a mainstream OS).
Windows and MacOS are close to being mirror opposites of each other in how/why they are what they are: you don’t get a sleek minimal-resource-using OS with backwards compatibility, it can’t be done. You can’t get a sleek OS with maximal device driver support for the same reason.
Backwards compatibility could in theory be offered in other formats than what we usually think it means.
For instance, in many cases I could setup a virtual machine that would run an operating system just as if it'd been a regular hardware computer; and then run my choice of operating system on top of that. So I could run most software from most eras.
So in theory Apple could allow backwards compatibility simply by running some sort of loader that analyses the app you're trying to run, and then downloads the correct (walled) environment for it (meaning virtualisation from the hardware and up). So none of the mess of every version of the OS having to "natively" handle every API and whatnot of every earlier version.
So you could in theory have a situation where you just click on anything, and at most the OS give you a warning about potential license fee, if it is a huge download, and whether or not your current hardware will be able to run the environment at 1x speed or not. It wouldn't matter if it'd be software for Windows, NES, Jaguar, Linux, Mac, iOS, or anything else.
However, that wouldn't allow much of an integration between those environments, nor between them and your host OS; and there would be a huge hit in perfomance (which wouldn't matter with older stuff, but might be crippling with more modern environments).
The point being that as this separates the environments you would have the benefit of a lean OS to develop with new features, at the same time as you can offer more complete (but different) style of backwards compatibility. So a new style of backwards compatibility might be reasonable to pursue for a business like Apple; because it could allow whole back catalogs of software to without any effort at all be sold in Apple's AppStore.
And… as far as the comment about Apple not caring about backwards compatibility beyond a handful of years… Well, I don't think I've ever gotten less than 5 years of running the latest and greatest on any Mac that I've bought; and I think I in two cases hit 9-10 years before the hardware had to be retired. That's actually really good, and great value.
Certain things can’t be virtualized in a manner to provide acceptable results, such as Bluetooth as one I’m very familiar with being very problematic. The best virtualization of it by any vendor still sucks, and doesn’t have full functionality at all when virtualized, even then.
TCP/IP networking is actually far easier to virtualize, though there are still some complications you can run into.
Things get more complicated with other external hardware hooked up via hardware buses that no longer exists on newer hardware but (in theory) can be used with adapters, as in the Apple universe there’s often a tighter tie between newer OS versions with newer hardware and dropping of drivers.
Windows 10 out of the box has Hyper-V and it works quite well for things with no special I/O requirements but again, there are practical limitations.
Don't forget in the middle of Intel transition Apple also made the move from 32-bit to 64-bit. A7 has been 64-bit since 2013, Apple could have been planing the M1 transition since 2013.
When will I stop receiving onscreen messages telling me 3rd Party Software installed on my Mac won’t be compatible with a future version of Mac OS and to contact the developer? It’s not the customers job to remind the developer to update their software to be compatible.
Which 3rd-party software are you using that's triggering this message? That's the important question here since it's not Apple's job to update 3rd-party software. Contact the developer, if you can.
As for the article, I knew that BBEdit would be on the list. I was blown away when I read that they were fully compatible shorter after the M1 Macs were released. Talk about impressive engineering work!
I was surrprised to read that StuffIt! is still being used! That Big Sur interface looks sweet! Clean, friendly.
And GraphicConverter ... wow! That was a trusted super-handy utility for me back several years ago. I forget why I was even using it, but these days I manage to do what I need with ImageOptim and Pixelmator.
When will I stop receiving onscreen messages telling me 3rd Party Software installed on my Mac won’t be compatible with a future version of Mac OS and to contact the developer? It’s not the customers job to remind the developer to update their software to be compatible.
Which 3rd-party software are you using that's triggering this message? That's the important question here since it's not Apple's job to update 3rd-partyk software. Contact the developer, if you can.
As for the article, I knew that BBEdit would be on the list. I was blown away when I read that they were fully compatible shorter after the M1 Macs were released. Talk about impressive engineering work!
I was surrprised to read that StuffIt! is still being used! That Big Sur interface looks sweet! Clean, friendly.
And GraphicConverter ... wow! That was a trusted super-handy utility for me back several years ago. I forget why I was even using it, but these days I manage to do what I need with ImageOptim and Pixelmator.
BBEdit is ancient, has gone through more than one processor change, and what it does is not commonly something coded in a very CPU-specific manner, typically, so I’d expect the biggest question was what weird differences exists between M1 Big Sur and Catalina (not available on M1) and perhaps small changes required for style updates for making it look proper for Big Sur, that’d also be identical on Intel Macs. Any other changed features are extras, but making it fully compatible (with old styling, not using new APIs) was likely as simple as changing CPU target, building, and some quick automated tests.
Something using CPU-specific instructions for such things as media processing are going to be more problematic: Apple has provided OS frameworks for abstracting those things, so I’d hope developers rely on those and make their software M1-native with a simple rebuild.
When will I stop receiving onscreen messages telling me 3rd Party Software installed on my Mac won’t be compatible with a future version of Mac OS and to contact the developer? It’s not the customers job to remind the developer to update their software to be compatible.
Never. Apple will do this to you again and again.
It would be trivial for Apple to support 68k software in System 11. It would be trivial to support 68k, PowerPC, 32-bit Intel, and ARM software at the same time. The only programs that truly couldn't handle it would be things like disk utilities.
But in the next few years you can expect that Apple will again f you over when they intentionally break 64-bit Intel software, just as they did for every previous architecture.
I'm done. No M1 for me. Xubuntu is looking really nice these days, and it'll run on standard x86 hardware for the foreseeable future. Hardware that also doesn't make me get new dongles for every new port that comes along because it still includes the old ports. And with just a tiny hack, I can run x86 Mac software in VMware Workstation. I can even get it to run Apple's last really good version of Mac OS X, 10.6.
For now, I'm telling my clients to buy Intel Macs while they still can, avoid the M1 garbage like the plague it is. That'll get them at least 5 years of reasonable functionality, then we can move on to what's next, which at this point isn't likely to be Apple.
Microsoft OSs suck. But did you know you can still run some 16-bit Windoze 1 software on current Windoze 10 20H2? You can.
Intentionally breaking compatibility is insane.
That backwards compatibility comes at a cost - a huge increasingly complex OS that has numerous issues because developers took shortcuts that make going to the next level. Look at the horrid performance of Microsoft's x86 emulator vs Apple's translator. Like it or not x86 has likely reached the end of the road of how it can be improved without getting into the 'doubles as a space heater' jokes again. Nearly everybody (even AMD) has seen that ARM is the future be it Opterron (and the M1 competitor AMD is rumored to be working on) or the M1. Hanging on the dying past is why Sears, Blockbuster, and dozens of other business are either walking undead are all but dead.
I can run a World Builder, a 32-bit 68000 assembly program from 1986 via emulation on a modern Mac. If you want to run old software there will be a market for emulators. If their isn't a market not enough people really care about act old software...otherwise there would be emulators QED.
It’s interesting to me while DarkVader says Microsoft operating systems suck, Apple is f-ing over people by blowing away backwards compatibility.
The engineering tradeoff is there ain’t no such thing as a free lunch: for DarkVader he wants the backwards compatibility Windows is famous for, despite claiming the OS sucks, while saying Apple sucks for not having it. Well, here’s the thing: all that backwards compatibility is what causes the perception of it “sucking” as an OS as it absolutely has a HUGE amount of overhead in maintaining/fixing/updating/adding features for the OS, not to mention system performance. Backwards compatibility exists in Windows to a large degree because of something called shims, which accounts for various applications and groups of applications expecting the OS to behave in some particular internal-detail method that it no longer does: this is what shims are for. If applications only use APIs as formally documented, there’s lots of backwards compatibility with zero efforts.
Windows over time has had major changes as hardware capabilities have changed (SMP, multiple sockets, sound hardware, GPUs arriving, etc.) and natural performance characteristics of underlying hardware has changed assumptions that made sense in the past, but remember: Microsoft focuses on big enterprise customers, and they loathe rewriting applications that have no functional need to change, as that’s huge money: enterprises tend to be tied together with a lot of custom applications designed only for them, paid for only by them: Microsoft Office updates are cheap by comparison. New sets of APIs are created also when it’s figured out there are better ways of doing things.
Apple doesn’t care about backwards compatibility beyond a handful of years. They keep rewriting a lot of things and changing them out entirely, and any given software will usually work fine without major changes just as long as the support lifespan of any of their sold machines, which is fine for most non-enterprise consumers. This has a logical result in a lot less resource usage, and increases the chances of having cleaner code in the OS with far fewer odd special cases as well to account for third-party application software or device drivers (which, btw, Windows has a HUGE array of what’s supported compared to every other OS, especially MacOS for a mainstream OS).
Windows and MacOS are close to being mirror opposites of each other in how/why they are what they are: you don’t get a sleek minimal-resource-using OS with backwards compatibility, it can’t be done. You can’t get a sleek OS with maximal device driver support for the same reason.
Backwards compatibility could in theory be offered in other formats than what we usually think it means.
For instance, in many cases I could setup a virtual machine that would run an operating system just as if it'd been a regular hardware computer; and then run my choice of operating system on top of that. So I could run most software from most eras.
So in theory Apple could allow backwards compatibility simply by running some sort of loader that analyses the app you're trying to run, and then downloads the correct (walled) environment for it (meaning virtualisation from the hardware and up). So none of the mess of every version of the OS having to "natively" handle every API and whatnot of every earlier version.
So you could in theory have a situation where you just click on anything, and at most the OS give you a warning about potential license fee, if it is a huge download, and whether or not your current hardware will be able to run the environment at 1x speed or not. It wouldn't matter if it'd be software for Windows, NES, Jaguar, Linux, Mac, iOS, or anything else.
However, that wouldn't allow much of an integration between those environments, nor between them and your host OS; and there would be a huge hit in perfomance (which wouldn't matter with older stuff, but might be crippling with more modern environments).
The point being that as this separates the environments you would have the benefit of a lean OS to develop with new features, at the same time as you can offer more complete (but different) style of backwards compatibility. So a new style of backwards compatibility might be reasonable to pursue for a business like Apple; because it could allow whole back catalogs of software to without any effort at all be sold in Apple's AppStore.
And… as far as the comment about Apple not caring about backwards compatibility beyond a handful of years… Well, I don't think I've ever gotten less than 5 years of running the latest and greatest on any Mac that I've bought; and I think I in two cases hit 9-10 years before the hardware had to be retired. That's actually really good, and great value.
Certain things can’t be virtualized in a manner to provide acceptable results, such as Bluetooth as one I’m very familiar with being very problematic. The best virtualization of it by any vendor still sucks, and doesn’t have full functionality at all when virtualized, even then.
TCP/IP networking is actually far easier to virtualize, though there are still some complications you can run into.
Things get more complicated with other external hardware hooked up via hardware buses that no longer exists on newer hardware but (in theory) can be used with adapters, as in the Apple universe there’s often a tighter tie between newer OS versions with newer hardware and dropping of drivers.
Windows 10 out of the box has Hyper-V and it works quite well for things with no special I/O requirements but again, there are practical limitations.
Absolutely, I once even had to get a newer MBP simply because my work required a newer version of bluetooth, and the just plain old regular OS really didn't want to work with a simple USB-dongle; so there would absolutely be cases where virtualisation would just compound certain limitations.
But just like I had to get a new computer I think that when we are talking professional use not just getting the right equipment falls into the territory of pet peeves and being stubborn out of principle; so I do think that for the average consumer the practical limitations wouldn't be felt at all.
And by running these environments in their own windows there would be this visual indication to the user that they are running that particular software in some form of "jailed" environment, one extra step away/behind their "real" computer; which hopefully would be enough for them to understand that maybe that's not the right place to run servers etc.
Comments
The engineering tradeoff is there ain’t no such thing as a free lunch: for DarkVader he wants the backwards compatibility Windows is famous for, despite claiming the OS sucks, while saying Apple sucks for not having it. Well, here’s the thing: all that backwards compatibility is what causes the perception of it “sucking” as an OS as it absolutely has a HUGE amount of overhead in maintaining/fixing/updating/adding features for the OS, not to mention system performance. Backwards compatibility exists in Windows to a large degree because of something called shims, which accounts for various applications and groups of applications expecting the OS to behave in some particular internal-detail method that it no longer does: this is what shims are for. If applications only use APIs as formally documented, there’s lots of backwards compatibility with zero efforts.
Windows over time has had major changes as hardware capabilities have changed (SMP, multiple sockets, sound hardware, GPUs arriving, etc.) and natural performance characteristics of underlying hardware has changed assumptions that made sense in the past, but remember: Microsoft focuses on big enterprise customers, and they loathe rewriting applications that have no functional need to change, as that’s huge money: enterprises tend to be tied together with a lot of custom applications designed only for them, paid for only by them: Microsoft Office updates are cheap by comparison. New sets of APIs are created also when it’s figured out there are better ways of doing things.
Apple doesn’t care about backwards compatibility beyond a handful of years. They keep rewriting a lot of things and changing them out entirely, and any given software will usually work fine without major changes just as long as the support lifespan of any of their sold machines, which is fine for most non-enterprise consumers. This has a logical result in a lot less resource usage, and increases the chances of having cleaner code in the OS with far fewer odd special cases as well to account for third-party application software or device drivers (which, btw, Windows has a HUGE array of what’s supported compared to every other OS, especially MacOS for a mainstream OS).
Windows and MacOS are close to being mirror opposites of each other in how/why they are what they are: you don’t get a sleek minimal-resource-using OS with backwards compatibility, it can’t be done. You can’t get a sleek OS with maximal device driver support for the same reason.
For instance, in many cases I could setup a virtual machine that would run an operating system just as if it'd been a regular hardware computer; and then run my choice of operating system on top of that. So I could run most software from most eras.
So in theory Apple could allow backwards compatibility simply by running some sort of loader that analyses the app you're trying to run, and then downloads the correct (walled) environment for it (meaning virtualisation from the hardware and up). So none of the mess of every version of the OS having to "natively" handle every API and whatnot of every earlier version.
So you could in theory have a situation where you just click on anything, and at most the OS give you a warning about potential license fee, if it is a huge download, and whether or not your current hardware will be able to run the environment at 1x speed or not. It wouldn't matter if it'd be software for Windows, NES, Jaguar, Linux, Mac, iOS, or anything else.
However, that wouldn't allow much of an integration between those environments, nor between them and your host OS; and there would be a huge hit in perfomance (which wouldn't matter with older stuff, but might be crippling with more modern environments).
The point being that as this separates the environments you would have the benefit of a lean OS to develop with new features, at the same time as you can offer more complete (but different) style of backwards compatibility. So a new style of backwards compatibility might be reasonable to pursue for a business like Apple; because it could allow whole back catalogs of software to without any effort at all be sold in Apple's AppStore.
And… as far as the comment about Apple not caring about backwards compatibility beyond a handful of years… Well, I don't think I've ever gotten less than 5 years of running the latest and greatest on any Mac that I've bought; and I think I in two cases hit 9-10 years before the hardware had to be retired. That's actually really good, and great value.
If you ship an OS with bugs - fix them.
No major release should ever be the solution for bugs in a previous major release.
If you are eliminating features, be very, very upfront about it.
Shipping incremental updates and then cutting off further fixes in a rush to the next major release just one year later creates a culture of chasing the next release. When it arrives, users are nagged senseless to upgrade to it and a swathe of new bugs.
First advice is always 'update to the latest release'. That is a hoop you absolutely must jump through most of the time and is in itself a cause of problems unless your hardware/software just happens to be relatively modern. Often you get zero warning of the (often hellish) problems that result from jumping through that hoop. But you are just told to jump anyway.
I've been there in a classic situation: old MBP, new iPhone, iTunes.
Even going to a retail Apple Store, explaining my concerns (borne out of years of experience in Apple's failed compatibility problems) didn't stop me from getting snagged.
The guy at the front end just wants the sale. Any resulting problems will be dealt with after the sale. No amount of pushing will change anything. You get smarmy smiles and told there shouldn't be anything to worry about.
Then the problems begin. This iPhone needs a newer version of iTunes. Download and install (that itself is fraught with issues - every iTunes update I've ever done has sent something to hell!). Open iTunes, connect the phone. This now needs a newer version of the OS.
A newer version which will break applications that have nothing to do with the new iPhone or iTunes. But Apple wants you on the newest x.0 release (itself full of bugs) so I say, nooooo! I'll go for an older, more stable release which is nowhere to be found (easily) at Apple because they are hellbent on you going to the latest version, no matter what!
To the point of stealth updating your machine unless you read everything very clearly.
Can you see a pattern forming here? Yearly major updates, changes everywhere, applications that get lobotomised (I'm looking at you Disk Utility) applications that fall apart under their own weight but are left to wreak havoc on users. iTunes should have been broken up looooong before it was. It was Apple that turned it into a monster.
The list is endless.
Resources? Overheads? Complexities?
Apple has the resources available. So many cash reserves it doesn't even know what to do with them!
I had told the Apple Store employee about my concerns. They were shoved aside and I was left with a erased iPhone (trade in) and a backup on a perfectly valid Mac that the iPhone couldn't talk to and three smiley Apple people charged with setting up the phones, all scratching their heads. Solution: make an appointment with tech support and come back another day. 120km round trip. Nope. I even tried to contact Apple via web because the information I needed wasn't visible anywhere. To do that you needed the serial number of the machine, then you get shoved into a paywall for a tech related consultation that requires a payment. I was looking for basic compatibility information. Nothing more.
The story is longer and more complex than I'm relating here - and I fixed it myself in a more traditional 'old school' way but is a perfect example of what I'm saying and the massive irony of the situation is that if I were in exactly the same situation but on Windows, I wouldn't have run into any of the problems because of backwards compatibility.
Siri should be able to eliminate ALL the possible conflicts the user might need to know of. AI is perfect for this stuff. Why support issues of this kind aren't available through Siri is a mystery.
I did not need for a smug Apple employee to tell me I shouldn't run into issues. A machine could have put the brakes on the whole process but that would have stopped the sale in its tracks but that, of course is sacred. After the sale it is up to the back end guys to resolve problems. The same guys who many of which have never seen a 'vintage' mac in their lives.
It was always crazy that Apple didn't let you backup your iDevice 'universally'. Throwing up messages informing users that this or that will or won't be backed up depending on which type of backup (local/remote) you choose is not user friendly.
File format support? This should be baked in law. As we are now firmly entrenched in a digital age no one should have to lose access to their documents due to format issues. Saying a format is 20 years old and the app is long gone is NOT a valid answer especially when it's an old Apple application that came with the system. The problem here though needs a legislative focus.
Slowing down release schedules would greatly improve compatibility and the bugginess of the system and related applications. Better planning would also go a long way. The migration of applications like Pages to 'apps' was a disaster from a user perspective. In fact, Pages and its cohorts is a classic example of Apple releasing a major application and letting it rot until the next major OS update suddenly sees it get some love. In between bugfixes are a lot less than they should be.
The original Rosetta was dropped way earlier than it should have been and is one of the reasons I shied away from later updates.
TCP/IP networking is actually far easier to virtualize, though there are still some complications you can run into.
Things get more complicated with other external hardware hooked up via hardware buses that no longer exists on newer hardware but (in theory) can be used with adapters, as in the Apple universe there’s often a tighter tie between newer OS versions with newer hardware and dropping of drivers.
Windows 10 out of the box has Hyper-V and it works quite well for things with no special I/O requirements but again, there are practical limitations.
Which 3rd-party software are you using that's triggering this message? That's the important question here since it's not Apple's job to update 3rd-party software. Contact the developer, if you can.
As for the article, I knew that BBEdit would be on the list. I was blown away when I read that they were fully compatible shorter after the M1 Macs were released. Talk about impressive engineering work!
I was surrprised to read that StuffIt! is still being used! That Big Sur interface looks sweet! Clean, friendly.
And GraphicConverter ... wow! That was a trusted super-handy utility for me back several years ago. I forget why I was even using it, but these days I manage to do what I need with ImageOptim and Pixelmator.
Something using CPU-specific instructions for such things as media processing are going to be more problematic: Apple has provided OS frameworks for abstracting those things, so I’d hope developers rely on those and make their software M1-native with a simple rebuild.
But just like I had to get a new computer I think that when we are talking professional use not just getting the right equipment falls into the territory of pet peeves and being stubborn out of principle; so I do think that for the average consumer the practical limitations wouldn't be felt at all.
And by running these environments in their own windows there would be this visual indication to the user that they are running that particular software in some form of "jailed" environment, one extra step away/behind their "real" computer; which hopefully would be enough for them to understand that maybe that's not the right place to run servers etc.