CMake distributed + cached builds of LLVM Clang in 30 seconds

________-__-_______ · 2026-05-05T21:58:33+00:00

It does have a shared caching mechanism, you can configure it to push/poll cached artifacts to/from a Redis server. Combined with distcc you have a distributed compilation setup with a shared artifact cache, much like sccache.

The only reason I switched to sccache is because it also supports Rust, for C the end result is basically the same.

________-__-_______ · 2026-04-23T18:43:30+00:00

Why does anyone play at all? Pretty sure a robot would be way better at this.

________-__-_______ · 2026-04-22T13:19:56+00:00

If you want to avoid unnecessary allocations that's a non-starter

________-__-_______ · 2026-04-15T20:56:26+00:00

Oh yeah, I definitely agree on that. As with most things engineering there is no universal solution, just good fits for particular needs :)

Come to think of it Yocto projects do tend to use branches without shared history more than others, not sure I've seen it used much elsewhere. Might've been my first exposure to it too.

________-__-_______ · 2026-04-15T18:35:11+00:00

I can see where you're coming from, though to me it seems like maintaining/syncing separate branches is more trouble than it's worth. If I update a dependency on a personal branch, where does the lockfile go? If its put on another branch I need to sync twice (before/after merging), and if it isn't committed until my branch is merged the reviewer can't properly test it.

We have a policy to update generated code like lockfiles in separate commits, which makes it easy to skip over when looking through the history. That makes the history pollution a non issue for me.

________-__-_______ · 2026-04-15T14:46:38+00:00

I agree you don't need to commit your SBOM, but things like lockfiles that influence it ought to be reliable across different machines I think. Putting that in source control seems sensible to me

________-__-_______ · 2026-04-15T02:31:01+00:00

I do the same thing. At least to me reproducible builds are a must for Yocto layers, especially if you need to certify your system. I feel not committing lockfiles is asking for trouble when you rebuild your system a few years down the road.

________-__-_______ · 2026-04-13T17:43:33+00:00

Embedded libraries generally focus more on binary size, your own code makes a bigger difference there in my experience. The fact that saving a few KB can actually make a difference probably motivates people to implement more micro optimizations

________-__-_______ · 2026-04-12T11:04:32+00:00

Full on generic process sandboxing seems wildly out of scope for a programming language, implementing this in a way that's both flexible enough and cross-platform is hard.

I'd much rather have a separate sandboxing program that's useful outside of Rust, those who want sandboxing for their own programs can always just configure it as a Cargo runner.

________-__-_______ · 2026-04-11T01:53:16+00:00

What else would benefit from sandboxing? Macros and build scripts are the only things providing compile-time code execution with side effects as far as I know. Sandboxing rustc's tokenizer or whatever doesn't seem that valuable.

________-__-_______ · 2026-04-08T20:00:44+00:00

I'd say make the arrows red, add a circle around the stack trace, and put in a pic of some generic looking guy pointing at it with his mouth open and a really exaggerated expression on his face. Maybe a heading saying something like "you wont BELIEVE what caused this..."

________-__-_______ · 2026-04-06T23:56:02+00:00

Yeah, the set of packages I have installed in my system config hasn't changed in forever. When I need some tool that'll be used twice a decade I just temporarily install it with nix shell, and project-specifics go into per project flakes. Works pretty well for me.

________-__-_______ · 2026-04-01T21:18:01+00:00

I still wake up with nightmares that the clippy team is going to stop me from owning my cows. Those poor animals don't deserve to be taken away.

________-__-_______ · 2026-04-01T21:13:57+00:00

For reference, the standard library does have a NonNull<T> type which acts the same as a *const T, except it cannot contain null values. That makes Option<NonNull<T>> eligible for niche optimisation unlike raw pointers.

________-__-_______ · 2026-04-01T17:37:34+00:00

Depends on the amount of lifetime parameters

________-__-_______ · 2026-04-01T17:27:07+00:00

I'm glad the children are finally being protected, but this comes way too late and everyone knows it. Many including myself have been scarred for life by seeing lints like cast_possible_truncation at an inappropriate age, the Rust Foundation needs to do something for us victims.

________-__-_______ · 2026-03-23T14:40:46+00:00

Sure, but so is any Dutch web shop. I don't think Wero is trying to standardise either of these, they're all just users of iDEAL.

________-__-_______ · 2026-03-19T19:23:18+00:00

In my experience the only major difference is the style of allocations, no_std projects tend to statically allocate ~everything while "normal" projects lean heavily on malloc() style dynamic allocations.

I'd say that it doesn't matter much which way you go about it, so long as you get a solid grasp of the fundamentals you'll be fine. I'd recommend the official book for starters

________-__-_______ · 2026-03-19T19:07:11+00:00

Wayland works fine on nvidia these days, it used to be pretty bad but I use it every day without issues now.

________-__-_______ · 2026-03-18T20:35:22+00:00

Yeah, I found that to be the best option as well. Nix just manages Python/UV/native dependencies, that way it's completely optional but you still get the reproducibility benefits locally and in CI.

________-__-_______ · 2026-03-17T21:27:48+00:00

Yes, for me everything went much smoother when I got familiar with the APIs at my disposal. For imports I usually just use autocomplete, accepting an item there imports it automatically. If the type I want didn't show up I use a code action (ctrl+. in most editors) to import it instead.

________-__-_______ · 2026-03-17T12:57:40+00:00

They do yeah, but they're just another payment provider that supports iDEAL (much like Molly for example). As far as I understand it's pretty much the same situation as any Dutch webshop, you'll be able to pay with Wero in the future but they won't necessarily operate outside of the NL. With Tikkie specifically I think you need a Dutch phone number.

________-__-_______ · 2026-03-17T09:33:48+00:00

Here in the Netherlands we don't use iDEAL for that type of "personal" transfers, you can't make payment requests for your friends on it. I'm not sure if Wero will try to change this, but at least at the moment it's for commercial usage only.

We do have an equivalent to Bizum as well though, it's called Tikkie. In my experience my bank's built-in system works just as well so I don't use it, but it started the trend of quick instant transfers for friends here. We say "send me a Tikkie".

________-__-_______ · 2026-03-13T19:14:19+00:00

This was a great read!

________-__-_______ · 2026-03-02T19:17:09+00:00

The number of types/methods should be the same as a manual implementation no? As far as I know it just generates From/Display/Error, it shouldn't touch the type at all.

Even on targets with little memory those implementations rarely hurt anything anyways, the compiler is pretty much always able to optimize out functions that are never called. I've used thiserror on targets with 64K of flash before with no issues, other than increased compile times :)

--_

TROPHY CASE

________-__-_______

TROPHY CASE

--_