Don't upgrade to macOS Sonoma 14.4 yet: plug-in compatibility issues
cdm.link
cdm.link
They always rely on kernel extensions, undocumented functionality and hiding a lot of stuff in your hard drive, in locations that are often in your (and Apple's) interest to protect, or even to routinely clean.
I also remember some scandal a couple decades ago with some plugin scanning your /etc/hosts file for their domains. I'm pretty sure there's more egregious stuff going on.
I swore off iLok about a decade ago when I had to go into a studio and couldn't get the goddamn thing to authorise anything and had to spend a few hours in support. On my local machine I could just buy stuff then immediately pirate it for stability, but on a studio that was not possible.
I'm ok with other people using, but I'm tired of those software makers treating my computer as if it was their playground.
Even to this day I've kept the habit of doing any production or live stuff on a dedicated, offline-only box, and treat it as if it were an analog synth or dsp.
Live? Different matter altogether.
I never did sound live professionally, but I still perform. I don't even have third-party plugins in Mainstage anymore.
Given that this used to be enough to prevent Adobe CS5 and CS6 from phoning back home and detecting you used a keygen, some sort of "sanity check" against the license server endpoint IPs does make sense.
No it doesn’t. If you want to verify the response from a given endpoint, cryptographically sign the response and verify the signature. TLS + hostname verification for the license server is pretty close too (with the proviso that you’re trusting the CA cabal to not let someone else spoof you).
There’s no world where it’s okay for software or even hardware to mess with networking or DNS.
And keep in mind that usually, the user has ultimate control over the "CA cabal". Since the user is the antagonist in the world of DRM, relying only on HTTPS might not be the best idea.
But then again, the whole effort of preventing the user from doing what they want on hardware and an OS they have total control over might not be the best idea in general.
Back in the ... 1990s, I think? It was like Cubase had their dongle, Studio Vision had... I forget, but something... but eventually they just mostly all went iLok. I dabble in music computer stuff for fun, and I feel like outside of Linux, it has been 15 years or so that it is basically just de facto all-iLok. Even though I am buying from like 10 or more companies.
I feel like we are now to the "inevitable result" part of any company gaining that kind of monopoly.
I try to "vote with my wallet" for those cases. Now I'd rather not have something that is cool but requires iLok.
The better way is a long public developer release cycle. The folks doing weirdness like blocking things from working (plug-in DRM) should have released updates long before this.
I've never understood the "no, we don't update until after OS-maker releases to the public, please delay updating until every third party dev in your stack gets around to it depending on the volume of complaints", versus shipping stack component updates during the dev releases, so that when RC and general releases come out, it's all good.
Well, I understand it. One of these requires funding proactive and preemptive continuous maintenance. The other is easier in a budget allocation battle: "users are broken, my team needs money to fix it."
So I'm not faulting developers either, I'm faulting the tech maintenance and expense culture of the firm where the developers work.
I use beta cycles on MacOS and 14.4 was released to devs in early February, so they've had 1-2 months roughly to detect and address this. And contact Apple if there was a major issue (audio professionals are a big business for Apple).
Everything I've seen about iLok...and plenty of other older VST/music companies... have a strong gleen of software teams that are either budget-tier or extremely behind the times. The UIs are the worst, often 10yrs out of date. I suspect partially because they do lazy cross-platform stuff.
iLok is, I think, an accidental monopolist like Adobe Flash in the era just before Steve's famous Thoughts on Flash. Terrible product, content to milk it to the end, no intention or capability of fixing it.
I have a couple iLok USB sticks (that are like $75) and the only purpose of them is so my music shit (from various vendors) keeps working when iLok servers are down.
But the flip side of this is this: I am just a hobbyist with no professional use of this stuff — I just love having all these (simulations/emulations of) retro guitar amps and various effectors and mixing consoles that to my (non-pro, non-audiophile) ear sound indistinguishable from the real thing, and would have cost a couple million dollars back in the 1990s.
But even in my case, the dollar value of this stuff is a lot more than the Mac I run it on. So most of the time, I've had a dedicated Mac for music, and another one for work and/or life.
Because historically, these music companies need more like 1-2 years, not months, to update their shit. (If they do at all; quite a lot of the music plugins and apps never make the transition — whether that is PPC to Intel, 32-bit to 64-bit, Intel to ARM, old kernel extensions to new blehpmpphblewhatev, pre-SIP to SIP, and so on and so on...)
For professional use (music studios, etc) waiting to upgrade isn't that insane — the music software is the main thing, and the OS version is a secondary concern.
(I wish it were otherwise.)
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?
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.
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.
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.
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.
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.
Oracle was relying on behaviour that was POSIX valid so I don't see how it is "incorrect code".
Some say it's a POSIX valid thing to do.
14.2 was also a disaster for me.
Our security chain was so deeply embedded in every part of the OS that I was constantly trying to figure out where the failures and slow downs were coming from.
Oh hey you now get a thumbs up bubble appear on your video call if you start counting with you thumb.
“ <thumbs-up> things you need to improve as a developer…”
That's something Zoom implemented ages ago. Out of interest, which client are you talking about?
Great, just what I needed built into my OS.
Because Microsoft doesn't subtly change the behavior of half a dozen APIs every release without warning anyone, that's why. Don't get me wrong, I despise MS, but as a developer, at least they've got that going for them.
Yes I know that's not the specific issue here, but I promise you my old company is still dealing with this problem every single release.
The actual thing you can praise MS for is to respect the «all observable behaviors» in their backward compatibility or support. Apple never ever gave in that way, only that you are supposed to use things as expected or expect to be punished. Not that they have stellar track records on that front either, there are tons of old code that still work out there.
Why that customer was using TGA images in their workflow in the 2010s I'll never know.
Every single release may have been an exaggeration, but I was at the company three years and saw this happen more than once.
Microsoft was a dream to work with. They more or less made sure old API calls continued to work long after they stopped developing it. Usually just some wrapper code in their libraries to manage it automagically.
Part of it I feel is Apple is quick to cut insecure APIs while Microsoft will let them linger for a while and try and patch them.
I've been a Mac user for decades but Sonoma is the 1st major release I can remember where everything is going to shit, even 9.x -> OSX wasn't this bad.
This order of operations is wrong.
"The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update."
Audio plugins have a history of ignoring announced changes, and months of betas, and then getting surprised on release day when their plugins just don't work.
I'm currently tracking these 3 for our staff:
https://appleinsider.com/articles/24/03/14/the-macos-sonoma-...
https://appleinsider.com/articles/24/03/16/oracle-advises-us...
https://appleinsider.com/articles/24/03/12/latest-macos-sono...