Did you know my !!con West talk from February is online? You should watch me talk about old video games and obsolete text encodings! https://youtu.be/t37Cr3FDyvU
Has anyone used Mastonaut yet? I'd love to hear impressions. https://apps.apple.com/us/app/mastonaut/id1450757574
Wow, Apple just released a patch for devices that haven't gotten an OS update in three years. Looks like it's a fix for the GPS epoch bug? At least, Apple says this is for a bug that will start happening November, 2019. https://support.apple.com/en-us/HT210239
“Women working in electronic computing early on were dismissed precisely because they had technical skills, not because they lacked them. As those skills became more highly valued, women were often forced out of the field instead of being promoted …“
📄 Marie Hicks, Against Meritocracy in the History of Computing, 2016 → http://s3data.computerhistory.org/core/core-2016.pdf
At any rate, the “bad” version of the MPEG file is always having the “data” bit set, while the “good” version varies between “video”, “audio”, and “data”. Feels like Lunar is probably skipping over every non-video sector.
There’s also a format-dependent “coding” byte, which the “bad” tool is setting to 0. It has information about resolution and coding type; Lunar may be depending on it.
I’ll continue investigating, but I think I have all I need to attempt a fix now.
Think I’ve about figured out my problems with the MPEG version of Lunar.
The CD XA format has some metadata that goes along with the actual data in each sector, signalling things like “what kind of data is in this sector?” I guess the intent is that primitive systems can use the sector metadata without needing to actually identify the file type using other means?
I've written something about the Andaluh and the andaluh-rs crate that I've been working on: http://danigm.net/andaluh.html
Now in blog form! "rsync, GUIs, power, control, design, and decisions" https://bits.ashleyblewer.com/blog/2019/06/29/rsync-guis-power-control-design-and-decisions/
So there's a debatable regression in bzip2-1.0.7. It cannot uncompress some files from lbzip2, which worked fine with bzip2-1.0.6, because of the fix for CVE-2019-12900.
Bzip2-1.0.6 and before had a bug with unvalidated input, which a fuzzer found to lead to a buffer overflow.
However, those version seemed to work for lbzip2 files, which (arguably wrongly) were writing the input value larger than bzip2 expected.
https://gitlab.com/federicomenaquintero/bzip2/issues/24 - people who want to do code digging appreciated!
digipres.club is a space for folks interested in productive conversations about, well, digital preservation! If you enjoy talking about how to do memory work with computers, or even with cardboard boxes of old photos, you belong with us on digipres.club. Many of us are/were Twitter users looking for an inclusive and community supported approach to social media. If any of these things sound good to you, consider joining us now.