Dropping 32 bit support seems to me to be an unnecessary policy that could put good software out of business just because it should be ported to 64 bit. What would it take for apple to keep supporting 32 bit software?
Flight checking software
William Kucharski wrote:
I'd disagree that it's slower; my MacPro 5,1 is still quite snappy running off rotating rust.
Try booting it from Mountain Lion sometimes.
In all seriousness, EtreCheck didn't spring forth from a focus group either, you wrote it after realizing that getting the data to be able to answer a user's question was more easily supplied by a utility that could collect it.
I wouldn't hold up EtreCheck as a shining example. If anything, it exemplifies the problems inherent is having one person try to do too much.
As far as 32-bit mode is concerned, it's a royal pain. You literally have to duplicate your entire test matrix for both 32-bit and 64-bit applications, which bind to 32-bit and 64-bit libraries and have 32-bit and 64-bit versions of syscalls.
No disagreement there. Maintaining support for 32-bit code is a silent bug-generator. I did that for a while with EtreCheck. The problem is that the API is the same, but the runtime is slightly different. The only way to test is to run it on a true 32-bit machine. In my case, I just happened to have an old 2008 machine that would run in 32-bit with the aid of some kernel boot flags. There are a number of really convenient language techniques that compile and build with no warnings for 32-bit, but just don't work. You just have to know what those are.
Ripping all that out makes macOS cleaner, faster and much easier to maintain.
It has the potential to do that. Somehow I doubt that we will notice that in the end.
I'd disagree that it's slower; my MacPro 5,1 is still quite snappy running off rotating rust.
You may not like the philosophy of "one person made it happen" but I personally know that's true of most every company you could name; certainly it's true of operating systems. There are an incalculable number of things in Linux, as an example, that exist only because one person saw a problem or wanted it to do something nifty and then sat down and wrote the code to do it.
In all seriousness, EtreCheck didn't spring forth from a focus group either, you wrote it after realizing that getting the data to be able to answer a user's question was more easily supplied by a utility that could collect it.
That same drive happens within companies too, and not just for people named "Steve."
As far as 32-bit mode is concerned, it's a royal pain. You literally have to duplicate your entire test matrix for both 32-bit and 64-bit applications, which bind to 32-bit and 64-bit libraries and have 32-bit and 64-bit versions of syscalls.
Ripping all that out makes macOS cleaner, faster and much easier to maintain.
I suspect it has to do with data compression. All architecture is 64 bit. Apple is making way for the new processors.
It never pays to get too far behind in hardware or software.
Technology marches on—
A change from a 32-bit to a 64-bit architecture is was a fundamental alteration, as most operating systems must be extensively modified to take advantage of the new architecture, because that software has to manage the actual memory addressing hardware. Other software must also be ported to use the new abilities; older 32-bit software may be supported either by virtue of the 64-bit instruction set being a superset of the 32-bit instruction set, so that processors that support the 64-bit instruction set can also run code for the 32-bit instruction set, or through software emulation, or by the actual implementation of a 32-bit processor core within the 64-bit processor, as with some Itanium processors from Intel, which included an IA-32 processor core to run 32-bit x86 applications. The operating systems for those 64-bit architectures generally support both 32-bit and 64-bit applications.
The name of the game is smaller, faster, more efficient. Cutting out the fat ie 32-bit software and the bloated processors that have to manage that old garbage. There is a performance penalty to pay having to cater to old software.
rccharles wrote:
Isn't ios and macOS basically the same thing? It seems mostly a different user experience.
Not quite. Apple has been making a big effort to get them closer the past few years. Since Yosemite, there has been little development at all on macOS other than porting iOS frameworks. The only parts left are some legacy frameworks and user interface frameworks. Some of those may be involved, or "compromised by" 32-bit support. The rumours are that Apple is going to port the iOS user interface this year. I'm surprised it has taken them this long. I think that is a testament to how much they have cut back on Mac development.
Without divulging anything I can't, I know a number of people specifically working on macOS internals, so I wouldn't be calling the coroner quite yet.
macOS is mature enough that it really doesn't need framework or UI changes, but it can certainly become faster, sleeker and more scalable underneath, plus things like large memory pages can be supported advantageously.
You do not have to go back that far in time when Apple dropped support for PPC (powerpc) apps. and everyone was up in arms.
For a release or two they continued support including the emulator "Rosetta." Then Rosetta was an option, then that was dropped all together. You can draw your own conclusions.
The terms of use for this user-to-user support community discourage speculation about Apple business decision, and practice. Only Apple knows the official reason behind the move to 64-bit applications.
William Kucharski wrote:
Without divulging anything I can't, I know a number of people specifically working on macOS internals, so I wouldn't be calling the coroner quite yet.
But what are they doing with those internals? They may be just porting iOS frameworks to the Mac.
One thing that has always bothered me is an offhand comment at WWDC (which is no longer under NDA). Apparently, there are features in macOS that are there only because one person put in the extra effort to make it happen. While I applaud the initiative and effort required to make things like that happen, it shouldn't happen that way.
There are people working on macOS internals, just not as many as there should be. They don't seem to have the full support of the corporation. macOS is no longer the flagship software product. It is the old legacy ball-n-chain held together with duct tape and bailing wire.
macOS is mature enough that it really doesn't need framework or UI changes, but it can certainly become faster, sleeker and more scalable underneath, plus things like large memory pages can be supported advantageously.
But every year it gets slower. I now tell people straight up "do NOT buy a new Mac without an SSD - a 'Fusion' drive does not count as an SSD".
And it does need framework and UI changes. In that respect, I support the ports from iOS. At least then, if something is broken and fixed on iOS, the fix will eventually make it to the Mac too. The Mac-specific APIs haven't been updated in years. I am looking forward to a unified UI API. I hope that isn't a rumour.
I don't think you can really use Mountain Lion as a comparison; it may feel and actually measure faster on some tasks, but it's also doing a lot less in the background.
That may not seem important for particular tasks, but overall the extra work High Sierra is doing is arguably more important for system stability and overall speed, notably the automatic RAM compression/decompression introduced in Mavericks.
William Kucharski wrote:
I don't think you can really use Mountain Lion as a comparison; it may feel and actually measure faster on some tasks, but it's also doing a lot less in the background.
No argument here.
However, none of that extra work in High Sierra does anything for reliability or speed other than reducing both. Instead, it is designed to support Apple's new services, whether or not you use them, and drive purchases of new hardware. A new, faster system from Apple used to cost $129, now it costs $3000.
Oh that's silly.
For most macOS is as stable as its ever been and compression on the fly makes running multiple apps more seamless than before. The Mac is based on very powerful hardware its good to see macOS take advantage of; for example, if it's not already present, I certainly hope large memory page support is imminent.
If new releases are meant to drive new hardware purchases, Apple really screwed up as my almost eight year old Mac Pro 5,1 feels faster than ever and if it were a real pig I would have sprung for an iMac Pro by now.
Hello breckfromtustin,
No one knows the details on the 32-bit thing. My suspicion is that Apple just wants to clean up a few legacy APIs to smooth the switch to iOS on the Mac.
Isn't ios and macOS basically the same thing? It seems mostly a different user experience.
Maybe apple is falling for the Microsoft Windows 8 thing ... one user experience every where.
R
Why is dropping 32 bit so important to apple?
