boris

EPYC is compared to a previous generation Xeon with lower TDP (105w vs 155/170w) and slower RAM (2400 vs 2666). The Xeon server is more expensive probably because it has 4x the amount of RAM.

Edit: actually, this is a dual Xeon machine so its TDP is slightly higher than EPYC's.

Just add this as a second line?

  trap "exit 1" ERR

Yes, all valid/good points, thanks. We are packaging external libraries that we need ourselves (libmysqlclinet was "fun" -- it is actually a C-library with C++ implementation details). And getting some "critical mass" of packages done by us is also something we are considering.

Good question. Currently you will need to email a git repository URL and tag you want published (e.g., https://git.build2.org/hello/libhello.git#v1.0.0) and we will publish it for you (or you can provide a package archive if you prefer).

For the next version we plan to implement a CI/CD bot which will poll your git repository for tagged versions and automatically test and publish them to cppget.org (there will be some sort of a control file that you will be able to use to specify which tags should be published where, etc).

Yes, see https://build2.org/build2-toolchain/doc/build2-toolchain-int...

> if this can be used with a private repository

Sure, you can run both archive-based and version control-based (git) private repositories without any restrictions.

I don't believe we can get to thousands of packages by packaging a substantial part ourselves -- we will just get bogged down in this instead of building a decent toolchain. Instead, the "secret" I believe is to make creating, testing, and publishing C/C++ packages as easy and frictionless as possible. This is how you get to thousands of packages and this is what we are trying to do.

Why would you go run (hunt) if there is still stuff (food) in your gut.

Ah, GNU make second expansion... glad to see someone else appreciates it ;-).

Right, RAM is part of the SoC... that probably makes the idea pretty much a no-go.

Or even 4G. Would be nice to have a high-memory variant especially seeing that that would require zero changes in the OS unlike most othet hardware variations.

>We use a magjack that supports Power over Ethernet (PoE), and bring the relevant signals to a new 4-pin header. We will shortly launch a PoE HAT which can generate the 5V necessary to power the Raspberry Pi from the 48V PoE supply.

This is nice though I personally wish they used the same Silvertel PoE module as Arduino which you just solder onto the board. Plus their PoE hat has a spinning fan.

Writing your own, general-purpose build system is a hard, multi-year project (spoken from experience[1]).

[1] https://build2.org

Had a similar question (with a reply from someone from Intel):

https://www.reddit.com/r/cpp/comments/7gjmgd/intel_offers_pa...

> Everything is string-ly typed and you can only build up a thing to a certain level of complexity easily.

Yes, make was designed for the 1970 world, where all you care about is building simple utilities on Unix. There was no today's complexity (out of tree builds, cross-compilation, etc) nor "alien" platforms like Windows where people have spaces in their paths.

What we need is to redesign make to handle today's requierements. And this is what we are trying to do with build2.

>... wrap make to make it easier to make ...

I think there is a deep truth in (unintended?) pun: those who don't understand make are bound to reinvent it, poorly.

Check build2, it has a sane build model and syntax and comes with integrated package manager/repository, similat to Cargo:

https://build2.org

>I've had to answer the "why not just use github?" question a lot of times.

We have a FAQ entry for that:

https://build2.org/faq.xhtml#github

There is a fresh build tool that supports modules in the big three (GCC, Clang, and VC):

https://build2.org

I wouldn't call a limit to two VMs friendly. Plus Apple doesn't make suitable hardware for this.

Shameless plug for open source C/C++ projects: if you add support for the build2[1] build system, we will CI[2] your project on Mac OS (as well as Linux, Windows, and FreeBSD with various versions of GCC, Clang, and VC) for free and without any limits.

For those curious about the setup, we have our own infrastructure that runs a custom in-memory Linux-based OS called Build OS[3] that performs build tasks in throw-away VMs (KVM). This is used for all targets, including Mac OS (though we have to run Mac OS builds on a bunch of Mac Mini's due to Apple's licensing restrictions).

[1] https://build2.org

[2] https://cppget.org/?builds

[3] https://git.build2.org/cgit/buildos/tree/

It is being implemented by the big three (GCC, Clang, and VC). In Clang and VC it is already usable to some extent.

Could you summarize how you handle this in redo? Also what about the case where a header file does exist but is out-of-date and because of that triggers an error (e.g., version compatibility check with #error) -- how do you handle that?

There is work on a sane build toolchain (build system, package manager, etc) for C++: https://build2.org (full disclosure: I am involved with the project).

IMO, it's more important what's happening on the ground, that is, in the compilers, than the "official" status in the standardization pipeline. After all, we've had export in the standard and we all know where it went (in case you don't: nobody implemented it).

And on the ground things are looking pretty good: the big three (GCC, Clang, and VC) have modules supported to various degrees and are actively working on improving things.

I tried. The problem is standing without moving seems to be just as bad as sitting. As you tire you will start shifting weight to one leg and locking the hips to one side.

I then tried a half-reclined chair which was a bit better. Then I switched to a flat hard chair without back support. That was tough initially (more so than standing desk) but seems to be the best option so far. Other than moving, of course.

Mark & the gang thought they could build something better and so they went for it. Their ideas may be wrong, but they took a stab. Most of those criticizing Mir never go beyond mere talk. That's the main difference to me.

- Hey, Echo, send two thousand rand to Mike

- Ok, sending twenty thousand rand to Mike

- Noooooooo! Two thousand

- Ok, also sending twenty thousand to Nolan

No, its like using a nailgun A with nails Y when it's only guaranteed to work with nails X. Or like using a chainsaw A with chain Y when it says you should use X. But hey, at least you are not trying to use nails on a chainsaw... ;-)

With one big limitation: they must all run the same os kernel (so you cannot run say a Windows or FreeBSD container on a Linux host).

In fact, nobody guarantees that say Fedora will run on an Ubuntu-built kernel. Or even on a kernel from a different version of Fedora. So, IMO, anything other than running the exact same OS on host and in container is a hack.