On Monday, February 5, 2018 at 4:37:26 AM UTC-5, rob_66 wrote: > On Sun, 4 Feb 2018 12:17:41 -0800 (PST) > Yuraeitha <yuraei...@gmail.com> wrote: > > > 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. > > I strongly support this attitude and could re-post it again and again. (: > > Best regards, R.
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 -- 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/6974d697-0fef-4159-ac2d-c050e1510dab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
