7 ms·

I mean most software that's currently maintained has been 64-bit ready for a decade. The issue is that there's a lot of 3rd party ghostware that isn't, and 32 b

I mean most software that's currently maintained has been 64-bit ready for a decade. The issue is that there's a lot of 3rd party ghostware that isn't, and 32 bit bridging to support that code has been popular for awhile. That software is a lot like vintage gear, there may be alternatives but they aren't the same, and that's the problem.

sneakernets 7y ago
This is the same boat I'm in. Some of these programs were created only by one person, who can be impossible to track down and get a timely response.
- chrisseaton 7y ago
  Sounds like the software was effectively already dead and it was best to move off it as soon as it became clear there was only one developer and they were hard to get hold of. The problem isn't with macOS.
  - _ph_ 7y ago
    Going to 64 bit can be a lot of work. So there is quite some software which is still lightly maintained for which there isn't a 64 bit update available. Software which has worked perfectly fine up to date.
    - davrosthedalek 7y ago
      Additionally, it has zero benefit for many applications from a performance stand point, or makes them even slower.
      - chrisseaton 7y ago
        > it has zero benefit for many applications They literally can't run without porting, disregarding performance. The benefit is infinite!
        davrosthedalek 7y ago
        But that's artificial, and you know it. The only reason for forcing 64bit is to lower Apple's support cost and push its bottom line.
        deleted 7y ago
        [deleted]
        chrisseaton 7y ago
        Fine by me - sweeping out the dust.
        bikeshed 7y ago
        If a program works fine, with no issues, why should companies be forced to update it simply because Apple decrees they no longer support 32 bit applications? "Sweeping the dust" is an absurd declaration.
      - wtallis 7y ago
        > or makes them even slower. Only in misleading microbenchmarks. In the real world, the memory bandwidth saved by using 32-bit pointers in some programs that can be guaranteed to not need more than 4GB of memory (or ASLR or other features enabled by x86-64) is completely outweighed by the costs of keeping both 64-bit and 32-bit libraries on disk and in memory and in cache. That's why even on Linux the x32 ABI was never able to gain traction even among Gentoo users, and why retaining traditional 32-bit support is viewed as only a compatibility measure for closed-source code that literally can't be updated.
  - odmjoevpojewivf 7y ago
    How was it dead when it still worked? And why move off something that fulfills your needs and works?
  - w1nst0nsm1th 7y ago
    It's specifically a macos issue. 32 bit softwares run naturally on 64 bit hardware on any platform, Windows, BSD, Linux, without any maintenance. It's just an Apple trick to force financial turnover for owner of 32 software. It's not that there softwares are not compatible anymore, it's MacOS which block artificially 32 bit software. It's for the same reason MacOS block sidecar for device older than 2016,even if they are capable to run sidecar in the first place.
    - chrisseaton 7y ago
      Your software doesn't run in isolation. It needs services of the operating system. Apple has to spend resources maintaining 32-bit software and consumers would rather they didn't do that.
      - virgilp 7y ago
        Poor Apple, that's certainly too onerous of a burden to put on their shoulders.
  - repolfx 7y ago
    I would note Chris, given your insistence on all this, that your own project Graal is still shipping on Java 8 despite that being many years old. You're now working on moving to Java 11, which is itself already obsolete. Imagine if tomorrow nobody could download GraalVM anymore because OpenJDK 8 stopped working for some reason (yes I know it's bundled, this is just a metaphor). It could easily be said you had years to upgrade, so why so sluggish? Well, of course, there were actual features you wanted to ship during this time too, not just doing upgrade work, especially given that Java 9 and 10 maybe didn't deliver many compelling upgrades.
    - chrisseaton 7y ago
      Hmmm I take your point, but OpenJDK 8 is maintained. A better example is the obvious impending transition to ARM, which GraalVM is already preparing for.
      - repolfx 7y ago
        Sure, but so is Mojave. It'll be some years before Apple stops shipping security updates to older releases. Until then app vendors saying "don't upgrade macOS" is no different to Java developers saying "don't run this on Java 11 because it doesn't work yet" and we've seen plenty of that. In fact, I'm guessing the pain of losing Java 8 will be too much for many organisations after so many years of stability and 9/10/11 breaking so much (current Gradle doesn't even work on Java 13!). Maintaining 8 will be a good business for a long time.

sneakernets 7y ago

This is the same boat I'm in. Some of these programs were created only by one person, who can be impossible to track down and get a timely response.

chrisseaton 7y ago
Sounds like the software was effectively already dead and it was best to move off it as soon as it became clear there was only one developer and they were hard to get hold of. The problem isn't with macOS.
- _ph_ 7y ago
  Going to 64 bit can be a lot of work. So there is quite some software which is still lightly maintained for which there isn't a 64 bit update available. Software which has worked perfectly fine up to date.
  - davrosthedalek 7y ago
    Additionally, it has zero benefit for many applications from a performance stand point, or makes them even slower.
    - chrisseaton 7y ago
      > it has zero benefit for many applications They literally can't run without porting, disregarding performance. The benefit is infinite!
      - davrosthedalek 7y ago
        But that's artificial, and you know it. The only reason for forcing 64bit is to lower Apple's support cost and push its bottom line.
        deleted 7y ago
        [deleted]
        chrisseaton 7y ago
        Fine by me - sweeping out the dust.
        bikeshed 7y ago
        If a program works fine, with no issues, why should companies be forced to update it simply because Apple decrees they no longer support 32 bit applications? "Sweeping the dust" is an absurd declaration.
    - wtallis 7y ago
      > or makes them even slower. Only in misleading microbenchmarks. In the real world, the memory bandwidth saved by using 32-bit pointers in some programs that can be guaranteed to not need more than 4GB of memory (or ASLR or other features enabled by x86-64) is completely outweighed by the costs of keeping both 64-bit and 32-bit libraries on disk and in memory and in cache. That's why even on Linux the x32 ABI was never able to gain traction even among Gentoo users, and why retaining traditional 32-bit support is viewed as only a compatibility measure for closed-source code that literally can't be updated.
- odmjoevpojewivf 7y ago
  How was it dead when it still worked? And why move off something that fulfills your needs and works?
- w1nst0nsm1th 7y ago
  It's specifically a macos issue. 32 bit softwares run naturally on 64 bit hardware on any platform, Windows, BSD, Linux, without any maintenance. It's just an Apple trick to force financial turnover for owner of 32 software. It's not that there softwares are not compatible anymore, it's MacOS which block artificially 32 bit software. It's for the same reason MacOS block sidecar for device older than 2016,even if they are capable to run sidecar in the first place.
  - chrisseaton 7y ago
    Your software doesn't run in isolation. It needs services of the operating system. Apple has to spend resources maintaining 32-bit software and consumers would rather they didn't do that.
    - virgilp 7y ago
      Poor Apple, that's certainly too onerous of a burden to put on their shoulders.
- repolfx 7y ago
  I would note Chris, given your insistence on all this, that your own project Graal is still shipping on Java 8 despite that being many years old. You're now working on moving to Java 11, which is itself already obsolete. Imagine if tomorrow nobody could download GraalVM anymore because OpenJDK 8 stopped working for some reason (yes I know it's bundled, this is just a metaphor). It could easily be said you had years to upgrade, so why so sluggish? Well, of course, there were actual features you wanted to ship during this time too, not just doing upgrade work, especially given that Java 9 and 10 maybe didn't deliver many compelling upgrades.
  - chrisseaton 7y ago
    Hmmm I take your point, but OpenJDK 8 is maintained. A better example is the obvious impending transition to ARM, which GraalVM is already preparing for.
    - repolfx 7y ago
      Sure, but so is Mojave. It'll be some years before Apple stops shipping security updates to older releases. Until then app vendors saying "don't upgrade macOS" is no different to Java developers saying "don't run this on Java 11 because it doesn't work yet" and we've seen plenty of that. In fact, I'm guessing the pain of losing Java 8 will be too much for many organisations after so many years of stability and 9/10/11 breaking so much (current Gradle doesn't even work on Java 13!). Maintaining 8 will be a good business for a long time.