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.
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.
> with the proviso that you’re trusting the CA cabal to not let someone else spoof you
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.
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.
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.
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?
"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.
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.
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.
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.
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.
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.)
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.
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.
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.
I was recently downvoted for describing this exact situation, and yet, here we are. This is effectively gauaranteed to happen every single macOS release.
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>
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...
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.
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.
that issue I linked to apple developer forums has 37k thumbs up so I guess the issue is widespread - when reading the conversation a lot of pissed people me included how they handled it.
It is built into macOS now, if you start using your camera, you can click the camera-icon in the top bar for more spectacular options. Link to the support page: https://support.apple.com/en-us/105117
... and here I wonder why video chats make my CPU usage go brrrrrr. Fuck hell no, I'd like to have an opt-out after an OS update that disables everything that can negatively impact performance.
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 specific example I remember (because I'm the one that fixed it) had something to do with how Image I/O handled TGA images. I don't remember all the details, but it was definitely not the case that we were misusing the API. Per the documentation everything had been above board, and everything was still above board. The images causing the issue were well-formed. Just something subtly changed with the CGImageSource API for TGA images specifically that required finding a workaround.
Why that customer was using TGA images in their workflow in the 2010s I'll never know.
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.
This situation is different. This isn't about some deprecated API, but Apple changing the behaviour of the API, with no prior warning. Even the beta releases of 14.4 didn't implement this change, so no third parties actually got a chance to detect this. It's a really bad situation.
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.
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'd be willing to give them the benefit of the doubt in this instance, as 14.4 seems to be a duff release. Haven't seen this many major issues since High Sierra.
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.
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.