4 ms·

Note that by plug-in, they appear to be talking about plug-ins for professional audio and music production software specifically.

bmitc 3y ago
I was recently downvoted for describing this exact situation, and yet, here we are. This is effectively gauaranteed to happen every single macOS release.
galad87 3y ago
Plug-ins that use PACE / iLok protection. The irony is that the cracked versions probably are still working.
- inferiorhuman 3y ago
  E.g. any photo editing stuff from DxO
  - diggan 3y ago
    And a ton of professional audio tools. From the top of my head: Avid/Pro Tools, Waves, iZotope, Eventide, Lexicon, Softube, and I'm sure a lot of others.
- deleted 3y ago
  [deleted]
bzzzt 3y ago
It's an issue for plugins 'protected' by the iLok DRM system. It's probably not macOS, but incorrect code that accidentally worked in the past. Seems similar to the JVM situation.
- SpaghettiCthulu 3y ago
  What JVM situation are you referring to?
  - Mashimo 3y ago
    Probably this: https://news.ycombinator.com/item?id=39741115 https://news.ycombinator.com/item?id=39741115 Some say it's a POSIX valid thing to do.
- diggan 3y ago
  > It's probably not macOS, but incorrect code that accidentally worked in the past Well, it was correct code, as it was working, and after a macOS update, the code that used to be correct, is no longer correct. But it's not the fault of macOS, but the people who produced the code?
  - dylan604 3y ago
    Yes -- Tim Apple
  - jackcviers3 3y ago
    It's not a bug. It's a feature.
  - Someone 3y ago
    > Well, it was correct code, as it was working, I haven’t checked this case, but that’s not valid logic in general. For example, code that writes out of bounds data can be ‘working’, yet read from or write to unallocated memory, but then break when a new OS release changes the memory allocator or changes the size of some allocations. Another example are broken checks for features. If, instead of checking whether the OS or CPU supports feature ‘foo’, you check for ‘version ≥ magic_number’, assuming every OS/CPU will after that will support the feature, your program code can stop working when that assumption turns out to be incorrect. The code was broken all the time, though.
    - diggan 3y ago
      Both those cases sound like code that was correct at the time of writing, with the assumptions at the time in mind. Which turned into incorrect code when the environment changed, but that doesn't mean the code itself wasn't correct at the time, for the intended environment. I guess I'd reserve "broken code" for code that doesn't work at all, I wouldn't use it to describe code that worked in one environment but not in another, unless purposefully built for the second of course.
      - Someone 3y ago
- subtra3t 3y ago
  > Seems similar to the JVM situation Oracle was relying on behaviour that was POSIX valid so I don't see how it is "incorrect code".
  - jjtheblunt 3y ago
    Where did you get that it’s posix valid? Like link to posix spec? Or hearsay? I know what you mean but haven’t found such. (SIGTERM is catchable though so it does seem a bug/overkill sending SIGKILL instead of SIGSEGV or even SIGTERM.)
    - subtra3t 3y ago
      Good catch. I haven't found a proper source other than a quotation from some HN comment, so I'm not sure if it actually is POSIX valid or not, just that many people seem to think it is.
  - bzzzt 3y ago
    Depends. Does Apple promise POSIX compliance for current macOS?
    - lxgr 3y ago
      I’m pretty sure they do, given that macOS is even still a Certified UNIX(tm).
- tumult 3y ago
  There are issues for ones that don't use iLok or any bad DRM system at all. Kilohearts plugins, for example. 14.4 is bad, Apple makes it harder and harder to not have your computer updated (including forcing major OS upgrades on users back in January and bypassing password authentication to do it, linked to multiple times here) and their software quality is not so good these days.
- gkbrk 3y ago
  Is it similar to the JVM situation? The JVM situation is just a macOS bug.
jahnu 3y ago
Another reason we are glad we didn't impose iLok on our customers.

bmitc 3y ago

I was recently downvoted for describing this exact situation, and yet, here we are. This is effectively gauaranteed to happen every single macOS release.

galad87 3y ago

Plug-ins that use PACE / iLok protection. The irony is that the cracked versions probably are still working.

inferiorhuman 3y ago
E.g. any photo editing stuff from DxO
- diggan 3y ago
  And a ton of professional audio tools. From the top of my head: Avid/Pro Tools, Waves, iZotope, Eventide, Lexicon, Softube, and I'm sure a lot of others.
deleted 3y ago
[deleted]

bzzzt 3y ago

It's an issue for plugins 'protected' by the iLok DRM system. It's probably not macOS, but incorrect code that accidentally worked in the past. Seems similar to the JVM situation.

SpaghettiCthulu 3y ago
What JVM situation are you referring to?
- Mashimo 3y ago
  Probably this: https://news.ycombinator.com/item?id=39741115 https://news.ycombinator.com/item?id=39741115 Some say it's a POSIX valid thing to do.
diggan 3y ago
> It's probably not macOS, but incorrect code that accidentally worked in the past Well, it was correct code, as it was working, and after a macOS update, the code that used to be correct, is no longer correct. But it's not the fault of macOS, but the people who produced the code?
- dylan604 3y ago
  Yes -- Tim Apple
- jackcviers3 3y ago
  It's not a bug. It's a feature.
- Someone 3y ago
  > Well, it was correct code, as it was working, I haven’t checked this case, but that’s not valid logic in general. For example, code that writes out of bounds data can be ‘working’, yet read from or write to unallocated memory, but then break when a new OS release changes the memory allocator or changes the size of some allocations. Another example are broken checks for features. If, instead of checking whether the OS or CPU supports feature ‘foo’, you check for ‘version ≥ magic_number’, assuming every OS/CPU will after that will support the feature, your program code can stop working when that assumption turns out to be incorrect. The code was broken all the time, though.
  - diggan 3y ago
    Both those cases sound like code that was correct at the time of writing, with the assumptions at the time in mind. Which turned into incorrect code when the environment changed, but that doesn't mean the code itself wasn't correct at the time, for the intended environment. I guess I'd reserve "broken code" for code that doesn't work at all, I wouldn't use it to describe code that worked in one environment but not in another, unless purposefully built for the second of course.
    - Someone 3y ago
subtra3t 3y ago
> Seems similar to the JVM situation Oracle was relying on behaviour that was POSIX valid so I don't see how it is "incorrect code".
- jjtheblunt 3y ago
  Where did you get that it’s posix valid? Like link to posix spec? Or hearsay? I know what you mean but haven’t found such. (SIGTERM is catchable though so it does seem a bug/overkill sending SIGKILL instead of SIGSEGV or even SIGTERM.)
  - subtra3t 3y ago
    Good catch. I haven't found a proper source other than a quotation from some HN comment, so I'm not sure if it actually is POSIX valid or not, just that many people seem to think it is.
- bzzzt 3y ago
  Depends. Does Apple promise POSIX compliance for current macOS?
  - lxgr 3y ago
    I’m pretty sure they do, given that macOS is even still a Certified UNIX(tm).
tumult 3y ago
There are issues for ones that don't use iLok or any bad DRM system at all. Kilohearts plugins, for example. 14.4 is bad, Apple makes it harder and harder to not have your computer updated (including forcing major OS upgrades on users back in January and bypassing password authentication to do it, linked to multiple times here) and their software quality is not so good these days.
gkbrk 3y ago
Is it similar to the JVM situation? The JVM situation is just a macOS bug.

jahnu 3y ago

Another reason we are glad we didn't impose iLok on our customers.