What would you like to see improved in Qubes OS?

General Discussion
224

Isn’t that the whole purpose of this thread?

1 Like
225

(Since I’m a new user, I am not allowed to post more than two links in a message. I have abbreviated the Github tickets for Qubes and i3 I am referring to as qubes-issues/#xxxx and i3/#xxxx respectively.)

  • More useful real-time logging in the Details pane of qubes-update-gui. Right now you get all the output blurted out in one buffered chunk at the end, which is rather useless for anything other than auditing. Printing it as soon as it is produced by the package manager would help identify problems (e.g. the update DispVM freezing, which tends to happen from time to time on weak machines). I know the buffered output is a Salt limitation. There seem to be workarounds from a quick glance on Google, but I’m not salty enough to write and submit a patch for this for the update GUI.

  • qubes-issues/#3267: I run into this issue several times a day where keyboard input or mouse clicks are sent to the wrong window, instead ending up being picked up by a different window in the same Qube. Most commonly, it happens with floating+sticky windows, where clicking them in one workspace causes a click to be sent to a tiled window on a different workspace (typically the workspace where the floating window was originally spawned). This is yet to cause any security mishaps on my part (only some close calls with middle-click pasting embarrassing DMs to the wrong recipient that I luckily caught before sending) but I can easily see how it could have really bad consequences. Mitigated slightly by only affecting windows running in the same Qube, but it’s a real headache to have to keep that in mind before doing pretty much any mouse clicks or key presses.

    (This might be related to i3 as a whole, since it does have some recurring issues with input focus even for non-Qubes users: i3/#3609 ; i3/#2778 ; https://www.reddit.com/r/i3wm/comments/apsos1/problem_with_focus_on_new_windows/ )

  • The barrier for contributions to Qubes is unnecessarily dense. I have been meaning to submit a patch (qubes-issues/#6589) which ought to be correct since it’s just reverting a merge error, but have been putting off setting up a development environment for some basic functionality testing, because the information for how to do it is (or was, at the time) so esoteric.

    I see now that there are a few pages documenting it in the developer docs, but skimming through them I still find myself wanting an overview before jumping into disparate sections titled “How to do <some very specific step>” with little to no context.

    Specifically, I’d appreciate an introduction to building programs on Qubes and how (if?) it differs from system’s programming on ordinary Unix systems. Is there a different build process for dom0 packages vs AppVM ones? What are the various build tools (without delving into the details of how to set them up immediately)? What is a typical setup like? Can I do it in a Qube on my normal machine, or do I need a separate machine for testing, where I don’t care about the security of dom0?

    I’m not necessarily too concerned about ending up with a neat RPM file ready for release either, just as long as I can compile a quick and dirty binary to test and make me confident enough to submit a pull request, from whence the CI system can help out with all that bureaucratic stuff :wink: Maybe something like a “My First dom0 Package Build” tutorial would fit my need.

    I suppose a lot of distros struggle with the same dilemma of how much of the documentation should be targeted toward the full-time maintainers versus drive-by-contributors like me, so this is not in any way a criticism uniquely about Qubes.

  • Automatic closing of bug reports between major releases risks losing track of bugs. It’s not a huge deal to write a comment to reopen them (I just did for my ticket above) and I understand why some open source projects do this, but it’s yet another hurdle and it’s ever so slightly disheartening when you’ve put in many hours of research to write a useful bug report :slight_smile:

  • When upgrading from 3.x to 4.x one of the quality-of-life packages I used (unclutter) was silently removed. There is currently a discussion about reinstating it (qubes-issues/#2676) but it is unclear to me why it disappeared in the first place. For the time being I’ve reluctantly put up with the cursor staying on screen and being in the way (moving it out of the way is not always a great idea, since, due to the first bullet point of this post, that can cause tooltips from other programs in the same Qube to pop up instead). There is the xbanish program that ought to replace it, but the current version in Qubes is really old and does not support hiding the cursor after a timeout (instead only doing so when typing). I presume this will sort itself out if 4.2 contains a newer version.

4 Likes
226

Have you had a look at this?

In short:

  • I think people read too much into “closed.” It’s definitely not just you. There’s some kind of widespread cognitive bias where people really don’t like the “closed” state, but it doesn’t mean what they think it means (see link above).
  • On the one hand, you can’t really lose track of closed issues any more than open issues, because they’re all still there. On the other hand, you can definitely lose track of even open issues when you have too many of them. It happens all the time.
  • I think having a very low hurdle like “Add a comment asking to reopen” can actually be a good thing. If no one cares enough about an issue to do even that after many years, then it would probably be a mistake to let it eat up scarce project resources (like developer time and mental bandwidth).
3 Likes
227

That is very true, and I completely sympathize with needing to compartmentalize the high priority and actionable tickets so you don’t drown. Going by personal experience, I don’t think any place I’ve worked has managed to settle on a healthy way to deal with backlogged tickets, so I definitely shouldn’t be throwing stones. If it works for you all in the Qubes team, it’s the right approach!

I hadn’t seen that section in the documentation, but I’m glad that the intent of the open/closed state is explained somewhere. This is partly on me for not reading the links in the README of the qubes-issues repo :slight_smile:

In part, for me at least, I think the knee-jerk reaction towards the “closed” status comes from associating it with less friendly open-source projects from the olde bugzilla days dismissing bug reports “CLOSED-WONTFIX” without any context. To be clear, the github-actions bot does leave a very helpful explanation when closing tickets that clarifies the situation. This helps a lot. Still, the cognitive bias is hard to shake after being in the open source community for so many years.

I do think there is an inherent discoverability issue for closed tickets (for us users), only due to how the Github UI emphasizes open ones by default. Though, as mentioned in the documentation page, you do encourage users to search for both open and closed tickets. I will definitely try to remember to do that from now on.

(By the way, thanks for your welcoming comment on that #6589 ticket from last year, and trying to point me in the right direction in the dev docs. Though, as mentioned, I sadly never got around to delving into it, with life getting in the way :confused: Then again, it’s the very definition of a low priority ticket, so I’m not too fussed about it stagnating.)

2 Likes
228

This one wouldn’t take much effort:

People, especially novices are often confused

Simple tool tip for installer saying something like:

“You don’t have any USB device attached so the installation can proceed. But, you have USB controllers. Please consider to create sys-usb. For more info please refer to The Invisible Things Lab's blog: USB Security Challenges”

… would help I guess.

1 Like
229

I discuss some “things we want to express” (which could translate to your “groups of visual ques”), here:

I do like your qube properties based idea though. If i could still edit the above post i’d probably add “indication of which sys-firewall-* qube it was using” (or more generally, what qube it’s using as it’s network qube).

One option could actually be changing the window title from something like
[work] user@work: ~
(for a terminal) to something like
[work via sys-firewall-wifi] user@work: ~
or
[work via sys-firewall-only-my-bank] user@work: ~
or
[work with no networking] user@work: ~

3 Likes
230

Better communication from the devs

4 Likes
231

Better communication from the devs

Yes please! It’s so hard to have to trawl through forum posts to try and figure out breaking issues and if they are fixable or we have to sit and wait.

I’d also add better treatment of the stable release. It feels like it’s just not cared about when you look at issues like the current breaking updates or security updates where it tends to be along the lines of “those of you on testing you are good, for the rest of you on stable, godspeed, you’ll get the fix eventually”

1 Like
232

One positive development on this front is the new main project showing what the team is working on:

@marmarta just submitted a PR explaining it:

I’m curious why you have this impression. Is it because you think there’s too long of a time gap between the fix going into testing and that same fix migrating to stable, or is it something else? The consequences of moving fixes from testing to stable too quickly can be very bad. We had that problem years ago, where “fixes” that broke more than they fixed were pushed out to all stable systems without sufficient testing. We learned our lesson from such experiences and created the testing repos in order to avoid repeating the same mistakes. If you want, you can enable the testing repos on your own system, then you won’t have to wait as long. There is an inherent trade-off here between speed and stability, so you have to choose which you wish to prioritize.

7 Likes
233

@adw

Is there any article explaining the algorithm of how Qubes software moves from testing to stable? Something like:

https://www.debian.org/doc/manuals/debian-faq/ftparchives#testing
https://www.debian.org/devel/testing

1 Like
234

I think the closest thing we have is this:

Is this what you had in mind?

1 Like
235
2 Likes
236

Coming from a Windows environment that I would like to make less risky, some still recurring points:

  • fix the problems posed by QSB-091 and bring a new, working version of Qubes Windows Tools
  • for Qubes R4.2, fix the problem with the Qubes menus caused by the mishandling of the menu transfer from Windows to Qubes
  • have a new graphic driver in Qubes Windows Tools which would enable seamless mode for Windows 10 and 11, too
  • continued support for Windows 7, as running this last good version of Windows securely is possible only / mostly under Qubes

In my opinion, this would be a considerable help to broaden the usage of Qubes, as, alas, most users still are forced to use Windows.

6 Likes
237

Is this what you had in mind?

Yes. Thanks.

2 Likes
238

UX design. Bad UX is bad security. And so far the UX feels like one or two decades behind.

2 Likes
239

do you have examples?

2 Likes
240

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
241

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
242

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
243

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