Live data from Hacker News

Show HN: Open-source x64 and Arm GitHub runners

ubicloud.com

61–70 of 128 posts

Re: Show HN: Open-source x64 and Arm GitHub runners

#61
I am hearing about Ubicloud for the first time and it sounds very good. I don’t have a need for a cheaper GitHub runner now, but I’ve been dreaming about a modern, less complex open stack alternative for some time. Also, having a cloud service combined with the open source product seem like a great fit!

Re: Show HN: Open-source x64 and Arm GitHub runners

#63
post #9

Congrats on the launch. Looks interesting. Quick thoughts on the landing page: - Pricing looks awesome. - I'm not currently the target audience because everything I'm doing right now is open source with free GitHub actions. - I'm left wondering what the catch is / why it's cheaper and faster. - Visual nit: lacking horizontal padding from 990px to ~1200px, a common window size on my 14" MBP. > Ubicloud is an open sour…

> I'm left wondering what the catch is / why it's cheaper and faster. I don't think it's very expensive to run a build server.

Not until it works. But when it doesn't you have an office full of people waiting for someone to fix that broken build server. In terms of lost productivity this disaster is very expensive. Over the years I have suffered only three hardware disasters. One was a NAS+backup screwup but other two were both related to build servers...

Re: Show HN: Open-source x64 and Arm GitHub runners

#65
post #24

Gitlab + Home laptop runners = free Been using this setup for year, very happy with it. I don't see the point of Github to be honest?

In a similar vein, using Gitea + self-hosted runners (including macos) here, very happy although we did do some of the work to make the "CI stack" (contributed back to gitea and act projects) so not totally batteries included yet. One thing that helps quite a bit imho is to avoid virtualization -- our approach is to run all CI jobs in containers, not VMs. Yes this has isolation implications, and requires some futzing to get docker-in-docker and docker-in-docker-in-docker to work (shout out to the Earthly team for figuring out how to host kind/k8s inside a container), but the "runs on any computer" property of containers (vs virtualization) is powerful. Want CI on your laptop? No problem. On a Windows machine? No problem.

Re: Show HN: Open-source x64 and Arm GitHub runners

#69
post #9

Congrats on the launch. Looks interesting. Quick thoughts on the landing page: - Pricing looks awesome. - I'm not currently the target audience because everything I'm doing right now is open source with free GitHub actions. - I'm left wondering what the catch is / why it's cheaper and faster. - Visual nit: lacking horizontal padding from 990px to ~1200px, a common window size on my 14" MBP. > Ubicloud is an open sour…

If we're doing nits, because this product looks cool, here are a couple of potential tweaks: > Imagine to do more I'd get rid of this. I don't understand the phrase, and it sounds like fluff. > Fast runs even at this price point I'd get rid of the "point". "Price point" isn't a synonym for "price", which I think is what's being attempted here. I'd be tempted to just have no tagline, and retitle this section "Faster t…

Nitpicking is contagious. Once one does it, then immediately others feel compelled to do it too, me included...

Their pricing page looks amazing. Not because of any funky UI stuff but because of the slight displacement of the decimal point.

Re: Show HN: Open-source x64 and Arm GitHub runners

#70
post #63

Earlier quoted context omitted.

> I'm left wondering what the catch is / why it's cheaper and faster. I don't think it's very expensive to run a build server.

Not until it works. But when it doesn't you have an office full of people waiting for someone to fix that broken build server. In terms of lost productivity this disaster is very expensive. Over the years I have suffered only three hardware disasters. One was a NAS+backup screwup but other two were both related to build servers...

This reminds me. It must have been 2009ish. I was at Microsoft. Part of the code I was responsible for ran on the Windows build servers. This code was triggering a kernel bug in the Windows registry. The only way I knew how to reproduce it was by building Windows. Because thousands of Windows builds happened per day, maybe 1 of them would hit it every 1-3 days.

The way I got it in a kernel debugger was to constantly run the problematic race condition inside a VM, when it detected that it hadn't hit, it would roll back the VM to a save state of the code already running in progress ... Took an overnight run to hit it on a machine in the office.

All that said, I'd still say it's not very expensive to run a build machine.

Post reply on HN