jmtd → log → Borg, confidence in backups, GtkPod and software preservation
Over the summer I decided to migrate my backups from rdiff-backup to borg, which offers some significant advantages, in particular de-duplication, but comes at a cost of complexity, and a corresponding sense of unease about how sound my backup strategy might be. I've now hit the Point Of No Return: my second external backup drive is overdue being synced with my NAS, which will delete the last copy of the older rdiff-backup backups.
Whilst I hesitate over this last action to commit to borg, something else happened. My wife wanted to put a copy of her iTunes music library on her new phone, and I couldn't find it: not only could I not find it on any of our computers, I also couldn't find a copy on the NAS, or in backups, or even in old DVD-Rs. This has further knocked my confidence in our family data management, and makes me even more nervous to commit to borg. I'm now wondering about stashing the contents of the second external backup disk on some cloud service as a fail-safe.
There was one known-good copy of Sarah's music: on her ancient iPod Nano.
Apple have gone to varying lengths to prevent you from copying music from an
iPod. When Music is copied to an iPod, the files are stripped of all their
metadata (artist, title, album, etc.) and renamed to something non-identifying
(e.g. F01/MNRL.m4a), and the metadata (and correlation to the obscure file
name) is saved in separate database files. The partition of the flash drive
containing all this is also marked as "hidden" to prevent it appearing on macOS
and Windows systems. We are lucky that the iPod is so old, because Apple went
even further in more recent models, adding a layer of encryption.
To get the music off the iPod, one has to undo all of these steps.
Luckily, other fine folks have worked out reversing all these steps and implemented it in software such as libgpod and its frontend, GtkPod, which is still currently available as a Debian package. It mostly worked, and I got back 95% of the tracks. (It would have been nice if GtkPod had reported the tracks it hadn't recovered, it was aware they existed based on the errors it did print. But you can't have everything.)
GtkPod is a quirky, erratic piece of software, that is only useful for old Apple equipment that is long out of production, prior to the introduction of the encryption. The upstream homepage is dead, and I suspect it is unmaintained. The Debian package is orphaned. It's been removed from testing, because it won't build with GCC 10. On the other hand, my experience shows that it worked, and was useful for a real problem that someone had today.
I'm in two minds about GtkPod's fate. On the one hand, I think Debian has far too many packages, with a corresponding burden of maintenance responsibility (for the whole project, not just the individual package maintainers), and there's a quality problem: once upon a time, if software had been packaged in a distribution like Debian, that was a mark of quality, a vote of confidence, and you could have some hope that the software would work and integrate well with the rest of the system. That is no longer true, and hasn't been in my experience for many years. If we were more discerning about what software we included in the distribution, and what we kept, perhaps we could be a leaner distribution, faster to adapt to the changing needs in the world, and of a higher quality.
On the other hand, this story about GtkPod is just one of many similar stories. Real problems have been solved in open source software, and computing historians, vintage computer enthusiasts, researchers etc. can still benefit from that software long into the future. Throwing out all this stuff in the name of "progress", could be misguided. I'm especially sad when I see the glee which people have expressed when ditching libraries like Qt4 from the archive. Some software will not be ported on to Qt5 (or Gtk3, Qt6, Gtk4, Qt7, etc., in perpetuity). Such software might be all of: unmaintained, "finished", and useful for some purpose (however niche), all at the same time.
Comments
GTKpod sounds like a great candidate for flatpak or some other user-level package management system that containerizes dependencies. I feel like it would be good for Debian if the project concentrated on providing a robust "base system" supporting one or more of these package systems. This would make a quite a few package maintainers unhappy if handled poorly, but I bet some skilled social engineering could make it work in a way that resulted in more and happier members of the project. Heck of a hack if it work.
One thing I would not like to see is for the project to select a "blessed" user-level package system (I expect flatpak would be the choice) and deprecate support for others. That would be a sad time for many, thinks I.
This all sounds like a job for one or more Pure Blends, and like I've talked myself into Yet Another Project... dang
I agree, GtkPod (and libgpod, and whatever other historic libraries it might depend upon) are a very good candidates for a user-level container-based packaging system.
I disagree that the project should not take a view on blessing one user-level container-based packaging system or another. The elephants in the room here are clearly flatpak and snap (I don't think there is a third contender really. although the appstream people beg to differ. Loudly. All over the place.). I'm not familiar enough with either to have a preference of my own, yet.
The reason I think the project should take a view on it is: we're once again in an absurd situation where >1 F/OSS technologies are competing in the same space and eating each other's breakfast whilst the proprietary world (walled garden app stores) look on and laugh. Blessing one over another doesn't necessarily mean preventing the other from being installed and used. A bit like taking a view on a default init system, or a default desktop session, or a default desktop technology.
Ultimately it would be very interesting if Debian could eventually consider adopting such a technology wholesale, and moving all the periphery packages out of the robust "core" OS/traditional repositories, and into containerized collections that could move at different speeds without breaking each other.
Well, chances are that I might be that person
Yes, seeing it from that point of view you are right: it's sad. But it's not just on the sake of "progress", it's also avoiding us maintainers becoming the upstreams of a huuuuge codebase. Let's take a look at Qt 4's changelog.
The latest stable release was 4.8.7. We got it packaged on Tue, 26 May 2015. That's 5 years from now.
Let's now take a look at Qt 5's changelog.
The first Qt 5 packaged release was on Thu, 11 Apr 2013. To be completely honest: Qt 4 died the same day Qt 5.0.0 was published. The fact that we got to manage some more stable releases was purely on the fact that interested parties pushed for patches.
But those patches where for easy fixes, not for adding new functionality or even changing API of it's dependencies, which we have a lot.
So we have been maintaining a dead upstream for ~7 years. A huge, massive code base. A webkit integration that was full of CVEs. Is it really up to us maintainers to keep this kind of projects alive? No, it isn't.
So, what if you really need a specific Qt 4 app no longer maintained? This is where containers prove really useful in my point of view.
At some point we developers and maintainers have to acknowledge the fact that "software life cycle" includes, well, death.
Porting a normal Qt4 app to Qt5 usually takes a couple of hours using the automated tools (if you want to turn off the compatibility warnings it usually takes a day). Porting Qt3 apps takes a bit longer, usually easier to port "via" Qt4 (same with Qt2, but last time it took about a week because of other old libraries it used).
Qt tends to value backwards compatibility highly.
Are there any Qt4 apps not ported to Qt5 in particular you're thinking about?