5 ms·

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

by 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
      That’s a very loose definition of “correct code”. If you write out of bounds or occasionally read memory you didn’t allocate and how do you know you get away with it, so that you can declare the code “correct”? Your program may crash only once in a thousand years. In my book it still would be incorrect as soon as it breaks the interface contract of the API, even if it never crashed or misbehaved. Also, in your definition, you can’t complain if a program stops running after even a tiny OS upgrade it wasn’t “purposely built for”, for example because it that didn’t exist yet at the time the program was compiled.
- mort96 3y ago
  "The code happens to work" and "the code is correct" aren't synonymous. If my code contains a use-after-free, it might "happen to work" on the current version of an OS, but a small change to the memory allocator might break it. Hell, I could write code which "happens to work" because I use the OS's version number as the length of an array and the OS's version number happens to be the same as the number of items in the array.
- veidr 3y ago
  We don't know, since we don't have the code. Both are possible. Science knows I've written a shit-ton of incorrect code that accidentally worked until it suddenly didn't. OTOH if you make an OS and you break API contracts that you had in the past, that would reasonably be expected to continue working, it's your fault. Blame is a judgement call.
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.

by 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
    That’s a very loose definition of “correct code”. If you write out of bounds or occasionally read memory you didn’t allocate and how do you know you get away with it, so that you can declare the code “correct”? Your program may crash only once in a thousand years. In my book it still would be incorrect as soon as it breaks the interface contract of the API, even if it never crashed or misbehaved. Also, in your definition, you can’t complain if a program stops running after even a tiny OS upgrade it wasn’t “purposely built for”, for example because it that didn’t exist yet at the time the program was compiled.
mort96 3y ago
"The code happens to work" and "the code is correct" aren't synonymous. If my code contains a use-after-free, it might "happen to work" on the current version of an OS, but a small change to the memory allocator might break it. Hell, I could write code which "happens to work" because I use the OS's version number as the length of an array and the OS's version number happens to be the same as the number of items in the array.
veidr 3y ago
We don't know, since we don't have the code. Both are possible. Science knows I've written a shit-ton of incorrect code that accidentally worked until it suddenly didn't. OTOH if you make an OS and you break API contracts that you had in the past, that would reasonably be expected to continue working, it's your fault. Blame is a judgement call.

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.