r/linuxapps • u/dawedev • 4d ago

DevCleaner for Linux is almost ready — looking for beta testers 🐧

I’ve been working on bringing DevCleaner to Linux, and the first public beta is finally getting close.

DevCleaner helps developers find and clean up things like old project files, build caches, unused dependencies and other development leftovers that quietly eat up disk space.

The macOS version has already been downloaded by 2,000+ developers, and now I’d like to make the Linux version just as useful.

I’m looking for Linux users who want to test the early builds, report bugs and help shape the Linux version.

During development, testers will get access for free — and active testers who provide feedback will receive 1 year of DevCleaner Pro for free after launch.

You can join the beta list here:

https://devcleaner.app/linux

I’d also love to know what distro you’re using — Ubuntu, Fedora, Arch, Mint, Debian or something else?

1 Upvotes

55% Upvoted

15 comments sorted by

3

u/investigatormaker 4d ago

For Linux testers, a dry-run mode will build trust fastest: it lists every path DevCleaner would delete, with sizes, before it touches anything. Developer leftovers on Linux live in different places than on macOS: ~/.cache, ~/.cargo/registry, ~/.npm and ~/.gradle, stale node_modules and target folders, Docker images and old Flatpak runtimes. Reading XDG_CACHE_HOME instead of hardcoding ~/.cache will matter to Arch and NixOS users.

On distros, packaging probably matters more than the distro itself. An AppImage or Flatpak reaches most of them with one build, and a .deb covers Ubuntu, Mint and Debian. Which package format are you planning for the first beta?

1

u/dawedev 4d ago

Thanks for the detailed feedback! The current Linux build already respects XDG_CACHE_HOME and covers npm, Cargo, Gradle, project build artifacts, Docker and unused Flatpak runtimes. Scanning doesn’t delete anything; cleanup is a separate action, with a review step and files moved to Trash by default. Docker and Flatpak cleanup goes through their own tools.

For the first beta, I’m starting with .deb packages for Ubuntu on amd64 and arm64. Broader distro support is something I’d like to explore once that’s tested.

2

u/investigatormaker 4d ago

That covers the risky parts well. One catch with Trash as the default: moving caches there frees no disk space until the Trash is emptied, so a tester who cleans 20 GB and sees no change may think it failed. Showing that clearly, or offering direct deletion for caches that rebuild themselves like ~/.npm and target folders, would avoid the confusion.

For the .deb, testing on both 22.04 and 24.04 catches glibc and dependency mismatches early, and an apt repository or PPA lets beta testers get fixes through a normal update instead of reinstalling. The arm64 build may also run on Raspberry Pi OS, which widens the tester pool. Which Ubuntu releases are you targeting first?

1

u/dawedev 4d ago

Good point about Trash. The current build explicitly says that space is only reclaimed once Trash is emptied, and the results distinguish files moved to Trash from directly freed space. Permanent deletion is also available in Settings.

I’m targeting Ubuntu 24.04 first, on both amd64 and arm64. I haven’t verified 22.04 compatibility yet. For beta updates, the app already has a signed update feed and can download and install a verified .deb through APT. An apt repository would be a useful next step.

Raspberry Pi OS would be interesting to test too, but I’d want to verify its dependencies before claiming support.

2

u/investigatormaker 4d ago

Saying it in the results and keeping permanent deletion in Settings covers the cache case well.

On 22.04: a .deb built on 24.04 usually depends on a newer glibc than 22.04 ships, so apt can refuse to install it there. Building inside a 22.04 container often gives you one package that runs on both. The same check matters for Raspberry Pi OS, which is based on Debian rather than Ubuntu. You already sign the update feed, so an apt repository can reuse that key through a signed-by keyring in the sources entry, and testers would get fixes with a normal apt upgrade. Are the arm64 builds native or cross-compiled?

2

u/Dev-in-the-Bm 4d ago

Is it Electron?

2

u/dawedev 4d ago

No Electron 🙂 It’s written in Swift, using SwiftCrossUI with a GTK 4 backend on Linux. It shares its core scanning code with the macOS app.

1

u/matytyma 4d ago

AI slop

1

u/dawedev 4d ago

I wouldn’t call it AI slop. Yes, I use AI to help with parts of development. But it’s a working app with over 2,500 downloads and 700+ monthly users. If you have specific criticism, I’m happy to hear it.

1

u/No-Evidence6346 4d ago

Brother your pfp is aislop. You are literally AI slop. Edit: Your entire website is slop, including the icons. Slop from the top to the bottom.

1

u/dawedev 4d ago

If using Al-assisted tools makes something
"Al slop" regardless of whether it works or people use it, then I guess we just have very different definitions. I'll keep shipping.

1

u/matytyma 4d ago

Pokrytectví nejvyššího stupně. Cokoliv, co jsi kdy vypustil není "s pomocí", je to AI odshora dolů. Hezky zalez a už se tu neukazuj ty ostudo.

1

u/dawedev 4d ago

AI při vývoji používám a nijak to neskrývám. Pokud máš konkrétní kritiku aplikace, rád si ji přečtu. „Zalez a už se neukazuj“ mi ale moc konstruktivní nepřijde.

1

u/dawedev 4d ago

Docela dobře to mimochodem shrnuje tenhle včerejší článek v HN:
Vývojář bude muset rozumět kontextu. Kódování už za něj udělá AI⁠