They actually did a study on it after rolling back to Windows, and it turned out to not have failed due to technical difficulties at all.
If I recall correctly they stated that something like 80-90% of all issues reported during the period were due to badly designed processes - processes which were the same as in Windows, and the number of technical issues actually dropped.

Certainly, the fact that Microsoft promised to build a fancy new HQ in the city if they switched back to Windows can’t have had anything to do with the choice to roll back…

Thank you so much, especially for the private instance improvement.

It’s sad when it’s revealing that ~80% of all traffic to my home instance is garbage.

10-20% of year-over-year revenue is the going rate.

Well, there’s the ALFIS project

And it’s still entirely unrelated to my point, since SUSE will remain the trademark in question regardless of what’s actually contained in OpenSUSE.

But yes, the free/open-source spins of things tend to have somewhat differing content compared to the commercial offering, usually for licensing or support reasons.
E.g. CentOS (when it still was a real thing)/AlmaLinux/etc supporting hardware that regular RHEL has dropped support for, while also not distributing core RedHat components like the subscription manager.

Not at all what my point was. There’s indeed plenty of Open-something (or Libre-something) projects under the sun, but no free/open spins of commercial projects named simply “Open<Trademarked company name / commercial offering>”.

To be fair, OpenSUSE is the only project with a name like that, so it makes some sense that they’d want it changed.
There’s no OpenRedHat, no OpenNovell, no OpenLinspire, etc.

Well, one available case you can look at is Uru: Live / Myst Online, currently running under the name Myst Online: Uru Live: Again.

They open-sourced their Dirt/Headspin/Plasma engine, which required stripping out - among other things - the PhysX code from it.

Both the rendezvous/mailbox and transport servers are available under an MIT license, though not every client makes it easy to use your own rendezvous.

I personally use the rymdport GUI client and the rust CLI.

In general, browser benchmarks seem to often favor Firefox in terms of startup and first interaction timings, and often favor Chrome when it comes to crunching large amounts of data through JavaScript.
I.e. for pages which use small amounts of JavaScript, but call into it quickly after loading, Firefox tends to come out on top. But for pages which load lots of JavaScript and then run it constantly, Chrome tends to come out on top.

We’re usually talking milliseconds-level of difference here though. So if you’re using a mobile browser or a low-power laptop, then the difference is often not measurable at all, unless the page is specifically optimized for one or the other.

There’s a bunch of extensions that allow you to switch user-agent easily, I personally use this one, it includes a list of known strings to choose between as well.

They used to also use the unreleased version 0 of shadow DOM for building the Polymer UI, which - being a Chrome-only prototype - understandably didn’t work on Firefox, and therefore instead used a really slow Javascript polyfill to render its UI.

I haven’t checked on it lately, but I imagine they must’ve changed at least that by now.

One thing you can test is to apply a Chrome user-agent on Firefox when visiting YouTube. In my personal experience that actually noticeably improves the situation.