mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

380K
active users

Garrett Wollman

Hey, it's Friday night! So what am I doing?

Oh, right, I'm waiting for rust to build. It'll be a while...

It'll probably finish some time on Sunday, this machine is ancient and slow and small and I would really do well to replace it with something more modern. I guess I could shop for a new build server (more affordable than the one I have at work, anyway).

(This poor old server is a 6-core Dell R415 from 2012 with only 16GB of RAM. It has served me pretty well but modern software is just too resource-intensive.)

I remember when I had to do all this stuff sequentially, on three different machines, and I'm glad that era is well and truly over now.

Update: gcc took nine hours to build. node only took five.
rust finally finished building after nearly fourteen hours, so now it's on to building llvm (two different versions), which have both been going for about four hours now. (Both depend on py311-recommonmark, which depends on rust.)

llvm requires a lot less temporary space than rust to build but I'm not sure how the heap footprints compare. I'm limited to four parallel builds on this machine because it doesn't have the memory -- sometimes it doesn't even have the memory for that, depending on whether the topological sort ends up scheduling multiple space hogs in parallel. Right now building qt6-declarative and webkit2-gtk3 in addition to the two compilers.

In case anyone's wondering (probably not) llvm15 and llvm17 are still building, now both at 16 hours 28 minutes in. Everything else that can be built has been, leaving just 24 downward dependencies of one or both of the two compilers.

llvm15 finally finished (llvm17 is still going). Just building the tarball for the package took 14 minutes 20 seconds (it's a *huge* package). apparently, `spirv-llvm-translator`, `qt6-tools`, and the expected `postgresql14-server` are the immediate dependencies that can now start building. I haven't the foggiest idea what `spirv-llvm-translator` is; apparently X depends on it for some reason.

Package build finished overnight. To my total surprise, firefox took less than six hours to build. The whole set (732 packages needing rebuild out of 1,345 total) took just under 46 hours.

I updated my decade-old hands-off remote HP DL160 westmere-era system to a modest ryzen 5600 one earlier this year. It was cheap, had a massive power consumption reduction, and was astonishingly faster. Yes, a desktop grade cpu in a budget server board (with decent IPMI/remote management, Asrock Rack x570d4u). But it was totally worth it.

It has never had a screen, keyboard, or media plugged in. It was remote installed literally by booting off a virtual DVD image from the freebsd.org https server over the internet. Mostly to prove to myself that the remote control was complete. Not that I particularly recommend it but I wanted to know for sure what the worst case was if I had to have somebody swap a board for me. It was actually easy.

I was tempted to get a used server via ebay, but this way I know its new hardware and should be good for 5-10 years before hardware age becomes an issue.

Also... compiling 4+ versions of llvm as well as gcc, rust and node all together is quite a stress test. Yay our ports system.
FreeBSD - The Power to Serve - Server - Desktop - Embedded
The FreeBSD ProjectThe FreeBSD ProjectFreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
@karinjiri @wollman I have two of these systems and use ECC RAM and the onboard NVMEs. They are so fast. And mine are also headless and were remote installed / managed. One has the 10gbit NICs, the other is the gigabit variant.

One went bad when I tried doing 128GB of RAM and they had an engineer ask me to ship him the board for him to analyze. They shipped me a replacement at no cost.

@feld @karinjiri My build system at work was donated by a startup that was liquidating and had to clear out their DC pronto, 72-thread Xeon in a Supermicro chassis. I put 512 GiB of RAM in it; the drives are boring Samsung SATA. It's still plenty fast enough that our (much smaller, non-desktop) package build is pretty much serialized. (Critical path is curl -> cmake -> rust -> llvm -> postgresql-server... most of the builders are idle before rust finishes.) Ofc everything in our DCs is headless.

@karinjiri Because I am bad at automation, almost all of my servers are built by cloning; I don't think I've run the actual official FreeBSD installer in more than 15 years. (This means, among other things, that we have a "nonstandard" ZFS root layout that doesn't play nice with boot environments.) Back in the mists of ancient time I made the i386->amd64 transition via `make installworld`, twice.

The coworker who did our Linux installer wants to do a FreeBSD one but I don't expect it to work.

@rsalz Because I need certain build options set in a way that the public package repository does not, and it's important to me to have a self-consistent package set (especially when I have to do things like upgrading postgresql, which is going to be in my future soon enough).

@rsalz Normally this would be a "set it and forget it" process but I forgot to start the build under screen so now I'm stuck with having that xterm open until it finally finishes. I also *just did* a build and wasn't planning on having to do this one, but I do want the updated Firefox ASAP. One of the unfortunate down sides of the switch to git is that you now have to update the whole repo at once; with svn I could just update the recipe for ffx and build only that, holding upward deps fixed.

@wollman I cannot imagine an environment that needs particular build flags that must be propagated from the compilers and languages on up. But that's okay, I don't have to. You've got it, and you know what you're doing. Good luck with that!

@rsalz Oh, they don't. But the build system is designed to ensure that all of the packages are consistent and build reliably from the recipe and configured options, which means rebuilding rust and llvm and everything that depends on them whenever curl changes. Poudriere doesn't know that curl is unlikely to affect postgresql-server through whatever long chain of dependencies, it always takes the most cautious approach to ensure there can never be an inconsistency.

@wollman It translates the SPIR-V intermediate representation for shaders to LLVM I think, unless it's the other way around. Maybe Mesa uses it somehow?