Speaking of “breaking away”, I spent most of the day yesterday re-building my problematic ThinkPad Helix unit. This time around, I put Kali 2022.2 on it (KDE Plasma for the display environment). It is running quite happily. Ironically, it was running Kali before I installed Rocky 8.4-8.5 on it. I was trying to get the machine on a more stable distribution (fixed rather than rolling). And I had already tried and failed with Debian and with Q4OS. Both of those distributions continue to exhibit issues with the display driver (Intel video, BTW). This is all a bit of a mystery to me because Kali is a Debian variant as well. I would expect it to show the same issues as Debian/Q4OS. But it doesn’t. What does THAT say about the state of things when fixed distributions like RHEL/Rocky/Debian/Q4OS won’t run properly, but a rolling distribution like Kali does run properly. The whole reason that I installed Rocky in the first place was to try to avoid a rolling distribution. Also, since many people cringe when someone mentions Kali Linux, you should know that I use a minimal install with few or none of the penetration testing tools installed. I have other machines that I can use if I want to play with those kinds of tools.
Reading that last message in the bug notes it says if P-PIDFD is supported then poll(pidfd) should be too but isn’t so RH only partly implemented some new functionality. No one can be expected to deal with the situation where you say you provide new functionality but omit a crucial part of the API for that functionality - it’s like shipping you a new car without axles. This is definitely a RH screw up that should be fixed by RH as a matter of urgency. Qt can’t be expected to mod their product to allow for RH not conforming to the rules.
This is a kernel change to fix a buggy kernel where the bug affects a lot of people - it’s no different in essence to a security patch.
EDIT
Apparently KDE/Qt didn’t change anything - they check at runtime and proceed based on what RH tells them. In this case RH told them they were getting a new Electric car but shipped then a diesel with a plug socket instead of a filler cap.
Yep, I agreed in my previous post, if it was there before then yes they should fix it.
It seems it wasn’t there before. It’s new but it’s broken new.
I presume the “P-PIDFD” is a feature that was backported from upstream kernel.
You have car that runs fine in summer conditions. You replace the motor oil to type that functions also in freezing conditions. Are you now good to go in Siberia, in -40C? No, your tires are still slicks, hopeless on ice. You A/C never had heating, etc. But, Qt only checks that engine is ok and therefore assumes that there is traction. The upstream car got tires, etc before the oil. That is why if car has “winter oil”, then it surely has the other necessities too. RHEL forgot to backport the whole winter setup?
No, a variation on my Electric/Diesel car is a more accurate analogy:
I trade in my diesel for a hybrid. (8.5 for 8.6)
When the new car arrives I look it over and find a charging socket and all the other external indications this is indeed a hybrid car (P-PIFD)
Not unreasonably I assume plugging it in will charge it and let me drive.
Alas, the socket isn’t connected to anything (poll()) and nothing happens.
I have a meeting 60 miles away, there are no gas stations on the way, the battery has no mileage and the fuel light is blinking.
Is this my fault ? no it’s the ****er who didn’t wire the socket. (EDIT) and knew the socket wasn’t wired and sent the car anyway.
I made that argument to myself as well. I’m running modern well-endowed hardware, and gave up on VMWare (and eventually got a refund) after they and I could not make it work.
My experience with VMWare was:
- Expensive
- Utterly incompetent technical support
- Unusable – to the point of fraudulent – ticketing and billing systems
I’ve been using VirtualBox since October of 2021 on my RL iron.
I plan to try kvm/qemu as soon as I get some headspace (and after I get my backup processes in place).
Hi
I do
I began with Red Hat 3 ti Red Hat 6.2
Then Fedora “core” 3 till now where I am on Fedora 29 after being working during about 10 years with Fedora 15
Also Centos since V. 5 till 8.5
And all tgis after some years of ms-dos 6 and W$ 3.
I continue to install new versions of Fedora but since I want stability, I stand on my 29.
Till I change my mind 
I run RL 8.5 on my workstation and dual boot Windows 7 and RL 8.5 on my travel / business laptop. I moved from CentOs to Rocky Linux when CentOs Stream came out. I’ve had a number of CentOs releases installed over the years, started with Red Hat before RHEL and Fedora. I have a second 500 Gb hard disk on my workstation where I also installed RL 8.5, I use this to test / try applications without risking any issues on my main installation. So far it works well. I may install RL 8.6 or 9 at some stage, but since 8.5 works and I can do what I need to do I stick to that.
Just done yum update to my RL 8.5 so now on 8.6 on my workstation and my dual boot Dell E7250 both works just fine.
Another Rocky desktop user here. Love it. No issues at al.
For the record, about two months ago I worked on a “pure KDE” version of Rocky without the whole GNOME kitchen sink (because I hate GNOME with a passion). Starting from a minimal installation, I installed X11 and a trimmed-down KDE with one application per task:
Before that I’ve been using OpenSUSE Leap KDE as my main desktop. But the idea was to have something similar with a real long term support.
Seeing that even a minor release causes breakage to the point where my whole setup has to be potty-trained again, I’m giving up on RHEL on the desktop and will only use it on my servers.
So back to OpenSUSE Leap again: Nicolas Kovacs / OpenSUSE Leap 15.4 KDE Setup · GitLab
Trivia Question: I’m using openSUSE 15.3 Leap while I try to get a handle on things such as WHY my Nvidia Drivers in RL 8.6 do not seem to work or WHY my resolution is confined to 1024x768 on a 1920x1080 monitor, and other annoying issues. You said that you are using openSUSE 15.4 Leap --??? When did 15.4 come out? or is it still in Beta? Does openSUSE simply rollover to the next point release like CentOS, RHEL, RL, et al. or does one have to do a fresh install as in the “Old Days”? Or is there some magic incantation that needs to be recited while sacrificing a goat to force it to rollover without having to do a complete reinstall???
I installed Leap 15.4RC1, which already identifies as 15.4 in /etc/os-release. Especially since the 15.3 release, Leap is a rather successful hybrid distribution with a stable enterprise-class base system with semi-rolling apps on top. Roughly once a year you can perform a dist-upgrade to the next version, which can be done without drama. It’s not exactly a trivial operation, but it’s way easier than upgrading, say, Slackware or FreeBSD. My workstation was initially a 15.1 install, and has been subsequently upgraded to 15.2, then 15.3. Some time soon I’ll upgrade it to 15.4.
I’ve just tested a little opensuse-upgrade.sh script that can upgrade Leap 15.0, 15.1, 15.2 or 15.3 directly to 15.4. This will give you a rough idea of how things are done here.
Cheers,
Niki
Thank you Niki. Rolling over CentOS/RHEL/Rocky Linux/et.al has spoiled me – dnf update is all it takes. When it works it’s a piece of cake – until it doesn’t work. I always backup my current setup just before I rollover the system in the event things blow up – then I simply rollback.
Trivia Question: I have 15.3 all tricked out which took some time to set up. When I “upgrade” 15.3 => 15.4, will it wipe out everything and rather unceremoniously deposit me back to Square 1? I have 10 Virtual Desktops (correction: now they are called “Activities” ) each with its own Wallpaper and sets of apps and / or widgets, with Custom Prompts in both BASH and ZSH. The idea of “upgrading” 15.3 => 15.4 only to find all that custom work wiped from the face of the Earth sends shivers down my spine.
I’m going pass this good advice onto my buddy who has vastly more experience with SUSE than I do. The difference between the way RH does things and oS does things is like night and day. It took me about 4 days of hacking to get oS installed my first time out of the gate. I have a Love / Hate relationship with openSUSE: I absolutely LOVE openSUSE once it is totally installed and up and running; I absolutely DETEST openSUSE the way they arrange things – it is very much like a Chinese Puzzle Box. When (open)SUSE is GOOD she is very, VERY GOOD (usually post install and finally configured); but when she is BAD (usually during the install) she is an absolute BITCH!!
D’ Cat
Very interesting. I am thinking about similar setup too.
Can elaborate more on the 4 virtual machine with 4 positions switch?
Do you use raspberrypi like device to serve as thin client or directly output the video to other position?
Whatcsort of issues didbu experience using dbf update
It’s been a long time, I don’t remember the specifics. I do remember that they went away when I replaced KDE/Plasma with gnome.
I’ve been impressed with how few issues I have with dnf update since that change. I run VirtualBox on my RL iron, and then I run a Windows 10 Pro guest VM on Virtual Box. I’ve had some minor issues during some VirtualBox upgrades, nothing serious.
I use the RL desktop only occasionally. In addition to VirtualBox, I use a premium SSH shell that I’m happy with from the RL desktop. I do all serious development on AWS EC2 instances, and I shell into them from my SSH client running on the RL desktop. I’ve configured VirtualBox to provide a shared virtual drive between the RL desktop and my Windows Guest VM.
My experience with RL is that it has been precisely the stable and robust platform I sought. I enjoy being able to spend nearly all my energy on whatever projects I’m working on with only very infrequent distractions from my local infrastructure.
Was that around 8.5 ? because the KDE issues are sorted for 8 since 8.6 (can’t say re 9).
Edit (correction) ;
8.6 introduced the KDE/Qt issues. They were fixed in 8.7
I run Rocky 8 as my desktop daily driver. About the only problem I have is that Firefox 102 is getting to be too old for a few of the sites I visit.