EZ Bkup: The easiest backup program on earth!
EZ Bkup is a data backup program for the desktop, striving to be as quick and easy to use, as possible.
EZ Bkup is a graphical frontend for Rsync, built with Owlkettle and GTK, written in Nim. EZ Bkup currently runs on Linux distributions, and expects rsync (3.2.4+) and polkit to be installed.
Respects Your Time
- Zero configuration/settings required.
- Zero Rsync knowledge required.
- Create Backup Routine(s) and run on-demand.
- Fast: Only copies what has changed since last time.
Respects your Freedom
Respects your Privacy
- No Telemetry.
- Does not beam your data back to the mothership.
If you've been reluctant to backup your data on a regular basis, or at all, because you didn't want to learn/configure a backup program, read a man page and use a command line program, or deal with the slow and tedious process of copying and pasting disparate folders/directories, we understand. That's why we created EZ Bkup for ourselves, and are happy to share it with you!
Thank You for supporting the development of ethical software!
A special thanks to Nim for rekindling the fun of programming, and making it easier to create programs that are more correct and efficient!
Thanks! hmmm, the website should probably say gtk4 is required too... In the source code, i'm just importing owlkettle and other nim deps, and calling rsync and pkexec via execCmdEx(). The Supporter Release has pre-compiled binaries for x86_64 glibc-based distros, along with desktop integration stuff, and a gui installer (shown in video on EZ Bkup website) and a couple bash scripts for debian-based distros until they update their polkit later this year, at which time the GUI installer should work. I will add a binary for Alpine to the Supporter Release when they update nim to 2.0 in the repos, or i build my own package for it. The installer/bash scripts just copy all the files where they go, or removes them all when uninstalling. The source code of EZ Bkup itself is released under the GPLv3, so users with distros not covered by the Supporter Release can still compile their own binary, though some external/supplemental niceties are omitted, like desktop integration icons, polkit policy, etc.
I hope that answers your question.
It does!
I haven't had enough of a passion for any of my more GUI-application-y projects to get them to any kind of finish line, so I didn't get to that point in any of them so far. I was always curious on how the experience is with just putting things into flatpaks or the like or making debs/rpms etc. out of them, so I was curious whether you went down that route and deal with those or not.
Thanks for the reply!
Great, you're welcome. I started reading the docs to flatpak, but I found them lacking, and have mixed feelings about flatpak, in general. I may revisit that later, once paid apps are a thing, but we'll see.
Making my own installer was easier (and funner) than packaging using anything else, it keeps things simple, light, and fast, and it works with the funding model i'm trying. I think it's easy for users too, especially once everyone can use the GUI installer.
I would like to make a whole desktop suite/distros' worth of software with nim and owlkettle, but we'll have to see how that goes. :) How cool would it be to have all your applications be nice looking, fast, low resource usage, with fewer bugs (security included), and readable source code?
I agree with you that it would be absolutely fantastic!
I'm kinda curious how you got your styling at the point it is When I was playing with owlkettle for a couple months, I found styling to be quite time intensive. It was hard to get a feel how much work it'd be in total to get it to look decent, so I'll likely take a look at your styling solution there later for sure!
Particularly since can.l implemented providing custom CSS sheets not too long ago.
Another thing which I'm ultimately wondering is how well ultimately owlkettle will end up working with reactive libraries. I'm from the webdev side of things where everything is done with observables and you even have central states that are observables and when those update the entire application gets informed of that. Or if that is even necessary, as in the month or so I played around with it, working with refs and just redrawing the entire application on state-changes worked okayish enough.
I would like to make a whole desktop suite/distros' worth of software with nim and owlkettle, but we'll have to see how that goes. :) How cool would it be to have all your applications be nice looking, fast, low resource usage, with fewer bugs (security included), and readable source code?
I mean, Nim Desktop would be kinda cool. Imagine being able to write extensions in NimScript live to tweak your window manager. ;)
Ey, stop stealing my ideas! Just kidding, but this is kinda the reason why I started experimenting with using NimScript from Nim programs to begin with.
You could piece together a distro already though. Nimdow as the window manager, notifishower/catcher for notification center stuff, and notifishower for all your system menu needs.
The GUI itself and styling was the easiest part for me. I didn't have to do much. I'm mostly just relying on the adwaita-dark theme. I only tested on fedora and ubuntu, IIRC, which both come with gnome packages. I will test other DE's eventually.
I'm coming from web dev too, and i'm still learning about desktop dev, using a strongly typed lang, etc. I found the owlkelttle state management stuff harder to understand than the actual gui.
The EZ Bkup website is written using nim too. Mummy, tiny_sqlite, etc.