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).