3 ms·

“Short timeline” assumes you didn’t see 64-bit coming a couple of years ago. Not saying it isn’t work, just that “I didn’t see it coming” isn’t much of an excu

“Short timeline” assumes you didn’t see 64-bit coming a couple of years ago. Not saying it isn’t work, just that “I didn’t see it coming” isn’t much of an excuse.

holy_city 7y ago
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.
13415 7y ago
It's not just 64-bit though. There are also some fake-security "notarization" requirements that were notoriously vague and poorly documented for months, as well as some equally vague and unspecific threats that certain non-notarized applications might or might not cease to work on January 2020. I've been developing for Macs since the late 90s and have never seen less clear developer info. See the discussion here - and notice how confusing and contradicting the opinions about it are: https://news.ycombinator.com/item?id=21179970 https://news.ycombinator.com/item?id=21179970
pier25 7y ago
> “Short timeline” assumes you didn’t see 64-bit coming a couple of years ago. Or that you haven't had the resources to spend on it
- chrisseaton 7y ago
  If you think the price of updating for 64-bit is expensive, you should see the price of not updating and not being able to run your software at all.
  - pier25 7y ago
    Thankfully I'm not in that position, but many companies can barely keep up with their day to day stuff. There is never time for doing something for the distant (or not so distant) future.
w1nst0nsm1th 7y ago
32 bit softwares run on 64 bit hardware. Period. It doesn't require maintenace on any platform, neither BSD, Linux or Windows. Depreciating 32 bit software is just an Apple trick to force financial turnover. It's the same reason why the deactivated sidecar for macbook older than 2016.
- jamienicol 7y ago
  It's a very odd trick given that Catalina still supports my 7 year old macbook pro. Why not force me to upgrade sooner if it's all about the money? Not saying I agree with apple's decision, but it's surely it's just about reducing their own engineering costs.
  - RantyDave 7y ago
    I think sidecar uses h265 so it's probably a question of the GPU either having dedicated h265 hardware or having enough grunt to run some kind of shader.

“Short timeline” assumes you didn’t see 64-bit coming a couple of years ago. Not saying it isn’t work, just that “I didn’t see it coming” isn’t much of an excuse.

holy_city 7y ago

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.

13415 7y ago

It's not just 64-bit though. There are also some fake-security "notarization" requirements that were notoriously vague and poorly documented for months, as well as some equally vague and unspecific threats that certain non-notarized applications might or might not cease to work on January 2020. I've been developing for Macs since the late 90s and have never seen less clear developer info. See the discussion here - and notice how confusing and contradicting the opinions about it are: https://news.ycombinator.com/item?id=21179970 https://news.ycombinator.com/item?id=21179970

pier25 7y ago

> “Short timeline” assumes you didn’t see 64-bit coming a couple of years ago. Or that you haven't had the resources to spend on it

chrisseaton 7y ago
If you think the price of updating for 64-bit is expensive, you should see the price of not updating and not being able to run your software at all.
- pier25 7y ago
  Thankfully I'm not in that position, but many companies can barely keep up with their day to day stuff. There is never time for doing something for the distant (or not so distant) future.

w1nst0nsm1th 7y ago

32 bit softwares run on 64 bit hardware. Period. It doesn't require maintenace on any platform, neither BSD, Linux or Windows. Depreciating 32 bit software is just an Apple trick to force financial turnover. It's the same reason why the deactivated sidecar for macbook older than 2016.

jamienicol 7y ago
It's a very odd trick given that Catalina still supports my 7 year old macbook pro. Why not force me to upgrade sooner if it's all about the money? Not saying I agree with apple's decision, but it's surely it's just about reducing their own engineering costs.
- RantyDave 7y ago
  I think sidecar uses h265 so it's probably a question of the GPU either having dedicated h265 hardware or having enough grunt to run some kind of shader.