general high-level discussion about spectrum
 help / color / mirror / Atom feed
From: Alyssa Ross <hi@alyssa.is>
To: discuss@spectrum-os.org
Cc: Ville Ilvonen <ville.ilvonen@unikie.com>
Subject: Reportback from MCH 2022
Date: Tue, 9 Aug 2022 10:38:45 +0000	[thread overview]
Message-ID: <20220809103845.nwbn3or2jyc7rfzg@eve> (raw)

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

I was recently at MCH 2022[1], one of the big European hacker camps.  We
had some really good conversations about Spectrum, and I thought I'd
share my takeaways here:

1. We were praised for our recent documentation efforts, both in
   implementing Diátaxis[2] and Architecture Decision Records[3].
   So big thanks to Ville for spearheading the latter.

2. We talked about the use case of having multiple user data partitions.
   This would allow very strict separation of security domains, and
   could also be helpful for data portability — you could have one user
   data partition in your desktop, and another on a portable disk, for
   example.  And if, way down the line, we want to do really cool things
   like have live migration of VMs between systems, architecting for
   multiple user data partitions will be a big help with that too.

   This is one of those things where it's not difficult to do, as long
   as we plan for doing it that way from the start.  But if we didn't do
   it that way from the start, and decided we wanted to add it later, I
   can see how we'd be in for a world of pain.  So I think it's a
   sensible change to make.  We're unlikely to regret making it, but
   reasonably likely to regret not having done it earlier if it becomes
   really important later on.

3. Something that can apparently be difficult for Qubes is having every
   VM have a unique, human-readable name in a global namespace.  This
   means that, for example, disposable VMs have to try to generate a
   name that isn't already in use.  This is especially relevant if we
   end up supporting multiple sources of VMs as described above.

   So in the short term, we should probably change VMs to be identified
   with UUIDs, and have human-readable names be a layer on top.  Not
   having a human-readable unique names in a single global namespace
   will help with thinking about VMs in terms of capabilities.

Since points 2 and 3 are architectural changes, I'll write them up and
submit them as proper ADRs when I get the chance.

[1]: https://mch2022.org/
[2]: https://diataxis.fr/
[3]: https://spectrum-os.org/doc/decisions/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

                 reply	other threads:[~2022-08-09 10:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220809103845.nwbn3or2jyc7rfzg@eve \
    --to=hi@alyssa.is \
    --cc=discuss@spectrum-os.org \
    --cc=ville.ilvonen@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.
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).