5 ms·

macOS is getting more locked down in time to the point of being iOS with a keyboard. This makes a lot of developer tools hard to use, eg. debuggers don't work a

macOS is getting more locked down in time to the point of being iOS with a keyboard. This makes a lot of developer tools hard to use, eg. debuggers don't work anymore https://jdk.java.net/macos/ https://jdk.java.net/macos/ So, software changes alone require quite some upkeep on your existing tooling otherwise you run into problems. Now imagine a whole new CPU architecture which means none of your tools work unless they are a) recompiled or b) virtualised. I expect the pain of virtualisation and the problems with that to make the whole experience miserable. And many tools will either never be recompiled or take so much time you are forever stuck in pleistocene times. I remember, ahem, fondly when Apple dropped Java and we had to wait forever to be able to work with modern versions on OS X. At some point Landon Fuller stepped in and hand-made a Java 6 build. Catalina is also quite famous in my circles as something to avoid. And the notarization requirements for macOS tools that are not on the macOS AppStore is also something that has been wasting some of my time (and the $99 for Apple, of course). So, all in all, I don't see how ARM Macs combines with the Catalina successor and even more stringent Apple rules are going to make a good developer workstation.

saagarjha 7y ago
You may download a version of Java lacking notarization if you'd like to debug it.
- fierarul 7y ago
  I'm doing http://www.openbeans.org http://www.openbeans.org which is an IDE supporting Java among other programming languages. It's made in Java too. So, I need to distribute a notarized build that also provides a JDK for users. My users would naturally want to debug their own code using the provided JDK. So either we just forget about notarization on developer tools and we just tell people to disable everything or Apple has to figure out some better way. I already see they apply the notarization rules differently so perhaps if you get your tool on the "internal Apple tools whitelist" it's easier. I programmed on Macs since the G4 days but I will not be upgrading the current software or hardware given the current trend. Just switch to a nice Thinkpad running Linux (or a BSD if I feel adventurous).
  - saagarjha 7y ago
    You can debug Java code without running into this issue; the problem is when you try to debug the JVM itself.
    - fierarul 7y ago
      I'm not quite certain what this means. So, if my JVM forks another JVM that will debug just fine? Or even that won't work as in I won't be able to add a breakpoint inside some standard Java class?
      - saagarjha 7y ago
        You won't be able to set a breakpoint inside native code: the JVM itself, and any JNI libraries it loads (assuming they too are signed the same way) are off limits. But setting a breakpoint in a Java class should be fine, because that inside the virtual machine and doesn't require special entitlements.
        fierarul 7y ago
        Thank you. This was quite illuminating.
  - Wowfunhappy 7y ago
    > So either we just forget about notarization on developer tools and we just tell people to disable everything or Apple has to figure out some better way. What would be a better way? A computer either is or is not allowed to execute non-Apple approved code. If you want your computer to execute non-approved code, then let it do that by disabling Gatekeeper.
Wowfunhappy 7y ago
> This makes a lot of developer tools hard to use, eg. debuggers don't work anymore https://jdk.java.net/macos/ https://jdk.java.net/macos/ They don’t work in notarized apps, and only notarized apps are allowed through Gatekeeper. But if you’re a developer who needs advanced debugging capabilities, you can let the non-notarized app through Gatekeeper and continue on your way. But maybe you're a hardware developer and need to debug the kernel, or replace the kernel entirely with a self-compiled version of Darwin. Macs let you do all of that too, just turn off SIP and the system is yours to command. What Apple has done with macOS is lock down the experience by default so your average technophobe doesn’t ruin their system. If you’re a programmer or power user who wants or needs a less restricted environment, macOS can still be that platform. I think it's a healthy balance.
- lonelappde 7y ago
  > your average Grandmother Please don't do this. Use a perfectly adequate and more correct term "layperson". My grandsons are equally capable of ruining their system with trojans and misapplied hacks
  - Wowfunhappy 7y ago
    Thanks, you're completely right! I've edited.
DenisM 7y ago
> I expect the pain of virtualisation and the problems with that to make the whole experience miserable. They did it twice for mac os - m68k->PPC->X86 and came out alright. Also transitioned two generations of ARM (current CPUs no longer support 32bit).
- mattl 7y ago
  And let's not forget that OPENSTEP happily ran apps that were compiled to work on 68k, 486, PA-RISC and SPARC.

saagarjha 7y ago

You may download a version of Java lacking notarization if you'd like to debug it.

fierarul 7y ago
I'm doing http://www.openbeans.org http://www.openbeans.org which is an IDE supporting Java among other programming languages. It's made in Java too. So, I need to distribute a notarized build that also provides a JDK for users. My users would naturally want to debug their own code using the provided JDK. So either we just forget about notarization on developer tools and we just tell people to disable everything or Apple has to figure out some better way. I already see they apply the notarization rules differently so perhaps if you get your tool on the "internal Apple tools whitelist" it's easier. I programmed on Macs since the G4 days but I will not be upgrading the current software or hardware given the current trend. Just switch to a nice Thinkpad running Linux (or a BSD if I feel adventurous).
- saagarjha 7y ago
  You can debug Java code without running into this issue; the problem is when you try to debug the JVM itself.
  - fierarul 7y ago
    I'm not quite certain what this means. So, if my JVM forks another JVM that will debug just fine? Or even that won't work as in I won't be able to add a breakpoint inside some standard Java class?
    - saagarjha 7y ago
      You won't be able to set a breakpoint inside native code: the JVM itself, and any JNI libraries it loads (assuming they too are signed the same way) are off limits. But setting a breakpoint in a Java class should be fine, because that inside the virtual machine and doesn't require special entitlements.
      - fierarul 7y ago
        Thank you. This was quite illuminating.
- Wowfunhappy 7y ago
  > So either we just forget about notarization on developer tools and we just tell people to disable everything or Apple has to figure out some better way. What would be a better way? A computer either is or is not allowed to execute non-Apple approved code. If you want your computer to execute non-approved code, then let it do that by disabling Gatekeeper.

Wowfunhappy 7y ago

> This makes a lot of developer tools hard to use, eg. debuggers don't work anymore https://jdk.java.net/macos/ https://jdk.java.net/macos/ They don’t work in notarized apps, and only notarized apps are allowed through Gatekeeper. But if you’re a developer who needs advanced debugging capabilities, you can let the non-notarized app through Gatekeeper and continue on your way. But maybe you're a hardware developer and need to debug the kernel, or replace the kernel entirely with a self-compiled version of Darwin. Macs let you do all of that too, just turn off SIP and the system is yours to command. What Apple has done with macOS is lock down the experience by default so your average technophobe doesn’t ruin their system. If you’re a programmer or power user who wants or needs a less restricted environment, macOS can still be that platform. I think it's a healthy balance.

lonelappde 7y ago
> your average Grandmother Please don't do this. Use a perfectly adequate and more correct term "layperson". My grandsons are equally capable of ruining their system with trojans and misapplied hacks
- Wowfunhappy 7y ago
  Thanks, you're completely right! I've edited.

DenisM 7y ago

> I expect the pain of virtualisation and the problems with that to make the whole experience miserable. They did it twice for mac os - m68k->PPC->X86 and came out alright. Also transitioned two generations of ARM (current CPUs no longer support 32bit).

mattl 7y ago
And let's not forget that OPENSTEP happily ran apps that were compiled to work on 68k, 486, PA-RISC and SPARC.