07.29.07
Posted in Camino, Open Source at 12:20 pm by Smokey
In the beginning, there was email. It was open, it was interoperable, and all was well.
Then came the web, and, for a while, it, too was open and interoperable, and all was well.
Then came “online services,” walled gardens that kept their users from the web and interoperable email. They were closed, proprietary ecosystems; interoperability was a late, shoehorned addition. All was not well for users locked inside these gardens.
Then came the days of the lawless, “Wild West Web,” where interoperability was bleeding on the main street outside the saloon after the duel with browser vendors determined to make the web something that only worked in their browser. Users, citizens of this internet junction, were suffering.
Then a new sheriff rode into town, on a fire-breathing red lizard. It was Mozilla, determined to make the internet, all of it (as witnessed by its flagship product, an all-in-one suite of internet applications), open and interoperable again. Lawlessness was at an all-time high, but slowly the sheriff gathered a set of deputies, chief among them Chimera and Phoenix, and later Thunderbird, to help reign in lawlessness and make the internet open and interoperable again and to promote the public benefit. Citizens rejoiced.
Now we are seeing a rise of new walled gardens, the last refuges of those who would partition the internet into tiny fiefdoms where they might lord over their users like serfs. These walled gardens are not open or interoperable; one cannot be in one walled garden and talk to someone in another. They merely leverage the hard-won openness of the web to erect their redoubts and then lock their massive gates. Citizens are beginning to feel the burden of rushing from one walled garden to another in order to communicate with each other.
Who will lead the fight against these new walled gardens, to ensure we do not face another dark era of lawlessness on the internet where communication becomes an impossible or arduous task? The outcome of the Great Thunderbird War will tell.
We must hope the noble and just will win, or we face a dark, uncertain future of walled gardens looming over the open web, and open communication will be only a faint, fond memory.
Permalink
07.18.07
Posted in Camino, Life at 1:24 am by Smokey
Monday afternoon, Josh and Sam turned off pawn, Camino’s venerable tinderbox, after many years of faithful service.
pawn was a 450 MHz Blue-and-White G3 with 512 MB RAM and an 8 GB disk which had been compiling builds for Mozilla since about a year after the code was originally open-sourced. pawn started building Camino in November 2003, about halfway between Camino 0.7 and Camino 0.8. pawn worked hard for Camino, building “hourly” builds that let us know right when someone broke something; building the trunk “nightly” builds that everyone could download and test, until April 15, 2006 (two months past the release of Camino 1.0 in February 2006); and running performance tests on “hourly” builds until 2 PM PDT on Monday. If you look at pawn’s performance graphs, you can trace the history of performance improvements (and regressions) of the Gecko rendering engine over the past four years.
In the end pawn became temperamental, in part because of age, in part because changes on the Gecko trunk made life more painful for Macs running Mac OS X 10.3, and in part because new IT policies at Mozilla required community projects to use different network segments that negatively impacted some test results. While Sam and mento surely won’t miss daily make -C mozilla/content clean fun or reboots (or me poking them to do such), we’ll all miss an old friend.
Thank you, pawn, for distinguished service during 7+ years of continuously building Mozilla and Camino, and enjoy your well-deserved rest. 
(And with that, we also bid a fond farewell to another old friend, Mac OS X 10.3 support in Gecko—catch you on 10.4 or 10.5 for Camino 2.0.)
Permalink
07.05.07
Posted in Camino, Software at 12:32 am by Smokey
Real software developers, at least the hip ones, or the good ones, or the open source/free software ones, have “devblogs” where they keep their users updated on the latest news as they work on new versions of their programs. As we know, I don’t really develop software, but from time-to-time I produce something useful, which I guess means I need to remember to occasionally turn افكار و احلام into a devblog….
It’s been some time since there has been a release of Troubleshoot Camino, largely because there aren’t many more features one could add, and also because there have been no reported bugs (yay!). I had actually been working on fixing one “major” missing feature, version validation, when Stuart announced the “playing nicely in other people’s sandboxes” campaign, so I quickly added the CAMINO_DISABLE_HACKS variable for version 1.1 instead. Following that, Troubleshoot Camino languished on the run up to Camino 1.5.
I picked up the version validation code again the other day and updated it to take into account the “new” Camino 1.5 version number, and today I spent a good bit of time integrating the code and squashing all (?) of the remaining bugs. Now Troubleshoot Camino will prevent you (me ) from launching versions of Camino that don’t work with the underlying fresh profile mechanism; mainly this will be useful for QA when attempting to find a regression range for a bug.
The other big feature missing from Troubleshoot Camino was the ability to localize the messages that are displayed when it is running. I had, like most bad software developers, deliberately left this out of 1.0 and 1.1 so that I could get the program out there (in my “defense,” those versions only have two messages—one of which should never appear—and when Troubleshoot Camino 1.0 and 1.1 were released, there were no multilingual versions of Camino available that supported the underlying fresh profile mechanism). This morning I almost recommended a French user try Troubleshoot Camino to test something, and I remembered I still hadn’t written the localization code. I spent most of today fixing that. (Unlike Cocoa apps where the OS handles the vast majority of the infrastructure for localizable code—getting the user’s preferred language and looking up strings in that language—in plain old AppleScript, you have to write that all yourself.)
Before I release Troubleshoot Camino with these nifty new features, I’d like to get a good collection of localizations. If you’d like to translate Troubleshoot Camino into your language, please take a look at the short guide and then send me your translation. (There’s a pretty bad sample French translation in the guide that I had hacked up when testing the new code; I apologize to my Francophone users for massacring la langue française and welcome a real French translation.) Translations will be warmly welcomed; to prevent duplicated efforts, you can leave a comment below if you are working on translating Troubleshoot Camino into a certain language. Many thanks for your help!
Permalink
