Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Stop being pedantic here. This is about me paying $$$ upfront and having support cut off because the developer can't be bothered. Just what type of shoddy development practices are you advocating here? You take my money? You sure as hell better support it when I use it, regardless of your excuses.

As for "licenses", call it what pretend method you want but that copy I bought belongs to me and is for me to decide what I do with it and how long *I* want to use it. Not some cowboy developer.

Ok, so I release software for licensing when I am 40. I'm not going to come back to it when I am 50, let alone sell you the entire codebase and right to alter it for the sake of passing off a shoddy copy.
You didn't do any development work, so you are not entitled to own a single line of code, instead you have a license to use it as it was designed, and not claim ownership for something you never worked on.

There are different levels of contractual obligations that you have with a developer or software product. For your standard consumer level purchase where you pay at most a couple hundred dollars and that is the extent of it -- you really are just buying the right to use a product for on a version (hopefully continuing to work on future versions of the OS) with support maybe for the first year only.... and maybe the ability to ask for your money back within the first month if the product did not live up to promises made by the developer... that is about the extent of it. If you use software in ways that are not meant to be used - that is not the problem of the developer. He can chose it is important or not. If a product is not profitable, and does not sell well.... there is no recourse if the product gets orphaned.... The reputation of the developer is one thing that you have to take into account when purchasing any software of any importance to you.

If you are purchasing it as a corporation which it may be "mission critical" there are a slew of other more detailed contractual obligations that may be included in the purchase agreement.... but then the customer pays for those. Things like minimum support length, Service Level Agreement stating expected turn around for different classes of defects etc. I know many corporations that will not buy mission critical applications from small developers because it is important for them that if the contractual terms are not lived up to ..... they have to be large enough to sue and have some redress.

Additional contractual terms could be agreement of a source code license - but not a customizable software license.... or that the company must place the source code in trust with a 3rd party so that if the contractual terms are not lived up to and a breach takes place -- worse comes to worse the company can take over their own support.

There are different rights a licensee has, but someone paying a small amount to use an application -- is really just paying to use as is.... nothing more -- nothing less.
 
Maybe this is the type of thing Trump should step into so that he can help make Apple Great Again(tm). I think it should be illegal to stop supporting 32-bit apps.

I think that Swarzenegger should Make Earth Great Again. I also think there is a time to separate rubbish from recycling, and 32 bit after a decade of 64bit is time for the rubbish bin.
 
I really hope Apple uses the opportunity.
When 32 bit Apps are phased out in IOS and MacOS Apple can design a 64 Bit only ARM design.
MacOS should (correct me if im wrong) need a compiler for ARM instead of an emulator like on Windows.
As far as I know (Im new to the topic) the MacOS Apps are designed to be compilable for many archtectures (PPC and X86) instead of just X86.
The A10x is already really powerfull. A 64 bit only sucsessor could make the Macbooks much faster and more efficient.
I really hope Aplle does that.
 
I really hope Apple uses the opportunity.
When 32 bit Apps are phased out in IOS and MacOS Apple can design a 64 Bit only ARM design.
MacOS should (correct me if im wrong) need a compiler for ARM instead of an emulator like on Windows.
As far as I know (Im new to the topic) the MacOS Apps are designed to be compilable for many archtectures (PPC and X86) instead of just X86.
The A10x is already really powerfull. A 64 bit only sucsessor could make the Macbooks much faster and more efficient.
I really hope Aplle does that.

Apple has everything in place that they absolutely need to - to have an ARM based MacOS device. The compiler, LLVM etc. and base operating system is all there.... and I have no doubt they have test machines with ARM running MacOS. I could see them creating an ARM based MacOS device, BUT they would have to have the App store apps done without the customers having to worry about whether it was an ARM or Intel based machine.

However, Apple is not going to replace their entire line with ARM based devices. The current ARM processor could handle the lower powered processors of the Macbook line, but they would have to create a higher powered processor for the middle of the line (which when the limits of thermal constraints are removed - I am sure the Apple engineers could do -- but that could affect their more important device lineup the iOS devices because of the distraction). The top of the line (Xeon class) would probably not have a replacement for the near future (unless they brought back Power based processors; but then the line is mixed and we are back to brand damage due to incompatible device lineup confusion).

An ARM based device would not be able to run X86 code (I see a lawsuit in the future for Microsoft and Qualcomm) so Bootcamp, vmware (running other OSs that are Intel based) would not run on these new devices.

So the question what are the benefits, and what are the costs. I have outlined some of the costs, and the benefits are that they could create a $200 or so less MacBook, and they could create a very cheap Mac Mini ..... but Apple's brand does not rely on building cheaper devices... and the potential brand damage due to confusion within the MacOS lineup would be not worth the risk (for the near and foreseeable future).
 
Apple has always pushed its customers toward the latest OS version.

Since 2000, Apple has stopped supporting:
- System 7
- Mac OS 8
- Mac OS 9
- Mac OS 10.0
- Mac OS 10.1
- Mac OS 10.2
- Mac OS 10.3
- Mac OS 10.4
- Mac OS 10.5
- Mac OS 10.6
- Mac OS 10.7
- Mac OS 10.8
- Mac OS 10.9

Microsoft, as a contrast:
- windows 98
- Windows ME
- Windows XP
- Windows Vista
- Windows 7
- Windows 8

Backwards compatibility is a Microsoft strength, not Apple's.



Buying Apple computers for industrial use is not a good call. That said, while I can understand consumers wanting to update to the latest and greatest OS, this is not something that is normally done with industrial equipment, or especially medical equipment, so this should be a non-issue.


This is Shullbit right from the start. Are you going to count Service Packs? Because this is not a fair comparison. Last release still supported - 10.10, and Windows 10. Both released when? 2013. Operating systems older than that offer large security risks and low ROI. Funny thing though... how much money have you paid for an OS since 2013? $0?
 
This is Shullbit right from the start. Are you going to count Service Packs? Because this is not a fair comparison. Last release still supported - 10.10, and Windows 10. Both released when? 2013. Operating systems older than that offer large security risks and low ROI. Funny thing though... how much money have you paid for an OS since 2013? $0?
Why would I? Service packs do not generally overhaul the OS. It's a fair comparison.

The conversation you are quoting concerns equipment that in all likelihood, should not be connected to the web or have other apps running, therefore security risks should be minimal and using an older OS is reasonable and a good ROI for the business.
 
If anyone here wants ByteController 0.9, I managed to find a .dmg on the Wayback Machine and a repository on GitHub… It's a nifty iTunes menubar control app which also allowed for setting always-available iTunes keyboard shortcuts (a useful feature for anyone using older or non-Apple media-keyless keyboards, but, alas, that functionality seems to be gone in this version), which I've been using since… 2005-ish, and in its v. 0.8.6 iteration it was one of the only 32-bit apps (besides some random Adobe processes) I could spot on Activity Monitor… Apparently there was a later, 64-bit App Store release (it's basically a dead link now) but also a regular release, which took me a while to find.

By the way, I added a few custom skins I made for Tiger, Leopard/Snow Leopard/Lion/Mountain Lion, Mavericks, Yosemite and El Capitan/Sierra/High Sierra and added Retina assets (even though I don't have Retina Macs to use them on, but that's where the HiDPI screen modes came in handy). The latter versions of macOS tend to mess with the pressed-down state background colours a bit (especially when using the dark+graphite look) depending on what colour your desktop picture is, but it's still usable.

So, long story short, I ended up repackaging the whole thing with my skins bundled and republishing it on GitHub. If anyone is willing to clean it up a bit or add some skins, be my guest. ;)

Enjoy! https://github.com/joaofrgomes/bytecontroller/releases/tag/0.9.1
 
Last edited:
Why would I? Service packs do not generally overhaul the OS. It's a fair comparison.

The conversation you are quoting concerns equipment that in all likelihood, should not be connected to the web or have other apps running, therefore security risks should be minimal and using an older OS is reasonable and a good ROI for the business.

A lot of those macOS versions are closer to service packs than overhauls of the system.

macOS x.y.z
x = 10 - version of the OS
y = 0 -> 13 - service packs with 0,1,2 being really betas.
z = security and bug fixes.

Many Microsoft "service packs" encompass a longer time frame than Apple's "releases" with probably just as much development resources.

Now it is not as simple as that.... but really.... how much has really changed in macOS really.... on each incremental version of the last decade.... A few new features of note in each of them (small), some application changes, some optimization, some inter-operative features with their new OS (iOS).... You get some of that in Windows service packs (the version updates for Windows tend to be lets royally mess things up - so we can fix them again).

There is a reason why many people are asking if this is the new "boring Apple" ....

(oh, I don't mind boring rather than exciting like Windows 8 :p )
 
Last edited:
A lot of those macOS versions are closer to service packs than overhauls of the system.

macOS x.y.z
x = 10 - version of the OS
y = 0 -> 13 - service packs with 0,1,2 being really betas.
z = security and bug fixes.

Many Microsoft "service packs" encompass a longer time frame than Apple's "releases" with probably just as much development resources.

Now it is not as simple as that.... but really.... how much has really changed in macOS really.... on each incremental version of the last decade.... A few new features of note in each of them (small), some application changes, some optimization, some inter-operative features with their new OS (iOS).... You get some of that in Windows service packs (the version updates for Windows tend to be lets royally mess things up - so we can fix them again).

There is a reason why many people are asking if this is the new "boring Apple" ....

(oh, I don't mind boring rather than exciting like Windows 8 :p )

Cool, and I can see you're points. All I'm pointing out is that in three to five years, a version of Windows, regardless of how many service packs have been released, regardless of the weekly security updates, will most likely still be supported by Microsoft. In three to five years, your version of macOS most likely will not.

It's not a criticism. It's the informed choice you need to make before you devote time, energy, and funds to whichever ecosystem you are going to choose to join.
 
  • Like
Reactions: huperniketes
Cool, and I can see you're points. All I'm pointing out is that in three to five years, a version of Windows, regardless of how many service packs have been released, regardless of the weekly security updates, will most likely still be supported by Microsoft. In three to five years, your version of macOS most likely will not.

It's not a criticism. It's the informed choice you need to make before you devote time, energy, and funds to whichever ecosystem you are going to choose to join.

I can agree with that statement -- though support itself differs by audience. If you are the right audience and pay as a corporation for that support as well as licenses (which are not free as it is with individuals) then yes -- you will have longer support.... though it does not mean that the issue will be resolved in that version necessarily (or in a timely manner).... The response may just be it has been resolved in the newer version, or the newer version of that device is only supported in the newer version.

The other issue is that Apple does not announce supported platforms ahead of time -- which can be more of an issue than the length of time for support. I remember back to a large schedule B bank that ran specialized software that I was part of a team developing and we told them at that time the aging 286 hardware would no longer be supported (they had not upgraded any hardware in a long time) and the minimum was 386 I think... The issue was not that they had to replace their hardware at not an insignificant cost.... the issue was that they had no budget to do so. For them to upgrade, they needed at least 18 months notice ahead of time so that they could have allocated a budget for it.

Now, Apple does not have major deployments in many of these companies (they do have their strong holds or areas that they have made inroads -- IBM being one notable one; and a former consulting company for most of the technical consultants)... so it would be less of an issue with those more resistant to change.

One other area of concern for those resistant to change is radical changes in the UI (which Windows has done in the last few major versions).... it can be seen as disruptive to rolling out updates due to company-wide retraining and confusion for those that are not the most technical. I upgraded my elder sisters mac probably 3 or 4 versions the last time I was in Canada... not that much of a change for regular users in that regards.
 
  • Like
Reactions: jeremiah256
Unless there is specific benefit to a particular app to leveraging 64-bit execution, being forced to use 64-bit rather than 32-bit potentially means potentially higher memory requirements (pointers and other values use twice as much memory to store what may be effectively the same data), among other possible ramifications.

64-bit versions of Windoze do not support 16-bit applications so dropping support for older stuff is hardly anything new, but it is not without consequence either.

Still, if Apple has evaluated the impact to their customer base and determined that this is an appropriate step at this time, there is nothing stopping them from doing that.
 
Unless there is specific benefit to a particular app to leveraging 64-bit execution, being forced to use 64-bit rather than 32-bit potentially means potentially higher memory requirements (pointers and other values use twice as much memory to store what may be effectively the same data), among other possible ramifications.

64-bit versions of Windoze do not support 16-bit applications so dropping support for older stuff is hardly anything new, but it is not without consequence either.

Still, if Apple has evaluated the impact to their customer base and determined that this is an appropriate step at this time, there is nothing stopping them from doing that.

That would depend on your compilers, your developers ... being inefficient.

It is your assets that take up more room... because people still often use images and bitmaps and monitors are higher resolution.
 
I can agree with that statement -- though support itself differs by audience. If you are the right audience and pay as a corporation for that support as well as licenses (which are not free as it is with individuals) then yes -- you will have longer support.... though it does not mean that the issue will be resolved in that version necessarily (or in a timely manner).... The response may just be it has been resolved in the newer version, or the newer version of that device is only supported in the newer version.

The other issue is that Apple does not announce supported platforms ahead of time -- which can be more of an issue than the length of time for support. I remember back to a large schedule B bank that ran specialized software that I was part of a team developing and we told them at that time the aging 286 hardware would no longer be supported (they had not upgraded any hardware in a long time) and the minimum was 386 I think... The issue was not that they had to replace their hardware at not an insignificant cost.... the issue was that they had no budget to do so. For them to upgrade, they needed at least 18 months notice ahead of time so that they could have allocated a budget for it.

Now, Apple does not have major deployments in many of these companies (they do have their strong holds or areas that they have made inroads -- IBM being one notable one; and a former consulting company for most of the technical consultants)... so it would be less of an issue with those more resistant to change.

One other area of concern for those resistant to change is radical changes in the UI (which Windows has done in the last few major versions).... it can be seen as disruptive to rolling out updates due to company-wide retraining and confusion for those that are not the most technical. I upgraded my elder sisters mac probably 3 or 4 versions the last time I was in Canada... not that much of a change for regular users in that regards.

I sort of understand people being worked up about all this if they have a computer that runs a program that operates some machinery or something of that nature. The truth in those cases, however, is that they really don't much need forward compatibility. They have an old computer and the software to make the machine do its thing. They don't really need to upgrade to the next iteration of an OS. They're screwed if their unsupported software crashes, but they're also screwed when a part on an old machine breaks and there are no more parts.

On the other hand, you mention here a bank running ancient hardware and software with no budget for upgrades. That to me is horrifying. A core function for a bank or similar businesses is data security. They should have money committed to upgrades every year. As the bad guys get more sophisticated, it's incumbent on the good guys to keep up. A bank should be planning on continuous upgrades, not fretting because they weren't given an 18-month lead time to maybe think about doing something to secure their data and operations. Maybe if they just wait a little longer, their data will end up being even more secure, because the bad guys who have the expertise to hack into their antique systems will all have retired.
 
  • Like
Reactions: kiwipeso1
(checks list of apps currently on Mac Mini)
I'm hoping a 64-bit version of Boxer will eventually come out, as I find it really useful when I do my "Let's Play" videos of old MS-DOS games from my childhood.
Then I can't use iDVD anymore, since Apple thinks DVDs are like Betamax tapes.
Hopefully 64-bit versions of Roxio Toast Titanium and Tuxera Disk Manager come out soon as well.

Other than those, most of the apps I regularly use are 64-bit versions.
 
I sort of understand people being worked up about all this if they have a computer that runs a program that operates some machinery or something of that nature. The truth in those cases, however, is that they really don't much need forward compatibility. They have an old computer and the software to make the machine do its thing. They don't really need to upgrade to the next iteration of an OS. They're screwed if their unsupported software crashes, but they're also screwed when a part on an old machine breaks and there are no more parts.

On the other hand, you mention here a bank running ancient hardware and software with no budget for upgrades. That to me is horrifying. A core function for a bank or similar businesses is data security. They should have money committed to upgrades every year. As the bad guys get more sophisticated, it's incumbent on the good guys to keep up. A bank should be planning on continuous upgrades, not fretting because they weren't given an 18-month lead time to maybe think about doing something to secure their data and operations. Maybe if they just wait a little longer, their data will end up being even more secure, because the bad guys who have the expertise to hack into their antique systems will all have retired.

This bank example does date back as I said to when 286, 386 were more common (i.e. before the internet outside of academia became common).... but yes budgets are still important but security is more of a concern as is ATMs, web portals, etc. If I remember right this was a time when the branch link to head office systems was 9600 baud fixed link and messaging was not bloated :p
 
Civilisation V is the only major game to worry about, and a few old Star Wars games.
However, VMware fusion is acceptable, along with the HDD on my iMac for running old systems.
However, Civilisation VI is fine now that the aussie "civilisation" DLC is here.
 
There are plenty benefits that the move will or could allow, some of which Apple alone is uniquely positioned to benefit; from rewriting their frameworks in Swift and the performance gains involved in that; further unification of iOS and macOS frameworks that can be done by getting rid of the legacy runtime 32 bit Mac apps require; removing entire classes of bugs that Swift does not even make possible compared to, say, Objective-C or C; Apple could use future chips that have only 64 bit instruction sets (getting rid of the 32 bit portion would bring performance and energy use benefits)...

The x86-64 processors used in the Mac don't execute Swift code. They execute x86-64 binaries which were compiled from C, C++, Objective-C, Swift, x86/X86-64 assembly language, etc. Rewriting their frameworks to take advantage of the benefits of Swift (which they could also add to their other compilers, by the way) doesn't mean it will only run on 64-bit processors. It just requires setting the compiler switch to generate 32-bit binaries, which the build settings for the frameworks obviously already do.

Some of these might be immaterial, but there are some strategic benefits in getting rid of 32 bit support.

You mean strategic in that an action taken by Apple will result in a reaction by others that will benefit Apple? Because it certainly doesn't benefit Apple's user community, nor its developers who aren't getting the benefits of compounded growth in the userbase.
 
  • Like
Reactions: jeh72
Apple is clearly withholding details about the reasons for phasing out 32-bit apps because it doesn't hurt anyone to simply leave it in the distribution.

Here are a few possible theories I have been mulling over.

Apple has already started moving forward with eliminating 64 bit applications and OS level support in iOS. The custom ARM processor in the future could in turn drop support for 32 bit support, freeing up some of the all important silicon (cost of manufacturing chips goes up the larger the die size, and the yield drops more or less in lock step (a semi exponential scale more or less).

The core OS is the same for iOS as it is for macOS, and I am not sure whether they are branches of each other long ago which they copy back and forth from -- or if they have one trunk and have custom deviations for it. If they drop 32 bit support for the ARM it would be logical to drop it from macOS to keep them reasonably close.

One other potential is that they have potential plans to run a mix of ARM and Intel processors (ARM at the lower end; Intel at the upper end). Part of this is in place with I believe the submission of the bitcode to the App store that can be "optimized" or in this case an ARM binary or Intel binary downloaded (fat binary alternative - along with app thinning). Applications distributed directly might still cause confusion - but it is possible they could change the distribution to fat binaries and/or bitcode that is translated to ARM or Intel on installation.

Now if they have eliminated 32 bit support for ARM but not for Intel -- this would make transparent support for ARM vs Intel impossible.

Obviously this sort of strategic information they would be unwilling to divulge ... so they would have to come up with some sort of vague storyline.

Interesting to note, some reports I have seen is that the iPad Pro A10X can hit geekbench of 9100ish which is on par with the top of the Macbook Pro 13" (dual core) lineup.... (5-7 watt chip vs 15 watt I believe and associated thermals).

-----

One 32 bit app is now no longer a problem. MS Office 2011 will not work or be supported under High Sierra (according to Microsoft). The problem apparently originates within Microsoft's Xamarin middleware layer. Microsoft has typically had a habit of straying from Apple's guidelines in the past... so not that surprising.
 
Last edited:
Here are a few possible theories I have been mulling over.

Apple has already started moving forward with eliminating 64 bit applications and OS level support in iOS. The custom ARM processor in the future could in turn drop support for 32 bit support, freeing up some of the all important silicon (cost of manufacturing chips goes up the larger the die size, and the yield drops more or less in lock step (a semi exponential scale more or less).

The core OS is the same for iOS as it is for macOS, and I am not sure whether they are branches of each other long ago which they copy back and forth from -- or if they have one trunk and have custom deviations for it. If they drop 32 bit support for the ARM it would be logical to drop it from macOS to keep them reasonably close.

One other potential is that they have potential plans to run a mix of ARM and Intel processors (ARM at the lower end; Intel at the upper end). Part of this is in place with I believe the submission of the bitcode to the App store that can be "optimized" or in this case an ARM binary or Intel binary downloaded (fat binary alternative - along with app thinning). Applications distributed directly might still cause confusion - but it is possible they could change the distribution to fat binaries and/or bitcode that is translated to ARM or Intel on installation.

Now if they have eliminated 32 bit support for ARM but not for Intel -- this would make transparent support for ARM vs Intel impossible.

Obviously this sort of strategic information they would be unwilling to divulge ... so they would have to come up with some sort of vague storyline.

Interesting to note, some reports I have seen is that the iPad Pro A10X can hit geekbench of 9100ish which is on par with the top of the Macbook Pro 13" (dual core) lineup.... (5-7 watt chip vs 15 watt I believe and associated thermals).

-----

One 32 bit app is now no longer a problem. MS Office 2011 will not work or be supported under High Sierra (according to Microsoft). The problem apparently originates within Microsoft's Xamarin middleware layer. Microsoft has typically had a habit of straying from Apple's guidelines in the past... so not that surprising.

Apple's second year of Intel macs were 64bit a decade ago. We are talking about machines that are long due to die from normal wear and tear, and it would be only in 2018 that the problem occurs for 2006 macs.
ARM is a totally different design for CPU instructions in terms of being of the RISC variety compared to CISC for Intel.
As ARM is far less powerful than Intel in terms of instructions processed, then it would not be capable of supporting MacOS without a hardware CISC coprocessor like the core M for retina Macbook.
What is more likely is that an ARM processor for low power tasks for power-nap and simple tasks becomes an addition to the 2018 macbooks and macbook pros, maybe even the macbook air if it gets a real update.
 
Apple's second year of Intel macs were 64bit a decade ago. We are talking about machines that are long due to die from normal wear and tear, and it would be only in 2018 that the problem occurs for 2006 macs.
ARM is a totally different design for CPU instructions in terms of being of the RISC variety compared to CISC for Intel.
As ARM is far less powerful than Intel in terms of instructions processed, then it would not be capable of supporting MacOS without a hardware CISC coprocessor like the core M for retina Macbook.
What is more likely is that an ARM processor for low power tasks for power-nap and simple tasks becomes an addition to the 2018 macbooks and macbook pros, maybe even the macbook air if it gets a real update.
You didn't see the benchmark results of the new iPadPro yet? They are as fast as the 2013 i5 iMacs...
 
Apple's second year of Intel macs were 64bit a decade ago. We are talking about machines that are long due to die from normal wear and tear, and it would be only in 2018 that the problem occurs for 2006 macs.
ARM is a totally different design for CPU instructions in terms of being of the RISC variety compared to CISC for Intel.
As ARM is far less powerful than Intel in terms of instructions processed, then it would not be capable of supporting MacOS without a hardware CISC coprocessor like the core M for retina Macbook.
What is more likely is that an ARM processor for low power tasks for power-nap and simple tasks becomes an addition to the 2018 macbooks and macbook pros, maybe even the macbook air if it gets a real update.

Do you understand what the LLVM is?

The LLVM roughly speaking is a portable assembly language of sorts. The clang compiler takes C, C++, Swift (there are more languages supported by the LLVM) and compiles it into IR - Intermediate Representation (sort of the portable assembly code). Eventually this code is then taken further down to either ARM or Intel (or it could support Power in the future). Apple has been using this for almost a decade. Microsoft has started supporting it in their platforms more recently. Linux supports it as well.

The primary reason that Apple had to move to Intel is because there was no real focus on creating good -- reasonably powerful chips for laptops. Banks that run an application that I have been previously involved in run our systems on IBM Power based hardware. Power processors are RISC processors -- always have been. Now Intel has made great strides in the their processors in adopting some of the stuff that RISC processors took for granted (parallel execution of code, less cycles per instruction).... basically adding some of the RISC architecture under the hood for their CISC processors... Back to the software these are large systems -- that have to be rock solid and powerful.

Being a CISC processor does not make it suddenly become more powerful. The ARM processor has grown up with it's main reason for existence of being energy efficient and very low power - which is why they are used in devices.... but that is a design restriction -- remove that restriction and you Apple could easily create it's own processor that takes out all but the very top of their line. It would however not be able to run Windows or Intel versions of Linux (there are Power versions of Linux).

Geekbench is a benchmarking that focuses on measuring close to the metal (i.e. CPU benchmarking focused). The A10X (3 core I believe again) is the heart of the new iPad has geekbench mark scores for multi-core of 9091 (3832 single core) -- in a processor that has to fit in a much more restrictive thermal design. That is almost the same as the i5-7360U based Macbook Pro (13-Inch) which has less of a restriction and uses 3 times as much power at least. The top of the line Macbook Pro (13-Inch is up to about 9730 for Kaby lake -- but that is the only Macbook Pro 13-Inch that is ranked higher).
 
You didn't see the benchmark results of the new iPadPro yet? They are as fast as the 2013 i5 iMacs...

Benchmarks do not reflect actual Flops in normal usage.
What do you not understand that Reduced Instruction Set Chip is less sophisticated than Complex Instruction Set Chip ?
Do you think there is something special about a maths test which has subject specific performance aimed at the test questions which are taught to the students for years before the test ?
No ? Then, why do you think the manufacturers make chips comply with known test questions just like teachers teach to the national standards questions.
 
Benchmarks do not reflect actual Flops in normal usage.
What do you not understand that Reduced Instruction Set Chip is less sophisticated than Complex Instruction Set Chip ?
Do you think there is something special about a maths test which has subject specific performance aimed at the test questions which are taught to the students for years before the test ?
No ? Then, why do you think the manufacturers make chips comply with known test questions just like teachers teach to the national standards questions.

You do realize that the "historic battle" of RISC vs CISC is largely over and RISC won? Even the x86-64 bit CISC instruction set is translated down to RISC microcode before execution (basically an on CPU API compatibility layer of sorts). Having more instructions (bloated) does not automatically translate to more advanced.

Now it has been almost 30 years ago since I last wrote any assembly code directly.... in those days there was the 8088/8086/80x86 pre moving to a RISC chip architecture and the "Flops" (or Floating Point Operations) actually executed in a math co-processor (80x87) and the main processor was integer only. Oh, and the more "complex" instructions took up to 12 clock cycles vs 1 clock cycle for the RISC (or less when parallel execution was taking place). On the Mac there is now a standard library to use if you are doing lots of "Flops" .... it is the Metal 2 Compute library.... and that uses the GPU to do lots of floating point calculations (which gives you a real bump in performance). There are rumours that Apple may even add additional "machine learning" specialized chips in future products. There is a reason why Nvidia has pivoted to this business.... they get to repurpose the same stuff they use in their GPUs (their Floating Point Compute Units) for a growing business... The Tensor Processor Unit that Google has is basically the same technology producing petaflops of compute power in a rack (more efficient than A tower full of Xeon processors for the same purpose).

Now a lot of standard banking /brokerage back-office financial applications would never ever use "flops" since using "approximate" scientific floating point calculations will inevitably lead to calculation errors due to repeating binary (like repeating decimal calculations of 1/3) and rounding.... leading to calculation errors when it comes to money (out by a cent out by 1,000,000.01 on one side of the ledger and 1,000,000.00 on the other side). i.e. fixed decimal calculations should be done through integer instructions with the decimal point applied after the calculation. I believe even in Java's implementation of Big Decimal the value is calculated and stored in an array of up to 8 integer values (does not fit in 64 bits) and the scale in another value... which is wrapped up in a immutable object.

Flops are primarily used for video, machine learning calculations, scientific... and all those are better executed on specialized hardware not the Intel CPU itself.
 
Last edited:
Why would I? Service packs do not generally overhaul the OS. It's a fair comparison.

The conversation you are quoting concerns equipment that in all likelihood, should not be connected to the web or have other apps running, therefore security risks should be minimal and using an older OS is reasonable and a good ROI for the business.

You're joking, right? Machines with things like Windows 7, and OS X 10.9... they shouldn't be connected to the internet, thus have a good ROI? Did you read what you wrote??
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.