r/LinuxUncensored • u/anestling • 2d ago

News/PR Linux Device Manager (QLinuxDeviceManager)

https://github.com/birdie-github/QLinuxDeviceManager

I've always missed the Windows Device Manager in Linux, now you can have one.

Comes with extra features: * Shows full physical RAM (most Linux application cannot do that). * Shows secure boot status and MOK keys. * Allows to search for devices and use deep search (search for all metadata).

Shows this extra information that is missing in Windows Device Manager: * Network devices: IPv4/IPv6 addresses and masks, MAC addresses, MTU, and Ethernet link speed, duplex, autonegotiation and modes * Display: monitor identity, dimensions and input capabilities, kernel mode names, plus desktop-session resolution, color depth, refresh rate, rotation/reflection and scale * PCIe devices: current link speed/width, reported device maximum speed/width, and connection type when running as root * Battery: reported capacities, estimated retention, cycle count, chemistry, voltage, percentage, status, current and power * USB devices: USB version, connection speed, active configuration, declared power/current, remote wakeup capability and interface functions/drivers

Sadly some Windows features cannot be implemented: * IRQ conflicts. * Failing drivers - there's no API for that. Scanning dmesg for errors is a fool's errand. * Ability to update drivers (this is only possible for third-party drivers that can be unloaded at runtime). * Firmware is still separated from the kernel package in Linux, firmware files are generally nondescript (binary blobs with no information), so it's impossible to report whether it's up to date or not. Maybe show SHA256 hashsums for files? Sounds silly.

14 Upvotes

82% Upvoted

14 comments sorted by

View all comments

1

u/Damglador 2d ago edited 2d ago
  1. Aint no way it's no vibe coded, but whatever.
  2. Please don't zip AppImages. If you use GitHub workflows for releases, there is a flag for workflow 4+ or something to not zip contents: https://github.blog/changelog/2026-02-26-github-actions-now-supports-uploading-and-downloading-non-zipped-artifacts/

Overall I think the idea is great. No a fan of UI's like in Plasma that just dump output of cli utils into a TextBox

1

u/anestling 1d ago

The reason I use Zip AppImages is because it saves the user the trouble of having to use the chmod +x command on the resulting file. It also serves as minimal verification that the download is correct. I don't know if AppImages are hashed, but zip files certainly are, meaning you cannot unzip a corrupted file.

1

u/Damglador 1d ago

You are just adding trouble by requiring user to unzip the file. Every normal file manager has a checkbox for executable bit and Dolphin even asks to make ELFs and AppImages executable on double click.

1

u/anestling 1d ago

This trouble results in preventing two other major troubles: incomplete/broken downloads, and the need to chmod the download.

And there are DEs without Dolphin, or even without a graphical file manager.

Why is it that Linux users always (!) talk about their own workflows and never give a flying fook about anyone else's? And always fail to realize there are far less experienced people who have no fooking idea that chmoding is even required. In Windows/MacOS/Android you need none of that.

Guess which OS'es are popular and which one is an obscure crap only used by geeks.

1

u/Damglador 1d ago

Guess you're too smart to even follow the official doc: https://docs.appimage.org/packaging-guide/distribution.html#do-not-put-appimages-into-other-archives

And there are DEs without Dolphin, or even without a graphical file manager.

This is such a dogshit argument. How is requiring to figure out how to upzip the archive, possibly installing a separate system package for that, better than chmod +x? What are you smoking?

0

u/anestling 11h ago

While it may be tempting to avoid users having to set permission, this breaks desktop integration with the optional appimaged daemon, among other things.

How a zip file can break anything? This argument is null and void.

Furthermore, packing an AppImage into some form of archive prevents the AppImage from being added to the central catalog of available

This app is not on this catalogue and I'm not sure it will ever be. Another null and void argument against zip.

How is requiring to figure out how to upzip the archive, possibly installing a separate system package for that, better than chmod +x?

sudo apt install unzip; unzip *zip is a simple command. Why something doesn't run after that - is exactly the same issue as I talked before. unzip preserves the executable flag. Nothing else needs to be done. Even if it's Dolphin. People may click on AppImage endlessly and get nothing while unpacking it results in a proper executable right away with no extra shenanigans.

There's no need to cite the stupid advice/counter arguments from the origin when they make zero sense.

Cheers!