I have intense PTSD from the months and months of crashing when I updated to 4.1. I still can’t watch the screen whenever I run a standard system update, I’m sure there are some others that feel the same.
I haven’t had a freeze in a long while now, so thanks to the Qubes developers, that’s a job well done. However I still stand by my statements in QubesOS freeze, crash and reboots that it was irresponsible to release an update that caused crashes like that. Can the Qubes team give their word that 4.2 will be stress tested before being released as stable, or should we hold off on updating for 6 months to a year?
There is always a 6+ month window between a new release and the previous one going EOL. Judging from your message you should stay with R4.1 until it goes EOL, which gives enough time for the most pressing issue to be found and addressed.
You plea for promises is unrealistic. There is testing and release candidates but ultimately only a growing base of installs will uncover the edge cases. This has to do with the wide range of hardware and use cases that are out there and also the limited resources the team has. So going with a brand new release is ok for folks with certified hardware and the ones who don’t care much about experiencing some roughness.
Users who rely on their install to be productive should wait a few months and monitor the forum or (as I have done) get a second identical computer to try the new release out on. And still I’ll probably wait until EOL of R4.1 myself before switching over my productive system to R4.2.
I think you’re misremembering how it all went down, Sven. Qubes 4.1 was released and working well, and then more than 6 months into its release some updates were applied which broke many, many systems including those with HCL hardware (mine included).
My plea is not unrealistic, what happened last time was irresponsible. If an update breaks hardware not on HCL list, that’s unfortunate but for par for the course. If an update breaks HCL hardware in the middle of a release then it’s just plain irresponsible.
You should be careful about jumping to somebody’s defense instead of letting them take accountability. The Qubes developers do and build amazing things, this is true. But in this instance they made a mistake, and should take accountability and learn from it to ensure it never happens again. That is how improvements are made, in all walks of life.
The HCL list doesn’t give you any guarantees, it’s just user reported data (unverified).
Only certified hardware means Qubes OS will be tested on it prior to release. Always was that way.
I understand you don’t like what happened but it might happen again, because the team doesn’t have all the hardware on the HCL list.
Even gigantic corporations like Microsoft regularly break things because they can’t possibly test all installed hardware out there before release. How do you expect a humble FOSS team to do better?
This may sound rude, but this is an open source operating system with limited resources (money and people). Many people dedicate their free time to help Qubes OS to make great releases.
For example, you could give a hand and report if your regressions still happen on the RC3 of the upcoming version. It’s easier for the development team to make changes to fix bugs when the system is still in development than once it’s released.
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
If the Qubes team wants to move fast and break things that’s their perogative, but don’t then advertise yourself as a privacy operating system. Privacy is about moving slowly and making sure everything is safe, not rushing to meet deadlines for requirements that your users don’t care about. If I’m wrong, then why not ask your users? Make a poll and ask if your users would prefer to stay on a highly secured 4.1, or move to 4.2 with the potential for what happened last time to happen again.
Even gigantic corporations like Microsoft regularly break things because they can’t possibly test all installed hardware out there before release. How do you expect a humble FOSS team to do better?
This may sound rude, but this is an open source operating system with limited resources (money and people). Many people dedicate their free time to help Qubes OS to make great releases.
If they are a humble team with limited resources and money then they should adjust their release model. Why these big releases that break so many things? Again, move slowly. This is the privacy way.
When or where has Qubes OS claimed to be a privacy operating system?
You mean “reasonably secure” right?
The focus of Qubes OS is to ensure security through compartmentalization. Which currently is done by relying on Xen. Which in turn limits the amount of hardware that’s supported.
Then solution for you is certified hardware. That’s the hardware the regression test run on. You’ll be on stable ground with it.
Privacy is provided by whonix. Qubes itself isn’t privacy-oriented. Qubes-Whonix integration is a collaborative effort between Qubes devs and Whonix devs, but Whonix isn’t a necessity for Qubes users.
Privacy is provided by whonix. Qubes itself isn’t privacy-oriented. Qubes-Whonix integration is a collaborative effort between Qubes devs and Whonix devs, but Whonix isn’t a necessity for Qubes users.
That was the dumbest thing I’ve read in a while. By that same logic Qubes isn’t reasonably secure, Xen is reasonably secure. … Actually, the CPU is reasonably secure. … Actually, electricity is reasonably secure.
That would’ve been irresponsible, and I see no suggestion that the reason those freezes happened were due to rushed changes or anything of the sort.
Updates were released that broke the system, but nobody bothered to verify this. This is called rushed. Especially when dealing with privacy software.
If I’m wrong, then why not ask your users? Make a poll and ask if your users would prefer to stay on a highly secured 4.1, or move to 4.2 with the potential for what happened last time to happen again.
This title caught my eye - I have had similar experiences and feel the same. Held off upgrading to 4.1 till well after EOL (Jan this year) and it was as painful as anticipated. 2 days for in place upgrade… mainly due to new larger kernels in restricted memory environment. R4.0 was quite reliable, I had some up times > 1 year. R4.1 reset 3 days after the upgrade. Since then it has reset once a month almost like clockwork since then. Usually when I am dragging a window or directly interacting with the system. I am expecting another next week, usually on 2nd or 3rd of the month. Now Qubes usually handles being cut off mid stream quite well, however on the 3rd of this month, a 1/4GB file was written and closed more than 5 secs before the reset, and cleanup on reboot deleted it. Not happy about that loss. Now it is possible that my hardware went soggy on the same day that I upgraded, but I doubt it.
4.1 also has odd problem with mouse overs for other qubes on different desktops pop up randomly - does not give one confidence in compartmentalisation, just reduces confidence generally in the attitude to software quality. Recently Nautilus was nerfed, I am reminded many times a day, was bad enough that dom0 was being a bit lazy and not putting its popups centred on main window, now most other dialoges are also broken (on a large screen the screen centre is a long way from the app main window).
Have put up 4.2 on a new system, where I needed 4.2 for Xen support of new AMD hardware, needed for some work I am doing. Did not expect Qubes to work, but it seems quite reliable, though I don’t leave it up for more than a few days at a time as it is being used for 1 app only. I am not going to invest in migration given I may not be able to upgrade to release version and there is no decision really confirmed on the forced migration to nftables. Have avoided having to learn that so far (elsewhere rhel firewallcmd has done everything needed) and will put it off as long as possible as there is no functional reason to change.
Thanks for speaking up, I have no doubt there’s many others (probability a majority) that feel the same. Unfortunately there seems to be somewhat of a disconnect between the wants/needs of the users and the developer roadmap. It doesn’t help that people in positions of authority in this community immediately jump to the defense of the developers/project instead of evaluating what is being said with a rational mind.
New user, but long time lurker here: the tone in these discussions is unnecessarily acid. Some users present their problems in a way that may be perceived as aggressive, while some others are unnecessarily defensive.
Let’s face it: if the problems described are real, and there is no indication that they are not, then there is a point in having some lessons learnt and try to avoid this kind of issue in the future.
I’m personally disappointed by the way some of the updates are pushed, for example the salt problem in fedora-38 leading to users being unable to update/upgrade some debian-based templates.
Not a problem for me, but a big issue for a non-technical user who chose Qubes for important, maybe life-or-death, reasons. Could it have been avoided? First time, don’t know. Second time, definitely.
Anyway, muzzling a forum user for complaining is not a solution.
If I hadn’t come in aggressively this thread would’ve got zero to a few responses and then been ignored forever. I’m not trying to ruffle feathers, I want Qubes to be the best operating system it can be.
It seems like, other than those that jumped on the immediate defensive, most people are taking my side on this issue. I ask again, why not poll your users for what they would prefer? I can’t make the poll myself, it would be skewed, somebody else needs to do it.
Oh, I agree with your point about the transition to R4.1 being a rough one. Had my own problems too, even went back to R4.0 for a while.
What I disagree with are your wild claims and demands. They are neither reasonable nor productive. If you want to try again, I propose starting a new thread. This one is likely beyond salvageable.