Template Distro EOL Notifications & Badges #6905
Comments
ninavizz
added
T: enhancement
|
At least Fedora and Debian both support in-place upgrades, which might actually be a better alternative. |
|
Users need to have one consistent system they can depend on for their "Qubes system" (which is many distros) is the thing. Also: Which is more time intensive to implement well within Qubes... a notifications/badge system, or an in-place upgrade system that would also require template renaming and possibly other manual tasks (presuming in-place upgrades would require both)? I agree that "automate/streamline it all" to remove user burdens, is preferred. Until an ideal solution can be developed, though, a stopgap improvement to what exists today, feels important. Hence, this issue. |
|
How is this not a duplicate of #3430?
Not really. Releases of those OSes also reach EOL. For example, the EOL of Windows 7 was a big deal, and it's still a major problem that so many systems continue to run it without any security updates. |
|
@andrewdavidwong I commented on #3430. This issue is specific to EOLs, that issue is for "any critical" thing. Each thing needs to be handled uniquely. I requested additional things Yes, Mac and Windows do both eventually EOL; however, EOLs are faaar less frequent with those. I've casually observed among Linux users, EOL to be a commonly-known about concept. Whereas in Windows and Mac using friends/family "Oh, my thing is too old, lol" is the infrequent anecdote. |
|
I've casually observed among Linux users, EOL to be a commonly-known about concept.
I think you are biased by the Qubes OS defaults. ;-)
With R4.0 the default distribution used for qubes is Fedora which has a lifecycle of 13 months, with new versions being released every 6 months! Let me assure you THAT is crazy even from a Linux users perspective. The reason is that Fedora is meant as kind of a proving ground, leading edge kind of thing from where changes flow into the more serious distributions. It's also the reason I personally do not use it at all except in dom0 where I have no choice and the distribution/EOL doesn't matter anyway.
Debian on the other hand has a life cycle of 5 years, which is much more reasonable. So Debian 10 "buster" will be supported until June 2024 and Debian 11 "bullseye" will be supported until June 2026. An new release becomes available roughly every 2 years. That's pretty close I think to what you are used to from Mac/Windows machines.
If I don't misunderstand, one can now choose in the R4.1 installer whether Fedora or Debian shall be used for the default qubes -- right? If correct, then this should ease the problem mentioned in this ticket tremendously. I haven't tried R4.1 yet, so forgive me if that's already taken care of: maybe we should call out in the installer screen the life cycles of Fedora vs. Debian and why one would prefer the one over the other. Something like:
Debian: long-term support for 5 years, extremely stable but somewhat dated software packages, best choice for most users
Fedora: short support window of ~13 months, leading edge / latest software, best for tech enthusiasts who do not mind frequent updates and maintenance
Just for context some other distributions to compare:
Ubuntu: 5 years (with ESM 10 years!)
Mint: 5 years
…--
public key: https://www.svensemmler.org/2A632C537D744BC7.asc
fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7
|
|
@SvenSemmler SecureDrop uses Fedora and Ubuntu on its servers, and between SecureDrop and Qubes, both, over the past 3 years I've encountered "Uh oh, thing is EOL'd!" several times. Granted, both are unusually complex projects, and most of the anecdotal observations have been from developer users. Thx for the info above, it is actually very helpful to see! Yeah, project-based exposure bias, feeling seen. 🥇 If in fact this issue is likely a non-issue for a majority of users, I'd love to see it just "not done" and punted on, in favor of just waiting for the updating experience to be improved. On the surveys there's been a strong preference for Debian over Fedora, but also a strong preference for just using defaults. In the 4.1 installer, if a user just totally doesn't care and wants to go with what Qubes recommends, what would the installer pick for the user @marmarta (only @'ing Marta to spare Marek the pings)? Below is a screencap from the surveys.
|
|
Makes sense. With Debian templates I see (just normal) updates maybe once a week? Maybe sometimes even less frequent than that. While using Fedora templates it kind of felt like a daily thing. It would be great if R4.1 would default to Debian (I know @adw I advocate a personal preference ... but looking at the survey results I might just represent the majority). ;-) |
|
EOLs happen all the time in Android, Windows, and iOS, which are some of the most commonly-used OSes in the world. Most users just don't know or don't care. You probably notice it more now that you work on SecureDrop and Qubes because these two projects actually understand and care about security. You were probably just oblivious to it before, like most of the rest of the world. |
Why? Still seems like a dupe to me. The other issue includes this. |
There could be one single issue created: "Make a reasonably Secure Operating System," and everything within Qubes OS would qualify as fitting that one issue. So then how would we track the thousands of details that go into building Qubes? The other issue will entail multiple different solutions for each and every "critical thing" identified. One issue for multiple unique problems/solutions (that, yes, each funnel-up to "Better call-out critical things"), feels problematic. EOL stuff's solution is a notification and a badge—I doubt that will be an appropriate solution for all (or even any) of the other "critical things." The initial task of identifying "critical things" apart from EOL stuff, also has yet to be tackled—and to me feels like a more appropriate narrowing of that issue, with individual issues opened from it to solve for each identified problem/solution. It feels (to me, at least) like packing all those solutions into a single issue, is too much. This is one identified "critical thing" that has a specific solution identified for it. You're the PM, and Marek is the guy who oversees the people coding all the things, so it's your call—not mine. That was just my own thinking on it. Happy to defer to your judgement. |
|
from my perspective having two separate issues makes sense, as tackling Template EOL issues may include aspects not part of system-wide critical notifications (#3430), tho it may also take advantage of such notifications. examples below. I think tackling template EOL issues for the user should be seen as a high priority item as there is really no way for the user to navigate it successfully without external guidance (Qubes news, mailing list, documentation), and worse it is not explicitly clear to the user that they need to be seeking such guidance. One strategy could be to incorporate an EOL warning into the Qubes Updater widget - red icon warning that the template (maybe italized, rather than normal or bold) is no longer receiving updates. combined with adding some EOL information in the new Qubes Template Manager this would allow the user to become aware of a template's EOL and also install the newer template, all via GUI. and separately, once critical notifications infrastructure exists, a (daily?) notification could also be pushed to the user. |
andrewdavidwong
added
P: major
This is a hint for updater to notify about old templates (like imported from older qubes version). Related to QubesOS/qubes-issues#6905
andrewdavidwong
added
P: critical
This is not perfect - just gives the user information, not immediately actionable button - but should at least help significantly. fixes QubesOS/qubes-issues#6905
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
andrewdavidwong
added
the
pr submitted
|
Automated announcement from builder-github The package |
qubesos-bot
added
r4.2-vm-centos-stream8-stable
and removed
r4.2-vm-centos-stream8-cur-test
labels
|
Automated announcement from builder-github The package |
|
Automated announcement from builder-github The package |
qubesos-bot
added
r4.2-vm-bookworm-stable
r4.2-host-stable
and removed
r4.2-vm-bookworm-cur-test
r4.2-host-cur-test
labels
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
How to file a helpful issue
The problem you're addressing (if any)
Non-Linux-native users are not familiar with the concept of an OS/distro (or really, any software) "End-of-life'ing."
Mac and Windows OS and app software, just do updates very differently than Linux things. Even for Linux users, when one uses a system such as Qubes with so many distros on it, it can be hard to keep track of them all.
Because of the above, and because we have yet to build-out a more streamlined experience to manage updates, users do not know to migrate their app-vms from one template to another, or to delete the old templates.
Bigger-picture and longer-term, a more streamlined updater experience is a preferred solution—to handle all of this in a guided UI experience. Until then, a notification to let users know what's up, would be great.
The solution you'd like
FooBar-66Template on my machine, I would receive a notification letting me know that FooBar-66 will soon be retired, and that I will need to 1A. Install newer FooBar Templates, and 2B. Delete older FooBar Templates.The value to a user, and who that user might be
For many users, just being told they need to install new Templates and then re-link those to all the qubes using the soon-to-EOL template, and then can delete the EOL template, will be helpful.
For users who already know they need to do this, being reminded that they still have those Templates and need to take action, will be very helpful—both from a security perspective, and ta general-helpfulness perspective. ADHD users matter!
Speaking only for myself, as a user (that like other enterprise users) whose machine is configured by an IT manager in another location, they never see what the total-view of my system is. They had no idea I had 4 versions of FooBar on my machine, with only 2 of them in active use. I'm siked I get to delete the other two versions, but knowing about all of this would have been great.
Related Issues
#3430, #6023
The text was updated successfully, but these errors were encountered: