DEV Community: Tomas Pluharik

Protecting local AI work with incremental cloud backups in TuxInDrive 0.26.57

Tomas Pluharik — Sun, 27 Sep 2026 18:18:49 +0000

AI-assisted work increasingly depends on local state that does not live in a normal project repository: conversations, prompts, memories, skills, commands, and tool configuration.

I maintain TuxInDrive, an open-source multi-cloud synchronization client. Version 0.26.57 adds automatic cloud backups for locally installed:

Codex
Claude Code
Gemini CLI
Cursor
Continue

How it works

TuxInDrive detects supported local data folders and creates scheduled, upload-only jobs in a cloud account you already control. The first backup starts immediately; later runs use the normal scheduler and can be paused like other jobs.

Backups are incremental. Unchanged files are not uploaded again, and the job displays its current completion percentage while running. Replaced or deleted cloud versions are retained for seven days, then older history is pruned after a successful run so storage consumption cannot grow indefinitely.

If TuxInDrive closes during an upload, the job records an interrupted state. Choosing Sync now safely continues the incremental upload and skips content already present in the cloud.

Credential boundary

These are local-file connectors, not AI-account integrations. They do not sign in to Codex, Claude, Gemini, Cursor, or Continue, and they cannot export browser-only conversation history.

Known authentication files, private keys, environment files, caches, logs, sockets, locks, and temporary runtime data are excluded. Because third-party extensions may use custom secret filenames, users should still review the generated exclusions before enabling a backup.

Try it

TuxInDrive 0.26.57 is available for Linux, Windows, macOS, and Android:

Download TuxInDrive 0.26.57

The project is open source. Feedback on additional local AI tools, exclusion rules, and restore workflows is welcome.

How I removed polling from a Linux laptop power manager

Tomas Pluharik — Fri, 25 Sep 2026 20:35:35 +0000

Power-management software has an awkward requirement: it should not become part of the power problem.

I built PowerSifu, an MIT-licensed GTK tray application for Ubuntu and Debian laptops. It switches power-profiles-daemon profiles when AC power changes, applies optional profile-specific brightness, runs weekly schedules, and can gracefully stop selected user applications when a profile activates.

The first implementation worked, but its monitoring design was too eager. Version 0.3.5 is the result of reworking it around system events instead of repeated polling.

The first design

The original monitor woke every five seconds. It checked whether the laptop was on AC power, asked for the active power profile, compared the result with the saved policy, and acted if anything had changed.

That approach is easy to understand and usually reliable. It is also a poor fit for a utility whose purpose is to reduce unnecessary laptop activity. Even when absolutely nothing changes, a polling loop still wakes up, performs work, and often launches helper processes.

PowerSifu also used powerprofilesctl repeatedly. Besides the process-launch overhead, this exposed the app to a shutdown crash in the Python-based command on a newer Ubuntu environment. Moving the operation into the long-running process solved both problems at once.

Listening instead of asking

Linux already has services that know when these properties change. UPower exposes the power-source state and power-profiles-daemon exposes the active profile. Both are available over D-Bus.

PowerSifu now creates persistent proxies for those services and subscribes to property-change notifications. A transition from AC to battery causes an immediate callback. A profile change does the same. When the laptop sits untouched, the monitor has nothing to poll.

Keeping the proxies alive is important. Recreating a proxy for every read would still repeat service discovery and connection work. The current design creates the service objects once, reuses them for reads and writes, and de-duplicates notifications before applying policy.

The profile write path moved to the power-profiles-daemon system D-Bus interface as well. There is no repeated command-line process between the application and the service.

Events still need a recovery path

An event-driven design should not assume that every desktop session and service behaves perfectly forever. A service can restart, a signal can be missed during reconnection, or an older environment may not expose an expected notification.

For that reason, PowerSifu retains a 60-second reconciliation check. This is not the primary monitor. It is a slow safety net that compares the real system state with the last observed state and repairs any discrepancy.

The distinction matters: normal behavior is immediate and event-driven, while recovery remains bounded and predictable.

Schedules should sleep too

Weekly schedules originally shared the frequent monitoring loop. They only need minute-level precision, so checking every few seconds was unnecessary.

The scheduler now calculates the next wall-clock minute boundary, sleeps until that boundary, and evaluates enabled entries once. If the user has not configured any schedule, the schedule timer is disabled completely.

This also makes the behavior easier to test. The tests can verify alignment, once-per-minute execution, and the no-schedule sleep state independently from AC and profile events.

Brightness without fighting the desktop

Profile-specific brightness presented a different problem. Writing directly to a backlight device can change the panel while leaving GNOME's Quick Settings slider at its old position. That gives the user two conflicting views of the same setting.

On GNOME, PowerSifu therefore changes the desktop's own global brightness control and keeps the visible slider synchronized. Mutter and brightnessctl remain fallbacks for environments where that route is unavailable. External monitors are left to their own controls because they often require DDC/CI or vendor-specific handling.

Keeping the security boundary small

PowerSifu does not install a custom privileged daemon. Profile and brightness changes use the desktop and existing system services. Installing an official update is the one action that requests operating-system authentication. Before that request, the app verifies the download size and SHA-256 digest along with the Debian package name, version, and architecture.

Application rules are intentionally limited. They accept exact process names, match only processes owned by the current user, and send SIGTERM so the application can exit cleanly. There is no arbitrary command field and no root-process termination.

The app has no account, analytics, or telemetry. The update checker contacts the official GitHub Releases API only when the user selects Check for updates.

What changed in 0.3.5

The practical changes are:

UPower and profile property events replace the five-second polling loop.
Persistent D-Bus proxies are reused for profile reads and writes.
Duplicate notifications are filtered before policy is applied.
A 60-second reconciliation check covers missed or unavailable signals.
Schedule checks align to minute boundaries and stop when unused.
Regression tests cover proxy reuse, event de-duplication, and schedule timing.

I am deliberately not claiming a universal battery-life percentage. That depends heavily on the laptop, kernel, desktop, workload, and existing services. The engineering goal here was narrower and measurable in the design: eliminate repeated subprocesses and unnecessary five-second wakeups while preserving fast reactions and recovery.

PowerSifu 0.3.5 is available as a standalone .deb, with source, tests, architecture notes, and release documentation on GitHub:

I would appreciate reports from different Ubuntu and Debian versions, laptop models, and desktop environments. I am also interested in feedback about packaging for distributions beyond the current .deb target.

TuxInDrive: sincronização multicloud open source com foco em Linux

Tomas Pluharik — Thu, 27 Aug 2026 13:45:36 +0000

Olá! Sou o desenvolvedor do TuxInDrive, um cliente gráfico de sincronização multicloud de código aberto, pensado primeiro para Linux.

A proposta é reunir em uma única interface recursos que normalmente exigem várias ferramentas ou configuração manual:

sincronização bidirecional e seletiva;
arquivos sob demanda;
histórico de versões e tratamento de conflitos;
busca e pré-visualização de arquivos sincronizados;
controle global de largura de banda;
suporte a diferentes serviços de nuvem.

O projeto continua em desenvolvimento ativo. Estou procurando pessoas interessadas em testar diferentes distribuições e provedores de nuvem, além de colaboradores para código, documentação e traduções.

Projeto, documentação e downloads: github.com/tpluharik/Tuxindrive

Feedback sobre confiabilidade, experiência de uso e empacotamento para Linux é especialmente bem-vindo.

Transparência: sou o desenvolvedor do projeto.

TuxInDrive 0.26.30: a visual comparison of Linux sync alternatives

Tomas Pluharik — Wed, 26 Aug 2026 12:22:41 +0000

I am the maintainer of TuxInDrive, an MIT-licensed, Linux-first multi-cloud synchronization client. I made this comparison to show where the project fits among provider clients, command-line tools, self-hosted platforms and peer-sync applications.

Why another sync client?

Linux users often have to combine several tools: one for cloud accounts, another for files-on-demand, scripts for safety checks, and a separate peer-sync application. TuxInDrive aims to put these workflows behind one interface while retaining explicit safety controls.

Version 0.26.30 includes:

Google Drive, OneDrive, Dropbox, Box, pCloud, MEGA, Proton Drive, Nextcloud, S3, WebDAV, SFTP and GitHub support
two-way, upload-only and download-only synchronization
files-on-demand with offline pinning
selective rules by path, extension, size and age
a pre-transfer change preview and mass-change protection
local version history, recovery and visual conflict resolution
one global bandwidth controller shared by sync, streaming, scans and updates
owner-approved LAN and encrypted peer collaboration
Linux, Windows, macOS and Android builds

How to read the matrix

The matrix is not a performance benchmark. A green mark means the capability is documented and generally available. Amber means it is limited to certain platforms, providers or command-line workflows. Red means I could not verify the capability in the regular product.

The sources are the official documentation for each project. If a rating is outdated or too strict, please open an issue with the relevant documentation link and I will correct it.

Try it or help improve it

The project is still looking for testers across different providers and operating systems. Bug reports, documentation corrections, security review and code contributions are welcome.

Repository and downloads: github.com/tpluharik/TuxInDrive

Why I built TuxInDrive: one open-source sync client for multiple clouds

Tomas Pluharik — Fri, 21 Aug 2026 14:38:35 +0000

Linux cloud synchronization is still surprisingly fragmented. One provider may have a native client, another needs a command-line tool, and a third requires a collection of scripts.

I started TuxInDrive to provide one interface for managing several cloud services while keeping Linux as a first-class platform.

What it supports

TuxInDrive currently works with Google Drive, Microsoft OneDrive, Dropbox, Box, pCloud, MEGA, Proton Drive, Nextcloud and GitHub repositories.

Depending on the provider, it offers:

One-way and two-way synchronization
Files-on-demand
Conflict handling and version recovery
Safety previews before potentially destructive operations
Integrity verification
Global bandwidth and network controls
Encrypted peer sharing
An optional self-hosted coordination server

Linux is the primary platform. Builds are also available for Windows, macOS and Android.

Where I need help

The project is usable, but still young. I would especially appreciate:

Testing with different providers and distributions
Reproducible bug reports
Feedback on installation and documentation
Security and networking reviews
UI and accessibility feedback
Code contributions

Please begin with non-critical test data and maintain an independent backup while evaluating synchronization software.

Development transparency

AI coding assistants have been used during development. Architecture and release decisions are reviewed by the maintainer, and automated tests are run before releases. Contributions and independent review are welcome.

Repository, documentation and releases:

https://github.com/tpluharik/Tuxindrive