Thanks for your input Brendan, David, Chris. Having switched to KDE, the laptop is now completely stable, and in my opinion far more usable than XFCE.
I'm also running Trisquel on a Thinkpad X200 flashed with Libreboot, which feels more secure although requires more care over choosing what to install. I would be keen to see a laptop that supports Libreboot and is powerful enough to run Qubes. What are your thoughts on LXD? Lightweight enough to run on an X200/T400, although of course not offering the same compartmentalization as XEN, sharing the same kernel etc [and yes something can 'feel' more secure, insight deeper into the stack results in more trust] Marc Griffiths marc.d.griffi...@gmail.com On Mon, 20 May 2019 at 20:58, <brendan.h...@gmail.com> wrote: > On Friday, May 10, 2019 at 2:09:09 PM UTC-4, Chris Laprise wrote: > > On 5/10/19 12:16 PM, Marc Griffiths wrote: > > > Next step for me is ordering a T400, which doesn't have Intel > Management > > > Engine, supports Libreboot, and has proven itself as an uncrashable > > > workhorse. I used to run Windows and SUSE on this laptop back in > > > 2008-2011, it never crashed, despite running a complex J2EE dev > > > environment. I will miss having 16GB RAM, but the i7 I can happily > part > > > with. > > > > I doubt that Qubes will install or run on a T400. Qubes was initially > > developed on Sandy Bridge-era hardware, and the requisite virtualization > > features in chipsets was still maturing up to that point. > > > > I feel obliged to mention that if you want to avoid management engines > > and a raft of other processor vulns, you should look to the AMD 15h > > generation of chips (circa 2013). In the form of a Lenovo G505s A10, > > installing Qubes first requires re-flashing the firmware with > > Coreboot... an exercise that I'm about to try. :) > > As much as is really quantifiable...what percent of the real-world risk of > the Intel ME to end-user is related to the fact that the > manufacturer-whitelisted networking chipsets are directly usable by the > firmware, primarily in support of the AMT feature set (and anything > remotely hijacking via AMT, potentially without local compromise)? > > Which is to say: isn't one important mitigation of remote pwnage the > disabling and/or removing (as appropriate) of the manufacturer-supplied > network connections? Without a custom firmware, one can always use a > USB-based wifi/ethernet connection..and with custom firmware (when > possible) you can bypass the hardware whitelist and supply your own > third-party wifi/bt card that the local AMT portion of the firmware has not > been designed to talk to. > > Brendan > > -- > You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-users+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/d84a4fe5-1dcf-4c77-b86a-663672532fcd%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAPsYiwpVzO%3DN1Siver%2BYrKhsULLTTbVZmw59vm9utBxO%2BcLp-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
