The roads I take...
Displaying recent entries tagged with "Mozilla". Back to all recent entries
February 27th, 2014
One problem for preserving software is that the original hardware that the software did run on might not survive very long. Some people are still keeping some old machines like C64, Apple ][ and others running, but at some point there won't be many left as the original ones wear out or get damaged, and other hardware might not be usable at any more already at this point. And for sure, those machines are not available broadly to the public. Ideally, we'd have the hardware and recreate the full experience, e.g. how you connected the machine to your own TV in the living room and played or worked with it there - but that is pretty unlikely or at least hard to do, esp. with the hardware being less and less available, as I mentioned.
But there's one way to bring at least part of the experience to users: We can emulate the old machines and let the preserved software run within that emulator. That doesn't give us the living-room-TV experience, but there's a better chance in both preserving that way of running the old pieces of software for a long time and making the experience broadly available. Now, it's not always easy to get emulators running well, but there are a number of projects out there, and we heard about a few interesting solutions in the preserving software event at the LoC, but one was particularly appealing to us as Mozillians.
Since the event in May, a lot of work has been flowing into JSMESS, and as Jason has blogged about, there are a thousand cartriges available now in the Historical Software Collection of The Internet Archive, and performance is pretty decent within the browser now.
With that, a whole lot of old software is available for everyone, at any time, to try and experience within their own browser!
That's a powerful way to preserve software for the current world and upcoming generations, isn't it?
December 19th, 2013
I blogged a month ago about how it may affect my customizations and I have dealt with those to a good degree by now, even though not yet even as drastically as I thought when writing that blog post. As always, more will follow. It took me some time until I switched over actually, as I wanted to keep using my theme, but it was naturally not compatible with such a huge redesign.
But after a lot of hours of my free time in the last few weeks, I have experimental support for Australis working in LCARStrek. The new changes living together with support for pre-Australis Firefox in the same theme require quite a few hacks to have a number of styles only apply on one side or the other. But then, I have been doing theme design for long enough (about 14 years now) that I know a few tricks and could use those - thankfully, there are a few changes in attributes set on the main toolbox, for example.
There's still a lot to be done in this area to fix some details (and I see a painting issue that is triggered in the submenus of the new main menu but is probably Linux-specific and connected to transparency used in the arrowpanel), but the main things seems to work decently now. See this screenshot:
Given that I'm using it every day, I hope starting now gives me enough experience with it that I can deliver a really decent theme when Australis finally will ship, probably with Firefox 29.
December 6th, 2013
While the local just asked me if I'd go there, the Mozilla contacts had been asked by the organizers for a speaker to open up the event. We were trying to get someone more used to talking about Firefox OS, but everyone's busy this time of year, so in the end we settled with me doing this keynote.
Now, I have been giving presentations on different occasions and events in the last years, but I never have actually keynoted anything, so that made me somewhat nervous. The other talks that were lined up for the evening were about app development, to some part about very concrete pieces of it, so I figured I should give that some frame and introduce people to Firefox OS, starting with why we are doing it, moving to what and where it is and giving a bit of glance onto where we want to take it. So I came up with "Firefox OS: Reasons, Status & Plans" as the title (my slides are behind the link).
The audience was supposed to be about 50 people, I guess 30-35 really showed up (the pictures, taken "in style" with Firefox OS on my Peak, only show one part of the room), but those were an awesome bunch. They were really into the topic, asked interesting questions, and the talks following me were showing that we really had capable developers in the room, from those that do JS in their free time to those who earn their bread and butter by doing apps.
We also had two Mozillians, both of which I had not met in person before, even though I spent a lot of time in this city in the last decade!
As the event was going on, I was often the voice in the room who would have answers from the Mozilla side or could explain our point of view and initiatives - and in quite a few cases, I could loop back to something I said in my keynote. It was really great to see how apparently I had touched exactly on the right things there and gave everything else a good base to build on. Interestingly, there was quite a bit of interest in the DeviceStorage API, probably because accessing local files is something people can refer better to than storing items in-app. I was thankful someone did a talk on our Marketplace and in-app payment API/Services as that's one area I'm actually weak in, but it also sparked quite a bit of interest. The permission model did also get a few questions.
We surely had people with Firefox OS app experience in there, but I think more of those people might pick up web app development, esp. if more similar events come around, which would be cool. And maybe someone should tell them how to do simple apps without larger libraries or frameworks, and explain app manifests in more detail. I hope they will organize more of those and the chance for that will come along!
November 7th, 2013
I have blogged about what the archive has and can do a few months ago and I probably will mention it again when I get to more posts on preserving software.
I think it's in the best interest of everyone, esp. us as Mozillians, to keep this organization going and make the history of the Internet and more openly available to current and future generations.
Please help them to rebuild and continue on their way and make a Donation. I will for sure.
November 1st, 2013
One idea would be to award badges automatically to people who leave their email in a crash report (i.e. a badge for taking part in our efforts by delivering data through crash reports) - but that would probably end up being a bad badge because you' award people for crashing Firefox (and not award people who don't see crashes). We really do not want people to search for how they can crash so that they can get a badge - after all our mission is to avoid crashes, not provoke them. So, no badges for submitting crashes (thanks to Benjamin for pointing me to that issue right away when I was rolling that idea).
So, how can we potentially award a badge for Stability/"CrashKill" work without rewarding bad behavior?
One thing I could think of was "filed x crash bugs that ended up fixed". That should be relatively easy to get out of Bugzilla data and I think there's no doubt that filing bugs that end up with a fixed resolution is a good thing.
This idea would also open up the avenue for different badges for different amounts of badges (similar to the webdev badges), or to create a badge for developers who fixed x crash bugs, and similar things.
What do you think? Which ideas do you have for awarding badges for contributions to the Mozilla Stability program?
October 28th, 2013
Derzeit gibt es nur kommerzielle Anbieter für so etwas, allen voran Google Location Service, aber eine offene Variante öffnet die Tür für Implementierungen, die mehr Wert auf Datenschutz und Privatsphäre legen und trotzdem den gleichen Komfort bieten (z.B. könnte man einen Ausschnitt der Daten für eine Umgebung lokal herunterladen und dann ohne Übermittlung der genauen Daten eine Ortsbestimmung lokal durchführen).
Für so einen Service braucht man jedenfalls die an sich öffentlich einsehbaren Daten über die "sichtbaren" WLAN-Netze und Telefonmasten an verschiedenen Orten. Diese Infos wollen wir über Crowdsourcing gewinnen, und eine "Stumbler"-Anwendung für Android ist verfügbar, die diese Arbeit verrichtet (natürlich sind die Quellen für den Stumbler und den Server genauso offen wie eine API zum Service, wir sind schließlich Mozilla).
Hilfe ist natürlich erwünscht, vom Senden der Daten mittels Stumbler bis zur Verbesserung dessen und auch der Server-Seite!
September 8th, 2013
Now, what I'd really like to see, though, is an app that runs locally on the Firefox OS device in its entirety, and which has a UI that is useful and nice on a phone. Especially the latter might mean not implementing all the fancy functionality that many IRC clients have, but only those parts required for some simple chatting.
We have the technology to run a full IRC client on a Firefox OS phone with the TCPSocket API, and the simplicity of the IRC protocol would make it a nice reason for someone who wants to play with this API.
The UI, OTOH, would make a very interesting challenge for someone who like UX design, as on a phone, you need to be way more minimalistic, and you probably need to consciously decide what functionality and which elements to leave out, or implement completely differently than what we might be used to.
I'd really love to be able to have an easy way to tell my manager via IRC that I'll be late for a 1:1 while I'm on my way, or be able to make a quick inquiry in a chat channel while I'm traveling.
Anyone up for the challenge?
August 2nd, 2013
Jason talked about multiple efforts he's involved in, including his early (and ongoing) work on textfiles.com, collecting writing from the time when people first got online, and some other initiatives I'll mention at the end of this blog, but the main focus was on The Internet Archive, the non-profit he is working for nowadays and which has public collections of historical digital content as its main mission.
The site and organization are probably best known for the Wayback Machine, which has archived "over 240 billion web pages" going back more then 15 years, see e.g. a Mozilla homepage from around the time when I first encountered the project. But next to that, they have tons of other digital content archived - video, audio, texts, and more. Jason said they are basically seeking to store everything available in digital format that could be of any historical use at some point - preferably first making sure it's store and worrying about legal questions only as they arise, as it's better to have something but take it down than to be able to publish it but not having lost it to history. He went as far as to say they want to be "the hard drive of the Internet" and store everything anyone gives to them, be it personal documents, software that was published at some point, or other digital content. For example their software collection contains collections of entire FTP servers of the past as well as CD images and terabytes (!) of software and firmware for old systems to run in emulators.
And there's an "Upload" button on the site as well, inviting me, you, and everyone else to contribute content that they can archive!
So, if you have old digital content lying around, go to archive.org and make it available to the public, including the kids of the future, before it gets covered with enough dust or otherwise degrade in a way that the media can't be cleanly read any more.
If you have really important pieces of history that are on media that you fear is too dusty and old to still be read cleanly, or where it's hard to find any drive to read that media any more, or you know of such things that might otherwise be hard to recover, you might be interested in another project that Justin Scott is involved in: the Archive Team. That group is dedicated to rescue old digital contents where it's not easy, and to save history before it's actually lost. They have specialized equipment to read even aged disks and tapes, and they are building up communities to save sites before they die - they even archived most of Geocities before it died!
A quite awesome story is also how they helped to recover the original "Prince of Persia" source code.
All those projects can profit from your help, so if you have anything you can contribute, please do so!
July 22nd, 2013
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.
July 18th, 2013
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!