Orphis

It's relatively new I think.

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.

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.

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.

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.

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?

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.

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.