guoshuang reader » mozillaZine feedHouse

mozillaZine feedHouse (52 未读)

Alex Vincent: The strangest crash I've seen in a while

提交: January 31, 2010, 3:33pm CST

Tags: [编辑]

Last week, I wrote about a new logging infrastructure I built to track down a bug. In the original post, I warned that logging wasn't a panacea - that it could cause more trouble than it solved. I was more right than I knew, as I added a bit of logging which led inexorably to a crash by JS_ASSERT failure. (For those who don't know what a JS_ASSERT is, it's an assertion inside the JavaScript Engine that all is well. Since JavaScript is one of the primary languages of the World Wide Web, these assertions are really important. If JavaScript is misbehaving, it can't be trusted. Fail one such assertion, and the program aborts, forcing the developer to take notice.)

At first, the crash didn't make a damned bit of sense. I prefer to write JavaScript, not just because I entered into software engineering (and Mozilla development) through JavaScript, but also because it's super-stable. In fact, the only new code I was introducing was in JavaScript. It shouldn't crash. Through an unlikely chain of events, it does.

This article details how I was able to analyze the crash itself, how logging set up the conditions for the crash, and how other logging ultimately proved that the crash resulted from a logging call. I've filed this as bug 543304. Ultimately, reducing this test case to a usable bug report will not be easy - but worth it. More details in the extended entry. (Warning: technobabble content ratio is high. If you do not want to see how this developer thinks and debugs Mozilla code, do not read on.)

Mike Pinkerton: DropBox

提交: January 30, 2010, 2:20am CST

Tags: [编辑]

In the spirit of the title of this blog, I wanted to pass along my experience with some software that...

Robert O'Callahan: Ruapehu Redux

提交: January 30, 2010, 7:29pm CST

Tags: [编辑]

Five Mozilla people at the top of Mt Ruapehu 12 days ago. The crater lake is in the background.

Robert O'Callahan: Three Lessons From A Pernicious Bug

提交: January 30, 2010, 2:21pm CST

Tags: [编辑]

We were having a lot of problems on Tinderbox with xpcshell tests randomly failing on Windows by returning exit code 1. Curiously, it seemed that almost any test could fail this way, with low probability, and the output log for each test indicated that all the actual subtest assertions passed, the process just mysteriously returned an exit code of 1 for no apparent reason.

Naturally I charged into battle with my sword +5 against orange (i.e., VMWare's record-and-replay debugging). The tests failed randomly about one run in a thousand, so capturing a failure wasn't hard. Then I verified that the problematic xpcshell run was passing 0 as the exit code for the final NtTerminateProcess system call, but the outer python script was indeed getting 1 from GetExitCodeProcess. Very mysterious!

I was at a loss for a while until some questions from Benjamin Smedberg led me to observe that in the failing run, the Google Breakpad helper thread was still alive at process termination, but in passing runs, that thread had exited before process termination.

Benjamin then looked into the Breakpad shutdown code and noticed it using TerminateThread to shut down its helper thread. The MSDN documentation for TerminateThread warns that that function is an extremely dangerous API, because it abruptly terminates the thread, leaving any shared resources it was manipulating in a possibly inconsistent state. Nevertheless, the Breakpad shutdown code seems to use it in a safe way ... mostly. We observed that that code was passing exit code 1 to TerminateThread. Changing that exit code to 44 made the exit code returned in our randomly failing tests change to 44. Clearly, somehow the exit code set for the Breakpad helper thread by TerminateThread was becoming the exit code for the process!

We think that, although it's not mentioned in MSDN, TerminateThread is actually asynchronous. The thread is not terminated immediately. If you're (un)lucky, the main thread can trigger process exit (passing exit code 0) before the helper thread's termination is complete. Then, somewhere in the netherworld of NT kernel process finalization, after the main thread has been terminated, termination of the helper thread finally completes and as the last thread to terminate, its exit code is recorded as the process exit code!

Moral of the story: never use TerminateThread. If you must use TerminateThread, you should probably try to wait for termination to finish (e.g. by calling WaitForSingleObject) before exiting the process, if you care about your process exit code. Another moral is that record-and-replay debugging rocks (but we already knew that). Yet another moral is that debugging closed-source operating systems sucks (but we already knew that too).

Doron Rosenberg: Google starts killing IE6 support

提交: January 29, 2010, 6:26am CST

Tags: [编辑]

According to Google's Enterprise Blog, Google is starting to phase out IE6 support, starting with Google Docs and Google Sites by March 1st. While this won't affect the big enterprises (who probably don't use those Google services much), this is a good first step and as more follow IE6 in the enterprise will finally die.

Boris Zbarsky: Cross-compiling success

提交: January 29, 2010, 6:25am CST

Tags: [编辑]

I took another stab at directly cross-compiling (not via distcc) using toolwhip. My previous attempt failed, but not due to libffi at all. The problem there was that I had the Mac ld in my path before the host ld. After fixing that and a few mozilla build system issues and making sure the build system can find the right SDK and the right ar and such I now have a cross-compile setup working. No make package yet, since that requires the dmg-creation utility which I don't have on the Linux machine. No --enable-breakpad support yet due to bug 543111. --enable-shark needs headers I don't have on that machine yet, so I'd need to sort that out. But for basic bisecting, this works.

Just so I can find it later, the working mozconfig file I'm using is something along these lines:

mk_add_options MOZ_MAKE_FLAGS="-s -j10"
export MOZ_MAKE_FLAGS="-s -j10"

mk_add_options CC="ccache /Developer/usr/bin/gcc-4.2"
export CC="ccache /Developer/usr/bin/gcc-4.2"

mk_add_options CXX="ccache /Developer/usr/bin/g++-4.2"
export CXX="ccache /Developer/usr/bin/g++-4.2"

mk_add_options CROSS_LIB_PATH="/Developer/usr/lib:/Developer/SDKs/MacOSX10.5.sdk/usr/lib"
export CROSS_LIB_PATH="/Developer/usr/lib:/Developer/SDKs/MacOSX10.5.sdk/usr/lib"

mk_add_options CROSS_COMPILE="1"
export CROSS_COMPILE="1"

export LD=/Developer/usr/bin/ld
export AR=/Developer/usr/bin/ar

mk_add_options PATH="/home/bzbarsky/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/Developer/usr/bin:/Developer/SDKs/MacOSX10.5.sdk/usr/bin"
export PATH="/home/bzbarsky/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/Developer/usr/bin:/Developer/SDKs/MacOSX10.5.sdk/usr/bin"

ac_add_options --target=i686-apple-darwin9
ac_add_options --enable-application=browser
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
ac_add_options --disable-crashreporter
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --disable-tests

Various other --enable-whatever are hanging out in there too, but the above are sort of the minimal set one needs at the moment.

Robert O'Callahan: H.264 Licensing And Free Software

提交: January 29, 2010, 4:00pm CST

Tags: [编辑]

I've read comments on the Web suggesting that since the MPEG-LA's patent licensing documentation only mentions playback products that are "sold", the MPEG-LA doesn't expect software that is given away at zero cost to need a license. Intrepid LWN reader Trelane actually bothered to ask them, and got a response. Here it is.

The most important part of the response:

In response to your specific question, under the Licenses royalties are paid on all MPEG-4 Visual/AVC products of like functionality, and the Licenses do not make any distinction for products offered for free (whether open source or otherwise).

Also

I would also like to mention that while our Licenses are not concluded by End Users, anyone in the product chain has liability if an end product is unlicensed. Therefore, a royalty paid for an end product by the end product supplier would render the product licensed in the hands of the End User, but where a royalty has not been paid, such a product remains unlicensed and any downstream users/distributors would have liability. Therefore, we suggest that all End Users deal with products only from licensed suppliers. In that regard, we maintain lists of Licensees in Good Standing to each of our Licenses at http://www.mpegla.com.

In other words, if you're an end user in a country where software patents (or method patents) are enforceable, and you're using software that encodes or decodes H.264 and the vendor is not on the list of licensees, the MPEG-LA reserves the right to sue you, the end user, as well as the software vendor or distributor.

Gervase Markham: Protecting Germans I: The Problem

提交: January 26, 2010, 12:28am CST

Tags: [编辑]

Recently the German government, along with the governments of several other countries, recommended (link in German) moving away from IE to "an alternative browser", due to some well-publicized IE security flaws. Blog of Metrics has shown us the effect this recommendation has had on downloads of the German localized version of Firefox - 300,000 extra copies in one weekend.

Unfortunately, we strongly suspect not all Germans will be getting the real deal. Germany is a place where Mozilla has a particular problem with trademark infringement of various types. The most typical of these are:

infringing domain name registrations (e.g. typo domains such as "morzilla.de", "firfox.de")
misleading online content (people pretending to be the official Mozilla download site)
offers of modified versions of Mozillaâs software, e.g. with a changed toolbar, or containing malware
"subscription traps" - where something which seems free actually ends up costing you

I've written about subscription traps in the past. These are fraudulent websites which lead users to believe that they are obtaining a typical free download of Firefox or Thunderbird. Only the small print mentions that by registering for the download, the user undertakes a contractual obligation to pay up to £95 (€105; US$150) per year.

This sucks.

Over the next few days I'm going to be blogging about what Mozilla is actively doing to use our trademarks to protect Germans, and residents of other countries as well, from being ripped off in this way.

My thanks to Anthonia Zimmermann of Lovells for her help in preparing this series of blog posts.

Boris Zbarsky: H.264 patents outside the US

提交: January 25, 2010, 11:47am CST

Tags: [编辑]

I've seen a number of comments recently along the lines of "I'm in Europe, so the H.264 patents don't apply to me; why are you not letting me have a browser that plays my Youtube videos?" So I took a look at the list of patents on H.264. Or rather, the first 6 pages of the 43 page list. Excluding the US, there are relevant patents granted in at least the following countries:

Europe: Germany, France, UK, Finland, Italy, Sweden, Belgium, Bulgaria, Liechtenstein, Austria, Czech Republic, Denmark, Spain, Hungary, Ireland, The Netherlands, Poland, Romania, Portugal, Slovenia
Asia: Japan, China, South Korea, Hong Kong, Singapore, Taiwan, India
Americas: Canada, Mexico
Australia

I wasn't reading very carefully; I'd be suprised if I didn't miss a few, or if a few more don't come later in the list somewhere.

Mike Pinkerton: Task Management, or "Why I'm Neurotic And Inches From The Loony Bin"

提交: January 25, 2010, 8:23am CST

Tags: [编辑]

I'm directly over the city of Columbus, Ohio, amidst a large amount of turbulence that would have spilled any drink...

Asa Dotzler: spring cleaning for firefox

提交: January 25, 2010, 4:35am CST

Tags: [编辑]

It's not quite Spring yet, but with the release of Firefox 3.6, now would be a great time to give your browser a good cleaning.

First, make sure you're on the latest Firefox. In the Help menu, select Check for updates... and apply any updates offered.

Next, let's look at your extensions. Go to Tools -> Add-ons... and select the "Extensions" tab. Scroll through your list of extensions and if you see one that you're not using regularly, go ahead and click the Disable button. This won't remove the add-on, it'll just stop it loading up when you start Firefox. You can always re-enable it if you decide you need it back. Next, look and see if you have any extensions that you disabled in the past that you probably won't be using again. Let's remove those. Simply click the Uninstall button.

Go ahead and restart Firefox at this point. You might already notice a big speed-up in Firefox's start-up time.

Now that we've taken care of extensions, let's look at your plug-ins. Plug-in vendors are notorious for adding plug-ins to Firefox without asking you so you might have a few there you don't need or want. To check, go to Tools -> Add-ons again. This time, select the "Plug-ins" tab. Scroll through that list. In my experience the only plug-ins that are really useful are Flash and Silverlight. (and the "Mozilla Default Plug-in"). Unless you know you need it, go ahead and disable any other plug-ins in the list. This will probably help Firefox perform better and certainly keep you safer. You can always re-enable the plug-in if you find that you need it later.

Go ahead and restart Firefox so these plug-ins get unloaded from your browser.

One final clean-up I like to do is to "vacuum" my history and bookmarks database. There is an extension called Vacuum Places that makes this really easy. Once you install the extension and restart Firefox, you should see a button in your statusbar that will trigger the clean-up. You should only have to do this once (and you can then disable or uninstall the add-on) because Firefox 3.6 now does its own periodic cleaning. This will just give you a jump so you don't have to wait on Firefox to do it automatically.

With those simple steps, you'll probably have a much faster, more stable, and overall happier Firefox.

Gervase Markham: FOSDEM 2010

提交: January 25, 2010, 12:25am CST

Tags: [编辑]

FOSDEM 2010, the premier grass-roots open source conference in Europe, is fast approaching. Every year, I try and persuade the organizing committee to reduce the number of Mozilla talks so that I can take the time to see what other free software projects are up to. Particularly as we had MozCamp EU last year, I hoped that this year it might actually happen. But, as in every previous year, they have managed to find too many interesting people with interesting things to say :-( Ah, well. As well as all of them, I'll be giving a fast Foundation update, and doing a lightning talk on the Bugzilla API.

Speaking of which: if you are coming, and would love (a maximum of) 5 minutes to tell the Mozilla community about your latest project or ask for help with an upcoming idea, then why not propose a lightning talk of your own?

Robert O'Callahan: ActiveX All Over Again

提交: January 24, 2010, 6:28am CST

Tags: [编辑]

Many responses to my post about video codec issues have expressed the opinion that "Mozilla should do whatever is most useful for users today, regardless of 'politics' or 'ideology'" and also that "if a user already has codecs on their system, it's wrong for Mozilla to refuse to use them". These opinions fail due to various legal and technical issues that I've already discussed, but I also want to point out that taking such positions is nothing new for Mozilla and history has proved us right for doing so, in particular regarding ActiveX and Web standards in general.

Perhaps it's not widely known, but Gecko has had code to support hosting ActiveX controls, dating back as far as 1999. ActiveX controls are very much like system video codecs. ActiveX support would have been very useful to users ever since 1999, and still would be now --- certainly in corporate intranets, and everywhere in China and South Korea. Enabling ActiveX support would probably boost our market share significantly. Most users have useful ActiveX controls on their machines. But for the last ten years, even during Mozilla's most desperate days, we have consistently refused to turn this feature on, because we believe that ActiveX is not good for the Web.

I think history has proved that this decision was completely right. Our market share rose anyway. The ActiveX ecosystem was a big vector for security attacks. Most importantly, if we'd caved, the Web everywhere would look like it does in China and South Korea, but more so --- dependent on ActiveX, and tied to Windows. No resurgent Apple, no Linux netbooks, precious few Linux users, no ChromeOS, no iPhone, no usable browsers on phones at all, and Microsoft's grip on the industry stronger than one dare imagine. We would have sacrificed huge long-term wins for users --- ALL users, not just Firefox users --- for the sake of a temporary filip.

During the ascendancy of IE, we had similar pressures over the issue of whether to follow Web standards or focus on IE compatibility. The "pragmatists" wanted us to focus on IE compatibility for the very sensible reason that authors had to develop for IE anyway, so it would be easier and cheaper for them if we just fell in line. Obviously pursuing IE compatibility would also have been good for our market share --- and our users --- at the time. We chose standards. Again, I think history shows we made the right decision.

I'm not suggesting that the consequences of exposing system codecs to the Web would be identical to exposing ActiveX. That's unlikely, and unknowable. But favouring our principles over short-term gains for users is nothing new for Mozilla, and when we've done it in the past, history shows it was the right thing to do.

Mike Shaver: HTML5 video and codecs

提交: January 23, 2010, 1:45am CST

Tags: [编辑]

Recently, Vimeo and YouTube announced that they were moving to support the HTML5 video tag, as DailyMotion did last summer. This is an important step in making video a first-class citizen of the modern web, and that is great news. Unlike DailyMotion, however, Vimeo and YouTube chose to rely on the patented H.264 video encoding, rather than an unencumbered encoding like Ogg Theora. This means that the <video> pages on those sites will not work with Firefox.

Vimeo and YouTube seem to believe that reliance on proprietary plugins for video is a problem on the web. Mozilla believes that reliance on patent-encumbered formats is a problem on the web. Who’s right? Both groups are, in this case; that we can attack, from different perspectives, the multifacted problem of freeing video on the web is an example of the distributed innovation that has made the web such a powerful and popular platform.

For Mozilla, H.264 is not currently a suitable technology choice. In many countries, it is a patented technology, meaning that it is illegal to use without paying license fees to the MPEG-LA. Without such a license, it is not legal to use or distribute software that produces or consumes H.264-encoded content. Indeed, even distributing H.264 content over the internet or broadcasting it over the airwaves requires the consent of the MPEG-LA, and the current fee exemption for free-to-the-viewer internet delivery is only in effect until the end of 2010.

These license fees affect not only browser developers and distributors, but also represent a toll booth on anyone who wishes to produce video content. And if H.264 becomes an accepted part of the standardized web, those fees are a barrier to entry for developers of new browsers, those bringing the web to new devices or platforms, and those who would build tools to help content and application development.

Some companies pay annually for H.264 licenses, which they can pass on to users of their software. Google has such a license, but as they have described, it does not extend to people building from their source or otherwise extending their browser. (Apple and Microsoft are licensors to the MPEG-LA’s AVC/H.264 patent pool, so their terms may differ substantially.) Personally, I believe that it is completely their right to make such a decision, even if I would prefer that they made a different decision.

Mozilla has decided differently, in part because there is no apparent means for us to license H.264 under terms that would cover other users of our technology, such as Linux distributors, or people in affiliated projects like Wikimedia or the Participatory Culture Foundation. Even if we were to pay the $5,000,000 annual licensing cost for H.264, and we were to not care about the spectre of license fees for internet distribution of encoded content, or about content and tool creators, downstream projects would be no better off.

We want to make sure that the Web experience is good for all users, present and future. I want to make sure that when a child in India or Brazil or Kenya discovers the internet, there isn’t a big piece of it (video) that they can’t afford to participate in. I want to make sure that there are no toll-booth barriers to entry for someone building a whole new browser, or bringing a browser to a whole new device or OS, or making and using tools for creating standard web content. And I want that not only altruistically, but also because I want the crazy awesome video (animation, peer-to-peer, security, etc.) ideas that will come from having more people, with more perspectives, fully participating in the internet. The web is undeniably better for Mozilla having entered the browser market, and it would have been impossible for us to do so if there had been a multi-million-dollar licensing fee required for handling HTML, CSS, JavaScript or the like.

I very much believe that Google (both the Chrome and YouTube teams), Vimeo and many others share our desire to have a web with full-featured, high-performance, unencumbered, natively-integrated video, and I look very much forward to us all working — together and separately — towards that end.

People have raised questions about using existing support for H.264 (or other formats) that may already be installed on the user’s computer. There are issues there related to principle (fragmentation of format under the guise of standardized HTML), to effectiveness (about 60% of our users are on Windows XP, which provides no H.264 codec), to security (exposure of arbitrary codecs to hostile content), and to user experience (mapping the full and growing capabilities of <video> to the system APIs provided); I’ll post next week about those in more detail, if others don’t beat me to it.

Robert O'Callahan: LCA

提交: January 23, 2010, 6:08pm CST

Tags: [编辑]

At LCA I found it harder to talk to people than I normally do at conferences, probably because a lot of people already seemed to know each other and I don't already belong to any of those cliques. The same was true at my first computer science conferences, but there I at least had connections to other students and faculty from CMU that I could leverage. At LCA I was often forced to initiate conversations with random people, which is definitely a good thing.

I went to several interesting talks, and some less interesting. Although I enjoyed the joke talks at the time, I think they probably weren't a good use of time. Some of the other talks were just reiterating things I already knew.

One talk that was really useful was the talk about Clutter. I had been wondering if we should be using Clutter somewhere instead of writing our own layers system, but listening to the talk and talking to Emmanuele afterwards, it became clear that would not work. One big design issue is that Clutter animation runs on the main GLib thread, synchronously with application processing (and that will be hard to change), whereas we eventually need to run animation on its own thread. Another big issue is that Clutter depends heavily on OpenGL whereas we need the option to use D3D on Windows.

Jeremy Allison's talk about Microsoft was good. We've feared Microsoft for so long it's become almost unfashionable, but I think Jeremy is right to keep reminding the free software community of the danger there. He talked about Microsoft's attempts to take over the Web, and kindly mentioned Firefox's role in pulling us back from that brink. He made the point (which I think is too often overlooked) that which company one works for is almost always an individual moral choice and we should hold people accountable for it ... we can't let people off the hook by saying "oh, the company I work for is just evil and I can't do anything about it". The focus of his talk was the suggestion that Microsoft is gearing up for an all-out patent war on free software. I don't know if this is true --- honestly, I expected them to do it long ago and I'm not sure what's been holding them back --- but we certainly do need to keep aware of the possibility. Jeremy suggested that Microsoft will promote "RAND" standards --- standards covered by patents whose licenses would require a "Reasonable And Non-Discriminatory" fee, which sound good except that for free software, any non-zero fee is a show-stopper. In fact, as I discussed later in my talk, RAND-encumbered standards won't fly in the traditional Web standards world --- e.g. CSS and HTML5. We have a very good situation there, where everyone understands that any suggestion that can't be implemented in Gecko (MPL/LGPL/GPL) or Webkit (LGPL) is simply a non-starter. However, we do face a very serious situation in video, where the licensing isn't even RAND, and possibly in other technologies such as touch interfaces. It was good to be able to use some of these issues that Jeremy raised as launching points for my talk.

I went to Jan Schmidt's talk about GStreamer. Although the talk wasn't super-interesting, during LCA I did have some interesting discussions with people about whether we should be using GStreamer as the basis of our implementation of HTML5 <video> and <audio>, like Opera is. For now I tend to think it still makes sense to do our own thing, since there's a bunch of stuff GStreamer has that we don't want, like filter graphs and a GLib dependency. But going forward, as we want to add functionality, I think it's definitely something we shouldn't rule out.

Another interesting talk was Andrew Tridgell on patent defence for free software. Most of it was basic stuff about patents that I already knew, but he made one very important suggestion, which was that we need to find a way for free software organizations to collaborate on patent defence by sharing legal information. Right now this is basically impossible; for reasons I don't understand, the legal opinions we get, we are required to keep secret. This makes us vulnerable to a divide-and-conquer strategy because we can't band together to work together effectively on strategy and to share legal advice to keep costs down. Some sort of legal hacking may be required to solve this problem.

Of course, one of the main purposes of conferences is to meet people, and I did. In particular it was great to meet more of the Xiph/Annodex people behind Ogg. It was also great to meet Carl Worth and talk to him about cairo and the layers work that we're doing for hardware acceleration.

The social events were so-so for me, largely because of the issues I mentioned at the beginning, except for the final Penguin Dinner, which was great. The show was amazingly good ... to be honest, I often suspect "culture on display"-style shows of being insulting to everyone involved, but Friday night's was just great. One nice feature of the dinner was that the food was very good and they put out food for every seat at the table, including the seat next to me where nobody was sitting, so I had a double helping of everything I liked. The only really annoying thing about the Penguin Dinner was the relentless fundraising. OK, Life Flight is a good cause, but we can give to good causes without being constantly harangued ... can't we?

Robert O'Callahan: Video, Freedom And Mozilla

提交: January 23, 2010, 3:51pm CST

Tags: [编辑]

Note: below is nothing but my own opinion as a developer of video-related Mozilla code!

My LCA talk on Friday was about why open video is critically important to free software, and what Mozilla is doing about (plus a discussion of the relationship between Web standards and free software in general). Little did I know that Youtube and Vimeo would pick the day before my talk to cast a glaring spotlight on the issue!

Youtube and Vimeo have started offering video playback using the HTML5 <video> element. That is good news for free software, since it means you don't need a closed-source Flash player to play the video [1]. However, they only offer video in H.264 format, and that is not good news for free software. A lot of people have noticed that Firefox doesn't support H.264, and apparently many people don't understand why, or know what the problems are with H.264. This is a good time to restate the facts and re-explain why Firefox does not support H.264. I'll be mostly recapitulating the relevant chunks of my talk. (Hopefully a full recording of my talk will become available from the LCA site next week.)

The basic problem is simple: H.264 is encumbered by patents whose licensing is actively pursued by the MPEG-LA. If you distribute H.264 codecs in a jurisdiction where software patents are enforceable, and you haven't paid the MPEG-LA for a patent license, you are at risk of being sued.

So why doesn't Mozilla just license H.264 (like everybody else)? One big reason is that that would violate principles of free software that we strongly believe in. In particular, we believe that downstream recipients of our code should be able to modify and redistribute it without losing any functionality. This is freedom that copyleft licenses such as the GPL and LGPL (which we use for our code) are intended to ensure. It is possible to obtain patent licenses in a way which works around the letter of the GPLv2 and LGPLv2, but honoring the letter while violating the spirit is not a game we are interested in playing.

But aren't there (L)GPL implementations of H.264? Yes, but they're not as free as they appear. Their freedom has been silently stolen by patents (in jurisdictions where those patents exist and are enforceable). The software license permits you to redistribute and use the code, but the MPEG-LA can still stop you. [2]

But the MPEG-LA won't bother suing me or my project, we're not worth bothering with. Perhaps true, but I hope "remain irrelevant" is not the favoured strategy for most free software projects. It's certainly not an option for Mozilla. If we hadn't distributed Firefox to tens of millions of users --- legally --- it probably wouldn't be possible to browse the Web today using anything but IE on Windows. Plus, relying on selective enforcement is rarely a good idea.

Mozilla should just ship without licensing as a civil disobedience measure. That might be fun, but I expect an injunction would quickly force us to disable H.264 and send a hefty damages payout to the MPEG-LA. That's not a win.

Mozilla should pick up and use H.264 codecs that are already installed on the user's system. I've previously written about a variety of reasons this would be a bad idea, especially on Windows. Really there are two main issues:

Most users with Windows Vista and earlier do not have an H.264 codec installed. So for the majority of our users, this doesn't solve any problem.
It pushes the software freedom issues from the browser (where we have leverage to possibly change the codec situation) to the platform (where there is no such leverage). You still can't have a completely free software Web client stack.

But I could just download gst-plugins-ugly and I'd be OK. That's a selfish attitude. Everyone should be able to browse the Web with a free software stack without having to jump through arcane hoops to download and install software (whose use is legally questionable).

The H.264 patents will expire soon, and then we'll be OK. Many H.264 patents don't expire until 2017 or later. Anyway, H.264 isn't the last word in video compression. There will be an H.265 and the same set of problems will persist.

Users just want video to work. You Mozilla people are such idealists! Yes, that is the reason for Mozilla to exist. Anyway, in the short term, our users probably won't be affected much since Flash fallback will still work. In the long term, I think freedom will ultimately benefit users (not just Firefox users, but all users).

Apart from the issues with H.264 support in clients, there are also huge issues around H.264 for Web authors and content providers. Currently providing H.264 content on the Internet is zero-cost, but after 2010 that will almost certainly change. A couple of good articles are here and here. We won't know much about the terms until the end of this month. The key issue is not exactly how much it will cost, but that if you want to publish H.264 you will probably have to hire lawyers and negotiate a license with the MPEG-LA. If you just want to put a few videos on your Web site, or add a help video to your Web application, or put a video cut-scene in your Web game, that is probably not something you want to do. Web video is not just about Youtube; mandatory licensing would cripple the use of video on the Web. (Just imagine if we had such a regime for still images...) Even if there were no patent issues on the client side, this would still be a good reason for Mozilla to push for truly free codecs.

The honest truth is that none of us know how this is going play out. The proponents of mandatory licensing are strong, and most people don't care about software freedom. We're doing our best to make Ogg Theora rock, and I don't know what else we can do directly right now except spread the word and help people understand what's at stake here ... hence my LCA talk, and this blog post.

[1] Yes, I know gnash and/or swfdec might play these videos, but in general they are not able to keep up with the latest Flash APIs offered by Adobe and used by major sites. Anyway, it's good to not have to play that game.

[2] RANT: in many cases, free implementations of heavily patent-encumbered technology are harmful to the free software ecosystem, for two reasons: people are confused into thinking they have rights that they actually don't, and thus these implementations can discourage the adoption of alternatives that are free for everyone.

Robert O'Callahan: The Road To LCA: Ruapehu

提交: January 22, 2010, 1:52pm CST

Tags: [编辑]

Several Mozilla-related people went to linux.conf.au in Wellington last week. We decided to combine this with our annual outdoorsy "team building for accounting purposes" Auckland Mozilla office event, by driving down from Auckland and spending a couple of days in Tongariro National Park on the way.

So, Sunday night found me, Karl Tomlinson, Michael Ventnor, Josh Matthews, Taras Glek, Matthew Gregan, Chris Pearce, Tim Terriberry and a few others in National Park. The drive down was great ... our visitors finally saw the sheep they'd been waiting for. We had a great dinner at Schnapps Bar, the only hitch being that we exhausted their venison pie special. Our evening was occupied with a six-player game of Settlers. I won.

On Monday the weather report predicted afternoon thunderstorms so our plans to ascend to the summit of Mt Ruapehu were aborted. Instead we took the Whakapapaiti Valley Track from the Bruce Road down to Whakapapa Village, many of us taking a detour to the Silica Rapids near the end. Even though it rained a fair bit, I still really enjoyed this walk. It descends from alpine terrain into forest, crosses some nice mountain streams, and the Silica Rapids look awesome. Photos below.

Monday night's dinner was at the Station Cafe ... pretty good, although I think Schnapp's Bar is better value for money. Monday night's game was Scrabble. Josh won, although I claim I was crippled by getting 4 "I"s on my last tile draw.

On Tuesday the weather was again very cloudy up the mountain and the chairlifts were reported to be closed. Just for the heck of it we drove up to the Whakapapa ski area anyway, and thanks to some fast talking by Karl we managed to hire a guide and get the chairlifts to run us up the mountain to the start of the walk to the Ruapehu summit. Due to people leaving on Monday night and Michael not feeling up to wearing his boots for another five hours, six of us went up: me, Matthew and Casey, Karl, Josh and Taras. It was a fantastic trip. The cloud came and went, but we had great views of parts of the mountain, especially the crater lake. Just being up there eating lunch looking down into the swirling waters of the lake was amazing for a volcanophile like me. (The base of the lake is a molten sulphur plug over the vent; the surface lake water is currently heated to 16-17C and is highly acidic.) The walk up was steep and rockhoppy, but fun, and going down was even more fun, due to a few short cuts that involved butt-sliding down the snow. Highly, highly recommended. I can't wait to do it again.

Our guide Callum was great, and had a lot of stories to tell. He was involved in the rescue operation in 2007 when the volcano belched a few rocks into the Dome Shelter hut and smashed the leg of a climber sleeping there. The DOC ranger we met at the summit claimed that there are still pieces of sleeping bag at the bottom of a hole in the hut floor...

As soon as we got back to the car, Michael, Josh, Taras, Karl and I drove straight to Wellington. We didn't get there in time for the Speaker's Dinner, but I had already expected that ... I heard the dinner was great, but I don't regret choosing Ruapehu instead! I'll blog more about LCA soon. Alpine terrain near the top of the Bruce Road.

A stream in Whakapapaiti Valley. The water was so cold that just dipping my hand made my fingers tingle.

No wonder the venison pie was on special.

Lunch in the Whakapapaiti Valley.

Apparently the water leaches alumino-silica minerals out of the volcanic rock while underground. When it reaches the surface and encounters rapids, carbon dioxide leaves the water and the minerals precipitate out.

Heading up to the Ruapehu summit. Most of the walk ascends rocky ridges like the one you see here.

View of the crater lake from the Dome Shelter area. If you look carefully you can see an outer area of lighter turquoise. The boundaries of that area change slowly as you watch, presumably due to convection from the volcanic heat below. When the volcano is more active you can see more disturbances --- lumps of elastic yellow sulphur rising to the surface, geysers, and I suppose full-on phreatomagmatic blasts, although you only get to see one of those :-).

Sliding down the mountain. Lots of fun, especially with limited visibility.

More fun than static analysis.

A view of Ruapehu on the way to Wellington down the Desert Road. For me, Ruapehu defines the word "mountain".

Eric Meyer: MIX Judging

提交: January 22, 2010, 4:50am CST

Tags: [编辑]

I was recently honored to be asked to be a judge for the MIX 10k Smart Coding Challenge, running in conjunction with Microsoft’s MIX conference. The idea is to create a really great web application that totals no more than 10KB in its unzipped state.

Why did I agree to participate? As much as I’d like to say “fat sacks of cash“, that wasn’t it at all. (Mostly due to the distinct lack of cash, sacked or otherwise. Sad face.) The contest’s entry requirements actually say it for me. In excerpted form:

The entry MUST use one or more of the following technologies: Silverlight, Gestalt or HTML5…
The entry MUST function in 3 or more of the following browsers: Internet Explorer, Firefox, Safari, Opera, or Chrome…
The entry MAY use any of the following additional technology components…
- CSS
- JavaScript
- XAML/XML
- Ruby
- Python
- Text, Zip and Image files (e.g. png, jpg or gif)

Dig that: not only is the contest open to HTML 5 submissions, but it has to be cross-browser compatible. Okay, technically it only has to be three-out-of-five compatible, but still, that’s a great contest requirement. Also note that while IE is one of the five, it is not a required one of the five.

I imagine there will be a fair number of Silverlight and Gestalt entries, and I might look at them, but I’m really there—was really asked—because of the HTML 5 entries. By which I mean the open web entries, since any HTML 5 entry is also going to use CSS, JavaScript, and so on.

The downside here is that the contest ends in just one week, at 3pm U.S. Pacific time on 29 January. I know that time is tight, but if you’ve got a cool HTML 5-based application running around in your head, this just might be the time to let it out.

Asa Dotzler: firefox 3.6 awaits you

提交: January 21, 2010, 8:41am CST

Tags: [编辑]

Help -> Check for updates...

Or, if you're on some other browser, just head over to getfirefox.com

Postbox Team: Indie+Relief Effort to Aid Haiti

提交: January 20, 2010, 4:45am CST

Tags: [编辑]

Today, nearly 150 software developers are participating in Indie+Relief, an effort to help the people of Haiti who are in desperate need of aid. Proceeds from today’s sales will be donated to a variety of charities and support organizations, such as the American Red Cross, Doctors Without Borders, UNICEF and more.

Visit Indie+Relief today to purchase some terrific software and to help those in need.

Ian Hickson: T-Mobile makes no sense

提交: January 20, 2010, 4:02pm CST

Tags: [编辑]

For reasons that aren't material to this rant, I'm trying to get a T-Mobile SIM card set up with T-Mobile's ridiculously named "Even More Plus 500 Talk + Text + Web" plan. At this point I have a SIM card, and after much pain and suffering in phone conversations and online chat support, I have an account that is fully paid up.

Let's log in to the "My T-Mobile" site's "Billing & Payments" page to see how much I currenly owe:

Ok it says I owe $62.42 by 1/19/2010 (today) for service from 2/9/2010 - 3/8/2010 (next month). But it also says that my monthly charges for my previous bill are $127.42 due on 3/9/2010 (two months from now).

None of those numbers seem to add up to $59.99, which is what the "Even More Plus 500 Talk + Text + Web" plan is advertised as costing, but I suppose $62.42 could equal $59.99 if one were to imagine that T-Mobile felt they could put a few "fees" on there that for whatever reason could be assumed not to count. But what's with the $127.42? And what's with the due dates? Let's click "See details" to see details:

Wait, bill summary? I wanted details! And hold on, this page says my account balance is $0.00, and that I paid $62.42 on 1/20/10 (tomorrow). It also gives my monthly charges twice... once as $0.00, and once as $127.42! I guess if you average them it adds up to $63.71, which is similar to $62.42...

Oh look, the details are below the fold.

This says the next service period is $63.71, that they've received $62.42, that the previous balance was $63.71, and that they "adjusted" my account by $65.00 (the result of my calling billing support because they hadn't applied the $63.71 they actually charged me to my account), and apparently that all adds up to me owing $0.00... by 02/05/2010.

Clearly maths is not their strong point. Also not their strong point: being consistent about how they mark up dates. Or how they decide what dates are important.

Oh and... also not their strong point: matching reality. So far they've only actually charged me $63.71, once, though I have in fact tried to pay more than once (earlier today I also tried to pay the $62.42 that some of these pages claim I owe, though my bank has yet to see that charge).

Still, the $127.42 is a bit confusing. Let's see what the "View Bill" button under that number brings up.

Whaaaa!? FPEvenMorePlus 500TTW $119.98? What on earth is that? "Amount due 2/05/10: $127.42"? That completely contradicts the previous page! How much do I owe on that day, $0, or $127.42??

They say the way to work out how much you owe is to dial #225# from the phone, so let's try that... Ok, that says $0. I guess the phone would know best.

I give up trying to work out how much I owe; let's instead try to get the "Unlimited Data" working on this phone. I've heard rumours that one has to buy a $0 optional extra "Unlimited Web" service since otherwise the "Even More Plus Unlimited Web" is actually limited. Add additional services on this line... Internet & E-mail... Aha, here we go. "T-Mobile Smartphone Unlimited Web with FlexPay". That sounds promising. And it's free! Just like the rumours. Let's "buy" that and quickly review the charges:

Added plan and services... $0, yup. Unchanged plan and services... $59.99. Yup. So, the grand total is... $89.99. Wait, wait, hold on, let me recheck the maths here... $0... plus $59.99... carry the one... What??

Ok, ok, clearly it got confused. Let's close the browser and start over. Add additional services on this line... Internet & E-mail... "T-Mobile Smartphone Unlimited Web with FlexPay". And it says FREE. So we click it again, and let's see how much $59.99 + FREE equals this time:

TEN THOUSAND AND EIGHTY EIGHT DOLLARS AND NINETY NINE CENTS?!

I give up. I'll try calling them tomorrow.

Boris Zbarsky: From the mouths of babes

提交: January 19, 2010, 1:19pm CST

Tags: [编辑]

Today Arlan happened to look at my screen when part of the desktop was actually visible. That led to approximately the following conversation:

Arlan:Папа, там лиса! Me:Где? Да, там лиса. Arlan:Еще лиса! Две лисы. Me:Две? Arlan:Один, два, три.... Три лисы!

Little did he know that the fourth one (3.5 to be exact) was hiding under the iTunes window....

Alex Vincent: XPCOM and Logging, part 2

提交: January 19, 2010, 3:36pm CST

Tags: [编辑]

First off, thanks to everyone who took the time to reply to my original blog post. Several people pointed me to moz4js, and I'm quite pleasantly surprised to find out the Mozilla Thunderbird team uses it quite a bit. I hadn't heard of it, but when I did through the comments, I found it had the same problem NSPR logging has: single language support.

Then I realized: if we put moz4js in a JavaScript module, then a component can reference that module and expose the same interfaces to XPCOM. Chrome JS and JS components can load the module, and all other languages can use the XPCOM component. Maybe not simple, but certainly workable.

No, I'm not signing up to own the toolkit moz4js bug. I'm not wholly convinced, personally, it's the right way to do logging. What I do think, though, is that we need a general discussion on logging API's and consumers.

In the bug, Flock mentioned their own API - which I also didn't know about. I mentioned Skyfire has an internal logging system. It makes me wonder how many other companies and projects (Songbird, Komodo, Disruptive Innovations, etc.) have implemented their own logging API's. This is one subject that reasonably affects the whole Mozilla developer community.

If MozPad were still active, this is one subject I'd put right to them and develop a standard logging API for. Since we don't have MozPad anymore, I would like to put it to the community at large:

What do you require logging for?
What logging capabilities do you need?
What logging infrastructure (API, code) have you already implemented or used?
What tests exist and pass for the logging infrastructure you use?
How extensively do you use your logging infrastructure?
How easy is it to work with your logging infrastructure?
If you use someone else's logging infrastructure, what's missing?
Are you willing to work on getting your logging infrastructure into the Mozilla code base? (Writing code, tests, specifications)
Are you willing to work on developing a common Mozilla standard logging API and infrastructure, and getting that into the Mozilla code base? (Writing code, tests, specifications)
Are you willing to actively "own" and drive an effort towards adding a Mozilla standard logging API to the Mozilla code base?

Please reply in the comments. The quality and quantity will tell me how seriously I should be taking this.

(P.S. I found a bug in my logging interfaces already. Not the JavaScript code, but the IDL. Bonus points to the first person to spot it besides me - it's a little undocumented gotcha.)

Asa Dotzler: the french agree with the germans

提交: January 18, 2010, 12:26am CST

Tags: [编辑]

Just a few days after the German government warned users off of Internet Explorer, the French government has done the same.

Yes, all browsers have flaws, some of them security flaws. But IE has a known flaw that has been weaponized. There have been and are ongoing attacks in the wild. It is not safe.

Even if only temporarily, please move to another browser.

update: more on this from BBC

Alex Vincent: XPCOM and Logging

提交: January 18, 2010, 2:01pm CST

Tags: [编辑]

What we have now

Over the last several years, I've learned to appreciate good message logging. Mozilla's NSPR Logging API is a very good example, and works well, for compiled code.

JavaScript components? They can't use NSPR. Neither can chrome, PyXPCOM, or any other privileged code. The best alternative I've got is a dump() statement. dump() writes to the standard error console, commonly known as "stderr". In debug builds, though, stderr gets populated with a bunch of other stuff that I really don't care about at a particular moment. (I'm not entirely clear of blame, either - leftover dump statements from my code pollute that console as much as anything else.)

At Skyfire, I've had to implement a couple logging systems as well, and the generated logs have helped us find and isolate bugs relatively quickly. What you log can help you identify bugs in most cases. They're not a panacea, though: doing it wrong can really cost you.

Over the past few days, I hit a really weird bug in Verbosio's templates system (which I've been quietly working on for about five months now, in a complete rewrite with tests). One test fails at a critical point, but it's pretty far removed from the starting point. Amid all the other dump() statements and debug output, I can't quite figure out where the code started going wrong. To pin it down, I think the best approach is to insert some logging.

Oh, and did I mention that Mochitest includes logging for pass, fail, and todo conditions... but conveniently left out an informational-only logging feature? (Having that helps when you're trying to trace where a log statement came from - and the conditions at the time.)

The five paragraphs above combine to form one idea: Maybe I should implement my own logging service with tests.

Thoughts in the design

First of all, keep it really simple. Most logging implementations I've seen use a module name, a severity level, and a summary string. I figure that plus an optional details string should cover most messages.
For where those messages go, files are good. Streams are better. With a stream, you can feed it into a file, or read it into dump(), a XUL page's multiline textbox, or anywhere else.
Someone reading the logs probably wants a way of separating messages - so if I give them a "multipart" stream, where each part is a separate stream... it's easy to tell each message apart.
Make sure the user requesting the logging stream can specify which messages they want to receive - both by module name and severity level, and whether or not they want the details with each message.
Make sure to cache all the messages, so that a logging stream created later still gets all the messages that came before it.
Finally, since each message ultimately ends up as a simple string - use a simple string stream interface to construct each message as needed.

Did I overdo the design? Probably. On the other hand, it really maximizes flexibility. I don't know how much memory multipart input streams consume, though, so I don't recommend using this in a production environment. If you use this logging service for debugging, make sure you remove all references to it before checking in!

Did it solve my problem?

No.

Oh, the logging itself worked beautifully. But to get some of the data I wanted to log, I had to call other functions. Some of those functions triggered JavaScript garbage collection, which tried to run some cleanup code, which tried to execute JavaScript code I wrote, which resulted in a 100% reproducible crash. I don't yet know what I'm going to do about that. I'll probably first try to reduce the testcase and post it.

Also, logging itself will never solve the problem you've got. All it will do is provide data, and hints about where you are in the code execution. You still have to tell it what and when to log, and you have to read those logs to find the bug.

The good news is, though, that a logging infrastructure like this only took one afternoon to write. Sometimes, that's all I need: a quick, simple component to organize the dirty work into one place.

(The code I wrote I am making available under MPL 1.1 / LGPL 3 / GPL 3 tri-license. If you want it under another license, feel free to e-mail me, and I'll almost certainly say yes. I don't currently plan on submitting this in a bug for landing in mozilla-central, though.)

Gervase Markham: Packages and Trademarks - An Observation

提交: January 15, 2010, 2:10am CST

Tags: [编辑]

Better to have tried and failed than not to have tried at all, right?

Generations of fathers would say to their kids "of course". But it seems not in every case.

A while back, Mozilla and Debian had several goes at coming to an agreement for the use of the Firefox name and logo. In then end, we collectively failed[0], which is something I consider a great shame. Sadly, this failure seems to have left a significant number of free software people with a residual unhappiness and antipathy towards Mozilla. Which is, in some ways, an even bigger failure.

On the other hand, no-one seems to have even suggested that there's a possibility that the new kid on the block will allow their name to be used when Debian packages their software. So Debian are happily and peacefully packaging it under the alternative name. I haven't noticed anyone being upset about this.

Why is that?

[0] And I'm not interested in reopening the debate about who was right. That's not the point of this post.

Gervase Markham: A New Use For JavaScript URLs...

提交: January 15, 2010, 6:32pm CST

Tags: [编辑]

I was just invited by a 'friend' to join a Facebook "free laptop" group whose real aim is to get you to take surveys.

Facebook have obviously decided not to have a "Select All" button on your list of friends when you share stuff, to try and reduce spamming. Here's this group's way around that, from their instructions:

3) After that, Click the 'Invite People to Join' link on the left hand side of the page. (Must do it, it's part of how we can give these buttons away for free!)
4) Erase everything in your address bar... (The address bar is where http://www.facebook.com is typed, where you type in a website to go to.)

Then copy and paste the following code in there and hit ENTER.

javascript:elms=document.getElementById('friends').getElementsByTagName('li');for(var fid in elms){if(typeof elms[fid] === 'object'){fs.click(elms[fid]);}}

5) Once you've done that, all of your friends in the box should turn BLUE, Click 'Send Invitations'

So, how about a JS URL which creates form elements mimicing a Facebook login form, waits for them to autofill, and then posts the contents off to a server? (Or did we fix that?) Or one which inserts a <script> tag with a src at an attack site? If people get used to blindly following instructions like this, no good will come of it...

Robert O'Callahan: Volcanoes And Penguins

提交: January 14, 2010, 7:27am CST

Tags: [编辑]

Next week is linux.conf.au in Wellington. I'm going to be there from Wednesday to Friday, and I'll be giving a talk about why open video is important for free software. Actually I think I'll make it more interesting by broadening it with some discussion of the relationship between Web standards and free software in general.

On the way down to Wellington, a group of Mozilla-related people are going to be stopping at National Park Sunday night and Monday night so we can attempt the Mt Ruapehu summit walk. Should be fun, if the weather cooperates.

Anyway, this means I'll be completely offline Monday/Tuesday and mostly offline Wednesday to Friday next week.

Robert O'Callahan: More On Patch Division

提交: January 14, 2010, 4:51am CST

Tags: [编辑]

Kyle Huey asked me to comment on my approach to breaking up work into a large number of small patches.

First a big disclaimer: I've only been doing this for a short time, but I know other communities have been doing it for a long time. I bet Linux kernel developers know far more about this than I do. Probably many Mozilla developers do too.

As I always have, I try to plan out the work into incremental steps in my head before I actually start writing code. This plan always needs modification after contact with the enemy but it generally works. Each step is of course a new mq patch.

Sometimes I find that additional steps are needed. If I need to add new steps after the point I'm currently up to, there's nothing to do. If I need to add new steps before the point I'm currently up to, it's easy to pop off mq patches and do the work in the right place.

When I think I've completed a step, I often (but not always) do a build to make sure it compiles. However, I rarely test my changes until I've finished the work. Perhaps this makes me a bad person, but I find that test effort before that point is often wasted since I frequently go back and change previous patches as I learn things from writing later patches.

When I'm testing and fixing bugs, I accumulate many fixes as a diff in my working copy. Periodically (once a day?) I take the changes in that diff and distribute them to the patches that each change logically belongs to. I.e., if I fix a bug in new code that was added by a patch, I apply the fix to that patch.

Once the code works, I then reread the patches (a sort of self-review). One thing I look for is large patches that could be broken up into smaller ones consisting of logically independent changes. (I especially focus on the largest patches, to try to minimize the maximum patch size.) Wherever breakup is easy to do (e.g. because the smaller patches don't overlap), I'll do it. If it's hard because patches overlap, I generally won't do it unless the gain in clarity seems large. When patches can be broken up into really tiny fragments, I'm not sure what the correct minimum patch size is ... a patch consisting solely of many instances of the same mechanical change probably isn't worth breaking up, unless different reviewers are going to review each piece.

It's important for bisection searches that at each stage in the patch queue, the project at least builds. To verify this for large patch queues I just run a script overnight that does a loop of hg qpush ; make.

When the code is ready to submit, I upload all the patches to the bug, numbering them with "Part NNN" to make it easier to refer to a particular patch. For large projects it's also helpful to publish the patches as a Mercurial repository using qcommit.

If reviews take a while, as they often do for large projects, every so often (once a week to once a month) I'll refresh the patches to trunk (see below) and push the results to tryserver to make sure nothing's broken.

One tip: at least with Mercurial 1.1, DO NOT refresh to trunk using rebasing (e.g. hg pull --rebase) while you have mq patches applied. Instead, hg qpop -a, hg pull -u, and then hg qpush -a. For me, rebasing screws up my patches in various ways. Also I find that fixing conflicts during rebasing is far more tedious than fixing conflicts during qpush, partly because I have no idea what rebasing is actually doing, but mostly because as of 1.1 rebasing with mq seems to force me to fix the same conflicts over and over again.

Asa Dotzler: html5 and open video for youtube

提交: January 14, 2010, 3:18pm CST

Tags: [编辑]

HTML5 <video> with Ogg Theora codec support seems to be pretty popular among those voting on YouTube feature ideas.

These kinds of voting systems are of course heavily influenced by activist types, but it's still nice to see how dominant this feature request is given all of the other solid ideas in the list.

Gervase Markham: Find A Firefox

提交: January 13, 2010, 8:46pm CST

Tags: [编辑]

The prolific Simon Willison and a happy band of hackers squirrelled themselves away in a fort in October 2008 and built WildlifeNearYou.com. (MySociety site-naming style, perhaps because Matthew Somerville was one of the hackers involved.)

This means I can now point you at a list of places in the world you can go to see a Firefox (a.k.a. the red panda)!

If you know of Red Panda locations not on that list, you need to upload a photo of it to Flickr and follow the instructions in the FAQ. I'm off to add the one in Symbio Wildlife Gardens, Sydney, Australia.

Robert O'Callahan: CSS Absolute Length Units

提交: January 12, 2010, 5:37pm CST

Tags: [编辑]

While reexamining the way we handle screen resolutions in Gecko, we had to reconsider how to handle CSS "absolute length units" --- especially pt, but also in, cm, mm and pc. The spec says that these units should be displayed at their physical sizes, so CSS "1in" is rendered as one inch, etc. Unfortunately this breaks Web content, because most Web pages were designed on desktop screens. A one-inch margin may be fine on paper or on a desktop screen but doesn't make much sense on a two-inch-high phone screen. For related reasons, IE and Webkit have already redefined these units to be fixed numbers of CSS pixels, i.e. 1in = 96px, etc.

After I raised this issue on www-style, it became clear that this is not just an issue of compatibility with existing content. In fact, absolute length units as defined in CSS are only rarely useful. When do you want to force a length to be one inch, no matter what kind of screen is being used or how far from the user's eyes it would be? The only use cases I know of would be touch interfaces and "life size" diagrams. Indeed, the CSS spec says

Absolute length units are only useful when the physical properties of the output medium are known.

On the Web, physical properties of the output medium are almost never known, so the spec suggests that currently absolute length units are useless on the Web.

It seems to me that it will be far more useful, as well as compatible with existing Web content, to specify that absolute length units should take those physical lengths when printed to "normal paper" --- paper (or other media) that you hold when reading, like almost every printed page. Then the browser decides how to render the content on a screen to best express the author's intent. Common sense, as well as Web compatibility, will dictate that the ratios between "px", "pt", "in", "cm", "mm" and "pc" will be fixed based on the assumption that 1in = 96px.

We may find it useful to define a new unit or units, say "truemm", that is a true physical millimeter, for the rare use cases of touch interfaces and "life size" diagrams.

Redefining "in" to not always mean physical inches is quite controversial in www-style. I hope sanity prevails.

Robert O'Callahan: Unifying Abstractions, Dividing Patches

提交: January 12, 2010, 5:15pm CST

Tags: [编辑]

Speaking of architectural misfeatures, one that's been glaring for quite some time now is the Gecko "view system" --- nsIView, nsIViewManager and friends. Originally views were intended to be used as "heavyweight" rendering objects for elements that used "advanced" features such as translucency. Over time it became clear that it was simpler to just support those features directly in the "frame tree" of rendering objects that most elements have, and now we see that everything in the view system would be simpler and more performant if it was handled by the frame system.

However, there are large chunks of functionality still handled in the view system. One big one is scrolling. Scrollable elements have an nsHTMLScrollFrame (or nsXULScrollFrame) which handles layout, scrollbars, and related stuff, except for the actual scrolling --- the visual movement. That is handled by nsScrollPortView. Well, until today, when I landed a series of patches to move all scrolling functionality in the view system out to the frame system. The hard part of these patches is that there were two interfaces exposed to let other parts of Gecko manipulate scrolling --- nsIScrollableFrame and nsIScrollableView. A lot of code was using the latter view-system interface; APIs present in nsIScrollableView but not nsIScrollableFrame had to be added to nsIScrollableFrame, and then all the callers of nsIScrollableView APIs had to be modified to use the frame API instead. This was a lot of work --- not really very hard, but difficult to get right without accidentally causing regressions.

Anyway, it's done. A lot of code that used to have to mess around with views no longer has to know about them. Scrolling code is simplified since it's all in one place. Page load is little more efficient because we don't have to construct scrollable view objects. Better still, this just happened to fix the long hang at the end of Firefox loading the HTML5 spec, since that was all about updating a big pile of scrollable view objects! (There are still some issues with slow script execution ... they're being worked on.)

When I did this work I decided to do a little experiment in development style by breaking up the work into a very large number of small patches, managed with Mercurial Queues. The final commit has 37 separate changesets. I thought this might be overkill since our culture, and Bugzilla, isn't really designed to handle that many patches for a single bug. While Bugzilla (especially the way we use it for code review) could certainly be much better at handling a large set of patches, overall I declare the experiment a resounding success. I think this approach made it much easier for me to keep track of things, made code review much easier and less daunting, and made it much easier for me to keep the patches up to date over several months as the tree changed underneath it. I'll do it again. In fact, I'm already doing it again with the layers work --- more about that later :-).

Robert O'Callahan: There Can Be Only One

提交: January 12, 2010, 4:04pm CST

Tags: [编辑]

For quite a while now, Firefox 3.6 has been done as far as most Gecko work is concerned. Meanwhile all kinds of exciting things are happening on trunk, but we haven't been blogging enough about them. I'll try to do that a bit more starting today, and I encourage my colleagues to do the same!

Since it was first designed, Gecko has supported multiple presentations per document (in code terms, multiple nsIPresShells per nsIDocument). The idea is that you would be able to have multiple views of the same document, each with different style sheets and layouts, and display and even edit the views simultaneously and have them all stay in sync. It sounds cool, and the idea also appears in the DOM specs (see document.defaultView), but the reality is that there is no need for this feature in Web browsers, as Dave Hyatt pointed out a long time ago. (Different views into the same presentation --- e.g., live thumbnails --- are useful, but that's a different and much simpler feature.) Supporting multiple presentations just adds unnecessary complexity.

The only use of multiple presentations in Gecko was for printing and print preview. When printing or previewing a document, we'd create a temporary extra presentation. But for printing you don't need a new presentation for the same document, it's fine to make a copy of the document and create a presentation for the copy. In fact this is a better approach, because you can print or display a preview while continuing to change the original document. You don't want to be displaying a print preview while a script keeps making changes to the document; apart from not being what the user wants, we never supported such dynamic changes properly, so we had to carefully freeze scripting while a print preview was displayed. This was complex and fragile.

Thanks to Olli Pettay this is all history now. He went ahead and implemented the document copying approach for printing and print preview. This approach let us fix a lot of bugs more easily. For example, we can take a snapshot of the current frame of each animated image --- and video, and plugins --- when copying the document, so the copy is truly static (although you can still change the layout, e.g. by changing the page margins). We don't have to worry about temporarily freezing scripts --- we just disable scripting altogether in the copied document.

Better still, this let Olli go ahead and remove the support for multiple presentations. This lets us do various simplifications and optimizations. In particular, before, each presentation had a hash table mapping elements to their "primary frames" used for rendering that element in that presentation. Now a DOM element can have a direct pointer to its primary frame. This is more efficient and also lets us use much simpler code since we no longer need to maintain primary frame maps.

In general there are lots of places in our code where we used to have to think "am I using the right presentation for this document"? We no longer have to think about that.

One architectural misfeature eliminated. Stay tuned for more :-).

Boris Zbarsky: More on distcc

提交: January 11, 2010, 4:48am CST

Tags: [编辑]

A few days ago I mentioned that I've been experimenting with distcc. I finally took the time to do some timings. All times below, unless stated otherwise, are for a completely clean debug non-libxul build on my Mac. In particular, none of the files are in ccache, but ccache _is_ being used (so the compile time includes the cost of caching the new object files). distcc is being invoked via CCACHE_PREFIX. The distcc builds were done with -j10 (I also tried higher -j numbers and saw things between no effect and a slowdown as I got up close to -j20) and allowing 10 distcc connections to the server. The non-distcc builds were done with -j3, which is my normal build setup (since the mac in question only has 2 cores). distcc over ssh did not use ssh connection sharing, and was doing X forwarding on each ssh connection; I should retest with those two things changed at some point, if I decide I don't like doing things over tcp. The network is a wireless 802.11g on the Mac laptop end and gigabit ethernet to the wireless router on the Linux desktop. I found that ,lzo for the distcc builds didn't materially affect things (may have made the build 1-2% faster when used).

Build type	Time
local build on the Mac	38 minutes
distcc over ssh	50 minutes
distcc over tcp	32 minutes

This was obviously distressing. I didn't test distcc over ssh after this, but particularly distressing was the fact that the compilation seemed largely diskbound and therefore distcc didn't help much. This got me started looking into hard drive performance as a function of utilization, since I could swear that the Mac's hard drive has been getting slower as it fills up. Turns out, this is actually the case. So I moved my rarely-used Linux VM to an external hard drive, which took free space on my internal disk from 4GB to 65GB or so. With that change done:

Build type	Time
local build on the Mac	32 minutes
distcc over tcp	22.5 minutes

Progress! Next, I tried dropping ccache, which let me measure the impact of pump mode. Since I do generally see a benefit from ccache, and wanted to measure it, I also tried a build without distcc but with a primed ccache (so build a tree, delete the objdir, rebuild that tree). Results:

Build type	Time
no-ccache distcc in pump mode	16 minutes
no-ccache distcc without pump mode	17 minutes
Local build coming entirely from ccache	15 minutes

So if I were pretty sure I'd almost always be near this Linux box, just not using ccache and using pump mode might be the way to go. As it is, using distcc + ccache seems like a good approach for now.

Now all I need is a way to figure out a way to get this sort of data without it taking several hours, a way to pick good values for -j, and a faster internal hard drive in this laptop.

SeaMonkey Team: SeaMonkey 2.0.2 Update

提交: January 11, 2010, 3:08am CST

Tags: [编辑]

As part of Mozilla's ongoing stability and security update process, SeaMonkey 2.0.2 is now available for Windows, Mac, and Linux as a free download from www.seamonkey-project.org.

We strongly recommend that all SeaMonkey and old suite users upgrade to this latest release. If you already have SeaMonkey 2.0, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting "Check for Updates..." from the Help menu.

For a list of changes and more information, please review the SeaMonkey 2.0.2 Release Notes.

Note: All SeaMonkey 1.x and old Mozilla or Netscape suite users are encouraged to upgrade to SeaMonkey 2.0.x by downloading it from www.seamonkey-project.org.

Gervase Markham: Committers Whose Email Address Has Changed

提交: January 11, 2010, 10:36pm CST

Tags: [编辑]

If you have Mozilla commit access, and your username corresponds to an email address which no longer works, you will have missed important emails about signing the new Mozilla Committer's Agreement. This means

your commit access may go away at any time

(don't make me turn on 'blink') which would be bad. If this is you, contact me, and then follow these instructions, remembering to note on your submitted form the username of your account. And perhaps also file a bug on IT on updating your username.

Asa Dotzler: firefox add-ons

提交: January 11, 2010, 2:32pm CST

Tags: [编辑]

In case you don't read newsgroups, here's some of Mike Beltzner's latest comment:

The JetPack project is very interesting to Firefox, and we are participating (as should all of you, as interested consumers and stakeholders!) in its development both in terms of building the platform and setting requirements on that platform. It is a stated goal of the Firefox team to do what we can to make it easy to install, uninstall and manage JetPacks alongside other customizations such as Add-Ons, Plugins, Search Providers, Themes, and Personas.

We also plan on continuing to dedicate time to working with the JetPack drivers to help them shake out requirements based on existing Add-Ons and what we know the most common compatibility "gotchas" are. It's my sincere hope that mconnor's "call to arms" will be heeded and that everyone contributes to that effort. JetPack is being built specifically for the purpose of making it easier to write customizations for Firefox, so please, tell us what you find difficult and help us understand what your requirements are.

Many people have interpreted mconnor's post to mean that the Firefox product team has already made a strategic decision to remove support for the existing extensibility platform and technology in the near future: this is not the case. What mconnor wrote was that from a strategic perspective, we will be focusing on building an effective and viable alternative platform in conjunction with our extension development community in order to address specific limitations of the current system. I do not see this as a zero sum game, although as a separate but related issue, some specific aspects of the current model may need to be modified for security and performance reasons (I'm referring to binary components, which will likely need to migrate to js-ctypes.)

I hope this clarifies things, somewhat.

And BZ chimes in as well:

I think this hasn't been made clear enough, actually, so here's my attempt to make it clearer.

Right now we seem to have on the order of 10000 (a bit over 11k if I add my numbers right, but it's the order of magnitude that counts) Firefox add-ons on AMO.

Some of these are actively maintained; some are not.

The really popular add-ons, in my experience, have a tendency to be actively maintained. Even on trunk, adblock+ usually works just fine, and more importantly says so in its version metadata. Same for Firebug (it's been worse in the past, but is getting better). That sort of thing.

However there is a very long tail of add-ons that are not as actively maintained. This is fine; people are doing many of these in their spare time, and even the time they take to bump the maxVersion every time we do a new release is much appreciated. But the net effect is that:

1) Possible beta testers tend to avoid trunk builds because their
favorite add-on or three doesn't work with them yet, so we lose
useful feedback. The version check override approach helps some,
but only if the version check is really the only thing preventing
the add-on from working.
2) Doing a release involves getting several thousand people to update
things on AMO (at least the maxVersion, but in many cases more than
that).
3) Since even the updates from step 2 are not enough for the whole
long tail, we end up with users who are running outdated (hence
insecure!) versions of the browser because their favorite add-on
hasn't been updated.

If we can get to a point where we serve, say, 98% of these add-ons with a stable API that doesn't involve any more changes, and if the most popular of the remaining 2% are updated expeditiously anyway, we suddenly find ourselves with a _much_ shorter tail, and the three issues above become much smaller problems. Note that this doesn't involve all extensions using the stable API, nor does it involve preventing truly innovative extensions from being written, nor anything along those lines. It just involves a preponderance of extensions using the stable API. Note that the stable API can have things added to it as needed; this would probably happen based on feedback from extension developers, especially those who are in fact exploring the space of what can be done with things outside the existing stable API.

I think the above list of problems we're trying to solve, and why Jetpack or some other stable API with growing surface area would help us solve them, is so much in the hindbrain of the people who've been banging their heads on this problem that it's easy to forget that none of the above is obvious "from the outside"....

To be clear, the stable API doesn't have to be Jetpack. Jetpack is the current attempt at creating such a thing, as I understand it.

Mike Pinkerton: I hate having to repeat myself

提交: January 10, 2010, 5:31am CST

Tags: [编辑]

I know we've had this conversation before, but I would like to request, beg, plead, persuade, demand, buy flowers and...

Gervase Markham: Got A Fire? Use Firefox!

提交: January 9, 2010, 6:18am CST

Tags: [编辑]

Looks like a friend's theological college in Kenya is using some interesting fire suppression equipment...

Asa Dotzler: firefox growth continues to be amazing

提交: January 8, 2010, 6:58am CST

Tags: [编辑]

The Metrics Blog has an excellent post on Firefox's 2009 growth.

I'm consistently blown away by the scale this project has reached.

Boris Zbarsky: Toolwhip, distcc, and faster compiles

提交: January 8, 2010, 5:19am CST

Tags: [编辑]

Ted recently pointed me to the toolwhip project, which is a way to run Apple's gcc on Linux, cross-compiling to produce Mac binaries. Clearly desirable, since my Linux box is a lot faster than my Mac one. Here are the steps to get it working, as far as I can tell, at least if you Mac has OS X 10.5:

Grab yourself a toolwhip tree following their directions.
Follow the instructions in cctools.README to compile and install cctools. Note that the toolwhip tree comes with an existing usr_include so you can ignore the REQUIREMENTS section in this readme.
Follow the instructions in ld64.README to compile and install ld64. Once again, you can ignore the REQUIREMENTS section.
Download the Apple gcc source for the exact compiler version you want from the Apple site and untar it into a directory called gcc_42-5574 or gcc_42-5566 in your toolwhip source tree. If you plan to use this compiler with distcc, make sure it's the same exact version as that installed on your Mac. If you just plan to cross-compile, I'm not sure that it matters quite as much.
Apply the relevant patch (gcc_42-5574.patch or gcc_42-5566.patch) to the gcc source tree.
Follow the instructions in gcc_42-5574.README or gcc_42-5566.README to compile and install gcc. This time, follow the REQUIREMENTS section as needed; in particular you will need to copy whatever SDKs you want to your Linux box.
Create the following symlinks:
```
  ln -s Developer/usr/bin/gcc-4.2 /usr/bin/
  ln -s /Developer/usr/bin/g++-4.2 /usr/bin/
```
for all those makefiles that call the compiler with an absolute path.

At this point you should have a working cross-compiler. The remaining instructions are for setting up distcc with it.

Grab a toolwhip tree on your Mac a well and follow the directions in distcc.README to build distcc.
Follow the directions in distcc.README to build distcc on your Linux box.

What you do after this point probably depends on exactly how you plan to run distcc and distccd, whether you plan to use ccache, whether you want pump mode, etc. There are lots of directions in distcc.README. So far I have a setup that does distcc over ssh to my Linux box. I'm hoping to sort out the rest of the distcc stuff (not using ssh, and maybe using pump mode) sometime in the next week or so. To get what I have working so far going:

Set PermitUserEnvironment to "yes" in /etc/ssh/sshd_config on the Linux box.
Put DISTCCD_PATH=/Developer/usr/bin in your ~/.ssh/environment on the Linux box.

Now you run a test. In my case, I use ccache, so this worked:

  export DISTCC_HOSTS=bzbarsky@linux-box:/path/to/toolwhip/distccd/on/linux,lzo
  export CCACHE_PREFIX=/path/to/toolwhip/distcc/on/mac
  export DISTCC_VERBOSE=1

and then compiling Firefox normally, using make -f client.mk. If you don't use ccache, you would need to skip the CCACHE_PREFIXgcc-4.2 and g++-4.2 came in your PATH on the Mac before the real compilers and pointed to the toolwhip distcc. I think that should do the trick, but haven't tried it. The ",lzo" in the DISTCC_HOSTS above just says to gzip-compress the data; it can be left out if desired.



Question for those with some distcc experience: is pump mode worth forgoing ccache?

One last note: I have not yet verified that this gives me faster compiles!  Linking has to happen on the distcc client, and that tends to be a pretty slow part...  Perhaps I would be better off just compiling entirely on the Linux box then copying the resulting .dmg to the Mac.

UPDATE:  While the above distcc setup works for compiling an already-configured Mozilla tree, it seems that trying to configure from scratch fails because it thinks it failed to find Core Text, or more precisely because it fails to find ANSI C headers.  But only if you use DISTCC_VERBOSE=1, so don't do that.  It also seems that actually cross-compiling from Linux doesn't work because libffi insists on passing gnu ld options to an ld it detected as not being gnu ld.  That's very sad.



	
	
		
	
	
	
	
	Gervase Markham: Gerv Status 2010-01-08
	
	提交: January  8, 2010, 1:33am CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		Status for the last three weeks and the two weeks before that, which were spent in Mountain View. Highlights:


The Bugzilla API server is now in the same colo as Bugzilla itself! So it should be faster.
If you are are still an active contributor and haven't signed the new Contributor's Agreement, your SCM access is hanging by a thread (even if you work for MoCo :-).

	


	
	
		
	
	
	
	
	Ian Hickson: Phone "support"
	
	提交: January  6, 2010, 8:33am CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		I'm on hold with T-Mobile. The guy is very nice, but there's so much interference I can barely hear what he's saying half the time. Something about me having to pay a month in advance instead of at the end of the month (which I prefer anyway), and something about the order not going through for "reasons unknown" though he has already done "the credit check". Beats me why a credit check is necessary if I'm paying in advance without a contract, by the way, but that's another story. Same thing happened when I paid cash to buy a car recently. "We need to run a credit check". You knock yourself out.
Why can't all this stuff be done by e-mail? Really? I hate phones.
Time passes.
Hey check this out. The support guy gave up, and now I'm doing this all over again with sales! At least the connection is clearer now. Ok so I want the $59.99 plan, which of course comes with a $1.21 non-tax non-government "regulatory" fee and a $35 "activation" fee (given how hard this has been so far, I understand charging an activation fee, though I wonder if we could come to some arrangement wherein I get paid for my part in this ordeal also).
"Sir, what is your phone number?" Well, I don't know, aren't you supposed to tell me that? I mean, I don't have a phone, that's why I'm buying a phone. After trying to explain that I just gave them my Google Voice number — it's not connected to anything but at least they can leave me voicemail, I guess.
Ok, now we have to go through the terms of service... don't forget to opt out of the "you can't use the legal system if we screw you over" option.
"Actually sir, you can't have Flex Pay, you have to have Take Control." I have no idea what that sentence means. I wasn't aware I was trying to get either of those. What are you talking about. "Um..." time passes again "Ok it's going to be $59.99 plus $1.25 tax" (it's not a tax, that's a lie, but we'll let that slide) "so that's a total of $70." I'm going to briefly ignore the fact that those numbers don't add up, and ask where the activation fee went.
"Um... there's no activation fee with this plan."
"It's still the 500-minute, unlimited web, unlimited sms plan?"
"Sure."
"And how do I transfer an existing number to this SIM card?"
"Oh, uh, call technical support when you've received the SIM card. Yeah. We can't do that now but we can do that once we've taken your money, I'm sure."
I so have no idea what I've purchased.
	


	
	
		
	
	
	
	
	Mike Pinkerton: Some phone I heard about
	
	提交: January  5, 2010, 3:23am CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		I've now spent the last few weeks messing around with my Nexus One and I've got a few things to...
	


	
	
		
	
	
	
	
	Gervase Markham: From The Wind
	
	提交: January  4, 2010, 11:42pm CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		It's not possible to search Bugzilla for bugs where a particular flag has been set with no requestee. This means that people sometimes request e.g. review "from the wind" (as bugbot puts it) and no-one notices, so their patch sits there for ages, unloved.

Here is a Greasemonkey userscript which adds a "From the Wind" button at the bottom of buglist pages on bugzilla.mozilla.org. Clicking that button (after a few seconds) trims the list down to only those bugs where "review" (on an attachment) or "approval" has been requested from the wind. (It does this by fetching the bug data from the API and doing the check itself.)

So if you search for all bugs in the relevant component or product with "review?", and then click the button, it'll trim that list down to all bugs with "review?" and no requestee.

Why not take a moment to do this in a product or component for which you have review responsibilities?

Why didn't I use Jetpack? Because at the moment (Firefox 3.6b4, Jetpack 0.7) the authoring experience is really not good. The API documentation doesn't even mention that it uses jQuery (which led to me thinking for a long time that it was missing huge chunks of function), the Bespin code window is way too small and non-resizable, using Ctrl-X/C/V cut-copy-paste scrolls the page to the top, errors appear in the Firebug on the Jetpack page rather than the web page itself, you have to keep clicking "Try out this code" and "clear" on the Firebug on both pages, and I can't see how to step through the code using the debugger.
	


	
	
		
	
	
	
	
	Robert O'Callahan: 19e63a20e092ca81c1ae44694a3e6558
	
	提交: January  3, 2010, 4:16am CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		Robert O'Callahan: 19e63a20e092ca81c1ae44694a3e6558
	


	
	
		
	
	
	
	
	Robert O'Callahan: d525fd19a91535e97ead3f9afa9bfa58
	
	提交: January  3, 2010, 3:40am CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		Robert O'Callahan: d525fd19a91535e97ead3f9afa9bfa58
	


	
	
		
	
	
	
	
	Mike Pinkerton: Because
	
	提交: January  2, 2010, 12:33am CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		I fast-forwarded (because, face it, nobody actually watches commercials anymore) through a Jim Beam commercial yesterday, on New Years Day....
	


	
	
		
	
	
	
	
	Gervase Markham: And End To Ridiculous Email Confidentiality Disclaimers
	
	提交: January  2, 2010, 8:13pm CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		A snippet from the UK government's consultation paper on the future of the Ordnance Survey, page 13, relating to emailed submissions for the consultation:


An automatic confidentiality disclaimer generated by your IT system will not, of itself, be regarded as binding on the Department.


But if it's possible to say that, it means that these ridiculous disclaimers have no legal force, and that fact has been accepted by the government. So can everyone please, please stop using them?


	


	
	
		
	
	
	
	
	Asa Dotzler: firefox for maemo release candidate
	
	提交: January  1, 2010, 4:18am CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		Firefox for Maemo has just achieved release candidate status. w00t!
	


	
	
		
	
	
	
	
	Gervase Markham: DO NOT PUBLISH - Unintended Consequences
	
	提交: January  1, 2009, 7:45pm CST
	
	
	
	
		Tags: 
		 
		
		[编辑]
		
	
	
	
		Ah.

So when I set this blog up six years ago, I started using an unpublished post as a scratchpad to keep all my post ideas in. But it was a bit hard to find it amid all the others, so in order to keep it at the top of the list of posts, I set the date on the post to one in the far future - midnight on 1st January 2010. It now seems like Wordpress automatically publishes future-dated posts when their posting date gets hit. Hence, last night at midnight, my scratchpad (which I have long since stopped using, but never deleted) appeared on my blog, with the wonderful title "DO NOT PUBLISH - Idea Bank". Oops. Fortunately, while it was a random unconnected series of thoughts and URLs, there was nothing embarrassing there.

This was the mistake of the "two-digit year" people. Things last longer than you think :-)

guoshuang reader » mozillaZine feedHouse » January 2010

Feeds

mozillaZine feedHouse (52 未读)

提交: January 31, 2010, 3:33pm CST

Tags: [编辑]

提交: January 30, 2010, 2:20am CST

Tags: [编辑]

提交: January 30, 2010, 7:29pm CST

Tags: [编辑]

提交: January 30, 2010, 2:21pm CST

Tags: [编辑]

提交: January 29, 2010, 6:26am CST

Tags: [编辑]

提交: January 29, 2010, 6:25am CST

Tags: [编辑]

提交: January 29, 2010, 4:00pm CST

Tags: [编辑]

提交: January 26, 2010, 12:28am CST

Tags: [编辑]

提交: January 25, 2010, 11:47am CST

Tags: [编辑]

提交: January 25, 2010, 8:23am CST

Tags: [编辑]

提交: January 25, 2010, 4:35am CST

Tags: [编辑]

提交: January 25, 2010, 12:25am CST

Tags: [编辑]

提交: January 24, 2010, 6:28am CST

Tags: [编辑]

提交: January 23, 2010, 1:45am CST

Tags: [编辑]

提交: January 23, 2010, 6:08pm CST

Tags: [编辑]

提交: January 23, 2010, 3:51pm CST

Tags: [编辑]

提交: January 22, 2010, 1:52pm CST

Tags: [编辑]

提交: January 22, 2010, 4:50am CST

Tags: [编辑]

提交: January 21, 2010, 8:41am CST

Tags: [编辑]

提交: January 20, 2010, 4:45am CST

Tags: [编辑]

提交: January 20, 2010, 4:02pm CST

Tags: [编辑]

提交: January 19, 2010, 1:19pm CST

Tags: [编辑]

提交: January 19, 2010, 3:36pm CST

Tags: [编辑]

提交: January 18, 2010, 12:26am CST

Tags: [编辑]

提交: January 18, 2010, 2:01pm CST

Tags: [编辑]

提交: January 15, 2010, 2:10am CST

Tags: [编辑]

提交: January 15, 2010, 6:32pm CST

Tags: [编辑]

提交: January 14, 2010, 7:27am CST

Tags: [编辑]

提交: January 14, 2010, 4:51am CST

Tags: [编辑]

提交: January 14, 2010, 3:18pm CST

Tags: [编辑]

提交: January 13, 2010, 8:46pm CST

Tags: [编辑]

提交: January 12, 2010, 5:37pm CST

Tags: [编辑]

提交: January 12, 2010, 5:15pm CST

Tags: [编辑]

提交: January 12, 2010, 4:04pm CST

Tags: [编辑]

提交: January 11, 2010, 4:48am CST

Tags: [编辑]

提交: January 11, 2010, 3:08am CST

Tags: [编辑]

提交: January 11, 2010, 10:36pm CST

Tags: [编辑]

提交: January 11, 2010, 2:32pm CST

Tags: [编辑]

提交: January 10, 2010, 5:31am CST