Is this what you had in mind?
Yes. Thanks.
2 Likes
UX design. Bad UX is bad security. And so far the UX feels like one or two decades behind.
2 Likes
do you have examples?
2 Likes
It feels quite contrary to other distributions where typically announcements are only made when patches are available for stable, especially when it comes to security patches.
All the qubes security announcements that I can recall are as I mention. “fixed in testing, available in 2 weeks in stable”
I don’t particularly want to have to run testing but I would like to be able to apply security updates when they are announced
1 Like
I can understand - but what are the options?
If the announcement were made when the package hit stable then it would
look as if Qubes were slow to respond.
Generally, its good to be able to have some testing of packages before
they are offered to general users.
Also, there are people who use testing just so they can evaluate
packages in testing - it’s useful to tell those people when there
are such packages.
And finally, there are repositories for “update candidates”, and
“security updates testing” - you could enable just the security updates
testing, if you cannot wait for the migration to stable.
3 Likes
Interesting. I suppose it would be possible to publish QSBs on GitHub immediately but delay the announcements on the website, forum, mailing lists, and social media until the packages hit stable. That feels a bit weird, though, like hiding information from you for your own psychological comfort. On the other hand, I suppose it makes sense that announcements should be actionable for the majority of users who read them. But then again, most QSBs don’t require any special user action. Just “continue updating normally.” I’m also not sure how people would react to such a change. I can imagine the majority of the userbase hating that and preferring the current way we do it. I can also imagine the opposite.
Besides, even if we were to do this, it’s highly likely that some users would take it upon themselves to post their own unofficial announcements here in the forum whenever we quietly published a QSB on GitHub. That already happens now, even when we publish timely official announcements for things (recent example). So, you’d likely end up in a situation where you’re still forced to become aware of security updates before they’re in stable, except you’d probably receive a potentially less-informative, less-reliable unofficial announcement at first and have to wait longer for the official one.
If you don’t want to use security-testing updates (which is completely fine), why don’t you just continue updating normally and get the updates when they hit stable? Or, if you’d rather have the security updates as soon as they’re available, why don’t you just enable security-testing but not any other testing repos? If none of these options sound good, I think it’s because what you want is just fundamentally at odds with the nature of software development. There’s an inherent trade-off between stability and speed. Since testing takes time, you can either have faster updates that are less tested (less stable) or slower updates that are more tested (more stable).
The more I think about this, the more odd it seems to me. I would think that one should decide whether one wants to use only stable or some combination of testing repos, then one should update regularly from there, regardless of any announcements. One would then get the security updates whenever they’re available in one’s chosen repos. Why does it matter if the date of an announcement differs from the date on which the attendant patches are applied on one’s system? One already considered that when deciding which combination of stable and testing repos to use. The timing of the announcement doesn’t change the facts on the ground. The vulnerability is out there, and the fix is either applied on a system, or it is not. The user’s cognizance of the situation doesn’t affect this. Not wanting to hear about a vulnerability when a fix is available just because one has chosen not to apply the fix yet seems analogous to wanting to stick one’s head in the sand or close one’s eyes in order avoiding seeing something dangerous.
3 Likes
I am not a UX designer so this is entirely non constructive criticism, but the out of the box look just… feels like an old operating system. Something that is supposed to be used and made by people who got accustomed with their ideas of how computers are supposed to look and work some decades ago. I know that there are workarounds and stuff and this is a OS for power users mainly, but the simple out of the box appearance is one that limits the accessibility.
This feels like a bad thing to say because I don’t actually know how to make it better, but I feel like with some tiny twists the out of the box experience might become a lot easier.
On the other hand I kind of like that aspect, that setting it up is a lot of work and personalization and figuring things out. I like that as a hobby. But I feel like with some general redesign it might save a lot of clicking through menus for those users who are not willing or able to change much from the out of the box design.
1 Like
please, stop writing directly to me in public threads, and you should write in English in the non-French categories;
1 Like
accessibility as in allowing disabled people to use the system?
this could be improved indeed, but Gnome or Plasma wouldn’t help much in that regard
if you want to start working on it, you could analyze the current UX
write down each simple tasks a user may have to do, describe the steps, see if there are any extra useless steps or if some steps could be made easier / factorized across different tasks.
1 Like
I gotta second this one.
sudo nano /etc/var/lib/qube/libxenlight/qrexNOOOOO COME BACK 
I agree. Virtualization discrimination should be battled at every turn. In the meanwhile try installing it on a w*ndows 
qube with HYPER-V enabled.
1 Like
My big wish is that LibreOffice will run smoothly.
2 Likes
I believe that Plasma, with some tweaks and helper scripts, offers greatly
improved accessibility over Xfce.
I have always found it hard to battle with Gnome, and havent tried for
some time.
2 Likes
A few years ago, I hurt my right handed and found that GNOME was the best desktop for me to use with a single hand: Solene'% : How I ended up liking GNOME
this is good accessibility 
2 Likes
Usability improvement for the Application Menu: in the (Apps/Templates/Services) column of the Application Menu it would be nice to be able to “lock” an entry by clicking it. I find annoying to try to open an application for a given qube and realize that I’ve open a different application in a different qube just because when moving the pointer I’ve come over a different entry in the App/Template/Service column.
2 Likes
Somewhat helpful, but primarily aimed at upgrading template repos to 4.2 with the extra work of having to run inside each template. Thinking more like this:
1 Like
Another way to actually do. 
The two can be complementary. I also keep these scripts on hand 
1 Like
Maybe we should add to everyone’s wishlist this:
- Have the 1.9k issues on GitHub fixed.
9 Likes
Actually Qubes-OS is pretty great right now.
Having said that, what I found during my journey is that there are many features which are getting implemented day by day, but people who are developers or well versed with linux only using them or I should say able to use them. Because no one cares about writing documentation in qubes team. Most of the documentation comes from community, and that’s okay. But obviously person who is changing qubes as developer best knows what going on.So Qubes really needs at least occasional documentation update from developers.
As you can create great things but you should also simplify that to audience. Otherwise it’s all a lost potential.
3 Likes
- I agree on that. I would hope for better and more visible plans and roadmap for future releases. Qubes OS still lacks it to my opinion.
- I would hope the development priorities could be reviewed towards stability and users’ needs. Having Qubes OS for a year without working keyboard layout switching, or without (almost) support of Windows VMs was a terrible experience for community. I think in such cases everything should be postponed and all should be done to fix such regressions, to prevent frustration in the community.
Note, that it is not about my priorities, because I was able to make layout work better for me (and helped with fixing some of the layout issues on github), and lacking QWT for Windows VMs did not affect me completely, because I already had everything working. But for many users it all was (is) a disaster. - Reviewing and accepting
qubes-completionto make everybody’s life better. The contribution exists for a while, it works well for me and other users.
5 Likes