Post
Fun fact about #QubesOS (at least R4.3 release candidate) – seems like if I *log out* of the desktop environment session and then log back in all my stuff is still running, and GUI apps' windows show up just fine.
Which makes sense, the VMs have no reason to shut down just because KDE or whatever is not running anymore.
But still, it was a "huh!" moment when I noticed that!
Next I need to test if that's true also *between* different desktop environments (say, log out of KDE, log into Xfce). 👀
Now I need to figure out what that's useful for.
I mean, if my graphical session crashes for whatever reason, that's one obviously. But does it make sense to log out instead of lock screen? 
I feel there's some fun thing somewhere there that's enabled by it, but can't put my finger on it just yet.
@rysiek might be interesting to try and work out which have had more security vulnerabilities (login screen or screensaver lock). I suspect the latter has!
@rysiek Sometimes you want a full restart.
And sometimes you want a full deterministic restart.
That is, if I want to retain state, I just lock my session. Everything's as it was when I unlock it.
Crashes of course violate that, but a crash usually makes a deterministic recreation of prior user state impossible, so pleasant as that would be, it's probably a long reach.
One of the issues that came up in systemd / hotplugging issues was that various system facilities would be available at different times / different addresses (e.g., drive numbers), simply based on the random sequencing of operations during start-up. For all the issues with SysV Init scripts, they run in a determined order, at boot. Devices tend to show up where you expect them to be.
(Whether or not trusting device files to refer to specific /dev filenames is of course a whole 'nother discussion.)
A space for Bonfire maintainers and contributors to communicate
