Only Matrix is federated, like email. I really enjoy sending emails without opening an account for each recipient or being subservient to 1 stack provider for 50 years, with all the inbreeding that entails.
Just gave a talk on Monday about it in containerdays.io, but the video is not in youtube yet!
In a nutshell, with Kubewarden we strive to build the universal policy engine by:
- Provide all personas (policy consumer, policy developer, policy distributor, engine admin, engine developer/integrator, etc) with current and future industry-standard workflows, not only a subset of personas, nor more than needed knowledge for those personas. It's a bold statement, and if it would be universal it should indeed cater to everyone.
- This is achieved with policies as code, which are Wasm modules: Wasm policies allows us to support Rego DSL (OPA/Gatekeeper), YAML, SDKs for Wasm-compiled languages, and now an experimental Kyverno DSL policy by compiling it to WASM with WASI. Great for using your language and tools of preference.
- Wasm modules have first class support In OCI registries, just like container images: Use same tools that you know as artifact distributor: SBOMs, signing and verifying with cosign, airgap, slsa.dev, etc.
- Policies can be evaluated out-of-cluster: great for CI/CD, dev loop, integration tests, etc.
- Modular architecture informed by using Wasm policies: OCI registry, policy-server, k8s controller, out-of-cluster cli (kwctl), etc. This also helps in adopting future industry-standard workflows.
- Usual features of a Policy engine (mutating, context-aware, recurring scanner of already in-cluster resources, etc). Plus ample room for new features thanks to the architecture. E.g: possibility to run the policy-server directly in the k8s apiserver (one colleague already presented that in Kubecon), possibility to evaluate out-of-cluster policies outside of clusters like OPA just by running the policy-server standalone, more DSLs compiled to Wasm, more languages, etc.
- Vendor neutral, CNCF project, open source, developed in the open.
It consolidates Go compiled to WASI as an alternative of doing containers.
Linux containers don't "Run anywhere." as docker.io says. You need a specific architecture and kernel features, which is not obvious from afar.
There's also other benefits. Example: the team I work on compiled Kyverno, a CNCF K8s policy engine written in Go, to a WASI target. We are building Kubewarden, a CNCF policy engine where policies are Wasm binaries shipped in OCI registries. We strive to build "a Universal Policy Engine".
Now, we have an experimental Kubewarden policy `kyverno-dsl-policy` that allows you to reuse Kyverno DSL with us.
We also provide WaPC as a target, more performant and secure, hence normal SDKs for Go, Rust, C#, swift, typescript... In addition to supporting Rego, again compiled to Wasm.
IMHO you only benefit from the real sandboxing from WaPC, as WASI's posix-like interface allows you to attack the host.
The next step for the official Go compiler is to export the function symbols, to allow for WaPC.
A good architecture for fully parallel, deterministic, thread-safe, serializable and extensible games is the Entity-Component-System pattern. I'm sure that Godot has one or a way to integrate a library that implements it.
I think Unity doesn't come with ECS anyways.
You yourself say in a different comment that you are currently assessing Element:
https://news.ycombinator.com/item?id=34779070. Either you have a formed opinion Matrix, or you don't. Which one is it?
You keep saying Element instead of Matrix, and obviating the whole Matrix ecosystem. Matrix protocol has several server implementations, and many more things around:
https://matrix.org/docs/projects/try-matrix-now
I wonder, how could one use SGX for remote attestation when they didn't publish the source code for more than a year just to get their insiders' knowledge cryptocoin deployed.
In short; since privatization in the 90s, the spending in R&D went to 1% (median in other countries is 7%). Rising costs, and lagging on implementing DSL in 00s. OECD list it among the most expensive countries to own a landline, and cellphone. Then, lagging in DSL+, and then, lagging in Fibre. Bottom of the OECD list.
This is for a country that in the 50s, 60s, and 70s had an amazing copper infrastructure, and a computer and technology univerisity sector even.
Infrastructure is a natural monopoly [1]. The cost to enter the market is unfavourable, and the incumbent has all the margins.
Privatizing it is always a bad move for the citizens, and a good move for the private company.
At worst, countries should keep one publicly owned company that owns the infrastructure and rents it to others, and also keeps the playing field leveled with low prices for the customers (this is the case in some countries but not all..).
That sounds like moving goalposts: the OP mentions Arch's rolling release. And Arch doesn't rebuild the dependents when a package gets updated.
On the point of Testing lacking timely security updates, it's fair. But I invite you to compare the timelines with other distributions (including from corporate backers), and you will realize that their manual testing takes even more time.
Plus, you always have Debian Unstable. And apt-listchanges and apt-listbugs work fine in Unstable. It's the same experience: you get notified of serious bugs before upgrading, you get to pin packages and the pins are automatically lifted with the fixed version.
it exists: either Debian Testing (a week or so of proven stability) or Debian Unstable (latest and greatest).
If one follows the best practices for them[1] (installing apt-listbugs and apt-listpackages), one gets information of bugs and API-breaking changes before performing the upgrade, and can decide to pin the specific package as needed, and it will automatically get released when the bug is solved.
This is thanks to how the Debian packages treat bug reports, and the debian/NEWS file. I can't believe other distributions get it so wrong for so many decades.
Plus, these 2 distributions (Testing and Unstable) get all the automated QA usual from Debian: autopkgtest integration tests, piuparts, lintian, reproducible builds, policy conformancy..
It seems it's no coincidence that gLinux from Google, rolling release, and in TFA, is based in Debian.
