Amazon lists the price of mac1 instances (running on rack-mounted Intel Mac Minis) at $1.083 per hour, $9,487 per year. You have to pay for 24 hours up front, after which they bill by the second. https://aws.amazon.com/ec2/dedicated-hosts/pricing/
If you pay for three years up front, you can pay $0.764 per hour, $6,692 per year, 29% off. I believe that's the lowest price Amazon will offer you.
For comparison, you can rent an equivalent Mac Mini from MacStadium for $139/month, $1,668/year. Or you can rent their cheapest model for $59/month, $708/year.
You can also buy the equivalent Mac Mini for $1,899.
Those numbers actually make the AWS instances a shoo-in for my current development purposes.
The cost of housing and managing a unit of hardware is nonzero. Actuals vary wildly by location, purposes, and sector; but if everyone can get their heads out of the hobbyist-tinkerer mindset for a moment and consider that lifetime TCO is a real and meaningful consideration for businesses, then the component that isn't buying/leasing the server itself is typically several hundred dollars, per physical unit, per annum. Public clouds don't nullify all of it, but they swing the needle dramatically.
Since my duty cycle for a Mac Mini is rather less than 20%, the economics even of on-demand instances immediately make sense, and having it inside the VPC boundary without hybridising is gravy on the meat since I'm consuming several other AWS services besides.
These two factors (lifetime TCO and scale-down) are the economic foundation of the value proposition of utility computing. The "I can build that in my garage for cheaper" crew aren't wrong, but they're missing the point.
Putting on my sometime cloud infrastructure product manager's hat, long-term observers of service pricing may also observe the common enough pattern of starting a new product with a relatively high price, one that selects for early adopters and other price-insensitive (and, you hope, glitch/MVP-tolerant) customer segments, then gradually ratcheting prices down in order to estimate (amongst other things) the price elasticity of demand. It's naturally easier to get cheaper over time, than go the other way. In this AWS's position on compute is congruent to any other commodity merchant⁽¹⁾ with the luxury of being able to withstand potential losses on a single product line. For most EC2 instance types I'd expect they have a very good model of the price sensitivities, but mac1 is undoubtedly a unique platform with elevated uncertainty in the price parameters.
Which is my long-winded way of saying, it'll likely be cheaper in a few months.
> Since my duty cycle for a Mac Mini is rather less than 20%, the economics even of on-demand instances immediately make sense
MacStadium's prices are "rather less than 20%" of AWS's prices. To make sense, AWS would have to be comparable to MacStadium's pricing.
And don't forget the 24-hour minimum. If your duty cycle for a Mac Mini is only 20% per day every weekday, well, you can't rent a Mac Mini for less than a 24 hour period, so instead of paying for 20% of a month, you'll be paying for 20 work days, 60% of a month. On AWS, that would run you $546/month, 4x as much as you'd pay MacStadium for the entire month.
AWS's price is only comparable to MacStadium if you need five 24-hour periods per month (or less).
And, sure, AWS's prices will decline at some point, but I'm not expecting an 80% price drop this year.
This is what I mean by "hobbyist mindset": driving straight past the huge neon sign flashing TCO, assuming that some idiot (that's me) has failed arithmetic 101 (totally possible, my undergraduate mathematics ruined me for sums, isn't everything an infinite series?), and blithely disregarding the cost and time I'll need to obtain authorisation to establish a new commercial relationship, authorisation from legal and security to have our IP and/or customer data in yet another facility, then the overhead of managing the technical and billing elements, and the compliance reporting, and so on.
So yes, AWS is still a shoo-in.
Don't even get me started on the data sovereignty and latency issues of a self-proclaimed "global" hosting provider that's only on two continents, neither of which we are operating in.
I have an app I need to compile on a Mac that I only make changes to maybe once a quarter, or four days a year. That's an ideal use case for on-demand AWS Macs, and I'll probably transition to that if the Mac Mini in the corner ever decides not to boot or not to accept a mandatory OS update when I have to use it someday.
Also, I'm more likely to transition to this because I'm familiar with AWS, I didn't know MacStadium existed before this thread.
If that's their target market (and not someone who wants a scalable Mac build farm available 24/7 and doesn't care about costs), then it makes sense - I pay a lot less than the price of a Mini to rent it 4 days a year, if Amazon can find 90 other people who want to do the same, all of us are better off.
If you haven't you may want to consider https://www.macincloud.com/ where you can rent it for $1 per hour when you need. Your use case seems very suitable for that. It is roughly same price point as AWS but can stretch your dollars longer vs AWS 24 hour upfront.
Sure, but then I'd have to use an iPhone. The machine is the main thing to my customers, the app is just a tool for monitoring its status and the Android app and webserver shows the same information.
I'm no expert, but I'm stunned that it costs more than $10,000 a year to connect a single computer to a corporate network such that AWS Macs become cost competitive. I've never worked in a big enterprise organization but I just can't wrap my head around the inefficiency required to make that math work.
The problem is not the first time setup. The problem is essentially what “uptime” you can provide. Once you setup an infrastructure many people come to depend on it.
Lets say two teams lose half a day when that CI/CD mac mini goes down then paying for a cloud provider to manage many instances and “sharing them ondemand” makes a lot of monetary sense.
Of course, paying a cloud provider may or may not make sense for hobbyists. Personally, I pay for cloud storage - thats super hard to get right.
For what Amazon is asking, one could have both an extra hot _and_ an extra cold standby locally, so it still doesn't make economic sense for a large company.
In a very substantial number of enterprises; the cost of procuring, validating, installing, powering, cooling, fire-rating, commissioning, maintaining, writing up, handing over, revising, reporting, auditing, approving, and very occasionally actually executing those hot<>cold standby procedures, exceeds the entire purchase cost of the cold standby unit.
for real. I used to work at a large company in highly regulated industry with lots of scrutiny on our books. The number of meetings and program proposals it would take just to get finance to agree to the capex of standing up a dozen mac minis would easily dwarf the hardware cost. That's before you get to the actual work. From my experience, saying "we're just going to increase our EC2 spend" is a no-brainer
I could see it being reasonable if a medium to large companies entire infrastructure was cloud based, and they only needed a handful of mac minis. Alternatively, a company who needed them only a handful of days a year for some reason I can’t immediately think of.
Otherwise I agree. 24 hour minimum removes immediate scaling as an option, and for anyone who already has their own infrastructure the cost is prohibitively high. My hope would be that with time, at the very least the 24 hour minimum would eventually be removed, and ideally the price will come down too.
a company who needed them only a handful of days a year for some reason I can’t immediately think of
Perhaps it's good for render farms. Instead of building a giant render farm that sits idle between productions, you spin up a render farm only when you need one.
I don’t understand how you are confused. If I need to check if my app works on m1, I can now spend $24 to do that instead of $650 or whatever it retails for.
So these are for people who want to do quick compatibility testing? For that use case, how does it not make more sense to go with MacStadium? If you end up needing to test for two days instead of one, you're already in the pricing territory where you could have gotten a full month of usage from MacStadium.
> how does it not make more sense to go with MacStadium?
If you're already in AWS, your deployment infrastructure and tooling is already configured and tuned for AWS. Deploying a Mac EC2 instance is just adding another target. Whereas deploying to another provider is an unknown amount of work to integrate with their API (if they even have one). The wall-time cost of people's time and effort vastly outweighs the marginal savings you'd get by going with a low-cost provider.
I will spend more time trying (with no great chance of succcess) to obtain authorisation to establish an additional commercial relationship, and corporate billing/card approval, and the time burned on this instantly exceeds any amount of money they could possibly save me.
It's a lot easier to click a button on the AWS console then to get approval to buy new capital equipment, or to get approval to use a new vendor (for which we'd likely need legal review, security audits, etc.).
It would be cheaper if you had your own data center already or an office space sufficiently large to store these Mac Mini's. But if you have neither and are operating out of say AWS, then it becomes more expensive to rent space to put these Mac Mini's into, especially if you don't need it all the time. In that way it can actually be "cheaper", because it's compared to the cost of building out the infrastructure required to support your own hardware.
I'm fascinated by this thing where people tacitly assume that employee time is free. Even people who like to actually receive their paychecks.
The money spent paying someone to set up a Mac server somewhere else, getting that somewhere else connected to your AWS networks, and ensuring that connection is secure, and generally integrating it into your existing cloud devops infrastructure (or, perhaps more expensively, not integrating it into your existing devops infrastructure), would, I'm guessing, be horrendously expensive compared to the premium Amazon charges on a relatively turnkey solution for use cases such as, "We need to run the occasional Darwin build."
I've maintained mac mini farms and it is both time consuming and expensive. If it were reasonable to setup and maintain Macs for devops, these offerings probably wouldn't exist.
They would still exist. When a company's entire shop is set up in AWS they want to keep it that way, not buy physical hardware to install in their office, create a VPN to make build pipelines, worry about physical security, etc.
Yeah, the premium here would be easily justified for us in having a mac colocated with the rest of our infra and it being easy to provision and manage through CloudFormation/APIs just like the rest of our infrastructure.
If you are comparing buying the device + the other costs of running the device vs renting from aws, then the 24h upfront is not an issue. You could even consider renting for a year or more.
On my team, we just have a Mac Mini sitting under someone's desk to do stuff that requires a Mac. It gets used for about 1 hour every day for a daily build. For us, AWS's offering doesn't make financial sense.
Even if we were to switch to only doing a weekly build, it wouldn't be worth it, as that would still cost around $1,250/year.
Yes. The details don't particularly matter, but broadly, it's periodic QA of a couple of apps & tools vs Safari, vs OSX, and vs homebrew. Not CI/CD.
OSX seems more prone to bitroot regressions than Windows or Linux, I suppose Apple have a "you're with us, or you're against us" attitude and this even applies to base OS backwards (in)compatibility.
> Since my duty cycle for a Mac Mini is rather less than 20%, the economics even of on-demand instances immediately make sense,
What are you doing with macs that naturally works out at ~one continuous 24h period per work-week on average? Turn on CI once a week Thursday midnight, and no one goes into the weekend before all test failures are fixed?
Ya, weekly builds on Monday morning for a gaming company with multiple teams makes sense. They could slice it up across their teams even for better TCO
> but if everyone can get their heads out of the hobbyist-tinkerer mindset for a moment and consider that lifetime TCO is a real and meaningful consideration for businesses
This is the hard thing for me. I just like having so much control of having hardware at home, and I've got static IPs. But it costs to power and cool them, and they aren't elastic like cloud/IaaS. Having started the move to VPSs and finding them very good for the price, I'm now trying to wrap my head around "cattle, not pets", but still with a micropreneur mindset. I think it's still worth it, and my home office is getting quieter with every server I relocate to somebody else's hardware.
But the real place cloud/IaaS shines for me is when you aggressively scale, both up and down. If you're used to pets and physical machines then you probably over provision a lot. With the cloud you can ride the CPU/memory line a lot closer and scale quickly when needed.
Ok, I understand how just looking at the cost of a box of Mac mini in the Apple store doesn't represent the TCO...
...however is the AWS price including a lot of value the Mac mini colo price doesn't? I believe the AWS price is dramatically higher unless you can batch the 20% duty cycle into full days (AWS is following Apple's EULA and only billing in 24 consecutive hour chunks).
I'm not a "I can build in the garage cheaper", I'm a "we use to build servers that way, run them ourselves (and steal meeting rooms form ourselves and put extra cooling in), and then I went off to do other things for 20 years and now I work at a huge company where we build our own cloud stuff...but if I were at a less huge company how would this stuff actually work out?" kind of person (i.e. I know the _theory_ of renting other people's servers, but the finer points of actually evaluating it are not currently in my grasp).
With the pricing, 24h minimum and "only developers" restriction. it seems like there are exactly two usecases for this service.
1. You are a big company who needs Mac CI and your IT department has a strict "Cloud Only" restriction.
2. You are a developer for a cross-platform App who doesn't own a mac, but needs access to a real mac every few weeks or months for debugging/releasing.
Unsure if you've seen the comments elsewhere in the thread but in case you haven't and this is a genuine question - because Apple's EULA forces Amazon to do this.
I'm honestly kind of surprised that this isn't a service that Apple offers directly. Keep it part of their walled garden. Only apps compiled on the ACC (Apple Cloud Compiler) will receive certificate signing which allows them to be offered in the AppStore. And by a service Apple offers, I of course mean a service Apple requires.
Yes - I did know that. I guess my question is directed more at Apple. Why stipulate this unless they want to hobble reasonable use-cases or inflate usage arbitrarily.
Is the answer simply "Because they can and they like money?"
> Why stipulate this unless they want to ... inflate usage arbitrarily
That's exactly it. If you could rent Macs by the minute, you wouldn't need to own Mac hardware anymore to build Mac apps, and the cloud provider wouldn't need to own as much.
> Why stipulate this unless they want to hobble reasonable use-cases or inflate usage arbitrarily.
It seems this is Apple's sole motivation when it comes to anything developer related, which seems odd considering their goal is to commodotize software to sell their hardware - you'd think they wouldn't keep making it harder to make software for their platforms
But only as a second-order effect. This will lead to needing to buy more Apple hardware to support such a service but it's the service provider that rakes in the cash (or doesn't because people don't need 24h) as a result of this EULA.
Surely this just means that more people won't bother and we're back to hackintoshes or upgrading old Apple hardware. Making something uneconomical isn't a great strategy to drive growth.
Yea this should work because the license merely says it must be on Mac hardware and given that you're not letting everyone share/use the computer like AWS the new restrictions won't really matter.
> Could you virtualize a newer MacOS version on your Mac hardware?
Yes but I'm more likely to vierualize on my more powerful and better value PC. The EULA is rather hard to enforce and I don't have any moral qualms in this particular case.
You mean have opinions and open discussion? "I can only think of two things" doesn't mean "there are only two things exactly and everyone else is wrong". Welcome to the Internet, I see you are new here.
No, dismiss the possibility that there may be things that they don't know about or understand.
"I can only think of two things" doesn't mean "there are only two things exactly and everyone else is wrong".
But that's precisely what he said: "exactly two usecases for this service" He didn't write "I can only think of..." You're making stuff up.
Welcome to the Internet
I shall say the same to you, since I've been online since before the internet, back when you had to manually route e-mail, and it took a week to get a message from New York to Paris, if you were lucky.
I see you are new here.
Welcome to HN. I see you're new here. Be sure to read the rules about unhelpful snarky responses.
Because at some point it may literally be cheaper? Not that I made the math, but since the point here is about "opening the possibilities", then it is also possible that having a render farm sitting idle half a year is actually the more sensible option.
> For comparison, you can rent an equivalent Mac Mini from MacStadium for $139/month, $1,668/year. Or you can rent their cheapest model for $59/month, $708/year.
> You can also buy the equivalent Mac Mini for $1,899.
Not only that, but MacStadium lets you run multiple VMs on a single Mac at no extra cost. Amazon's offering is seriously underwhelming.
The more I use or learn about MacStadium, the less impressed I am with it (3 layers of virtualisation is overkill in my opinion!), but it beats the hell out of what Amazon has just announced.
The big problem with CI/CD on Mac is that Xcode does not allow you to run builds in parallel, so you need one Mac per build unless you use virtualisation.
To be honest I'm surprised that no one has added namespace/jail support to macOS yet. The XNU kernel is open source so this should be possible. In fact, can someone explain to me why there doesn't seem to be any sort of XNU hacking community?
Not only that, but MacStadium lets you run multiple VMs on a single Mac at no extra cost. Amazon's offering is seriously underwhelming
To the hobbiest market, yes. But large companies, at which this seem to be aimed, work with names they know, not names they don't.
The company I work for would pay more to use Amazon than MacStadium for equivalent products. That's just how corporate bureaucracy works. It shouldn't, but it almost always does.
As far as I'm aware, if you go for Orka Cloud, you only pay for the physical Mac, not the VMs. I've no idea about the hobbiest market, I've only used MacStadium for a large company. I didn't personally make the purchase but that's the information that has been relayed to me.
> The big problem with CI/CD on Mac is that Xcode does not allow you to run builds in parallel, so you need one Mac per build unless you use virtualisation.
Yes it does. The Xcode GUI only allows one build at a time, but you can run multiple `xcodebuild` command line builds using the same or different versions of Xcode in parallel, even under the same macOS user.
For running tests, there used to be problems if you were trying to invoke the iOS Simulator for different versions of Xcode in parallel, but those issues were fixed 4 or 5 years ago.
I've setup and used a set of bare-metal Mac mini CI runner, each configured to run two jobs in parallel, and the Xcode pieces of that are rock solid and didn't need _any_ workarounds to enable parallel jobs.
> Yes it does. The Xcode GUI only allows one build at a time, but you can run multiple `xcodebuild` command line builds using the same or different versions of Xcode in parallel, even under the same macOS user.
This isn't true. "xcode-select" forces you to set a system-wide Xcode version. If you have a job that uses one version and a concurrent job selects another version, it will potentially break the first job.
That’s not true. You can run macOS with a custom-built kernel and it should work fine, although it won’t be exactly the same as the stock one (the released source is missing some bits).
The Hackintosh community sometimes uses custom kernels, although much less often nowadays than they once did. There are custom kernels to add support for AMD processors (most common by far), and kernels to add compatibility with Intel processors that don't work natively (e.g. Atom). These do work on real Macs too, I used one a couple months ago for something stupid: https://apple.stackexchange.com/questions/402726/how-can-i-a...
Nowadays, however, Hackintosh tends to rely entirely on patching the kernel in memory, even on esoteric platforms like AMD. Custom kernels are really inconvenient for a few reasons—they get set back to stock after every update (which potentially means your computer won't boot, if you forget to put the custom kernel back before your machine restarts), and Apple releases XNU's source on a ~6 month delay.
I would love to see more kernel experimentation, but I think there's just not a lot of reason to do it? If you're on a Mac, you don't need to add support for new hardware.
That said, it would be great to get a kernel which e.g. disables TCC, or maybe which removes Big Sur's signed snapshot stuff. Both of those feel like achievable tasks, and they would have a real use!
Funnily bandwidth pricing at Oracle Cloud is the cheapest of all major clouds. Its kind of ironic as every product oracle sells costs your „first born son“.
Plenty of cloud providers don't charge for bandwidth until you hit an anti-abuse ceiling. For example, Hetzner offers a 20TB bandwidth cap per node. You don't need to buy AWS to get same prices on network.
The person above is clearly talking about Hetzner cloud which a 20TB cap per instance.
A no frills, SSD or network storage backed VPS which has price/perfomance than other offers i have seen which offer fine grained billing.
You wouldn't necessarily use this if you expect to keep all the systems running 24/7; for that, another provider would indeed be better. You'd use this if you want to scale up or down and boot different images on the host. Yes, you have a 24 hour minimum, but that's better than a 1 month minimum.
I'd have loved to have seen mac pros, and virtual instances (subdivided, even if you had to maintain a dedicated host to run them on), but this is still a major quality of life improvement for heterogeneous environments.
If you need it for CI/CD of some kind, then APIs, networking, access control, and security (including, possibly, physical security) are all important too, and not trivial to do with a machine in your closet.
Paying by the second is also ideal for these use cases. You run a build occasionally, but it mostly sits idle.
Just run ZeroTier on the Mini and join it to your network. That's what we do. Of course we are ZeroTier so this is how we roll. Anything with an Internet connection is in "the cloud." We just donate all its spare cycles to Boinc. :)
Pay by the second would perhaps be preferable but unless I am reading this wrong you have to pay by the hour and it's relatively expensive.
It's too early in the morning for me to try to parse an AWS pricing page, but according to another comment: "You have to pay for 24 hours up front, after which they bill by the second."
Where does Amazon document that 24 hour minimum? I've just encountered this problem but been unable to find anything on that. It makes the On Demand cloud concept completely useless.
Jeff is not the richest man on earth for no reasons. Us humans are lazy. Who wants to manage hardware or walk to the store when you can click on the cloud ?
An interesting offering from Amazon that is crippled by Apple and MacStadium, who deserve to be raked over the coals for their recent EULA changes. Just read the post on MacStadium's blog: https://blog.macstadium.com/blog/developers-big-sur-and-vind...
Under the new agreement, you must:
* Rent to only one organization
* Rent for 24 hours at the minimum
* Use it for some set of "approved" development work
…among other restrictions. And Brian Stucki is celebrating these changes?! This is a sick joke. You're enjoying a significantly tightened EULA that benefits nobody but yourself, a EULA that means that a single CI build now costs $26 on AWS instead of 50 cents; one that means that more than half the comments here are confused why AWS is ripping people off.
Shame on you Brian Stucki, shame on you MacStadium, and shame on you Apple. Your EULA changes are absurdly hostile to developers, since now they're either going to have to buy Macs themselves or rent from MacStadium-like services. Shame on you both for colluding together for making this situation horrible and then having the guts to write that blog post.
I can't believe I'm saying this, but Amazon, I feel so sorry for you. You didn't deserve this.
The vast majority of the time, situations are complex than internet users think they are. There are two sides to every story, &c. It's fine to make your point, but please stick to the HN rules and make it substantively and thoughtfully. The fact that rage rants get heavily upvoted makes this more important, not less.
Thank you for taking the time to write that! The comment was rubbing me the wrong way when I first saw it, but I wasn't able to put my finger on why, because I agreed with all of the individual points expressed.
You're right, of course. As I mentioned downthread, I was somewhat angry when I wrote this; Brian has stepped in to provide more detail from his side. I'm still a bit resentful, but I understand that displeased or not ranting on Hacker News is not something I should have done. I'm not ready to apologize to the people I included for the concerns I mentioned yet, but I am sorry (both to them and Hacker News itself) for commenting in this way. The blog post gave me a specific set of things to be mad at and I let that get the best of me.
Brian Stucki here. If I had the power over Apple that you think I do, I definitely would have pushed for iPhone Socks first.
Joking aside, the software license agreement was certainly a cause for personal celebration. It might be helpful for you to compare macOS 11 to previous versions. (Linked in my post.) If I/MacStadium did anything, we showed that there was a need for this sort of service and that both Apple and developers would benefit with some official way to do it. Amazon joining is further proof of that.
I’ve always pushed for the safe road at MacStadium (and my company Macminicolo before that) even if it meant losing out on gray area business. I can’t tell you how many times I’ve answered “but what if Apple shuts this service down?” Not anymore.
With the new Eula, the guidelines are now set. Doing everything above board paid off.
I get that you're happy because Apple has now explicitly permitted what you were doing.
I'm less clear on why you're happy that they didn't allow more stuff, like renting by the minute or for arbitrary purposes. You seem to depict companies that were doing this as "below board", while you as "above board". This is certainly true now, but before the changes both would have been a grey area - I don't see much of a difference.
Would I be correct saying that you're happy because in one stroke Apple has moved you from grey area to explicitly permitted, and part of your competition from grey area to explicitly forbidden?
For the record in no way I think that Apple took this decision to favor you or anyone else except themselves. It just seems that you won a regulatory lottery.
Regulations benefit incumbents. That holds whether the regulations are national laws or corporate policies. When you make new rules, the established ecosystem adapts and doubles down while new players have a harder time getting started.
This is not true at all. Anti monopoly regulations, for example, exist for the sole purpose of privileging new entrants over incumbents. The actions against Microsoft, or the breaking up of AT&T certainly did not help the incumbents.
An example closer to home is that entrepreneurial activity in Silicon Valley is often attributed to California law forbidding non competes in employment contracts. This is regulation, without which, as you see in nearly every other state, workers are severely bound by their employment contracts in the work they can do while and after being employed by a company.
If regulations seem to benefit incumbents, it’s because incumbents exist and therefore can play a role in setting regulations. The counterbalance to this should be public pressure and political action, but incumbents recognizing that do much to dissuade the public from pushing for such action, including convincing people of pithy, but 180 degrees wrong ideas such as “regulations always benefit incumbents”.
The best cases occur where they raise a floor uniformly. For example I would prefer to add anti pollution systems to my paint factory, because I live in town too, and I just don't want to pollute. It would raise the price of my paint $1/gal, and not enough customers will chose a product just because it polluted less. Many of my competitors feel the same. If we all do it everybody benefits and nobody suffers relative to their competition. This is even more important in cases where the customer can't signal through the market, e.g. electricity generation. These can benefit incumbents but not necessarily hurt new entrants, especially when they are cap ex rather than op ex (e.g. minimum wage rather than an additional piece of equipment).
There are many bad examples as well, some of which raise a floor asymmetrically. For example FB, or at least their CEO, is willing to have the CDA's section 230 abolished because they have such a dominant customer base and enough cash that they believe they would be able to afford to do the resulting government mandated controls and fight any lawsuits, while a new entrant would not.
> This is not true at all. Anti monopoly regulations, for example, exist for the sole purpose of privileging new entrants over incumbents. The actions against Microsoft, or the breaking up of AT&T certainly did not help the incumbents.
The intended purpose is to help the new entrants, but I don't see Microsoft or AT&T losing anything or their smaller competitors gaining anything after the regulatory action against them.
> An example closer to home is that entrepreneurial activity in Silicon Valley is often attributed to California law forbidding non competes in employment contracts. This is regulation, without which, as you see in nearly every other state, workers are severely bound by their employment contracts in the work they can do while and after being employed by a company.
That's a matter of negotiation. I always (successfully) negotiated with my employer to exclude my personal projects from the contract. I find that employees have a lot more negotiating power than they realize.
> If regulations seem to benefit incumbents, it’s because incumbents exist and therefore can play a role in setting regulations.
I think that's synonymous with the original statement made by OP. You're just providing another reason why it's true.
The "AT&T" you know today is not the same company. It is Southwestern Bell, which bought the AT&T brand in the bankruptcy fire sale and renamed itself.
It did so because AT&T was a more valuable brand than Southwestern Bell. Looks like it worked.
> It is Southwestern Bell, which bought the AT&T brand in the bankruptcy fire sale and renamed itself.
Southwestern Bell was the same subsidiary that broke off from AT&T Corporation. AT&T Inc was the merger of the companies that were originally broken up from AT&T Corporation. Here is the org chart: https://en.wikipedia.org/wiki/AT%26T#Chart_of_AT&T_Baby_Bell...
You think that AT&T Corporation going broke and selling to a company that originated from the AT&T Corporation, which later renamed itself to AT&T Inc is a good example of a government-imposed corporate breakup?! It literally divested from those companies only to have most of them merge under the same name again.
Technically Southwestern Bell was spun off from the AT&T breakup from the 80's.
So basically SBC was one of many companies spun off from AT&T, then it bought up several of the other Baby Bell companies spun off, too. Really, it was AT&T buying AT&T.
It worked on paper, but the victor was still from the same tree.
> Would I be correct saying that you're happy because in one stroke Apple has moved you from grey area to explicitly permitted, and part of your competition from grey area to explicitly forbidden?
I don't know how any competition would be negatively impacted by Apple implementing these terms, unless the competition was already selling services that were on a short-term basis (below 24 hours).
And to circle back around, this EULA enables MacStadium's hardware hosting competition to enter the market... thus comes Amazon into the playing field. I just don't see how having to compete with Amazon is, all of a sudden, a better deal for MacStadium. If anything, it just highlights the volatile nature of running a business in the Apple ecosystem.
> For the record in no way I think that Apple took this decision to favor you or anyone else except themselves. It just seems that you won a regulatory lottery.
"Congratulations, you're a winner... your prize is to compete with Amazon!" Some would certainly wear it with a badge of honor!
> I don't know how any competition would be negatively impacted by Apple implementing these terms, unless the competition was already selling services that were on a short-term basis (below 24 hours).
Almosto all of MacStadium post is about those competitors, did we read something different?
And Amazon would be much more of a competition were they allowed to rent by the minute, it's their selling point!
Why wouldn't Apple just let people rent out computers for any amount of time, as long as they don't contain music or movies? I can understand why Apple would wan't someone to pay $3.99 to rent a movie for 48 hours, and then sub-rent that movie a couple dozen times. But why do they care about someone running CI?
Because tens of thousands of devs working on other platforms would be able to rent a Mac for half an hour, build their cross-platform framework code as an XCode project, and then submit to the App Store, without ever touching a Mac, testing on a Mac, and so on.
> I don't know how any competition would be negatively impacted by Apple implementing these terms, unless the competition was already selling services that were on a short-term basis (below 24 hours).
Macstadium competes against other short-term rental companies but also against real Macs, Hackintoshes on physical machines, Hackintoshes on virtual machines (inc EC2), and non-consumption.
Hacks on VMs are a pretty direct competitor I’d think.
> Macstadium competes against other short-term rental companies but also against real Macs, Hackintoshes on physical machines, Hackintoshes on virtual machines (inc EC2), and non-consumption.
MacStadium isn't doing short-term rentals not because it can't but because the EULA doesn't allow it. Anybody doing short-term rentals is doing it on Mac hardware so they can just as easily sell long-term rentals. Aside from MacStadium being a major player in this field, I see absolutely nothing that favors them compared to their competition. In fact, it seems to have created Amazon as a competitor.
And the Hackintosh thing is the reason a Mac hosting companies exist in the first place. If Hackintoshes were allowed, there would be no companies offering Mac hosted hardware. I don't see how that's related to this particular situation tho. Apple created the need for Mac hosted hardware so blaming Mac hardware hosting companies for this is a bit backward.
> Hacks on VMs are a pretty direct competitor I’d think.
Condition: Person X has a need to run macOS for 3 hours for whatever reason. They have a lot of options, including the ones I listed.
Various options have different drawbacks, including EULA violations, but all represent viable alternatives for some (therefore competition) to Macstadium.
It represents an opportunity to MacStadium as well, since they too would be able to sell the hardware by the hour. Currently, the only reason they can't is due to the EULA. There is no other reason why a mac hardware hosting company couldn't sell hourly access to a Mac machine.
Hi, thanks for weighing in. I'm sure you picked up that I'm pretty mad, but I'll try to tone it down a little bit. I'm not an Amazon employee or someone who is personally harmed by this or anything, aside from being a developer for Apple's platforms who occasionally looks around for CI services. I'm mostly arguing about the principle of the thing.
Anyways: I read your blog post back when it came out. Whether Apple took your input into account when making the EULA, I don't know; I am sure that you must have some sort of amicable relationship at the very least. Running services "on the border" like this is never easy, but I would think that your business model (which includes buying a huge number of Macs) has probably kept Apple mostly on your side. I know the work you've done to keep it this way and to be honest, I was happy for you when Apple announced their rack-mountable Mac Pros and gave you a mention at the Mac Mini event.
The problem from my side (at least where you and MacStadium are involved) mostly lies with the blog post you wrote. Look, I get it, Apple's changes make the EULA work for you. That's great! But I'm sure you also realize that spelling this out clearly in the way that they did means that the "gray area" becomes a black area for basically everyone else. What I didn't appreciate is you calling it a "gray area" and coming up with rationale for why what they want is not reasonable. Apple came in, almost certainly looked at your business specifically, made its rules to hurt developers and these companies, and now you're writing blog posts about how Apple is your friend and you were right all along. It feels like you've decided to start singing praises for a bully that decided to leave you alone, and it leaves a bad taste in my mouth.
There's still a huge hole for a service that lets you rent a Mac for the a couple minutes so you can build your Xcode project. It's not your fault that doesn't exist, it's Apple's. But could you maybe not publicly celebrate that Apple has created a situation that happens to help you and make it generally worse for others? Can we stop trying to normalize or even argue that sharing a Mac is something wrong, something that Apple would think is ruining the "performance experience" you should get from a Mac?
>aside from being a developer for Apple's platforms who occasionally looks around for CI services
So, you give him all this shit and you're not even using his service?
>There's still a huge hole for a service that lets you rent a Mac for the a couple minutes so you can build your Xcode project. It's not your fault that doesn't exist, it's Apple's.
If we're talking for CI of builds, sure. But in that case, one wouldn't be much affected (the C in CI means continuous, so you wont just rent for a few minutes).
Otherwise, as a user, I'm quite satisfied with less developers being able to build XCode projects and submit apps without even owning a Mac to test them on. Looks like it would bring a delluge of poorly ported apps based on cross-platform APIs and only tested in non-Mac platforms (if that).
I like you and I think your posts are generally high quality, so I am going to say that an elitist "screw people who cant afford an overpriced mac" is not a good thing imo.
Will we get some lower quality apps, sure, do those already exist? yeah. It just sounds like gatekeeping for not much benefit.
>I like you and I think your posts are generally high quality
Thanks! I try to add the ocassional low quality comment for balance :-)
>so I am going to say that an elitist "screw people who cant afford an overpriced mac" is not a good thing imo.
Well, my intented meaning was more like "Don't create/sell apps for a platform you dont even own to test in".
The main reason to go for "by the minute" builds on the Cloud for a machine you don't own is to either help with porting to an architecture you don't use, or to churn apps with some cross platform framework to a platform you don't use/care about.
I think the latter would be more frequent.
If they were mere poor hobbyists guys legitimately coding for the platform, they'd own a machine, either new, or second hand, or whatever. It's when you don't code in the platform, but only want to target it for selling that you have an issue...
> The main reason to go for "by the minute" builds on the Cloud for a machine you don't own is to either help with porting to an architecture you don't use, or to churn apps with some cross platform framework to a platform you don't use/care about.
You can also go for "by the minute" builds on the Cloud for a machine you do own. Suppose the developers and testers have Macs on their desks, but you still want to have your CI run in the Cloud. Now I'm not an expert on cloud pricing so I could be wrong, but I imagine you could benefit from paying by the minute in that case, depending on the specifics of your situation (builds per day, time per build, total cost of ownership of having a build farm in house).
Is that why web developers have their hands on every iteration of every device on the planet? Or do they have some sort of tooling that emulates that experience for them?
Yes, I think I reserve the right to judge him for a decision that hurts iOS/macOS developers as a whole. Can't I judge Facebook for being a privacy violating nightmare even though I've never had an account with them?
As for your other comments: I know what CI is; I use it daily! The way my CI runs (which is how most CI is!) is that a when a commit gets pushed a machine gets spun up to build it, then a few minutes later it shuts itself down once the compilation is complete. Why would I want to pay to have a Mac for an entire day in this scenario? I'd have to be pushing code every few minutes to have any hope of efficiently using one machine.
And believe me, I hate cross-platform garbage apps just as much as you do. But I am not in favor of putting arbitrary restrictions on how people can write their apps. Xcode used to be a soft-requirement to build apps and look how well that worked out: native developers have to stick with it all the time, even when it's acting up and being buggy, and developers who couldn't care less have reverse engineered it to the point where they either generate an Xcode project from a source tree and build from the command line, or they just package their own app bundle themselves with the magic bits that Xcode would usually apply. Trying to stop people from making garbage apps by limiting their tooling options rarely works. And, in fact, I personally know people who go services like MacStadium (VNCing in) to use Xcode for the couple days it takes to set up a build system with the right certificates and profiles, then they never touch a Mac ever again. It's the native developers with their own Macs who want to use a fresh machine to build their code for Mojave or something that they aren't running on their personal computers.
Maybe a case can be made to eliminate the 24 hour minimum by focusing on reducing carbon emissions Why force someone to rent for a day when they need it for an hour?
“This 23 hours of global warming is proudly sponsored by the Appleverse.”
This seems like an absolutely bizarre take on the situation. You don't really think Apple added those EULA terms for MacStadium now right? They were clearly added for AWS! MacStadium just happens to be happy that there's crystal-clear red lines.
These rules are 100% down to Apple, absolutely nothing to do with AWS and MacStadium in terms of decision-making.
Apple don't want the perceived value of their machines to become lower, want to make sure there's no possibility of performance issues due to multiple tenancy, and want to make sure this doesn't become a way for people to have a personal Mac without having a Mac.
Maybe in another year or two, assuming nothing came out of this which Apple didn't like, they might loosen the rules slightly.
The terms seem to be a perfect fit for MacStadium and a poor fit for everyone else, including AWS. Do you think AWS wants to bill by the second…with 24 hours up front? Does this match their business model at all?
It's really not Apple's business to try to protect people from "performance issues due to multiple tenancy". People who buy these things already know how this works.
And it absolutely is 100% typical of Apple to do this kind of thing. They don't want third party companies to provide offerings which might cause them problems or degrade their brand/perception.
I'm not at all saying these terms were added to benefit AWS. More that they were a condition of Apple doing this first official cloud partnership.
It's also 100% in line with Apple's recent trends of being hostile to developers. It's absolutely absurd to have to rent an server for 24 hours to do a single build. It's incredibly wasteful to have this much hardware sitting around and doing nothing.
Recent trends? Apple has been periodically screwing developers since always. Ultimately Apple just sees developers as a necessary evil to sell their products, but making life easy for them is not a priority.
Just the EULA. Whether that holds any weight with you is up to yourself to decide. But AWS and MacStadium are going to make you click-agree to Apple's EULA before granting access.
Or maybe MacStadium’s model was based on the completely predictable direction and steps Apple would take when it came to licensing such activity.
For example, it wasnt hard to predict that a company which basically gives away its OS for free, and nearly makes all its money selling the hardware to run the OS would start with licensing terms that led to more sales of macs.
I have to disagree with this idea that Apple Computer is concerned with performance on hardware that's being shared through a service like AWS. If Apple has any concrete concerns, it's that developers would prefer to pay Amazon for the time they need on a Mac rather than purchase an entire Mac for themselves. It's an anti-developer move.
This idea that Apple is worried about an EC2 instance replacing a personal Mac is way, way, out there. What is much more likely is that a developer buys a lower cost, not Apple laptop and uses that to connect to a Mac on EC2 for the few tasks that require a Mac. Again, it's an move _against_ developers, it's not designed to make the lives of developers any easier.
Not a lawyer, I do wonder if such terms would hold up in court. I can see the case for EULA around virtualization when you're running multiple instances of macOS. But say I just buy a bunch of Mini's and rent (full access to) them out (bare metal, full system) per hour, rather than 24hr. Or for non-"development" work, whatever that means. Could Apple really put up a good case in court?
It seems unlikely that they could successfully sue me if I buy a bunch of Macs and give some people physical time-limited access (say, students in a classroom). What makes the difference? Remote access? Charging rent? I'm not sufficiently invested in these matters for a deep dive, so hoping someone with legal knowledge could chime in.
Inevitably, this inconsistency will be resolved, but not in the way you or I would like. Tesla is already removing features that previous owners unlocked at sale of the car.
Depends on if the courts look at this as a hardware issue or "digital" software one. I have a feeling they would look at like renting physical hardware in which the first sale doctrine would absoltely apply.
of course like with anything in the legal system it will take a company like Amazon that has their own team of $1,000/hr lawyers to face up against Apple's team of $1,000/hr lawyers in order to get a precedent setting case
That looks like a loophole for Apple. I wonder if soon you'll have to log in with your biometric identity document in order to use it plus always recording camera will ensure only the person who is licensed to use it, use it.
To use MacOS you have to first agree on their Terms, and through this they can legally block you from using it in certain ways. Like the famous "It is only legal to run OS X in a virtual machine if the host computer is a Mac." rule.
One thing is, they could write anything in the EULA, I was just wondering how much it is actually enforceable (even with a click-through "consent".
Second, I wonder on what legal basis they can actually impose usage restrictions of a whole Mac (hardware+software) via an EULA as long as I don't breach any copyright (which I don't think I do if I rent out usage of the entire system for a few hours).
AFAICT (again, not a lawyer), everything rests on section 1.J.[1] "Except as expressly permitted in Section 3, you may not rent, lease, lend, sell, redistribute or sublicense the Apple Software." being enforceable. (Section 3. contains the infamous terms for Leasing for Permitted Developer Services with the 24hr restriction). I don't know if such terms would hold up in court. If I read the thing correctly, the the EULA forbids people from lending their MacBook to a friend, or even resell it, which strikes me as quite absurd.
I have a hard time believing 1.J.[1] could be enforced as it sounds like you cannot sell your MAC, use it in a work or school environment. Apple can't risk to prove the point in court because if it is enforceable no organisation will touch their products.
I think the wording is ambiguous enough that it takes an actual court case to resolve.
In a broad interpretation, the prohibitions on rent/lease/lend/sell of "the Apple Software" would apply to the whole system (harware+software), which would forbid me to sell my old Mac. This would never hold up in court. But in a narrow reading, where the prohibitions only apply to the software, separated from the hardware it does not look like there is anything stopping me from renting out (access to) the entire Mac to a single user[1], for whatever purpose and duration I want. So those 24hr and "development purposes" would be moot.
[1] There's probably more than enough precedence to uphold number-of-users restrictions of software, e.g. Windows Server CALs.
I wonder the degree to which this is about apple trying to reduce their services crypto workload? When developers say they "want a mac instance" they often "want a mac instance that can talk to apple services like a normal mac instance" in order to sign apps and such. I'm not sure but I think arranging for that capability probably involves round trips with apple services to get required key signing artifacts into place ...
If instances are totally ephemeral in the same way as we are used to with linux vm's maybe that runs the risk of creating a real problem for apple services?
Taking a particular perspective and not really talking about the legalities, I can see some not so savory “non-development” work particularly when no one is seriously going to try putting macOS as a production machine for running SAAS apps, except perhaps using some of those specialized, bespoke chips:
- running apps in the cloud, not for q/a, but as a farm for adclicks and fraud. People already do that
- farm for generating and submitting low quality games primarily to sell ads. People already do this.
- Use backup images on systems with Secure Enclave in order to crack the encryption. Someone security company whose clients are state level actors, and increasingly, law enforcement, are doing this with iphones. I don’t know if a mac cloud makes this possible for other hardware
- The M1 is an Apple exclusive SoC with a lot of bespoke, specialized chips, and unified memory, and is only going to get faster for future Macs. I can see people trying to access a cloud for that, while ignoring the branding that links consumer, end-user experience with “Apple”. (Esp since Nvidia has bought ARM, and that RISC-in-cloud is becoming a big deal)
I am not saying those are a good enough reason to set the ELUA the way Apple did, but that I get why Apple might do this.
The flip side from my perspective. A monthly dedicated host on MacStadium is much cheaper than running an AWS Windows 2019 Server ondemand, or even with Reserved Instance pricing.
Why does that matter to me and the company I work for? Because Unity is behind on their Linux version, so CI builds are going to run on either Mac or Windows. I don’t really care that much about elastic compute for this, though being able to use AMIs matters more. The main reason we have not moved to using Macstadium dedicated hosts is that I would need to set up something like Chef as configuration management for what would be essentially a fleet of pet servers.
But if our team wants to deploy to either Mac or Windows as production systems ... I would be discouraging them from doing so.
Does this mean Apple explicitly allows re-sale (os license follows used laptop if you sell it), and explicitly forbids renting. (I can rent you my laptop, but then there's no way for you to legally run OS X on it)?
If you are in the US, it doesn't necessarily matter whether the terms would hold up in court. The question comes down to how deep your pockets are and how much money you are willing to spend to fight Apple. Apple certainly has deep pockets. There aren't a lot of companies that can take the financial hit to fight against a behemoth in court.
There's a limit to the power of deep pockets in court, especially if the remedy is not $billions. Many civil cases spend more time on damages than they do the actual dispute at hand.
The thing that Stucki is celebrating can be summed up with this line from the blog post:
> I’m happy to have an absolute guideline from Apple
Before this, it was a legal grey area. Now at least the rules are spelled out and are clear. More importantly, they are the same for everyone. I think we could all argue over what the "right" limits might be (or if there should be any), but at least MacStadium, AWS, and whomever else wants to rent out cloud-based Macs now know where they stand.
The legal gray area where Apple specifically called out their service by name in a presentation and how great their Mac Minis would be for their usecase?
The license changes basically allow nobody other than MacStadium to exist–throughout the blog post he gloats about how their business model is a hand in the new EULA's glove. And, of course, MacStadium been in contact with Apple to work this out, as he mention at the end. What has clearly happened is Apple asked them what the EULA should look like, or suggested a EULA based on what MacStadium is doing, and they went along with it. There is no way they didn't know that this would hurt everyone else's business (actually, he mentions this in the article, so he is writing this with full knowledge of that fact).
Even if MacStadium was not involved in this at all, making a blog post about a change that hurts your competitors and talking about how you are somehow better than them and deserve to exist is remarkably poor taste.
I'm pretty sure that MacStadium didn't limit their rental to one customer per hardware box out of spite for their customers, but because that's what Apple expected of them. So their were being held to a higher standard than some of their competitors, who had much higher profit margins by putting multiple customers on one machine.
So I think he is justifiably happy that Apple created a fair competition by clearly spelling out the legal rules for everyone.
The fact that Apple's official rules are close to what they were doing adds additional credibility to this interpretatio, because it suggest that they were following Apple's guidance before it became legally easy to enforce
I wouldn't put any blame for how these rules look like on MacStadium, because if Epic cannot negotiate with Apple on eye level, I'm confident that MacStadium never will. It's probably more like they received their future laws as dictated by their fruit-shaped God.
> Apple created a fair competition by clearly spelling out the legal rules for everyone
I think it could be argued that it shouldn't be Apple's place to set the rules of the competition. If MacStadium is correct, that the best experience is one-user-one-machine, then their business model should win out. It's not fair competition to rule out all other business models.
Sure, but that's copyright for ya. Apple gets to dictate the ToU for macOS. You can say that it shouldn't be Apple's place, and I agree, but macOS isn't free software.
> So I think he is justifiably happy that Apple created a fair competition by clearly spelling out the legal rules for everyone.
Thing is he's only happy because those rules are good for them. The way he talks about renting partial CPUs being somehow 'wrong' and makes them look like a ripoff is misleading. Just because you can get a VPS or hourly billed CPU time does not mean you can not get a full machine as well. But cost matters a lot, especially to smaller developers.
I have no problem with MacStadium's business model; in fact, I have seriously considered renting Macs from them in the past specifically because of their service of providing a dedicated machine for an extended period of time. In that case we were looking at running extended builds and the cost of downloading Xcode, then our source tree, then running a build for hours on a per-hour service was fairly competitive with what was being offered by MacStadium. That we didn't choose it was mostly chance and external factors.
What Apple did here is create a monopoly for MacStadium, at least in the near future, and remove services like AWS from consideration completely. Brian's claims that they were simply offering their services in a way that "felt right with what Apple would have wanted" is marketing drivel. I don't care if I am getting a single core out of four, I'm not trying to browse Safari on this machine. Just run my builds and give me what I pay for; that's how CI works for literally everything else.
> Brian's claims that they were simply offering their services in a way that "felt right with what Apple would have wanted" is marketing drivel.
It's not only marketing drivel, it's a downright strange statement. I mean with which other product would you consider the wishes of the anthropomorphized business which created the product in terms of how you use it? Normally the product is meant to serve the consumer, not the other way around.
> What Apple did here is create a monopoly for MacStadium
Why can't any business rent out physical Macs on a 1:1 basis on the same terms as MacStadium? It looks like they can, and if so then it's nothing favorable to MacStadium specifically: it's just not favorable to fractional renting like AWS.
Other than MacStadium already having that business model and their competitors that are hurt not having that model. They'd need to put in effort to transition at the very least.
…that Apple randomly selected, so now they’re the only thing that handled this right now. It’s a monopoly in that they are the one that exists and other things cannot, legally, since they had a business model that they must now change.
What makes you think that Apple selected this business? Don't you think it's more likely that this business simply reduced it's risk exposure by asking Apple what it's plans for Macs in data centers are? Apple is making the rules, not some third party company that is following them.
Aren't you misrepresenting this situation quite a bit? When it comes to business you are always on the hook for your own mistakes. If your company engaged in a risky business model then as the owner you are personally bearing that risk.
There is nothing dishonest about asking Apple about its future business plans and following Apple's rules. If you base your entire business on skirting rules then don't come crying when they are suddenly being enforced. It's on you to make your business work.
Small-m monopoly. Apple picked their business model and killed off the others; for now they’re the only game in town. I’m not claiming they’re going to use their position to control the market or anything.
Apple's angle here is that everybody who needs a Mac has to buy or rent one. That seems super obvious.
It also happens to align them with people who are in the business of selling or renting Macs, sure. But the point is not to screw AWS or MacStadium's competitors. The point is to sell Macs.
The obvious side effect of selling more Macs is that it hurts AWS and MacStadium's competitors. Developers don't want to buy more Macs from Apple that they don't need. Apple knows this and has known this for decades and so their actions are essentially the same as telling developers to suck it up and buy new Macs.
Which isn’t strange, seeing as their business is selling macs. Having a Mac is not some fundamental right or essential for survival. It is just a product.
If your complaint boils down to not liking what Apple is doing then why are you still using their platform? If you are using it privately then it's on you. If you are using it professionally and your company is paying for it then it's your job and responsibility to put up with it but it also means you're not on the hook for the extra expense of renting a Mac.
Yeah, I think that pretty much nails it. If putting up with all Apple's BS and extra costs puts you in the red on their platform professionally then the business decision seems obvious.
EULAs definitely apply in the EU. As do software patents. But as always, things are a bit more complicated than either you or pjmlp summarised. eg
- EULAs cannot deny permissions that are allowed under consumer rights.
- It's also worth adding that software licences behave slightly differently to EULAs in that software licenses are designed to provide additional rights above what copyright laws typically allow (this is particularly true in the case of open source licenses) where as EULAs are often (though not always) designed to place restrictions on top of existing consumer rights. Hence why they're often considered invalid.
- I'm not 100% on this specific point as it has been a few years ago since I've investigated it but there was once some contention about whether it's even legal to place a licence agreement to the user after said user has already purchased the product. However companies could still use an EULA to revoke support -- much like a company can revoke warranty if they suspect the device has been opened up (eg the tamper strips). The rules here might have been clarified in court since I've last investigated this point though.
- "The European Patent Convention states that software is not patentable. But laws are always interpreted by courts, and in this case interpretations of the law differ. So the European Patents Office (EPO) grants software patents by declaring them as "computer implemented inventions"." source: https://fsfe.org/activities/swpat/swpat.en.html
- Even the FSFE (Free Software Foundation Europe) quote above only tells half the story regarding Software Patents within the EU. There are some restrictions on what counts as a "computer implemented invention" plus also there are also national level patent offices that override the EPO at a local level. Wikipedia has some good summaries about this: https://en.wikipedia.org/wiki/Software_patents_under_the_Eur...
EULA may not have much if any force in some jurisdiction, but that's typically for private individuals. Corporations can reasonably be expected to have lawyers to understand legalese, for one.
Not saying the EULA would definitely be enforceable, just that it's not that simple in this case.
Apple obviously doesn't want companies like AWS to be renting Mac Minis as some sort of VDI solution. That's consistent with the (shitty) practices of Microsoft with respect to Windows, which confines Windows 10 hosting to Azure services.
Given the nature of Mac, an AWS MacOS service is unique in that it's very clear who the manufacturer of the underlying hardware is. Apple, given it's control-freak nature wanted to have a model that accommodated both their needs and the provided a clear, multi-provider model to do what developers need.
Windows 10 hosting is not confined to azure services, you can even bring your own license to AWS, or host your own terminal services, or run your own virtual apps, or literally anything.
I was imprecise in my wording. You cannot bring a shared Windows 10 virtual desktop to any provider that is not Microsoft Azure. Azure uses a delivery model based on tech for education customers that allowed 4-5 K-12 students to work from 1 PC via thin clients, and that model is only available on Azure. (And it's really cheap.)
If you do BYOL of Windows 10 on a non-Azure cloud service, you need to meet specific Microsoft EA requirements, and you must run on dedicated hardware. If you look at the AWS BYOL model for Workspaces, it very similar in cost to the Apple on AWS model. (https://aws.amazon.com/workspaces/pricing)
As far as I am aware, the new changes are clarification to the old terms, which didn't really say much at all. The situation where you have a clear "no" is significantly worse than the one where there's no specific rule prohibiting it. Many companies can and have decided that the latter was good enough to offer a service off of; no company with a competent legal department is going to offer such a service now.
It is still not allowed to virtualize macOS and rent that virtualized macoS: lease hardware and software ”in its entirety to an individual or organization”
The wording and language in that blog post is absolutely wild. Its demonstrably and undeniably better to have access to smaller virtualized Mac instances, or per-hour/per-second billing, or general use. Undeniably. There is literally no cogent argument I can think of to the opposite, on any of these points, but I understand why Apple is making these guidelines; If I had to follow them, I wouldn't be happy about it, but similar to the App Store guidelines you just gotta do what Apple wants.
That post exudes happiness at the guidelines, like an oil company that just got a regulation passed banning solar energy. I understand the happiness at finally getting validation that Apple is alright with this business model, but that's separate from exuding happiness at the terms of that validation.
AWS are offering the first ever officially supported macOS virtualisation, I would call that a milestone. Given the costs, you would only use these instances for "approved" development work only. It is aimed at larger companies where maintaining a MacBook Mini build server is relatively expensive. Such companies will be using more than one instance of a MacBook mini to have a level of redundancy in case of a failure. If they are used in earnest, such instances would have to be replaced at least every year with old instance disposed off professionally (scrambling hard drive contents, etc). Yes the instances are expensive, but there is a definitely an use case for these.
Neither is it first. MacStadium have done this for years.
GitHub Actions, Semaphore CI, CircleCI, Bitrise, they have all done actual virtualisation of macOS for a number of years too. Yes it's a slightly more specialised problem domain, but nothing about this is correct.
Technically no, but the word has come to mean something different. Because even bare metal instances come under the same APIs, security, architecture and usage model as the other "real" VMs, the difference is very slim now. We can think of them as VMs of a specific size with a minimum billing time and get on with using them with our existing tooling.
> but the word has come to mean something different
No, it hasn't. If you're using "VM" to include bare metal, then you are using the wrong term for something. The definition of the word "virtualization" has not changed.
I think you’re using the terms incorrectly. This is “Hardware as a Service” not a “virtual machine.” Yes, AWS Nitro provides extensive management services for both, but they are fundamentally different things even if you access them in similar ways.
The new instance name is “mac1.metal” just like AWS’ other hardware as a service offerings:
If you are a startup, you can have your MacBook Mini in the office. As a larger organisation, you will need a dedicated server room for it limiting access to authorised staff members. You are likely going to need more than one, as you don't want your developers sitting around doing nothing if your MacBook Mini fails. You also need to allocate IT budget to maintain your devices and to replace them on a regular instance.
Why not ditch the entire Apple ecosystem while you still can? Show them that we, developers, don't like feudal lords that like to tell us what we can and cannot do with our systems. So others won't dare to copy them.
Because there's money to be made by not "ditching the entire Apple ecosystem."
If you were able to run a business that was fun, that made you money, and that enabled you to help other people have fun and make money (i.e., your employees), would you not do that out of principle? I'm genuinely asking.
> Because there's money to be made by not "ditching the entire Apple ecosystem."
That's very shortsighted. You can make money without Apple. And by doing so, you show that you value open, generic compute systems. Also, the prosperity of your business won't be at the whim of Apple.
You could also make money by selling paperclips or by creating satellite constellations. Which path you choose comes down to interest, expertise, and luck/chance.
All businesses have constraints. In this business, you're subject to the Apple EULA. In others, you're subject to government regulation or pricing pressure due to commoditization. That's not short-sighted — no industry is forever, and there's money to be made now. Why not deploy their expertise toward financial success (and, presumably, fun)? There's demand for these services — someone's going to fill it.
For folks who don't value 'open, generic compute systems' over 'putting food on the table', the closed nature of Apple's ecosystem is just the reality they need to deal with. They're not making a moral tradeoff, just a practical one.
Are you suggesting MacStadium and co should shut down their businesses out of principle? Will you employ them once they do? Where will their customers go?
The EULA applies to leasing the whole OS. I don't need a whole virtual Mac to run CI jobs. It doesn't sound like there's anything stopping anyone from offering a Mac CI job runner that gets shared with multiple organizations at the same time.
There are some fairly broad usage restrictions in section 1.J.[1].
Except as otherwise permitted by the terms of this License or otherwise licensed by Apple: (i) only one user may use the Apple Software at a time, and (ii) you may not make the Apple Software available over a network where it could be run or used by multiple computers at the same time. You may not rent, lease, lend, sell, redistribute or sublicense the Apple Software.
if I've mac with accepted EULAs and share it via network to wife, kids or neighbor (might be even wife/neighbor used it to do some business activities) - how it does works from legal perspective? is it will viewed as EULA violation?
"The instances are launched as EC2 Dedicated Hosts with a minimum tenancy of 24 hours"
These are just rentable Mac Minis, not VMs. This will have only one use case and that's for build servers. Unless anyone has scalable AppleScript jobs to run?
But they will have to update to Big Sur in the feature. So if they don‘t set the limitation now they will have to „worsen“ the service later, it‘s best to the set the limitation now even if not required.
They still think of themselves as a hardware firm, this restrains usage elasticity to a level where system hardware scaling is a dominant cost driver rather than system performance.
Besides the inefficiencies of physical space at AWS sites, it is also a fine business for the cloud provider as it generates a less volatile usage pattern than normal. As Apple is acting as a monopolist by dictating the same terms to everyone, they further remove any competitive advantage of providing anything else.
I vividly remember a video interview with Steve Jobs from a long time back when he was clear that Apple is not a hardware firm, it’s a software firm, and admitting that it took him far too long to realise that.
I think you are missing the point intentionally. You can't run those apps on an Apple iPhone, but I suspect you knew this.
It's ok to take the literal definition of the word monopoly and take it to its logical conclusion, I suppose. The U.S. government will not do that, however.
If you don't like it then leave. That's how Apple operates. I still can't comprehend why people insist on licking Apple's shoe soles but then complain that it tastes awful.
Wow. That is insane and stupid and incredibly fucked up. I've had to rent Macs in the cloud on a rare basis to test certain latest-version Safari issues, and it's always a crap connection and a miserable experience. But is it enforceable for them to stipulate the minimum length of time of a VM lease?! That's your machine. You paid for it. If you want to rent it out to someone for 3 hours that's your prerogative. I don't see how they can possibly enforce that or how it could be legal as a seller to tell someone how to use their hardware.
If you ran a webserver hosting Great Cat Pictures on some Macs, for instance, your customers might pay a subscription fee to access your site, meaning they are paying for you to do processing and storage on their behalf. So that's an example that's clearly not leasing or subletting the devices.
Likewise, you might read it that Circle is simply providing a service to users, and the users are paying a fee for the service.
But a CI service will set up your dev account, your container image, to run your jobs. It'll even let you shell in, and it tears it all down when you're done.
And it really starts to look like leasing when they also charge for time used on various hosts. (IIRC, Circle charges for this a bit obliquely as max parallelism.)
If it went to court, Circle might argue the hosts can only be used within their larger CI system, that they don't guarantee a particular task will complete on a given host, and that they're not providing other requirements for virtual hosts, e.g. dedicated routing or names. And then Apple's lawyers might counter all that.
So this is where I think lawyers would start digging through case law to figure out where providing a service ends and leasing begins.
It's reasonable to think running CI service is similar to just running httpd. But what divides? Anyway CI service runs Apple software like Xcode. Even httpd uses Apple's TCP stack.
I've done iOS builds using Github actions. The build minutes cost 10x as much as Linux. Anyone out there offering MacOS in the cloud is doing the same thing. Just racking Mac Minis. It means you can't slice CPUs or memory like a VM so it's less efficient and more expensive.
AWS needs to buy a lot more mac machines from apple. Without the limit everybody would start a vm for a few minutes to run a ci job and stop the machine. So there is no „sharing“ of a machine within a 24 hour window if you only need the machine shortly.
I doubt Apple supports this in any way. It means that if you want to develop Mac/iPhone apps, you no longer have to buy Mac hardware. I'm surprised they aren't making this harder.
It's going to be out of their hands on this one. Apple have pretty strong EULAs.
Microsoft's licensing for clouds is also a pain in the arse. You (the cloud platform) have to pay for a full months license the moment an instance is created. The way it's structured you have some wriggle room, e.g. you have your placement algorithm land new instances on where Windows instances have already been in a given month, so you don't incur additional licenses (because the license "transfers"). It gets worse if you start wanting to do things like run SQL Servers, where it's the entire month license outright with no prorating, and it applies to a specific instance instead of the machine/VM slot.
Strangely enough, despite all the trends in the market, operating system vendors are determined to make it harder for people to pay them to use their stuff, rather than easier.
Strategically it makes sense. Apple is a hardware company, so making it difficult to run their OS in the cloud means more people need to keep buying their hardware. Microsoft has their own cloud, where they don't have to deal with the license requirements they force on other cloud providers, which gives them a competitive advantage over their competitors (when it comes to windows servers). The key is that these companies don't just sell operating systems. Red Hat on the other hand, which doesn't have competing market pressures, is much more friendly to licensing in a cloud environment.
But is using legal mechanisms to reduce a competitor's advantage (where the competitor licenses your product) considered to be antitrust? In the internet explorer case one of the major disputes was whether Microsoft manipulated its API to favour explorer versus other software.
IANAL, but I think only if you have monopoly power (at least as I understand US antitrust law), and MS doesn't really have a monopoly on the server OS market.
> Microsoft's licensing for clouds is also a pain in the arse. You (the cloud platform) have to pay for a full months license the moment an instance is created.
This is exactly how I would expect the licensing to work.
Can't you also bring your own licenses for AWS/Windows? This all makes sense to me too... if you want to run a Windows instance, you need a license for Windows (on top of the hardware fee). Microsoft says that AWS can loan you a license (if you need one), but AWS would still need to hold a full license.
In terms of "other people's computers" it seems to fit well. Nice to be able to build/CI test against macOS without having to provision and maintain apple hardware.
You “can”, in a technical sense, but not legally—Apple’s licensing for macOS only allows it to be run on Apple hardware. (You can run a macOS domU on another OS’s hypervisor, but that hypervisor has to be running on a Mac.) This matters when you’re a corporation.
I don’t know about the legalities, but according to Apple you are only allowed to run macOS on real Mac hardware. Anything else is probably an EULA violation or something.
As an aside, in the script you link to is this line
It's against Apple's T&Cs, though. If you're doing it at home by yourself, who cares. But a company that's interested in automated testing etc. isn't going to see it as an answer.
Get an old old old Mac pro from ages ago. Upgrade its motherboard. Then upgrade its RAM. Then upgrade its hard drive. Then upgrade its power supply. It will still be an "Apple-branded computer" because of its case. It will just have received a bunch of upgrades. Big "haha" to them.
(Or if you're actually a corporation just buy a Mac.)
You can't really test apps if there's no graphics acceleration. If you want graphics acceleration, you'll need to run a macOS VM with GPU passthrough using virtio or Proxmox. I did that for a bit until I just gave up and bought a Mac.
"These are just rentable Mac Minis, not VMs. This will have only one use case and that's for build servers."
It's difficult for me to believe that a hyper-scaled cloud deployment like AWS will rent individual mac minis to people. It sounds like a business idea I would have and then come to realize how labor intensive and inefficient the entire thing was.
At the same time, I wonder why there is not a well developed, well documented cross-compiling toolchain available for (whatever you are doing with a mac build server) ? Why not use your local (laptop) mac to do the dirty work and then run a (very complicated) cross compiling chain on a much cheaper, non mac, cloud instance ?
In the past when we needs iOS jobs to run from Jenkins we literally plugged a Mac Mini into the wall and forwarded a port from the router so it was reachable as a build agent by our cloud instance of Jenkins.
What other thing is worth doing on MacOS at scale in an off premise cloud? I'm genuinely curious if there isn't something I'm missing out on. Build and test for Apple related stuff is the only thing that comes to mind.
You can get more than 10 times as many ARM cores on a server chip compared to a M1 Mac. There is no way it is more energy efficient or cost effective to run 10+ Macs versus one server. Amazon designs their own chips, too.
But until now nobody was able to build an ARM cpu as fast as apples cou. Every server arm cpu in the past was still a lot slower than intel cpus, despite packing a lot of cores on a chip.
> Someone points out Circle let’s you ssh in, while afaik GHA and Pipelines don’t
That's mostly a convenience feature, you can ssh into GH Actions' macOS instances through something like an ngrok tunnel, or run a terminal sharing tool within to basically do the same. See for instance https://github.com/fastai/fastmac. I doubt that's a key difference.
I find it disgusting that Apple can force people to jump though these hoops while paying them a huge premium for sub-standard hardware[1] so that these people can develop for their platform.
Not only are they bleeding the developers at build, test and sale time. They are providing a shitty experience while doing it.
Of course from an economic point of view they are right! For businesses it still makes sense to do this most of the time (especially since webapps are crippled on iOS) due to the large user base. If they didn't have that user base I'd bet very few people would tolerate this crap.
This is one of the handful of reasons that I boycott Apple, I find their business practices morally unacceptable.
Safari support (and even chrome, FF on macs) is horrible. They've become the new IE in terms of typical web programming that works everywhere except that platform. In the past year, every browser-based support issue we've had to deal with across multiple projects is due to Safari not handling things the way the rest of the browsers do.
Worse, there's issues that are specific to Apple devices (iPad rendering of certain CSS, works everywhere else, including Mac's own emulators, but renders fubar on the actual iPad), leaving the debugging/fixing process a trial and error issue. It's horrible.
And even worse, this can't be debugged on anything but a Mac anymore, so if you don't use Mac as your primary dev platform, you're near-screwed when it comes to trying to resolve web app issues that only arise on their platform.
Then there's mobile app management, which is just as bad in it's own way. We had an app on the App Store for three years, then all of a sudden during one minor maintenance update they decided it wasn't allowed on the store any more and immediately pulled it. Thousands of business users affected, and two months to get the app propped back up on a custom business distribution channel, thousands of dollars worth of process re-development, etc.
Apple is the absolute worst platform for business-productivity programming. They screw the developers with a far stiffer rod than any other company has ever done.
+1 on this. Developing for Apple means you have to only use their tools. I legit hate XCode as an IDE. I tried to do swift in VScode last year but the language server was very barebones.
In my mind, despite this Apple is successful because they make fantastic hardware. If Apple didn’t have the fastest chips and stellar cameras, they wouldn’t be successful. Developers jump through so many hoops because the customers are there.
MobileSafari doesn't support a number of "PWA" features that Android Chrome does. Push notifications, for example, always require a mobile app on iOS (which I think is a good thing, personally, but I can understand other perspectives).
GitHub has been doling out tiny macOS runners in virtual machines for a bit now [1] (seemingly in violation of macOS SLA), and these were hosted on MacStadium [2]! So for MacStadium to come out and pretend they were following the rules the entire time is disappointing.
How is this at all MacStadium "pretending" to follow the rules? At worst, this is GitHub violating the rules.
MacStadium is renting those macs to a single customer for longer than 24 hours. MacStadium is following the rules. MacStadium is just providing a platform.
You're not really expecting MacStadium to snoop on each customer's usage and business model to enforce Apple's rules? AWS certainly won't be doing that.
If Apple told MacStadium or AWS to stop offering Macs to a customer such as GitHub due to some EULA violation committed by GitHub, they would probably do that.
I don't understand why your comment is trying so hard to frame MacStadium as hypocrites.
> I don't understand why your comment is trying so hard to frame MacStadium as hypocrites.
MacStadium customer here. It's an arm's length setup. They don't ask what you're doing, just give you the keys to the machines. BUT, when MacStadium's (likely) biggest customer is running thousands of hosts for CI jobs, and even lists you as the vendor in their docs, it's perfectly obvious that multiple end user jobs are being run on that host per 24hr per.
It really boils down to who Apple is going to bother to audit / sue.
CI runners are kinda different than VM hosting. I mean sure you could abuse them to run sshd and interactively use them for a while :D but the service as intended is that you don't "rent" the VM in any meaningful way, it's fully theirs, they just run your one single job on it and show you the logs.
Prior to Big Sur, it's my understanding the macOS SLA explicitly disallowed this. Snippet:
> Except as otherwise permitted by
the terms of this License or otherwise licensed by Apple: (i) only one user may use the Apple Software at
a time, and (ii) you may not make the Apple Software available over a network where it could be run or
used by multiple computers at the same time. You may not rent, lease, lend, sell, redistribute or
sublicense the Apple Software.
You could argue that the CI service is the "one user", and it doesn't make the software available over the network, it only makes logs available over the network.
This seems like a gray area, "does running a build on your behalf constitute renting out the build environment to you" is a very hard question.
I am not a lawyer but it doesn't seem like a gray area at all to me; you are providing inputs to GitHub and they provide the outputs of mac software over the internet.
What's maybe more of a gray area is whether apple can assert the user doesnt have these rights in their eula.
I can't see a way to frame it otherwise - it's certainly functionally identical in terms of effect, both on the end user's need and on Apple's interests to sell hardware.
As weird as it is, I think as long as they provide an entire physical Mac you’re free to run as many macOS virtual hosts on it yourself as you want to. At least that’s my understanding of the EULA explained in the MacStadium blog post.
It seems we are making the assumption that GitHub/MacStadium are bound by the same terms as everyone else. There is nothing that says they can't get special treatment for some arbitrary reason.
The limitation is only from Big Sur. AWS chose to do it on Catalina so that customers may not experience a big change later on. This means any provider who uses < Big Sur is in compliance.
> As always, I asked the EC2 team for access to an instance in order to put it through its paces. The instances are available in Dedicated Host form, so I started by allocating a host.
Dedicated Hosts (https://aws.amazon.com/ec2/dedicated-hosts/) are more pricey than virtual instances (most EC2) and Dedicated Instances. Not sure if it's possible to containerize/sell as many virtual instances off a dedicated server without paying a separate high license fee to Apple.
Apple’s licensing terms for macOS permit only the licensing of one unit of Apple macOS running on one unit of Apple hardware to one customer for a minimum term of one day. There is no option to purchase a virtual-machine or other shared-instance license when macOS is involved.
(Nitpicky points: I believe the customer can do whatever they want with their licensed cloud Mac hardware, such as dual-boot different releases of macOS or virtualize to their heart’s content, as long as they are the exclusive user of the Apple hardware underlying any instances of macOS. “One customer per Mac per day, no more and no less” is probably a better summary in hindsight.)
No mention of pricing that I can see, and I don't see it on ec2instances, AWS's pricing page, or the spot-pricing widget on the console.
Am I missing something?
Edit: And the reserved instances widget (I was going to guess based off this cost) just flat out breaks when you pick mac. I guess we're still in the "If you have to ask, it's too expensive" stage, or something.
Does that include their Mac Cloud offering with custom networking/subnets, or the per Mac Mini rentals? Generally the cloud services (similar to AWS) are pricier.
I’m working on https://screenplay.dev, where test every change against a battery of open source iOS apps (Wikipedia, signal, etc). We started on GitHub actions, but found it much cheaper to buys ~4 Mac mini’s and run them in the office. It takes a little love to keep them up to date and stable (maybe an hour a week), but in return we get cheap, debuggable Mac computer. I like that more offerings are appearing, but at this price, we’ll stick to our furnace of Mac mini’s for now.
At a first glance this sounds exciting: We use a lot of different versions of macOS and Xcode for building our apps. We have one dedicated Mac, and about 5 VMs on a second Mac that we use for building our software. Keeping everything up to date is a pain.
So if we could just rent Mac VMs that would be nice. But this is pretty much useless. You get only a single machine for a really high price.
Theoretically I could run VMWare on the rented machine, to run multiple virtual copies of macOS, but then I'd be doing all the maintenance that I don't want to do.
Cloud services to build/deploy for iOS already exist and are nowhere near this over-the-top expensive so no, I don't think cross-platform devs are the target market here.
Given how M1 is technically impressive (not only CPU but also for Neural Engine), one can dream Apple will resurrect XServe with multi-socket later versions of their silicon.
This kind of performance with this kind of power efficiency would be game changer in data center.
I can't seem to find pricing for this - anyone understand AWS better than me?
It's not listed on their dedicated host pricing page at https://aws.amazon.com/ec2/dedicated-hosts/pricing/ , and if I go through the web console to create an instance, I'm prompted to create a Mac dedicated host without any indication of how much I'd be paying.
This seems 100% about building in XCode, which leaves me wondering why it's being offered as an EC2 instance instead of some higher order build tool. Is there a use case I'm missing?
Interesting. I guess it's not the first but does the MacOS EULA really allow for this? Or does AWS have a special license? Which would beg the question as for the need of real hardware. (Sure you can break a EULA but at some point it would violate ToS and Apple could easily block updates).
> The instances are launched as EC2 Dedicated Hosts with a minimum tenancy of 24 hours.
This almost sounds like they are using first sale doctrine to just lend it for a day. Like I can lend a movie but I can't make my own movie theater (right?).
Also I'm very curious of these are in-tack macs or shucked and put in a frankenstein case of dozens.
> Powered by Mac mini hardware and the AWS Nitro System
Similarly, other Mac server farms use Apple hardware. I can't think of the name right now but I remember one popular provider racking trash can Mac Pro's.
If the current offering is Mac Minis, chances are Amazon has built an industrial grade version of what https://www.macstadium.com/ offers, and have racks with tons of Mac Minis, probably with custom ducting for A/C and so forth.
Nobody will without Apple allowing it and taking part, and Apple has not been supportive of things like this. E.g. any macOS hoster and many companies doing macOS software would love to throw money at Apple for permission to run "hackintoshes", but no dice, and the structure of this offering suggests AWS didn't get special treatment either.
I don't think I'm understanding. You are saying nobody will do it without Apple's support, but then say that AWS is doing it. There have been Mac Mini hosting for years, so I'm missing what is different about this.
Nobody will put M1 chips on their own motherboards/blades without Apple support. This is just offering Mac Mini hosting integrated in AWS' platform, with some custom hardware (that AWS also uses elsewhere) attached to the Mac Minis for storage virtualization etc.
Gotcha. Yes, that was what I was referring to as well. I don't think I was very clear in my original comment. I just meant if AWS doesn't offer M1's via Mac Minis that someone else will.
Boycott Apple completely. How did we go from open development to some overpriced, only half decent and walled mess that's now worth $2 trillion? Shame.
Because that’s the solution that resulted in my parents not suffering from malware and various toolbars in their browsers. There is no way they or a significant portion of the population was going to learn how to discern good programs from bad, and a walled garden is apparently the option that works.
This seems a bit half-baked and niche at the moment. You have to rent a whole machine for 24 hours, which is expensive and prevents on-demand scaling. I wonder if Apple and Amazon are just dipping their toes in to prepare for a deeper collaboration in future.
I'd take the fact that the 24h restriction from Apple's licensing hasn't been removed as a sign that there isn't much collaboration going on. Apple granting an exception from that would seem like a no-brainer if they wanted to support a partner offering this.
Given the pricing of these instances ($24/day with a 1 day minimum), nobody's going to be deploying their autoscaled k8s clusters on these anytime soon.
The thing I still don't understand with Mac, even if you were to virtualize it, is that VNC is abysmal compared to RDP from Microsoft. How are people actually /using/ this hardware (short of command line x-code builds)?
You can only use this for: "Permitted Developer services."
This is defined as "continuous integration services, including but not limited to software development, building software from source, automated testing during software development, and running necessary developer tools to support such activities."
$999.99 per month. "We wanted to redefine how people interact with macOS, on a deeper, ... and more granular level. Truly redefining the user experience and rethinking what was really possible, in the cloud."
Interesting that they’ve mentioned M1 support. That makes me wonder if VMWare is going to get together with Apple and make a ESXi port to Apple Silicon, as the Mac Mini and Mac Pro were long standing on the HWL since they were the only rackable devices on the market legally allowed to virtualize macOS. I’m fairly certain that Apple used it internally for testing.
(AWS will probably at least attempt a port of their Nitro hypervisor to M1 as well, since it’d make the machines infinitely easier to manage at scale since Macs no longer have a NetBoot or Internet Recovery option).
AWS does not use netboot, EBS volumes appear as local NVMe drives because their custom Nitro PCIe cards handle that. In the Mac case, they connect the cards using Thunderbolt.
The Mac instances will NOT use an AWS provided hypervisor until Apple's terms change. Currently the hosting provider is only allowed to lease the whole machine, only the end user can do virtualization.
Interesting. The deciding factor for our family when buying a Mac or Windows 10 device for my wife’s small business was actually my need to upload iOS apps for review by apple.
I’m an after hours hobby developer, and use a windows desktop. It’s powerful and has all the tooling I require. And it supports all the games I want to play from the steam store.
So - I think apple will lose a little bit of business from people like me with this announcement, as I’m sure we would not have purchased a Mac when we did only a few months ago.
The pricing makes this pointless for small businesses. $1/hour and minimum tenancy of 24 hours means each time you're updating your app you're spending $26. After 25 app updates you could own a brand new Mac Mini (assuming you never need to spend an extra day testing). Buying a used Mac makes even more sense.
MacStadium also already rents out Mac Minis starting at $59/mo.
I think the Amazon offering only makes sense for big corporations where (1) IT doesn't want to support macOS/exotic hardware on their network (2) it's easier to just charge to your your existing AWS billing than get a hardware purchase approved by your boss
Agree, but my needs are simple and I develop using expo.io. So once my app is published often minor changes can be pushed straight through to my app without App Store approvals. So it would be $26 per upload (ouch), but my “upload” may only be once every few months so I’d easily be ahead.
Alternatively, Apple might gain revenue from iOS and macOS builds becoming more accessible
Wishful thinking: resurrect the xserve. Give me that 1U Apple appliance so I can stop stacking up Mac Minis (we have an incredibly non-trivial amount of iOS development happening across multiple divisions. Current Mac Mini count: 8)
You only need it for compiling. There are plenty of cross platform frameworks that dont require to develop with xcode - and that's good in my opinion.
I built all my apps this way and faced the same problem as OP - so had to buy a Mac mini. It was the cheapest option ~8 years ago and I still use it today for the same purpose - just for compiling. I assume there are probably more of us.
My needs are simple enough that the standard inclusions in expo.io work without complication. I could imagine more complex apps need a more involved dev setup but not in my case.
Expo.io is good enough for my needs. Cross platform, just run it on my iPhone and and android simulator. Also, the way expo works is that not all updates need to go through the App Store approvals. I can quickly dev/test/release once I have the app container approved by the relevant store.
My only need for a Mac with expo is for the upload. The apk file is taken care of with the command above.
I have an iPhone I use for development and testing. Bonus points is that expo is cross platform, so I can publish to google play with the same single code base too.
I’m always developing without xcode. Using expo I can write apps in react native on my desktop and vscode. Mac only required for the upload to the App Store.
Yeah, I was about to buy an Apple laptop since I also have been doing more and more cross-platform app development. Didn't like borrowing others' laptops and doing the laborious process of switching to my icloud profile just to upload some apps to the app store.
I'm definitely out now. I was never the target audience for Apple products anyways so maybe they're not too worried about this
I wonder if these can easily run linux AMIs. Since OSX doesn't have native containerization, our CI system for mac builds runs linux on mac minis and runs osx VMs inside of linux since you're allowed to run osx vms on linux if linux is running on mac hardware. So in an ideal world, we'd run our own linux AMI on the baremetal mac instances and run OSX in VMs.
I'm sure it's possible of course, but I wonder how painful it would be to setup. Fighting EFI/secureboot? Some other bootloader?
I bought a Mac mini for iOS development and gee am I regretting it.
Especially this these devices cannot be booted unattended - if it ever powers off, I need to: take it out of the closet, plug it in my desktop, turn off file encryption, put it back in the closet, boot it, VNC in, and finally turn on file encryption again
How can this be viable cost wise. With their minimum billing of $1.083 an hour, and a minimum of 24 hour billing, unless you want this for a short time only, these costs are way too high. macstasium.com has much lower costs for this.
Lots of folks in this thread seem to be unaware that other companies offer Mac mini hosting, at less than one tenth the cost. If you don’t need the full AWS ecosystem for your workload it’s worth doing some research.
Seems like a major new growth vertical for AWS and gives Apple the ability to vet this [if its successful] for potentially launching their own offering one day.
Someone commented on a previous thread that the M1 Mac mini hadn't changed form factors despite a reduction in component size, lamenting that it had retained the same size and shape as its on-Intel predecessors.
This is the reason.
Datacenter customers (really, any customers racking minis) likely represent a meaningful share of Mac mini sales. Changing the form factor would mean these high-value customers would need to re-tool their racks to support a new design. Even Apple is not immune to the pressure of large customers.
This could be huge for the ecosystem. For example, there are ways to use third-party iMessage clients (e.g. through Matrix) that require you to keep a server running on your local macOS machine signed in to your AppleID - this could let developers create hosted versions of those services
One Mac (serial number) per instance, so you probably couldn’t host iMessage or other access to Apple Services without getting burned after a couple days (and AWS wouldn’t want you doing it and getting a whole rack of Minis banned from iCloud or something).
how does this affect companies like buddybuild that offer CI/CD for ios? has it commoditized them, or does it give them a lower cost way to run their cluster?
For CI/CD providers, it depends on how they offer the underlying macOS environment. If they target enterprise workloads that have stringent compliance needs, then this offering is a net benefit especially if the enterprise is already on AWS. The cost isn't cheap but there are many ways to price it as a value added provider.
CI/CD for iOS, MacOS, and React Native builds. Right now the pricing for Mac instances for builds via Github, Gitlab, Circle, etc are ludicrous. For a certain developer velocity, these instances will probably be much, much cheaper than running builds through the CI/CD SaaS providers.
$26 per day according to TC, for a full Mini (6 core i7/32 GB RAM). If you do enough that you can get high utilization that is cheaper than the CI services. (e.g. travis wants close to double for 2 vCore/8GB VMs) EDIT: On the other hand, renting a physical machine at Macstadium is a lot cheaper, so you'll want to have the AWS integration or some flexibility...
Automated testing using browsers on target operating systems as well as other testing that requires the target operating system. CI/CD pipelines using Mac build tools is another.
Custom CI agents perhaps. Or maybe on-demand / shared build / debugging machines for a development shop that does mostly cross-platform mobile development and (very) occasionally encounters ios-specific bugs.
Build servers for iOS apps, it can also be part of a CI/CD flow for mobile or cross-platform apps because you need to be running MacOS to upload apps to App Store Central
AWS is playing the long game and betting that M1 based servers start to take off. It's very risky (and expensive) but it would pay off if they are correct.
They would be first in the market and be years ahead of their competition.
I doubt this is a play at M1 servers. M1 servers on Apple hardware is not what AWS wants people to use when the alternative is other AWS servers. Only for running macOS there isn't an alternative.
Because they'd much rather use their own high-density server designs instead of dealing with Macs that really aren't made for datacenters, and M1 has no clear must-have benefit over those justifying that effort outside of the macOS use case.
Now if Apple were to selling/license M1 chips to them, that might be different, but there is no indication that's going to happen in any way, and then the current work based on Macs wouldn't really be preparation for it.
I disagree. I think it’s obvious that if they went into it big, they wouldn’t just buy retail Macs. The current work would be testing the market and the experience of providing MacOS as a server. If there’s demand for server M1 chips, why wouldn’t Apple sell them? It’s a completely different market from their laptop consumer business. Bottom line: if the market demands M1 on servers, there’s billions to be made supplying them.
Apple clearly isn't interested in others offering macOS servers on non-Apple hardware, their licensing practices make that clear. If not to run macOS, AWS customers have no reason to demand M1 cores, and AWS has little reason to want to buy M1 chips over their own designs. And Apple and AWS are not the kind of companies to go in a deep partnership with shared designs etc over something like this.
macstadium has been doing this for a while, but it can be unstable and annoying at times. If they can be better than macstadium then it is compelling for iOS dev shops who don't want to maintain a fleet of mac mini build servers. Also amazon can use it themselves for their own CI services
The video in the article literally shows trucks and pallets of retail Mac Minis being unloaded to be installed into a data center, so I think that’s exactly what they are doing. I doubt Apple would commission custom hardware for AWS when VMWare has most likely been begging for years to no avail.
"I dont see Amazon going out and buying 50.000 Mac minis and racking them" ...
you usually don't see this kind of thing unless you work at the actual place, or you have a colo where Amazon also hosts stuff. Unless you work there, you don't actually know whether they buy that number.
In fact, I bet you they do buy over tens of thousands of Macs of all kinds every quarter, if only to satisfy the demand for hardware for engineers and for testing purposes.
Rentable Mac Mini (or Mac colo of all flavors) has been a thing for easily 15+ years. https://www.macstadium.com/ is one of the original providers if I recall correctly. I remember renting a macmini for a month when the app store on ios first came out because I couldn't afford a macbook.
AWS is largely taking other peoples efforts and putting the Amazon brand on them.
They don't yet display any reservation pricing for mac1 instances, but they do offer a "savings plan." https://aws.amazon.com/savingsplans/pricing/
If you pay for three years up front, you can pay $0.764 per hour, $6,692 per year, 29% off. I believe that's the lowest price Amazon will offer you.
For comparison, you can rent an equivalent Mac Mini from MacStadium for $139/month, $1,668/year. Or you can rent their cheapest model for $59/month, $708/year.
You can also buy the equivalent Mac Mini for $1,899.