7 ms·

Apple is a trillion dollar company. It can easily support running 32-bit indefinitely, perhaps with a download for 32-bit libraries libraries and/or with some s

Apple is a trillion dollar company. It can easily support running 32-bit indefinitely, perhaps with a download for 32-bit libraries libraries and/or with some sort of containerization. As a platform holder it has the responsibility to do so. Failing to do that is a clear abdication. It is clear from the post that Apple's platforms are hostile towards any sort of digital executable art.

unlinked_dll 7y ago
It's not about "could" but about "should." Apple hasn't sold a computer with a 32 bit CPU in what, 8-9 years? They deprecated 32 bit support almost a decade ago. Software has a lifespan and always has, to run obsolete code you need to jump through hoops to get an obsolete target running. This isn't new.
- FussyZeus 7y ago
  I've always wondered, what exactly is the overhead on running 32-bit code on a 64-bit machine? Why is support eventually dropped? I'm sure there are good reasons but I've no idea what they are.
  - unlinked_dll 7y ago
    I believe there is a little bit of overhead when it comes to mapping virtual addresses and dealing with different pointer sizes for the OS, but imo the main reason Apple wants to ditch 64 bit support is so their OS isn't tightly coupled to an ISA that has 32/64 bit modes. In other words it's not about the overhead, it's about the reliance on x86.
    - WorldMaker 7y ago
      If ISA decoupling is the goal then they should be mandating everyone write to a VM like the CLR or JVM (or variants like Dalvik). It seems kind of silly to block x86 modes on x64 chips when the backwards compatibility needs of Windows pretty much insures "eternal" x86 modes. It's going to be a while before x86 modes disappear on Intel or AMD chips, and there's evidence to support that like the Itanium (IA-64) failure, and the fact that Windows on ARM made it a commitment to emulate x86 (but not x64) on ARM. x86 is likely going to be a lasting "lingua franca" ISA. Right now I'd almost put more money on x64 being retired before x86, and if anything from that perspective Apple is more tightly coupled to an ISA than before this choice.
      - pohl 7y ago
        > ...if anything from that perspective Apple is more tightly coupled to an ISA than before this choice. That really depends on what their long-term goal is. If the speculation & rumors about an eventual ARM transition have any merit at all, then sunsetting 32-bit support now can help them smooth that transition, since they'll have a lot less work to do to implement whatever Rosetta-esque dynamic binary translator they would need.
        WorldMaker 7y ago
        Microsoft and Qualcomm together supposedly just invested tons of money in making sure that x86 emulates well on ARM64, but apparently had little success emulating x64 on ARM64. If the speculation and rumors about an ARM transition have merit, it seems backwards to sunset x86 and not x64. Which it seems unlikely that Apple could do in secrecy what Microsoft + Qualcomm could not do (very publicly), but I guess all things are possible.
- bonaldi 7y ago
  Yes, it is about should, and saying "it's a bit old" doesn't justify it. Why is 8 years self-evidently "long enough"? Banks have code from the 1960s still running, and plenty of people have industrial hardware much older than that. Many of my household appliances are older. It's only "obsolete" code because Apple has decided it is, it didn't rot.
  - Doingmything123 7y ago
    "Long enough" is for certain a relative term. I don't think we should be making the comparison to banking software/appliances though. Banks are notoriously slow and I would think are more concerned with correctness than new features. Given how often we see complaints about archaic banking software I'm not sure if 1960's code is a good thing but it has longevity by design. Apple does not need to play by these rules and as an end user I'm ok with that. I think Apple should optimize for the 97-99% of average users even if it is at the expense of a few and I see this change in that lens. Besides, the users who use 8+ year old software probably have the know-how and the will to jury-rig a solution to get around this.
  - code_sloth 7y ago
    > Banks have code from the 1960s still running The only reason "old code" still works in banks is because untold man hours are spent wrapping around it, working around it, and testing it. A long time ago, some exec saw that some old thing needed updating because the world has changed. There are new regulations, new customers types, new products, new strategies... A bunch of people get hired. A bright future of next thing is promised. It gets everyone excited and devs start cutting little chunks away off the old thing, making a new thing. Now there are 2 things to maintain, but that's ok, some day new thing will become next thing. But the exec leaves (probably to another bank) before the next thing became a thing. Another exec comes in, declares the new thing is crap because it doesn't quite get the job done. A next next thing is planned. The previous new thing is now the old new thing. It will be removed, someday. Just not today, because it's _a_ thing now. old new thing will be sunset when next next thing arrives. Many many years and several execs later, there are many things maintained by a small army of devs and testers. These things work in really strange, archaic, or even stupid ways. Nobody knows how (or worse, why) the entire system works. The most knowledgeable people only know how it _behaves_. But it's there, still working. And your money is in that thing of things. Many peoples' money are in it. That's not necessarily a good thing.
- spijdar 7y ago
  It's been longer than that. Core 2 Duos are 64 bit chips, and there were core 2 duo Macs releas e in late 2006, so it's been almost 13 yesrs. The 32 bit support is actually a bit of a red herring here; the bigger issue for some is Apple dropping support for Carbon, a 32 bit only API made to ease porting of classic MacOS apps from the 80s and 90s to OS X, and itself deprecated in 2012. I guess Apple could have created a 64 bit version, but it also seems reasonable to expect software developers to have rewritten effected software in that timespan. Carbon was originally a compromise for companies not wanting to learn an entire new OS (NeXTSTEP) and API/libraries when updating their apps for OS X -- the fact some apps still need it today is kind of mind boggling. Then, I suppose the Win32 API has been stable-ish for far longer.
  - gowld 7y ago
    What's wrong with Carbon? CLI tools still work 40 year later. Tk/Qt/Swing programs still work 20+ years later. Why not updated and recompile carbon for 64bit?
- damnyou 7y ago
  A work of digital art is not "obsolete", and trying to pretend that it is is capitalist garbage. There is lots of great modern art. but none of it makes older art "obsolete".
  - dkonofalski 7y ago
    While I agree, I think there's an important caveat that is missing. To me, digital art needs to be self-contained. Digital art, unlike physical art, doesn't really rely on anything else for it to present itself. It's why digital media has standards. A .jpg should, in theory, be self-contained and only require a device to view. A game presenting itself as digital art, however, needs to be tied to a specific platform and software that may not potentially run in the future for any number of reasons. It needs to be feature-locked and self-contained so that it can be archived. To try and compare modern/older art to modern/older digital art isn't fair or equivalent, in my opinion.
  - dwaite 7y ago
    Digital art, just like physical art, needs to be maintained. If a painting sits in a moldy basement for a decade, don't be surprised when someone finally go to check on it at what happened.
    - deleted 7y ago
      [deleted]
- fortran77 7y ago
  Not true! The Intel Architecture CPUs that's in the Macs of today lets you seamlessly mix 32- and 64- bit processes. Windows 10 Operating System has no trouble managing both types of processes.
  - asveikau 7y ago
    The argument that I have heard people make is that some ABIs are changing in 64 bit land, such as syscalls or how appkit talks to the window server, so they have to keep some 32 bit frameworks frozen in time in some places, and update them in others. Maintaining 32 bit versions of that is nonzero cost. That said, I don't agree with such an argument. It seems like seeking out technical excuses for crappy user outcomes. In another thread on this topic I said: in any job there are parts that are fun and others that are not so fun but necessary. They should try to keep customer apps working.
    - gowld 7y ago
      If you want long term support, buy windows or get linux. Mac is for cutting edge beautiful experiences of the future, not legacy of the past. It's a trade-off. Supporting old tookits makes your Mac less pretty.
      - asveikau 7y ago
        If that were true, maybe they should get rid of ancient relics like the Mach kernel. But honestly you sound like you believe Apple craps rainbows, or something. They aren't better than everybody else by virtue of self identity. They make lots of mistakes just like any other group of mortals.
- ken 7y ago
  > Apple hasn't sold a computer with a 32 bit CPU in what, 8-9 years? The Mini was the last Mac to make the switch to 64-bit, in "Mid 2007". So a little over 12 years. For comparison, the Macintosh was on M68K from 1984 to 1994 (10 years), and on PowerPC from 1994 to 2006 (12 years). IOW, the Mac has been on 64-bit x86 for as long as they've been on any CPU architecture ever. Another fun fact: there was less than 10 years between the last Apple IIe they sold and the first Power Mac G5.

unlinked_dll 7y ago

It's not about "could" but about "should." Apple hasn't sold a computer with a 32 bit CPU in what, 8-9 years? They deprecated 32 bit support almost a decade ago. Software has a lifespan and always has, to run obsolete code you need to jump through hoops to get an obsolete target running. This isn't new.

FussyZeus 7y ago
I've always wondered, what exactly is the overhead on running 32-bit code on a 64-bit machine? Why is support eventually dropped? I'm sure there are good reasons but I've no idea what they are.
- unlinked_dll 7y ago
  I believe there is a little bit of overhead when it comes to mapping virtual addresses and dealing with different pointer sizes for the OS, but imo the main reason Apple wants to ditch 64 bit support is so their OS isn't tightly coupled to an ISA that has 32/64 bit modes. In other words it's not about the overhead, it's about the reliance on x86.
  - WorldMaker 7y ago
    If ISA decoupling is the goal then they should be mandating everyone write to a VM like the CLR or JVM (or variants like Dalvik). It seems kind of silly to block x86 modes on x64 chips when the backwards compatibility needs of Windows pretty much insures "eternal" x86 modes. It's going to be a while before x86 modes disappear on Intel or AMD chips, and there's evidence to support that like the Itanium (IA-64) failure, and the fact that Windows on ARM made it a commitment to emulate x86 (but not x64) on ARM. x86 is likely going to be a lasting "lingua franca" ISA. Right now I'd almost put more money on x64 being retired before x86, and if anything from that perspective Apple is more tightly coupled to an ISA than before this choice.
    - pohl 7y ago
      > ...if anything from that perspective Apple is more tightly coupled to an ISA than before this choice. That really depends on what their long-term goal is. If the speculation & rumors about an eventual ARM transition have any merit at all, then sunsetting 32-bit support now can help them smooth that transition, since they'll have a lot less work to do to implement whatever Rosetta-esque dynamic binary translator they would need.
      - WorldMaker 7y ago
        Microsoft and Qualcomm together supposedly just invested tons of money in making sure that x86 emulates well on ARM64, but apparently had little success emulating x64 on ARM64. If the speculation and rumors about an ARM transition have merit, it seems backwards to sunset x86 and not x64. Which it seems unlikely that Apple could do in secrecy what Microsoft + Qualcomm could not do (very publicly), but I guess all things are possible.
bonaldi 7y ago
Yes, it is about should, and saying "it's a bit old" doesn't justify it. Why is 8 years self-evidently "long enough"? Banks have code from the 1960s still running, and plenty of people have industrial hardware much older than that. Many of my household appliances are older. It's only "obsolete" code because Apple has decided it is, it didn't rot.
- Doingmything123 7y ago
  "Long enough" is for certain a relative term. I don't think we should be making the comparison to banking software/appliances though. Banks are notoriously slow and I would think are more concerned with correctness than new features. Given how often we see complaints about archaic banking software I'm not sure if 1960's code is a good thing but it has longevity by design. Apple does not need to play by these rules and as an end user I'm ok with that. I think Apple should optimize for the 97-99% of average users even if it is at the expense of a few and I see this change in that lens. Besides, the users who use 8+ year old software probably have the know-how and the will to jury-rig a solution to get around this.
- code_sloth 7y ago
  > Banks have code from the 1960s still running The only reason "old code" still works in banks is because untold man hours are spent wrapping around it, working around it, and testing it. A long time ago, some exec saw that some old thing needed updating because the world has changed. There are new regulations, new customers types, new products, new strategies... A bunch of people get hired. A bright future of next thing is promised. It gets everyone excited and devs start cutting little chunks away off the old thing, making a new thing. Now there are 2 things to maintain, but that's ok, some day new thing will become next thing. But the exec leaves (probably to another bank) before the next thing became a thing. Another exec comes in, declares the new thing is crap because it doesn't quite get the job done. A next next thing is planned. The previous new thing is now the old new thing. It will be removed, someday. Just not today, because it's _a_ thing now. old new thing will be sunset when next next thing arrives. Many many years and several execs later, there are many things maintained by a small army of devs and testers. These things work in really strange, archaic, or even stupid ways. Nobody knows how (or worse, why) the entire system works. The most knowledgeable people only know how it _behaves_. But it's there, still working. And your money is in that thing of things. Many peoples' money are in it. That's not necessarily a good thing.
spijdar 7y ago
It's been longer than that. Core 2 Duos are 64 bit chips, and there were core 2 duo Macs releas e in late 2006, so it's been almost 13 yesrs. The 32 bit support is actually a bit of a red herring here; the bigger issue for some is Apple dropping support for Carbon, a 32 bit only API made to ease porting of classic MacOS apps from the 80s and 90s to OS X, and itself deprecated in 2012. I guess Apple could have created a 64 bit version, but it also seems reasonable to expect software developers to have rewritten effected software in that timespan. Carbon was originally a compromise for companies not wanting to learn an entire new OS (NeXTSTEP) and API/libraries when updating their apps for OS X -- the fact some apps still need it today is kind of mind boggling. Then, I suppose the Win32 API has been stable-ish for far longer.
- gowld 7y ago
  What's wrong with Carbon? CLI tools still work 40 year later. Tk/Qt/Swing programs still work 20+ years later. Why not updated and recompile carbon for 64bit?
damnyou 7y ago
A work of digital art is not "obsolete", and trying to pretend that it is is capitalist garbage. There is lots of great modern art. but none of it makes older art "obsolete".
- dkonofalski 7y ago
  While I agree, I think there's an important caveat that is missing. To me, digital art needs to be self-contained. Digital art, unlike physical art, doesn't really rely on anything else for it to present itself. It's why digital media has standards. A .jpg should, in theory, be self-contained and only require a device to view. A game presenting itself as digital art, however, needs to be tied to a specific platform and software that may not potentially run in the future for any number of reasons. It needs to be feature-locked and self-contained so that it can be archived. To try and compare modern/older art to modern/older digital art isn't fair or equivalent, in my opinion.
- dwaite 7y ago
  Digital art, just like physical art, needs to be maintained. If a painting sits in a moldy basement for a decade, don't be surprised when someone finally go to check on it at what happened.
  - deleted 7y ago
    [deleted]
fortran77 7y ago
Not true! The Intel Architecture CPUs that's in the Macs of today lets you seamlessly mix 32- and 64- bit processes. Windows 10 Operating System has no trouble managing both types of processes.
- asveikau 7y ago
  The argument that I have heard people make is that some ABIs are changing in 64 bit land, such as syscalls or how appkit talks to the window server, so they have to keep some 32 bit frameworks frozen in time in some places, and update them in others. Maintaining 32 bit versions of that is nonzero cost. That said, I don't agree with such an argument. It seems like seeking out technical excuses for crappy user outcomes. In another thread on this topic I said: in any job there are parts that are fun and others that are not so fun but necessary. They should try to keep customer apps working.
  - gowld 7y ago
    If you want long term support, buy windows or get linux. Mac is for cutting edge beautiful experiences of the future, not legacy of the past. It's a trade-off. Supporting old tookits makes your Mac less pretty.
    - asveikau 7y ago
      If that were true, maybe they should get rid of ancient relics like the Mach kernel. But honestly you sound like you believe Apple craps rainbows, or something. They aren't better than everybody else by virtue of self identity. They make lots of mistakes just like any other group of mortals.
ken 7y ago
> Apple hasn't sold a computer with a 32 bit CPU in what, 8-9 years? The Mini was the last Mac to make the switch to 64-bit, in "Mid 2007". So a little over 12 years. For comparison, the Macintosh was on M68K from 1984 to 1994 (10 years), and on PowerPC from 1994 to 2006 (12 years). IOW, the Mac has been on 64-bit x86 for as long as they've been on any CPU architecture ever. Another fun fact: there was less than 10 years between the last Apple IIe they sold and the first Power Mac G5.