@Tom Zander

On Sunday, February 4, 2018 at 8:15:05 PM UTC+1, Tom Zander wrote:
> On Sunday, 4 February 2018 18:10:44 CET Yuraeitha wrote:
> > Also it's been explicitly said that no Qubes 4 existing features will be
> > added to the new-old Qube Manager. Which might also hint towards no
> > changes coming to Qube Manager. If anything, it has to be re-made almost
> > entirely to work well with Qubes 4+, and currently no one is doing that.
> 
> The Qubes Manager is written to Qt4, which is equally outdated as the 
> backends of Qubes it used (3.x).
> 
> I started a project using Qubes4-api and Qt5 APIs, though. See Ps at the 
> bottom of the mail.
> 
> [start rant]
> 
> The biggest issue i ran into is that Qubes4 is just too immature to actually 
> use for more than browsing and email. It was too painful for my desktop 
> full-time work machine.
> I tried for 2 months, my significant other stated that I had been 
> extraordinary patient with Qubes when I finally stopped using it ;)
> 
> My problems are widespread;
> * the admin-api is very immature and poorly implemented. Getting a stack-
> trace in the server logs and no answer is just unacceptable. Unit tests, 
> anyone?
> * system-tray is hopelessly broken. Losing apps because they don't show in 
> the system-tray up when you close them was fun!
> * The design of qubes-daemon is too fragile, it starts/stops VMs and 
> patiently waits and hopes everything will work. I expected a much more 
> 'hands-on' approach (at least for Linux kernels) with much more reporting. I 
> also lost data because apps aren't being quit, they are being killed on VM 
> shutdown.
> * Why do I see 'lock'-icons for most of my windows in the task-bar?
> * the documentation is very out-of-date.
> * I don't know how, it may be fedora packaging, it may be qubes packaging or 
> configs, but the amount of KDE (apps running in dom0) crashes I had in the 2 
> months of using Qubes is greater than the amount i had in the previous 5 
> years. This boggles the mind...
> * The graphics pipeline is hopelessly outdated. Its about a decade behind 
> the industry.
> * Poor quality of many tools, the icon-copier copying the 22px icon from a 
> VM instead of the 256 one that was also there is just... sad.
> * The amount of services, bash-scripts, config files, duplicated data in 
> qubes and then again in the system is horrible, under documented mess.
> * rexecd validation being implemented using bash is a joke (mostly felt 
> because its extremely slow)
> * total lack of mature end-user-focused tools. Swear to God. There are zero 
> today.
> * Having nothing but python APIs for your operating system is something that 
> makes no sense. Python was never meant for servers, or even big 
> applications. Finding a full-stack python developer is more rare than 
> finding a Bitcoin C++ developer.
> 
> end-rant.
> 
> Qubes is an amazing idea, has some fantastic and genius concepts in it.
> I hope many of those things will get fixed, although the list has grown so 
> long that I'm not sure it can without being forked.
> 
> ps. https://github.com/QubesController is the place where I wrote an already 
> pretty decent "Qubes Controller" using the new APis.
> I'm open to adding anyone to the approved committers list that wants to work 
> on it.
> 
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

I think discussion is good and healthy, though I don't feel it's entirely fair 
to paint it black and white like this. I can agree on many problems, but I 
think they look very different in different light and perspectives, so lets try 
shake it up a bit. I'm not claiming to be right, this is just my perspective of 
things. 

The ancient city Rom wasn't build in one day, it took many decades and even 
centuries. And as awokd said, the security in Qubes is rapidly evolving in 
short time, which is hard to deny. Qubes is heavily disrupting the security 
industry, which has been too stagnant and slowly reactive developing over many 
years, rather than a proactive forward looking perspective, which Qubes has. 


- The priority is first and foremost security, right? Everything else besides 
that is pretty much secondary or lower. Ease of use and emotional related 
things, such as good looking and appeal, will come even lower than secondary 
(don't get me wrong though, I do love good looking systems too my self). 

While the Qubes OS team could need more funding and donations, I don't think 
they are feeling ready yet to go and market themselves before the security is 
on an even higher level. And this I think is very justified in a logical sense 
seen from an understanding of market perspective, once you start market it, if 
the security isn't good enough, then Qubes will just become a short-lived 
fire-fly that only lives 24 hours, before everyone forgets about it again. For 
proper marketing, you need to be ready before spreading the hype. This is why 
many open source projects dye out too, they don't live long enough to be ready 
to deliver, or they deliver too early or too late. As I see it, the Qubes 
developers are currently doing a good job enduring. Security is also the main 
target group to begin with too, so I feel it's overall very justified to focus 
all their energy on security and secondary ease-of-use problems, important 
mainstream hardware support, and so on.

We're in early times, and as I see it, currently the fundamentals are being 
build in Qubes. The structure which everything else ontop will be changed in 
the future. I think it's very wrong to look at Qubes 4 as how Qubes will look 
like in the future. This is a deep mistake from other Linux OS's which are very 
conservative, unchanging, and by all means have an ingrained reactive thinking 
pattern, rather than proactively thinking pattern. I think the Qubes developers 
have a good forward looking foresight, and this is part of the reason why I 
like it so much. But for this reason too, Qubes is often misunderstood if they 
do things in Qubes 4, which may first show its full potential in Qubes 5 or 
Qubes 6.


- There is also the question of how much of this is upstream issues? Not 
everything is Qubes to fix, and it certainly would be ill advized to start 
doing what for example Red Hat is doing and change the code, which has to be 
done everytime a new update arrives from upstream. Although I have to admit I 
have little understanding of codes. 


- Also currently we're still seeing rapid development of security in Qubes, and 
it's still going. The primary developers of Qubes are busy, so I don't think 
it's justified to say any should shift focus to fix lower priority nice looks 
and appeals, like icons (although I do enjoy good looking systems, but it's too 
soon as there are other things to be done in Qubes first). Why are other 
developers from the outside not helping with this? The Qubes developers are 
busy enough with the security aspect as it is after all. Also if more people 
helped, and more put up donations (avoiding too early wide-spread hype though, 
there is a good timing for everything), then perhaps we can get issues fixed 
like missing icons, and so earlier than otherwise.


- Which programs and apps can't you run in Qubes? I mean, I can even run 
Android with Android apps, it's pretty amazing. What sort of programs do you 
have that can't run that well on Qubes? Maybe it can be fixed? 


- Lets not forget, Qubes 4 was about future-proofing Qubes. Currently many 
things need to be fixed again after having ripped everything apart and putting 
it together with many new parts and design shape. Qubes 4 is in many ways, in 
my understanding, really about making the upcoming Qubes 5 and onward possible, 
which is to say, Qubes 4 may not seem so special, but I'm sure it will start to 
show and build up when we're seeing Qubes 5.


- I agree there are problems, and I'm happy to discuss it too. But we must not 
forget to put everything into different perspectives to see things in different 
ways. This too is why discussions like these are so good and amazing, it can 
bring out new perspectives to the mix for everyone taking part in it.

-- 
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/37c1ecc0-cb6a-47d6-82cf-e6fff00a7954%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to