> Edit: Some comments mention Qt which could also work although how large is the runtime? Can it be compiled statically?
You need a commercial license for that, but yes you could. But since applications are typically distributed with install bundles that put into application-local program files directories, it's not super-important as long as you only cherry-pick the Qt libraries you need.
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.
I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.
Yes, that is true, but in practice nobody has ever done that. And the material complexity of offering that mode is higher than just dynamically linking the library.
Also, modern compilers make this method much harder to use. It is much harder to stably relink object files like that than to just use the normal dynamic link method.
It's pretty much rpm-ostree. Nobody bothered to make those workflows performant, so if you need to apply updates separately, it's going to suck. The OSTree download can be fast if you have a fast connection to the Fedora server, but it's not mirrored and there's no mirror network support (so no geographically close downloads). To be fair, bootc has this problem too because container tooling in general can't support mirror networks currently.
I think it's also worth noting that the Dockerfile format is still driven by Docker, and there have been zero extensions to the format by Podman folks, so Containerfile==Dockerfile.
SUSE used Teams for years (particularly under Melissa Di Donato, who made everyone use it). I used to participate in some of the community project meetings that wound up being on Teams because it was the approved solution they could use. It was the reason why the openSUSE Project deployed a Jitsi instance.
They do not use Microsoft 365 or Microsoft Teams anymore. They use Google Workspace just like everyone else now (the mail headers tell you that). I don't know anything about their workflows, though.
Stallman wouldn't agree, but in a FOSS spectrum, I think MSFT sits in the middle between FOSS and SaaS, at least they release binaries. With Google it's all SaaS.
I hold no horse in the race, but it seems that Google Workspace is a step in the opposite direction, you don't even have access to binary executables, and you can't self host much stuff, but hey at least you can export your data and make backups! (You can right?)
Microsoft has effectively ended support for the self-hosted versions of the groupware stack. So between Microsoft and Google (since both are SaaS), I would pick Google. Especially as I've had to administer both solutions before, and I would never voluntarily choose Microsoft 365 ever again.
And yes, you can regularly export your data out of Google Workspace and there are tools that can process that data and use it easily enough.
I think they mean you don't need ruffle if you can just export to web. The programming environment can be anything, but adding ruffle in the middle when it really doesn't need to be there, does indeed feel a bit tacky. Flash used to be necessary to add functions to browsers that were otherwise impossible, but these days you can do anything in a browser.
Yes indeed. The web with webgl/webgpu and wasm and all the other webapis has enough power to replace what flash could do since a long time. Just doing it by hand is messy, but as a target plattform it is good enough.
Google developed linux cgroups. IBM developed linux namespaces. Docker developed a completely new application runtime and delivery system, built on cgroups, namespaces, aufs, and tar. This required lots of original design and engineering work. Prior to Docker, there was no runtime contract for distinguishing the portable application bits from the non-portable host-specific bits. You just got a machine, and then had to provision, configure and templatize it - then upload application bits into it yourself.
All three companies contributed significantly to the modern container stack. As the co-founder of Docker, and someone who spent 10 years toiling away at container technology before it finally became cool, I wish people had more appreciation for the amount of engineering and design work that went into that. Google and IBM contributed the primitives that made Docker possible. But Docker made genuine contributions of its own.
You need a commercial license for that, but yes you could. But since applications are typically distributed with install bundles that put into application-local program files directories, it's not super-important as long as you only cherry-pick the Qt libraries you need.