From: Alyssa Ross <alyssa.ross@unikie.com>
To: Michael Raskin <7c6f434c@mail.ru>
Cc: vadim.likholetov@unikie.com, devel@spectrum-os.org
Subject: Re: Developer-friendliness
Date: Tue, 6 Dec 2022 21:14:36 +0000 [thread overview]
Message-ID: <20221206211436.d7qnzgfkaijjhcz3@x220> (raw)
In-Reply-To: <E1p2etr-008JBI-72.7c6f434c-mail-ru@smtp16.i.mail.ru>
[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]
On Tue, Dec 06, 2022 at 09:59:22PM +0100, Michael Raskin wrote:
> >> It may sound like religious point of view, but I strongly believe
> >> that developers is the number one priority to support with Spectrum OS
> >> now — as easier and friendlier the OS will be to the developer as
> >> faster it will be delivered to the common users. It, from my point of
> >> view, includes two main aspects — ease of development giving the
> >> developer proper “bricks” (well encapsulated OS services) and
> >> examples, that coveres main use cases/use patterns of the operating
> >> system.
> >
> >Yes, that's a compelling argument. I wonder if it would make sense to
> >add some special configuration option for development, that would enable
> >extra development tools and other goodies? (I often find myself adding
> >strace…)
> >
> >(I think they probably shouldn't be present by default, because then it
> >could be difficult to be sure nothing was depending on them in future
> >when it came time to remove them. But something that any given
> >developer could set once and then always have developer stuff available,
> >and toggle off when they wanted to test a production build, could make
> >things a lot nicer.)
>
> 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.
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-06 21:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-04 22:42 Firefox appVM patches and appVM refactoring Vadim Likholetov
2022-12-06 11:42 ` Alyssa Ross
2022-12-06 13:56 ` Vadim Likholetov
2022-12-06 15:18 ` Alyssa Ross
2022-12-06 15:20 ` Alyssa Ross
2022-12-06 15:57 ` Vadim Likholetov
2022-12-06 17:10 ` Alyssa Ross
2022-12-06 20:12 ` Vadim Likholetov
2022-12-06 20:25 ` Alyssa Ross
2022-12-07 7:41 ` vadik likholetov
2022-12-06 20:19 ` Vadim Likholetov
2022-12-06 20:31 ` Developer-friendliness Alyssa Ross
2022-12-07 7:46 ` Developer-friendliness vadik likholetov
2022-12-06 20:59 ` Developer-friendliness Michael Raskin
2022-12-06 21:14 ` Alyssa Ross [this message]
2022-12-06 22:05 ` Developer-friendliness Michael Raskin
2022-12-07 8:04 ` Firefox appVM patches and appVM refactoring Ville Ilvonen
2022-12-07 11:09 ` vadik likholetov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221206211436.d7qnzgfkaijjhcz3@x220 \
--to=alyssa.ross@unikie.com \
--cc=7c6f434c@mail.ru \
--cc=devel@spectrum-os.org \
--cc=vadim.likholetov@unikie.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).