@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 email@example.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.