On 6/15/20 1:44 PM, infokiller wrote:
Michael Raskin wrote:
resources than Qubes'. I mean, if the Qubes folks
could fix these issues without a huge effort, even if it meant rewriting all the inter-VM communication tools, they probably would. If they didn't, I assume this is because this is just a huge undertaking (as is the whole project), and they're busy with other work which has higher priority. I would assume that you will end up in exactly the same situation. Note that SpectrumOS is going to make tradeoffs that are complete non-starters for Qubes. True, but I'm not sure this applies to making GUI tools less buggy, or having better documentation for CLI tools.
Yes, it does apply. SpectrumOS is willing to accept quite a bit more of external code with good in-the-wild track record inside the trusted code base, at least for _most_ tasks. So where Qubes needs to reimplement something with a completely different design (allowing minimisation of TCB), Spectrum can (at least in the beginning, sometimes grudgingly) take the closest thing in existence and add only critically missing parts.
And you have all the right to.
However, it seems to me that the reasons behind SpectrumOS being done the way it's done have been pretty extensively explained and documented in this thread. At this point the discussion seems to focus on back-of-a-napkin estimates regarding what is a more effective way of implementing certain things.
Clearly your estimates are different than those of others responding in this thread. You might be right and we might be wrong, but the only way to test that is to start implementing things one way or the other.
SpectrumOS made their estimations and arrived at a decision to do things one particular way. You may disagree this is the best way to do things, but I feel at this point a better way of making your point would be for you to start implementing things the way you believe is more effective.
SpectrumOS is basically a one-person team. If you're right, you should be able to overtake SpectrumOS development pretty quickly.
-- Best, r