> On 13 Feb 2018, at 18:12, Kurt H Maier <k...@sciops.net> wrote:
> On Tue, Feb 13, 2018 at 05:01:35PM +0000, Rui Carmo wrote:
>> A full build environment (the way I’m used to having it) comprises the 
>> end-to-end automation for creating a full build,
> A full build of what?  It's one command to rebuild the whole OS.  Is
> that the goal?

Yes. And to deliver an image for the Pi, built on Intel systems.

>> triggered by an external code repository 
> This pretty significantly reduces the scope of the problem, since only a
> couple of the forks use version control.  This simplifies the task
> somewhat, at least.

I struggle to understand how version control is not more actively used.

>> and (when possible) doing automated testing.
> I think this is probably the most useful part of what you describe.  Do
> you intend to write the tests?

At least the basic ones regarding whether the result boots, yes.

>> I understand that you might be used to manually bootstrap things, 
> Please don't start making assumptions.  I'm just trying to clarify what
> you're after.
>> but I tend to go for fully reproducible builds and that usually requires a 
>> minimal degree of automation. I did that for my Inferno builds for the Pi 
>> (which, alas, are now lost) and do rely on Linux tools for building, because 
>> that’s what I can host in the public cloud (which is also what I do for 
>> work).
> Plenty of us run Plan 9 on public cloud providers.  There's even been
> some success on running it with crippled providers like AWS and GCE. 
> Obviously, the task is easier when you use providers that offer full KVM
> services.  We've had virtio drivers for a while, and it makes the job
> much easier.

Well, for full disclosure, I work at Microsoft. I do have extensive AWS and GCE 
experience, and hardly find them “crippled”. It’s just that the world has moved 
on and prioritised certain kinds of hardware virtualisation.

>> Fortunately, I have access to machines with nested virtualisation, so I 
>> might be able to get Plan9 running inside QEMU inside a modern Linux kernel 
>> with fair performance - but that does not preclude the need to automate 
>> things.
> I'm still trying to understand why you'd even need nested
> virtualization.

For using QEMU’s virtualization features inside Hyper-V.


Reply via email to