The rexiv2 library crate (available on crates.io) for Rust provides read and write access to media file (mainly photo) metadata in the Exif, XMP, and IPTC formats. Many file formats are supported, including of course JPEG, PNG, TIFF, XMP sidecar, some camera raw formats, and various others.
Matthew Garrett's timely post GPL enforcement is a social good reminded me to revisit my old Geeky Guide to Giving list, and to reprise and update it; this time with a Software Freedom theme. So, below, a list of charitable organizations seeking your help to advance the cause of Free/Open Source software.
Makefiles are the granddaddy of build systems. Though falling out of favour relative to more modern systems like SCons and ant, make is still the lingua franca of software builds, particularly in the C and C++ parts of the open source world. Because of this, it is imperative to have at least a basic understanding of makefiles and their use.
There are plenty of tutorials introducing the fundamentals of makefile
syntax, and a handful that show off some advanced features. There are very
few, however, that actually show how to write a useful makefile, or that
introduce makefile conventions and patterns. For me, this meant that writing
makefiles became an arduous process of stringing together snippets from
various places, and hoping they interoperated harmoniously. Frustratingly, I'd
often learn of a new feature months later and rip out half of the file and
replace it with a single line. Worst of all, I had no idea if what I was doing
conventional or even passable as a serious makefile.
I am afraid that I have to admit that the development of this site has until now proceeded in what any programmer must consider a state of sin: it was not under version control. Sure, I had periodic snapshot backups, but forget about versions, branches, and reverts.
The reason for this is that I was under the mistaken impression that my VCS of choice, git, made it difficult to set up remote branches. I think my confusion stemmed from the fact that it is somewhat tricky to set up public-facing ones with good commit-access control etc (which is why GitHub is so great).
Now that I looked into it more, I find it's actually tremendously easy, and
I've got a really great work-flow set up: I have a master repo on the server,
a development repo on my laptop, and another one in the directory from which
the site is served. I can make changes on my laptop (and thanks to the magic
of makefiles and m4 macros, keep a separate dev config file), and then push
those to the master repository. When I'm ready to launch, I just pull them to
the serving repo and run a