The roads I take...
KaiRo's weBlog
| Zeige Beiträge veröffentlicht im Juni 2007 an. Zurück zu allen aktuellen Beiträgen | |||||||||||||||||||||||||||||||||||||||||||
28. Juni 2007
SeaMonkey on magazine CD
The German computer magazine CHIP asked me for permission to include (German) SeaMonkey on their freeware CD in their 09/2007 issue. Not that they actually would need to ask anyone for permission to distribute our open source software (as long as they comply with the licenses), but it's nice to know they are spreading our application 
Von KaiRo, um 16:35 | Tags: Mozilla, SeaMonkey | keine Kommentare | TrackBack: 0
25. Juni 2007
Weekly Status Report, W25/2007
I spent lots of time this weekend at the Donauinselfest, one of the biggest yearly open air festivals with reportedly 2.6 million visitors spread over three days this year (my pics from the event are already online).
Leading up to that, I managed to do a share of SeaMonkey work as well in week 25/2007 (June 18 - 24):
Items where nothing happend but which I hope to to get some traction on again:
The list of things I've done might look rather short (and I wonder myself about this), but it shows again what amount of time some single tasks like a mere sync of two existing "code bases" (or actually "string bases" in this case) can suck up. And I think the improved quality we'll be able to provide all German users (and probably users of all languages through the en-US bugs spun off this) is really worth that time.
Leading up to that, I managed to do a share of SeaMonkey work as well in week 25/2007 (June 18 - 24):
- Bugzilla reorganization:
Lots of discussion in m.d.planning about the future product/components structure of bmo. Looking better with every revision Gerv makes - places history:
Updated patch for switching the backend, got CVS copy for nsIBrowserHistory.idl in toolkit and updated patch for building toolkit mork history for non-places non-SeaMonkey apps only, which got review. - German L10n sync:
I spent most of my time with that this week. Filed bugs and patches for syncing up dom/, netwerk/, and editor/ui between CVS and my long-lived MozillaTranslator glossary (in addition to the security/manager one I had filed earlier), which sparked a lot of discussions, some of which are still going on, most of which have been settled now though. I also discovered a bunch of cases where my colleagues fixed problems in general strings silently in the de locale, though it would improve quality for everyone to have this fixed in en-US first instead. I filed bugs for those cases we discovered, and also did a few patches for the easy cases. This should be done more often, it helps everyone. - Various discussions:
Form controls regression, user agent rant and proposal/idea, suiterunner regressions, info bars, debug UI, Firefox 3 UI, and others
Items where nothing happend but which I hope to to get some traction on again:
- xpfe cleanup:
Not much happened this week on that front, need to look into that again soon. - Killing wallet:
Neil provided new patches to sync up autocomplete for getting this to work. He reported he got an auocomplete popup on his local build, so it looks like we're getting somewhere. Neil is away (yes, really, not only in his nick) this week though.
The list of things I've done might look rather short (and I wonder myself about this), but it shows again what amount of time some single tasks like a mere sync of two existing "code bases" (or actually "string bases" in this case) can suck up. And I think the improved quality we'll be able to provide all German users (and probably users of all languages through the en-US bugs spun off this) is really worth that time.
Von KaiRo, um 16:26 | Tags: L10n, Mozilla, SeaMonkey, Status | 2 Kommentare | TrackBack: 0
23. Juni 2007
A possible idea for user agents
When I went to bed late last night, I was not completely satisfied with the blog rant I had just written. Not that anything would be wrong with what is in there, I stand by that. But just ranting cannot be the solution - there must be some way to get what Camino people want without making UA strings suck even more.
Up to now, there are several possible ways in which people deal with websites closing out people because of UA strings they "don't recognize":
But then, I realized, all those solutions are so 1990s, so static, so Web 1.0 - and we're all talking in terms of the modern, new, shiny, dynamic Web 2.0 all the time. So maybe that great new world may have a better solution for that problem as well. And actually, I think it really has. I began to think we could just combine all the methods above with some other tooling we have, make everything dynamic, and we have a cool, new approach!
Firefox has this nice feature of preventing phishing through lists of known phishing sites it dynamically updates from the web. Currently, there's a plan to do a very similar thing for completely blocking sites that offer malware in Gecko.
So, what about having a list of sites that need UA spoofing, dynamically maintained by our users, and dynamically downloaded and used by the web browser? That way, we would specifically only spoof our UA (by adding any token the site needs) on specific websites. The list would have the domain name where spoofing is needed along with what sort of spoofing, the client would follow those rules.
Of course, it's bad to do this automatically without telling the user that we are doing non-standard things - after all, the website might tell the user he is using Firefox even though he's using Camino. But then, there's this nice idea of info bars in the browser, which we could use for giving the user feedback about what's happening:
This is just a graphical mockup of how it would look, of course - I haven't implemented anything.
The "More Info..." button would open a new tab/window (depending on user prefs) with a page that carries all kind of info about our spoofing of UA strings on this website. The user can leave his comments there, find a contact where to nag the webmaster about this problem, etc. Of course, this is a page on our central site that also delivers the dynamic list and where our users can add spoofing for sites, change spoofing options for those sites, and similar things. This should be driven by the community and should combine the reporting system with evangelizing options.
Of course, several points are still open in this concept:
I'm willing to help with bits and pieces where I can, but I'm not a big XUL hacker and I have very little time to work on yet another new project.
It would be very cool to find someone who could implement a system like that.
If we design it well, it can help lots of browsers, not only Minefield, Camino and SeaMonkey, but also any number of others who could implement the same system.
Actually, we may even be able to leverage that system for going back to really short and useful UA strings for all our browsers, including even Firefox. Who knows?
Up to now, there are several possible ways in which people deal with websites closing out people because of UA strings they "don't recognize":
- Extend the UA string with some token they recognize. As said in the other post, this sucks. A lot.
- Evangelizing. Find out what kind of errors the site is making with browser detection, mail the webmasters, tell and help them to improve the situation. That's hard, manual work, often with very little reward, but where it helps, it makes the web better for everyone.
- Selective UA spoofing on the user side. Extensions like PrefBar give you a handy dropdown menu to spoof certain well-known UA strings when accessing websites, and a good way to switch back to the default. This is handy for experts, but normal users don't understand it. Additionally, the accessed websites don't even see your browser in any stats - and there's a high risk that you hide your real browser in more occasions than necessary.
But then, I realized, all those solutions are so 1990s, so static, so Web 1.0 - and we're all talking in terms of the modern, new, shiny, dynamic Web 2.0 all the time. So maybe that great new world may have a better solution for that problem as well. And actually, I think it really has. I began to think we could just combine all the methods above with some other tooling we have, make everything dynamic, and we have a cool, new approach!
Firefox has this nice feature of preventing phishing through lists of known phishing sites it dynamically updates from the web. Currently, there's a plan to do a very similar thing for completely blocking sites that offer malware in Gecko.
So, what about having a list of sites that need UA spoofing, dynamically maintained by our users, and dynamically downloaded and used by the web browser? That way, we would specifically only spoof our UA (by adding any token the site needs) on specific websites. The list would have the domain name where spoofing is needed along with what sort of spoofing, the client would follow those rules.
Of course, it's bad to do this automatically without telling the user that we are doing non-standard things - after all, the website might tell the user he is using Firefox even though he's using Camino. But then, there's this nice idea of info bars in the browser, which we could use for giving the user feedback about what's happening:
This is just a graphical mockup of how it would look, of course - I haven't implemented anything.
The "More Info..." button would open a new tab/window (depending on user prefs) with a page that carries all kind of info about our spoofing of UA strings on this website. The user can leave his comments there, find a contact where to nag the webmaster about this problem, etc. Of course, this is a page on our central site that also delivers the dynamic list and where our users can add spoofing for sites, change spoofing options for those sites, and similar things. This should be driven by the community and should combine the reporting system with evangelizing options.
Of course, several points are still open in this concept:
- The (advanced) user needs a possibility to opt out of spoofing for the site (for testing)
- The (advanced) user needs to be made aware of how to report pages in the first place
- Perhaps the user needs an option to mute the warning for pages he visits very often?
- and lots of others...
I'm willing to help with bits and pieces where I can, but I'm not a big XUL hacker and I have very little time to work on yet another new project.
It would be very cool to find someone who could implement a system like that.
If we design it well, it can help lots of browsers, not only Minefield, Camino and SeaMonkey, but also any number of others who could implement the same system.
Actually, we may even be able to leverage that system for going back to really short and useful UA strings for all our browsers, including even Firefox. Who knows?
Von KaiRo, um 14:00 | Tags: mozconcept, Mozilla, UA String | 8 Kommentare | TrackBack: 0
The fight for the suckiest UA string
Sure, User Agent strings suck. Well, actually, they are useful - at least for statistics.
This way, browser usage on different websites can be monitored and interesting stats can be generated, just like I did some time ago here.
And there are good specs that describe how a user agent should look (defined in HTTP 1.0 and HTTP 1.1 RFCs) - but even those already state "Note: Some existing clients fail to restrict themselves to the product token syntax within the User-Agent field."
Yay - the spec already notes that clients don't comply with the spec. Nice.
But it's even worse: The spec notes for what purpose this HTTP header should be sent: "This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations."
Over the years, many web site designers extended the "avoid particular user agent limitations" to "block any unknown client from accessing content" though - and with this, all the problems started.
Websites started to sniff for "Mozilla/" at the start of the UA string (which Netscape had) and gave only those clients access to their (most of the time) non-standards-compliant content that it somehow displayed, and they did this hard enough that Microsoft could not release their browser without the "Mozilla/" at the start of the string, unless they wanted to be blocked from content. And clearly they didn't. Following that, almost any decent browser had to use Netscape-style "Mozilla/" user agent strings, even if they weren't the mythical "Mosaic killer" that this internal code name stood for.
When the Mozilla project wanted to note a Gecko version, and later the Firefox name and version, they were forced to hold on to the more and more useless "Mozilla/" prefix and some syntax surrounding it, and just add additional product tokens, ending up with a standards-compliant, but a bit lengthy convention for Mozilla user agents - which also SeaMonkey is using.
Instead of a handy
When those website that use user agent sniffing would do it correctly, they would send W3C-compliant content to every unknown browser and only do small tweaks for those which don't comply correctly (along with explicit checks for only those versions that are known not to comply, still sending the W3C-compliant version for future releases that might fix this) - and we would never have ended up even at this stage.
But that's not even where the story ends, actually, it gets much worse:
When Gecko gained market share, browsers like Konqueror and Safari began adding "(like Gecko)" to their UA string to fool websites testing for "Gecko" in the UA string into letting them in when they would close out anything beyond MSIE and Gecko. And then, we arrived at the stage where Firefox gained a whole lot of market share and those crappy web designers decided to let "Firefox" into their websites, apparently not knowing that Gecko is Gecko and Firefox is "just" Gecko plus a nice UI (which is cool enough, actually). Because of that, there is a number of websites that don't work in non-Firefox Gecko browsers even if they could - that includes SeaMonkey, the Firefox development builds labeled e.g. "Minefield", and also Camino.
Instead of helping us all and the whole web with increasing the market share of non-Firefox Gecko browsers and making web designers aware of the problem and the easy solution (yes, the by far hardest part), the Camino team is now trying to win the prize for the suckiest UA string of them all by adding a "like Firefox" string to their UA. WTF?
If we're continuing on this path, every useful browser will have to add this, and probably a few other strings, in the future. I don't intend to support this or any project which decides to go down that road.
It would have been nice if one day I could have used
or something like that.
The new proposal sounds like I may end up with one in this style though:
Thanks to the Camino team!
This way, browser usage on different websites can be monitored and interesting stats can be generated, just like I did some time ago here.
And there are good specs that describe how a user agent should look (defined in HTTP 1.0 and HTTP 1.1 RFCs) - but even those already state "Note: Some existing clients fail to restrict themselves to the product token syntax within the User-Agent field."
Yay - the spec already notes that clients don't comply with the spec. Nice.
But it's even worse: The spec notes for what purpose this HTTP header should be sent: "This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations."
Over the years, many web site designers extended the "avoid particular user agent limitations" to "block any unknown client from accessing content" though - and with this, all the problems started.
Websites started to sniff for "Mozilla/" at the start of the UA string (which Netscape had) and gave only those clients access to their (most of the time) non-standards-compliant content that it somehow displayed, and they did this hard enough that Microsoft could not release their browser without the "Mozilla/" at the start of the string, unless they wanted to be blocked from content. And clearly they didn't. Following that, almost any decent browser had to use Netscape-style "Mozilla/" user agent strings, even if they weren't the mythical "Mosaic killer" that this internal code name stood for.
When the Mozilla project wanted to note a Gecko version, and later the Firefox name and version, they were forced to hold on to the more and more useless "Mozilla/" prefix and some syntax surrounding it, and just add additional product tokens, ending up with a standards-compliant, but a bit lengthy convention for Mozilla user agents - which also SeaMonkey is using.
Instead of a handy
"SeaMonkey/1.1.2 (Windows NT 5.1; de-AT) Gecko/1.8.1.4" (which would tell all statistics-relevant data and have a common "Gecko" name and version to detect to "avoid particular user agent limitations" common to all Gecko products), we end up with "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.4) Gecko/20070617 SeaMonkey/1.1.2" because of that legacy.When those website that use user agent sniffing would do it correctly, they would send W3C-compliant content to every unknown browser and only do small tweaks for those which don't comply correctly (along with explicit checks for only those versions that are known not to comply, still sending the W3C-compliant version for future releases that might fix this) - and we would never have ended up even at this stage.
But that's not even where the story ends, actually, it gets much worse:
When Gecko gained market share, browsers like Konqueror and Safari began adding "(like Gecko)" to their UA string to fool websites testing for "Gecko" in the UA string into letting them in when they would close out anything beyond MSIE and Gecko. And then, we arrived at the stage where Firefox gained a whole lot of market share and those crappy web designers decided to let "Firefox" into their websites, apparently not knowing that Gecko is Gecko and Firefox is "just" Gecko plus a nice UI (which is cool enough, actually). Because of that, there is a number of websites that don't work in non-Firefox Gecko browsers even if they could - that includes SeaMonkey, the Firefox development builds labeled e.g. "Minefield", and also Camino.
Instead of helping us all and the whole web with increasing the market share of non-Firefox Gecko browsers and making web designers aware of the problem and the easy solution (yes, the by far hardest part), the Camino team is now trying to win the prize for the suckiest UA string of them all by adding a "like Firefox" string to their UA. WTF?
If we're continuing on this path, every useful browser will have to add this, and probably a few other strings, in the future. I don't intend to support this or any project which decides to go down that road.
It would have been nice if one day I could have used
SeaMonkey/4.3 (Linux x86_64; de) Gecko/3.2or something like that.
The new proposal sounds like I may end up with one in this style though:
Mozilla/5.0 (X11 [like Windows]; U; Linux x86_64 [like Intel Mac OS X]; de [like en-US]; rv:3.2) Gecko/20100704 (like KHTML) SeaMonkey/4.3 (like Firefox) (like Safari) (like Opera) (like Netscape) (like MSIE) (like Mosaic)Thanks to the Camino team!
Von KaiRo, um 03:23 | Tags: Mozilla, UA String | 9 Kommentare | TrackBack: 1
22. Juni 2007
Better quality for everyone
Since Firefox landed on the L10n CVS, German localizations for Mozilla core strings have been done separately in two places: On one hand, there was my private MozillaTranslator repository holding the suite localization and maintained by myself only, seeing fixes through occasional bug reports. On the other hand, there was the L10n CVS version used for Firefox and later Thunderbird, which originally based on my work, but diverted as Firefox localizer Abdulkadir Topal maintained it, adding his own sets of changes, probably coordinated in different cases with Alex Ihrig, who is the Thunderbird maintainer and German core L10n peer.
Now that we are working on finally getting suite L10n into CVS as well, I could just concentrate on SeaMonkey-specific strings and just adopt what is in CVS for the rest - but there are two problems with that approach:
First, due to changes on trunk and Abdulkadir having little time, we lack some translations for core in German CVS, and I'm happy to help out there a bit (some people might remember my fight with nsserrors.properties a while back, which was an instance of that).
Second, it's a good idea to review where translations diverged between my version and the one in CVS, as either version could have better solutions for some hard cases and some systematic differences may be worth a discussion that makes us consistently improve our work across core and the different applications.
Because of that, I filed a set of bugs about syncing up our different versions, and both MozillaTranslator's "Search Translation Inconsistency" and my PHP script to rewrite output of that tool with the structure of the original files did once again show their usefulness.
Sure, the result was a few huge patches (and I haven't even touched toolkit/ yet), which take my colleagues some time to review, but I'm convinced the result will be a better quality localization for all German users, and that's surely worth the time we all are putting into that.
And we even came across a few things which are bugs in the original strings and which German localizers have solved silently in the translation only, but they really should be filed as common bugs, so we can improve the product for all our users. This includes the security libraries of Thunderbird and Sunbird not talking to the user as if those applications were browsers, Firefox telling the user it stores email passwords or just resolving our mixed use of "website" and "site" across the core strings. We'll sort those out, file bugs where necessary and care that the situation gets better for all of us.
I also want to ask localizers of other languages to do the same: If strings in the en-US original are strange, wrong or inconsistent, please don't hesitate to file bugs against the original code.
Better quality for everyone is surely worth investing some of our time, we all should our share to ensure it's possible.
Edit (June 22, 6:30pm CEST):
Some bugs we spotted in the original strings are filed now - and we may find even more
Now that we are working on finally getting suite L10n into CVS as well, I could just concentrate on SeaMonkey-specific strings and just adopt what is in CVS for the rest - but there are two problems with that approach:
First, due to changes on trunk and Abdulkadir having little time, we lack some translations for core in German CVS, and I'm happy to help out there a bit (some people might remember my fight with nsserrors.properties a while back, which was an instance of that).
Second, it's a good idea to review where translations diverged between my version and the one in CVS, as either version could have better solutions for some hard cases and some systematic differences may be worth a discussion that makes us consistently improve our work across core and the different applications.
Because of that, I filed a set of bugs about syncing up our different versions, and both MozillaTranslator's "Search Translation Inconsistency" and my PHP script to rewrite output of that tool with the structure of the original files did once again show their usefulness.
Sure, the result was a few huge patches (and I haven't even touched toolkit/ yet), which take my colleagues some time to review, but I'm convinced the result will be a better quality localization for all German users, and that's surely worth the time we all are putting into that.
And we even came across a few things which are bugs in the original strings and which German localizers have solved silently in the translation only, but they really should be filed as common bugs, so we can improve the product for all our users. This includes the security libraries of Thunderbird and Sunbird not talking to the user as if those applications were browsers, Firefox telling the user it stores email passwords or just resolving our mixed use of "website" and "site" across the core strings. We'll sort those out, file bugs where necessary and care that the situation gets better for all of us.
I also want to ask localizers of other languages to do the same: If strings in the en-US original are strange, wrong or inconsistent, please don't hesitate to file bugs against the original code.
Better quality for everyone is surely worth investing some of our time, we all should our share to ensure it's possible.
Edit (June 22, 6:30pm CEST):
Some bugs we spotted in the original strings are filed now - and we may find even more
Von KaiRo, um 03:46 | Tags: L10n, Mozilla, quality, SeaMonkey | keine Kommentare | TrackBack: 0
19. Juni 2007
Tricky unit conversions
When I just read this entry in mrz' blog about fuel economy of his car (or driving), I immediately was left with a problem: How good is a value of 53.4 mpg?
The real problem is that around here in Europe, we don't measure mpg at all. Of course, we track fuel economy and we are measuring that, but mpg values are something you won't find. Not only that we're using kilometers and liters instead of miles and gallons - we actually don't care about the cruising range we have with a certain amount of fuel, we care about how much fuel the car burns to go a certain distance.
That's probably connected with the fact that we have gas stations every few kilometers, I never saw scary signs like "42 miles no service" on this side of the big pond, but I remember a few of those from California, Arizona and Texas. Because of that, less range is not the primary concern - but how much fuel we have refill after a 200 km drive is much more, esp. as a liter of fuel costs about a Euro (>.30) these days around here.
So, I needed to find out how many liters per 100 kilometers (l/100km) those 53.4 mpg actually mean. As a physics student, a good time to do some nice unit math.
So, a US mile is 1.609344 km and a US gallon is 3.785411784 l, which makes 1 mpg be .425 km/l - inverse that and multiply it by 100, and you get a formula of
(or just use 235, that's probably enough for every normal calculation).
The same is true for the other direction of the equation:
So, 53.4 mpg equals about 4.4 l/100km, which is indeed a nice value. Even though the car producers love talking about the 3-liter-car (which would make 78 mpg), usual cars are still in the 5-8 l/100km range (30-50 mpg).
Sometimes a number that sounds quite normal for someone in the US can leave us Europeans quite puzzled, as SI units are not that common in the US. Thank god there's unit math
Edit: Some people have suggested on IRC to use Google for the conversion, but as a science student, it's always good to know you can do it yourself and grasp the logic of such things
The real problem is that around here in Europe, we don't measure mpg at all. Of course, we track fuel economy and we are measuring that, but mpg values are something you won't find. Not only that we're using kilometers and liters instead of miles and gallons - we actually don't care about the cruising range we have with a certain amount of fuel, we care about how much fuel the car burns to go a certain distance.
That's probably connected with the fact that we have gas stations every few kilometers, I never saw scary signs like "42 miles no service" on this side of the big pond, but I remember a few of those from California, Arizona and Texas. Because of that, less range is not the primary concern - but how much fuel we have refill after a 200 km drive is much more, esp. as a liter of fuel costs about a Euro (>.30) these days around here.
So, I needed to find out how many liters per 100 kilometers (l/100km) those 53.4 mpg actually mean. As a physics student, a good time to do some nice unit math.
So, a US mile is 1.609344 km and a US gallon is 3.785411784 l, which makes 1 mpg be .425 km/l - inverse that and multiply it by 100, and you get a formula of
x l/100km = 235.21458 / y mpg(or just use 235, that's probably enough for every normal calculation).
The same is true for the other direction of the equation:
y mpg = 235.21458 / x l/100kmSo, 53.4 mpg equals about 4.4 l/100km, which is indeed a nice value. Even though the car producers love talking about the 3-liter-car (which would make 78 mpg), usual cars are still in the 5-8 l/100km range (30-50 mpg).
Sometimes a number that sounds quite normal for someone in the US can leave us Europeans quite puzzled, as SI units are not that common in the US. Thank god there's unit math
Edit: Some people have suggested on IRC to use Google for the conversion, but as a science student, it's always good to know you can do it yourself and grasp the logic of such things
Von KaiRo, um 20:49 | Tags: cars, physics, units | 2 Kommentare | TrackBack: 0
18. Juni 2007
Weekly Status Report, W24/2007
After a week that has been a bit lighter than the last, here's a summary of SeaMonkey work I did in week 24/2007 (June 11 - 17):
And, just as it was in discussion a lot this week when ISS lost attitude control due to a computer failure for a few days, I hope I've got my attitude pretty well under control. Thank god I don't need to go through pre-breathe protocols, depressurization, pure oxygen breathing or complicated suits just to go outside this living environment - though sometimes it seems I may be leaving this well-known place not too much more often than those astronauts are stepping outside theirs
- Bugzilla reorganization:
Tripping over this once again, I opened a thread about organization of Bugzilla components in m.d.planning, telling my problems and some possible solutions.
This ended up with Gerv starting on a bmo reorg plan with looking for input from more developers on the newsgroup and posting a first reorganization plan. I hope we'll come to a good plan there and will get it really done as well afterwards. - SeaMonkey releases:
Uploaded a few more contributed localized builds for 1.1.2/1.0.9 - xpfe cleanup:
This is progressing, I cleaned up
xpfe/bootstrap as much as currently possible this week, more is to be done in other directories, but a few are apparently suffering from forkitis (the abandoned xpfe versions probably contain fixes that never made it into toolkit but still should). We should try to fix that as well. - Killing wallet:
Some talk with Neil about that, he's getting near to solving the remaining problems, I'll post an updated patch for the switch itself soon. - places history:
Removing toolkit mork history won't happen before Gecko 1.9a6, but the CVS copy I requested should make fixing that easier as well as our var-based build time switch solution for places history. Still need someone to look at the UI then. - Mac nightlies:
Investigated missing copies of Mac nightlies is latest-trunk/ a bit more and saw it fixed by a mostly unrelated fix. - Even more cleanup:
Filed a bug for removing suite autoscroll now that our solution has been ported to toolkit, proposed removing moz_pis_startstop_scripts from unix startup scripts after I killed that now unused feature from xpfe/bootstrap. - Various discussions:
Suiterunner theme regressions, untrusted X connections, autocomplete theming, Mercurial repository, Apple download pages, Mozilla Credits, profile location, Firefox 3 UI, P3P UI removal, and others
And, just as it was in discussion a lot this week when ISS lost attitude control due to a computer failure for a few days, I hope I've got my attitude pretty well under control. Thank god I don't need to go through pre-breathe protocols, depressurization, pure oxygen breathing or complicated suits just to go outside this living environment - though sometimes it seems I may be leaving this well-known place not too much more often than those astronauts are stepping outside theirs
Von KaiRo, um 02:43 | Tags: L10n, Mozilla, SeaMonkey, Status | keine Kommentare | TrackBack: 1
15. Juni 2007
Sweeping "LeBroom" off the floor - Congrats Spurs!
They really made it!
Unfortunately I haven't been able to watch any of those games (3am to 6am is quite a bad time), but I've been reading all the recaps, and it's just great how this team managed to win the NBA Finals and get to be a 4-time-champion.
A few days ago, San Antonio fans were mocking young Cleveland star LeBron James as "LeBroom" and chanting "Sweep! Sweep! Sweep!" after only two games of Spurs domination over the Cavs. That sounded overly optimistic, but it held true.
The Spurs clearly have joined the club of the best teams of all times in NBA history, and the Duncan-Parker-Ginobili trio probably earned being called "legendary" in the future - almost like Jordan-Pippen-Rodman - even though it's actually the whole team, including players like Rob Horry, Mike Finley, Bruce Bowen and others, and of course their great coach Gregg Popovich, who achieved this great success.
Being a great team is what it's really all about. I followed the NBA playoffs games of the Spurs closely this year, and found that they always had more players on the field as their opponents, with the last finals game being the exception where both teams used 10 players over those 48 minutes - but Shannon Brows of the Cavs is only credited with one second.
After the Spurs had not played like a to-be-champion in the first half of the season, it was really great to see this turnaround - I guess they were just getting better with every game they played this season.
To quote the NBA.com article:
"It never gets old, it never gets old," Tim Duncan said. "Unbelievable. Such a great run, a great journey, a great bunch of guys."
Congratulations to Tim, Tony, Manu, Gregg and all the other great people of the Spurs!
Oh, how I would like to be in the Alamo city to celebrate this...
Unfortunately I haven't been able to watch any of those games (3am to 6am is quite a bad time), but I've been reading all the recaps, and it's just great how this team managed to win the NBA Finals and get to be a 4-time-champion.
A few days ago, San Antonio fans were mocking young Cleveland star LeBron James as "LeBroom" and chanting "Sweep! Sweep! Sweep!" after only two games of Spurs domination over the Cavs. That sounded overly optimistic, but it held true.
The Spurs clearly have joined the club of the best teams of all times in NBA history, and the Duncan-Parker-Ginobili trio probably earned being called "legendary" in the future - almost like Jordan-Pippen-Rodman - even though it's actually the whole team, including players like Rob Horry, Mike Finley, Bruce Bowen and others, and of course their great coach Gregg Popovich, who achieved this great success.
Being a great team is what it's really all about. I followed the NBA playoffs games of the Spurs closely this year, and found that they always had more players on the field as their opponents, with the last finals game being the exception where both teams used 10 players over those 48 minutes - but Shannon Brows of the Cavs is only credited with one second.
After the Spurs had not played like a to-be-champion in the first half of the season, it was really great to see this turnaround - I guess they were just getting better with every game they played this season.
To quote the NBA.com article:
"It never gets old, it never gets old," Tim Duncan said. "Unbelievable. Such a great run, a great journey, a great bunch of guys."
Congratulations to Tim, Tony, Manu, Gregg and all the other great people of the Spurs!
Oh, how I would like to be in the Alamo city to celebrate this...
Von KaiRo, um 17:57 | Tags: NBA | 1 Kommentar | TrackBack: 0
13. Juni 2007
More than you wanted to know...
An IRC collegue today reminded me that I have a Wikipedia account and added some userboxes to my user page. I thought those weren't enough and added just about any userbox that sounded correct for me.
I ended up with currently 84 user boxes - not sure if such a list was what they were intended for
Anyways, you can find a pretty extensive list of a lot of things I have on my mind there now, probably more than you wanted to know about me
I ended up with currently 84 user boxes - not sure if such a list was what they were intended for
Anyways, you can find a pretty extensive list of a lot of things I have on my mind there now, probably more than you wanted to know about me
Von KaiRo, um 17:39 | Tags: Wikipedia | keine Kommentare | TrackBack: 0
11. Juni 2007
The trouble with forking
As you might know, a long time ago, some group of people decided to fork some parts of Mozilla and create a lean, shiny, new browser. What came out of that was not only Firefox but also a "new toolkit" that was used instead of the "old xpfe" as a backend for this new generation of applications that Firefox and Thunderbird spearheaded. What started as a fork of xpfe became the main toolkit over time and now is one of the core parts of the XULRunner environment.
Nowadays that SeaMonkey has been ported over to this new toolkit, we're trying to do some housekeeping and cleaning up the old code. But, as it turns out, not all of the "old code" is older than the "new code". In fact, some fixes and improvements were done on the "old" fork but haven't made it into the "new" one. This means that the old xpfe code includes some good, newer work than the new toolkit code, and deleting the old code would throw away a version that has valuable fixes.
While the old code will live on in the history of the mozilla.org code repository and can be retrieved from there any time, people usually don't look up code there that has been deleted from the mainline.
So, what we need to do is at least file bugs, possibly with patches to toolkit, to have some tracking of what needs to be done, before we can put the "old" code to rest.
We could need your help for this unforking work, which might be a good starting point for new contributors, as the code for most of the work is already there. Good starting points are the pointers in the themes cleanup bug and the dependencies on the resync xpfe bindings with toolkit widgets bug - we might be able to give you even more pointers on IRC.
Hope to get some helping hands on that, it will improve the toolkit we all are using!
Nowadays that SeaMonkey has been ported over to this new toolkit, we're trying to do some housekeeping and cleaning up the old code. But, as it turns out, not all of the "old code" is older than the "new code". In fact, some fixes and improvements were done on the "old" fork but haven't made it into the "new" one. This means that the old xpfe code includes some good, newer work than the new toolkit code, and deleting the old code would throw away a version that has valuable fixes.
While the old code will live on in the history of the mozilla.org code repository and can be retrieved from there any time, people usually don't look up code there that has been deleted from the mainline.
So, what we need to do is at least file bugs, possibly with patches to toolkit, to have some tracking of what needs to be done, before we can put the "old" code to rest.
We could need your help for this unforking work, which might be a good starting point for new contributors, as the code for most of the work is already there. Good starting points are the pointers in the themes cleanup bug and the dependencies on the resync xpfe bindings with toolkit widgets bug - we might be able to give you even more pointers on IRC.
Hope to get some helping hands on that, it will improve the toolkit we all are using!
Von KaiRo, um 18:22 | Tags: Mozilla, SeaMonkey | keine Kommentare | TrackBack: 0
Weekly Status Report, W23/2007
This week I've been piling up about 80 hours of work time, mostly related to SeaMonkey and Mozilla - I think that probably is not what I should be re-doing any time soon, even though interesting things like watching a space shuttle launch can be done right next to the work thanks to internet streaming.
Here's a summary of my SeaMonkey work in week 23/2007 (June 4 - 10):
I once again realized that it's a good thing to do those weekly wrapups to remember yourself what it all was that you spent you time on that week - with such a list, it happens that you forget what it even was that took up some of those hours...
Here's a summary of my SeaMonkey work in week 23/2007 (June 4 - 10):
- SeaMonkey releases:
Uploaded a few more localized and other contributed builds for 1.1.2/1.0.9 - xpfe cleanup:
As we're on toolkit now, I started to work on cleaning up xpfe/, which in turn needed a hack to get Camino away from building xpfe/bootstrap, but this is shaping up nicely. I'll look into even more cleanup in the next few days now that the tree is open and I could check in the patches I had review for.
Both in the xpfe/components and xpfe/bootstrap dirs, we can be cvs remove even more files than in the current patches, and we should kill off all the old cruft, as anyone who needs to refer to them can always go back in cvs history.
We also might need to file a few bugs though for fixes that went into xpfe but not corresponding toolkit code and improve toolkit along the way. - Killing wallet:
I posted an updated patch for the wallet -> satchel change so Neil can work on fixing up autocomplete to work with that. - places history:
The UI work seems to be getting too much for me, so I reworked the patch to user places history so that we can turn this on in any build be setting MOZ_PLACES=1 in confvars.sh but build old xpfe mork history by default, so someone else can easily look into the UI parts.
The harder part of that is sorting out a way so SeaMonkey (and Camino) get the nsIBrowserHistory interface built in toolkit (lives in history/public there) when places is turned on, but never get all of toolkit history built. I ended up proposing to remove toolkit mork history as it's not built any more by any app in the Mozilla tree. Mano didn't agree with the patch itself (the interface should probably just be move to places), but with the general idea, but wants to get an OK for removing support for mork history toolkit builds. Watch out for this happening soon in some form. - Crash reporting:
Worked with Chris Cooper from MoCo to get Talkback re-enabled on SeaMonkey trunk as far as currently possible, (and with Frank to get it correctly packaged on Windows). Also worked with Ted (luser) on figuring out how to get breakpad working for SeaMonkey. It turns out from our talking and my testing that we are on a good way for that once the breakpad people have stabilized their infrastructure enough to make other apps than Firefox (which already tests it) use this. - Startup profiling:
I created jprof-enabled build from just before the suiterunner switch to investigate the suiterunner Ts regression but the data didn't help as much as I had hoped. Boris, who knows a lot about profiling and has a slow machine, could unfortunately not run my builds due to them being linked against libpangocairo which he doesn't have on FC4. We're (again) a bit stuck on that, it seems. - Themes:
I should have finished porting over my EarlyBlue theme to suiterunner, mozapps is done (I hope my Add-Ons Manager design is fine) and I updated the suite parts for changes in Classic over the last months. I probably will still go to consolidate some icons into bigger PNG files and use -moz-image-region on them to match Classic a bit more, but after that, syncing LCARStrek will be the next task, which should prove interesting as well, esp. as all the usage of -moz-border-radius should probably look better with cairo-based UI. - Local (bug)mail housekeeping:
I'm keeping one bugmail for every bug I find interesting enough to track (or find fast when talking about them) in folders below my main inbox, and those have grown to too long lists over time, so I went through all of them, cleaned out all resolved bugs, cleaned out bugs that could be resolved but weren't marked as such, and asking for status on unclear cases. This should not only have resulted in me finding the really interesting bugs easier but also in some selected bug triage in Bugzilla, leading to a few bugs disappearing from the open lists - Widget sync bugs:
After a bugmail from the resync xpfe bindings with toolkit widgets bug reminded me of this issue, I went through all dependent bugs and asked if we still need to port something from xpfe too toolkit there - the other way round doesn't make sense any more and if bugs were kept open only for that, we should just close them. - Various discussions:
Optional extension L10n (inspector, etc.), mailnews crashes, "turbo" mode removal, static builds, profile migration, SeaMonkey default icon set, untrusted X connections, VC8 build changes, ongoing FF3 UI discussions, etc.
I once again realized that it's a good thing to do those weekly wrapups to remember yourself what it all was that you spent you time on that week - with such a list, it happens that you forget what it even was that took up some of those hours...
Von KaiRo, um 00:39 | Tags: L10n, Mozilla, SeaMonkey, Status | keine Kommentare | TrackBack: 0
10. Juni 2007
Wetter selbst bestellen!
Na, der Service hat uns noch gefehlt:
Wer hat sich nicht schon oft geärgert, dass das Wetter nicht passt. Jetzt kann man das ändern und sich das Wetter online bestellen!
Allerdings:
"Derzeit befinden wir uns jedoch in der Beta-Phase - das heisst, dass unter Umständen nicht alle Wünsche korrekt ausgeführt werden."
Hier in Wien dürfte sich allerdings jemand den Scherz erlaubt haben und für einen Teil der Stadt Gewitter und für den anderen Sonne bestellt haben, denn es donnert hier gewaltig bei strahlendem Sonnenschein. Da werde ich gleich poetisch und mir kommt ein altes Zitat in den Sinn:
"Den Donner hör ich wohl, allein es scheint die Sonne!"
Oder war das anders?
Naja, anscheinend hat das da oben jemand gehört, jetzt verschwindet auch die Sonne hinter den herannahenden Wolken...
Wer hat sich nicht schon oft geärgert, dass das Wetter nicht passt. Jetzt kann man das ändern und sich das Wetter online bestellen!
Allerdings:
"Derzeit befinden wir uns jedoch in der Beta-Phase - das heisst, dass unter Umständen nicht alle Wünsche korrekt ausgeführt werden."
Hier in Wien dürfte sich allerdings jemand den Scherz erlaubt haben und für einen Teil der Stadt Gewitter und für den anderen Sonne bestellt haben, denn es donnert hier gewaltig bei strahlendem Sonnenschein. Da werde ich gleich poetisch und mir kommt ein altes Zitat in den Sinn:
"Den Donner hör ich wohl, allein es scheint die Sonne!"
Oder war das anders?
Naja, anscheinend hat das da oben jemand gehört, jetzt verschwindet auch die Sonne hinter den herannahenden Wolken...
Von KaiRo, um 15:02 | Tags: Wetter | keine Kommentare | TrackBack: 0
9. Juni 2007
SeaMonkey® trademarks registered!
I just noticed that our SeaMonkey trademark applications now show up in a "registered" status on the USPTO search pages:
"SeaMonkey" work mark, reg. no. 3243415 and SeaMonkey logo mark, reg.no. 3246043 are therefore official trademarks in the US now!
In the EU, both are in the "Application accepted" state now, for the Japanese application, I see no "status" field but the info looks similar to that state. (EU and Japanese trademark applications were only filed in April this year, while we applied in the US in September last year and the registration was granted for both on 2007-05-22.
So, you can refer to our name as SeaMonkey® now!
"SeaMonkey" work mark, reg. no. 3243415 and SeaMonkey logo mark, reg.no. 3246043 are therefore official trademarks in the US now!
In the EU, both are in the "Application accepted" state now, for the Japanese application, I see no "status" field but the info looks similar to that state. (EU and Japanese trademark applications were only filed in April this year, while we applied in the US in September last year and the registration was granted for both on 2007-05-22.
So, you can refer to our name as SeaMonkey® now!
Von KaiRo, um 15:10 | Tags: Mozilla, SeaMonkey | 1 Kommentar | TrackBack: 1
4. Juni 2007
The F-Word - or: Code is not Country Music
Some of you might know a song called "The F-Word", recorded by Hank Williams, Jr. and Kid Rock, which explains in all length that "in Country Music, you don't use the f-word", and yes, it's fun - esp. given how Kid Rock lyrics usually read
A bit more recently, there Jack Ingram's "Love You" that takes this cursing down a completely different path: "Love this mother-lovin' truck that keeps breakin' lovin' down / There's only one four-letter word that'll do: / Love you"
Nicely said
Still, that's music, that's lyrical art - and software source code is different.
When I read preed's article on Planet today and read this recent bug report, I couldn't help but burst out into a big "WTF?" myself. There are lots of hacks in our code, we sometimes suck, and can't get it to fuckin' work as it should - and this guy wants to put censorship on us instead of admitting in comments what's really happening in the code. This sounds plainly wrong to me.
When I looked into an older article about Netscape/Mozilla "censorship", I had a few good laughs though. See for example this one, from Netscape 3 (but apparently still present in 4.x):
lib/libmime/mimestub.c: Life kinda sucks, but oh well.
Given this is in libmime, and I heard enough talk about the suckiness of that lib, it's real fun to see this in a version of it - even though I don't know what it relates to.
Seeing "hack" used various times in security/ might make some people uncomfortable though... and // fucking idiot! in the same subdir might also not increase trust in this...
I guess it depends where you can use what words
A bit more recently, there Jack Ingram's "Love You" that takes this cursing down a completely different path: "Love this mother-lovin' truck that keeps breakin' lovin' down / There's only one four-letter word that'll do: / Love you"
Nicely said
Still, that's music, that's lyrical art - and software source code is different.
When I read preed's article on Planet today and read this recent bug report, I couldn't help but burst out into a big "WTF?" myself. There are lots of hacks in our code, we sometimes suck, and can't get it to fuckin' work as it should - and this guy wants to put censorship on us instead of admitting in comments what's really happening in the code. This sounds plainly wrong to me.
When I looked into an older article about Netscape/Mozilla "censorship", I had a few good laughs though. See for example this one, from Netscape 3 (but apparently still present in 4.x):
lib/libmime/mimestub.c: Life kinda sucks, but oh well.
Given this is in libmime, and I heard enough talk about the suckiness of that lib, it's real fun to see this in a version of it - even though I don't know what it relates to.
Seeing "hack" used various times in security/ might make some people uncomfortable though... and // fucking idiot! in the same subdir might also not increase trust in this...
I guess it depends where you can use what words
Von KaiRo, um 20:55 | Tags: Country Music, Mozilla | keine Kommentare | TrackBack: 0
Build system defaults to MOZ_XUL_APP now!
The SeaMonkey confvars.sh did only set MOZ_XUL_APP=1 for a very short time, as I just removed it again
As a matter of fact, after my checkin for bug 383112 that I just did, the configure script makes all applications built from mozilla.org trunk default to MOZ_XUL_APP=1, so they don't need to explicitely set this variable any more - just Camino does unset it (until that last user of xpfe gets converted).
Actually, we might near a world where this variable isn't needed at all any more, as everyone uses the same toolkit anyways. But for now, configure turns it on for everybody - once Camino doesn't have to unset it, we might be able to just kill all its appearances from the code step by step.
As a matter of fact, after my checkin for bug 383112 that I just did, the configure script makes all applications built from mozilla.org trunk default to MOZ_XUL_APP=1, so they don't need to explicitely set this variable any more - just Camino does unset it (until that last user of xpfe gets converted).
Actually, we might near a world where this variable isn't needed at all any more, as everyone uses the same toolkit anyways. But for now, configure turns it on for everybody - once Camino doesn't have to unset it, we might be able to just kill all its appearances from the code step by step.
Von KaiRo, um 17:19 | Tags: Mozilla, Mozpad | keine Kommentare | TrackBack: 0
Weekly Status Report, W22/2007
After a quite busy week (both work- and non-work-related) here's the report on my SeaMonkey work in week 22/2007 (May 28 - June 3):
As we have entered the brave new world of the new toolkit now, there's a real lot to do to improve how well SeaMonkey works on it, clean up what we left behind, switch over to the parts of it we're not using yet - and add features that will make SeaMonkey 2 an even better Internet suite. We'd be happy about anyone who can help us in any of those areas.
Oh, and if you can't, test nightlies and report bugs - that's the first step to being a contributor and improving your favorite software!
- SeaMonkey releases:
Those went online on May 30, once more in sync with Firefox/Gecko releases - and I'm proud we could push out new localized packages in 7 languages additional to US English right at the same time as the official release. For our old process with L10n teams creating and contributing the packages themselves, this is quite a nice number. Along with the still usable language packs from 1.1(.1), we now have SeaMonkey 1.1.2 in 15 languages total - for the first time also in Brazilian Portugese. - suiterunner switch:
It is done!
I checked in the patch for the real switch on Tuesday, after Frank had added the NSIS installer on Monday. Also fixed tinderbox configs to build the nightlies correctly. Mark and Frank have fixed a number of problems in migration and installer since, and are still working on newly reported ones.
If you run into problem with the new "2.0a1pre" builds, look for filed bugs and report new ones if your problem isn't know there.
Now Camino is the only xpfe-based app left, I hope we get them off that toolkit soon as well so we can clean up the source and finally kill that old code. - Killing wallet:
Did look again into the wallet -> satchel change, but I'm now at an interesting point where my (opt) build crashes when I focus any form field, which is not too helpful for working on that. - places history:
Last Sunday evening, I was contacted by Mano in IRC about what history implementation we're using in suiterunner, and I had to confess we're still using the xpfe one after looking into the code. He told me it would probably be easy to skip the toolkit version of it and go directly to places history. I
filed bug 382187 for that and with help from him and biesi, I got the backend to build and work within 3-4 hours (where most of the time was spent tweaking build vars and recompiling). It even automatically imports data from the old mork file into places.sqlite, so visited sites still stay displayed as visited after switching.
Unfortunately, getting the UI to work with this is harder, as our UI for history stuff is mostly RDF-based and mozstorage data doesn't get presented as RDF. And, which is probably worse, I have much too little coding experience in those areas.
I did manage to get a Firefox places history panel mostly working in my experimental build, but though the search and sort is nice there, I think I like our old one better functionality-wise (or even better a crossover of them). Unfortunately, it needs a ridiculously big number of files from browser/ to work properly, and one bug caused my error console to fill with one repeated line over and over. - Themes:
I again put some work into porting over my EarlyBlue theme to suiterunner, adding support for the (new) help viewer. When I realized this might be a good place to start using PNG files and -moz-image-region, I asked on IRC what the coordinates there exactly meant and ended up writing a layout reftest and improving its documentation for that instead of doing actual theme work for a while. Even though such things are distracting, more people than just me end up profiting from that, I hope. - Mozpad:
Took part in the second IRC meeting - I think this project is heading into a good direction, even if some hopes of participants might be set a bit too high for now. Cooperating for a better platform and more docs is a quite important mission though, and everyone should profit from that. - Various discussions:
A huge list of suiterunner post-landing discussions around regressions, cleanups and further improvements; continued Firefox3 UI discussions, SeaMonkey icon set and others.
As we have entered the brave new world of the new toolkit now, there's a real lot to do to improve how well SeaMonkey works on it, clean up what we left behind, switch over to the parts of it we're not using yet - and add features that will make SeaMonkey 2 an even better Internet suite. We'd be happy about anyone who can help us in any of those areas.
Oh, and if you can't, test nightlies and report bugs - that's the first step to being a contributor and improving your favorite software!
Von KaiRo, um 00:22 | Tags: L10n, Mozilla, SeaMonkey, Status | keine Kommentare | TrackBack: 0
1. Juni 2007
talking moon
In a discussion about automatic translation we just had in #seamonkey, I got reminded once again of the good old "talking moon" story, which is always good for a laugh.
We all know that automatic translation services don't work perfectly, but e.g. translate.google.com does a good job in many cases and you can figure out what the original text was talking about, even if you don't understand the language it was written in.
Back in 2002, mozillaZine had a story about a German magazine polling their readers about their favorite browser. Of course, the magazine wrote its original story in their language, which was German, so mozillaZine linked to the rough translation of that Google service.
The mostly English-speaking Mozilla community was quite glad about this, and people could easily figure out through this translation what the results of that poll were. But, reading one sentence there made some people wonder what it means: "The Browser from talking moon is further unquestioned on place one, ...". Now how is a talking moon related to browsers? Looking into the original article revealed what had happended: "Zwar liegt der Browser aus Redmond weiterhin unangefochten auf Platz eins, ..." - "Redmond" had been translated to "talking moon"! Well, "red-" as a prefix derived from the verb "reden" - "to talk", can surely be translated to "talking", and "Mond" is the "moon", that's also correct. Just the algorithm detecting "Redmond" as a German word was probably a bit wrong, I guess
Who would have thought that there's a talking moon right in the vicinity of Seattle?
We all know that automatic translation services don't work perfectly, but e.g. translate.google.com does a good job in many cases and you can figure out what the original text was talking about, even if you don't understand the language it was written in.
Back in 2002, mozillaZine had a story about a German magazine polling their readers about their favorite browser. Of course, the magazine wrote its original story in their language, which was German, so mozillaZine linked to the rough translation of that Google service.
The mostly English-speaking Mozilla community was quite glad about this, and people could easily figure out through this translation what the results of that poll were. But, reading one sentence there made some people wonder what it means: "The Browser from talking moon is further unquestioned on place one, ...". Now how is a talking moon related to browsers? Looking into the original article revealed what had happended: "Zwar liegt der Browser aus Redmond weiterhin unangefochten auf Platz eins, ..." - "Redmond" had been translated to "talking moon"! Well, "red-" as a prefix derived from the verb "reden" - "to talk", can surely be translated to "talking", and "Mond" is the "moon", that's also correct. Just the algorithm detecting "Redmond" as a German word was probably a bit wrong, I guess
Who would have thought that there's a talking moon right in the vicinity of Seattle?
Von KaiRo, um 14:16 | Tags: L10n, Mozilla | 2 Kommentare | TrackBack: 0
>380k Downloads for SeaMonkey 1.1.1
Yes, you read this right in the topic: SeaMonkey 1.1.1 has more than 380k officially recorded downloads!
To be exact, the "bouncer" download redirecting tool recorded 381,196 downloads for SeaMonkey 1.1.1 from its release on February 28 until the release of 1.1.2 yesterday - for the three main download links on our websites only, i.e. Windows installer, Linux installer and MacOS X Disk Image, in English language.
Downloads of any other builds (.zip or tarballs, other platforms and other languages) are not counted, as well as downloads that are issued directly from FTP servers, or through other means of distribution (Linux distro packages, etc.) - so the real number is probably significantly higher, but we don't know such numbers. What we know are bouncer statistics (links to download.mozilla.org go through this tool), and only those.
A graph of bouncer downloads for all releases since 1.0 nicely shows how numbers are rising:
Of course, the long period between 1.1.1 and 1.1.2 has helped a lot to reach such heights, but still this shows that a significant group of people is interested in the SeaMonkey suite.
I hope numbers continue to increase like that in the future - and thanks for every one of those people who downloaded our software and hopefully are also using it!
To be exact, the "bouncer" download redirecting tool recorded 381,196 downloads for SeaMonkey 1.1.1 from its release on February 28 until the release of 1.1.2 yesterday - for the three main download links on our websites only, i.e. Windows installer, Linux installer and MacOS X Disk Image, in English language.
Downloads of any other builds (.zip or tarballs, other platforms and other languages) are not counted, as well as downloads that are issued directly from FTP servers, or through other means of distribution (Linux distro packages, etc.) - so the real number is probably significantly higher, but we don't know such numbers. What we know are bouncer statistics (links to download.mozilla.org go through this tool), and only those.
A graph of bouncer downloads for all releases since 1.0 nicely shows how numbers are rising:
Of course, the long period between 1.1.1 and 1.1.2 has helped a lot to reach such heights, but still this shows that a significant group of people is interested in the SeaMonkey suite.
I hope numbers continue to increase like that in the future - and thanks for every one of those people who downloaded our software and hopefully are also using it!
Von KaiRo, um 00:26 | Tags: Mozilla, SeaMonkey, stats | 1 Kommentar | TrackBack: 0
