>Europe is the only continent in the world to have a large public network of supercomputers that are managed by the EuroHPC Joint Undertaking (EuroHPC JU).
Who would have thought that Europe is the only continent to have a network of supercomputers managed by Europe⸮
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 also just no reason to rewrite SQLite in another language. […] But why would we want to throw away the perfectly good C implementation, and why would we expect the C experts who have been carefully maintaining SQLite for a quarter century to be the ones to learn a new language and start over?
The SQLite developers are actually open to the idea of rewriting SQLite in Rust, so they must see an advantage to it:
> All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. Some preconditions that must occur before SQLite is recoded in Rust include: […] If you are a "rustacean" and feel that Rust already meets the preconditions listed above, and that SQLite should be recoded in Rust, then you are welcomed and encouraged to contact the SQLite developers privately and argue your case.
I think it’s the opposite. They want to atleast explore rewriting in Rust but are afraid of backlash. Hence why they’re open to private discussion. I can imagine they are split internally.
Now that is an interesting picture! I am far from being a UI expert, but I do dabble and i would not have thought both forms of zero could be used in the same HMI display to lower cognitive load.
It's not a 90% speedup, it's ~50% (still quite impressive).
The author seems to be confused, because the original jq is 1.9x slower than the optimized one.
That depends on how you're representing the speedup.
To travel 10 miles, at 60 MPH, takes 10 minutes. Make it 100% faster, at 120 MPH, and that time becomes 5 minutes. Travel just as far in 50% of the time. Or travel just as far 100% faster. The 90% speedup matches the reduction of the time it takes to nearly half (a 90% (projected) speedup, or about a 45% time reduction, as mathed out by kazinator `Projected speedup from both: 4.631/2.431 = 1.905`). Your claim that its closer to 50% is correct from a total time taken perspective, just coming at it from the other direction.
