From: "infokiller " <joweill@icloud.com>
To: discuss@spectrum-os.org
Subject: Re: Comparison to Qubes OS
Date: Fri, 12 Jun 2020 11:54:09 -0000 [thread overview]
Message-ID: <159196284966.15924.16876974660333010445@localhost> (raw)
In-Reply-To: <30b730a5-773e-41e8-e94e-5abec26018a4@hackerspace.pl>
Thanks for a useful reply Michał!
Some responses below.
Michał "rysiek" Woźniak wrote:
> Hi!
>
> A QubesOS user here for about a year and a half, let's see if I can help out here.
>
> On 6/12/20 11:06 AM, joweill(a)icloud.com wrote:
> > Going over each usability issue mentioned in the
> > motivation doc:
> >
> > - "Hardware compatibility is extremely limited": I don't believe this is
> > really the case for the minimum Qubes 4 requirements [4]: most modern computers people buy
> > support these. Is there anything I'm missing?
> I got a shiny new Thinkpad T490 a few months ago. 3d acceleration (KDE user
> here, I demand my wobbly windows!) is simply not available, because the dom0
> system is too old.
>
> My other laptop, a T470, was specifically selected for QubesOS, and there were
> still issues (for instance, disabling Thuderbolt got me almost double the
> battery life).
>
> Generally speaking, one can buy almost any laptop today and expect it to mostly
> work with plain GNU/Linux. However, most might not even be able to boot QubesOS.
>
> > - "People are reluctant to use Xen on their
> > computer for power management etc. reasons." Can you elaborate on these issues?
> >
> The T470 had easily a 10-12h battery life on plain Kubuntu. On Qubes, 4-5h is
> maximum I can squeeze out of it, and that's *after* the Tunderbolt fix.
>
> Running virtual machines is extremely resource-intensive, there's no way around it.
But if the issues stem from running VMs (and not switching from Xen), they won't be resolved with Spectrum's current design, right?
>
> > - I know that Qubes considered using KVM and decided
> > against it for security reasons [2]. My understanding is that the downside of this
> > decision is the limited hardware support, which is one of the things that Spectrum views
> > as an opportunity for improvement. Can you elaborate on this decision?
> Can't speak for the developers, but the way I see Spectrum is as a compromise
> between regular GNU/Linux distro (with all the related security problems) and
> QubesOS (with the limited hardware support and
>
> > - "VMs are heavy": How will Spectrum improve
> > on this without sacrificing security?
> I'll leave this to the developers, but will say that I expect *some* security to
> be sacrificed. There are always trade-offs.
>
> I feel one needs to be an expert to use QubesOS, but a regular user (with some
> basic training) can use a Mint or Ubuntu-based system. And I think it makes a
> lot of sense to offer a middle ground.
Agreed, but I think the current design of Spectrum may improve Qubes' hardware issues, but not the other issues the doc mentions. Possibly switching to containers (which something like gVisor) may solve some of the other issues of Qubes, though that would further degrade security.
>
> > - "GUI applications are buggy, command line tools
> > are mostly undocumented": I assume that the reason for this is the lack of resources
> > the Qubes project has. However, I don't see how this will be be
> > better in the case of Spectrum which is a new project with one developer.
> That's a fair point. Things to consider:
> 1. *probably* certain things can be easier (thus, less bug-prone) in SpectrumOS
> than in QubesOS (kvm easier to work with than Xen, bigger potential community of
> users and developers due to improved hardware support, etc);
> 2. perhaps some QubesOS tools could be used in SpectrumOS, thus limiting the
> amount of work needed
>
> > More generally, I'm wondering whether this
> > projects' goals couldn't be better achieved by trying to work with the Qubes
> > developers to integrate Nix. It may very well be that they would reject it for
> > some reason, but then the logical next step would be to fork Qubes.
> My feel is that QubesOS and SpectrumOS might have a bit different threat models
> in mind, and thus things that make sense for SpectrumOS (like using kvm) are a
> no-go for Qubes. But that's just guesswork on my part.
>
> > Have you reached out to the Qubes developers?
> >
> > Thanks in advance!
> >
> > ## References
> >
> > [1] https://spectrum-os.org/motivation.html
> > [2]
> > https://www.qubes-os.org/faq/#why-does-qubes-use-xen-instead-of-kvm-or-some…
> >
next prev parent reply other threads:[~2020-06-12 11:54 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 [this message]
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
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=159196284966.15924.16876974660333010445@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).