A world without the Mac Pro

Not that I know of. I mostly pieced the process together from disparate sources. Let me try to give you a brain-dump:

First, a point of note: one funny thing is that the VSphere ecosystem assumes, is that the ops people deploying VSphere use Windows. So the tooling around VSphere—even the unofficial community tooling—are Windows programs.

Besides the server computer I was setting up, I only have a MBP (with no Boot Camp partition), so, "step zero": I installed VMWare Fusion, and downloaded a Windows evaluation guest image from Microsoft.

The rest of this assumes you have Windows:

1. Install http://www.v-front.de/p/esxi-customizer-ps.html, and use it to generate an ESXi ISO customized for your machine. (Add network-card and storage drivers, essentially.)

The generated ISO doesn't "burn" onto a USB correctly using regular tools for some reason. The recommended Windows tool is called Rufus. I couldn't use that from a VM without a lot of hassle, but it turns out the ISO is essentially an ISO9660 export of what was a FAT filesystem, including UEFI boot files. So:

2. Extract the ISO onto a FAT-formatted USB stick. Plug it into the new machine, and pick the UEFI file in your BIOS boot manager. The installation proceeds a lot like an ncurses Linux install (e.g. Ubuntu Server.)

3. Once the machine is running, it shows a URL you can reach its web client interface at. For managing the hypervisor, this is mostly fine. (You can also enable SSH from this web console, and then SSH into the hypervisor.) For setting up new VMs, however, I found the [free] VSphere Client (https://kb.vmware.com/selfservice/microsites/search.do?langu...) a lot more powerful. Install that if you like. Again, though, it's Windows-only.

4. Create a macOS VM in VMWare Fusion. (It assists you in doing this; it just requires that you have a recovery partition on your Mac.)

5. Find the menu option in VMWare Fusion to "Connect to an ESXi server"; specify the IP the server console provides, and the admin user/password you provided during installation.

6. Go to the VM library window, right-click the macOS VM, and one of the options should be "Upload to an ESXi server". You can then pick one of your connected servers.

---

One thing VMWare wants you to do, that you shouldn't do (for a home lab, at least), is to install their Platform Management Controller, "VSphere VCenter." (You might be tempted, because that's the only way to get their modern [horribly-janky] web-app interface that exposes all the VM configuration options like the Windows client does.) The VCenter VM appliance is ridiculously bulky: it takes ~16GB of RAM and two dedicated vCPUs just to run it. It's designed to consume one whole ESXi host node of a VSphere cluster, not to assist in the maintenance of a single-node ESXi setup.

Sure, but the Windows APIs that I mentioned aren't historical. Those are all currently supported APIs. Carbon/Cocoa was the last time that OS X has had a dual-API situation but even then, Carbon was always referred to as the transitional library and Cocoa was always referred to as what you should use for new code.

While Apple floundered during the 90s with their OS strategy, their API strategy in OS X has been absolutely rock solid.

It's now 2016, Carbon has come and gone as it was intended to and Cocoa is still around and is still the API you use for working with the Mac. If you're trying to do something on the Mac, there's going to be a single officially supported way to do it and that's it (if it's supported at all).

Meanwhile, there are three totally different frameworks on Windows that you can use to do the same thing, all of which are officially supported and none of which are deprecated.

They were afraid that x86 hardware would eclipse SPARC hardware, so development of Solaris x86 lagged behind "real" Solaris, and the HCL was always very small. They wanted to sell you expensive hardware, not a software license.

What actually happened was that x86 hardware eclipsed SPARC hardware... And organisations that would have been happy to refresh the hardware and keep the same OS and just recompile their apps found that they couldn't, so they jumped to Linux instead... And the rest, along with Sun itself, is history. I was working for a big Sun customer during this transition, we begged them to make Solaris x86 a first-class citizen, and we had a lot of support within Sun too but the SPARC Mafia won the day and with regret, our next big order was (IIRC) with Dell and SUSE...

Out of three daily desktop drivers, one is an XPS 13, one an old repurposed T3500 xeon, and one a Mac Pro 2011 tower. Arch runs faster and smoother on that Mac Pro than OS X.

I only really miss Adobe, but I was a heavy user of it. VMs/Wine aren't the same.

> Even Pixar has a Linux desktop fleet.

And those machines are terrible. Teradici thin clients streaming Red Hat from a closet somewhere. The latency on those things was significant, and the fonts unreadable. The hardware was really buggy, the monitors were really low resolution, and there was some irony on typing on a broken Dell keyboard in the Steve Jobs building. The crappyness of having to sit in front of those machines for 10 hours a day was a significant part of my decision when I left Pixar.