On 06/05/2016 05:33 PM, [email protected] wrote:
Just a curious fan here interested in upcoming 3.2 and beyond. So with 3 units
separately tested 3.1 with newest kernels (including 4.4) all have been
struggles to get installed and working on each various piece of hardware. 2
involved incremental upgrade trials and troubleshooting only to still either
reach lack of usability or functionality (boot failure, lockups etc.) I'm
curious if the soon to come 3.2 releases will begin to address the hardware
struggles a lot of us are still experiencing? No judgment or disrespect
intended, I'm trying to resolve issues for hopeful offering to the community
just don't have background or time I'd like. I only ask because it seems that
the better my Qubes OS runs, the OLDER the version (OS , kernel) of the program
has to be loaded.
Am I doing something or understanding something incorrectly maybe? I get
wanting recommendations on templates and what to INCLUDE in 3.2, but I would
say the best inclusion would be a seamless and 100% garunteed installation and
boot up process.
It seems so universally common that OS install and boot are the consistent
issues you guys seem to be getting hit up about, that it would be the goal to
100% iron that down. I'll use Subgraph OS as a recent example (sorry I know
different designs, goals etc. ) as I had it installed and booting unfailingly
on 3 generations of systems, using AMD/Intel various UEFI mixtures and Bios
options and it's considered an ALPHA release with much less community
involvment.
I don't mean to insult, I LOVE what Qubes promises, and when I've managed to
keep it stable for a few hours loved the operational capacity. I just am
struggling to understand what adding more variables and unknown compatability
issues accomplish outside feature bloat and more endless bug testing. Is not a
consistent and standard experience the best focus in driving later
amplification and variation? A reliable foundation vs unsteady and still
unsettled?
My thoughts on the subject:
Hardware specifics cannot be treated as a small detail with Qubes.
People usually encounter compatibility issues with open source systems
like Linux if they are trying it on a variety of hardware. They think of
their hardware as "PCs" and just want "PC compatibility". But this
notion is misleading: The brands in the PC category are trying to make
money on ingenious corner-cutting of very complex designs, and then
customize drivers and configuration options to make it all work with
their target OS... WINDOWS.
So even Subgraph would have difficulty approaching the level of
compatibility that Windows enjoys as the defacto standard.
With that said, Qubes and Subgraph are really not in the same class.
Qubes depends on a bare-metal hypervisor (Xen) which -- let's face it --
was designed for and is mostly tuned for *server* hardware. It also uses
some of the most advanced and quickly evolving features of that
hypervisor, such as PCI passthrough to isolate hardware. This *greatly*
heightens the already precarious nature of non-Windows compatibility on
PCs. Of course, we're also in a special phase where incompatibility with
Intel Skylake graphics is causing even greater challenges.
So while Qubes boots up with a Desktop Linux face, it is far from having
a Desktop Linux architecture and there is currently only one hardware
vendor (Purism) that takes Qubes' design even slightly into account.
Vendors that certify some PC/laptop models for Linux are not taking Xen
into account.
By comparison, Subgraph is like a regular Linux distro with some
"security in-depth" tweaks.
Now, step back a bit: OS X is considered successful... How many models
does Apple offer for it? Its possible Qubes may have more compatible
hardware to run on.
I don't think you mentioned which computer models you are trying to run.
But my suggestion is -- if you want to run an OS as unique and secure as
Qubes -- that you purchase systems from Purism or at least adhere
closely to the most compatible systems indicated by the HCL for now. Do
not get stuck on "I want it to be PC compatible"; that mentality created
unrealistic expectations in the Desktop Linux realm and its exceedingly
at odds with the situation here.
FWIW ...
This is probably an issue where Qubes will have to evolve in order to
succeed. Compare the "desktop Linux" category with Android: The latter
has a reference hardware platform in the form of Nexus. The significance
of this is often overlooked, but Google understands it. (Here, Windows
is no real exception as "IBM compatible" pre-dated "PC compatible" and
the former was its reference hardware platform while Windows predecessor
MS-DOS gained in popularity.)
So, I think the long-term answer to your question is that the Qubes
project will have to evolve to begin specifying what hardware design is
most appropriate to bring Qubes' features to interested users. It may
have to create deep partnerships with hardware vendors to do it. My
guess is that someday the core developers may wish to do this by
defining an open source platform that doesn't use x86, creating a new
class of personal computer in the process.
Chris
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/57554005.2000704%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
