Not possible anymore to hide "un-running VMs" ?
By the way, is it possible to create in Qubes Manager folders to be able to sort out VMs ?
Thx
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.
To me the only ones I feel have a right to comment on this specific topics are people that have at least contributed to the project. I am not saying I am correct but after 25 yrs of open source I have found there way to large a percentage of people wanting to be spoon fed and want and want and want. Entitlement mentality without offering anything constructive to the group collective projects.
IMO that is the largest issue Qubes struggles with as an opensource project. As do many projects. It seems plenty of people want this or that even demand it but rarely are any of them willing or even capable of contributing. Of course all projects needed basic users but this project really really needs more devs.
People complain about doc being outdated......then fix them. If a person is capable of loading Qubes OS they sure as hell are capable of creating or updating some Markdown pages even if it more cumbersome than a typical document format. A 3rd grader could do it.
With all the users commenting in the qubes-user list there is zero reason Docs should ever be outdated for more than a week or two in any area. I have redone and created a number of doc pages and a VERY minor amount of updating a couple script and conf files. (not much of a coder) But there is no reason there are not 20-30 people that over time should be keeping these docs up to date.
Tom has built a Qubes Controller (manager) based on the 4.0 code and went so far as to add in library package so other coding can be used to build. He has been super open to adding functions based on comments. If another person or two could help him with coding now that its not needed to just be python it could become the defacto Qubes GUI to manage the qubes system. That would take it off the plate of the core system devs. i plan to use his controller and if the QM does not work well I will stay with his controller.
You have to consider the finances of the core qube dev that are paid. This was a huge project moving Qubes forward. Consider Qubes 1 and how rough it was. Look at where we are at now. Its a long ways. 3.2 was 3 full major revisions and many sub revisions of the same basic code where 4.0 is very different compared to the other progressive steps of this Os before. 3.1 and finally 3.2 was getting very polished and it can be a bit of a shock when you have to take a step back in polish with such a over all change. Its going to take time but the bugs will be fixed and things will be polished.
I am not a coder so I will make not comments about python use etc other than it seems the reasons were memory-safety vs other. I tend to wonder if KDE issue seen are because they moved officially to XFCE. I think this may have been because of prefer of dev as users and also the low resources of devs to code. But as I said I do not have the knowledge to really speak on the topic beyond what I have seen.
> - The priority is first and foremost security, right?
> Qubes is often misunderstood if they do things in Qubes 4, which may first show its full potential in Qubes 5 or Qubes 6.
I understand security is the priority, but I too think the current state of qubes is a mess. You make a good point about the future and Q5-Q6, and maybe you are both right. Besides surfing and emails, as an end-user I may have to wait for a few years to have a mature QubesOS.
I too cannot evaluate the code, but qubes-manager, system-tray, widgets paired with so many bugs is not a even close to any early beta version I would use as a daily OS. I will wait, for a few years, but that's really a highly optimistic and rather long-term speculation while dreaming about Qubes-IOT and Qubes-Cloud. All while implementing a new admin-api which roadblocked an already delayed update of QubesOS for new fedora versions and leaving qubes with half baked widget solutions in a bug-riddled mess.
Regards
That is what I was getting at. Not to mention if more people would help out so much would be so much smoother and things would seem much more professional and polished i.e. the documents. I know Awokd has started. I now have gotten to a point where I have much more free time. As I am far from a top coder I plan to start going thru the docs topic by topic and updating adding breaking apart. I like the idea of separate 3.2 and 4.0 lines as they are so radically different and really the only complaint for not separating is updating and upkeep. That really should fall on the users once the devs have given us the initial how to on new things.
I really think we should get behind Tom's Qubes Controller and make that into the defacto QM. The ground work is already done and it has a feel that goes more with 4.0.
tom, I really hope you do not get too frustrated and walk as you really bring some good ideas and talent. What you did with the controller gui so many users like it. I think its great and allows for more and more functionality to be added to it. the same can not be said for the QM. I think that is a certainty. I am sure the qubes dev team sure would love to not have to keep the neutered QM as they already tried to drop it so..... Now with the library added that should open the door to those users that stated they wanted to help but were not python proficient to jump in and help with the controller app.
I am currently going thru all the setup script qubes build template options to find what templates compile correctly and what ones have bugs. After that I am happy to write up a markdown page for how to compile and install the Qubes Controller and use it. That can then be submitted to be added to the Qubes 4.0 Docs.
Cheers,
Tim
Don't be so dramatic, I m not suggesting any such thing.
Having developed a Yubikey component for Qubes, I prefer to use Python when possible for transparency. The C bit I've done are opaque to the user (unless he compiled his install of Qubes, and reviewed the code). Not saying it is the default choice but pointing that Python has this benefit.
> Google is a good example, for instance they shipped proto-buffers. Which
> have bindings in a long list of languages (20 or so).
True that API use should be easy at least with Python and C. But C should only be used for core protocols.
I did this doc long long ago. 4.0 has a new networking model. I've just upodated to v4, I'll review it... sorry...
OK, networking is working in R4rc4, I have it working fine with a dozen of VM + my intranet traffic at home routing through QubesOS.
I've started to update the doc here: https://github.com/adubois/qubes-doc/blob/master/security/firewall.md
I am about to do a pull request for this first update.
I do not address the main part because I believe there is a bug with /rw/config/qubes-firewall-user-script not triggering on network change that I want to report and get an understanding on how it will be addressed.
Yes thanks found it and commented on my needs in this type of context. for example, I spin up a web server, I need the FirewallVM to get a hook to update it's firewall rules accordingly.
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 ;)
* 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.