Hi all — sharing a small desktop app I’ve been building: Lindoze, a system/process monitor laid out like the Windows 11 Task Manager.
The itch that started it: I have a 32-thread Ryzen, and the existing monitors (mission-center, gnome-system-monitor) overlay every logical CPU into one graph that turns into unreadable spaghetti at that core count. Lindoze gives each thread its own mini-graph in a grid that reflows to your window, so you can actually see what’s pinned.
Built with PySide6 + psutil. Tested on KDE Plasma and GNOME (Fedora Workstation); should work on any Qt-capable desktop. GPL-3. It’s a tribute to Dave Plummer’s Task Manager work — not affiliated with him or Microsoft.
I’d genuinely love feedback — especially bug reports from non-NVIDIA GPUs (the Intel path is experimental and I only have one machine to test on). If you give it a spin, tell me what breaks.
Thanks Alex — and fair point, KDE System Monitor is genuinely excellent and can be set up to show per-core graphs. I didn’t mean to imply nothing else does this.
A few reasons I built Lindoze anyway:
Desktop-agnostic. KDE System Monitor is (understandably) tied to the Plasma stack. Lindoze is plain PySide6, so it runs the same on GNOME or any Qt-capable desktop without pulling KDE in — that matters to me on non-Plasma machines.
The reflowing per-thread grid out of the box. Getting the layout I wanted at 32 threads — every thread its own cell, auto-wrapping to the window — was the specific ergonomic itch I kept hitting. Lindoze does that with no setup.
The Win11 Task Manager layout itself. Processes / Startup / Performance in that familiar arrangement is half the point for folks who want that muscle memory, not just the CPU view.
GPU in one view. It also shows multi-GPU stats out of the box — NVIDIA natively via NVML, plus AMD and (experimental) Intel — which I found more piecemeal to get going in KDE System Monitor.
Not trying to dethrone the incumbents — just filling a niche I kept wanting. Appreciate you taking the time to compare and post the shot.
One heads-up on the manual route: lindoze depends on python-nvidia-ml-py, which isn’t in Fedora’s repos — it ships from the same Copr. So if you install the standalone RPM without enabling the repo, dnf may complain about that missing dep. Easiest fix is to just dnf copr enable awn007/lindoze first (even if you then install the file by hand), and dnf can resolve it. Builds are also up for Fedora 42 and 44 if you swap the version in the URL.
Looks nice, but why the name “Lindoze”? It sounds like some sort of power management or sleep troubleshooting utility… why not call it something like Process Manager or Task Master or Resource Manager or something along those lines, if you want to give a nod to Dave Plummer?
Ha, you’re not wrong — “Lindoze” does kind of read like a battery/suspend tweaker at first glance. Fair call.
The full name is “Lindoze Process Manager”, since the whole idea is the Windows-Task-Manager-style layout running natively on Linux.
I also wanted something short and clean to type as the package/command name (pipx install lindoze, copr enable awn007/lindoze, just lindoze to launch) — “Lindoze Process Manager” is clear but a mouthful on the CLI.
Your point about clarity stands though, so I’ve updated the post title to “Lindoze Process Manager” — keeps the playful name but says what it actually does up front. Appreciate the thoughtful feedback!
I hear you, and choosing a package name is way less straight forward than it appears at first glance.
In this case, lpm’s tempting for brevity, but it’s actually a pretty crowded acronym — there are already several package managers using “lpm” (LodOS, Liquibase, Loupe, a couple of distro ones), so it’d be ambiguous and unsearchable, and it loses the Win11 nod entirely.
That’s how I landed on Lindoze as the handle and I just let “Process Manager” carry the clarity, hopefully.
Appreciate you thinking it through with me though! I genuinely am grateful, it made me rethink how I label posts etc.
While I’m not accusing anyone of anything here I still feel the urge to remind everyone to remain cautions of what you are installing on your computer and from what sources.
COPRs are not reviewed in any way!
This forum user is just 20 hours old.
The Github user is just 1 week old.
Github user “Claude” (a generative AI) contributed to the Github project.
My subjective feeling is that the comments here could also be written by genAI, but I’m not an expert here. My hints are the generous use of em dashes and soft friendly tone.
I’ve heard that the Arch User Reposiory (AUR, essentially their Copr) had issues with malware very recently.
You are not wrong - but I do get the sense that the author is a legitimate contributor - I’m less inclined to trust the AI to write secure code though.
Good call out. The vibe coded app itself isn’t a big red flag to me, because there are a lot of people doing stuff like this today (for better or worse). However, the comments they’ve posted are very clearly coming straight out of an LLM. It’s not just the em dashses, it’s the structure of the replies, the word usage, etc.
So this is an AI generated app being promoted with AI generated comments by a brand new account. Make of that what you will.
David, that’s fair and I’m glad you said it. A day-old account posting a Copr link should get exactly that reaction, and I’d rather see the warning than not.
So, plainly: yes, this is my first project, and yes I used Claude Code to help build it. I haven’t hidden either one. And you’re completely right that nobody should install this, or anything, from an unreviewed source they can’t inspect. That’s why it’s GPL-3 with all the code public, and why the Copr builds straight from the spec in the repo instead of some binary I’m asking you to trust. I’d honestly rather someone read it and tell me it’s bad than run it on faith.
On the “vibe coded” read: I get it, but I didn’t paste a prompt’s output and hit publish. I built this because my Ryzen has 32 threads and every monitor I tried crams them all into one unreadable graph, and I wanted the per-thread grid Windows has. I made the design calls, tested it on KDE, in a GNOME VM, and on my father in law’s old laptop for the Intel GPU path, and wrote the packaging by hand, including building a dependency Fedora doesn’t even ship. Claude was a tool in that. A good one. But I was the one driving.
The comments reading like an LLM, that part’s true and I’ll own it. I understand why it trips the alarm, but there’s a real person on this end.
If the mods feel a Copr-stage project doesn’t fit this category, tell me and I’ll move it or wait until it clears Flatpak review. No hard feelings either way. I shared it because I’ve gotten years of use out of other people’s open source and wanted to put something back.
Thanks Matt, you’ve been the one welcoming voice so far. It helps a lot, I’m feeling pretty discouraged at this post and your other comments are helping!
That’s why I’m in the the Welcome Wagon (Join SIG).
At the moment Flock is on, but if you drop by Join, we can help you get acquainted with the different teams and how they work.
AI is allowed in Fedora, though we do require a notification of such, as detailed in the policy.
Bang on with your project, get some feedback. Everyone is using AI these days, so I heard, so the key is to review it and allow peer access. Exploits were around long before AI. We gotta deal with the next generation in some way. So lets try and do it nicely.
Friendly reminder to anyone passing by that the XZ Utils backdoor happened through social engineering techniques. Keep that in mind if you’re planning to give this a try because you feel bad for the poor robot feeling “discouraged”.
@awn007 if you’re actually looking for feedback from humans, stop using an LLM to write all your comments. It comes off as disingenuous and untrustworthy, and nobody wants to converse with an agent.
Thank you Mat, I made sure the AI disclosure was added per the policy you pointed me to, and I left Claude as a contributor on GitHub so there’s no question for anyone that looks at it.
It is GNOME shell applet, and gnome-shell eats about 166Mb of mem right now, so I wonder what is the overhead of your monitoring app?
Also, the primary use case to have separate views for cores is “who eats that core”? It that addressed? And the use case for the CPU/GPU/Mem pages is “who ate my resources”. Tables give that info, but they are boring. I also need ability from Process Manager to teleport a process to another machine, freeze/restore it with relevant data (CRIU or anything that helps).
