On Mon, Oct 11, 2021 at 02:59:35PM +0200, local10 wrote: > Am considering upgrading from buster to bullseye and looking for some > feedback from those who have already done so. Was it worth it, in your > opinion? Anything you like in particular about bullseye? Any problems/issues > or degradation of performance/functionality/features, especially related to > the KDE and its apps?
You mention KDE. So, let me share this little story with you. We (i.e. my employer) have some Debian workstations that are set up to run a commercial data review/analysis software suite. The vendor of this particular software suite started out on HP-UX, and later migrated their support platform to Linux. They use a variant of CentOS, and they use KDE. I set up some Debian 9 (the stable version at that time) workstations, and managed to get them up and running the vendor's software suite. Since the vendor used KDE on their supported workstations, I used KDE as well, in order to minimize confusion for the users. The workflow model was pretty straightforward: data were collected by one data acquisition system (running the vendor's Linux variant), and reviewed by trained users sitting at the data review workstations (running Debian 9). Then the pandemic happened. Did I mention that this is *medical* data? It's medical data. The users are physicians, or highly trained medical specialists. So, in the early stages of the Covid-19 pandemic, access to the physical workstations was severely limited. People were not allowed to come to work in person except in special cases (e.g. the people who actually guide the patient into the room, hook up the electrodes, etc.). All of the people who were supposed to review the data were stuck working from home. Skipping over a *whole* lot of detail, what we ended up doing was setting up a VNC server on each of the data review workstations. The users who are reviewing the data from home connect to that, and run the vendor's software suite inside a VNC session. The problems did not start immediately. Periodically, for reasons I could not initially pinpoint, one of the VNC sessions would simply stop working. Stopping and restarting it did not help. The only thing I could do was reboot the entire workstation. After several months of this, running every command I could think of, doing Google searches, etc., this is what I came up with: It seems that when KDE's SDDM (display manager) locks the screen, and a user unlocks the screen, there are two different things that can happen. Either the screen unlocks normally, and the user resumes their KDE session; or, SDDM launches a whole *new* KDE session, and now the user is logged in twice. So, as near as I can tell, every once in a while (increasingly often as users were allowed back on site), someone would sit down at one of the workstatiosn, try to unlock the screen, and would be thrown into a whole new session. They would be logged in twice on the console, and running two different X sessions, one on display :0, and the other on display :1. Sometimes this would show up in "who" output. and sometimes it wouldn't. Sometimes I'd see a /tmp/.X11-unix/X1 socket owned by root instead of the VNC session's user. Sometimes I wouldn't. Whenever this happened, the VNC session that was trying to use display :1 would fail. Only rebooting would fix it. My Google searches told me that this was considered a "feature" in SDDM, but was annoying for many people, because they kept tripping it accidentally. For them, it wasn't a disaster -- they would be logged in twice, and they'd struggle to figure out that they could get back to their original session by hitting Ctrl-Alt-F7 or whatever. For *us*, it meant someone was completely locked out, and I had to intervene to fix it. This was more than simply annoying. As it turns out, there's a configuration option to control this feature in SDDM. But only in *new* versions of SDDM. It didn't exist in the version shipped with Debian 9. And it didn't exist in the version of SDDM shipped with Debian 10 either. Apparently it *does* exist in the version shipped with Debian 11, but it's undocumented. It's also supposedly enabled (fixed) by default. So, the point of all this is that upgrading to Debian 11 helped us work around a major design flaw in SDDM (KDE's display manager). It hasn't caused me any problems yet (although having to rework NIS was a small hassle). As always, please read the release notes, and also check <https://wiki.debian.org/NewInBullseye> for the latest set of known issues reported by the user community.
