The roads I take...

We've known for a long time that we'll need some way of displaying crash information on Firefox OS devices for quality assurance (QA) purposes. Anyone helping in debugging crashes needs to deliver crash IDs to developers, and for verifying that crash reporting works and has the correct settings, QA needs to get crash IDs as well and look at the data in those crash reports.

The bug report linked above has not seen any more in 10 months though, as priorities are elsewhere for most of our developers. Also, this functionality can only be achieved via not-yet-existing APIs or via the "apps" DeviceStorage, which requires certified app privileges, which in turn only preinstalled core apps get and 3rd-party apps cannot get at all. The problem is that the submitted (and pending) crash reports are files in a "Crash Reports" directory parallel to the user profile in /data/b2g and we'd need some form of access to that.

In addition, it's pretty unclear how to do a useful UI there. What I personally envision is doing a list of the date/time of the crashes and next to those put a "share" button that allows people to send the crash ID to a larger-screen device via email, bluetooth or whatever. We could directly link the crash reports on https://crash-stats.mozilla.com/ in theory, but the pages there don't have a layout that looks useful on a small phone screen (right now). On future larger-screen Firefox OS devices like tablets, such a direct link will make more sense.

This would be an app (or a screen of Settings, somewhere deep in the Device Information section, probably under the developer settings) that might have a few challenges in creation, but would be huge in reward as a help to improve stability of Firefox OS as a whole.

Right now, people need adb to get info on the crash IDs and dates, with a command like this:
adb shell ls -l '/data/b2g/mozilla/Crash Reports/submitted'
It would be much better and nicer for our work to have that available somewhere via the device's UI.

If you want to help there, please contact me or comment in the bug cited above.

One thing I found interesting on the software preservation summit was that some collectors told us that people investigating preserved software, e.g. for university studies or for museum exhibits, are often not interested in getting the software itself from the collectors they contact, as very often they already could get that via other channels, esp. when it's software that had been wide-spread at one point - a often-mentioned example that apparently is the corner-stone of all software preservation efforts is DOOM.

What many people of those writing works on preserved software or museums doing exhibits on it do want from collectors in those cases is artifacts, or if you want "meta-materials", around the software itself - packaging, guides, brochures, ads, posters, magazine reviews, and whatnot. With those pieces, any papers or exhibits on the software becomes way more interesting and can also deliver some of the culture around the software.

And that made me wonder somewhat - I know we are preserving all binaries we ever shipped and all code at Mozilla, even our website code, but how much of physical objects related to our software are we preserving? Well, we don't have packaging, but we had CDs for some stuff (I remember one for Mozilla 1.0), we did T-shirts, stickers, etc. - and there's surely magazine articles, the NY Times ad, and similar items. What of all that do we still have preserved? Do we have some kind of archive at Mozilla for that?

Here's a part of my "personal collection" of Mozilla artifacts:

I hope we have a better collection of those things somewhere at Mozilla headquarters or so.

A larger problem for preservation is if you want to preserve the environment and culture that the software was running in, e.g. how it was when you connected the C64 to the TV in your family's home, or even when you ran Altavista (which just has been shut down) for Internet search. At this level, preserving, reproducing or even emulating the environment and experience of older software is becoming really hard - but an interesting challenge esp. for museums trying to educate new generations about our history.

Another, connected, topic is metadata of the software itself - from product names/versions and writers/vendors via info on installation media/packages to file names, checksums and settings of the installed software there is a lot of metadata one can collect along with the preserved binaries and/or code.

For example, NIST's National Software Reference Library (NSRL) - see also this interview by the LoC - is collecting a lot of information about the installed software, and also what it leaves behind when uninstalled (as their original cause is to help the FBI find out what was installed on investigated computers).
And this metadata collection might actually provide us with an opportunity: Knowing the names and checksums of libraries installed with valid software can help us identify at least some of the libraries we see correlated with crashes. For that reason, we recently did get the Dragnet tool online that is intended to help us there, and it would be great if metadata from NSRL or similar efforts can be connected to that and help us in our own investigations there.
So, here's a way that software preservation efforts can directly play back into our current work on understanding current software and improving future releases of Firefox!