Bob Smith

That’s a solid piece of advice. Before I automate any rsync jobs, I’m going to familiarize myself with mountpoint so I can check on the front end of the job.

I lived this. It was a great way for me and several of my closest friends to learn about the variable latency among devices between pushing the play/unpause button and when a cd track actually starts to play.

I do something like that with rsync. The syntax is a bit tricky to figure out at first, but the idea is that you take a known-good copy of your data and run rsync to copy it to the removable drive. After the first sync, you can run the command to check for any changes and push the changes from your main data to the copy on the drive.

You’ll want to research the command and the options, but you can theoretically run something like: rsync -avP --delete /mnt/Data_Drive/Data/ /run/media/user/Backup/Data/ where a is archive mode which helps to do things like preserve file attributes, v is verbose so you can see more details when you run the command, and P gives a progress line and keeps any partial files on the receiving end if the transfer is interrupted for some reason. --delete removes any files on the receiving end that have been deleted from your main data folder since the last time you’ve run rsync. The mnt folder path can be replaced with wherever your main data backup lives and the /run folder is a hypothetical destination folder on a removable drive.

An additional trick is to run the command with -n at the end of it before you run it without -n at the end. -n performs a ‘dry run’ where it will output what the changes are going to be when you actually run the sync operation. This can help you spot issues like mistyping the file path in your command. If you’re only syncing one or two changes and the dry run indicates that it is going to basically re-transfer your entire data folder, then you probably got something wrong.

Another fun thing about rsync is that if you’ve got ssh server set up on your home computers, you can run rsync to sync files from one computer to another one on your network.

I agree with you entirely. Anybody who is comfortable with calibre and with managing their own library of epubs won’t have a problem with a device like this.

I have one of these and I enjoy using it. If you have a lot of drm-free ebooks and you want a tiny device with good physical buttons, then it might be worth getting one of these.

It only supports drm-free books that you load on to the sd card, so you’re hosed if you buy all of your books through the kindle store. No libby app or other workarounds. Edit: I just got access to the article. Apparently the newest version of Crosspoint has Libby support. On the plus side there’s a nice 3rd party firmware scene. I use Crosspoint, which makes the interface more straightforward. It is also easy to sideload new lockscreen images and my preferred fonts for ebook reading.

I only use it for basic epub ebooks.The processor/screen combo makes comics and pdfs a bad experience. Due to this Crosspoint doesn’t officially support pdfs or comic book files.

From a hardware perspective, I REALLY like it. It takes up minimal pocket space and I can fit it into the bonus pocket on my jeans. The physical buttons on the front and side are very nice and responsive. Screen is small but more than adequate. Battery life is fine.

Debian is sooo Dorothy.

I’m running the standard version of syncthing through termux at the moment. It lacks some of the power management options, but otherwise I’ve experienced no issues.

I agree.

A part of me misses the days of dual-using a rock solid professional server OS for business and a cobbled-together similar OS for home computers and older hardware.

Cobbled-together became good enough. Then it became better in some cases. Then it became better in most cases. Now I haven’t bothered with a non-Linux for over half a decade.

I always assumed that a lot of this boils down to semantics and trademark law.

OpenIndiana is a direct code-line descendant of Unix System V through OpenSolaris via Solaris. Thank you for that, Sun Microsystems. I understand (but haven’t looked) that a lot of code these days is simply ported over from BSD or Linux. If you compare the source code to an old copy of the Lions book, you’re probably not going to see any line-by-line overlap. Thank goodness - we shouldn’t be literally running old operating systems from the '80s. I don’t think that OpenIndiana is Unix-certified by the Open Group (Trademark).

The BSDs started out as a sort of ‘Ship of Theseus’ rebuild of an academic-licensed copy of Unix around the time that AT&T was getting litigious and corporate Unixes (Unices?) were starting to Balkanize.

GNU/Linux started out as a work-alike (functions the same but with totally different code) inspired by MINIX, which in turn was an education-licensed Unix work-alike designed to show basic operating system principles to students. I think that one or more linux-based operating systems have obtained UNIX certification from the Open Group, just like Apple did for MacOS (paying money and passing some tests). It doesn’t seem like any of them are still paying to keep up the certification. Does it matter if they did at one point?

Going back to proprietary corporate Unixes, I believe that IBM AIX and HP-UX still exist as products. They started out as UNIX and have been developed continuously since then. They are both Certified Unix. By now, their codebases probably diverge substantially both from one another and from all of the Unix-likes. IBM also has a mainframe OS with a fascinating history that has nothing to do with UNIX. It is Certified Unix because it passes the right tests and IBM paid for certification. It is not UNIX code and doesn’t descend from UNIX code.

Simple as.