From memory and from when I took a lot of it decades ago, cortisol is the natural produced version, cortisone is the prescription one, also called prednisone.

When you take cortisone, your body reduces or stops producing cortisol. So if you want to get off the drug, you need to heavily taper it over a long period of time. When I was on it over 20 years ago and high doses, I would slowly go down to 20mg daily, watching any symptoms, and eventually do 20mg every other day and continue to lower from there.

Cortisone dependence is a real thing unfortunately, and it took me forever to get off it.

You can coat the rabbit meat with Dijon mustard and cook it to make "Lapin à la moutarde" too!

It's not a knock-your-socks-off dish, I don't think the meat has enough qualities for such a dish (not enough of a distinct taste or texture or quantity), but it's always nice to have!

In the same family of languages (proto-germanic), you'll have Swedish for which the word for the meat is "kyckling" which more pronounced like "chickling".

Modern German might have changed along the way, but if you go back far enough, there should be something. I'm not a linguist or a native speaker of a Proto-Germanic language, so I don't know enough to pinpoint this better.

That's why you have signed packages that everyone can rebuild and verify from the very early stages of bootstrapping to speed up the process and get back to a synchronization point that is reasonable.

Distros that are not fully hermetic and don't have reproducible packages (and there are many layers of reproducibility) will certainly have issues, but that's not a huge problem as long as you have a documented path to getting back to the current state. It doesn't need to be the fastest path, just a verifiable chain of trust.

We do sign our packages, but the threat model is to minimize the time it takes for users to not have to trust us.

It is critical to encourage many independent verifications that it be as fast as possible that someone can go from a clone of our tree of pure source code to the exact release hashes we publish.

Adding any binaries to that means someone that distrusts us must now go build those past releases as well, and if they rely on binaries, they must build those past past releases as well. This approach would make verification time go up dramatically every release.

You don't need to verify the chain of trust all the time, you can remember up to where you had trusted everything when you adopt your solution.

Also, while you can use the latest prebuilt as a stage0, you could also use any other prebuilt from earlier down the chain as a stage0 and still get the same stage2 binaries. This is the next trust checkpoint you have, and it should be fine to have multiple ways to get there too, one for quick iterative releases and one that is reusing the minimal amount of bootstrapped packages.

Or you just try to only upgrade your stage0 once in a while when extremely necessary and it would build your new stage2.

So many ways to optimize the system, it's a choice to refuse to reuse what was trusted yesterday in order to build the next stage.

>it's a choice to refuse to reuse what was trusted yesterday in order to build the next stage.

If the point is to let independent people verify the full build chain, then there is no "trust from yesterday" to reuse.

Even worse, if every release N depends on trusting release N-1, then you need to do a full rebuild of everything in the whole history, instead of just building the current release. This doesn't sound reasonable, or at least sounds incompatible with the project goals.

It gives me hope that at least some people understand the problem!

It seems like you would benefit from having reproducible and hermetic builds with a good caching layer so you don't do the same work again and again.

Then you can just use the latest built version to build mold and the next version of rust.

Our tree is entirely reproducible and hermetic. In fact we are the only distro that does this 100%.

The problem is changing any dependency of rust, even python or perl or musl or openssl or the llvm stack or any dependencies of the llvm stack have the potential of resulting in a different hash for rust.

Any time a dependency is changed all decedents must be rebuilt. Which we must do very frequently. That is where mold saved us a ton of time.

That's why you build a stage2 compiler at least with stage0 being the latest prebuilt.

Your stage1 will be based on whatever version is your stage0, but your stage2 should end up identical to any other build with any other stage0. So you don't have to rebuild the full chain all the time.

And then preferably you build a stage3 with FDO, you can easily get 20% more speed with a good corpus of tests.

Do you have at least a distributed cache with I guess sccache to save time for each rebuild?

If we added rust to our stage3, it would add 6 hours of wall time with the fastest 192 core CPU on the market to the time it takes people to reproduce and validate stage3. Add a couple days for someone with just a 16 core consumer CPU.

Our goal is to allow people to reproduce the entire tree from source in the shortest time possible, so no one has to trust us, thus encouraging as many people to do it as possible, thus preventing us from having the means to inject supply chain attacks without anyone noticing.

It is literally a goal for new users to be able to run a server that bootstraps itself, and then bootstraps and signs all future releases, with remote attestation proofs. The shorter that initial build window is the better, which is why things like fast linkers written in early-bootstrappable-languages are so important.

How long are all the rust builds in your distro? If the compiler is 20% faster (my LLVM Clang results), you "just" need 30 hours of building time to get even, and I'm sure there is enough rust around (maybe not all in your distro) to make this worthwhile.

In any case, people could be using the stage2 or stage3 binary and still get the same binaries in the end, they are just alternative versions of the same package that should be compatible.

And using a 192 core CPU is a bit futile, have you looked at how well the work can parallelize? Isn't there some good remote worker solution you could use to have more cores available for the whole fleet without locking a 192 cores machine for a single build? It doesn't look very efficient to me as it is.

Building from zero to rust is about 6 hours on my 192 core local workstation. The extra cores absolutely help. Each linux kernel takes 16 seconds. Rust still takes a few hours. And on a typical laptop, a day or more.

Building rust that far to build mold to then build rust again faster negates any benefits.

There are definitely some uses for a washer and drier with "smart" capabilities. Just alerting me when the program is done so I can put the next load is great. The cycles are not "fixed time" anymore, they all weigh the load and end up variable.

I could do without them, and it's not the end of the world if the laundry stayed 20m or 1h longer in the drum. It's practical, and hopefully not a critical feature of the internal board. One could argue if alerting is really a "smart" feature either.

There's also a chance the people claiming to do clean room are cheating and took some shortcuts.

It's easy to make random claims that are impossible to prove or disprove.

They could claim that some employee one day used their model to ask a question about internal stuff and they trained on that.

It doesn't have to necessarily have to make sense to make a claim, but it doesn't necessarily bear any weight.

If using the OpenAI models to develop this taints you with Apple insider knowledge, then so is developing any macOS, iOS, Android or Windows apps around that are using any LLM.

You can't claim that some work is necessarily tainted by existing, you also have to prove which knowledge was retrieved, used and that there was no other reasonable way to know it. But unless it is actually tried in a court in all major jurisdictions, it's just speculation from all parties (including line).

One person could also claim that someone someday might leak information to them, and even though they'll ignore it, since they'll be exposed, they are tainted and can't contribute anymore. It'd be absurd.

A project is free to chose who can contribute, but they can't necessarily gatekeep others from doing their own project with different rules.

There's also been Wii games rereleased on PC with all debug symbols that cover the Wii parts that were still compiled in. You'd get mostly type names, enums, object layouts and function signatures that way.