viccuad

Though luck. Be more careful next time. That's how licences work (not only open source ones, or software ones).

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.

I wonder how a home assistant built with an Entity Component System architecture would look like.

At that point I would just call it a reimplementation instead of emulation.

Let's just build it in open source and out of walled gardens then.

Agree here. I long for an open source combat flight sim, and Bevy, with ECS, rust, wasm capabilities, thread safety, etc sounds quite apt.

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.

I'm also waiting for that :) See https://github.com/golang/go/issues/42372

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.

This seems like goalpost moving.

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

T

it displays fine here on Firefox on Linux: https://i.imgur.com/MoRqYL8.png

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.

if they want it to work as you posit, they should not save all the date in Discords systems, but create a distributed chat system.

Signal is just XMPP implementing the Axolotl ratchet.

XMPP is just SMTP and some protocol addons on top. SMTP is just FTP with RFC 469 and others. Etc.

I can recommend this timeline of the history in New Zealand: http://www.wordworx.co.nz/KiwitelcoTimeline.htm http://www.wordworx.co.nz/Kiwitelcotimeline2.htm http://www.wordworx.co.nz/Kiwitelcotimeline3.htm

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

[1] https://en.m.wikipedia.org/wiki/Natural_monopoly

I do the same, but in a Steamdeck. It doubles as HTPC, as I can use a Steam Controller as mouse, and the pop-up keyboard with it.

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.

[1] https://wiki.debian.org/DebianUnstable#What_are_some_best_pr...

In addition to points from others: no middleman can tamper with the information being sent (e.g: see how Russia changes content of pages served via http to display war propaganda or ads).

One is not a better parent by controlling their kids for their foreseeable future. One needs to let them join the world and grow on their own, with their own friends.

That's analogous to the halting problem.

Why was it disappointing in them? Don't they need to compete with Chrome and Safari's UX, that just allow those cookies?

Gedit (and Gnome Builder, etc) do this.

Matrix has threads.

I don't think vendoring helps at all. People can't review all the dependencies' code. And recursively, for the dependencies of the dependencies. At some point, you delegate trust.

What helps is having provenance information, signing and SBOM. One example. https://sigstore.dev (vendor neutral effort from the Linux Foundation).

part of the supply chain is your source forge and builders. On GitHub, you can point the builders to your own infra.. and then maybe check cryptographically that all source code that lands on the builder is correctly signed and trusted.

But it's nearly impossible to do that for the forge itself (GitHub).

I recommend https://slsa.dev (vendor-neutral effort from the Linux Foundation) for a better picture of a secure supply chain.

The engineer building the bridge is liable. Hence, you get engineers with qualifications (instead of a random person with X years in Y), and those qualifications certify they know what they are doing.

The underlying issue to me is the different velocity of different conversations between the same people in a room. Conversation 1 can be fast, with short messages and informal, Conversation 2 can be slow, with long technical messages or attached files. And all in between.

Sometimes one type of convo transforms into another. And the tool should reframe it so: either by providing a schism for a new thread, changing the topic of the thread, or so.

This is something that tools with N-level threads, where each message creates a new thread (technical email discussions with top posting) do very well. I wish that each message would create a new thread. And that the UX allowed to me pivot from short and informal to long and thought out messages easily.

From an informal conversation of the daily, to starting a thread from a message, where we discuss a technical implementation in a long comment. And then back to someone opening an informal thread starting from a phrase of that long comment (ala document reviews).