Re: Developer-friendliness

Michael Raskin
2022-12-06T21:56:36Z

>> Well, one could have VM generator functions, so that you can easily
>> generate a development-like VM or a reasonable-setup like VM or minimal
>> VM (without D-Bus etc.), and so the developers can just use the dev
>> version and always get the good stuff included?
>
>Yes, that's true.
>
>Just as a quick refresher, currently if you want to make a Spectrum VM,
>these are your options:
>
> - Lay out the VM configuration directory manually in the user data
> partition, and bring your own kernel/rootfs.
>
> - As above, but use the rootfs and kernel in /usr/img/appvm. These aim
> to provide a "standard" environment that can be shared between
> application VMs, so it comes with mesa, and in future virtio-gpu set
> up, as well as D-Bus, PipeWire, etc. It mounts a second block device
> that contains your application, as well as any dependencies not
> included in the base image, and then runs your application from
> there. This way, big stuff like mesa only has to exist once on disk.
>
> - Create an application VM that uses /usr/img/appvm with Nix, using
> vm-lib/make-vm.nix.

Yes, sorry, I have still not tried all this (I am going to avoid Wayland
as the main UI as long as practical, and I am not going to commit enough
time to Spectrum-adjacent things to make it worth your time to ask how
would I set up things for Spectrum-like isolation of single things into
Weston-inside-Xorg or whatever on host).

>So what we're missing is a way to create, with Nix, a VM that isn't
>based on the /usr/img/appvm "template". The reason we don't currently
>have such a function is that I don't think it's clear yet how it should
>work — what should be customisable, what should be part of the base
>image vs. not, etc.? For a while, how make-vm.nix should work was
>similarly unclear, which is why it only recently came into existence.
>After I'd manually created my third or so application VM, it became
>clear what could be part of the base image, and what had to be
>customisable. Currently, we only have one VM in the tree that doesn't
>use the /usr/img/appvm template, netvm. Once we have more, I think
>it'll be easier to evaluate how a more minimal VM builder function
>should work.

Hm, I would say that I have a good experience solving such a problem
with a Nixpkgs-overlay-like structure, i.e. a makeExtensible with all
possible tunables defined as attributes, and then more complex data
structures built out of them, as well as packages for the things.