Updating Dom0, Qubes, grumbles, things that need to be fixed and not need to be fixed.

[Drew White]

Hi folks,

Please, do not take this whole thing the wrong way.
It will seem like it is sounding the way it is not sounding, just because of the way
it is put together. It's all things that I find need to be looked into, things that I know
need to be fixed, and that I have fixed on my local.
Hopefully you will understand where I'm coming from and understand this the way I
intend for it to be understood, and not the way you will most likely take it.



When will Dom0 be updated to a recent version of something?

If this was CentOS for Dom0 then there would not be this update issue where Fedora
removes the packages and repositories for their "obsolete" operating systems, and
you wouldn't have a useless Dom0 that one couldn't get updates for.

This is the problem with Fedora. CentOS is heading the same way slowly after version 7.

But at least they have long term updates and stable system that doesn't have
invalid repositories after a few months.

Please change the way things are done so that they work long term, not short term.

Or else have a workaround for things to work properly over a long period of time.

Another thing, please get the menu structuring and naming correct, that way we don't
have to alter your code to make the menus correct.

With Windows HVM Templates and AppVMs wether they are standalone or not, why
do you have the menus the way they are? Why not build the tools to build the menu
correctly instead of us having to edit EVERY menu item to get it the way it should
have been built?

Why is the networking so difficult?
I have my DNS server set to the parent virtual (proxyvm or netvm) which has the main
DNS server as the one that's on the network acting as the DNS server, but the
virtuals can't find it, unless I specify it explicitly.

Why is it that the Qubes-Windows-Tools almost never work?
Why is it that the tools never set up the screens right?
Why does it set it up as ONE screen, instead of multiple screens when I use 2+ monitors?
         (This is the reason you are having the issue and bug that you have with the tools on
            large displays)

When reading https://github.com/QubesOS/qubes-issues/issues/1870
There are some good ideas, and some that aren't really good at all.

https://github.com/QubesOS/qubes-issues/issues/1870#issuecomment-223055937
If THAT is what the manager will be like, it has no structure, no layout that is understandable,
it is designed to be "wanky" and not functional.

Your current manager needs only altering to work better, and adding onto it. Not a facelift to
make it look like crap.

The installer doesn't allow for multiple HDDs to be used. It just decides that all HDDs are 1 HDD.
If I select the smaller HDD that the O/S is going on, and the drive I want /var/lib/qubes to go on,
then it sets them up as one hdd and just wants me to assign space.
But that's not what I want. The one that will have the virtuals on it is a mirrored drive, to
keep my virtuals protected.
I don't want half of the virtual to be on the main drive and the other half to be on a mirrored drive
because then if my primary drive dies I won't have the first part of the virtual, only the second.
That's pretty useless to me.

[jkitt]

One of the many benefits of FOSS is that users can contribute - even if it's just writing tickets on the issue tracker.

[Drew White]

On Thursday, 16 June 2016 03:44:00 UTC+10, jkitt wrote:

One of the many benefits of FOSS is that users can contribute - even if it's just writing tickets on the issue tracker. 

Exactly, it's an open thing, but these are things that there are tickets about for some thing.
And some things I have notified Qubes-OS of the problem and it's never had a ticket created or been fixed.
And some things have had great response and been fixed or had a fix in place for the next release, but not being fixed/patched in that one release.

Some things they blatently said they would not ever do, even if it was something that was beneficial (in my opinion), nor were they giogn to give the OPTION that I had recommended to them because they said it would be too much hassle, yet it wouldn't be any great hassle to do it, only adding in a couple of lines of code to the build, nothing strenuous or anything, but still too much hassle for it to be done. So my conclusion is they the couple of lines of code had to be engraned somewhere behind XEN, which would require the XEN people to do it, not the Qubes people, and so it was not able to be done.

And this MacOS patch that was built in version 3.0, if you could please build a patch for version 4, and include that in the build for version 4, that would be great, ebcause having it in there doesn't break any agreement or any terms of lisencing. For me, it would NOT break the lisencing BECAUSE I own the iMac that would be doing all the initial data processing and creation of the system, and updating, for me to then run it as a virtual. Even then if I updated on my virtual and changed things, I still own the iMac, so there is no issue. The iPhone I have can also be a virtual, so it makes no difference.

Hopfully you will add the patch to allow those that own Macs to run ONE system, instead of having to be forced to have both PC AND Mac on their desks.

If I can just keep the Mac in the cupboard, and only use ONE amoutn of Electric Power, instead of having mmultiple machines running and costing money, then that is more than advantageous.

[Alex]

On 06/16/2016 07:26 AM, Drew White wrote:
>
>
> On Thursday, 16 June 2016 03:44:00 UTC+10, jkitt wrote:
>
> One of the many benefits of FOSS is that users can contribute - even
> if it's just writing tickets on the issue tracker.
>
>
> Exactly, it's an open thing, but these are things that there are tickets
> about for some thing.
> And some things I have notified Qubes-OS of the problem and it's never
> had a ticket created or been fixed.
> And some things have had great response and been fixed or had a fix in
> place for the next release, but not being fixed/patched in that one release.

The fact that it's open does not mean that they serve everybody like the
counter of a McDonald's restaurant. It means that anyone can contribute.

> Some things they blatently said they would not ever do, even if it was
> something that was beneficial (in my opinion), nor were they giogn to
> give the OPTION that I had recommended to them because they said it
> would be too much hassle, yet it wouldn't be any great hassle to do it,
> only adding in a couple of lines of code to the build, nothing strenuous
> or anything, but still too much hassle for it to be done. So my
> conclusion is they the couple of lines of code had to be engraned
> somewhere behind XEN, which would require the XEN people to do it, not
> the Qubes people, and so it was not able to be done.

Same as above. You may have your respectable opinion, but that doesn't
automatically cause anything to happen outside your brain. You may share
that, and that may be rejected by others for any reason - be it valid or
not, should you agree on that or not. There's a fine line between
"anyone can contribute" and "contributes from anyone will be absolutely
accepted and included", and no sane project will agree on the second.

Still, since it's free and open software, you can create your patch and
propose it to the project. The steering committee (yes, there must be
one even in FOSS, that's not democracy and could never be) may accept
your patch or not, with reasons that are valid (say, who is going to
maintain your code?) or not, and there's nothing you can do about that.
Yes, you can argue that your reasons were not fully understood, and try
to explain them again. Or maybe they were clear from the start, and your
contribution just doesn't make it.

If your contribute is rejected and you really think the world will be
better with that, fork your distribution. That's how a lot of the linux
distributions were born.

--
Alex

[floria...@gmail.com]

So today must be the 1000th time in my life where I see a project shoots down a good summary feedback, making sure the issues are broken out into pieces and no discussion can take place on the future impacts, and that the very contribution of a higher-level-then-bug-report feedback is being handled as offensive, leeching and useless.

Since it's apparently the 1000th time, I'll put it in your face now.
The answer is "thank you for this feedback".
Noone demands you all sit down and fix anything she wanted, now, for free.
You're being told, in a high-level from the things that will drive away many of the people who are *not* using Qubes.
That doesn't mean you should / need to act now. You should take the opportunity to engange and consider the feedback.
If you sat someone down to write it it'd cost you a few 1000 to get it.

Please don't think I want to single out Alex I'm replying to, this thread is full of this unproductive arrogance and this is just the mail that set me through the roof.

Am Donnerstag, 16. Juni 2016 08:52:09 UTC+2 schrieb Alex:
> On 06/16/2016 07:26 AM, Drew White wrote:
> >
> >
> > On Thursday, 16 June 2016 03:44:00 UTC+10, jkitt wrote:
> >
> > One of the many benefits of FOSS is that users can contribute - even
> > if it's just writing tickets on the issue tracker.
> >
> >
> > Exactly, it's an open thing, but these are things that there are tickets
> > about for some thing.
> > And some things I have notified Qubes-OS of the problem and it's never
> > had a ticket created or been fixed.
> > And some things have had great response and been fixed or had a fix in
> > place for the next release, but not being fixed/patched in that one release.
> The fact that it's open does not mean that they serve everybody like the
> counter of a McDonald's restaurant. It means that anyone can contribute.

Trying to shake up a project that gets stuck on the one end ahead of i.e. coding something that won't work *is* a contribution. It's what a good manager would do, and it comes free.

Giving test feedback on UX level is something that one'd need a UX engineer to do, which is not cheap at all, especially not so if they'd need to rewire menus and understand hypervisor management. It comes free.

Pointing out architectural issues in upgrades that could escalate in the future and listing the factors is priceless, and it comes free.

So maybe try something else than being offended and shooting down the feedback that was given.
There's a few nice options:

- "Yes, some of those issues have given me trouble too"
- "No, to me this has been a rather pain-free thing, it seems I do it differently than you"
- "Can you work with the GUI designer and give the feedback directly? We need the rewrite anyway because <things>"
- "You're right about some of the issues, but - this isn't a bugtracker - can you please make sure there are bugs for *all* of them, and not just some? You know about them now, we have a few 100 more and can't possibly keep an eye on all of this. If you need someone to help you, let us know but please help by doing as much as you can"
- "It seems you're more troubled by the multitude of issues that hurt you, not by individual ones. We don't have the resources to proactively fight things like that, and noone can fix them now. But please understand they are transient and for many of us, it doesn't hurt that much".
Finally also this one:
- "Thank you for writing. I'm sorry to tell you, but what you're listing just isn't important when you consider the project goals, which are already sky-high. If the community demands fixing every single scratch, there will be no project."
Even this would have been better.
- "HAHAHA No"

I'm sickened by the lack of empathy and thinking and you should stop this, for the better of the project.

Florian

[Drew White]

Firstly, Alex, hello,

Initially I want to say that I appreciate your harassment of my feedback and information provided.

If you noticed in my initial opening statements I wished for the details and information to NOT be taken the wrong way, which it appears that you have.

On the subject of contributing, I would love to, but the areas that need much of the issues resolved I would have to spend a year or maybe even 2 to be able to learn the code, know the code inside and out before I attempted to start contributing in those areas. Thus I provide the details and information here as questions to find out answers, and make statements about things that would generally cause issues.

I respect where you are coming from when you say what you say, and my statements are not "this needs to be fixed this second" for most things, as I stated in what I said, there are restrictions that come up that can cause it to not be possible, or just not possible at this time. And I did mention that, but you have seemingly overlooked that fact when writing your scathing reply.

I hope that you can in future please read thoroughly before you reply to avoid a situation such as this arising again.

Sincerely,

Drew.

[Alex]

On 06/16/2016 01:52 PM, floria...@gmail.com wrote:
> So today must be the 1000th time in my life where I see a project

> shoots down a good summary feedback [...]

>
> Am Donnerstag, 16. Juni 2016 08:52:09 UTC+2 schrieb Alex:
>> On 06/16/2016 07:26 AM, Drew White wrote:
>>>
>>>
>>> On Thursday, 16 June 2016 03:44:00 UTC+10, jkitt wrote:
>>>
>>> One of the many benefits of FOSS is that users can contribute -
>>> even if it's just writing tickets on the issue tracker.
>>>
>>>
>>> Exactly, it's an open thing, but these are things that there are
>>> tickets about for some thing. And some things I have notified
>>> Qubes-OS of the problem and it's never had a ticket created or
>>> been fixed. And some things have had great response and been
>>> fixed or had a fix in place for the next release, but not being
>>> fixed/patched in that one release.
>> The fact that it's open does not mean that they serve everybody
>> like the counter of a McDonald's restaurant. It means that anyone
>> can contribute.

I did not shot down the summary feedback, so I assume your first
paragraph apply to the discussions in the qubes-user ML as a whole.

I do not even represent anything related to Qubes beyond myself (an
user), so I will not take the rant as directed to me.

In fact, the first mail by Drew *is* a nice report. If I were in the
Qubes project, I'd thank him for the feedback.

What I'm complaining about is the reply Drew wrote to jkitt, that
complains that his/her suggestions were not taken into account in the
Qubes issue tracker. The discussion that follows points out only that:
yes, feedback is nice and appreciated, but there's no need to lament
that it did not have any effect.

--
Alex

[Alex]

On 06/16/2016 02:46 PM, Drew White wrote:
> Firstly, Alex, hello,
Hello to you =)

> Initially I want to say that I appreciate your harassment of my feedback
> and information provided.
>
> If you noticed in my initial opening statements I wished for the details
> and information to NOT be taken the wrong way, which it appears that you
> have.

As I told florian.heigl, I did not accuse your feedback - which is nice,
per se, imho; I'm not involved in the Qubes project any more than any
other casual user.

What I tried to explain was that, like florian is sick and tired of
projects rejecting feedbacks, I'm sick and tired of people crossing the
line with expectations about their feedback - yes, feedback is nice and
highly appreciated, but that does not automatically mean anything inside
any project.

> On the subject of contributing, I would love to, but the areas that need
> much of the issues resolved I would have to spend a year or maybe even 2
> to be able to learn the code, know the code inside and out before I
> attempted to start contributing in those areas. Thus I provide the
> details and information here as questions to find out answers, and make
> statements about things that would generally cause issues.
>
> I respect where you are coming from when you say what you say, and my
> statements are not "this needs to be fixed this second" for most things,
> as I stated in what I said, there are restrictions that come up that can
> cause it to not be possible, or just not possible at this time. And I
> did mention that, but you have seemingly overlooked that fact when
> writing your scathing reply.
>
> I hope that you can in future please read thoroughly before you reply to
> avoid a situation such as this arising again.

Don't worry, I do; I'll try to explain myself better, instead, since it
appears that both you and florian mistook my rant against the "immediate
transformation of feedback in action" for a rant against feedback.

--
Alex

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-06-16 04:52, floria...@gmail.com wrote:
> So today must be the 1000th time in my life where I see a project
> shoots down a good summary feedback, making sure the issues are
> broken out into pieces and no discussion can take place on the
> future impacts, and that the very contribution of a
> higher-level-then-bug-report feedback is being handled as
> offensive, leeching and useless.
>

Just to be clear: The Qubes Project has not shot down this feedback in
any way. In fact, no one from the Qubes team has had a chance to
respond to it yet.

> Since it's apparently the 1000th time, I'll put it in your face
> now. The answer is "thank you for this feedback". Noone demands you
> all sit down and fix anything she wanted, now, for free. You're
> being told, in a high-level from the things that will drive away
> many of the people who are *not* using Qubes. That doesn't mean you
> should / need to act now. You should take the opportunity to
> engange and consider the feedback. If you sat someone down to write
> it it'd cost you a few 1000 to get it.
>

I mostly agree.

Drew: Thank you for taking the time to communicate your feedback to
us, and thank you for making the effort to do so in a constructive
way. It is being taken into consideration.

Please understand that our resources (especially our developers' time)
are very limited, so we can't respond to every piece of feedback we
receive, but we value it all and take it all seriously. Please also
understand that the project has its own road map and its own
priorities, which don't always align with what each individual user
thinks the priorities of the project ought to be, even though our
ultimate goal is always to improve the security of our users.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXYtFpAAoJENtN07w5UDAwCSwP+gLR+kzKzf6viFEitXPEoPuf
0GO2MdaXp1xBLCWsPaKsCZ12brsPQJ8hb2Ud+Z9EL/48P2yRZq6/W+u0iMSOekWV
S2Z23NJkLCOefWZwlXntKYdBc/fn4FI7hXg6H5AkiVTJXPMGO7z0WE98nmcgIPxZ
YPLB55iqNnJaeDOnQFWWd0iY1TsdOCP2ROsiVnuGpPcjv79jlPAajORafkfTkqWF
sDyFJrDDoZQbEwBCud84SnNJXJtlv+K7PbKqr+/MDDFkXLCnytB9ZgnsCwEj3Oy3
vjJEQl60ZFw5IgSrP8sjJR7VOd0Q53mHlMhRwBYkxhwj92eMlMPaIrf6v6nlksNK
pSSygXCnQo2TF/aU+ynlz2ks6sNKPaQz9m0pj6Q6rFx7l2O2naUc1/A4zwlecgZ0
52oJHhop0op+urA2BSKY/q05eQ3kc7HfPDHehtQsG0LFoU+9D79Dj7MZdwswPoRh
pg7LTaZctX+ZP4f6TUMDnOqd4Pc16tLyeumGfp33jkuUB2Yu2DWijzFJR+FPRx+1
JwAgRU1tNNVZjQHMKqqsPOT7b3KWtvFsfcHFXU1VvLCgD2xAJ+wOOdBcblMe7ZwQ
0I8eqjiukesGf3LV4s57CiopEyP6wUc3rV4/zybjrGUY5SB1ZxLAhaGOepgT8Ele
ASpymttyLiw1JmoM7TuQ
=p/tx
-----END PGP SIGNATURE-----

[Franz]

Yes Florian I too am unable to feel empathy either for your post or for Drew one. Being in empathy means sharing feelings. But what I feel is gratefulness for all developers. How can I share grumbles? Too difficult for me. I am sorry. I like proper form and respect even for a bug report. But of course I understand what you mean and you are not wrong either. But no empathy sorry.

Fran

 

--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2bcc2cb3-60f4-484e-92af-9f624d299cff%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Drew White]

Hi andrew,

On Friday, 17 June 2016 02:19:02 UTC+10, Andrew David Wong wrote:

Just to be clear: The Qubes Project has not shot down this feedback in
any way. In fact, no one from the Qubes team has had a chance to
respond to it yet.

in the past, yes, my feedback has been shot down and rejected and not
really taken any notice of, perhaps they were not actually part of the
Qubes Contributors and I was mistaken in that fact?

Because there have been things that have been broken AFTER version 2,
and they still have not been addressed. And you are now 2 whole versions
later, and it's STILL broken

So, naturally, what else am I supposed to suspect?
 

I mostly agree.

Drew: Thank you for taking the time to communicate your feedback to
us, and thank you for making the effort to do so in a constructive
way. It is being taken into consideration.

I like Qubes, it's the best system I can find so far for security purposes.
It's got bugs that need to be fixed, and I just keep adding to the list of
bugs and now I have reported most of them here, all the bugs since
version 2 of Qubes that still remain, along with some gripes and
frustrations and forward looking at what it planned/suggested.

 

Please understand that our resources (especially our developers' time)
are very limited, so we can't respond to every piece of feedback we
receive, but we value it all and take it all seriously. Please also
understand that the project has its own road map and its own
priorities, which don't always align with what each individual user
thinks the priorities of the project ought to be, even though our
ultimate goal is always to improve the security of our users.

Time and resources, yes, that they are, and I completely understand that.
There are some things that I myself could do to contribute if I knew what
tools were required for some of the things, and if I had a GIT account,
but I dont' have the account at this time, and thus I can't contribute.
All the things I have done are only on my machine and another at the
time, and working flawlessly (even though Qubes developers told
me that it was "NOT POSSIBLE" in not so similar words.

Yes, I can see the roadmap, but the pothole 2 miles back isn't fixed
yet. That is where my gripe started. If I was able to code that myself, if
I had the knowledge in C that I required to be able to fix it, then I would
fix it myself and upload the code to you. But I don't, and thus I can't.

I understand that security is the most important, but I just don't want to
see this project start to fail like I see many others do. I see projects
start and there's a bug I report, then it isn't fixed, and then down the
track they have to undo a years worth of coding to fix that bug.
Then that project collapses unto itself.
That's not something I want to see ever happen to Qubes. And since
It's based on a Unix platform on XEN, I don't see the problem arising
in that way so much as it's all separate coding.

I wish I knew what I could do to help, but there are things that were
talked about in the forum here, that I was then going to discuss
things, but then I found on GIT that it was going to have a
complete overhaul sometime, so I was just leaving it, that's the
qubes-manager, which I have cured the bugs here on my end.

There are things that are done in the wrong way, which are easy to cure.
There are things which I have built my own scripts to do things for me
that are just common things that should be done.
I have altered code in many qvm-* things just to make things work the
way that they are needed to work.

The Qubes manager, it really just needs a scrollbar and sorting feature.
Simple and fixed.
Also, removal of these coloured bars for CPU and RAM... Just text...
Remove the overhead for the CPU and have Dom0 without all the EXTRA
graphical stuff, to keep it as an administration platform, not as an end-user
platform that soaks up the CPU and GPU.

I'll end it there for now. Before I start going on and on about it all.

Sincerely,
Drew.

[Drew White]

Hi Francesco,

On Friday, 17 June 2016 03:52:26 UTC+10, Francesco wrote:

Yes Florian I too am unable to feel empathy either for your post or for Drew one. Being in empathy means sharing feelings. But what I feel is gratefulness for all developers. How can I share grumbles? Too difficult for me. I am sorry. I like proper form and respect even for a bug report. But of course I understand what you mean and you are not wrong either. But no empathy sorry.

Fran

As I said Fran, my posts were not to be taken the WRONG WAY, because I knew that they probably would be.
So that is the reason you can't feel the empathy for my post even though it is there.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-06-16 17:36, Drew White wrote:
> Hi andrew,
>
> On Friday, 17 June 2016 02:19:02 UTC+10, Andrew David Wong wrote:
>>
>> Just to be clear: The Qubes Project has not shot down this
>> feedback in any way. In fact, no one from the Qubes team has had
>> a chance to respond to it yet.
>>
>
> in the past, yes, my feedback has been shot down and rejected and
> not really taken any notice of, perhaps they were not actually part
> of the Qubes Contributors and I was mistaken in that fact?
>

Well, there's a difference between a contributor and a member of the
core team. Anyone is free to contribute to the project, even if they
are not a member of the core team.

(Note that saying, "anyone is free to contribute" does not mean that
everyone's contributions are guaranteed to be accepted.)

As for feedback "not really [being] taken any notice of," that may be
due to the time constraints we all face (and the fact that the team
was smaller before). As I mentioned before, we can't respond to every
piece of feedback we receive. (If we did try to do that, it would be
easy for people to "DoS" the project by flooding the mailing lists
with lots of low-quality feedback.)

> Because there have been things that have been broken AFTER version
> 2, and they still have not been addressed. And you are now 2 whole
> versions later, and it's STILL broken
>
> So, naturally, what else am I supposed to suspect?
>

Well, it's most likely one of the following:

* We recognize the problem but still haven't had a chance to fix it,
given our list of priorities and the small size of the development team.
* We recognize the problem but don't have someone with the necessary
expertise to fix it.
* We recognize the problem, but we do not plan on allocating any of
our limited development resources to fixing it because we have other
priorities, so we're asking members of the community to contribute
patches for it.
* We disagree that it is a problem or that it should be changed.

>
>> I mostly agree.
>>
>> Drew: Thank you for taking the time to communicate your feedback
>> to us, and thank you for making the effort to do so in a
>> constructive way. It is being taken into consideration.
>>
>
> I like Qubes, it's the best system I can find so far for security
> purposes. It's got bugs that need to be fixed, and I just keep
> adding to the list of bugs and now I have reported most of them
> here, all the bugs since version 2 of Qubes that still remain,
> along with some gripes and frustrations and forward looking at what
> it planned/suggested.
>
>
>
>> Please understand that our resources (especially our developers'
>> time) are very limited, so we can't respond to every piece of
>> feedback we receive, but we value it all and take it all
>> seriously. Please also understand that the project has its own
>> road map and its own priorities, which don't always align with
>> what each individual user thinks the priorities of the project
>> ought to be, even though our ultimate goal is always to improve
>> the security of our users.
>>
>
> Time and resources, yes, that they are, and I completely understand
> that. There are some things that I myself could do to contribute if
> I knew what tools were required for some of the things, and if I
> had a GIT account, but I dont' have the account at this time, and
> thus I can't contribute.

Please note that a GitHub account is free (as in, costs no money) to
create and use. However, a GitHub account is in no way required to
contribute to Qubes, so if you have other objections to GitHub, that
is fine. You can instead email Git patches to us (which Git supports
natively).

Please see these pages for more details:

https://www.qubes-os.org/doc/contributing/
https://www.qubes-os.org/doc/source-code/

As for finding out what tools are required, it would be best to ask
specifically on the qubes-devel list. For example: "I want to help
implement feature X. Here is my rough plan for implementing it: [...].
Is this a good plan? Which tools should I use to do this?"

> All the things I have done are only on my machine and another at
> the time, and working flawlessly (even though Qubes developers
> told me that it was "NOT POSSIBLE" in not so similar words.
>
> Yes, I can see the roadmap, but the pothole 2 miles back isn't
> fixed yet. That is where my gripe started. If I was able to code
> that myself, if I had the knowledge in C that I required to be able
> to fix it, then I would fix it myself and upload the code to you.
> But I don't, and thus I can't.
>
> I understand that security is the most important, but I just don't
> want to see this project start to fail like I see many others do. I
> see projects start and there's a bug I report, then it isn't fixed,
> and then down the track they have to undo a years worth of coding
> to fix that bug. Then that project collapses unto itself. That's
> not something I want to see ever happen to Qubes. And since It's
> based on a Unix platform on XEN, I don't see the problem arising in
> that way so much as it's all separate coding.
>

I think the best thing to do here is to lay out your argument (e.g.,
for why bug X should have a higher priority) as clearly, objectively,
and rationally (but also concisely) as possible. In my experience, the
Qubes developers are very receptive to that type of argument. In the
end, they may still not agree, but you will likely have a much clearer
understanding of why, exactly, they don't agree.

> I wish I knew what I could do to help, but there are things that
> were talked about in the forum here, that I was then going to
> discuss things, but then I found on GIT that it was going to have
> a complete overhaul sometime, so I was just leaving it, that's the
> qubes-manager, which I have cured the bugs here on my end.
>
> There are things that are done in the wrong way, which are easy to
> cure. There are things which I have built my own scripts to do
> things for me that are just common things that should be done. I
> have altered code in many qvm-* things just to make things work
> the way that they are needed to work.
>
> The Qubes manager, it really just needs a scrollbar and sorting
> feature. Simple and fixed. Also, removal of these coloured bars for
> CPU and RAM... Just text...

An overhaul of Qubes Manager (which would affect all the things you
list here) was in progress, but we currently need a GNOME/GTK
developer to continue work on it:

https://www.qubes-os.org/join/#tocAnchor-1-1-5

> Remove the overhead for the CPU and have Dom0 without all the
> EXTRA graphical stuff, to keep it as an administration platform,
> not as an end-user platform that soaks up the CPU and GPU.
>

Splitting dom0 into an "AdminVM" and a "GUIVM" is on our roadmap:

https://github.com/rootkovska/qubes-roadmap

> I'll end it there for now. Before I start going on and on about it
> all.
>
> Sincerely, Drew.
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXZN2LAAoJENtN07w5UDAwA0IP/2NqKCSwuN/zPcU/QiF7PFza
TnmDxZGK3ZvjtHRDkOvVNcqMBFuMb8K+hOD8uHJr28KEM62rwYnWJUHUiVL8Fpv1
3p10xEsBCpunbQufr4we7yc8ovmTTqYYRGVtH4GIn/1WytAqf1mnpnFoYiJHvEcm
2PH19aP1hbnpJgH3y6fqJEoQwXEU4YYZwuauM6YbUv8CDeRVVJqMSR2/mY8yMzAL
Czx/ZxM2UE3TWrPMmZdiYlrIrU+7ruXW3Y3CWSmj8+U+WaaUYqcCw53fOsZcYEid
1wTLyy2yvifbbt8kn++UkeDpHRJ4CzBJSIWyYO6QSRMM87cr8oF4J1TO8sUQBQTm
fWAdsghjSaayy5JMEPrDHBF7w4uiHqTI+JpRRJXq+Bu2FBgIy7bAbn0nGsO/zbnV
gZTUqFl79Xeggg6FF5IhS5Mwd6PQPUkJKsj4BCGH1AQ7XeAHljcKRKAMy4hUBAUs
oTs/0vMErFezpazqJuHFKXRLLDLECImdaNYDMlfJw2vBichcEY5Xn0bveMvrKSrI
bZqczznXkeg9d1su45mItwaI570/AoPNf7I9VI4DFB7zQ5FD/jtJ3e8ZnLR3RcXQ
yz3xTEBuz2BxMSae6Eq4/ftgjW8DM2fRi965NPlCKreRTdGVZZk9qIF5D621MPjF
O9cJkGO0EMpdYc/A72Lf
=astl
-----END PGP SIGNATURE-----

[raah...@gmail.com]

What updates do you want for dom0? I'm only worried about security improvements and would like dev team to focus on that. Its why I'm using qubes. I don't need the latest shiny desktop.

I do agree about that qubes manager proposal. I like the manager the way it is, keep it simple. I don't need it fancy. IMO, the less screens and mouse clicks I need to use the less cumbersome and confusing it is.

I also like all the vms shown on one screen, which I always have open on the desktop to see any error or update notifications that might appear. (I never see popups on panel) And also to make it easy for me to click on one if I need to change settings or administer it. So I hope that doesn't change. I definitely don't want to have to use numerous diff tabs and menus just to list vms.

[Alex]

On 06/20/2016 03:50 PM, raah...@gmail.com wrote:
> What updates do you want for dom0? I'm only worried about security
> improvements and would like dev team to focus on that. Its why I'm
> using qubes. I don't need the latest shiny desktop.

I would like upgraded versions of video drivers, and I remember Drew
being another person who could use updated video drivers too.

In mitigating this need, 3.2 Rc 1 seems to have an updated dom0, which
should bring updated video drivers (together with updated desktop
environments), and in the roadmap for R4 there is a separate guiVM,
which should be upgraded like the others but should host the video
adapters (driver updates more frequent).

--
Alex

[raah...@gmail.com]

I have that old school 90s mentality. I hate updating drivers unless they are for security patches, or bug fixes directly related to my software. Otherwise I feel I end up with more bugs and vulnerabilities and poorer performance, then otherwise. I feel most of the updated videos drivers are made soley for supporting the latest cards. I have this issue now with the latest ndivida drivers for my 650 ti card. Older drivers have better performance. 340xx vs 362. I also don't update my hardware all the time either...lol If it aint broke I don't fix it.

But if you are saying that you have a newer board that isn't supported well in linux and have critical issues that are only resolved in a later kernel then I completely understand. Eventually newer hardware has to become supported.

[raah...@gmail.com]

Also let me add the latest KDE's are so buggy and unstable its crazy. When comparing all the baremetal distros, debian is the only one that isn't bugged out with my hardware. It seems to be the only sane distro left in linux.

[Drew White]

Also let me add the latest KDE's are so buggy and unstable its crazy.  When comparing all the baremetal distros,  debian is the only one that isn't bugged out with my hardware.  It seems to be the only sane distro left in linux.

The latest version of KDE is full of the "wanky" stuff. (please excuse the language)

I can't get a simple menu any more, I HAVE to have this stupid one.

I want to click on the menu and have a cascading menu that's easy to

follow, not have to click 5 million times to do something.

In 3.1 I had a lovely menu, it was clean and concise and functional, not

this crazy one that's hard to use. I tried to find the basic menu, but it

just wasn't there.

Is it possible to add it back in please?

[Drew White]

If the qubes-manager is going to change to that one that's in

GitHub*, could you please let me know how to uninstall the

current manager without breaking anything?

* https://github.com/QubesOS/qubes-issues/issues/1870#issuecomment-223055937