Live data from Hacker News

Show HN: Open-source x64 and Arm GitHub runners

ubicloud.com

81–90 of 128 posts

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

#81
post #18

Earlier quoted context omitted.

The docs still say the Elastic license is used but looking at https://github.com/ubicloud/ubicloud/blob/main/LICENSE it looks like the project might have switched to GNU Affero General Public License v3.0 in the last day.

thank you and that's correct, just updated the docs as well.

Wow. When you guys first launched this was my biggest concern. This is absolutely awesome, thank you team!

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

#83
post #72
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…

Thank you for your feedback! I've just made several edits to the text for clarity; will also fix UX bugs and do bigger a update in the upcoming weeks.

big improvement! good luck

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

#84

Am I missing something or GitHub can easily block all 3rd party runners if they want to?

Of course, but doesn't GitHub embrace these runners?

Depends on how you define "embrace". Services like Ubicloud violate the GitHub Terms of Service.

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

#85
post #2

Hi there, I'm Ozgun, one of Ubicloud's founders. We have dozens of customers using Ubicloud runners in production today. We’re now designing our caching layer (Docker instance registry, Docker layer cache, or package cache). We wanted to put this out there for any comments. Also, if you have any points related to the broader topic of an open and portable cloud, please pass them along!

Yes, please do what Depot does and put fast persistent disks close to builds to cache docker layers. Github action runners and circleci and all the others adding expensive network calls to manually cache layers has always been such a time sink and I think moves lots of people to remove caching entirely.

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

#86
post #57

Earlier quoted context omitted.

> so for us it's been faster to disable cache entirely and just redo everything on each build. I wonder what the consequential "carbon footprint" of this is, but at scale for all companies/all jobs of similar nature

Also consider the carbon footprint of using caches! Apparently it takes longer, because it has to send/recv more data, compress and decompress, cause load on other systems ... It's really kinda impossible to judge the carbon footprint for these kinds of things, and if it's justified. Consider the carbon footprint of all the dumb AI feature rolled out at Facebook, Google, etc. Consider the carbon footprint of everyone…

There’s a French think tank called “The Shift Project” which actually produced a report estimating CO2 impact of data transfer a few years ago [1]!

The numbers are obviously very rough; there’s a LOT of factors to consider and which vary from one node to another. But the methodology is quite comprehensive, e.g. they factor in power consumption of the end user’s device while waiting for the data to transfer over the wire

Green software engineering is interesting to me because it seems like a good way to impact greenhouse gases _without_ requiring consumers to change anything about their lifestyle (which is the hard part of climate change…) There’s a cool presentation from Rasmus Lerdorf from around the time when PHP7 released where he estimated a 50% adoption rate of PHP7 would result in a saving of 3.5B kg CO2/year iirc, purely because of the compute efficiency gains from PHP6 -> PHP7.

I used their numbers to calculate that swapping our CI/CD clones at my day job over to shallow clones saved (maybe) 5.5 kg/week of CO2 emissions [2]. Not quite as impressive as the PHP7 figures, but I still think it’s kinda neat.

[1] https://theshiftproject.org/en/lean-ict-2/

[2] https://sophiabits.com/blog/the-cost-of-bandwidth

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

#87
post #4

Our biggest GHA fees come from running on MacOS. Do you offer MacOS as a managed service (or plan to?) and how much cheaper is that than GitHub?

Biggest issue with MacOS is that it requires a physical Mac (not virtualization) and IIRC the licening from Apple requires a minimum "rental" period of 24 hours or something like that Edit: the TOS for OS X says this: 3. Leasing for Permitted Developer Services. A. Leasing. You may lease or sublease a validly licensed version of the Apple Software in its entirety to an individual or organization (each, a “Lessee”) pr…

What I did for work was, getting a Mac Mini and set up multiple self hosted runners in Tmux (very hackish, I know). The builds became faster (and cheaper) because each run no longer had to download the dependencies again.

Of course, hosting myself means I also gotta own the uptime of it..

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

#88
post #4

Our biggest GHA fees come from running on MacOS. Do you offer MacOS as a managed service (or plan to?) and how much cheaper is that than GitHub?

Biggest issue with MacOS is that it requires a physical Mac (not virtualization) and IIRC the licening from Apple requires a minimum "rental" period of 24 hours or something like that Edit: the TOS for OS X says this: 3. Leasing for Permitted Developer Services. A. Leasing. You may lease or sublease a validly licensed version of the Apple Software in its entirety to an individual or organization (each, a “Lessee”) pr…

How does Github Actions get away with this? They certainly don't bill and provide the machine for 24 hours for each CI run.

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

#89
post #77

Earlier quoted context omitted.

Any timeline for supporting repositories in personal accounts? I'm willing to create an organization and move the repository, but I won't bother if it's right around the corner. macOS ARM runners are a gamechanger given the offensively high pricing GitHub offers them at.

We're not prioritizing personal accounts at this point, one of the reasons being to limit spammy accounts. Sorry about the hassle - you sound like a genuine user.

No worries. I've already created the organization; I doubt this will impact many serious users. I look forward to seeing your new Mac support on HN as a top level submission. Since GitHub doesn't give free macOS ARM minutes at all, this should be immediately interesting to anyone running such builds.
Post reply on HN