Fastmac – A macOS instance or Linux shell | Hacker News Reader

Fastmac – A macOS instance or Linux shell

github.com

216 pointstosh88 comments

Interesting idea but likely in violation of the GitHub Actions ToS [0].

> Actions should not be used for:

[...]

> any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used.

At the very least, I recommend you highlight the Actions ToS to your users lest they miss this restriction.

[0]: https://docs.github.com/en/github/site-policy/github-additio...

One could peruse CircleCI, which has the ssh feature built-in, and also the widest support of macOS versions x Xcode combinations.

All others CI providers are content with Y and Y-1 versions (at best) and seem squarely focused on build-for-iOS CI (Including Travis is hopelessly slow, when it’s not outright broken)

Many thanks - my bad for not reading the ToS closely enough. I've highlighted the relevant section at the top of the README now.

I think (AFAICT) it's still OK for what I use it for, which is building and testing conda packages interactively, as long as I copy the fastmac files into the same repo as the conda packages I'm building. I'm sure there's plenty of other folks who would find similar things helpful.

Bit risky with a company org if they decide it violates TOS does that just impact the offending repo, or the entire org?

Better to ask for forgiveness than permission.

Not the case with things like Google accounts. Probably not worth the risk for GitHub accounts either.

Unless you dick around in someone elses org and get them booted.

There are a lot of things where that adage doesn't work.

Risking losing an important account due to TOS violations is one.

Also, you don't see a lot of people in jail saying that.

The people not in jail are the ones who asked for forgiveness.

This is actively encouraging people to abuse a free service that many people depend on. It's incredibly irresponsible to see it posted here.

Stealing a worker for up to 6 hours likely running on real Apple hardware because that's how OS X is licensed, man, there are no words. Free CI is difficult enough to supply as it is without freeloaders tying up a limited pool of workers because they're too lazy to run something locally

It should be noted that we're talking about Microsoft's resources here, not some independent CI company or startup. While I don't wanna encourage anyone violating any ToS I think the moral situation is a bit different for a tech giant.

It's not about Microsoft's resources, it's about holding up those resources from others

The resources are effectively limitless, it’s not a big deal.

It's a tragedy of the commons situation. Microsoft might be _able_ to provided effectively limitless funding to power these free workers, but if enough people choose to abuse this, Microsoft might no longer be _willing_ to provide that funding, so everybody would be deprived of a useful resource because of the bad actors.

Yeah, Microsoft does some very strange things. Particularly, I'd like to draw attention to how skydrive/one drive used to have 25? GB and not only did Microsoft lower it to 7? But it said it would delete files over the limit. I have gone over the limit on Dropbox and it just stops you from uploading until you bring your storage within quota. Google Drive does the same iirc. Microsoft is just outright terrible.

I would even argue that rampant abuse might actually be threatening to GitHub the company.

MS may still be the type of company to change it’s mind about upholding the principles that GitHub runs on.

You mean MacStadium resources, since that's the 3rd party company that provides the actual backend service.

I don’t mind the post because it’s a cool hack and could be useful for debugging workflows, but I do agree we should refrain from abusing it as a free shell.

> This is actively encouraging people to abuse a free service that many people depend on.

The internet was built by phreakers and pirates. This statement shows how far we've since fallen.

There's nothing of the spirit of the early hacker days in this repo, it's following GH's documentation and cutpasting some tunnelling instructions. I think it says more about the common misunderstanding of what hacking originally meant that this comparison was attempted at all

(FWIW, spoken as someone who spent many months wardialling by hand and poking around as the rest of the household slept during his school days)

I didn't cut and paste any tunneling instructions, or indeed any instructions at all.

which phreakers and pirates built the internet?

I'm pretty sure it was built by the military and universities.

Wow, Good Hack. I also noticed that using so would violate Github action's TOS.

I run macos in qemu/kvm . works very good.

https://github.com/foxlet/macOS-Simple-KVM

Wow I didn't know you could do this. I thought OS X was tied in some way to Apple hardware (i.e. you can emulate the CPU but they tie it to other hardware).

Is this how Github actions and other CI services work? For some reason I thought they had to buy a bunch of Apple hardware ...

> I thought OS X was tied in some way to Apple hardware (i.e. you can emulate the CPU but they tie it to other hardware).

It is, but very weakly - basically a secret string stored in the SMI.

> Is this how Github actions and other CI services work? For some reason I thought they had to buy a bunch of Apple hardware ...

You can virtualize MacOS, but only on official Apple hardware. There is likely a fleet of Mac Pros or Mac Minis somewhere running real hardware + VMs.

EDIT: Read "You can ..." above as "You are authorized by Apple and can legally virtualize MacOS". You can run OSX on virtually any hardware in a VM, but doing it at scale or in a commercial setting will probably be a bad idea from a legal perspective.

OK so by "can" you mean "according to Apple's TOS" ?

Because it seems like you "can" in the technical sense (although I didn't try it, I looked at the code and it looks legit)

I imagine that a small CI service could start with the QEMU solution unofficially, but they would likely have to switch to Apple hardware before Apple got wind of it ...

You couldn't hide a macOS CI service from Apple for long. You can also get old Xserves and Mac Pros for quite cheap.

New versions of macOS deprecate support for older hardware. Sierra dropped support for Xserves.

> You can virtualize MacOS, but only on official Apple hardware.

legally only on apple hardware. It does actually work fine on normal PCs though.

> It is, but very weakly - basically a secret string stored in the SMI.

Which, incidentally, is "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"

Interesting, did some Googling on this and apparently they tried to protect the haiku in court as trade secret:

https://www.rcfp.org/wp-content/uploads/imported/20120105_20...

(Direct link to PDF)

GitHub uses MacStadium (https://www.macstadium.com/), a cloud provider that exclusively runs Macs mini and Pro, in compliance with Apple's license.

Any idea of this could run Snow Leopard?

I'd be curious to run that too. That was the very last release of macOS I really liked. Everything from that point on went down hill.

> shelling out thousands of dollars to buy a Mac Or you can buy one for a few hundred and that works fine too...

It's a nice hack, but if you build software for Mac it really isn't more expensive than building software for Windows for example.

If you want to sign/resell/other_thing_here that's a different story, but not related to your shell or building.

I built it because I needed to build and test conda packages easily. Without it, I just wouldn't have bothered and would have only created Linux versions.

I built and maintain dory[1] which supports macOS, but I haven't had a mac to test with in many years, and I'm not giving any more of my money to Apple (I happily would if they respected my freedom, but that's not likely to happen so I don't usually mention this caveat).

However I care about the humans who benefit from the software and run on mac, so I try to maintain support. This might be a great way for me to actually test instead of asking the community to test for me :-)

[1]: https://github.com/FreedomBen/dory

Building for mac is at least marginally more expensive. Especially if you're a mobile dev. I find it utterly galling that if I own an iPhone, I can't install my own software without buying an apple computer and paying apple to let me be a developer for the two devices I bought. And CICD world has definitely improved but since Mac doesn't allow VMs you can only only build on hardware.

For example, paying for build minutes via GitHub actions for OSX costs 5x as much as windows and 10x as much as Linux.

Is it? You buy a 500$ computer and off you go, no extra costs. Same if you get a computer for Windows or Linux. Same if you target a different device, you still need to get that development system, regardless of the vendor.

$500 for what? The current Mac Mini with an i3 and 8GB is $800 and it isn't really powerful enough as a dev machine. Equivalent Windows computers are much cheaper. If you're an organization, you're buying dozens or hundreds. And just buying workstations isn't the only thing you'll need.

Why do you need to buy a current Mac Mini? A Mac Mini from 2014 does the same job. And how is a i3 not enough? Unless your time costs a lot of money it doesn't really matter if your code compiles 20% faster or not, does it? And when your time is very valuable and you make money with your software, an expense to make that happen seems rather trivial, right?

Also, if you are an organisation you're not going to cheap out on your tools (at least not where I'm from). So your multi-thousand workstation that delivers multiples of that in revenue is really not that big of a deal.

There is one, and only one case where it's a problem: if you don't make money, but do want the latest and greatest and access to a commercial platform. And in that case it sucks that your values and wishes are not aligned with the commercial interests, but that's life.

You can’t legitimately make excuses for Apple’s terrible CICD support. If I was an Apple engineer I’d be ashamed of how bad it is. I thought Windows was a pain in the ass but they’ve stepped up and they’re almost done with containerized Windows.

Is it gonna take 10 more years until we have viable test environments for Apple? 15? At this point I’d say it’s more likely they’ll never bother. There can’t be any other reason to be this late.

I'm neither 'excusing' for anyone nor talking about CI and CD. But if you want to talk about it; how about you talk about MSBuild. Or the lack of sources in Windows.

The point is that someone makes an invalid statement about availability and/or cost. Just because you wish something doesn't mean every company in the world is bad for not supplying exactly that. (they are of course bad, but for other reasons)

Not everything can be the same happy build systems we're used to. That's not a bad thing in itself as a mono-culture has plenty of problems all by itself.

> Or the lack of sources in Windows.

What's released as Darwin and XNU often is several years behind what Apple is currently shipping if they choose to release parts of the source at all. The stuff that actually matters on macOS isn't open source.

> Why do you need to buy a current Mac Mini? A Mac Mini from 2014 does the same job.

Because in a year or two, macOS will deprecate support for the machine[1].

[1] https://en.wikipedia.org/wiki/MacOS#Hardware_compatibility

Well, then get a 2018 model, also available second hand cheaply. It's not the point. You can also get a laptop or iMac or whatever.

The point is that you can make it as difficult or as easy on yourself as you want. Yes, proprietary systems and commercial vendors are going to add to the difficulty to some degree when compared to open source community systems, but that's a known fact and has very little to do with any specific vendor.

> but that's a known fact and has very little to do with any specific vendor.

Yet I can still run Windows 10 on a computer that I've had in my closet for the last 15 years.

Look up AltStore.io.

I really wish Apple were more developer friendly. I'd like to have macOS versions of my free software projects but I don't own a mac so I can't support macOS.

Not only do you need a Mac, you have to pay Apple $100 a year for the right to distribute software to your customers, and you need an iPhone or iPad to complete the two-step verification on your developer account[1].

[1] https://news.ycombinator.com/item?id=24446970

This is a weak argument. If you can’t shell out $100 a year then you don’t really care about your Apple customers.

The argument about needing Mac hardware is only slightly stronger, but again if you’re serious about the Apple market, you’ll find a way to get some kind of hardware at a price point that works for you. Unfortunately some developers think that price should be $0, perhaps simply spoiled by the idea that building software is some noble pursuit that should always have no costs associated with it, only pure profit. Nevermind that the true biggest cost is the ever increasing amount of time that must be spent writing and maintaining code, which can easily run in to the tens of thousands of dollars if you go by the average developers salaried rate.

For smaller open source projects, this creates a huge hurdle. Google Play requires a one time payment and the whole stack can be run on any computer. The barriers are even lower to get going with supporting Windows, Linux and *BSD.

Meanwhile, Apple wants you to have a Mac, pay $100 a year for the privilege of being able to submit apps to their review process.

To release for Mac you don’t have to, you can release out of the store, using java or python or some other language. Your users will have a big warning though. I think the notarization for Mac OS to get rid of the warning has no semi-editorial approval process but then you still need the Mac and the $100 (per year).

You need a Mac, to pay $100 a year, and to pass the Notarization process. For many open source utility apps that give customers greater control of their hardware, those apps will not pass the Notarization process because they touch things like private APIs.

The end result is the user is misled by macOS into thinking that the software they want to use is either broken or malicious, and they are left being unable to use their computer in a way that Apple doesn't like.

> This is a weak argument. If you can’t shell out $100 a year then you don’t really care about your Apple customers.

It doesn't matter how much money you give Apple, because if they don't like your app, then you can't distribute it without macOS treating it likes it's radioactive.

To me, it seems like Apple doesn't really care about its customers when it doesn't let them run the software of their choosing with ease.

You might not have "Customers"

$100 is a barrier to entry for someone who is distributing software that they give away for free. It's not a high-bar but it's still a bar. If that software would otherwise work except for the fact you didn't pay Apple, it's kind of shitty.

In some countries, it can become a high bar.

That person misunderstood something along the way. Enabling 2fa requires an apple device and a phone number, but a mac counts as an apple device and the phone number is just for SMS. No iPhone is required.

This is not so different from needing a Windows machine or Android device to develop software for Windows or Android.

(I suppose there’s an argument for making VMs available for development like Microsoft does [1] not aware of a comparable offering from Apple.)

[1]: https://developer.microsoft.com/en-us/windows/downloads/virt...

> This is not so different from needing a Windows machine or Android device to develop software for Windows or Android

You don't _need_ a Windows or Android device. The Android sdk provides the Android emulator, ms has their vm images, and for a cross platform oss tool, you can often get away with just cross compiling and user bug reports for Windows.

You may want a physical device for testing, but this is different to Apple's physical hardware _requirement_.

This would be great for testing apps that run in a terminal. However, most people who build macOS apps aren't building these types of applications. So, they'll still need to shell out the $$ for a Mac running Xcode.

This isn't necessarily true. For example, you can write GUI applications with Qt, QML, wxWidgets, GTK, IMGUI, or SDL without having to use Xcode, if you use a language like Python. I believe this applies to Electron, as well, but I haven't used it on a Mac.

You can but they will never look as native as xcode/objc apps.

wxWidgets uses native widgets on macOS.

Lots of open source developers contribute to cross-platform libraries and dev tools. Testing/debugging on OSX is a significant hurdle for those of us who don't buy Apple hardware, and that increases the chances that users encounter issues before developers, thereby degrading their experience.

macOs works fine in a VM, there's no need to buy mac hardware.

If you want something that runs 100% locally with a persistent environment, take a look at macOS-Simple-KVM [0]. With some trivial tweaks in virt-manager as well as the guest OS, you can easily create a local macOS VM that you can SSH into from the host machine (EULA concerns still apply). This also allows you to pass-through devices such as USB devices or a secondary GPU to achieve near-native graphics performance in your macOS VM.

[0] https://github.com/foxlet/macOS-Simple-KVM

Oh, this could be really useful for debugging actions! A lot of time when a workflow fails, I wish I could ssh into the failing build to investigate what went wrong. With this, I could save the whole build tree in an artifact, and restore it on-demand with a tmate session to see what happened!

I’m really frustrated with actions coming from circle and the ability to SSH in.

Also the Act project to run locally is a joke. Everything runs in the node image.

GitHub has the repo for all the packer scripts open sourced I just haven’t had time to make Dockerfiles from them. They really should offer that in an official capacity.

I'm guessing this isn't directly helpful but I believe sourcehut does ssh-able CI as well.

Yea it wasn’t my decision to use GH actions. That’s good to know about source hut!

The annotations are really nice but I think that’s an API that can be used from other CI providers.

A very capable 2020 MacBook is $999 new and $849 certified refurbished.

Or macincloud is $20/month with GUI access.

That's a lot of money for the vast majority of software developers outside of the SV bubble.

Really? I’m geographically as far outside of the SV bubble as geographically possible and still live in the US. $799 for a Mac Mini or $999 for a MacBook Air is not some super luxury that most middle class Americans can’t afford. The Mac Mini is about the same price as a mid tier iPhone.

The average selling price of a PC in the US is $639.

https://www.statista.com/statistics/722992/worldwide-persona...

I think that's missing the point. Sure, it's not far off the price of a computer - but it's still not an amount of money that you spend on a whim just because you need occasional access to macOS. It's the price of a (second) computer, and an above-average price too.

But it’s not some luxury good that only people in the “SV bubble” can afford.

If I were serious about being cross platform, why wouldn’t I just buy a Mac since it can run Windows, Linux and Mac software and I can build both Android and iOS software?

You don’t even have to buy a new Mac. You can always buy a used 2014 Mac Mini.

> If I were serious about being cross platform, why wouldn’t I just buy a Mac since it can run Windows, Linux and Mac software and I can build both Android and iOS software?

I personally wouldn't buy one as it's not worth the money performance-wise [1], and I don't like Mac hardware/software in the first place.

> You don’t even have to buy a new Mac. You can always buy a used 2014 Mac Mini.

It's still a shame to have to spend $300+ to use an underpowered 6 year old machine while I have perfectly capable Ryzen cores sitting here idle.

[1] - 8GB and 4-core i5 for a Macbook at the same price of my 32GB and 8-core Ryzen 4750U current laptop. A maxed out MBP, still not reaching the same CPU/GPU specs as my T14 is over 1000eur more expensive.

It's not a whim. For a software developer it could easily be used 8 hours/day 5 days/week. Or more.

@dang/mods - I accidentally wrote "for" instead of "or" on the github repo linked here, but have now fixed it. So now the title of this thread is wrong. It should be "Fastmac – A macOS instance or Linux shell".

Sorry about that!

Ok, we've de-effed that bit.

Did GH bought lot of Mac minis for actions? Or is it some separate custom server module from Apple? Or is it hackintosh?

Almost certainly a bunch of Mac minis. I would think and expect that Microsoft (or any decently run company) would never even consider using hackintoshes. It’s simply not worth the risk and damage.

Someone else said that they use https://www.macstadium.com/, which does that.

Who's providing the macOS session, GH? Azure?

It's one of GitHub-hosted runners:

- Windows Server 2019 windows-latest or windows-2019

- Ubuntu 20.04 ubuntu-20.04

- Ubuntu 18.04 ubuntu-latest or ubuntu-18.04

- Ubuntu 16.04 ubuntu-16.04

- macOS Catalina 10.15 macos-latest or macos-10.15

From: https://docs.github.com/en/actions/reference/workflow-syntax...

To answer the parent's question: "GitHub hosts Linux and Windows runners on Standard_DS2_v2 virtual machines in Microsoft Azure... GitHub uses MacStadium to host the macOS runners."

https://docs.github.com/en/actions/reference/virtual-environ...

Reply on news.ycombinator.com