Aiwendil

You can set most KDE menus to show the "Comment" key of the .desktop files instead of the "Name" key. So "KDE Advanced Text Editor" instead of "Kate".

Packages can come with several "programs" that aren't necessarily named the same as the package. Example: Calibre installs menu items for "Calibre", "EBookViewer" and "EBookEditor" on my distro.

It's not about forgetting...it' about helping to quickly find what you just installed and what is all included.

I was wondering too why anyone would ever want this...but the proposal explains it:

Support for UEFI on MBR was originally added in blivet#764 to accommodate cloud image use cases, such as AWS, which at the time did not support UEFI booting on GPT disks. These constraints no longer apply to modern cloud platforms, making MBR-based UEFI setups unnecessary for current Fedora deployments.

So basically it was some workaround a few years ago. I have a hard time to see any reason speaking against the removal.

On-screen keyboard was already mentioned, but there are some other small things that might be useful for some:

Reboot/shutdown without having to login (Your husband/wife/partner can shutdown your computer without first having to login and be greeted by the porn folder on your desktop...nah seriously, this can be useful at times when your turn on the computer, get called away and someone else can easily shut down the computer after you didn't return for some hours)

Keyboard language selection before password entry. Very useful in multi-language households/companies.

The WM selection also allows kiosk-like behaviour in special cases...like you don't start a WM but start in kodi media player for a movie evening or you create your own WM session file for a single game that runs as soon as you login.

It not being worth using is good, I want this malware practice to die.

Which is a noble goal in my view, I completely agree. But you will not be able to use anything like wine to achieve this...anti-cheat software is specifically designed to prevent all the things that wine does (For the reason that there is no technical difference between a "cheat program" and what wine does)

i’m sure there are already workarounds on windows, it’s not like cheating has been eliminated there

Actually I read about an interesting way a few months ago...on games that enabled linux support in their anti-cheat systems windows "cheats" started spoofing the OS signature to make the anti-cheat system think it runs on wine and turning of the kernel-level anticheat...

But as I said, the effectiveness of anit-cheat is a different discussion independent of the question if wine will support them. Even if anti-cheat systems are ineffective it doesn't change that they are mainly aimed at stopping exactly the kind of "trickery" wine does. Wine would have to play the same cat and mouse game with anti-cheat as cheats do...if it finds a away to work around them the anti-cheat systems need to find a way to prevent that workaround.

If it could the anti-cheat system wouldn't be worth using. Being able to "trick" the anti-cheat system into thinking something else is going on than actually happens is the same an actual "cheat" would do. That's why kernel level anti-cheat system go though a lot of trouble to detect any kind of virtualization or similar tricks...the moment you could trick them into accepting a fake kernel is also the moment that fake kernel can pretend the fake input it generates actually comes from a real mouse or the checksum of that openGL/vulkan library is exactly the one expected and not the one of some altered libraries that "accidentally" forget to not render stuff behind walls...

It's also something that needs to be kept in mind when talking about "Companies can just enable the linux support in their anti-cheat systems but they don't." While this is true of course it also means the kernel-level anti-cheat systems are bared from kernel-access and degraded to user-space only. And as people have access to the source-code of the linux kernel nothing is stopping anyone from just modifying the kernel to...give more "favorable results" while playing the game. Of course the linux playerbase it too tiny to really offer a market for such cheats...but it's not completely unreasonable to not want to erode the capabilities of your anti-cheat system (That is of course if you believe they work in the first place...but that's a different discussion).

Just to make this clear (Sorry if it's unnecessary, but maybe still useful info for others)...Path= lines in .desktop files are not related at all to the $PATH environment variables. They do something completely different (And yes, picking Path as key was a terrible choice in my view). Path= lines in .desktop files change the current working directory...they do about the same as a cd <directory> in a shell.

They do not change where a .desktop file looks for executables....only indirectly if a executable runs another file relative to the current directory or looks for images/icons/audio/other data relative to the current working directory.

And I have no clue why it doesn't work with TryExec...the desktop file spec doesn't mention anything about that :( ( https://specifications.freedesktop.org/desktop-entry-spec/latest/recognized-keys.html )

Try adding a PATH=/home/werecat/Grayjay line to your .desktop file. Without it the application will run with your home directory as your working-directory...and there the data files are missing (Why you need to copy them to your home). The path entry makes the program work in /home/werecat/Grayjay where the data directories actually are.

Edit: That is assuming when you started it manually you did a cd Grayjay and a ./Grayjay or similar. So you changed your working directory there first before starting it. If that is not the case ignore my post ;)

"Timber!"

I remember playing this some years ago...it was a lot of fun. Back then the "Atlantis" (I think...not sure, its been some years) campaign wasn't completely finished so maybe time to give it another shot :).

Obscure as in "only for a very specific purpose and nothing else"?...

Well, there is the Mircrosoft linux distro for their azure cloud

I guess DD-WRT as distro for router is also kind of obscure. Or the more general openWRT for embedded systems.

I imagine the "update from another system" path runs in troubles with more complex gentoo installs than just the base system. For a full update from the live disk it will have to include lots and lots of (often exotic) tools that might be used in the building process (document generators like doxgen, lexer, testing frameworks, several build systems and make-likes. programming languages...) in addition to being able to build against the already installed updates for packages while not accidental building against packages that are not updated yet.

Or you go the simpler way and only do a base update from the live-system...only update the base build system and package management of the gentoo system and afterwards boot in a "broken" system in which only the basics works and rebuild it from there.

For be both those options sound less desirable than what is suggested in the blog.

Cautionary

I settled with German because finding English took way longer than I care to admit ;)