Re: [PATCH] Documentation: reword the distinctive feature of shared state

[Valentin Gagarin <valentin@gagarin.work>]

> The "still" appears to have got lost from the actual diff.  Should I put
> it back in?

Oh yes, please.  Sorry, apparently I dropped it while changing it back 
and forth.


>> - s/backed up and//
>>
>>    The difficulty of backing up is a specific instance of the
>>    fragmentation problem.  But this is likely only evident to Qubes
>>    users.  We can expect most readers to know about it theoretically at
>>    best.  While it's not wrong to have this sort of anchor, keeping it
>>    risks diluting the main message.
> 
> I'm concerned that removing the more specific verbs here might make it
> more difficult to understand /why/ treating the system as a whole is
> desirable.  We don't have to be so specific as to call out backups or
> management, but I think without talking about something more specific,
> even if that's just "thinking", as in "one only needs to think about a
> single system", it loses its motivation.

Yes, what we're trying to convey here feels tricky to get right.  Not 
sure "thinking of" is more specific than "treating", but maybe it better 
gets across a sentiment of "conceptualising" (in the sense of: mentally 
grasping).  In my drafting I was mainly focused on the interaction with 
the system, since I came from the original which worked with examples of 
handling the system and thus *implied* some thinking.  Maybe thinking is 
just the right thing.  At least this sounds perfectly fine to me:

     This means that the system can be thought of as a whole, rather than
     many virtual machines each becoming a system of its own.

One could argue that thinking about a system is a very specific 
interaction we perform very often...

Feel free to fix it up like that, otherwise I'll give it another round 
of ideas.

Signed-off-by: Valentin Gagarin <valentin@gagarin.work>
> 
>> - "each becoming a system of its own"
>>
>>    This captures the Qubes failure mode Spectrum avoids, where per-VM state
>>    accumulation forces operators into what amounts to orchestrating
>>    a cluster on one's desktop.
>>
>>    In the original, the contrast to Qubes would not be as strong for
>>    people only familiar with it superficially.  Being more explicit about
>>    the nature of the problem helps establishing the narrative frame and
>>    original motivation of Spectrum early on, part of which is overcoming
>>    Qubes limitations.
> 
> Missing Signed-off-by.
> 
>> ---
>>   Documentation/index.html | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/index.html b/Documentation/index.html
>> index 6d6faf7..0ea0a2f 100644
>> --- a/Documentation/index.html
>> +++ b/Documentation/index.html
>> @@ -23,9 +23,9 @@ such systems.
>>   
>>   <p>
>>   User data and application state will be managed centrally, while
>> -remaining isolated, meaning that the system can be backed up and
>> -managed as a whole, rather than mixed up in several dozen virtual
>> -machines.
>> +remaining isolated.  This means that the system can be
>> +treated as a whole, rather than many virtual
>> +machines each becoming a system of its own.
>>   
>>   <p>
>>   Spectrum is an upstream-first project.  Wherever possible, we aim to
>> -- 
>> 2.54.0