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.

Bazzite. Here’s why:

• Optimised for gaming (gaming optimised kernel, common tweaks pre-applied, all common gaming apps pre-installed like Steam, Mangohud etc)
• All necessary drivers pre-installed (game controllers, RGB, and even proprietary nVidia)
• A Steam-Deck like gaming experience, if you want (the Deck variant boots directly to Steam)
• Immutable and atomic (image-based OS updates, so updates either work or don’t - there’s no chance of a broken state)
• Easy rollbacks (just select the previous image in the GRUB menu)

But since you said:

how to squeeze the best performance out of this

and if you’re really serious about squeezing the best performance, then check out the Arch-based CachyOS - unlike most other Linux distros, Cachy has optimised x86-64-v3 and v4 packages in their repos, which means apps can make use of advanced CPU instructions such as SSE3, AVX512 etc. Most other Linux distros on the other hand still use x86-64-v1 for compatibility reasons, which unfortunately means that you’d be missing out on all the cool new optimised CPU instructions introduced over the past 16 years.

You can read more about microarchitecture levels (aka MARCH) here: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

In addition to the MARCH, Cachy’s packages have other optimisations such as LTO/PGO, optimised kernel with the BORE and Rusty schedulers which are better for gaming, plus several performance-oriented tweaks which you’d otherwise have to do manually on Arch (such as makepkg.conf tweaks, pacman.conf tweaks etc).

Finally, Cachy are always on the bleeding edge when it comes to gaming/driver/kernel/performance related stuff, so you’ll get all the good stuff even before Bazzite or other optimised distros. For instance, Cachy was the first distro to include the new nVidia driver which has explicit sync support for better Wayland compatibility, and they’re always on top of major Arch developments and provide detailed announcements which are relevant to gamers and performance freaks.

Eg, here’s their recent recent nVidia announcement:

Hi @here,

as you maybe noticed, we have rolled out the new NVIDIA Driver, which includes the explicit sync protocol and tearing for Vulkan. We have been prioritized to move this forward to finally resolve the wayland situation. Additionally arch has pushed CUDA to 12.5, which is NOT compatible with the current 550 driver (it needs the 555 Driver).

The beta driver is not perfect, but so far we are applying some fixes to avoid issues and restore performance problems with disabling the GSP Firmware load. This is handled via the “cachyos-settings” package.

Anyways, since some people maybe have problems with this driver, here is a short instruction to manually downgrade and block the driver:

[…]

If you are facing issues with the new NVIDIA Driver, reproduce the issues and then run “sudo nvidia-bugreport.sh” and report it to their forum: https://forums.developer.nvidia.com/c/gpu-graphics/linux/148

We are also shipping now an precompiled nvidia-open module. This will be also as default installed for users, which have supported cards as soon NVIDIA releases the 560 drivers.

The CachyOS Team

So as you can see, they’re pretty on to it with this sorta stuff.

Now the Bazzite team are also like the Cachy guys and keep up with this stuff, but because they’re based on Fedora, they can’t be as bleeding edge or as optimised as Arch. So it’s up to you - if you prefer stability, a primarily gaming-focused optimisations, and want something that “just works” then get Bazzite; or if you want an ultra-optimised distro to squeeze out the most performance out of your box but also don’t mind ocassionally diving into the terminal and getting your hands dirty, then get CachyOS.

cc: @01189998819991197253@infosec.pub

The best option is to just support the developer/project by the method they prefer the most (ko-fi/patreon/crypto/beer/t-shirts etc).

If the project doesn’t accept any donations but accepts code contributions instead (or you want to develop something that doesn’t exist), you can directly hire a freelancer to work on what you want, from sites like freelancer.com.

That’s a shame. I hope someone continues a fork and calls it Shinyaku Toaru.

I am not a fan because they install all that WINE stuff on the system level which is a huge security degradation.

I disagree with this. Sure, it could be made more secure, but Wine, on it’s own isn’t, any greater security risk compared to any other scripting runtime such as say Python, which is also installed at the system level. Ultimately it’s up to the user to get their executables from trustworthy sources - and whether it’s a random bash script or an exe, doesn’t really make a difference.

As for Firefox, if you’re truly concerned about security then you wouldn’t be using it in the first place, you’d be using Librewolf, which you can install without any issues.

I am! I run it both on my gaming PC and laptop.

But it doesn’t seem like a “typical” distro for a daily driver? How does Bazzite for example differ from Nobara which is another gaming-oriented distro?

Well, for starters, if you get the Bazzite-deck edition, your PC boots straight into Steam’s game mode - in this mode, everything runs thru gamescope so you get all the awesome benefits like being able to use FSR even with games that don’t support it, HDR and more. You get a console-like experience on PC, and it’s awesome.

Another cool thing about this mode is that all your updates - including OS, Flatpak, firmware/BIOS, container, Nix, pip etc - all of it is presented as if it’s a Steam update like in SteamOS - and it’s automatic too, and it doesn’t interrupt your gaming experience. Basically a unified update backend and frontend, which is awesome.

Compared to Fedora/Nobara, one advantage this has is that the updates are image based and atomic, so when you reboot, the new update goes live instantly so there’s no wait-time. Another advantage is that your previous image is available in the GRUB menu, so in case the update broke something, you can always boot from the previous image - no need to even restore anything, no need to edit your fstab etc (unlike btrfs snapshot restores where the subvolid changes). And you can also pin “good” images to your GRUB menu (and I highly recommend doing that), so you can always fall back to a known good version. This came in handy on my laptop recently where after one of the Feb updates I was experiencing some weird graphics corruption in game mode, but thanks to image pinning I always had a working image to fall back to. Also, the rebase feature allows you to go back and forth between 90 days of images (stored on github), so it’s easy to switch between various versions for testing. The rebase is also interesting because with just a single command you can switch between any other Fedora Atomic distro, so if you’re bored of Bazzite or you want to try out a new DE, it’s just one command to switch. And with pinning, you can always switch back instantly.

Finally, there’s the whole immutability aspect. Personally I’m ambivalent on this, but the fact that it allows image/atomic updates (with easy rollbacks/rebases), I think of it more as a convenience - especially on a gaming-oriented machine, where I just wanna jump straight into my games without worrying about updates and broken systems.

So having used Fedora, Nobara, and finally Bazzite, I can highly recommend Bazzite as a daily driver - and it’s 100% worth switching. AMA.

This is my my phone running Debian with XFCE:

I’m a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:

Usability issues

GearLever solves all the problems mentioned.

Updates

There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.

The lack of repositories
Appimages don’t even have a central place where you can find them, not to mention download them.

This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.

Lack of Sandboxing

That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would’ve at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.

Random location
[…] A necessary step would be mounting the entire /home non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?

There would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.

I completely disagree with making the entirety of /home as non-executable, when $HOME/.local/bin is recommended by the XDG standard as a place to store executables. As long as $HOME/.local/bin is in the XDG spec, I’ll continue storing my executables there. If you disagree, go argue with the XDG guys.

Duplicated libraries

This is a fair point but “they include all the libraries they need” is the entire point of AppImage - so mentioning this is pointless.

If users would really install every Software as Appimages, they would waste insane amounts of storage space.

Then it’s a good thing that they don’t right? What’s the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn’t really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn’t be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn’t be using Flatpaks either.

Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don’t even need to do anything special to get AppImages integrated nicely in your system, and there’s nothing stopping other distros adding these packages as optional dependencies - but it’s kinda moot at this point I guess since Flatpak has already won the war.

Personally, I’m pro-choice. If AppImage doesn’t work for you, then don’t use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it’ll die a natural death and you don’t have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution…

Yep. I ran it on my 450MHz Pentium III back in the day - was incredibly fast and felt so ahead of it’s time, especially it’s multimedia and multitasking performance, as well as the fast boot speeds. It was my second favorite OS back then.

Nice writeup!

Only thing is:

If you decided to do that, you have to reboot each time you install something, which obviously sucks!

You don’t have to reboot if you use the --apply-live switch, but of course, you’d still need to reboot for something like a kernel update. And of course, I wouldn’t recommend layering packages either, unless there’s no other alternative.

It’s already a reality: https://www.unihertz.com/collections/jelly-series

My only issue is that it’s not Snapdragon and not quite dev/root friendly, but otherwise it ticks all the boxes - including a 3.5mm jack and an IR Blaster!

Um… that’s NOT a refusal, it’s just a warning. Clicking on that highlighted button will save the DOCX.

To not get the warning again, all you have to do is untick the checkbox which says “ask when not saving on ODF” - it’s there right in your screenshot.

Firstly, there’s no guarantee that a document would look exactly the same even within different versions of MS Office itself. Also, try opening any complex document in MS Office on macOS for instance, and you’ll most likely notice issues or differences compared to the Windows version. In my old sysadmin job, where I used a Mac, we had a standard “change control” template that we had to fill out when doing infrastructure changes, and the radio buttons used in the form didn’t work on the macOS version of Office. So issues like this are pretty common. These sort of issues are why people either normally ignore them OR in the case that layout/formatting is critical (eg: for publishing/printing), then they’d use PDF or TeX or similar formats, where the formatting is preserved.

Secondly, as @cygnus@lemmy.ca mentioned, use OnlyOffice if MSO compatibility is important. Below is a screenshot I captured of a recreated Lorem Ipsum docx on my Linux machine, with MS Office Online (running on Edge) on the left and OnlyOffice on the right.

As you can see, they’re virtually identical - and any difference in the sizing etc would come down to the fact that I’m running the web version of MSO, so the zoom/scaling may not exactly match that of OO. But other than that, if you check the spacing and everything else, it’s pretty accurate.

Finally, in saying that, even OO has it’s limitations and isn’t a 100% replacement for MSO - as it can’t run macros, or may not be able to display certain types of embedded objects in Excel and so on. But then, even the web and Mac versions of MS Office has these sort of limitations. But the average home user wouldn’t normally use macros or advanced features in Office, so for the most part, OO, or even LO should be fine for most users.

Also, just as a reminder, in this thread we’re discussing about how Linux can work fine for most home users, the kind of users who have simple requirements, and aren’t dependent on specific proprietary programs like Photoshop etc. Obviously Linux will not be suitable for every single need or use case out there, but neither is Windows or MacOS - if you have special needs or requirements, then use the tool that’s best for the job. But nitpicking minor differences like this isn’t helping anyone, we’d be sitting here arguing all day about how “X OS sucks because it can’t do Y”, which is a pointless exercise.

Edit: I was curious to see how bad LibreOffice actually was so I just tested it out:

… and that was surprisingly not bad at all! Just one word out of place. But this goes to show how opensource software is ever evolving and constantly improving - so a particular criticisms you may have had in the past may no longer be applicable, unless you test it out yourself against the latest versions.