Sorry, but this time Microsoft wins. Sunbird is not even a complete piece of software. Last time I used it, not all the menu buttons even did anything. (This was a known problem.)
Indeed, Sunbird has yet to release its 0.2 version, and has never claimed to be a complete piece of software. The developer resources applied to Sunbird and the Mozilla calendaring components in general have grown materially over the last months, during which we've seen important refactoring work to support multiple calendar protocols, rearchitecture of the UI to handle async networking, implementation of initial CalDAV support, improvements in several pieces of the UI (including, you'll be glad to hear, a rationalization of the menu system), and many other smaller fixes. Attachments, attendee management, a sqlite-based local store for improved performance; I could go on, but it's more interesting to read the checkin logs for yourself, I assure you.
Now, as the Wiki indicates -- would that you could get to it! -- competition with Outlook is not a primary goal of Lightning at this point. To do calendaring in the year 2004 requires that you compete with Outlook in some sense, because they really own that market pretty completely, but knocking off their feature set isn't what we're after here. A lot of people have been asking for Sunbird's calendar capabilities (and more) to be integrated more tightly into the Thunderbird mail interface, and that's what Lightning is all about.
I believe that by the summer of 2005 the Lightning project will have developed software that is useful and interesting to a large enough number of people to warrant releasing it. Do I believe that people will abandon Outlook en masse for Lightning in its first release? Seems unlikely. Do I think that there are some users of Outlook who might rather use Thunderbird+Lightning at that point? I'm pretty sure there are.
Exchange interoperability is obviously a hot topic, and rightly so; IMO it was one of the most significant features of Evolution, and one that we're grateful Novell saw fit to release as open source after the acquisition of Ximian. The new protocol architecture we've been designing and implementing over the last few months should accomodate an exchange-protocol plugin, at least on the calendar side, though nobody has yet stepped up to write it. I have reason to believe that a serious contribution of such a plugin, no doubt based on lessons learned from the Evolution connector's source, would be very warmly received into the calendar tree, and featured prominently in Lightning.
I wish I had a local copy of the wiki's Q&A so that I could post it here, but, alas, I do not.
Firefox uses gdkpixbuf for system MIME-type icons and window icons, which are loaded from the local system (GNOME icons or the firefox distribution). It does not use gdkpixbuf for decoding or displaying web-fetched images; it uses the Mozilla cross-platform image library (libpr0n), calling out to libpng, libjpeg and libgif as required underneath.
Anyone who knows the recent history of how
Interbase became Firebird appreciates just how
wretched and bloody and ugly the final months
were before it became open source. There were
folks fighting tooth and nail to give this
incredible product a fighting chance, and I have
nothing but respect for what they have achieved.
From what little I know about the FirebirdSQL database, I have tremendous respect for their technical accomplishments, and the work they did to get their project off the ground.
I do not have any respect at all left for their methods in dealing with conflict. There are a lot of people trying to guess what mozilla.org did or did not do in the search for a new name for Phoenix, and how mozilla.org will or will not use the name "Firebird". These are speculations that don't need to happen, since simply asking politely would have had the questions answered. Instead, the FirebirdSQL crew assumed malice and and "dirty deeds" and went straight from "hey, they're using the name Firebird as well" to "they're evil and we must mailbomb them into the ground, so that they see that we deserve the name more".
I'm not involved in the day-to-day operation of Mozilla anymore, and I've been under email siege for days now. When this whole thing started, I was sympathetic to their emotional reaction, and interested in finding ways to mitigate the (incredibly small) chance of user confusion. Now, I don't want to have anything to do with the Firebird people at all, I no longer care much for their feelings, and I'm very unlikely to expend more effort in trying to reach some sort of outcome that makes them happy. Maybe that was their intent, but maybe I'm starting to understand why their dealings with Borland were so troublesome.
(That they've had historic problems with names and legal issues and whatever other hell they, like any other large project, have endured might explain some of their IMO immature, self-damaging, offensive behaviour, but it sure doesn't excuse it.)
Actually, the very first thing I did when I heard about the conflict was head to Google, where I found that searching for firebird turned up a pile of projects and products, firebird software was just as crowded, and firebird internet completed the trifecta of shared-namespace results. So my take was, and largely still is, that there's a community of projects using the name "Firebird", including many in the software and internet spaces, and that we would be N + 1 to their happy N. Nobody has yet made a convincing argument to me that it can't be the case, nor that FirebirdSQL's million-plus users and developers will disappear because FirebirdSQL is no longer the largest project using the name-part. And believe me, I've heard a lot of argument on this topic.
If a name change is made -- which I find to be unlikely, and which makes the "only a name change will satisfy us" position of the FirebirdSQL people somewhat unfortunate -- I hope it's to "butt-head database".
I am not speaking for mozilla.org here, in case that wasn't clear. I just think that the FirebirdSQL people could have done themselves a lot of good by approaching mozilla.org politely and explaining their concerns, before bitching to the press and inciting mail and forum-bombings, replete with ad hominem nonsense. At the least, they've lost themselves whatever meagre contribution I could have made to a peaceful resolution.
If the application has the "wrong" pattern of allocations and frees, it may be exploitable. One such pattern is the freeing of x, an allocation -- which gets x-(sizeof void *) -- and then the subsequent double-freeing of x.
It would be more amazing if only Opera did that, I think. =)
Mozilla's had bookmark keywords for ages and ages (including parameterization, see http://www.google.ca/mozilla/google-search.html), and Galeon has that need parameterized-toolbar studd.
The mozgest guys have some great gesture bits available for installation, too: http://optimoz.mozdev.org/gestures/.
I think I left ZKS several months back (on good terms, etc., etc.).
I think that Hamnett's message says it all (they couldn't afford to keep operating the network, because of that traditional operating-cost-vs.-revenue balance).
I think that gov't pressure -- should any have actually existed; I don't recall much such pressure from when I was there -- had nothing to do the decision.
I think they picked a very hard market nut to crack, and chose a very high bar for the level of security and privacy they were going to provide.
I think the market didn't share their (our) enthusiasm for that level of service, perhaps unfortunately.
I think a lot of people have talked here and elsewhere about how the Freedom network could have been done better, from technology or marketing or whatever perspectives...
...but I think nobody has done a better job so far of that type of network service.
I think they've learned a _lot_ about protecting privacy and helping other people and organizations protect privacy.
I think there's a market for that knowledge, and good applications of it.
(I'm a Zero-Knowledge employee, but am not speaking for the company except where noted otherwise.)
Opensourcing an app the relies on their own network/servers- big risk, big deal; its just a publicity stunt.
I don't think the ``their own network'' part of the argument indicates a deep understanding of what's going on here: you can configure Freedom to use AIPs that are not owned or operated by ZKS, quite happily.
As far as the server source goes, I'm behind you 100%: the server source must be released, and it will be. We've said this in public, and I'll say it again here: <speaking officially>all of Freedom -- client and server software alike -- is destined for source release</speaking officially>. It's not going to happen all at once -- there's a fair amount of code involved, and trying to bite it all off at once is a recipe for unbridled pain -- but it's definitely going to happen.
When? Soon. Before you've forgotten that you read me write ``Soon''. =)
(Disclosure: I'm a Zero-Knowledge employee, though I'm not speaking for them here.)
One of the primary features of the Freedom system is that it provides IP obscurity: people see your traffic originating at one of the Freedom network ``wormholes'', not from your real IP address. Is that not clear from the whitepapers?
(Disclosure: I am a Zero-Knowledge employee, but I am not speaking for the company.)
The idea here is not that you trust us. The idea is that you don't have to. The name isn't just self-deprecation: the Freedom system is designed to protect us from knowing things about you, as well as protecting you from having us -- and others -- know things about you. The whitepapers cover this approach[*], and the limitations of it, so I won't bore you with the details here.
[*] though they focus on the 1.0 technology, the issues remain largely the same. The biggest change is in the mail system, where the removal of ``reply blocks'' removes the chain-of-warrants attack from that part of the system.
Actually, MPL/GPL isn't the same as LGPL -- consider the case where a developer wants to simply use a single file from the library source, rather than link with the library as a whole. Under MPL/GPL, they can choose the MPL route and have the rest of the code under another (BSD, proprietary, what-have-you) license. Under LGPL, the rest of their code would have to be GPL-or-LGPL covered.
People have expressed a desire for an MPL/LGPL dual -- which is equivalent to an MPL/GPL/LGPL triple, whee! -- rather than a MPL/GPL dual, and that's something that we'll have to look at more closely.
I, personally, think it makes more sense, precisely because of the fact that MPL/GPL code + LGPL library = GPL library -- which isn't really what anyone would want to have happen.
The amount of bizarre falsehood WRT licensing being thrown around here is, as always, impressive, but this stands out especially. The MPL is most certainly an Open Source license, according to the OSD and DFSG.
Dual licensing is not a new concept, luckily, so there's some good precedent here for us to point at. Also luckily, it's not that hard to get around as long as you deal with it in small steps.
First, you can imagine that a dually-licensed source file is really two files: one that has the GPL at the top, and the other than has the MPL at the top. When you use the file -- distribute it, compile it into a binary and distribute that, combine it with other code -- you can choose which of those ``virtual files'' you're dealing with. So if you want to use nsMozFile.cpp with your GNOME app, you might choose to use it under the GPL. But when Netscape builds Netscape 6 from nsMozFile.cpp, they'll probably choose to mean the requirements of the MPL instead of the GPL.
I'll restate that, because it's traditionally the sticking point: a dually-licensed file lets you choose which license you will honour. You have to meet the requirements of one of the licenses, at least, so mixing and matching requirements is obviously out. (Obviously. I'm embarrassed to even mention it.) You do not have to meet all the requirements of both licenses, and in fact it's impossible to do that, because the GPL forbids additional restrictions, and the MPL has several requirements that would fall under that category.
So what about changes? Well, now you've got three choices: you can create a derivative that is GPL-only, or a derivative that is MPL-only, or -- perhaps better still -- a derivative that is also dually-licensed. mozilla.org would certainly prefer that people keep things dually-licensed, for the same reasons that we want to dually-license it in the first place: it serves a larger community of contributors and consumers. Now, we can't require that your derivative be dually-licensed; that would violate the terms of both licenses, I suspect, but certainly the GPL. So all mozilla.org can do is exert control over its infrastructure, and insist that contributions which go into the cvs.mozilla.org tree be dually-licensed. It's still well within anyone's legal rights to create a GPL-only derivative of Mozilla, and fork the world. I think that would suck, a lot, and even RMS has in the past discouraged people from doing that. If nothing else, it would discourage other organizations from going the dual licensing route.
I hope that helps some. I'm really psyched about this; it's been a dream of mine (and others') since before Mozilla was even released, and the success of dually-licensing the JavaScript, NSPR and NSS/PSM code whet my appetite for more. Please join us in the mozilla-license forum for more discussion.
I'm not really concerned about polka-dotted scrollbars either, but there are some other areas where platform widgets tend to fall down (especially current GTK, as it turns out), and some of those are pretty important. Things like variable opacity for input widgets (this whole article is about variable-alpha, right?) and support for mixed font sets in input widgets (key for decent i18n support). The GTK i18n stuff is being improved dramatically by the Pango project, but it's not ready to deploy yet.
Pluggable toolkit support is broken in M16, but will be repaired, and it then might be possible for you to build your own libwidget_darchmare.so that uses all-native stuff. I'm not really expert on the widget-construction code.
So, my jaw fairly dropped when I read the little intro blurb here. The release of the Netscape 6 beta is not the end of the Mozilla project, by any stretch of even CmdrTaco's vivid imagination.
Netscape is the first in what we at mozilla.org expect will be a long list of vendors and organizations releasing Mozilla-based products, and while that's a pretty exciting milestone, it's not our final goal. Lots more work to do.
If you're having trouble with specific parts of the Netscape beta, you might want to try the upcoming Mozilla M15 to see if the bugs in question have been fixed. There are a few familiar reports in the comments here, and some of them are already fixed in the tree. (Nightlies are always a hit-and-miss thing, and have been largely miss in the last week or so, but the brave and self-directed might want to take a peek in the interim.)
13785 was an error, it turns out, and has been remedied.
I'm apparently to look out for other such cases of error, but some at Netscape don't think that I should be able to view Netscape-confidential bugs, so that might get tricky.
Fine, then roll out the red carpet for me by making it as easy to get started as the linux kernel. "make config ; make dep ; make bzImage ; make modules "
How does "./configure; make" sound? If the build instructions bother you, what about filing a bug?
I wish I could take my option money and retire, to be honest. I'm not sure that I would do it, but I won't lie and tell you that I dread being financially independent. The only thing that I'm going away from right now is my current employer, and I certainly plan to stay involved with Mozilla as long as I'm wanted.
If you think I'm not a good open source evangelist, I can't really disagree; I must not have evangelized to you very well at all, though I was certainly trying harder to make Mozilla look good than to make myself look good. (That's the easier task, of course: Mozilla's a lot more lovable than I am.)
As for nights and nationality, people familiar with the project know what hours I work, and from where.
I'm honoured to be grouped with Jamie, though -- he's a fine evangelist indeed. (Even when he makes me cry.)
Slashdot Mirror
Indeed, Sunbird has yet to release its 0.2 version, and has never claimed to be a complete piece of software. The developer resources applied to Sunbird and the Mozilla calendaring components in general have grown materially over the last months, during which we've seen important refactoring work to support multiple calendar protocols, rearchitecture of the UI to handle async networking, implementation of initial CalDAV support, improvements in several pieces of the UI (including, you'll be glad to hear, a rationalization of the menu system), and many other smaller fixes. Attachments, attendee management, a sqlite-based local store for improved performance; I could go on, but it's more interesting to read the checkin logs for yourself, I assure you.
Now, as the Wiki indicates -- would that you could get to it! -- competition with Outlook is not a primary goal of Lightning at this point. To do calendaring in the year 2004 requires that you compete with Outlook in some sense, because they really own that market pretty completely, but knocking off their feature set isn't what we're after here. A lot of people have been asking for Sunbird's calendar capabilities (and more) to be integrated more tightly into the Thunderbird mail interface, and that's what Lightning is all about.
I believe that by the summer of 2005 the Lightning project will have developed software that is useful and interesting to a large enough number of people to warrant releasing it. Do I believe that people will abandon Outlook en masse for Lightning in its first release? Seems unlikely. Do I think that there are some users of Outlook who might rather use Thunderbird+Lightning at that point? I'm pretty sure there are.
Exchange interoperability is obviously a hot topic, and rightly so; IMO it was one of the most significant features of Evolution, and one that we're grateful Novell saw fit to release as open source after the acquisition of Ximian. The new protocol architecture we've been designing and implementing over the last few months should accomodate an exchange-protocol plugin, at least on the calendar side, though nobody has yet stepped up to write it. I have reason to believe that a serious contribution of such a plugin, no doubt based on lessons learned from the Evolution connector's source, would be very warmly received into the calendar tree, and featured prominently in Lightning.
I wish I had a local copy of the wiki's Q&A so that I could post it here, but, alas, I do not.
Mike
Firefox uses gdkpixbuf for system MIME-type icons and window icons, which are loaded from the local system (GNOME icons or the firefox distribution). It does not use gdkpixbuf for decoding or displaying web-fetched images; it uses the Mozilla cross-platform image library (libpr0n), calling out to libpng, libjpeg and libgif as required underneath.
Mike
If Jamie caught you calling him the technical lead of Netscape 5.0, I think he would not be especially pleased.
Mike
Nah, sometimes it's just a slow news day. (Not in this case, IMO.)
MikeFrom what little I know about the FirebirdSQL database, I have tremendous respect for their technical accomplishments, and the work they did to get their project off the ground.
I do not have any respect at all left for their methods in dealing with conflict. There are a lot of people trying to guess what mozilla.org did or did not do in the search for a new name for Phoenix, and how mozilla.org will or will not use the name "Firebird". These are speculations that don't need to happen, since simply asking politely would have had the questions answered. Instead, the FirebirdSQL crew assumed malice and and "dirty deeds" and went straight from "hey, they're using the name Firebird as well" to "they're evil and we must mailbomb them into the ground, so that they see that we deserve the name more".
I'm not involved in the day-to-day operation of Mozilla anymore, and I've been under email siege for days now. When this whole thing started, I was sympathetic to their emotional reaction, and interested in finding ways to mitigate the (incredibly small) chance of user confusion. Now, I don't want to have anything to do with the Firebird people at all, I no longer care much for their feelings, and I'm very unlikely to expend more effort in trying to reach some sort of outcome that makes them happy. Maybe that was their intent, but maybe I'm starting to understand why their dealings with Borland were so troublesome.
(That they've had historic problems with names and legal issues and whatever other hell they, like any other large project, have endured might explain some of their IMO immature, self-damaging, offensive behaviour, but it sure doesn't excuse it.)
Actually, the very first thing I did when I heard about the conflict was head to Google, where I found that searching for firebird turned up a pile of projects and products, firebird software was just as crowded, and firebird internet completed the trifecta of shared-namespace results. So my take was, and largely still is, that there's a community of projects using the name "Firebird", including many in the software and internet spaces, and that we would be N + 1 to their happy N. Nobody has yet made a convincing argument to me that it can't be the case, nor that FirebirdSQL's million-plus users and developers will disappear because FirebirdSQL is no longer the largest project using the name-part. And believe me, I've heard a lot of argument on this topic.
If a name change is made -- which I find to be unlikely, and which makes the "only a name change will satisfy us" position of the FirebirdSQL people somewhat unfortunate -- I hope it's to "butt-head database".
I am not speaking for mozilla.org here, in case that wasn't clear. I just think that the FirebirdSQL people could have done themselves a lot of good by approaching mozilla.org politely and explaining their concerns, before bitching to the press and inciting mail and forum-bombings, replete with ad hominem nonsense. At the least, they've lost themselves whatever meagre contribution I could have made to a peaceful resolution.
Mikehttp://bugzilla.mozilla.org/show_bug.cgi?id=81653
If power users want to try their hands with wobbly features and additional instability risks, we have nightly builds of the wild-west trunk for them.
Mike
traceroute provided an example of an exploit for a double-free in a setuid program.
"that need parameterized-toolbar studd", indeed. Neat parameterized-toolbar stuff. Ahem. Please send sleep.
It would be more amazing if only Opera did that, I think. =)
Mozilla's had bookmark keywords for ages and ages (including parameterization, see http://www.google.ca/mozilla/google-search.html), and Galeon has that need parameterized-toolbar studd.
The mozgest guys have some great gesture bits available for installation, too: http://optimoz.mozdev.org/gestures/.
I think I left ZKS several months back (on good terms, etc., etc.).
I think that Hamnett's message says it all (they couldn't afford to keep operating the network, because of that traditional operating-cost-vs.-revenue balance).
I think that gov't pressure -- should any have actually existed; I don't recall much such pressure from when I was there -- had nothing to do the decision.
I think they picked a very hard market nut to crack, and chose a very high bar for the level of security and privacy they were going to provide.
I think the market didn't share their (our) enthusiasm for that level of service, perhaps unfortunately.
I think a lot of people have talked here and elsewhere about how the Freedom network could have been done better, from technology or marketing or whatever perspectives...
...but I think nobody has done a better job so far of that type of network service.
I think they've learned a _lot_ about protecting privacy and helping other people and organizations protect privacy.
I think there's a market for that knowledge, and good applications of it.
I think they're going to be OK.
I think you shouldn't really care what I think.
(I think Craig's still a dork.)
(I'm a Zero-Knowledge employee, but am not speaking for the company except where noted otherwise.)
I don't think the ``their own network'' part of the argument indicates a deep understanding of what's going on here: you can configure Freedom to use AIPs that are not owned or operated by ZKS, quite happily.
As far as the server source goes, I'm behind you 100%: the server source must be released, and it will be. We've said this in public, and I'll say it again here: <speaking officially>all of Freedom -- client and server software alike -- is destined for source release</speaking officially>. It's not going to happen all at once -- there's a fair amount of code involved, and trying to bite it all off at once is a recipe for unbridled pain -- but it's definitely going to happen.
When? Soon. Before you've forgotten that you read me write ``Soon''. =)
One of the primary features of the Freedom system is that it provides IP obscurity: people see your traffic originating at one of the Freedom network ``wormholes'', not from your real IP address. Is that not clear from the whitepapers?
The idea here is not that you trust us. The idea is that you don't have to. The name isn't just self-deprecation: the Freedom system is designed to protect us from knowing things about you, as well as protecting you from having us -- and others -- know things about you. The whitepapers cover this approach[*], and the limitations of it, so I won't bore you with the details here.
[*] though they focus on the 1.0 technology, the issues remain largely the same. The biggest change is in the mail system, where the removal of ``reply blocks'' removes the chain-of-warrants attack from that part of the system.
Actually, MPL/GPL isn't the same as LGPL -- consider the case where a developer wants to simply use a single file from the library source, rather than link with the library as a whole. Under MPL/GPL, they can choose the MPL route and have the rest of the code under another (BSD, proprietary, what-have-you) license. Under LGPL, the rest of their code would have to be GPL-or-LGPL covered.
I, personally, think it makes more sense, precisely because of the fact that MPL/GPL code + LGPL library = GPL library -- which isn't really what anyone would want to have happen.
The amount of bizarre falsehood WRT licensing being thrown around here is, as always, impressive, but this stands out especially. The MPL is most certainly an Open Source license, according to the OSD and DFSG.
First, you can imagine that a dually-licensed source file is really two files: one that has the GPL at the top, and the other than has the MPL at the top. When you use the file -- distribute it, compile it into a binary and distribute that, combine it with other code -- you can choose which of those ``virtual files'' you're dealing with. So if you want to use nsMozFile.cpp with your GNOME app, you might choose to use it under the GPL. But when Netscape builds Netscape 6 from nsMozFile.cpp, they'll probably choose to mean the requirements of the MPL instead of the GPL.
I'll restate that, because it's traditionally the sticking point: a dually-licensed file lets you choose which license you will honour. You have to meet the requirements of one of the licenses, at least, so mixing and matching requirements is obviously out. (Obviously. I'm embarrassed to even mention it.) You do not have to meet all the requirements of both licenses, and in fact it's impossible to do that, because the GPL forbids additional restrictions, and the MPL has several requirements that would fall under that category.
So what about changes? Well, now you've got three choices: you can create a derivative that is GPL-only, or a derivative that is MPL-only, or -- perhaps better still -- a derivative that is also dually-licensed. mozilla.org would certainly prefer that people keep things dually-licensed, for the same reasons that we want to dually-license it in the first place: it serves a larger community of contributors and consumers. Now, we can't require that your derivative be dually-licensed; that would violate the terms of both licenses, I suspect, but certainly the GPL. So all mozilla.org can do is exert control over its infrastructure, and insist that contributions which go into the cvs.mozilla.org tree be dually-licensed. It's still well within anyone's legal rights to create a GPL-only derivative of Mozilla, and fork the world. I think that would suck, a lot, and even RMS has in the past discouraged people from doing that. If nothing else, it would discourage other organizations from going the dual licensing route.
I hope that helps some. I'm really psyched about this; it's been a dream of mine (and others') since before Mozilla was even released, and the success of dually-licensing the JavaScript, NSPR and NSS/PSM code whet my appetite for more. Please join us in the mozilla-license forum for more discussion.
I'm not really concerned about polka-dotted scrollbars either, but there are some other areas where platform widgets tend to fall down (especially current GTK, as it turns out), and some of those are pretty important. Things like variable opacity for input widgets (this whole article is about variable-alpha, right?) and support for mixed font sets in input widgets (key for decent i18n support). The GTK i18n stuff is being improved dramatically by the Pango project, but it's not ready to deploy yet.
Pluggable toolkit support is broken in M16, but will be repaired, and it then might be possible for you to build your own libwidget_darchmare.so that uses all-native stuff. I'm not really expert on the widget-construction code.
Netscape is the first in what we at mozilla.org expect will be a long list of vendors and organizations releasing Mozilla-based products, and while that's a pretty exciting milestone, it's not our final goal. Lots more work to do.
If you're having trouble with specific parts of the Netscape beta, you might want to try the upcoming Mozilla M15 to see if the bugs in question have been fixed. There are a few familiar reports in the comments here, and some of them are already fixed in the tree. (Nightlies are always a hit-and-miss thing, and have been largely miss in the last week or so, but the brave and self-directed might want to take a peek in the interim.)
(Posted with 2000032909)
I'm apparently to look out for other such cases of error, but some at Netscape don't think that I should be able to view Netscape-confidential bugs, so that might get tricky.
We Shall See.
When you're done banding together to implement RSA without violating their patents, please drop us a line. (Have fun storming the castle!)
There is an ActiveX wrapper for Mozilla, which can be used in place of the IE ActiveX component.
If you think I'm not a good open source evangelist, I can't really disagree; I must not have evangelized to you very well at all, though I was certainly trying harder to make Mozilla look good than to make myself look good. (That's the easier task, of course: Mozilla's a lot more lovable than I am.)
As for nights and nationality, people familiar with the project know what hours I work, and from where.
I'm honoured to be grouped with Jamie, though -- he's a fine evangelist indeed. (Even when he makes me cry.)