d3Xt3r

I'm not moving any goalposts. You're the one arguing about the semantics around "Plasma", and I keep saying that's irrelevant.

Refer back to my original comment which was, and I quote:

So, are there any plans to reduce the bloat in KDE, maybe even make a lightweight version (like LXQt) that’s suitable for older PCs with limited resources?

To clarify, here I was:

• Referring to KDE + default apps that are part of a typical KDE installation
• Stating that a typical KDE installation is bloated compared to a typical lightweight DE like LXQt
• Saying with the intention that the "bloat" is RELATIVE, with respect to a older PC with limited resources

The ENTIRE point of my argument was the KDE isn't really ideal RELATIVELY, for older PCs with limited resources, and I'm using LXQt here are a reference.

In a subsequent test, here's a direct apples-to-apples(ish) component comparison:

plasmashell was sitting at 250MB btw in this instance btw.

The numbers speak for themselves - no one in their right minds would consider KDE (or plasmashell, since you want to be pedantic) to be "light", in RELATION to an older PC with limited resources - which btw, was the premise of my entire argument. Of course KDE or plasmashell might be considered "light" on a modern system, but not an old PC with 2GB RAM. Whether something is considered light or bloated is always relative, and in this instance, it's obvious to anyone that KDE/plasmashell isn't "light".

You're arguing semantics and that's not the point I'm trying to argue here. Forget the term "Plasma". I don't really care about what the DE is branded as or what's in "Plasma" the software package. When I say "KDE", I mean the desktop + all the basic default/recommended apps that you'd see on a typical KDE installation, such as Dolphin, Konsole, Kate, Kalculator, Spectacle etc that's part of the KDE project. IDK whether the apps I've mentioned are considered part of "Plasma" or not, but again, that's not the point, I'm saying this is what I meant when I said "KDE" - and what most people would expect when they picture a "KDE" environment.

Anyways, I tested this myself on two identical VMs with 2GB RAM, one installed with Fedora 40 KDE, and another with Fedora 40 LXQt, both set to use X11 (because LXQt isn't Wayland ready yet), both updated and running the latest kernel 6.8.10-300.fc40. I logged into the DEs, opened only two terminal windows and nothing else, ran, and ran htop. The screenshot speaks for itself:

And when I tried disabling swap on both machines, the KDE machine was practically unusable, with only 53MB RAM remaining before it completely froze on me. Meanwhile, the LXQt one was still very much usable even without swap enabled.

I'd like to see you try running without swap and see how it fares. And if you think it's unfair disabling swap on a 2GB machine - try installing LXQt yourself, disable swap and see for yourself how much more usable it is compared to KDE.

And this is why I say KDE is bloated and not suitable for old machines.

Edit: Also, check out the memory consumption listed by a user in this post: https://lemmy.nz/comment/9070317

Edit2: Here's a screenshot of the top 30 processes on my test systems, side-by-side:

Of the above, I calculated the usage of the top 10 processes specific to each respective DE, and you can see that KDE's memory usage is almost double that of LXQt. Had I counted all the DE-specific processes, it'd no doubt be a lot more than double.

Correct me if I'm wrong, but this #OptGreen project isn't talking specifically about Plasma, is it? They don't mention Plasma anywhere on the page they linked.

In any case, that's irrelevant, also, I don't doubt that KDE can't run at all under the specs you mentioned - that's not the issue. The question is, how much free/usable RAM do you actually have on that machine - let's say with no apps open first, and with then check again with Konsole + Dolphin + KWrite/Kate open? And for fun, fire up Konqueror as well and check again.

Edit: Screenshots proving that what you're saying is not correct:

I'm not talking specifically about Plasma, I'm talking about the "DE" part of KDE in general; and particularly in this context of repurposing and extending the life of old PCs.

I find it a bit ironic for KDE to be pushing this message, when it's a heavy DE (relatively speaking) - it's NOT what anyone would have in mind when when selecting a DE for an old PC.

For instance, take LXQt - run the default/recommended file browser, terminal and text editor, and compare it with KDE + equivalents - you'd see a significant difference in resource consumption. On a system with low RAM, that extra bit of free memory makes a big difference, as it could mean avoiding the penalty hit of the swap file, which you'd invariably run into as soon as you fire up a modern Web browser. So it's vital that the DE use as little resources as possible on such a machine.

So, are there any plans to reduce the bloat in KDE, maybe even make a lightweight version (like LXQt) that's suitable for older PCs with limited resources?

The problem is that games don't run at all or require major effort to run without issues.

A major cause for that is the distro - when it comes to gaming, the distro makes a huge difference as I outlined previously. The second major cause is the flavor of Wine you chose (Proton-GE is the best, not sure what you used). The third major cause is checking whether or not the games are even compatible in the first place (via ProtonDB, Reddit etc) - you should do this BEFORE you recommend Linux to a gamer.

In saying all that, I've no idea about pirated stuff though, you're on your own on that one - Valve and the Wine developers obviously don't test against pirated copies, and you won't get much support from the community either.

Unfortunately you chose the wrong distro for your friend - Linux Mint isn't good for gaming - it uses an outdated kernel/drivers/other packages, which means you'll be missing out on all the performance improvements (and fixes) found in more up-to-date distros. Gaming on Linux is a very fast moving target, the landscape is changing at a rapid pace thanks to the development efforts of Valve and the community. So for gaming, you'd generally want to be on the latest kernel+mesa+wine stack.

Also, as you've experienced, on Mint you'd have to manually install things like Waydroid and other gaming software, which can be a PITA for newbies.

So instead, I'd highly recommend a gaming-oriented distro such as Nobara or Bazzite. Personally, I'm a big fan of Bazzite - it has everything you'd need for gaming out-of-the-box, and you can even get a console/Steam Deck-like experience, if you install the -deck variant. Also, because it's an immutable distro with atomic updates, it has a very low chance of breaking, and in the rare ocassion that an update has some issues - you can just select the previous image from the boot menu. So this would be pretty ideal for someone who's new to Linux, likes to game, and just wants stuff to work.

In saying that, getting games to run in Linux can be tricky sometimes, depending on the game. The general rule of thumb is: try running the game using Proton-GE, and if that fails, check Proton DB for any fixes/tweaks needed for that game - with this, you would never again have to spend hours on troubleshooting, unless you're playing some niche game that no one has tested before.

As an actual M1+Asahi user and a gamer: Asahi is not there yet. Right now, if you're on macOS, Crossover (or Porting Kit) and/or Parallels is able to run more games and with better performance compared to Asahi (using krun + FEX). Also, Steam on macOS (non-native) is much more peformant compared to Asahi, where it's currently slow and glitchy.

But that will all change in the future once the Vulkan driver and TSO patches are ready. FEX is also seeing a lot of improvements, so by the end of the year, there's a good chance that gaming on Asahi would be much better than macOS.

You can, if the laptop supports VLink/DP-in, such as the Minisforum V3.

This has nothing to do with Arch or Bazzite, it's actually a bug in recent kernels. Switching to Mint only fixed it for you because Mint uses an old kernel.

The fix/workaround is to enable "above 4G decoding" and "resizable BAR" in your BIOS. If your BIOS does not have these options, you can either downgrade to an earlier kernel (or OS image if you're on Bazzite), or switch to a patched kernel like the Cachy kernel.

Is that all? Will that remove all the traces of arch?

There will be some other minor dot files in your /home which you might want to review, like .bashrc, .bash_profile, .profile etc. These should be mostly harmless, but if you don't recall customising them, then yeah free to nuke all the dot files. Also be aware that some programs also leave their configs outside the .config folder, like Firefox might have a .mozilla folder, GTK programs might create a .themes folder, vim has .vim. So you might want to review and delete these as well, if you want a clean config.

As for the last step - just before you boot into your new distro, you might to get rid of the Arch/Endeavour entries from your ESP/UEFI. Run efibootmgr to see your current UEFI boot entries, then nuke the entries using efibootmgr --delete-bootnum -b #.

And to get rid of the GRUB configs, delete your <ESP>/EFI/grub folder. I'm guessing your /boot is on your root partition? If not then you'll also need to delete /boot/grub.

Now when you install your next distro, you should get a nice and clean GRUB install.

1. No
2. You'll need to delete your ~/.config, ~/.local, ~/.cache ( and maybe ~/.var, which is your Flatpak app data/cache). Might be best to rename your .config instead of outright deleting it, just in case you need to restore some old config.
3. It's been a while since I used Nobara, but IIRC it only creates the default @ and @home subvolumes.
4,5. Nobara should have Timeshift installed by default.

Honestly though, since you said that you want something that "just works" for gaming and coding, you should just get Bazzite. Bazzite is an immutable distro and everything is set up to work out-of-the-box. You never have to worry about broken updates again due to atomic updates and image rollbacks. You can directly boot from a previous image from GRUB (no need to restore it first), pin known good images to your GRUB, and even rollback to any previous image via the web (upto 90 days) - all with just a single command. And for coding, you can easily set up a Distrobox container to install all your tools and IDEs etc, it integrates well with the host OS so you won't even notice/care that it's inside a container.