@Chancerubbage This process informed me that on hackernews I write about 300k words, or one full length Game Of Thrones book, every year.

I am still processing how I feel about that.

So I trained an LLM on myself, and it sounded like a complete idiot so I deleted it immediately.

I am starting to consider that it might be a me problem.

The biggest life lesson I have internalized this year:

The greatest skill in the world without sufficient motivation as a catalyst can accomplish nothing, but with enough motivation one can pick up just enough skills as they go to accomplish almost anything.

An insane amount of personal data is getting routed to proprietary LLM providers directly and indirectly.

Worse, all that personal data is going to get used to sit on the scales of otherwise "fair" weights to produce an entirely new form of toxic and manipulative targeted advertising.

Since we can't un-invent LLMs, the way forward is to make sure they exist with provable privacy and integrity.

We just released the first FOSS stack to do exactly that.

https://caution.co/blog/verifiable-llms.html

@jas @rekahsoft Also, you can build on very very old x86 CPUs that long pre-date the existence of these bootstrap binaries and tools and would not have the means to identify and circumvent those code paths.

With every wild ass platform someone reproduces and gets the same hashes, trust keeps stacking.

@jas @rekahsoft But also there are x86 implementations in FPGAs, such as in the Mister FPGA project.

These are powerful enough to booststrap in a few days.

If you randomize the gate layout each time, the odds of a backdoor smart enough to always flip the right gates that could tamper with it on every run approach 0.

@jas @rekahsoft Technically yes, though it is slow as it has to use a hypervisor.

That said there is another potentially more interesting path.

Compile the stagex bootstrap in RISC0.

Then you get a zk-proof of the entire compilation process so you can verify the bootstrap entirely in seconds, instead of many hours.

Some experiments have been done in this direction already and it looks viable once we can afford the compute.

@jas @rekahsoft All of the early bootstrap ingredients have alternatives that are mature or very close to usable allowing for bootstrap diversity.

One can use a Linux, Moss, or Asterinas, kernel on CPUs by distinct vendors, and even FPGAs. and one of multiple hex0 implementations, and then everything else can be built from there. If all get the same result, then we have eliminated any single point of failure.

Linux distros trusting binaries however completely undermines security needlessly.

@PuercoPop @rekahsoft

Native as in OCI is the native packaging standard, as compared to say an RPM or a DEB.

Exported means the distro supports a way to build a root filesystem and export to OCI.

Is there wording you feel would be more fair?

@tyil @civodul @rekahsoft

I am probably one of the most radicalized FOSS advocates most people will ever meet. I co-run two companies with 100% FOSS and use 100% FOSS tools in my personal life. Not had a smartphone in more than 5 years because iOS and Android are both closed platforms at this point.

I care about freedom a LOT, I just don't care about a /specific/ FOSS license or the other as much as I care about minimalism, auditability, security, maintainability, etc.

@civodul @rekahsoft I was not close to the website redesign other than the technical content, but I agree with you that is an overly strong statement and will make sure that is reworded soon.

As far as the "GNU way of doing things" I should have used less dismissive language here. After all GNU got us here!

I suppose I mean a very strong preference for GNU tools, even if other FOSS solutions are technically superior in the ways most people (at least in my circles) care about.

@hipsterelectron Also speaking of crazy, there has already been work towards doing the bootstrap in RISC0 so we could have a zero knowledge proof of bootstrap that would be easy to verify on a wide range of hardware.... stay tuned :D

@hipsterelectron That is really encouraging for us to hear as that was our intent.

Talos Linux just uses stagex/bootstap-stage3 to bootstrap their own distro directly, and that is exactly why we made bootstrap its own thing.

I don't want people to have to re-invent these wheels again because there are like 20 people on the planet that really care about this stuff and they should focus on the layers not solved yet.

@hipsterelectron Also of note we don't use guix at all, but we do use mes today. That said I don't expect we will need mes much longer as M2Planet and M2Libc will likely be able to directly build tinycc soon the way things are progressing.

@hipsterelectron In the spirit of never taking choices away, we made sure to still expose several different toolchain combinations in our "pallets" making it easy to swap toolchains depending on what you are doing:

https://codeberg.org/stagex/stagex/src/branch/main/packages/pallet

@hipsterelectron Too bad about LLVM? Gcc is absolutely still in tree and you can use it, but it is hard to beat the cross compiling capabilities of LLVM.

@rekahsoft Guix goes further than any other distro and was a big inspiration, but it is not 100% reproducible/bootstrapped, trusts downloaded binaries, has a single-party trust model, chooses the GNU way of doing things above all others.

As a desktop-first distro with thousands of packages it would make it incredibly difficult to ever fully clear those bars.

Our threat model mandated the design a distro and release process built for supply chain security.

https://codeberg.org/stagex/stagex#comparison

@llvm Great call. Will try to figure out how one updates this.

@jas Full disclosure, I largely designed and led development of the first four of those.

All are immutable/minimal examples though. Stagex is not /currently/ targeting general purpose mutable desktop use cases, focusing only on high security appliance use cases no other distro was appropriate for first.

That said, AirgapOS is an example of it booting and running on a wide range of laptops for direct use by humans, albeit non graphical.

@jas No extensions needed. There are already several high security focused laptop/server/enclave distros built with stagex.

ReprOS - https://codeberg.org/stagex/repros
AirgapOS - https://git.distrust.co/public/airgap
EnclaveOS - https://git.distrust.co/public/enclaveos
QuorumOS - https://github.com/tkhq/qos
Talos Linux - https://github.com/siderolabs/stagex/blob/ci/.github/workflows/stage3.yaml
Nautilus - https://github.com/MystenLabs/nautilus