From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.3 (2019-12-06) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=ALL_TRUSTED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.3 Received: by atuin.qyliss.net (Postfix, from userid 496) id 564A394B4; Mon, 15 Jun 2020 15:07:49 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 0E2EC9444; Mon, 15 Jun 2020 15:07:40 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id B4B8F9424; Mon, 15 Jun 2020 15:07:37 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 7A523948F for ; Mon, 15 Jun 2020 15:07:35 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Subject: Re: Comparison to Qubes OS From: =?utf-8?q?infokiller_=E2=80=8B?= To: discuss@spectrum-os.org Date: Mon, 15 Jun 2020 15:07:35 -0000 Message-ID: <159223365545.15924.16442522043812491572@localhost> In-Reply-To: <3f3cd409-2501-2718-1198-25f2e8c79c83@hackerspace.pl> References: <3f3cd409-2501-2718-1198-25f2e8c79c83@hackerspace.pl> User-Agent: HyperKitty on https://spectrum-os.org/ Content-Transfer-Encoding: quoted-printable Message-ID-Hash: FFSZWZ2SVZL7XNECPJB75VBBCVDMEIZI X-Message-ID-Hash: FFSZWZ2SVZL7XNECPJB75VBBCVDMEIZI X-MailFrom: joweill@icloud.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.3.1 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Micha=C5=82 "rysiek" Wo=C5=BAniak wrote: > Hey, >=20 > On 6/15/20 1:44 PM, infokiller wrote: > > Michael Raskin wrote: > > =20 > > 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 (a= s is the whole > > project), and they're busy with other work which has higher priorit= y. I would > > assume > > that you will end up in exactly the same situation. Note that Spe= ctrumOS is going > > to make tradeoffs that are complete non-starters for Qubes.=20 > > 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 wi= lling 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 somet= hing with a > > completely > > different design (allowing minimisation of TCB), Spectrum > > can (at least in the beginning, sometimes grudgingly) take the close= st thing in > > existence > > and add only critically missing parts. I disagree.=20 > And you have all the right to. >=20 > However, it seems to me that the reasons behind SpectrumOS being done t= he 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 estimat= es > regarding what is a more effective way of implementing certain things. I was mainly responding to understand if I'm missing anything. >=20 > 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 t= est that > is to start implementing things one way or the other. >=20 > SpectrumOS made their estimations and arrived at a decision to do thing= s 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 sta= rt > implementing things the way you believe is more effective. I'm not trying to make any point, and I honestly don't have any stakes he= re. I'm trying to figure out why things are done the way they are. My ultimate goal is to have a secure, performant, and easy to manage OS. = And so, I would be very happy if SpectrumOS will be able to satisfy these= requirements. >=20 > SpectrumOS is basically a one-person team. If you're right, you should = be able > to overtake SpectrumOS development pretty quickly. I'm not saying integrating with Qubes is quick or easy: I'm arguing that = it may be the better approach to reach the project goals in a sustainable= way.=20 Either way, I won't have much time to work on something like this anytime= soon. That said, though I'd like to figure out what it involves, and if = it's reasonable to expect I'll be able to make incremental progress as a = side project. >=20 > -- > Best, > r