It's probably due to the Electron bug[1]. A lot of common apps haven't patched up yet.
I also have an M2 Pro with 32GB of memory. When I A/B test with Electron apps running vs without, the lag disappears when all the unpatched Electron apps are closed out.
> It's probably due to the Electron bug[1].
> When I A/B test with Electron apps running vs without, the lag disappears when all the unpatched Electron apps are closed out.
Look, if userspace apps can break system functionality, to the level that simple mouse cursor is not responsive, it suggests that there is something fundamental broken in the OS.
Yes, everyone should blame and shame Electron, but here the bug is firmly in the OS.
If it is accessible from userspace it is by no means private.
Does it mean the API is private in the sense of "unstable" interface? It could very well break the userspace app relying on undocumented behavior, however, crucially here, anything that is exposed to userland WILL at some point be used by some application, be it legitimate or malicious, and it should not break the OS in any way. That's basic hygiene, not even security.
inb4: yes, userspace app could trigger e.g. millions of io operations and millions of number crunching threads and thus cripple the rest of userspace (or at least the rest of userspace at given priority level), yet the system part should still run within performance envelope. Insert "Task Manager (Not Responding)" meme.
It’s not in a public header. You can easily snoop “private” properties and methods quite easily in Objective-C, because the concept doesn’t exist. It doesn’t exist in C either, but if you roll up your sleeves and figure out the memory layout and offsets, you can do whatever.
> if you roll up your sleeves and figure out the memory layout and offsets, you can do whatever.
So we are talking about public/private access specifiers in source code, which only matter in cooperative setting. But that's IMO highly naive view as compute, especially OS, is objectively an adversarial environment. Some actors, at some point WILL figure out the memory layout and use that in an attack. There have been literally decades of whack-a-mole against bad actors.
I maintain my stance that any fields/members/methods loaded into a userspace program should not be capable of breaking the system.
People using private APIs know that they might cause instability (in their apps usually). That's why those APIs are private, they can change since there are no guarantees.
I'd point fingers towards the electron core devs for this one, and not devs building apps on top of electron (since they likely didn't know that's how electron was doing it).
There are cases where OS companies noticed the use of private APIs and made cleaner public ones (the most obvious was the file system syncing stuff used by Dropbox and others, which used to use private APIs until Apple provided a public one).
If you can call it, it's not private, it's that simple. Putting a "please don't call this" on is just naïve. Even in legal matters, it's already the case that laws that aren't enforced are worthless, cf. driving 5-10 mph over the speed limit being normal. It won't work any better on a weak statement on an API.
And either way, applications shouldn't be able to break the system like this. You can reasonably expect error handling to catch this, even if the error is "a private API was called".
This is on Apple. 90% at least. Maybe 10% on Electron.
If I can walk on land that says private property, it's not private. I'll remember to use that argument when I get ticketed for trespassing.
There are APIs that are explicitly declared verboten for third-parties to use because they aren't intended for outside use. That doesn't make them magically inaccessible, but it does mean that when their unanticipated use breaks things, that's on the people who ignored the warnings.
I agree that this shouldn't be able to have the huge impact that it does and that Apple ought to have made their OS more resilient, but your logic is weak.
> Even in legal matters, it's already the case that laws that aren't enforced are worthless, cf. driving 5-10 mph over the speed limit being normal.
Just because all but one cop of the force ignore people driving over the speed limit doesn't mean the one who pulls you over is isn't able to write you a speeding ticket. Try that with a judge. It might work, but the law is very much still enforceable. This isn't like failing to protect a trademark.
> If I can walk on land that says private property, it's not private. I'll remember to use that argument when I get ticketed for trespassing.
Dude. Dudette. Duderino. Did you think this through before you hit post? I'm talking about enforcement. If you're getting a ticket, it's literally being enforced. And if it isn't, you get squatters! Thanks for the point in support, I guess?
I think this is the most braindead knee-jerk HN comment I've ever gotten as a reply, congratulations.
[Ed.: god, please, this genuinely hurts my brain.]
> but it does mean that when their unanticipated use breaks things, that's on the people who ignored the warnings.
Yeah. When it breaks things for them. Not when it breaks the entire OS' UI.
Let's stay with your analogy. Things change, Electron apps break? That's analog to finally getting around to calling the cops on squatters after dozing on it. Things change, your UI goes belly up due to Electron? That's you deciding to pay the bill for electricity and indoor plumbing for the squatters. No, wait, even better: you decided you finally want to build a new house on your plot, and now have to deal with getting the squatters out first. It'll happen, but you'll have to unnecessarily sink time and money into that. Apple's dealing with evicting Electron off their private APIs. What a nice analogy.
Of course the squatters are technically wrong. But why did you leave your front door open, and neglected and didn't check in for years? The part where you're making it hard for yourself is on you, mate. You're not going to get your lost time back. Why didn't you grab a lock at home depot?
> Just because all but one cop of the force ignore people driving over the speed limit
This is generally policy, not individual cops' discretion.
Indeed that Mastodon post refers to the sibling to yours. I genuinely can't bear the contradiction. My reply below is as polite as I could manage; on Mastodon there is no point in attempting to restrain my bafflement :)
Yeah, of course they shouldn’t, but they do. Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down. DDoS for example. It’s not a solved problem.
Wax idealistic all you want, but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one. “No userland APIs, private or otherwise, should be able to crash your app!!!” Is the argument I would be responding to right now.
> Kick off a bunch of processes doing too much of the wrong thing on any platform and it will bring the whole system down.
> > userspace app could trigger <...> and thus cripple the rest of userspace (or at least the rest of userspace at given priority level), yet the system part should still run within performance envelope
If userspace triggers what is an effectively a DoS attack and you cannot login to root terminal and get things sorted out that's a system not designed for adversarial userspace.
> but just imagine the discussion we’d be having if Apple had sigabort-ed all these misbehaving electron apps on day one
A more general context we are discussing here is resource exhaustion. There are myriads of scenarios where userspace can cause some form of resource exhaustion. My argument is that a 1) well designed 2) general use system should implement resource management in a way (e.g. priority queues) that userspace-inflicted resource exhaustion does not affect performance envelope of the system itself. Otherwise the system is open to unprivileged DoS attacks with only recourse being power cycling.
If your userspace app overcommits memory to some monstrous degree, what should the system do?
1. Enter a swap feedback, crippling the system down to unusability.
2. OOM-kill a process based on some heuristics.
3. freeze userspace, leaving privileged space functional.
I think you’re losing me. This is all completely tangential to the current discussion, bordering on non-sequitur. I don’t know why you chose to latch onto my loose quip of “bring the whole system down”, because that’s not what is happening here. I thought you knew that.
The OS got a little slower, that’s it. It was never in some unrecoverable state. One could soft close the offending processes at anytime and regain the lost perf. I’m willing to bet you could hide or minimize the window to mitigate the issue, because the bug is very specific to the layout and render run loop, which auto-pauses on lost visibility by default.
That said, I haven’t even noticed the slowdown on my work machine, but I only use Teams. it’s always been dog shit slow, just par for the course.
I can think of multiple ways to pass the message to Electron developers:
- Open a GitHub issue explaining those private APIs shouldn't be used.
- Even better, open a PR fixing their use.
- Make those API calls a no-op if they come from an Electron app.
- Fix those API calls not to grind the OS to a halt for a seemingly simple visual effect.
- Create a public API allowing the same visual effect on a tested and documented API.
Choosing to (apparently violently) downgrade the user experience of all Electron app users, without a possibility to update at the launch day, if a deliberate decision and not an overlooked bug, is a rather shitty and user-hostile move, don't you think?
> - Make those API calls a no-op if they come from an Electron app.
Long-term, this is a maintenance nightmare. These hacks can stick around for decades, because there's no backpressure on downstream to actually fix things. It's not about "team velocity", it's about keeping yourself sane.
> - Open a GitHub issue explaining those private APIs shouldn't be used.
> - Even better, open a PR fixing their use.
Apple has a history/culture of secrecy. Whenever they provide public source code, it's a dump thrown over the fence. There is most likely some team inside that actually cares, but they can't "just" open an issue. My guess is that this is their message.
> [...] is a rather shitty and user-hostile move, don't you think?
Yes, I agree, the general direction they've been taking has been increasingly user-hostile for a very long time; let alone the developer story.
But sometimes there's also a perfectly reasonable excuse, from both "technical" and "organizational" POV. That's just my take, a skunkworks effort to get Electron to fix their crap. I would do the same.
To be clear, Electron themselves fixed the bug quite quickly; but many Electron apps haven't pushed a version that vendors in the fixed version of the Electron runtime.
(And shit like this is exactly why runtimes like the JVM or the .NET CLR are designed to install separately from any particular software that uses them. Each of their minor [client-facing-ABI compatible] versions can then be independently updated to their latest OS-facing-bugfix version without waiting for the software itself to ship that update.)
Apple is consistent in their warnings to not use private APIs, and especially don't override them for custom implementations which is what Electron does here.
The _cornerMask override was a hack that shouldn't ever have existed in the first place, and it's not the only use of private APIs in the electron code base.
Apple is very clear about how they want you to make software for their OSes. It's 100% on electron that they choose to do it this way regardless.
I'd go as far as to say Electron itself is a hack that shouldn't exist, but sadly everyone has decided it's the only way they are going to make desktop software now.
> How else do you get the message across? Do not use the private APIs.
The most effective way would be for Apple to actually seek feedback on requirements and then actually implement public APIs for functionality that people need.
That's confusing "consensus building" with "effective". Killing a private api is pretty effective. And consensus building doesn't always build the best software.
... and in the process we will deteriorate the performance of millions of users and hurt our brand as a top class experience company?
Don't really care who is to blame, but they should have identified this, and either warn developers, or warn users. Or provide a tool for identifying guilty apps in your machine, and let users decide how to proceed.
There's no meaningful difference between "private" and "documented, but changing every patch release" from userspace POV, yet not committing to documentation saves development effort for the same result, hence "private" APIs. If anything, private apis let "system" apps run at userspace, reducing attack surface dramatically.
wtf am I reading? No no no. Undocumented apis callable from user space, that can break the OS, is a security flaw (in the OS). It’s why people laugh at windows.
Should we not be shaming apple for their recent software releases? Every bit of the os is N times slower than on the previous macOS version. Safari has been unusable. Constant lags and crashes in the shipped browser alone. We are back in Windows Vista times
Windows Vista broke UX for apps that tried to request admin permissions too often but didn't break the applications thenselves, and for video drivers wasn't that largely due to Intel shipping crap?
My MacOS experience has been first party software is getting worse.
If I’m remembering correctly, the original script he found had different emoji in the two lines (red X vs. green checkmark), but since HN comments strip emoji, pasting it here made them equivalent.
hmm there are apps produced by your script that claim to be fixed according to https://avarayr.github.io/shamelectron/ (Signal, Discord, Notion, etc). And I checked that those apps are updated. Which one’s correct?
I also have an M2 Pro with 32GB of memory. When I A/B test with Electron apps running vs without, the lag disappears when all the unpatched Electron apps are closed out.
1. https://avarayr.github.io/shamelectron/
Here's a script I got from somewhere that shows unpatched Electron apps on your system:
Edit: HN nerfed the script. Found a direct link: https://gist.github.com/tkafka/e3eb63a5ec448e9be6701bfd1f1b1...