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.

The Juniors are also very good with AI. Having them merge bad commits into logical ones is a fine operation for them too.

People say they care about the "story" behind the PR. But no one cares about that story if it's about forgetting to fix a test and a typo in a comment.

The extra commits are just noise that make you think the original commit is a source of truth in a blame when it has been amended 3 times more in the same PR, but the link isn't apparent anymore.

Force pushing is bad to a published branch, not a feature branch (not that you really have force pushes in Gerrit anyway). There are versions of Gerrit tooling where you can have a branch as dirty as you want locally, but only the final aggregated change is visible for review of that's what you prefer too.

Thinner modular systems also require some good tooling and a good platform that ensures many security properties.

You will be trading a stable and vetted huge standard library for 200 small packages that may all be targets for supply-chain attack. Open-source projects don't all have the resources unfortunately to keep track of all their dependencies, so I'm not sure it's necessarily a more natural fit.

C++ ended up in that situation because they don't want to break backwards compatibility (ABI, API) or change contracts, except in some rare cases, even on major releases. Quite often, it is a vendor issue to break the ABI and fix issues, and some have refused to do that.

It's a self-inflicted issue that most other languages with "batteries included" don't have since they will document breakage and upgrade paths when anything changes, or they are not impacted as much since they are using an intermediate language as interface and avoid most ABI issues.

The implementation is fixable though, you can break the ABI and address your issues. A lot of standard library defects are fixed in an unstable ABI mode they have, but that requires you to link it statically or dynamically and then ensure all your shared object dependencies are using the same exact version. It's not trivial for everyone, but many do this (usually the static version).

You mostly hear about the bad ones. Mine has been doing great for almost 2 years now. I use it in a clean environment, I'm very careful and not clumsy, so that helps.

It's not that noticeable when you use the device. It will depend on your ambient lights usually and how you hold it. It's a lot easier to see when someone else is holding the phone too, so if that was your reference, you may want to use them a bit more first.

I think the clumsiness can be improved. I always make a conscious effort when I grab my phone or put it away, so that is is always secure. No "I thought it slid into my pocket but apparently it was still outside it and then dropped". I would grab my phone with both hands in a lot of situations that are risky etc.

It's a bunch of small habits to change, then you may be ready for a fragile foldable. Until then, yes, probably not the target audience!

Turns into a small tablet which is great for reading, for impromptu client demos, and for playing some games like puzzles.

It also enables multitasking by having applications side by side which can be very useful on a phone too.

You don't have to use it all the time, but it's nice when you need it.

And mine is almost 2 years old and in great condition. It's hard to know what is responsible in those cases, a manufacturing defect or a rough user. And knowing what I've seen people do with their non-foldable phone, I'm not sure who to trust.

Practice helps!

What also helped me is being so knowledgeable about the topic that I didn't need to prepare the presentation much (except for the slides and the general plan). When you know what you have to talk about, it becomes a lot more natural and relaxed for me.

I would be a lot more stressed if I had to learn a presentation by heart and it would probably be a robotic delivery.

So I did quite a few "surprise" presentations, with very light prepared material and a topic I cared about. Got me the practice I needed and I learned not to get "stuck" as if I forgot the next sentence. The presentation always flows!

Now, I have a talk at a major conference, and I'm afraid this won't work there, so I'll prepare my talk better this time, maybe even have speaker notes!

Curious, Windows is not supported by this.

Ultrawide curved are amazing. Put your main activity in the middle since there's no screen bezel and enjoy your neck-pain-free work hours. 2 monitors force you to usually have one on the left, one on the right and always face your head towards either.

Also, it's fine to have side activities on the side, but you usually won't be looking at those all the time, so they shouldn't cause any strain.

Why not just embrace Content Based Addressing and the Bazel action cache? Not necessarily adopt the RBE protos, but you could have on-disk cache that are similar or even identical.

Nowadays, I think a build tool that doesn't natively support distributed caching (and possibly remote execution) is a weird choice. And I don't think that spawning layers of processes allows for good parallelization as you don't know if an action is going to be network bound or compute bound and the job slot is then spent. So you either oversubscribe or undersubscribe.

This is not purely a CMake problem, this is a maintainer problem. It's absolutely possible to not define the man page targets if the related tools are not found, or to add a variable to disable that.

In practice, it does show the limitations of the CMake model though. You should not be paying the price to generate the build files for bits you don't care about. You should be able to just load the CMake files and build a target, ignoring the rest.

This is how tools like Bazel function and that allows them to scale to very large monorepos. Build files are only processed when a target from that folder is built directly or used. CMake has to load everything as it does not know about the build tree and the maintainer has to manage exclusion lists or inclusion lists.

Xerces is an old library, probably ported from autotools and will do a lot of autotools like checks which for CMake means: creating a CMake project with the probe, generating the build files from it, building it, gathering results. Once for each test. It's SLOOOOW.

I recently (a few weeks ago) made a project to batch those type of commands together and parallelize tests as much as possible. You can check a merge request for CMake upstream here: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1226... and the associated issue for more details.

In general, CMake is fast enough, the only slow bit on the critical path is detecting the toolchain. The rest is quick, but if your build scripts are using slow serialized functionality, you'll be paying that price. But only once as the slow results are cached, so next incremental run should be pretty fast!

> I want the build stages to communicate in one direction for sanity

That's easy to do if you control the whole pipeline and can integrate all the features together, not so much with the CMake model unfortunately. I think it would be nice if CMake had Ninja integrated as a library, it could lead to some nice optimizations later.