Computers for cross-platform development

[Lucas Holt]

You could also use something like bhyve on FreeBSD or even vmware esxi.  I’ve setup esxi on an old intel core i7 box here for package builds for MidnightBSD and it’s worked out quite nice.  It’s also free.  



> On May 25, 2019, at 4:28 AM, Lassi Kortela <lassi at lassi.io> wrote:
> 
>>> Get a single large machine and virtualize each one of the
> 
>> I double the sentiment for virtualization
> 
> Tripled :) Spending the same amount of money on a fast/spacious amd64 system will probably give you more development speed and convenience and maybe even more stability than buying exotic hardware. (Unless you specifically love owning exotic hardware as a hobby in its own right.)
> 
> I run all of the following on VirtualBox on an Intel Mac:
> 
> * DragonFly
> * FreeBSD
> * OpenBSD
> * NetBSD
> * Solaris (OmniOS)
> * Debian Linux
> * Alpine Linux
> * Haiku (BeOS clone)
> 
> Everything is very fast and convenient and surprisingly easy to set up nowadays. VirtualBox doesn't have as good a reputation as VMWare in the stability department but I've had very few crashes; it's perfectly usable for ordinary programming. It can use grow-on-demand virtual disks so if you make a 10 GiB disk it doesn't instantly use up 10 GiB of real space. Probably all virtualizers can do that nowadays.
> 
> For non-x86 platforms, QEmu on Linux may be your only reasonable option (I've successfully run Linux on VirtualBox and then QEmu inside the virtualized Linux box). QEmu is generally less stable than VirtualBox but the range of virtualized hardware is amazing. This would be the first approach I'd try to cover big-endian systems.
> 
> VirtualBox and QEmu can do TCP port forwarding, so you can make an extremely nice setup to ssh into your boxes by putting things like this in your ~/.ssh/config file:
> 
>    Host dragonfly
>      HostName localhost
>      Port 9001
> 
>    Host freebsd
>      HostName localhost
>      Port 9002
> 
>    Host alpine
>      HostName localhost
>      Port 9003
> 
> Then whenever you need to test things on a particular VM, just start it up, wait 30 seconds, and `ssh dragonfly` from your shell. All the usual things like scp/sftp, tmux and git pulls from the network run fine. Emacs will even let you remote-edit files inside VMs from your main editor session via ssh (Vim probably has something similar). ssh-copy-id your key into the VM for passwordless logins, install your favorite software and clone all your dotfiles, and you have an almost seamless cross-platforms development experience.
> 
> VirtualBox can also easily juggle like 5 different VMs at once if you have the RAM. Set up ssh port forwarding so each VM exposes a different port to your native OS, and you can have tmux and editor files open on all of them at once. Really great for cross-checking things quickly.
> 
> With not-all-that-much practice it's basically as easy as developing on a single platform. Except the portability concerns will make you write better software by avoiding over-complicated approaches and sticking to data structure / OS fundamentals ;) And it helps add inspiration and relieve some of the boredom of development when you visit different OSes regularly.
> 
>> As Justin mentioned, the frequency of the runs adjusts the value of VM vs physical.
> 
> With a reasonably beefy Intel machine (which will likely be more reliable and not more expensive than having separate computers), you can run a whole lot of things before a separate physical machine becomes easier/faster. Not sure is this applies to really CPU/RAM heavy workloads (if you can stomach closed-source software I'd evaluate VMWare for those).
> 
>> I don’t know if Travis CI supports every OS on your list, but it might and you could set up a testing framework with it.
> 
> When I started out I used to think that cross-platform CI is enough. But it turns out it's painfully slow to check your work using only a CI server since you have to push a new commit to try the simplest of things. I wish Travis provided an ordinary login shell running the same environment as their CI, would have already saved hours of my time. This is true in general, and doubly true for unfamiliar environments (different OSes than what you are used to). I gradually found out that instant ssh access from my main text editor and terminal is mandatory for programming sanity. The more slow/complex/annoying it is to access the boxes the less often you check stuff. I can't speak highly enough of the SSH-into-VirtualBox setup for getting real work done.
> 
> Nevertheless CI is great! Travis only has Linux/MacOS/Windows natively. Somebody managed to run FreeBSD in a Travis job by installing QEmu, downloading a BSD image, virtualizing BSD inside Travis's virtualized Linux and then making Travis ssh into the BSD to run the actual build script. Here are the gory details: <http://erouault.blogspot.com/2016/09/running-freebsd-in-travis-ci.html>. Genius or madness?
> 
> Cirrus CI apparently has native FreeBSD: <https://forums.freebsd.org/threads/cirrus-ci-free-freebsd-ci-testing-for-open-source-projects.68560/>.
> 
> SourceHut too but I can't find the details now: <https://meta.sr.ht/>.
> 
> Not sure if any CI services offer other BSDs but it seems to be a fast-moving field so there is hope.
> 
> Another possibility would be to rent some virtual servers running different operating systems as a group and pool money for the running bills. Vultr.com has a very good reputation and offers cheap servers with ready-made installations of many popular systems (including BSDs). They also have custom ISO image support.