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.
It’s literally on the homepage under “What’s Inside Qubes”, right next to “Secure Compartmentalization”. It’s a clear claim that Qubes is privacy focused.
You would do good to acknowledge when you’re wrong instead of persisting. I bet you’d be a lot more successful than you are now, hardware boy.
You mean under it by two headers, and it is addressing Whonix with Tor networking, not Qubes OS alone.
Yeah, reminder: privacy and security are not the same, and don’t always imply each other. With that said, see you all in some other thread.
I think the main misunderstanding is right here. From the Github and forum discussions I got the impression that everybody bothered and took it seriously; however the issue was really hard to reproduce, and due to the low resources of the Qubes team it took a long time to actually find and fix the cause. I did not see any rush.
For example, on my hardware I never even encountered any reboots or freezes.
The OP was temporarily supended for an ad-hominem attack against another community member.
In the forum we do encourage people to discuss issues they have with the system, but making demands from the Qubes team starts being a bit unacceptable (though not necessarily CoC-violating) especially when we all are aware of the constraints. The Qubes team doesn’t want to to break people’s systems at all, but as @Sven pointed out, even big tech companies can’t guarantee this either. So the certified hardware is the only guaranteed way to have compatibility assurances (because everything is tested there).
Regarding the Qubes protecting privacy, it’s not entirely true. It certainly enables you to have more privacy (multiple VPNs, whonix, etc.). But ultimately it’s about security and so there are no privacy claims by the Qubes team about the system (apart from collecting nontelemetry). But this discussion is not relevant here. Please discuss instead here:
Why are you speaking on behalf of me?
Anyway, Invisible Things Lab offers Qubes OS services, i.e. deployment, debugging, feature development. Why not pay for such a service and support the development this way as well?
I was haunted by kernel freezes in Qubes 4.1 for several months myself. I have nigher an idea why they precisely appeared in the first place, nor what solved the issue for me in the end. They turned out to be impossible to debug, at least for me, besides the fact that they only appeared in conjunction with salt.
With the new updater the Qubes team is moving away from salt it seems. At the very least regarding the updater. As I understand it that was the part that actively ran salt the most, post install
I use salt quite extensively, several times a week, for all kinds of tasks. Anyway, the matter is solved for me, apparently, since a few months now.
The only issues I had with 4.1 was when kernel-latest was updated to 6.3 and later 6.4. I switched back to 6.1 and my freezes are gone. Apart from that I had no issues with 4.1, on 2 different machines.
I think it is only for the updater that there is a move away from
Salt.
Actually there have been many threads on the same topic which have
attracted attention without starting with hyperbole and aggression.
In one of the previous threads I tried to make some progress by inviting
users who had problems to provide some system information so we could
hone in on the issues.
That effort never got off the ground because few users wanted to put the
effort in to identifying when the problem arose. And there’s the heart
of the problem - Qubes updates are tested by the dev team, and released
to testing before they make their way to the standard repositories. If
there are few people using the testing repositories and identifying any
issues that arise, …
Another difficulty with these issues is that they were not systematic
or easily reproducible. Of course, users often feel that if an issue
affects them it must affect every one - you can see this with
complaint about the installer, or networking, being broken.
I dont underestimate how bad this could be - I had to completely change
my configuration and usage to try to mitigate the problems.
But I knew that it was an issue that did not affect every user - not
even every user who had the same hardware that I had.
(Interesting - I recently broke out one of my old machines, installed a
new fan, new paste, and a new SSD, clean install 4.1 and updated it to a
combination that I had identified as “broken” - no problem at all.)
What can we learn? We need more users prepared to test templates before
final release, and more users using the testing repositories,
identifying problems in normal use, and giving feedback.
That’s the way to make Qubes be the best operating system it can be.
@kbxyyefmllxixxeyxn Thanks for raising the profile.
Thought I should follow up on my last post with my experience. The expected reset early October in 4.1 did not happen, and I presume that was due to my moving a few qubes over to 4.2 and relieving memory pressure. I do acknowledge that qmemman was much improved in 4.1 (much less likely to get the dreaded “insufficient memory to start …”). Perhaps related? To me it seems that testing in a memory constrained environment is only cursory. If one is seriously trying to work in such an environment then a means of setting swap space per qube is necessary, and my request years ago for a setting on the advanced tab was ignored.
I have completed migration to 4.2 and have had one of those surprise resets so far, however it is alpha software, and so not unexpected. It was actually an instant shutdown while AFK and system mostly idle (last in journal cron hourly successfully completed) - not memory constrained.
Perhaps there should be a thread here solely dedicated to logging just these sort of surprises that are very difficult to attribute and so not able to be recorded as a formal issue. Too easy just to blame the hardware. They do seem to happen quite often since 4.1.
Could you give a link to the Issue?
Hmm github search appears broken…
Perhaps I should not say ignored, initially so, then some discussion on technical issues after I had one of the unpleasant surprises on an upgrade, and left open:
https://github.com/QubesOS/qubes-issues/issues/4880
Oddly adw recently took it off 4.2 without comment. Guess it is less of an issue?
I do remember looking at freeze, crash, reboot thread a while back but was staying away. Stopped posting bug issues too as adw seemed more antagonistic than usual, and I needed to get up to date to file when I was getting allergic to updates (unless the QSB looked important and relevant).
[ed] Perhaps it was the custom swap settings I was running in all qubes in 4.1 that was causing my problem. Decided to just put up with it.
No. That is just housekeeping. See here for details:
This comes as a surprise to me. I’ve just checked all of the issues you’ve opened, and I don’t see anything on them from me that seems even remotely antagonistic, but I invite you and others to perform the same check to eliminate any bias.
I’m guessing it was probably just a miscommunication or misunderstanding. I try to enforce a consistent set of policies to make the issue tracker a useful tool for the developers. Sometimes, this entails doing things like closing issues and pointing out when issues are problematic. I have a set of canned messages that I use to explain these situations and actions so that everyone is on the same page about what is happening and why, and so that people understand how they can appeal the decision if they disagree. Sometimes, people still take it personally, e.g., when their issues are closed or problems are pointed out. I’ll look into modifying and further softening the language in these canned messages to avoid misunderstandings in the future.
Hello there, I have updated to Qubes 4.2 on my T430 and my X230 yesterday and it has gone smoothly so far. Since I use salt for basically everything my Computers where on heavy duty for the last day and I neither had kernel freezes nor crashes so for. If something, the resource management has improved and on at least my T430. Is is heating up less since the upgrade.
On 4.1 I had at least for some time regular crashes and freezes especially when using salt. So far things are fine for me.
I am quite happy with 4.2 performance so far. I am using kernel latest, on my thinkpad x230 i7-2520M CPU hardware. Haven’t had freezes. Quite stable.