9 ms·

Honestly, the 32-bit support shouldn't have been removed. It should have been split off into a separate package like the XQuartz project, as some of us still us

Honestly, the 32-bit support shouldn't have been removed. It should have been split off into a separate package like the XQuartz project, as some of us still use 32-bit applications daily. Very disturbing that one of the biggest companies around can't keep 32-bit support, at least in some capacity.

buzzerbetrayed 7y ago
It’s not that they can’t keep 32-bit support, it’s that they don’t want to. Apple has a history of forcing people in to the future that they envision. Much like they did with removing the disk drive and the headphone jack. Seems like that is what they are doing here by killing 32-bit applications.
- wtallis 7y ago
  This is more like when they dropped support for PowerPC emulation. It's less about forcing people into the future than about forcing Adobe and friends into the present.
  - Wowfunhappy 7y ago
    Adobe is in the present, though—Creative Cloud is completely 64 bit. Removing 32 bit support hurts users.
    - wtallis 7y ago
      Adobe wasn't 64-bit clean at the time that Apple announced they would be deprecating 32-bit binary compatibility. At the very least, Apple forced Adobe to update their DRM to something that didn't require running 32-bit code.
      - Wowfunhappy 7y ago
        That's fair, I didn't realize that. However, I think it's worth asking, who was that hurting? Users certainly aren't going to notice, and license activation isn't performance-critical code.
        wtallis 7y ago
        > and license activation isn't performance-critical code. No, but DRM is pretty likely to require your OS to remain exactly bug-compatible with older versions. After all, the entire point is for it to cause trouble if it detects unexpected changes in system configuration or behavior, even if those changes are within the scope allowed by loose API definitions or undefined/unspecified behavior. E.g. it's pretty much expected that when an OS tightens security restrictions, it'll break a lot of DRM and video game anti-cheat systems. Inserting a new compatibility shim is also likely to be mistaken by those systems as a circumvention tool.
        Wowfunhappy 7y ago
        Well, that assumes the DRM is stringent. I don't think Adobe's ever was, it was certainly cracked easily enough. CS6's activation system has also survived _many_ macOS updates, up until this moment when Apple outright ripped out 32 bit. Maybe that's because Apple was purposefully maintaining compatibility with CS6 explicitly, but given how they operate, I kind of doubt it.
        pfranz 7y ago
        I'm sure for Apple it's QC, build process, documentation, examples, and constraints around building new things--maybe sharing stuff between iOS or preparing for a transition to ARM. Who knows? Apple tends to support the old OS for a few years, so while it does suck, it should be manageable. It drives me nuts that installers and license managers are old and crufty. I do understand why. A few times now I've encountered situations where the installer cannot run even though the software it installs is fine.
        Wowfunhappy 7y ago
  - asveikau 7y ago
    The real issue is that some people are relying on unmaintained software. If they want to serve customers, IMO, the platform vendor should make a best-effort attempt to let unmaintained software keep working. I hear a lot of post hoc justifications from Apple fans about how hard to maintain the compatibility layers are. But. It strikes me that a job has fun and not so fun parts. If there is really an ongoing maintenance issue generating more work release-to-release maybe look to re-design how the compatibility layer works.
    - wtallis 7y ago
      > If they want to serve customers, IMO, the platform vendor should make a best-effort attempt to let unmaintained software keep working. I agree. The problem is when the major ISVs abuse this and force Apple to keep doing high-priority QA to preserve binary compatibility with major applications that are mission-critical for many Apple users and are still maintained to some degree. Users of unmaintained applications are generally somewhat understanding or accepting of gradual breakage driven by real technical necessity. Users with an active subscription to Adobe CC rightfully have higher expectations that their software continue to work without being broken by OS updates - but Adobe was trying to make that entirely Apple's problem, just as they did for migrating away from PowerPC and Carbon APIs.
sigjuice 7y ago
The 32-bit support is probably not easy to carve out into a separate self-contained package.
- favorited 7y ago
  You literally need 32-bit builds of every system library & framework. That's the state of things in Mojave. If you run `otool /System/Library/Frameworks/AppKit.framework/AppKit -f` you'll see 2 slices, one for "cputype 16777223" (CPU_TYPE_X86 | CPU_ARCH_ABI64) and one for "cputype 7" (CPU_TYPE_X86).
  - sneakernets 7y ago
    I don't expect new features to be implemented in 32-bit builds - maybe security patches at the most - so freezing it and keeping it as a separate package should be feasible. This is exactly what Linux distros are planning to do.
    - vetinari 7y ago
      Apple uses the concept of fat binaries, where single binary contains code segments for several architectures. Optional support would mean basically two versions of the entire operating system: one supporting only 64 bit, and the second supporting both, 32 and 64 bits. Linux solves it differently, it uses separate binaries for separate architectures. You can install the libraries into separate paths, have separate dynamic loader and everything works. Apple has no such option.
      - sneakernets 7y ago
        This explains the downvotes. I did some googling and noticed "Universal Binaries" mentioned in the results, which I remember in the 00s but had no idea that was remotely related to the OS binaries themselves.
      - comex 7y ago
        Also, macOS has a lot of system libraries that do IPC to either system daemons or kernel drivers, where the library exposes a stable API/ABI, but where the IPC interface itself has absolutely zero stability guarantees. This is because the library and the daemon/driver are developed together as part of the same codebase; users are expected to upgrade them in lockstep as part of an OS update, and to always use the library to talk to the daemon/driver rather than reimplementing the IPC yourself. This way, the developers only have to manage one stable interface (the library) rather than two (the library as well as the IPC interface). But that means you can’t just freeze the version of the library and expect it to work with newer daemons/drivers. In theory Apple could change course and decide that all system IPC interfaces must be kept stable starting now, but that would be really annoying, and probably more work than just continuing to update the 32-bit libraries. (This even applies to the base Unix system calls. Go previously did syscalls by hand but recently switched to dynamically linking against libSystem and using its wrappers, because they’re the only guaranteed-stable interface.)
ubermonkey 7y ago
It's not, really. Nobody wants to carry support for both 32- and 64-bit forever. You've got to call the ball at some point. Now's as good a time as any.
- bluedino 7y ago
  Is it a security improvement? Is it just less hassle to keep updating all the 32-bit stuff? What does Apple or the users gain from removing 32-bit?
  - sigjuice 7y ago
    As a user, I get some of my disk space back.
    - kstrauser 7y ago
      And RAM, as you don't have two copies of every library loaded at the same time.
  - kamyarg 7y ago
    > What does Apple or the users gain from removing 32-bit? > Nobody wants to carry support for both 32- and 64-bit forever. Support means money and developer time, no one wants to waste money unless they really have to. In this case they don't have to, because everyone should have already updated whatever they use that was first made only for 32bit to 64bit. imho the actual blame lies on whoever have resisted moving to 64bit(again mostly because of money).
    - Hammershaft 7y ago
      We are talking about one of the richest companies on the planet that makes by far the largest margins on their laptops and desktops in the industry. If any company is equipped to offer 32 bit legacy support for the benefit of their users it is Apple.
      - 7y ago
zelly 7y ago
If only there were an OS that allowed you to do what you wanted with your computer. http://www.linuxfromscratch.org/ http://www.linuxfromscratch.org/ https://www.openbsd.org/ https://www.openbsd.org/
- sneakernets 7y ago
  Unfortunately the applications I use are Proprietary and Music related _on top of_ being OSX/Windows specific, and there's no way I can replicate this setup on Linux.

buzzerbetrayed 7y ago

It’s not that they can’t keep 32-bit support, it’s that they don’t want to. Apple has a history of forcing people in to the future that they envision. Much like they did with removing the disk drive and the headphone jack. Seems like that is what they are doing here by killing 32-bit applications.

wtallis 7y ago
This is more like when they dropped support for PowerPC emulation. It's less about forcing people into the future than about forcing Adobe and friends into the present.
- Wowfunhappy 7y ago
  Adobe is in the present, though—Creative Cloud is completely 64 bit. Removing 32 bit support hurts users.
  - wtallis 7y ago
    Adobe wasn't 64-bit clean at the time that Apple announced they would be deprecating 32-bit binary compatibility. At the very least, Apple forced Adobe to update their DRM to something that didn't require running 32-bit code.
    - Wowfunhappy 7y ago
      That's fair, I didn't realize that. However, I think it's worth asking, who was that hurting? Users certainly aren't going to notice, and license activation isn't performance-critical code.
      - wtallis 7y ago
        > and license activation isn't performance-critical code. No, but DRM is pretty likely to require your OS to remain exactly bug-compatible with older versions. After all, the entire point is for it to cause trouble if it detects unexpected changes in system configuration or behavior, even if those changes are within the scope allowed by loose API definitions or undefined/unspecified behavior. E.g. it's pretty much expected that when an OS tightens security restrictions, it'll break a lot of DRM and video game anti-cheat systems. Inserting a new compatibility shim is also likely to be mistaken by those systems as a circumvention tool.
        Wowfunhappy 7y ago
        Well, that assumes the DRM is stringent. I don't think Adobe's ever was, it was certainly cracked easily enough. CS6's activation system has also survived _many_ macOS updates, up until this moment when Apple outright ripped out 32 bit. Maybe that's because Apple was purposefully maintaining compatibility with CS6 explicitly, but given how they operate, I kind of doubt it.
      - pfranz 7y ago
        I'm sure for Apple it's QC, build process, documentation, examples, and constraints around building new things--maybe sharing stuff between iOS or preparing for a transition to ARM. Who knows? Apple tends to support the old OS for a few years, so while it does suck, it should be manageable. It drives me nuts that installers and license managers are old and crufty. I do understand why. A few times now I've encountered situations where the installer cannot run even though the software it installs is fine.
        Wowfunhappy 7y ago
- asveikau 7y ago
  The real issue is that some people are relying on unmaintained software. If they want to serve customers, IMO, the platform vendor should make a best-effort attempt to let unmaintained software keep working. I hear a lot of post hoc justifications from Apple fans about how hard to maintain the compatibility layers are. But. It strikes me that a job has fun and not so fun parts. If there is really an ongoing maintenance issue generating more work release-to-release maybe look to re-design how the compatibility layer works.
  - wtallis 7y ago
    > If they want to serve customers, IMO, the platform vendor should make a best-effort attempt to let unmaintained software keep working. I agree. The problem is when the major ISVs abuse this and force Apple to keep doing high-priority QA to preserve binary compatibility with major applications that are mission-critical for many Apple users and are still maintained to some degree. Users of unmaintained applications are generally somewhat understanding or accepting of gradual breakage driven by real technical necessity. Users with an active subscription to Adobe CC rightfully have higher expectations that their software continue to work without being broken by OS updates - but Adobe was trying to make that entirely Apple's problem, just as they did for migrating away from PowerPC and Carbon APIs.

sigjuice 7y ago

The 32-bit support is probably not easy to carve out into a separate self-contained package.

favorited 7y ago
You literally need 32-bit builds of every system library & framework. That's the state of things in Mojave. If you run `otool /System/Library/Frameworks/AppKit.framework/AppKit -f` you'll see 2 slices, one for "cputype 16777223" (CPU_TYPE_X86 | CPU_ARCH_ABI64) and one for "cputype 7" (CPU_TYPE_X86).
- sneakernets 7y ago
  I don't expect new features to be implemented in 32-bit builds - maybe security patches at the most - so freezing it and keeping it as a separate package should be feasible. This is exactly what Linux distros are planning to do.
  - vetinari 7y ago
    Apple uses the concept of fat binaries, where single binary contains code segments for several architectures. Optional support would mean basically two versions of the entire operating system: one supporting only 64 bit, and the second supporting both, 32 and 64 bits. Linux solves it differently, it uses separate binaries for separate architectures. You can install the libraries into separate paths, have separate dynamic loader and everything works. Apple has no such option.
    - sneakernets 7y ago
      This explains the downvotes. I did some googling and noticed "Universal Binaries" mentioned in the results, which I remember in the 00s but had no idea that was remotely related to the OS binaries themselves.
    - comex 7y ago
      Also, macOS has a lot of system libraries that do IPC to either system daemons or kernel drivers, where the library exposes a stable API/ABI, but where the IPC interface itself has absolutely zero stability guarantees. This is because the library and the daemon/driver are developed together as part of the same codebase; users are expected to upgrade them in lockstep as part of an OS update, and to always use the library to talk to the daemon/driver rather than reimplementing the IPC yourself. This way, the developers only have to manage one stable interface (the library) rather than two (the library as well as the IPC interface). But that means you can’t just freeze the version of the library and expect it to work with newer daemons/drivers. In theory Apple could change course and decide that all system IPC interfaces must be kept stable starting now, but that would be really annoying, and probably more work than just continuing to update the 32-bit libraries. (This even applies to the base Unix system calls. Go previously did syscalls by hand but recently switched to dynamically linking against libSystem and using its wrappers, because they’re the only guaranteed-stable interface.)

ubermonkey 7y ago

It's not, really. Nobody wants to carry support for both 32- and 64-bit forever. You've got to call the ball at some point. Now's as good a time as any.

bluedino 7y ago
Is it a security improvement? Is it just less hassle to keep updating all the 32-bit stuff? What does Apple or the users gain from removing 32-bit?
- sigjuice 7y ago
  As a user, I get some of my disk space back.
  - kstrauser 7y ago
    And RAM, as you don't have two copies of every library loaded at the same time.
- kamyarg 7y ago
  > What does Apple or the users gain from removing 32-bit? > Nobody wants to carry support for both 32- and 64-bit forever. Support means money and developer time, no one wants to waste money unless they really have to. In this case they don't have to, because everyone should have already updated whatever they use that was first made only for 32bit to 64bit. imho the actual blame lies on whoever have resisted moving to 64bit(again mostly because of money).
  - Hammershaft 7y ago
    We are talking about one of the richest companies on the planet that makes by far the largest margins on their laptops and desktops in the industry. If any company is equipped to offer 32 bit legacy support for the benefit of their users it is Apple.
    - 7y ago

zelly 7y ago

If only there were an OS that allowed you to do what you wanted with your computer. http://www.linuxfromscratch.org/ http://www.linuxfromscratch.org/ https://www.openbsd.org/ https://www.openbsd.org/

sneakernets 7y ago
Unfortunately the applications I use are Proprietary and Music related _on top of_ being OSX/Windows specific, and there's no way I can replicate this setup on Linux.