yesterday at 4:31 PM
Amazing article. It just goes to show how many problems they are solving just to work around bugs and limitations within Apple itself. I’d wager a guess that if Apple made a new Xserve with the same performance as a Mac mini but twice the price people would still buy them, because figuring out data center operations is expensive.
yesterday at 9:27 PM
Apple still runs iCloud with Puppet managed unhardened desktop Linux distros last I heard with most devops engineers having plaintext God access to all of it from their individual engineer ssh keys.
They are one of the last companies we should be trusting with hosting infrastructure.
yesterday at 9:38 PM
Like most bold claims about security, it omits a whole swathe of controls that allow that to happen.
yesterday at 10:33 PM
Cattle-pets: smart!
today at 12:34 AM
Any server with a shell and opensshd is a pet, and has no business being near sensitive production workloads.
Add to that aging and wildly insecure ssh-based centralized ruby based infra management solution and I can only conclude everyone invovled has been asleep at the wheel on industry best practices for a over a decade.
Production servers should be immutable once deployed, remotely attestable at all times, with quorum signed secret management that trusts no single admin, with every workload in a dedicated vm with only a kernel, reaper, and target daemon, under an inaccessible offline base OS with TPM gated full disk encryption that fails closed if the system is ever modified after first boot.
And all of that is the bare -minimum-. Unfortunately negligence is industry standard since security engineers that actually know how to do system hardening are crazy rare in the bay.
today at 12:46 AM
People love to throw out these buzzwords describing their ideal “maximum security” setup suitable for “sensitive production workloads” without ever defining what the threat model is.
The most grating thing is requiring every workload to be in a dedicated VM. You are throwing so much performance away. What kind of threat model would justify this? Usually there’s no threat model analysis at all.
Banning opensshd is again mostly a fool’s errand. It’s much more productive to design a system that writes the authorized_keys file read by opensshd. For example you can design a system that requires peer approval before your own key gets written to authorized_keys.
today at 2:26 AM
Any service that has the potential to attract state actors, or attackers with access to frontier AI, MUST have a threat model that trusts no single employee or workstation.
From there the spec I described writes itself. No one can ever have the ability to mutate a system once launched.
A new server spec should be defined in a signed change, it is approved with a signed review, it is compiled deterministically from source and signed by multiple independently controlled systems which both must match, and then given multiple signatures. Then any engineer can deploy those immutable images, other engineers can remotely attest the expected PCRs from the independent signed builds. Finally secrets can be released to the machine by an HSM that validates m-of-n approval signatures.
This is table stakes zero trust deployment and again, the bare minimum.
Humans manually sshing to production machines and running commands is a 90s way of doing sysadmin that is exactly why Binance was just compromised and a thousand orgs before it. Survivors bias is not a reasonable security posture.
Also with even nested virtualization on modern hardware the perf hit is minimal, though distinct servers for each workload is fine too. At -least- sandbox each workload with something like gvisor at a minimum. Linux kernel namespaces are not enough as evidenced by endless exploits.
I practice what I preach here too. I spent the last decade building this way for high risk orgs responsible for hundreds of billions of dollars in value. I also founded https://stagex.tools and co-founded https://distrust.co and https://caution.co to make it easier for others to follow these basic tactics. Much more to come soon on this. All FOSS of course.
We need adoption on these tactics to be as wide spread as TLS if the internet is going to survive an army of AI armed skiddies.
yesterday at 11:57 PM
Citation needed. Would love to hear more about this if verifiably true
today at 12:28 AM
Apple does not brag about using Linux, and while I will not call anyone out directly because it is a great resource, resumes of current and former Apple DevOps/Security engineers describing what they worked on are quite telling.
All sorts of intel you can get about all sorts of companies that way.
today at 2:51 AM
Yeah but that’s just hearsay right? To reiterate my original point, I’m not disagreeing with you, however I’d love to see some documentation and/or hard evidence of these alleged shoddy security practices at Apple
today at 7:53 AM
What company publicly documents their shoddy security practices?
That is part of the entire problem in the industry. No standards and no accountability. Those with the purse strings only invest in security that is marketable or protects IP. Anyone that invested in proper remotely attestable provably quorum managed systems is going to be bragging about it and happy to show off the proof to earn trust from their customers. I do.
When no one is bragging about doing these things, it is because they are not doing them, and they just have a bunch of humans running around with god powers to execute any code they want on production systems or in binaries that will end up on your laptop.
To get a clue about their internal practices, lets see what they do when everyone is watching in public.
https://github.com/apple/foundationdb/commits/main/
No signed commits, no signed reviews. Merges done via browser. One Github API token away from being supply chain attacked. Also put one of those recent usernames into "forgot my password" and you can verify they do not mandate hardware 2FA. One compromised email account and you get to make a PR as a rando, then merge it with an Apple account and huzzah, you now have code in a critical repo used internally at Apple. Also releases are not signed or reproducible and are just cut by github actions. Another API key you could use to be even sneakier.
Almost any community maintained Linux distro does way better than this. Inexcusable for an org of their resources.
If this is how poorly Apple handles supply chain integrity in public, why would anyone believe they do any of this internally. I have also talked with multiple current and former Apple employees close to such things off the record but obviously will not out which ones.
today at 8:21 AM
Respectfully, I think you're missing my point here. When someone presents a claim, I hope you understand that the onus is on the claimant to provide evidence of their claim. Extraordinary claims require extraordinary evidence. I could just as easily assert that aliens from Jupiter visited me yesterday afternoon for tea but I can imagine you would like to see some evidence before wholeheartedly agreeing with me. Again, I don't think you're necessarily lying about the "plaintext god-mode access", but I am hoping you'll show us some evidence; "trust me bro" isn't good enough
today at 8:29 AM
I -did- give you clear public evidence of severe gaps in their supply chain security on at least one heavily relied on Apple software library. Same is true of all their public repos and code.
What better evidence could I possibly provide?
Also see the other commenter in this thread who identified themselves as a former Apple contractor admitting Apple uses Jenkins. -Jenkins-.
today at 8:39 AM
> plaintext God access to all of it from their individual engineer ssh keys
Scroll up, I asked for evidence of this specifically. This is a pretty damning allegation and worthy of further examination given the security implications for many, many users. Frankly, whatever they're doing in unrelated public repositories is concerning in a different context but otherwise thoroughly irrelevant to this claim above
today at 9:03 AM
Was easier to find public proof than I expected.
https://jobs.apple.com/en-us/details/200440680-3337/senior-l...
Puppet does not have quorum signing or approval support. By -design- it means one god server that ultimately trusts every ssh key of every admin to make changes to a fleet of -malleable- RedHat servers via ssh like it is 2005.
But for just one attack chain to humor you:
1. Malicious party gets access to one Apple engineer ssh key (Or literally just their email account since they sign nothing and the key could be swapped out temporarily)
2. They make a PR injecting a subtle malicious dependency to any of the core Apple component repos almost certainly used on prod servers on the Apple github.
3. They use their stolen key to merge the PR.
4. Code lands in next release and eventually lands in Apple production servers because nothing is signed so how would anyone know?
We learned nothing from xz.
yesterday at 9:30 PM
i think they run icloud on gcp dude
yesterday at 9:36 PM
“icloud” is not one single piece of infrastructure that runs in one place.
yesterday at 9:32 PM
Sure for bulk storage, but at least as of a few years ago Apple controls a lot of their own metal for the trusted backbone. I would not be shocked if they are crazy enough to manage GCP with puppet too.
today at 3:48 AM
Back when I did a consulting job for Apple Retail Software Engineering, the first part was getting a Jenkins CI/CD server up and running for the people who developed and supported the tools that were used by Apple to communicate with the employees in the stores, provide trading for them, etc….
Think of it as a predecessor to Facebook, plus whatever training platform you like. One of these guys wrote a complete software simulator for the iPod Touch-based device they were using in all the stores to handle point-of-sale transactions, so that he could include that in the training.
Content was created on macOS. Content was consumed on iPhones and iPads. The backend servers ran on Linux. It was my job to get all that compiling on the Jenkins server sitting under my desk, instead of on their laptops. I had to make minor changes to each of those code bases to get that to work.
Their build processes were quite advanced for the times. Thousands and thousands of regression tests. Thousands of UI conformance tests.
Then I had to get that Jenkins server up and running on the in-house VMware based cloud they had, where they sucked up their entire last two runs of rackmount xserve hardware and turned it around for their own internal use.
I was given a VM and remote access, and then that was that. My job was done. My contract was over, and I moved back to Austin. But that was a few years ago.
today at 8:21 AM
Jenkins. Wow. I thought Puppet was the worst of it.
Thank you for having the balls to admit this in public.
Hopefully others can stop putting Apple on a pedestal as some gold standard for high accountability and rigorous security.
yesterday at 6:02 PM
I feel like the ideal would be a 2U, 8 mac mini with dual 10Gb ethernet, shared dual power supplies, actual datacenter heatsink layout would be such a great CI platform.
yesterday at 6:05 PM
How many would they sell per year, and how would the total revenue compare to iPhone revenue?
yesterday at 6:20 PM
> how would the total revenue compare to iPhone revenue
That's not a useful watermark, most of Apple's own offerings are nowhere near the iPhone revenue level.
yesterday at 6:25 PM
Well it means why Apple doesn't care about the market lol.
yesterday at 6:43 PM
If they can sell them for higher margin than a mac mini/macbook it seems sensible enough.
yesterday at 8:37 PM
The very purpose of these hosted Mac instances is to help people not buy a Mac of their own. Any higher margins would have to compensate Apple for this cannibalisation.
yesterday at 10:35 PM
Not really. The main purpose of this is to run CI that never was going to be a personal machine anyway. This is just making it difficult for devs to have automated testing of their software on macs.
yesterday at 9:41 PM
That’s like saying Apple didn’t listen to the market when it deliberately avoided going all in on a solo AI play.
It’s not all about what you think consumers think they want. There are other more pressing factors, like ability to deliver and supply chain management which have strategic impacts in the longer term.
yesterday at 7:06 PM
How much would they save for internal serve purchases?
yesterday at 6:09 PM
I have no idea if this is true, but I would not be surprised if Apple has its own unreleased server variant based on the Mac Mini or Mac Studio platform that is deployed in data centers for specific clients.
yesterday at 9:20 PM
Apple published an article about the design of those servers in 2024. Custom hw with a custom OS.
https://security.apple.com/blog/private-cloud-compute/
today at 4:29 AM
That article has only software details, unfortunately.
yesterday at 6:42 PM
They do. They have their own custom 2U rack machines which they use for AI and private cloud stuff.
yesterday at 9:30 PM
Ok, I work for NoMac cloud hosting, and it might be interesting how we do it, in short:
A 21U rack at a datacenter (currently 2 in EU). It holds three MyElectronics 1.25U steel mounts at 2U pitch (3 Mac Minis each, rear ports, open floor for the bottom intake, 18 slots in all). 12 M5 Pro 15-core/24 GB/1 TB/10GbE NoMac Sendbox hosts at two 6-vCPU/8 GB VMs each, four M5 Pro 48 GB NoMac Simulator hosts at about 20 phones each.
Power comes from two Netio PowerPDU 8KS units (8 Ă— C13, per-outlet switching and metering over an API) on the A and B feeds. Hosts are split evenly across the two feed and connected with C14-to-C7 cords, and an APC AP4421 transfer switch feeds only the network gear. The rack peaks around 1.3 kW and averages about 0.3 kW.
The network is a MikroTik RB5009 holdin the only public IP, doing outbound NAT and inbound WireGuard only, plus a MikroTik CRS312 giving 10GbE to every Mac on a 1 Gbit/s uplink. It has three VLANs: management (PDUs, KVMs), hosts with port isolation so they can only reach the gateway, R2 and the public internet.
Every host is commissioned with FileVault off and pmset autorestartatconnect 1, autorestart 1 and sleep 0, with auto-login on the phone hosts, hostd as a LaunchDaemon, zero-touch MDM enrollmen through Mosyle, and updates deferred 90 days.
Basically that's it. Fortunatelly, we did not have supply problems, but we are also smaller.
today at 1:19 AM
Do you have any recommendations for 10G external ethernet for macs?
yesterday at 8:34 PM
It's actually rumored that Apple is working on a new server product:
https://x.com/zerohedge/status/2100211198805381524
yesterday at 8:44 PM
I also get my trustworthy news from naked men on Twitter.
yesterday at 8:52 PM
It's a screen grab of Fight club, in case you're serious
yesterday at 11:37 PM
Correction noted. I also get my trustworthy news from naked fight club actors on Twitter
today at 9:42 AM
I have reasons to believe he's only naked from the waist up..
today at 6:57 AM
Thanks for the good laugh. Rofl
yesterday at 8:48 PM
Lol that guy just reposts news posted on the Bloomberg terminal
yesterday at 8:54 PM
No, he's actually crazy, if you read his website. He was claiming that the US would be destroyed a few years ago.
yesterday at 9:04 PM
So… was he wrong?
today at 3:53 AM
The US is better than ever, so yes.
yesterday at 9:00 PM
Yea, I would hit his website every once in a while years ago but came to the same conclusion
yesterday at 9:25 PM
Anything posted on X already should be assumed low credibility by anyone, but someone willing to actually pay Elon a subscription for a blue checkmark I immediately assume is an idiot.
yesterday at 5:54 PM
they could charge 8x if they packed 4 in a rack.
today at 7:00 AM
Except that Xserve had some of the same problems. I managed 10 of them in datacenters, and tens of Mac minis in 2005-2010.
today at 11:27 AM
Yeah, for the target audience - software houses and specialist hosting providers - they really ought to be providing something more like HPe ConvergedSystem or Cisco UCS.
Sell them in units of a rack at a time with super-premium pricing. Fiddly little '4 mac minis in a 2u chassis'-type solutions are a halfway house that no-one actually wants, and are never going to provide the sort of margin that Apple expects.
yesterday at 5:26 PM
The plants have grown over the edge of the walled garden. The walls will get higher.
yesterday at 5:23 PM
Apple still lives in the world where software developed in IDE on a personal computer and shipped as a boxed software on a disquette with a licence key. Xcode cloud is a joke. All their automation is a joke. It’s not surprising even their own software development stuck because of their ecosystem because they use same tools, same cryptic software signing with their plists, p8, chains, certificates, lack of ui testing, horrible cpp, objc legacy. You just drowning in this environment. How I wish we have proper web app apis at last
yesterday at 6:18 PM
I used to drown in this stuff in the when I first did IOS dev back in 2017. I recently got back into it and was pleasantly surprised at how quickly I could setup a ci/cd pipeline. What used to take hours figuring out certs, debugging build issues, I can now even test my build against prod without even deploying.
I'm not building anything complicated, just a iPhone / watch app, but when I do get stuck with env its codex to the rescue. IMO relative to my experience many years ago its amazing.
yesterday at 9:52 PM
So is Codex the real reason it’s much easier to setup?
yesterday at 10:53 PM
Codex is definitely the reason I'm able to debug ops issues so quickly. For instance, I introduced a watch app into my iphone project. The build failed in xcode cloud but didn't give a reason. I gave codex some context and had it scan the project and it found the problem almost immediately.
yesterday at 6:36 PM
In my experience this is only partially true. Apple has come a long way and their code signing experience is leaps and bounds better than Android at this point. Their UI testing is actually pretty solid, and Swift is a wonderful language to program in. The IDE part is partially true, but to be fair they are opening things up to coding agents (they're using Claude Code themselves) so I feel like this is only going to get better from here.
yesterday at 10:43 PM
> Apple has come a long way and their code signing experience is leaps and bounds better than Android at this point
"Apple has come a long way and has made a very inconvenient and complex process only slightly less inconvenient, and people somehow are happy and pretend Android sucks."
We moved off GL/GH CI for iOS apps and switched to XCode Cloud only because of the pain that Apple is w.r.t. to signing. This is the other way, and luckily we have LLMs now: https://docs.fastlane.tools/actions/match/
Whatever we pay in runner-minutes/month is the price of our sanity so we don't have to deal with the nightmare that is their signing/release process, and their stupid CLI/XCode tools. Not to mention that even XCode Cloud seems to have been coded and shipped without any kind of second pair of eyes (QA nowhere to be found), and the XCode UI and Web UI behave in totally different ways for the same input. Of course without any kind of proper explanation for any errors, as in Apple's fashion.
today at 5:37 AM
Fastlane has existed for more than a decade; this has nothing to do with LLMs.
yesterday at 9:58 PM
Back in the early/mid 2010's when I was still a native iOS dev, I remember interviewers would ask how do you code sign an app.
And when they started trying to "automate" the process, it was a roll of the dice if it would work.
I have been out of that game for last 5 years, but I occasionally still open Xcode and it _seems_ it works most of the time.
yesterday at 11:16 PM
I understand the technical difference between signing, stapling and notarization, but c'mon man, what the hell‽
yesterday at 7:49 PM
> their code signing experience is leaps and bounds better than Android at this point.
In which universe ? You generate a signing key, its password, configure the alias, the alias password and then just modify your gradle build script to say signingConfig.set(file("file/path.jks"))
Hell, if you want to go even further, give up on signing, use the debug signing certificate and let google sign for you with their own keys.
I've stopped counting how many issues you get on trying to build iOS apps because "whoops, sorry, xcodebuild just farted and can't sign"
today at 7:43 AM
[dead]
yesterday at 6:56 PM
SwiftUI is one of the nicer UI frameworks to use imo. And fast
today at 7:43 AM
[dead]
yesterday at 6:18 PM
I assume you hit some limitations if you try to use Xcode Cloud for a larger project, but for small-scale use it’s pretty great. The setup is instant and seamless, builds are fast, and you get a bunch of minutes with your developer membership, which has been fixed at $99 for as long as I can remember.
yesterday at 5:27 PM
and what kind of world do we live in now
yesterday at 5:32 PM
Android tooling is cross-platform and easily executed in your choice of CI provider with cheap Linux ARM minutes. Simulator-based UI tests are headless (there are headless tests for iOS but not macOS). It's not even remotely a close comparison.
yesterday at 5:34 PM
That must be why everyone’s trying to release Android apps now.
yesterday at 5:38 PM
No, the apple ecosystem will always hold a monopoly over stupid upper class people to fleece. Apple will say "jump" and Developers will ask how high (if they know what's good for their wallet)
yesterday at 8:02 PM
It's going to be interesting to see how this plays out with their "no unapproved code" stance. The old excuse was that normal users don't know how to write code and so don't need to be able to run their own code.
But now normal users can have some AI thing write single-use code for them, and for relatively simple code like "show me all my pictures between these two dates that are in landscape rather than portrait" they'll usually get it right.
And now who wants a phone where you can't do anything like that?
today at 4:27 AM
You absolutely can. You just have to pay Apple their $99/yr for the privilege. I have an app I vibecoded running on my phone to do regexps against a phone copy of /usr/share/dict/words because I find the regexp practice to be more fun when faced with a word game compared to getting stumped. There's some restrictions, like no running your own JIT on user specified JavaScript, aka no making a web browser, but for most apps I dare say you won't run into the limitations trying to scratch an itch.
today at 6:11 PM
> You just have to pay Apple their $99/yr for the privilege.
Do you expect ordinary people to do this?
Also, what's the excuse for even having a "developer" distinction if ordinary users are expected to need it?
yesterday at 10:33 PM
year of the linux mobile
today at 10:00 AM
We are there with the kernel, folks tend to forget about the userspace when celebrating it.
yesterday at 5:29 PM
A world where people use Claude to operate doomed SaaS products
yesterday at 5:55 PM
Which are developed in jails, in virtual containers in other containers in virtual machines on top of hypervisor cloud system
yesterday at 9:23 PM
yesterday at 5:32 PM
>How I wish we have proper web app apis at last
You mean APIs that inconsiderate developers use to release a simple calculator in the form of a 300+MB binary that eats a quarter of my RAM?
yesterday at 9:50 PM
I’m not active in mobile development, how do the iOS and Android development practices differ?
yesterday at 5:34 PM
They might still be living in that world, but they also live in a world where they can do exactly $0 of R&D of actual rack server SKUs and still have people buying their high-end MBP SKUs at halfway-decent used car prices.
So I get why they don't care.
today at 3:09 AM
> Many of our customers build and test iOS apps. You can't build iOS apps without a Mac.
Not true.
https://cross-compilers.sjer.red
Sorry for the clearly vibe-coded website. I use this to build a few iOS/macOS apps for personal use.
It started a few years ago (pre-AI) when I pieced together a toolchain for cross-compiling C/C++/Fortran from a Linux host to macOS (used by my former employer at https://p3m.dev/client/#/).
Even signing/stapling/notarization can be done on Linux: https://github.com/indygreg/apple-platform-rs/tree/main/appl...
There's no good reason why these things can't be done on Linux, especially with AI.
today at 3:42 AM
While the article is chock full of technical details, your comment is lacking. The idea seems interesting, but what's missing is details like cross-compilation performance characteristics compared to native, challenges faced, handling xcode upgrades, taking your project for a spin against popular projects on GitHub that use MacOS runners, etc. Saying "here's some vibe-slop so Linux is good enough" just doesn't cut it.
today at 4:30 AM
You have really high standards for comments.
My intent was to inform others that you do not need Apple hardware to build software targeting Apple platforms. This is a very prevalent belief as if Apple has some “magic” that cannot run on other platforms.
I did not/have not polished this project because it works for my use cases.
Again, the original version of the project is used by my former employer who uses it in their package manager.
today at 2:33 PM
The belief is prevanlent because it used to be true for the longest time.
rcodesign only made that possible circa 2022.
And it still a bunch of hacks that are only made practical because AI can stomach retrying the glue all day until it works.
And I don't see any official Apple support in their docs so this can be broken on a whim.
Just this day there was https://news.ycombinator.com/item?id=50356944
> macOS 27 does not support CoreStorage volumes
They break things on a whim.
today at 4:41 PM
No, cross-compiling worked even before AI.
Even if code signing stops working you can still cross-compile code for macOS which eliminates the need for a CI fleet of Apple hardware
today at 1:13 AM
Just a random anecdote:
For years, "code review" in iOS meant "email your patch set to a particular email address, which would format your patch and send it to a mailing list". That list would be populated with people who could approve or disapprove it.
The server that ran that conversion was a MacBook sitting in a pretty random "server" room that included MacBooks, iMacs facing a wall, and other Mac devices used as headless servers.
Useful more than a decade ago, still useful now!
yesterday at 8:03 PM
> Under certain conditions, an external USB NIC stops working and acts as if it is not powered and shows no link. Trying another cable, another NIC, another switch port, no luck. But a quick visit to Network Preferences, deleting and recreating the “network service” in MacOS Settings brings it back to life
I too have this really annoying issue where my Mac decides a USB-C or Micro-SD peripheral is no longer readable if I am working through multiple SD cards and backing them up, not sure why. Would love to work at Apple for 2 weeks with Claude to fix it and then quit and come back home, tbh would love to just work at all sorts of companies to fix really obnoxious "never to be fixed" bugs, Discord's abysmal roles stack would be on my list as well.
yesterday at 8:04 PM
Chock full of technical details, thank you to the authors! Got a few takeaways for using my own mbp remotely.
But if you read between the lines it is fascinating what isn't said - about Apple's customer focus.
These folks have no advocate at Apple; they worked all this out on their own. At this scale with hardware from Framework or Lenovo or Dell, there'd be a 24/7 hotline with a human to reach.
With its market power Apple can ignore these people - let them suffer, as it were.
I wonder if Ternus' Apple will.. think different.
yesterday at 8:31 PM
They really don't care about developers it seems. I've literally been trying to give them money for an Apple Developer membership for over a month. Ten support emails later, I'm still stuck. I'm starting to think the only way is to buy an existing iOS development company. Plenty of similar stories in their developer forums.
today at 4:29 AM
Fun fact! You'll also need a DUNS number if you're publishing Microsoft software as well these days. Otherwise it's preemptively marked as malware! Yay!
today at 7:24 AM
Apple and Google as well (I have one). In my case, the issue is not getting the enrollment approved but literally just paying for it. It's some bug in their system and support is absolutely useless. They just keep replying the same unhelpful canned responses, probably without reading my emails at all.
today at 4:32 AM
Apple for at least 10 years
yesterday at 6:23 PM
What interests me is the miniaturization and thinness of the mainboard. Imagine if the mainboards were produced en masse and mated with a perfectly-fitting (liquid-cooled) heatspreader. That could be a very space-efficient blade server for very high density compute.
yesterday at 8:28 PM
I run a mac mini server at home and it was quite a culture shock getting that thing to do anything like linux. The password retirement at boot is a hard gate and your server will just not do anything until you unlock it. GREAT feature for desktop and laptops, not so much for a server.
today at 1:45 AM
At least they added the ability to unlock through SSH in macOS 26, so you can SSH to unlock, then use screen sharing to do the graphical login. Used to just be broken until you could physically log in.
today at 2:27 PM
Just disable FileVault? Full disk encryption on something in your house that never moves? Why? What's your risk profile that your home server needs such strong theft protection?
yesterday at 4:50 PM
This article is dated November 3rd yet I've read it months ago, it was already in my history.
today at 11:21 AM
Looks plausible. The tweet featured in the post upfront is dated 24 August.They might also blogged around that time and may have updated with new content or design yesterday.
yesterday at 5:20 PM
Hmm hundreds of laptop batteries in a datacenter doesn't seem too smart.
yesterday at 6:52 PM
With that kind of airflow and consistent temperature I would suspect the failure rates to be incredibly small on those batteries - typically what kills them is extreme temperatures and high C charge/discharge at high temperature deltas (as measured from 25'C) which is where the cells have lowest degredation, which they should see very little of in this environment.
What would be more pertinent is changing the charging logic so the packs are held at 50% state of charge vs being always charged up to 100%, that will significantly decrease the chance of pack issues while greatly increasing the longevity of the battery itself. If you hold a lithium ion cell at 50% SOC for years without varying it and keep the temperatures flat, it can last for a very long time without capacity degredation. If you leave it at 100% it will be degrade in a few short years and can swell, at which point it has twice the chemical potential to flame out. Also if it's charged to 100% when the datacenter is at 20'C ambient and datacenter cooling fails and temps go up, having the pack warm up to 40'C can overvolt it and that is usually where they swell/fail.
Also fair to note here that Apple is probably at the frontier in terms of using the highest safety cells and battery management logic so I'd feel better about this than I would putting a lesser brand's lipo pouches in datacenter environment.
yesterday at 7:40 PM
> With that kind of airflow and consistent temperature I would suspect ....
A lot of words, many of which might well be true. But it ignores the fundamental point.
I think we can safely assume its not their building, not their datacentre.
As a result, they need to play by the rules of the datacentre operator.
The datacentre operator has fire suppression systems build to a certain spec.
The datacentre has risk assessments and insurance covers to think about.
The datacentre has other customers to think about.
The datacentre has its own staff to think about.
Yes, datacentres have some of the most advanced multi-layer fire detection and suppression systems in the world.
But a fire caused by multiple racks stuffed full of LiPo batteries will likely result in very hard to control results, especially if it becomes a cascading event.
Yes, it is arguably highly unlikely to ever happen, especially with Apple hardware as you say.
However at the very least the guy should fess up and have a chat to the datacentre operator to at least give them a chance to say (preferably in writing) "ok, no problem, we'll just add it to our risk register".
Its The Right Thing To Do (TM).
yesterday at 8:57 PM
We run lithium ion UPSs in our racks and have for many years - I think you're taking the airline approach here but the reality is the environment inside a datacenter is much more stable than almost everywhere else lithium ion batteries are employed today, and the fire suppression detection and suppression systems add on top of that.
yesterday at 11:28 PM
When the MacBook is fully charged and still plugged in, it bypasses the battery and runs directly off power from the wall adapter. So those batteries are hardly doing anything.
yesterday at 4:59 PM
Title should be edited to "Putting hundreds of MacBooks in a data center (because Apple is silly)" imo
yesterday at 4:02 PM
Isnt it against the Apple EULA to sell VMs of Macos? Love the creative problem solving with the HW.
yesterday at 4:11 PM
> A well-known limitation is that Apple only allows two macOS VMs per physical Mac. It can be a Mac Pro with 24 cores and 192 GB memory, yet it is limited to running only two guest VMs. This limitation leaks into our product offering: we can only slice Mac resources in two halves. So we run instances with 6 or 12 cores on 14-core Mac Minis and 8/16-core instances on 18-core MacBooks (we reserve a couple cores for management overhead).
yesterday at 10:12 PM
yesterday at 4:07 PM
I don't know about selling, but Apple permits up to 2 virtualized Macs to run on a Mac. If they are circumventing this limit that would be an issue, but it doesn't sound like they are.
today at 2:45 AM
Yes but if you read the EULA the two VM limit it does sound like you can't really sell access to VMs:
> except as otherwise provided in writing, signed, or issued by an authorized representative of Apple, to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
In section 3 they also say that if you're renting access to a Mac you can only run one VM, which sounds kinda like that
> Except as expressly permitted in Section 3, the grant set forth in Section 2B(iii) above does not permit you to use the virtualized copies or instances of the Apple Software in connection with service bureau, time-sharing, terminal sharing, relay service or other similar types of services.
yesterday at 4:19 PM
Ah okay - and the 24 hour minimum rental time doesn't apply to VMs? Im just curious how they are getting around the limits that Mac Stadium and AWS have.
yesterday at 5:18 PM
They aren't getting around any limitations. How you decide to bill for meeting the limitations is a business decision, and you can do it via either higher average rates and allow more granular rentals to be financially covered that way or by requiring a 24 hour minimum.
I.e. just because Apple requires you to do things in 24 hour increments does not mean your billing has to expose it in exactly the same way.
yesterday at 5:58 PM
I dont think thats an correct interpretation of the EULA, they are just choosing to ignore it - https://wiki.licenseware.io/catalog/rules/apple-macos-lease-...
yesterday at 6:24 PM
If a business reserves a Mac for 24 hours (and allows no other users for that window), it complies with the EULA, no?
That doesn't mean the business has to charge the user for 24 hours. You could charge for 6 hours and then just let the Mac sit idle and unused the remaining 18.
You're eatting the cost of that unused time, but if its a differentiator that leads to more business than it might still be worth it.
EDIT: To be clear, imagine a case where the user has 24 hour sole access to the Mac. They could use up 24 hours if they wanted. But usage is tracked per hour, and they're only billed after the fact based on how much time they actually were running something during that 24 hour window.
yesterday at 10:42 PM
From the wording of the parent comment my understanding is that 24 hour period applies to the MacOS VM, not the hardware itself. Since they split each physical host into at least 2 different VMs the 24 hour period is for that VM. Even stronger case if they also lock the core affinity to the physical layout like Max editions having multiple Pro chips/dies within...
For Amazon EC2 the case is different since it doesn't allow VMs but only possible to get dedicated bare-metal hosts. Obviously Amazon could offer VMs but they would not because the current way allows them to charge 24 hours even if user uses the host only 1 hour. And obviously no body big enough challenging the status quo and impacting AWS' revenue hard enough.
yesterday at 8:49 PM
I don’t think they are doing this.
yesterday at 10:13 PM
The hack for the 24 hour thing is, of course, as a data center, to form an s-corp and hire employees to work 1 hour per week racking servers and give them a W-2 for a princely sum of just $16.90/week which works out to $878.80/year. Then as a perk of the job, those employees get to access the cluster as a perk of their employment. You can't charge an application fee since it's California, so then you sell interview prep courses for $1,000, and encourage graduates to apply.
yesterday at 6:07 PM
To be fair, it was against Microsoft's EULA to sell the OEM version of Windows to individuals who built a computer from parts.
Nobody cared.
today at 1:52 AM
GitHub Actions gets around the 24 hour rule by saying you agree to have them as a subcontractor, so you're paying them for their infrastructure and services, not for the minis themselves.
yesterday at 6:50 PM
I thought you could also only sell exclusive use e.g only one vm (or two vms to same customer)
yesterday at 5:34 PM
> Another source of pain: FileVault disk encryption. Or rather decryption.
Amazon solves this by disabling FileVault and warns against enabling it.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-...
Amazon also has much tighter integration and offers the Macs bare-metal. This has the downside that you can only gets Macs as dedicated hosts, so it's another layer to manage, and that it takes around an hour to wipe the Mac whenever you shut it down, even if you're not going to release the underlying dedicated host. Also for the last year, even grabbing a Mac dedicated hosts often runs into "None available" for hours at a time. Amazon tells you "try this other zone" but even that is no guarantee. I wasn't even able to get our TAMs to tell me whether trying other regions was likely to help. Besides that, it takes 5-10 minutes to launch a Mac, and once you acquire one, there's a 24 hour minimum billing period due to Apple licensing restrictions. Which is all to say, as a single customer, you can't really build an elastically scaled Mac CI/CD farm on top of AWS. You really need to size for your peak load. Which is expensive compared to just buying your own Macs, but $former_employer didn't want to be in the datacenter business.
FWIW, I believe MacStadium was the first to offer Macs in datacenters as a service:
https://9to5mac.com/2020/12/27/macstadium-mac-mini/
today at 7:24 AM
Funny, I have been using an old 2014 MacbookPro has my homeserver since last year. To be fair, I've installed Linux on it, replaced the battery and set it to only charge to 60% battery. With full disk encryption requiring me to unlock it at every reboot, the built-in display and keyboard comes in handy, and the battery serves as a UPS just in case. Laptops make very good servers for home use, I think.
yesterday at 5:48 PM
Yeah Apple needs to fix this by either making Xcode Cloud better, make more Mac minis (or just dedicated server hardware), or even loosening the two-VM limit. This kind of thing is bad for the average consumer and just plain wasteful.
yesterday at 6:14 PM
They literally don't care. To them, either it's 1999 and your Macs should all be on desks at your physical office that you definitely have, or, you can "just" use Xcode Cloud[1], which is definitely fully featured and surely addresses the only possible 'headless' use case.
Plus, since the desperate are willing to do crazy-looking things like this, bulk-buying $6,000 premium laptops with batteries and screens, at enormous margins, Apple is even more incentivized to keep (not) doing exactly what it's (not) doing.
[1] https://developer.apple.com/xcode-cloud/
yesterday at 6:47 PM
At least in 1999 they had proper desktops.
yesterday at 9:42 PM
At TestingBot we’ve recently deployed Mac Mini M6 instances for (automated) testing on macOS using Virtualization.Framework. Never considered Macbooks; what about the battery hazard in a rack? We also host iOS devices, after a couple of months of intense use, the batteries tend to swell up and bump up the screen of the device.
yesterday at 7:41 PM
This is quite an amazing setup and shows the current limitations of Apple supporting their enterprise customers, which end up buying MacBooks to make their products available...
yesterday at 8:58 PM
There've been many words spilled over Apple's... studied disinterest, in enterprise customers.
It's kinda hard to argue with their results, though. They handed the enterprise market to Microsoft 40 years ago, and have shown few-if-any signs of changing their mind.
yesterday at 7:45 PM
It’s kind of an interesting benefit though that you get a UPS on each machine.
Also you can pull one out and work on it with the integrated keyboard, trackpad, and screen if it has problems.
Obviously it’s super inefficient to need to do this, but there are some upsides.
yesterday at 5:22 PM
Honestly, my first thought was "does the datacentre know ?"
12 MacBooks per shelf, if we say roughly 5U per shelf (21.12/4.445 rounded up), so roughly 9 shelves per 47U rack, so 100-ish MacBooks per rack.
That's a scary density of LiPo battery.
The author complains about the lack of redundant power in Mac Minis, but there are other ways to get redundant power into one AC input.
yesterday at 6:46 PM
the issue is the internal power supply is not redundant, even if you supply it with an ATS or UPS, that component can still die taking out the entire thing.
yesterday at 7:30 PM
> the issue is the internal power supply is not redundant, even if you supply it with an ATS or UPS, that component can still die taking out the entire thing.
I mean, its basically the same thing in the MacBook, no ? The SMC ?
After all, there needs to be a magical chip inside to make sure you don't, for example, fry the laptop because it accepts charge via both USB-C and the MagSafe port.
Sure SMC failure is incredibly rare, but it doesn't mean the theoretical SPoF is not there.
Also when was the last time you had an internal PSU on a Mac fail ? Its been a very long time since I've ever seen one, and that's even thinking back to the old days with the old-school canister capacitors. Say what you like about Apple, but on the whole they do a decent job on their BOM selection.
yesterday at 6:06 PM
yesterday at 5:35 PM
"Luckily by now we found almost perfect cables that bend exactly as we want them to bend. And we bought the entire supply of them. There are zero more of them available to order on Amazon." Everyone is hoarding at any cost...
today at 2:28 PM
Unboxing with a thirst trap, count me in.
yesterday at 5:53 PM
I'm a little surprised that people would rather rent a Mac than buy one. Less so now that Apple raised the prices but for a long time a M4 Mac Mini was $599 which only works out to about 6 months at these prices.
Especially since they're not like a regular server, loud and power hungry. They're the definition of quiet and power sipping. I have one do all my background coding work when I want to keep my laptop clear (being headless helps with me moving around too).
yesterday at 6:26 PM
Some places are so cloud pilled they can't fathom it.
yesterday at 7:52 PM
If you're a fully remote company with no offices, where would you stash your purchased mac server? This alone makes renting worth it.
yesterday at 8:50 PM
Sometimes you need a Mac for just a bit.
yesterday at 5:35 PM
Author here. Happy to answer questions.
yesterday at 7:07 PM
Excellent article. Just the battle I'm fighting now in terms of virtualization.
Could you please share how you setup the host Mac? Which pmset settings, defaults, tips and tricks for it?
yesterday at 7:32 PM
Thank you!
We have all the hosts enrolled into MDM, so we have all sorts of access ready: SSH, KVM, VNC, MDM. With Macs in the DC we found having all these ways to access the machines is really essential. Things break in unexpected ways.
In terms of settings, besides the obvous (do not sleep, do not auto-update, etc), disabling USB restricted mode helps a lot (Privacy&Security > Allow accessories to connect) - no need to approve connected devices via UI.
What are you building if it's not a secret?
yesterday at 9:12 PM
MDM is essential, yes.
I'm building a EU Mac mini hosting service. Very early stage, I have just bootstrapped the company.
yesterday at 9:15 PM
... and I'm slooowly very slowly thinking of creating a "mock Docker".
Think 80% of Dockerfile syntax supported for running "docker build" against macOS guests. I do have some pieces already done here and there and basically it all comes down to actually creating a product out of a pile of various working scripts (OSS obviously). That's the hardest part.
And then comes the final boss of the game: marketing. Not sure anyone needs this at all.
yesterday at 7:45 PM
How do you partition the cores between the VMs?
With up to three tiers of cores (Super/Performance/Efficiency), how do you handle getting them split evenly to customers?
yesterday at 11:31 PM
Apple doesn't give direct control over that unfortunately. Here is an excellent article on that topic: https://eclecticlight.co/2023/10/23/how-does-macos-manage-vi...
yesterday at 8:51 PM
Virtualization does not expose this to VMs
yesterday at 6:02 PM
I remember seeing on X about someone building iOS apps on Omarchy - have you something tried similar?
today at 4:11 AM
Link for reference: https://github.com/joshuaswarren/omarchy-apple-dev
It has been used to build and and submit an app on a Linux machine, according to: https://x.com/JoshuaSWarren/status/2109068298537066710
This directly challenges the author's claim "You can't build iOS apps without a Mac."
omarchy-apple-dev is built on: https://xtool.sh which is "a cross-platform (Linux/WSL/macOS) tool that replicates Xcode functionality with open standards."
There's also: https://github.com/MarcoDotIO/Ycode - which even includes an experimental simulator.
yesterday at 6:16 PM
That stack is based on xtool at its core (xtool.io). It's very cool, but still early for steady enterprise use IMO.
Also it doesn't have iOS Simulator, so automated testing is out of question. I doubt that porting the Simulator would be feasible, since it requires macOS kernel.
Well, maybe with XNU in a VM and reimplementing parts of macOS userland. Would love to see someone try.
yesterday at 7:08 PM
Also: which solution you have chosen for the p2p deployment? I used to manage deployments on a large scale cluster and got it down from 2h to <1m using libtorrent.
yesterday at 7:19 PM
Yeah, as alluded to in the post, we have a custom p2p distribution, very inspired by BitTorrent. So you're on the right track :). We'll probably share more on that topic at some point too.
But honestly before we had that, we started with a system where nodes pulled whole images from each other (a decentralized algorithm without central coordination, but no chunking). It worked surprisingly well considering how simple the implementation was.
today at 1:22 AM
What are you using for external 10G nic? Any recommendations?
today at 1:24 AM
You already have an answer[0], and have asked this twice [1] since.. are you automated?
[0]: https://news.ycombinator.com/item?id=50360432
[1]: https://news.ycombinator.com/item?id=50360445
today at 1:50 AM
Well, I asked once, then I saw a relevant thread, then I saw the author.
yesterday at 5:58 PM
Do you think Apple will allow more than 2 VMs at some point?
yesterday at 6:11 PM
I was hopeful that they might lift the limit with a refresh of Mac Pro (it even had a rack mount version). But with Mac Pro discontinued not keeping the hopes up anymore.
yesterday at 8:52 PM
Psst…macOS images are IPSWs, not XIPs
yesterday at 11:30 PM
Doh :/. An LLM would not make such a silly mistake.
Fixing, thank you!
yesterday at 7:45 PM
Dang, I hope they sell the older laptops for cheap (less than what they were at time of purchase obviously) on Ebay once they're phased out, wouldn't mind buying a "datacenter mac" if its still viable...
I could see them flooding the used Macbook market and selling like hot cakes, but also giving them back "rack" space.
today at 1:32 AM
A full OS for all agents' workload could be overkill. for things like monitoring, research, or transforming data, a WASM sandbox is often enough.
yesterday at 9:43 PM
I recently setup my home lab in a way that kind of replicates their end goals and it wasn't hard:
1. Beefy M6 Mini as the server. UTM managed MacOS VMs with screen sharing enabled. 1 VM per project. Set the Mini and VMs to never go to sleep. 2. Secondary Macbook Air -- I screenshare into the VM for the project I want to work on and do work from there. I can close the laptop at any time and not worry about agents stopping. 3. With Tailscale on all machines I can work from anywhere.
yesterday at 7:35 PM
It is mind blowing to me that a 1 trillion dollar company don’t have a way to support large customers with enterprise servers. Fun fact: they used to have.
yesterday at 5:05 PM
Man, kudos to the person or AI who designed their website. Easy to read, easy to find any information, with eye catching branding.
yesterday at 9:05 PM
Try now stacking ten iphones, or as many as you want. The world definitely will get more interesting in the very near future
Yesterday I saw AI in a pendrive, which got me wondering if small set-top boxes isolated from the web, connected to TVs or your local WiFi will be the norm of tomorrow
today at 3:27 AM
On a related note, has anyone modified a Mac Studio to run directly from DC power? I'd like to use one in a battery-powered system without an inverter.
yesterday at 4:24 PM
The cost of cloud Mac hardware is quite frankly ludicrous across the board. Namespace's minimum for an M6 is, what, $0.06/minute for 6 vCPU? And that's on the cheap end - Semaphore wants $0.09/minute for 4 vCPU and GitHub Actions wants $0.062/minute for M1 hardware (forget AWS pricing even which is even more atrocious).
If I run just a UI test suite for an hour, that's $3.60/run, which is now higher than what I'm paying for AI inference that made the change that triggered the run. That's crazy! If I ran even just one run per night that would run me more than $100/month. A Mac Mini is $900 - I break even in nine months by buying the hardware outright. If I run multiple UI test suites per day, I break even much faster. These ARM chips are so power-light that the cost of electricity is practically irrelevant, and after all, these aren't rack-mounted monstrosities with 90 dB fans - they're meant to cool themselves sitting on your desk. Maybe it's different if you need like 60 of them?
Is anyone even running the numbers before they sign up? Or are companies really running that many Minis and are paying the premium to outsource the DCOps?
yesterday at 5:42 PM
> A Mac Mini is $900 - I break even in nine months by buying the hardware outright.
When you take resale value into account, purchase makes even more sense than renting.
Used M1 Mac Minis from 2020 are currently selling for about $500 when they originally retailed for $699.
yesterday at 4:51 PM
> A Mac Mini is $900 - I break even in nine months by buying the hardware outright.
The clue to their decision may be right there, potentially going for an increase in sales.
But nowadays it seems they suffer from a lack of vision and drive; perhaps (hopefully) they’ll come around.
yesterday at 5:51 PM
yesterday at 5:01 PM
I have a test suite that needs to run on a Mac in a project that merges < 20 PRs a year. No point in provisioning our own Mac and maintaining it for that.
yesterday at 9:34 PM
Yep. I run a local CI cluster of Macs made up of old laptops, so the effective cost is "zero" (resale would be annoying and I probably wouldn't bother). It's pretty easy. No way am I paying those kinds of rates for cloud Macs.
yesterday at 5:41 PM
I looked at our GitHub Actions monthly expenses, then at the price of a M4 Mac mini (just when they were released, and still cheap), and decided to buy one as it would pay for itself in less than a year. There are definitely still cases when buying hardware still makes sense, over renting in the cloud.
yesterday at 5:47 PM
the problem of buying machine is that it doesn't scale. you have to buy another one if the test gets heavier.
yesterday at 6:41 PM
Mac Minis are small and power efficient. Scaling questions are always a question of degree. Several Mac Minis, Ethernet cabling, a KVM switch, maybe a simple MDM to make your life a little easier, scales just fine.
yesterday at 7:43 PM
NoMac is just $0.015/min or $0.90/h, it is the cheapest one.
yesterday at 7:35 PM
Farming Apples :D
yesterday at 7:54 PM
Disappointed they didn't call this configuration the orchard at any point.
yesterday at 6:45 PM
Perfect illustration of plan vs reality in terms of complexity divergence.
yesterday at 4:25 PM
> You can't build iOS apps without a Mac.
I'm not sure this is true anymore.
yesterday at 4:43 PM
xtool [0] came up on here a while ago [1]. I think it still requires you get a big xcode app bundle off a macos machine and drop that into xtool, since there's no other way to get the iOS library header files from Apple. The other parts of xcode just aren't used as far as I know. Other than that caveat, you're running builds in xtool's own environment on whatever platform you choose. You can even do code signing.
[0] https://xtool.sh
[1] https://news.ycombinator.com/item?id=44011515
yesterday at 5:26 PM
Technically you can, legally not sure
yesterday at 4:36 PM
It is.
yesterday at 4:38 PM
You can build iOS apps on Omarchy now
yesterday at 5:25 PM
Omarchy is even less production ready than racking up laptops.
yesterday at 5:30 PM
Plus there's the issue that DHH is a racist twat.
yesterday at 5:38 PM
That's one of the reasons to keep it as far as possible from anywhere you need trust (like prod): software, like soylent green, is made of people. And you can't trust people like him.
yesterday at 11:26 PM
Omarchy, for what it is, is just a toy project from DHH. As much as I acknowledge the guy's talent, it is not viable for any production grade build
yesterday at 9:27 PM
I really need to leverage my JetKVM’s. Now it’s too expensive to deploy AI machines with them. I could have my own personal AI utopia.
today at 1:18 AM
I wonder which 10G external nic do they use? And any recommendations for 10G specifically?
today at 1:20 AM
These made the rounds recently: https://www.jeffgeerling.com/blog/2026/new-10-gbe-usb-adapte...
today at 1:49 AM
Thank you, noted.
yesterday at 5:46 PM
> You can't build iOS apps without a Mac.
I'm hoping AI will change that soon.
yesterday at 5:51 PM
You can already do this, but the Apple’s EULA forbids Mac OS running (virtually or otherwise) on non-Apple hardware.
yesterday at 7:02 PM
It's MY operating system after I bought it.
yesterday at 5:54 PM
So what? The EULA can say whatever it wants.
yesterday at 9:10 PM
As an individual developer I would totally violate that part of the EULA, but if I'm selling OSX computer like OP, you're exposing yourself to much greater legal risk.
yesterday at 5:50 PM
Today you can run macOS and current Xcode in kvm/qemu on any modern amd64 server. Next macOS will be arm only and likely DRM’d up the wazoo.
https://github.com/kholia/OSX-KVM
yesterday at 5:49 PM
I could see Mac minis being used for data center type setups. But MacBooks are distinctly consumer devices. I know your company is trying to solve a niche. But if it stops becoming a niche, consumers will be impacted because of operations like yours.
yesterday at 5:51 PM
The incentives of the current system are not set up as such for this company to care about potential negative externalities of their actions.
yesterday at 5:52 PM
The article addresses that. In the very beginning.
> But still, why laptops? Isn’t it a major waste of screen pixels and keyboard buttons and battery ions? Well yes, Mac Mini would be a better choice for a datacenter. Sure, it has very rudimentary remote management, no redundant power, and a beautiful case that ensures that cooling will be difficult regardless of which side you lay it on. But these are all known challenges that we have learned to manage.
> But have you actually tried to order a couple hundred Minis? We have. Ordered in January, delivered in July. Welcome to the world of 2026 when the supply chains are in disarray. Never mind that Apple doesn’t release updated CPU models to all devices at once. So Mac Mini didn’t get M5 cores for 10 months (and then suddenly got M6 before any other device model!). We promise the best and the newest to our customers so we had to be inventive. That’s how the MacBook-in-Datacenter project was born.
yesterday at 7:09 PM
Above all else, looking at a "Mac rack" is, at least for me, a truly F**ing awesome aesthetic and technological experience.
yesterday at 4:36 PM
I really wonder if Apple's logic to require a sale of a unit for 2 VMs is fiscally correct. Seems like it would be better to open it up to virtualization such that more devs can make iOS and macOS apps. Is the community of devs being forced to buy mac hw just do dev a iOS/macOs app so large that its worth putting us through all this HASSLE? Maybe they are worried about clone machine/farms that will eat into their sales. Idk. Because they are so VM unfriendly, I refuse to deal with Apple's bs.
yesterday at 5:01 PM
> Is the community of devs being forced to buy mac hw just do dev a iOS/macOs app so large
Yes.
Why else would you buy such an expensive machine with such a crappy operating system?
yesterday at 5:13 PM
It's Unix and it can run any pro creative app you like.
yesterday at 6:20 PM
> It's Unix
Not so much these days.[0]
[0] https://news.ycombinator.com/item?id=50031653
yesterday at 6:51 PM
Because the target market (mobile) is very profitable, if you have the skill, I also don’t understand that stance because Mac powerbooks, Mac minis, Mac studios last a long time and have high resale value if you decide to move on, particularly if you are a smaller development company.
yesterday at 5:04 PM
Not crappy. Skill issue.
yesterday at 8:10 PM
yesterday at 4:52 PM
I am lost, doing it in a Hackintosh is feasible but against EULA terms? I remember having a Hackintosh around the office two years ago (yes, it was x64 based). BTW I just found "ARM is not a universal architecture, there will be no more Hackintosh" [1].
[1] https://www.reddit.com/r/hackintosh/comments/1uboij0/arm_is_...
today at 2:16 AM
"We are close to an ARMintosh!"
https://old.reddit.com/r/hackintosh/comments/1x8j5h1/we_are_...
"A second ARM-based hackintosh has been confirmed, this time on an RK3588 board!"
https://old.reddit.com/r/hackintosh/comments/1xhtefq/a_secon...
yesterday at 4:30 PM
The registry distribution subject "for another blog post" is the most interesting part of this to me. I'm very interested in the efficiency/locality metrics that went into designing that. I look forward to that future post.
yesterday at 9:22 PM
iOS simulator is just software. Reverse engineering it to run on Linux seems pretty viable these days and likely cheaper?
yesterday at 7:53 PM
Scaleway seem to have a better solution https://www.scaleway.com/en/blog/how-we-turn-apples-mac-mini...
Uptime.lab (see Insta) deshells M2sand runs them bare a bit like GitHub does
yesterday at 7:45 PM
> The most unreliable cable? HDMI! Often thick and inflexible. Tends to fall out every time you touch the shelf.
For real. Also disconnects if you wave a palm hair in its general direction. So much worse than screw-in DVI, mechanical design wise.
yesterday at 6:45 PM
Why HDMI cables instead of a HDMI dummy plug with screen sharing enabled?
yesterday at 6:58 PM
They mentioned have to deal with FileVault at boot.
yesterday at 7:23 PM
Apple bros, why don’t you just make servers? People would go nuts for a 1TB RAM Mac server. You’re a hardware company! Why are you throwing away one of the biggest hardware markets!?!?!
yesterday at 9:10 PM
'cuz they can't source enough fab time for their existing products - so further expanding their market doesn't do anything to expand their revenue.
Though to be fair, they more-or-less ignored enterprise even when we weren't in a fab-constrained environment.
yesterday at 7:44 PM
Apple decided they don't care about neither servers, nor workstations markets.
today at 12:56 AM
> But have you actually tried to order a couple hundred Minis? We have. Ordered in January, delivered in July. Welcome to the world of 2026 when the supply chains are in disarray.
I hope you guys are the only ones employing this strategy otherwise you're just contributing to the same problem mac minis have.
yesterday at 5:19 PM
[dead]
yesterday at 7:23 PM
[dead]
yesterday at 4:19 PM
Wild to see them using MacBook Pros and not Mac Mini/Studio. Curious how that possible makes sense for economics and cooling.
yesterday at 4:38 PM
They answer that in literally the first paragraph in the article.
TL:DR; They couldn't buy enough minis or studios.
yesterday at 7:06 PM
The Mac Mini’s and Mac Studio’s are very popular fast, quick, and easy to move around. With very good resale value private party or back to Apple.
yesterday at 5:32 PM
it's "literally" the 5th paragraph, but yeah, it's there.
yesterday at 6:30 PM
yesterday at 5:25 PM
[dead]
yesterday at 5:38 PM
tbh, I skipped to the part about Virtualization.framework and skipped the part that started "Chances are you’ve seen me on X: "
yesterday at 8:43 PM
[dead]
yesterday at 5:18 PM
So they buy up the machines, likely create supply issues (add waiting time etc.), then rent them out at premium?
People are outraged landlords doing that with housing.
Yet someone such rent seeking behaviour is acceptable?
Get fucked.
yesterday at 7:17 PM
Many people/companies are willing renters today even when the resale value is very good with Mac’s in comparison to PCs. Never have trouble selling on decently equipped Mac computers. The PCs, aside from the graphics card, end up in a scrap heap. (computer graveyard).
yesterday at 10:22 PM
"willing" renters, because corporations are buying up the supply.