To call the current release cycle sub-optimal would be rubbing salt into a non-zero gradient wound.

Until recently, the process was something like

• The dev community on #tari-dev would notice that the codebase’s chakras were properly aligned, it was a Tuesday, or that it had been three weeks since the last release. Sometimes a combination of all three.
• This would trigger a flurry of activity involving manually building a set of binaries, OSX packages and Windows installers.
• These builds would then be uploaded to the Tari website and everyone would heave a big sigh of relief before noticing that it was already Thursday and the chakras were all mis-aligned again.

Today the flow is so much better:

• The dev community on #tari-dev notices that the codebase’s chakras are properly aligned, it’s a Tuesday, or that it’s been three weeks since the last release. Sometimes a combination of all three.
• The lead maintainer tags the new version and pushes the tag to Github.
• Magic happens.
• New binaries appear on the Tari downloads page.

This process has saved many hours of manual labour among dev community and freed up much needed time for them to work on their Hearthstone laddering and CT meme game.

That said, things aren’t perfect yet.

There are only automated builds for:

• Mobile libraries
• GNU/Linux executables
• OSX executables (not the full package installer, just the node binary)

Still missing are:

• Windows binaries / installers
• OSX installer packages

(Psst: If you’re a script wizard and develop on a Mac or Windows machine and want to contribute/improve the Github actions to fill these gaps, let us know!)

So why is this important?

Granted, while it’s not the most mentally taxing collectible card game out there, Hearthstone is still very popular, and if you’re not tracking the meta, your deck will be absolutely crushed.

It’s also pretty helpful in fixing the “I keep getting illegal instruction crashes” issue that has been affecting quite a few people.

Let’s pause for a second and let me mansplain what’s happening if you get this error.

As you might imagine, Tari’s code employs a lot of intensive number crunching. Let’s say there’s some code that requires us to multiply two columns of numbers together. We could have the compiler generate a loop and call MUL (for multiply) for every pair. Every CPU knows how to do this. But we’re building the code on a machine with a cool new instruction, FANCY_MUL that can do this in one go, and it’s 100x faster than the loop version. Obviously, we want to use this instruction and the compiler just happens to be smart enough to recognise that it can replace the loop with one instruction. So it does just that and the Tari community releases these blazing fast binaries that run so well on newish machines.

Clever Tari devs!

But now you come along and run that code on your older machine. Everything works fine until it hits the FANCY_MUL instruction. Your CPU says “I don’t know what that is! Screw it!” and whiny rage quits. Your OS is only slightly more polite and dumps an Illegal Instruction (core dumped) error into your terminal before quitting.

Stupid Tari devs!

This is where the automated builds can help. Not only do automated builds save a ton of time, it’s now also fairly simple to configure a bunch of builds for a range of architectures and CPUs! In fact, if you hop over to https://tari.com/downloads, you’ll see a few new entries.

There are tari base node binaries for

• older than 7 years (look for links containing x86_64)
• 4-7 year old CPUs (look for links with ivybridge)
• recent CPUs (skylake)

There are plans to refine the process and add even more architectures and supported chipsets in the future, but this is a great start. In particular, if you’ve been getting the Illegal instruction error on Linux, please try and run the x86_64 safe version and let us know if the problem goes away. The dev community really relies on the wider community to test this sort of thing.