d3Xt3r

joined 1 year ago
MODERATOR OF
[–] d3Xt3r@lemmy.nz 1 points 5 months ago

I've disabled the "other" option now, someone hijacked the poll. Guess that's what I get for allowing users to add their own options. >_<

[–] d3Xt3r@lemmy.nz 1 points 5 months ago* (last edited 5 months ago)

Sorry about that - was just alerted to it. I've disabled the "other" option now. It was fine a few hours ago, looks like we have a sick troll here. :/

[–] d3Xt3r@lemmy.nz 5 points 5 months ago

Serenity for sure. I love the 90s aesthetic and would like to see it make a comeback. At the very least I'd like to see their Ladybird browser become mainstream - we really need more alternatives to the Chromium family.

[–] d3Xt3r@lemmy.nz 2 points 5 months ago* (last edited 5 months ago) (1 children)

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:

Component Process_KDE RAM_KDE Process_LXQt RAM_LXQt
WM kwin_x11 99 openbox 18
Terminal konsole 76 qterminal 75
File Manager Dolphin 135 pcmanfm-qt 80
File Archiver ark 122 Lxqt-archiver 73
Text Editor kwrite 121 featherpad 73
Image Viewer gwenview 129 lximage-qt 76
Document Viewer okular 128 qpdfview-qt6 51
Total 810 446

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".

[–] d3Xt3r@lemmy.nz 2 points 5 months ago

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 KDE VM was unsable when I disabled swap - it completely froze on me. Meanwhile, LXQt chugged on just fine. Of

Of course, I could get rid of some bloat like akonadi, so I did that and rebooted my machine. Then I compared just the essential components, but I excluded plasmashell because it includes stuff like the panel and notifications, unlike LXQt where they're all separate components so you can't really compare them:

Component Process_KDE RAM_KDE Process_LXQt RAM_LXQt
WM kwin_x11 99 openbox 18
Terminal konsole 76 qterminal 75
File Manager Dolphin 135 pcmanfm-qt 80
File Archiver ark 122 Lxqt-archiver 73
Text Editor kwrite 121 featherpad 73
Image Viewer gwenview 129 lximage-qt 76
Document Viewer okular 128 qpdfview-qt6 51
Total 810 446

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

[–] d3Xt3r@lemmy.nz 8 points 5 months ago* (last edited 5 months ago) (3 children)

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.

[–] d3Xt3r@lemmy.nz 7 points 5 months ago* (last edited 5 months ago) (6 children)

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.

[–] d3Xt3r@lemmy.nz 11 points 5 months ago* (last edited 5 months ago) (11 children)

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.

[–] d3Xt3r@lemmy.nz 12 points 5 months ago (15 children)

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?

[–] d3Xt3r@lemmy.nz 6 points 5 months ago (1 children)

You should still have the previous package in your cache right? If so, extract that and the current package, and then compare the two folders to see what's changed - meld is a good tool for that.

[–] d3Xt3r@lemmy.nz 15 points 5 months ago* (last edited 5 months ago)

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.

[–] d3Xt3r@lemmy.nz 65 points 5 months ago* (last edited 5 months ago) (11 children)

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.

 

Ventoy is an open source tool to create bootable USB drives for ISO/IMG/VHD(x)/WIM/EFI files. With Ventoy, you don't need to format the disk over and over, you just need to copy the disk images to the USB drive and boot them directly. You can have multiple images on the disk and Ventoy will give you a boot menu to select them.

Changelog for 1.0.98

  1. Updated EFI boot files.
  2. Fix the issue that can not recognize Ext4 filesytem created with latest gparted.
  3. Fix the issue that VTOY_LINUX_REMOUNT=1 cannot take effect in RHEL9/CentOS9. (#2827)
  4. Fix the boot issue for latest archlinux. (#2825 #2824)
  5. Fix the boot issue for latest KAOS.
  6. languages.json updated.
  7. vtoyboot-1.0.35 released. Notes
 

Sadly, DNF5 and the new Anaconda installer didn't make it to the party, in case you were wondering.

84
submitted 7 months ago* (last edited 7 months ago) by d3Xt3r@lemmy.nz to c/linux@lemmy.ml
 

The main issue is the handling of security updates within the Nixpkgs ecosystem, which relies on Nix's CI system, Hydra, to test and build packages. Due to the extensive number of packages in the Nixpkgs repository, the process can be slow, causing delays in the release of updates. As an example, the updated xz 5.4.6 package took nearly 5 days to become available in the unstable branch!

Fundamentally, there needs to be a change in how security fixes are handled in Hydra. As stated in the article, Nix was lucky to be unaffected, but multiple days to push out a security patch of this severity is concerning, even if there was no reason for concern.

 

Winlator is an Android application that lets you run Windows (x86_64) games and applications using Wine and Box86/Box64.

Version 6.0 Changelog:

  • Added Magnifier
  • Added option to add Wallpaper
  • Improved UI
  • Fixed Container startup error that occurred on some devices
  • Improved XInput compatibility
  • Improved Input Controls and Cursor sensitivity
  • Added support for external mouse
  • Updated Wine, Box86/Box64, Turnip and DXVK
  • Added "Bring to Front" on Task Manager
  • Added 7-Zip on context menu
  • Removed the option to install OBB image (now it's all in one apk)
  • Performance improvements and other fixes
 

Can we get some icons for c/support and c/wellington please?

This is triggering my OCD:

Thanks!

 

#Edit: This has been resolved now.


For those of you who've been using the Steam Deck variant of Bazzite on desktops/HTPCs with AMD GPUs - beware that currently there's a bug affecting (some?) users, where the GPU's TDP is capped to just 15W!

You can check your settings by running a tool like LACT (ujust install-lact):

As you can see, LACT shows the current limit is 15W, but it can actually go upto 280W on my card.

A bug report for this was opened last year, but it was closed as fixed, but at least one other user (besides me) has been experiencing it - so check your wattage, you might be affected too!

At the moment there are no actual fixes - but you can try the workaround posted in the original bug report. Also, using tools like LACT or corectrl isn't a fix unfortunately, because as soon as you go into game mode (or reboot), the limit resets back to 15W. I'm currently troubleshooting this with a couple of the developers, and hopefully we may get to bottom of this soon.

As for the performance impact - here's a screenshot of Last Epoch running at a glorious 4 FPS, thanks to the caps:

 

Wayfire is a 3D Wayland compositor, inspired by Compiz and based on wlroots. It aims to create a customizable, extendable and lightweight environment without sacrificing its appearance.

v0.8.1 is a bug-fix release with a few new features. Notable changes:

  • Compatible with wlroots 0.17.x releases and wf-config 0.8.x

  • Support for multiple new protocols:

    • shortcuts-inhibit-v1 (shotcuts-inhibit plugin, #1969)
    • fractional-scale-v1
    • wlr_drm_lease_v1 for non-desktop outputs
    • input-method-v1 for better fcitx5 support (#2172).
  • Wayfire's IPC has been extended with many new signals and commands:

    • Has methods to get view, output and workspace (and workspace-set) information
    • Signals for view-mapped, unmapped, plugin-activation-state-changed and several others.
    • More plugins can be activated via the IPC, check the full commit log for details.
  • Wayfire supports SIGINT, SIGTERM for graceful shutdown (#2056, #2197)

  • Oswitch has binding to switch in the other direction (#2072)

  • Many crashes and bugs were fixed, including regressions in the 0.8.0 release.

 

With the release of mkinitcpio v38, several hooks previously provided by Arch packages have been moved to the mkinitcpio upstream project. The hooks are: systemd, udev, encrypt, sd-encrypt, lvm2 and mdadm_udev.

To ensure no breakage of users' setup occurs, temporary conflicts have been introduced into the respective packages to prevent installing packages that are no longer compatible.

The following packages needs to be upgraded together:

  • mkinitcpio 38-3
  • systemd 255.4-2
  • lvm2 2.03.23-3
  • mdadm 4.3-2
  • cryptsetup 2.7.0-3

Please note that the mkinitcpio flag --microcode, and the microcode option in the preset files, has been deprecated in favour of a new microcode hook. This also allows you to drop the microcode initrd lines from your boot configuration as they are now packed together with the main initramfs image.

21
Incus 0.6 has been released (discuss.linuxcontainers.org)
submitted 8 months ago* (last edited 8 months ago) by d3Xt3r@lemmy.nz to c/opensource@lemmy.ml
 

Incus, a community-managed fork of LXD (container and VM manager), has been updated to v0.6.

New features:

  • Clustered LVM storage driver

  • Storage bucket backup and import

  • Listing images across all projects

  • Mounting binfmt_misc filesystems inside of unprivileged containers

  • Control over shared block storage volumes

  • OVN logical router name in network info

  • File ownership and permissions in image templates

  • Encrypted EC client certificate keys

  • lxd-to-incus improvements:

    • Support for Void Linux
    • Detection of the boot.debug_edk2 configuration key
    • Handling of OVN SSL database connections
    • Automatic clearing of the simplestreams cache during migration
56
submitted 9 months ago* (last edited 9 months ago) by d3Xt3r@lemmy.nz to c/opensource@lemmy.ml
 

In case you guys missed it - btop++ has had for GPU monitoring for a while now. However, it didn't work with AMD ROCm v6.0 until a few hours ago (v1.3.2)!

To get GPU monitoring to work, you'll need to compile btop with GPU support, or used a distro-provided package compiled with GPU support. Arch users for instance can use the btop-gpu-git package for this.

The other catch is that right now the monitoring options are pretty basic, so if you're really interested in proper GPU monitoring, you might want to stick with nvtop. But hopefully that changes in the near future now that btop has basic GPU support!

 

Anyone else remember Corel Linux?

 

kdotool uses KWin's scripting API to control windows. In each invocation, it generates a KWin script on-the-fly, loads it into KWin, runs it, and then deletes it, using KWin's DBus interface.

This program should work with both KDE 5 and the upcoming KDE 6.

view more: next ›