Reproducible builds reduce the need for trusted parties.

Have many organizations produce the binaries independently and post the arifacts.

Once n of m parties agree on the arifact hash, take that as the trusted build.

If every party reaches a different hash then we cannot build consensus.

To move away from organizational dependence, there should be an installable project for debian where I can dedicate some configurable small percentage of my compute when idle to reproducibly building debian components to make a robust verification system, starting with the most critical code.

Obviously, it would be a ton of work to make such a system resistant to gaming by malicious actors (see GNU Guix for useful efforts), but it would provide valuable diversity in architecture and (political or other) control.

It would be even cooler if we could have independent projects that could run on various distros and OS, and build packages for any of them. Having packages for bsd verified on linux and vice-versa with statistical logging (this code has been verified x times on y OSes) would be reassuring.

I don't know of anything Ubuntu is doing that is significantly beyond what Debian is doing in this regard, nor that they have a distributed reproduction system set up???

Building Ubuntu does not produce identical binaries to Debian, so no, that's not what they're asking for

Probably easiest way is to use Bazel to leverage the effort that has gone in there

Over-eating is not strictly a choice. Corporations spend billions on manipulating the public because it works. Regulation is needed, not willpower.

I don't believe regulation is the answer. As I get older, I've become increasingly skeptical of any information coming from the government.

But somehow information from corporations is good and we should let me do whatever?

Your inference does not follow.

Python has a reputation for being good for beginners so it's taught to beginners so it has a reputation for being good for beginners.

Success rate in that era was very low. There are thousands of movies from that time that no one cares about today.

Do you know of anything like AoC but that feels less contrived? I often spend the most time understanding the problem requirements because they are so arbitrary - like the worst kind of boardgame! Maybe I should go pick up some OSS tickets...

Take a look at Everybody Codes. It occurs in November instead of December, so this year is wrapping up. Like AoC, it is story based but maybe you'll find the problem extraction more to your liking.

https://everybody.codes/events

Being contrived, with puns or other weirdness is kinda on par for this kind of problems. Almost every programming competition I've ever been to have those kind of jokes.

Just a random example: https://open.kattis.com/problems/magicallights

But the Kattis website is great. The program runs on their server without you getting to know the input (you just get right/wrong back), so a bit different. But also then gives you memory and time constraints which you for the more difficult problems must find your way out of.

Terse languages with great collection functions in the standard libraries and tail call optimization. Haskell, OCaml, F# ...

- Write side is a Postgres INSERT

- Read side is a SELECT on a Postgres view

I think you might struggle to "scale the read and write sides independently".

It's a real stretch to be describing a postgres view as CQRS

Sqlite can scale CQRS to 100000 events per second on a relatively small VPS. That's 10x what the author achieves with postgres.

You can scale them independently in that you can control the rate at which your views are read and the batch size of your updates.

The whole big win wirh CQRS is it allows for very efficient batching.

But only one server can access each SQLite at a time?

I've heard worse, e.g.

You use POST for your Cs and GET for your Qs. Tada!

Huh?

That's EXACTLY what CQRS.

I think you might struggle to understand CQRS.

> Go is one of the best languages to go for Event Sourcing toda

Can you explain this? Go has a very limited type system.

How does event sourcing handle aggregates that may be larger than memory?

Smaller aggregates.

You really don't want your streams/aggs to come close to being that large.