<MichaelRaskin>
Hmm. BTW the cost-benefit of configure Wayfire just right starts critically depending on the system design
<qyliss>
Does it?
<MichaelRaskin>
Well, there are different directions
<qyliss>
fwiw, I'm not trying to configure it just right, but to get it to work at all
<MichaelRaskin>
That's what you said about virtio_wl in the beginning
<MichaelRaskin>
But basically, it's the question of granularity.
<MichaelRaskin>
Qubes seems to use window border colours in a system where 16 classical colours are enough to distinguish all VMs
<MichaelRaskin>
And the border between a bug and a feature might be thin: one could say that VNC is bad because it forces each VM into its own rectangle, but maybe with minimal integration it is actually more transparent to give each VM a few rectangle windows presented as monitors to the inside? With VM-run window management inside them.
<qyliss>
if you want that you can have it today with qemu or virtualbox
<qyliss>
what spectrum presents has to at least be an improvement over that, or there's no reason for it to be taken seriously
<MichaelRaskin>
Qemu has targeted a different set of priorities for too long to be trustable for isolation (although the same applies to wl_roots).
<MichaelRaskin>
I would say that something that manages connecting to multi-monitor Qemu VMs well is a very useful tool…
<Shell>
I'm fairly sure you can point qyliss's CrosVM at a virtual display right now and get what you want, no need for Spectrum.
<MichaelRaskin>
So far the work on Spectrum seems to be focused on «let's have opaque-to-host networking between VMs under a VMM written with _some_ attempt at security throughout»
<MichaelRaskin>
Runtime-resizable multiple monitors for CrosVM actually doesn't sound like something that obviously exists today
<qyliss>
I don't believe monitors for crosvm exist at all
<Shell>
the goal of Spectrum is, as it was explained to me, largely around building a secure operating system which is significantly more useable than Qubes/Linux-on-Genode/etc, it just so happens that there's a lot of technical work to get to the point that that can be built.
<Shell>
if the eventual UX looks pretty much exactly like Linux-VMs-on-Genode as they are today, there's no point continuing.
<ehmry>
Shell: the benefit is nix, spectrum systems can be build in a deterministic manner
<MichaelRaskin>
Well, the limitation of Qubes is management of the VMs restricting effective granularity
<MichaelRaskin>
And the driver restrictions
<Shell>
ehmry: sure, but the solution there would be to make Genode configurations buildable with Nix if that was main the concern. I seem to recall you having dabbled in that in the past.
<ehmry>
Shell: yes, I'm working on that right now, but slowly
<Shell>
MichaelRaskin: the limitation of Qubes is that it's miserable to use, imo.
<ehmry>
Shell: also, it makes sense to build the hypervisor and the guest as parts of a single coherent build, which is something that neither or qubes or genode do
<ehmry>
so the right holes between worlds are poked at the right places
* Shell
nods.
<MichaelRaskin>
Build-time hole-poking? That sounds like a way to ensure you inherit all the pains of Qubes
<Shell>
the bit that changes that is Nix; building stuff and configuring your OS are exactly the same thing.
<MichaelRaskin>
OK, all but one
<ehmry>
MichaelRaskin: I mean getting compatible software on both sides, guest integrations and so on
<MichaelRaskin>
Yeah, sure, integrations package would be prebuilt at the same time as host. Once, not even once per VM
<MichaelRaskin>
Because VM number is unknown at the build time anyway.
<MichaelRaskin>
But I am not sure, if the granularity is like firejail and not like Qubes, then having the container windows per each VM could be much less of a limitation than in the Qubes model.
* ehmry
has installed qubes, once, but not used it
<MichaelRaskin>
Of course in the firejail model there are just too many windows to distinguish them by window border colours…
<qyliss>
Qubes also prepends a domain identifier to each window title
<qyliss>
Color isn't enough even with Qubes
<qyliss>
But it's still useful
<qyliss>
For distinguishing things at a glance
<Shell>
I do not see my community regularly using an operating system which does horrible UX things like windows-in-windows on a day to day basis, and they're pretty much the target market for Spectrum.
<MichaelRaskin>
Domain identifier is useful indeed
<qyliss>
If you're running 100 vms at once there's going to be no scheme that can meaningfully help you keep track of all of them
<qyliss>
because that's just fundamentally too many things to keep in your head
<MichaelRaskin>
Indeed, so we need to keep track of some hierarchical categorisation
<qyliss>
Interesting concept
<MichaelRaskin>
Like «this is a throwaway Firefox window»
<Shell>
qyliss: assuming you're not actually interacting with all of them at once, named workspaces help a lot I think?
<qyliss>
MichaelRaskin: the qubes distinction between disposable and non-disposable VMs is quite nice I think
<qyliss>
very easy to understand
<qyliss>
Shell: good point
<qyliss>
I don't remember ever using named workspaces in Qubes.
<qyliss>
It might have supported them, but if I didn't know about it it might as well not have :P
<Shell>
but also
<MichaelRaskin>
I am not sure disposable/non-disposable will map _that_ well to Spectrum
<qyliss>
Perhaps not
<Shell>
100 applications open at a time is not the normal use case for most people, lol
<qyliss>
Indeed
<qyliss>
And good luck finding a computer that can handle it tbh
<Shell>
qyliss: my girlfriend's laptop probably could, it's beefy af
<qyliss>
I doubt even power users have more than 20-30 open windows at a time
<MichaelRaskin>
«Open window» is such a nebulous concept
<qyliss>
20-30 colours are distinguishable by most people I reckon, especially if well chosen so similar VMs are coloured most differently
<MichaelRaskin>
Well-chosen means choosing for all defined VMs, not for all simultaneously open VMs
<qyliss>
I'd also like to investigate using textured patterns, since not everybody can distinguish colours
<MichaelRaskin>
Counted my screen sessions… >50
<qyliss>
I suspect you are an outlier
<qyliss>
How would you like to distinguish between your 50 different VMs?
<MichaelRaskin>
But they are hierarchically organised, and I guess ~35 of them would be counted as _tabs_ in a chat client for a different setup
<qyliss>
I see
<qyliss>
You could name then hierarchically and use the title bars
<MichaelRaskin>
In a sense, I do not need extra help for distinguishing some of VMs
<MichaelRaskin>
If I cannot distinguish a Firefox window from a terminal session, I need… something different from better window decorations
<MichaelRaskin>
Maybe eight hours of sleep?
<qyliss>
I'm assuming you have more than one firefox session
<qyliss>
I could also presumably exploit your firefox and make it look like a terminal
<MichaelRaskin>
You would probably exploit a throwaway Firefox session (throwaway should be marked, sure)
<MichaelRaskin>
Of course, if I see the window, I have probably switched to it in some way, and choice out of 10+ windows is of course textual search…
<MichaelRaskin>
For chat sessions, where I sometimes forget which one is the top one, I can unfortunately admit that the ones that _look_ the same, if I don't intentionally pick-by-search or pick-by-remembered-number, there is no sensible visual clue that helps me.
<MichaelRaskin>
Strategic location of name displayed, full-chat background colour — tried, does not help.
<ehmry>
in my experience everything quickly becomes muscle memory and the discriminators quickly fall away
<MichaelRaskin>
Yep, window selection as muscle memory, visual discriminators ignored
<MichaelRaskin>
Same
<ehmry>
I think that is a side effect of window managers with deterministic placement rules
<MichaelRaskin>
Nah, I do not have enough space for deterministic placement, I actually pull windows into frames
<MichaelRaskin>
Still, the stuff that matters can be pulled by the same selectors…
<MichaelRaskin>
Also, another granularity-related problem
<Shell>
I'd personally want to see (a) windows placed exactly where I left them, and (b) VMs frozen somehow (just given 0 CPU time?) when I stop looking at their windows, until I refocus them. that solves the "a window decides to impersonate me while I'm not looking at it" problem, and the "being aware of what is where" problem.
<Shell>
impersonate something else*
<MichaelRaskin>
Of course, one definitely needs an ability to override that…
<Shell>
of course.
<qyliss>
Do you expect that a VM impersonating you would generally be user visible?
<qyliss>
I'd expect it to happen in the background
<Shell>
I meant impersonating another screen
<MichaelRaskin>
Anyway, a completely different granularity-related problem is of course caching. Qubes has a relatively low number of VMs, so each gets its own image, its own copy of glibc, its own disk cache, no logical problem
<Shell>
e.g. a compromised VM pretending that it's my banking website's "you've been logged out cos timeout, pls give me your password to log in again" screen
<MichaelRaskin>
Spectrum… we should share glibc etc. between similar VMs, right? Caching in every VM sounds RAM-expensive, always rereading from hosts sounds hypercall-expensive
<qyliss>
Yes, we can share read-only memory pages
<Shell>
does that have Spectre/Meltdown implications?
<qyliss>
I don't know yet
<MichaelRaskin>
qyliss: is shared RO memory also enough for, say, locale database?
<MichaelRaskin>
I would expect that there is _some_ way to abuse such sharing to know which parts of the shared pages are in active use by other VMs
<qyliss>
possibly timing?
<qyliss>
i don't really know yet
<MichaelRaskin>
Yeah, timing + cache overload is very likely to do some kind of a leak
<qyliss>
there are people more knowledgeable than me about this I plan to get advice from on this sort of thing when the time is right
<MichaelRaskin>
Well, tradeoffs here might change the tradeoffs for granularity (which can cascade, I guess)
<Shell>
MichaelRaskin: aggressively freezing VMs to deduplicated/compressed RAM (and then to disk) would largely solve that even if the VMs had to have 100% their own unshared memory
<MichaelRaskin>
Freezing means we cannot have any kind of timeouts anywhere…
<MichaelRaskin>
Which probably adds to many design challenges…