biohazard2

> I believe Matt is right about the core issue in this fight. WordPress cannot become a place where large companies extract massive value from the ecosystem while ignoring the responsibilities that come with that position.

I don't think Matt was acting for that, though. I was only interested in money that ended directly in his pocket. Both WPEngine and Automattic are extracting value from an existing ecosystem. But does Automattic give 8% of their revenue to PHP? It doesn't seem so. And would Matt still have acted the way he did if WPEngine was giving money to PHP, Nginx, Debian and MariaDB? I think so.

Don't get me wrong, I do believe you would have a moral obligation to help the projects on which you make money, but that obligation can't apply to everything (where would you put the limit? Technically, you depend on all packages installed on any OS you use to run any software. And you would depend on quite a bunch of specifications from W3C/IETF, don't they deserve money from companies that extract value from those standards?)

I would even argue that WPEngine financing libxml2 would have been even morally better than WordPress, if you look at open source as a whole. So I would happily argue that Matt wasn't right about the core issue, just being selfish. Being sometimes selfish is probably OK when you're an open source project leader, but don't make him a leader of rightful funding of open-source software because he's certainly not.

That's really great news. There was a lot of discussion around the planned EU Digital Identity Wallet, which is using Google Play Integrity. Many voices were raised against this requirement. The Swiss decision is an odd, but very welcome decision (and that's quite rare for a Swiss public IT decision)!

The repository is less than one week old though; having only the initial commit wouldn't shock me right away.

>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?

Can we blame the Apple employees who apparently never tested their new OS release with any Electron-based application?

I find it a bit too specific, because it won't get rid of the `rewrite everything in (Go|Zig|…)` crowds. But who knows…?

> 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.

+1, I replaced my aging DS1812+ with a DXP4800 Plus and I've been quite happy with it.