In school and public libraries it was a physical piece of thick paper, similar to a Rolodex card, which had multiple copies, always one per author and one per title, but sometimes backups by subject manager. And when I was a kid, there were often multiple, redundant copies that one could take to the librarian to check out the physical book if it were particularly important.
Wait, you had card catalogs where you took the cards out of the drawer? I grew up with card catalogs where there was a metal rod at the bottom of each drawer that ran through holes in the bottom of the cards. There were cards for author, title and subject with multiple subject card possible for each book. The CIP blocks on the copyright pages of books list all the possible subject headings.
And I've been thinking that I don't use the subject indexes on the online catalog anywhere near enough. They can surface things that the standard keyword search might miss or bury among irrelevant results.
How is that? I can follow his thoughts 100% and it's very plausible.
Also his reference to the german green party hits home because I'm from there. And I can see my electricity prices right now go to 90 Cent/kWh _before_ the war.
> I don't believe the US would immediately attack Russia even if Russia wiped Paris off the map, because doing so would guarantee we are all wiped off the map.
I think it is obvious that FRANCE would retaliate with nukes.
Technically this is true, however UAE, one of the most popular Amiga emulators comes with a free replacement ROM from the AROS project, which although not fully compatible can run some games.
> Hot tip for handling office file formats or anything that uses a ZIP container: just unzip them and commit _that_ to the repo.
Even modern (zipped XML-based) office file formats do make some limited use of binary blobs. You can either keep these intact, or write a small objdump-like tool that serializes them to text†. For portability, it might be best to write the serializer/deserializer in JS dumped into a thin HTML wrapper, so you pretty much anyone can double click to "run" it. (My experiments on roundtrippability with including that file in the ZIP container yielded poor results.)
† I've used this strategy for Oberon .rsc binaries. Due to Wirth's affinity for single-pass compilers, the Oberon toolchain doesn't involve a discrete assembler or AOT linker tool, so there is no assembly format or linker scripts. However, Wirth's distribution of the Oberon system does have an ORTool utility <https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/ORToo...> (in the vein of objdump/readelf/nm) that will dump a textual description of the binary you give it. I realized that with some slight tweaks, you can use the output of ORTool.DecObj as a de facto "assembly" format—just write a tool capable of parsing it and then write out the corresponding binary.
I built a tool to explore version control of files like that by decompressing their contents and version controlling those. It was an interesting experiment.
