qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
clever has joined #spectrum
klltkr_ has quit [Ping timeout: 264 seconds]
cole-h has quit [Quit: Goodbye]
thefloweringash has quit [Quit: killed]
danielrf[m] has quit [Quit: killed]
colemickens has quit [Quit: killed]
Irenes[m] has quit [Quit: killed]
vladimir-lu[m] has quit [Quit: killed]
edrex has quit [Quit: killed]
danielrf[m] has joined #spectrum
edrex has joined #spectrum
thefloweringash has joined #spectrum
Irenes[m] has joined #spectrum
colemickens has joined #spectrum
vladimir-lu[m] has joined #spectrum
tilpner has joined #spectrum
<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…
spacekookie_ has joined #spectrum
cole-h has joined #spectrum
Profpatsch has quit [Ping timeout: 246 seconds]
spacekookie has quit [Ping timeout: 272 seconds]
Profpatsch has joined #spectrum
spacekookie_ is now known as spacekookie
c4rc4s has joined #spectrum
klltkr_ has joined #spectrum
c4rc4s has quit [Quit: Adios]
c4rc4s has joined #spectrum
DrWhax has quit [*.net *.split]
DrWhax has joined #spectrum
andi- has quit [Ping timeout: 240 seconds]
andi- has joined #spectrum
ehmry has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ehmry has joined #spectrum