I’ve found Shotcut to be more stable than Kdenlive. Tho I haven’t tried the latest kdenlive yet. Both have glaxnimate support so motion graphics is possible with both.
If Debian Stable supports your hardware, go for it. If not, try Debian Sid, but it won’t be as stable. You can install up-to-date applications, like Steam, using flatpaks in any case.
Even if you opt for stable and there’s an update that you may take advantage from, you can always update your kernel in several ways or change to Debian Sid (unstable), but you can’t go back unless you change to Debian Testing and then wait the freeze of Testing which then becomes Debian Stable.
That page is a pain to read on mobile. I copied the main part of the announcement here for readability.
The Wine development release 9.0-rc1 is now available.
This is the first release candidate for the upcoming Wine 9.0. It marks the beginning of the yearly code freeze period. Please give this release a good testing and report any issue that you find, to help us make the final 9.0 as good as possible.
What’s new in this release:
Bundled vkd3d upgraded to version 1.10.
Support for DH encryption keys with a recent GnuTLS.
Only issue is they’re stored in my server as belonging to the server user (I assume everything in those directories should belong to root and I can just use chown?) But I also don’t know if they retain the same permissions when backed up.
Not everything will be owned by root, and some of the binaries will be setuid or setgid, some might even have extended attributes (e.g. ping will usually have a security.capability attribute). /var will also have a lot of different owners.
I did a similar fucky-wucky before and honestly i just cut my losses and backed up the user data before reinstalling the OS from scratch. Took a few days of tinkering to get my system back to where it was but there’s no telling what kind of system you’ll be left with when you merge a known good image with a broken system.
DVI should not control the monitor’s actual physical controls - it does include a small non-display channel but IIRC that’s used to get the display modes info from the monitor, and potentially to transmit contrast information and the like; some monitors will prevent you from adjusting contrast if DVI sends that info for example, but it certainly shouldn’t disable the power button.
My guess would be a hardware issue - in the monitor itself - which is somehow triggered by the sequence in which you do enable the displays, and your system update being unrelated. It’s a huge guess though. One thing to try is repeating both sequences (the one that locks your buttons and the one that doesn’t) using a live CD - not a “nobara 38” one if such a thing exists, another distro. Trying both monitors on another computer would be an interesting test as well, although not necessarily that helpful (because if it doesn’t occur there, it might just mean the issue is triggered by peculiarities in your graphic card).
So I decided to bite the bullet and did a fresh install of Fedora 39 and that appeared to have made the issue go away. In the process of installing updates and configuring it the way I like, the monitor control buttons on both monitors response. So, it seems like the cause of the issue could have been a glitch during an update. Who knows? At least I know that it’s not a hardware issue (cross finders). :)
At the end of the day, the distribution is not that important for gaming, unless you need those 1-2 extra fps. Debian is a very good choice for workstations nowadays. I was a long time OpenSUSE user, always had joys with Debian, but yesterday switched to Garuda Linux (Arch variant optimized for gaming) and I love it so far very much.
Really looking forward to this release! Good stuff, another (minor) possible improvement for wine would be native pipewire support. But this is definitely more interesting
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.