▲ 88 points
back
76 comments
This is the kind of thing that puts me off the most about those complicated copy protection schemes.
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.
iLok, even when it was just a dongle-only protection, had a 100% chance of crashing and/or not working at all in any live setup I can think of. I learned the hard way about always exporting any stem of any track to lip-sync them as a last resort.
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.
You're totally right. In a studio, a bit of downtime or crashing is not good, but used to be just a "fact of life".
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.
The USB licensing dongles used in Cubase [1] were clunky and annoying, but were pretty effective. A lot easier to manage than Flex-LM, assuming you weren't roaming around too much.
> I also remember some scandal a couple decades ago with some plugin scanning your /etc/hosts file for their domains
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.
> … 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.
Wholeheartedly agree with you, but I want to check my own understanding, which is: iLok became this weird monopoly because it let all the makers of actual music software stop doing all this weird shit, right? Like hiding registration details on your computer, making hardware dongles, etc.
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.
There's also some companies that moved away from it. I think Waves, and all the companies in Plugin Alliance.
I try to "vote with my wallet" for those cases. Now I'd rather not have something that is cool but requires iLok.
yes, Cubase used a parallel port dongle in the 90s and then in the 2000s a not-iLok USB dongle called eLicenser. They have switched to software activation for their products since 2022.
> I’m not saying technical problems are inevitable or faulting developers. I’m saying there has to be a better way of handling this quality issues – both in how changes are made and how they’re communicated. Waiting for the system to fail on users’ systems – whoever is to blame, whatever the reason – is waiting until it’s too late.
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.
> 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 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.
Yeah, but iLok especially, but Mac music-production software as a whole always has the stench of death about it. Even the Intel->Apple CPU transition was awful, with many (super performance-intensive, latency-sensitive) audio software packages running on Rosetta for years... many years.
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.)
Note that by plug-in, they appear to be talking about plug-ins for professional audio and music production software specifically.
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.
> 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?
> 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".
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.
Is it similar to the JVM situation? The JVM situation is just a macOS bug.
What JVM situation are you referring to?
Plug-ins that use PACE / iLok protection. The irony is that the cracked versions probably are still working.
E.g. any photo editing stuff from DxO
I was recently downvoted for describing this exact situation, and yet, here we are. This is effectively gauaranteed to happen every single macOS release.
Another reason we are glad we didn't impose iLok on our customers.
Before iLok and USB, there were ADB dongles. You'd daisy chain each one and then add your normal ADB devices like your keyboard/mouse cable. The company I was at would rent out it's Avid bays at night to freelancers and students. They would have to unplug the ADB cable to add/remove any dongles they needed for their work. For those unfamiliar with ADB cables, the pins were not the sturdiest. It was also very similar to the SVideo port common on Macs at the time. I found this out when I came in one morning to start prepping for a session when the keyboard/mouse didn't work. After checking the cable, I noticed the dongles were in a different order on the ADB cable. Turns out, one of the overnight users had attempted to plug the ADB chain into the SVideo and bent one of the pins on the Avid dongle. Removing the dongle allowed the computer to function, but no Avid and a client was due in 30 minutes. Dongle replacements were not something just available at the local store. It took lots of phone calls and a week's down time. Yeah, I hate physical DRM in any form whatsoever. </rant>
Title should say Audio Unit or AU plugins for clarity.
The accompanying Safari update seems to have re-broken the GitHub IDE as well – trying to select text is "off" by a few lines. This was pretty annoying when it was broken previously and I was glad for the fix in 13 – oh well...
Is this related to the same issue reported with the JVM crashing on the same update?
Hard to tell if it's exactly the same, but audio plugin and DAW manufacturers warning people to upgrade to the latest macOS version because of incompatibilities is a common sight, it happens with every major macOS version at the very least. Sometimes also with minor versions, like in this case.
Has macOS been this bad in updating, or is this something of recent times?
14.2 was also a disaster for me.
it's getting worse and worse with apple software quality - the latest Xcode is so broken and they haven't fixed it properly since release in september[0] - I have to turn off VPN both on mobile and desktop and turn off wifi on iphone to force deploying debug apps via cable...
Broken or broken in your use case? I recently left corporate development for the start up life. As I recall we had to disable our VPN for the majority of development use cases, from package management (gradle), robotics comms, all the way down to running third party unsigned software (I received a stern email from security for downloading Apple’s OpenAPI package).
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.
It’s always been like this. Updates are just times a bunch of stuff on you pro device stops working randomly or differently.
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…”
Clearly implemented by non-European developers: <https://en.wikipedia.org/w/index.php?title=Finger-counting&o...>
> Oh hey you now get a thumbs up bubble appear on your video call if you start counting with you thumb.
That's something Zoom implemented ages ago. Out of interest, which client are you talking about?
High Sierra broke FAT32 files over 2GB which was similar levels of fun.
I used to work on some professional software that shipped a macOS version. macOS updates were, and I suspect still are, awful, and it's Apple's fault. Every single update we would beg our users to please, please, please, hold off on updating until we put out an update. Users would always rag on us on the forums because they assumed we were just sloppy and "why doesn't Windows have this problem".
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.
I'd really like to have some specific example, because while apple never kept much backward compatibility, I've not eared of or being impacted much by supported API changes when used in intended ways.
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.
The beta period is at least a month long and Xcode shows you deprecation warnings years ahead on this stuff. I get that there are corner case bugs that might happen once every few years but if this is happening 'every single release' your users are right.
I'm an old dinosaur of a developer but I do remember enough XCode to know that it would throw enough warnings when API calls were going to be deprecated. And you could ignore those warnings and ship your binary. But eventually those warnings come true and your binary won't work in later OS releases.
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.
> Every single update we would beg our users to please, please, please, hold off on updating until we put out an update.
This order of operations is wrong.
If only there was a way for all these customers to test their software on upcoming versions of MacOS before it releases...
Per: https://blogs.oracle.com/java/post/java-on-macos-14-4
"The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update."
thanks for the heads up, will stay with Monterey.
what a bizarre site.
IMO cdm is a great resource for musicians. I have been reading it for close to a decade and have found many cool tools and learned a lot from it. I particularly like the DAW update summaries.
CDM is a very standard audio industry blog
What's bizarre about it?