> X.org architecture is inherently insecure - even if you run a desktop GUI application under a different user in your desktop session, e.g. using sudo and xhos

> X.org architecture is inherently insecure - even if you run a desktop GUI application under a different user in your desktop session, e.g. using sudo and xhost, then that "foreign" application can grab any input events and also make screenshots of the entire screen. I don't know of any system that doesn't involve some method of running software in a VM where one could actually be reasonably secure even if the application itself was compromised. Through Mac Windows and Linux land the only way to be semi secure and the one that has mostly worked for decades is don't install malware and make it easier to install legit software by installing by default from trusted sources not random websites. A LOT of work remains to be done on the entire landscape of desktop software to change that and it remains largely undone. If this was disqualifying you would just have to give up on PCs entirely. How about > X.org has no means of providing a tear-free experience, it's only available if you're running a compositing window manager in the OpenGL mode with vsync-to-blank enabled. There is no way to do ___ except foo which is what everyone is doing. Alrighty then. > No true safe mode for the X.org server Safe mode is called a console, ssh, or at last resort mounting it in a chroot. If this seems complicated it could trivially be automated up to the point where rescue was available by plugging in a USB drive and waiting for it to chroot AND start X giving you graphical configuration or the option to reinstall and keep existing programs and files. The problem with this getting done is the manual method works fine for most of the people who actually use Linux now. > HiDPI support is often a huge issue (many older applications don't scale at all). This isn't my experience AT ALL. Most applications are created with toolkits like GTK and QT running recent distros and setting a few env vars seems sufficient to get everything working swimmingly. What sort of applications in 2021 still have scaling issues? > ! Fast user-switching (and also concurrent users' sessions) under X.org works very badly and is implemented as a dirty hack: for every user a new X.org server is started. The author doesn't understand what the term dirty hack means. Multiple concurrent users worked fine in 2003 and continues to work fine. > It's possible to login twice under the same account while not being able to run many applications due to errors caused by concurrent access to the same files. At your login screen if you choose an already logged in user you will only be able to select unlock not create a new session. If you manage to work around that. For example switching to a tty and starting X that is really on you. > 1) Concurrently logged in users cannot access the same USB flash drive(s). This is in theory fixable but its harder than it seems. Files need to be mounted belonging to usersname:users instead of username:username and new files have to be created readable and writable by usersname:users which in fact would actually be sub-optimal for cases in which user accounts were intended to be an actual security boundary. The more secure default would be to simply unmount the usb drive, switch users, then mount it. Honestly though how often do 2 users on the same machine need to access the same removable storage at the same time? A more realistic issue is an external hard drive on which multimedia files are stored. Many machines have fairly anemic ssd storage that is insufficient for much multimedia and would be likely to be used with an external usb drive. However it seems likely that most users are moving away from large multimedia collections on disk and away from shared PCs so this realistically probably effects fewer and fewer people. > Keyboard handling in X.org is broken by design - when you have a pop up or an open menu, global keyboard shortcuts/ keybindings don't (GTK) work (QT). Answer the pop up and continue working > X.org does not support different scaling modes for different monitors. This seems to work on my mixed DPI configuration. > X.org server currently has no means of permanently storing and restoring settings changed by the user (xrender settings, Xv settings, etc.). NVIDIA and ATI proprietary drivers both employ custom utilities for this purpose. I'm not seeing why this is an issue for practical purposes I think the desktop environment provided utilities just stave and restore your settings from somewhere in ~/.config/ If you want to save global settings there is a configuration file in /etc for that. Should you not want to muck around with that nvidia-settings lets you use the handy graphical configuration and write out your present settings to the desired location. This has worked 2003-2021. How should this be handled either approach seems functional