From: "infokiller " <joweill@icloud.com>
To: discuss@spectrum-os.org
Subject: Re: Comparison to Qubes OS
Date: Mon, 15 Jun 2020 15:07:35 -0000 [thread overview]
Message-ID: <159223365545.15924.16442522043812491572@localhost> (raw)
In-Reply-To: <3f3cd409-2501-2718-1198-25f2e8c79c83@hackerspace.pl>
Michał "rysiek" Woźniak wrote:
> Hey,
>
> 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. I disagree.
> 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.
I was mainly responding to understand if I'm missing anything.
>
> 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.
I'm not trying to make any point, and I honestly don't have any stakes here. 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.
>
> 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.
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.
>
> --
> Best,
> r
next prev parent reply other threads:[~2020-06-15 15:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 11:06 joweill
2020-06-12 11:28 ` Michał "rysiek" Woźniak
2020-06-12 11:54 ` infokiller
2020-06-12 12:02 ` Michał "rysiek" Woźniak
2020-06-13 11:19 ` Alyssa Ross
2020-06-13 11:38 ` Alyssa Ross
2020-06-14 20:19 ` infokiller
2020-06-14 21:27 ` Alyssa Ross
2020-06-14 22:19 ` Michał "rysiek" Woźniak
2020-06-15 1:59 ` infokiller
2020-06-15 1:54 ` infokiller
2020-06-14 21:13 ` Michael Raskin
2020-06-15 1:33 ` infokiller
2020-06-15 11:38 ` Michael Raskin
2020-06-15 13:44 ` infokiller
2020-06-15 14:06 ` Michał "rysiek" Woźniak
2020-06-15 15:07 ` infokiller [this message]
2020-06-15 14:42 ` Michael Raskin
2020-06-15 15:29 ` infokiller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=159223365545.15924.16442522043812491572@localhost \
--to=joweill@icloud.com \
--cc=discuss@spectrum-os.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).