boris

You may want to check build2[1] then. As a bonus you also get a Cargo-like package/project manager (but with a real build system underneath). Full disclosure: I am involved with the project.

[1] https://build2.org

We did start with C++ thinking (correctly, IMO) that if we can build C++, we can build pretty much anything. But build2 is a general-purpose build system, for example:

https://build2.org/build2/doc/build2-build-system-manual.xht...

https://github.com/build2/libbuild2-rust

I found it to be an "atmospheric" (for the lack of a better word) book -- you understand by feeling as much as by, well, direct understanding. Kind of like Master and Margarita (which some people also find pedestrian).

The need for speed is the direct result of worse is better.

Yes, just tried it the other day and it's great. Not a hint of acidity. Now need to decide which one I like best.

Second that. As much as I want to believe a $10k La Marzocco is absolutely essential to good espresso, a $100 Nespresso machine and Kazaar roast is the best espresso I've ever had.

FWIW, for the build2 project we host our own CI servers on premesis and the power supply is supplemented by a solar array. We have configured our daily package rebuild window to coincide with the maximum solar output so that on a sunny day it is all done using renewable energy.

If you are interested, Peter Thiel's 0 to 1 has more on this and with more depth. As he says, we are the "indefinite optimists", expecting the future to become better somehow, rather than "definite optimists" that expect to build the better future.

And the rest of the book deals with why it is more often than not painful. In summary, it's complexity. Brooks argues that software, being a pure thought-stuff, is also the most complex thing we attempt to build. And it's even worse now than in his time with any concern for quality taking a back seat in the face of competitive pressures. So it's not really surprising that slapping together ever more complex systems out of ill-fitting, purely-designed components is not fun.

> ... maintained by people that believe they and their work are utterly infallible. Hence why to this date they have not made it possible to detect musl ...

Yes, and they are every bit as fallible as anyone. Here is an example of a pretty pedestrian bug: https://github.com/build2/build2/issues/50

And that's a pity, really, since otherwise it looks like a reasonable implementation. But this dogmatic "we know better" attitude now triggers an allergic reaction.

Yes, this struck me as a crazy idea for C/C++ development, embedded or not. What if you save something intermediate not meant to be compilable/testable? I for example have a deeply ingrained habit of saving my changes all the time going back to the floppy disk days when computers would regularly crash/freeze.

> This is the bleeding edge; these devices have only been available for 13 weeks [...]

Shouldn't these devices have been tested by AMD and motherboard manufacturers for months before they were released? Including on workloads like Prime95 which are well known to uncover system instabilities.

Keep in mind also that this is not the first time in the Zen/Zen2 history that AMD has shipped buggy products: there was the segfault bug, the random number generator instruction bug, and the unbootable Threadripper on recent (at the time of release) Linux kernel. The worst part, to me personally, is that they were all "surface bugs" that could have been detected by AMD with a little bit of testing.

I've been wondering why Supermicro isn't releasing any Threadripper motherboards (while they do for Xeon-W). Maybe this explains it: the consumer CPU business at AMD is a circus and Supermicro wants none of it?

Good example of how we develop software these days: instead of fixing GNU make by ripping out that antiquated pipe-based jobserver and replacing it with proper multi-threaded parallelism[1], we rather optimize the operating system to make the antiquated stuff work better.

[1] Having hacked on GNU make I know this won't be easy (it's quite a mess). In fact, it would probably be easier to replace it entirely and fix some of its other deficiencies in the process.

Interesting how compilation benchmarks do not scale at all from 24 to 32 to 64 core Threadrippers. Neither Linux kernel nor LLVM compilation. I wonder why it's so bad.

We (the build2 project) use it in our CI infrastructure for VM storage. For every build we make a snapshot of a VM, boot it, build, drop the snapshot, repeat. So we are talking about making/dropping snapshots every couple of minutes 24x7 for months without a reboot. We haven't had a single issue.

Oh, there is plenty of drama on /r/cpp/.

> being in an exhausting fight against terrible odds by yourself [...] eat the shit necessary to do it

I think (from experience) that's a pretty accurate way to describe a software startup.

And so as you find yourself on the floor (continuing with the fight analogy) time after time, the question starts to creep in: "What's the purpose? Am I just wasting my life?" The usual answer is to enjoy the journey, the experience (maybe getting some flow), what you learn in the process (and you do learn a ton, no question there).

But the thing is, the further along you are, the less it is about learning or flow and the more it is about eating shit -- figuring out how to fix issue after issue after issue, often because of other people's poor decisions. In a sense, you become a lean and mean shit eating machine. And so the question starts to creep in again.

Thanks. Seeing that we are sharing ECC overclocking information, this post has some useful information for Kingston RAM: https://old.reddit.com/r/ASUS/comments/cw74rl/asus_pro_ws_x5...

Thanks for the info. Is this the same motherboard as OP?

Could you share the specs for your build, specifically the motherboard and RAM models. Also have you verified that ECC actually works?

I am tempted to build something similar but AMD's wishy-washy ECC guarantees as well as Linux-specific issues make me unsure.

In build2 we do something similar for snapshot versioning between releases by incorporating the date and commit id into the pre-release component of semver. The result is a unique, properly ordered version for every commit in a project (we call it "continuous versioning"). If anyone is interested, here are the details: https://build2.org/build2/doc/build2-build-system-manual.xht...

> I often wonder how many of them could actually speak at depth, extemporaneously, about the subect of their talk or if their actual knowledge collides with the end of their slides.

Was not my experience at CppCon at least. In fact, the problem is usually that they are pretty pedestrian presenters and/or run out of time. But most clearly know what they are talking about. Maybe this is different at other conferences though.

There is build2. It has "high-fidelity" (instead of hermetic) builds meaning that besides sources it keeps track of changes to options, compilers, etc. This gives you similar benefits at a fraction of the cost. There is no distributed compilation or caching yet but it's coming. In other benefits, it doesn't need Java or Python (or any other "platform").

Here you go: https://www.infoq.com/presentations/os-rust/

You can go a step further and factor the build system core into a library and provide dynamically buildable/loadable modules. This way you can reuse the same core in several drivers (different frontends, build-by-convention like Cargo, etc) or embed it into IDEs. This is what we did in build2[1][2].

[1]https://build2.org/release/0.12.0.xhtml#build-system-modules

[2]https://build2.org/release/0.12.0.xhtml#library-context

We did in build2[1]. Specifically, we have a notion of target type which may not be path or mtime-based. For example, one such target type is alias (something that is achieved in make with PHONY targets). So you could define, say, a url target type. Then you can implement a rule that knows how to perform a certain operation on certain target types (we've also generalized a notion of operation so in build2 test, install, dist are operations, not targets).

[1] https://build2.org

- Jeff Dean once caused an AI winter so cold, even humans lost their intelligence.

Isn't this how things work in dynamic languages like Python?

I would recommend staying away from OVH for anything important (e.g., a mail server). While the service is fairly reliable, when things do go wrong (like an IP network that you share with others get blacklisted because one of the IPs is part of a botnet), their support is useless. They do respond and are very polite, but nothing actually gets fixed and you eventually realize they are just wearing you down hoping that you give up.