Today I had a look at running LA2 on Linux.
Having had a need for Windows containers on Docker recently, I had Hyper-V setup on my Windows 10 machine. Hyper-V is a selfish feature; it doesn't permit other virtualisation technologies from co-existing on your system, such as VMWare Player or VirtualBox.
In theory, Hyper-V is as capable as either of those, so figured I'd take it for a(nother) spin (having already done so a few years back, at which point it was half-baked).
Some interesting bits I discovered whilst learning more about it was that when Hyper-V is active, Windows, the operating system currently running, is itself a virtual machine running on Hyper-V. :O How is that for inception? What happens, and the reason is requires a reboot, is effectively because without this "feature" Windows is running on bare-metal whereas with it it's booting up inside of a Hyper-V container.
I would never have suspected this, which speaks for how transparently it's been integrated with Windows. You would have thought that performance would be an issue, like it is for virtual machines running in VMWare and VirtualBox. Especially for graphics.
From what I gather, the reason it's happening is security-related. To facilitate sandboxed environment within which processes can run; potentially per user account or even per process group. They've already started demonstrating this with the Windows Sandbox feature which is quite neat. A clean copy of Windows 10 running as a virtual machine (for free, already built-in) on Windows 10. Sadly this particular feature is very half-baked, not supporting even the most basic of additional software installs, like Python. The reason? I couldn't tell for sure, but from the looks of it the .msi installed assumes a particular flavour or version of the operating system and this particular sandbox wasn't recognised.
With all of this in mind, it wouldn't have surprised me if CentOS 7 could also run as efficiently as my native operating system. That would have been fantastic.
However, as I feared, things were not that great.
- No graphics acceleration (~8 fps)
- Installation took a solid hour
- No clipboard
- No shared drives (CIFS works however, but you need to redo it on boot, or get familiar with fstab)
- No sleep (restore doesn't work..)
Bottom line, VMWare is far superior still.
With all that out of the way..
Works.
That's rather lucky, considering I hadn't actually tested this at all on Linux until now. But I have been writing it with Linux in mind. Everything from listing projects, application and packages to running applications work well.
For continuous integration throughout the years, I've turned to Travis-CI. Sadly it was Linux-only, but at some point AppVeyor came into the picture to provide Windows support. Nowadays, Travis also supports MacOS and AppVeyor also supports Linux.
Sadly, neither support all three platforms.
And then came Azure Pipeline. I would never have expected Azure to (1) even have a CI platform, (2) work alongside GitHub repositories as well as it did and (3) be better than Travis or AppVeyor. But, so far it's been really good.
- It wins over both Travis and AppVeyor by having support for all platforms
- It wins over AppVeyor for having a sensible multi-language syntax to its .yaml file (that stuff is a mess)
- It wins over both in terms of a very intuitive and well-partitioned configuration file format.
- It wins over both in the number of free concurrent runners it gets you (8!)
- It wins over both in native support for code coverage and test reports
- It wins over GitLab in that it can run CI on GitHub projects without synchronisation/mirroring.
Just look at this.
So expressive, so clear. I bet you'd understand it, even if you'd never read or written a CI script before. And that's why I think it's the better of the 4.
Weekend next, but on Monday I'll start looking into localisation with Rez.