Mozilla-nl planet

Yesterday the Jetpack project released SDK 1.5. Alongside this Dave Mason pointed out that the upcoming release of Firefox 11 will break compatibility with add-ons packaged with SDK versions 1.3 and below. This is necessary because of a change in Firefox where nsIDOMNSElement was removed ( Jorge recently mentioned this in his compatibility post ). Add-on SDK 1.3 and below contains code that uses this api, and SDK 1.4.* and up do not.

If you are an add-on developer who has an SDK-based add-on on AMO, what this actually means is the following:

• You do not have to change your own code at all.
• If you are doing development on your own machine using the command-line SDK, you do need to download the latest version of the SDK and re-package your add-on with this new version.
• If you are doing development with the online add-on builder, the process is even simpler – just switch the version of the SDK being used in your builder project and click on save, as I demonstrate in this incredibly short screencast.
• Once you have an updated xpi file, please submit it to AMO. As the AMO approval queues are at historically low levels currently, I expect your review should be dealt with promptly!

We’d really appreciate it if developers would do this some time before Firefox 11 ships on March 11. We will also be using the powers of AMO to directly contact affected developers over the next couple of weeks as well. If you have any questions about this, please comment below or drop by #jetpack on irc.mozilla.org.

We released Bugzilla 4.2 today, exactly one year after our previous major release, 4.0! Bugzilla 4.2 now supports SQLite, lets you create attachments simply by pasting text into a text field, can send bug changes notifications in HTML format, supports more complex queries, lets you disable old target milestones, versions and components (so that you don’t need to delete them, but also don’t let users report new bugs to them), has accessibility improvements, and much more…

This release also means that Bugzilla 3.4.x is no longer supported. Installations still running 3.4.14 or older are highly encouraged to upgrade to 4.2, especially to benefit from the security improvements made in newer versions. This also means that Bugzilla 4.0.x will now only get security fixes, and other bug fixes won’t be accepted on this branch anymore, unless they fix critical flaws, such as upgrade issues or dataloss.

The Bugzilla team will now focus on the next major release, Bugzilla 4.4, which we expect to release before the end of the year. We expect to release the first development snapshot (4.3.1) in a few weeks. New features will be accepted for the next two months, till the end of April. Then we will focus on stabilization to prepare Bugzilla 4.4rc1.

If you are interested in helping with the development of Bugzilla, now is a good time to join the team and contribute with new features and/or bug fixes. Due to other activities and because life can sometimes make you very busy, some core developers had to stop their contributions to the Bugzilla project in the last few months and so we would be very happy to see new faces. Bugzilla needs to be faster, nicer, more user friendly, and all this is only possible with your help, your ideas and your feedback. So even if you aren’t a Perl expert, there is a lot of place for everyone (you  can do a lot with HTML + JS + CSS only, think about the User Interface!). If you are not sure about how to contribute or help, feel free to join us on IRC in the #bugzilla channel. There is always someone around to answer your questions.

Add-on Builder 1.0:

Add-on Builder, the product I’ve been working on for the past year, has just hit 1.0 It’s a web-based IDE that let’s people create add-ons for Firefox using JavaScript and HTML.

After a year in incubation we’re ready to remove the beta tag from the Add-on Builder! For those of you who are unfamiliar with this fantastic tool, Add-on Builder is an online development environment that allows developers with knowledge of HTML, JavaScipt and CSS to rapidly create add-ons for Firefox using the Mozilla Add-on SDK. You can think of it as the jsFiddle of add-on development and debugging.

Add-on Builder leverages the Add-on SDK to produce add-ons that users can install without restarting Firefox. In addition, add-ons created with Add-on Builder are automatically repackaged with Add-on SDK updates – which ensures that Builder-based add-ons will continue to work for users without interruption, regardless of Firefox API changes.

Add-on Builder provides many features specifically tailored to help add-on authors develop add-ons:

• a simple online interface for writing your code
• live, one-click add-on testing
• access to a repository of third-party add-on libraries
• jsFiddle-like sharing and collaboration
• instant upgrade options for new versions of the Add-on SDK
• integrated features for publishing to addons.mozilla.org

If you haven’t yet developed an add-on for Firefox, we suggest you give the Add-on Builder a try. With a simple interface and many helpful tools, it truly is the quickest, easiest way to create add-ons for Firefox!

Joey continues his series examining make-makefiles internals over at his blog.

He’s doing thankless work in documenting the existing build config system. Of course, it’s all building up to Joey’s work on container makefiles where he’s going to change it all.

A bunch of us Mozilla Developer Network folks — web developers, technical writers, developer evangelists and cat herders like me — will be hosting MDN’s first Hack Day in the great city of New York.

Like many teams who work together at Mozilla, we’re geographically dispersed, and manage to meet in real life a few times per year. The U.S east coast is a relative mid-point between Western Canada, California, Colorado, Oklahoma, Texas and Tennessee on the one hand, and France, Great Britain, Sweden, and Switzerland, on the other. So we’re headed for Brooklyn and the Big Apple!

On Saturday, March 24, we’ll be at New Work City, a splendid coworking space, which aims “to make the world a better place by empowering people to make a living doing things they love.” (That sounds like us!) We’ll open with a series of short talks about our projects and technologies, and after lunch we’ll hang out and hack, closing the day with demos.

We know that New York City is home to a flourishing tech scene with a thriving startup culture, influential venture firms, and lots of opportunity for developers. The hacker ethic is alive and well in NYC through the work of many collaborators, including: our Mozilla Foundation colleagues at The Hive Learning Network; WebFWD partner General Assembly, putting together a campus for technology, design, and entrepreneurship; and The Creators Project, which will be in San Francisco the weekend before, March 17-18, with a spectacular audio visual installation and other works of astonishing goodness.

We’re eager to meet, explore, and share some of the stuff we’ve been working on: HTML5, gaming, developer tools for Firefox, the evolution of Jetpack, open-source documentation, and roadmaps that support brand new open platforms and projects. We hope you’ll come check out what we’re building on the open Web and see if we can work together.

Mozilla is a non-profit with a mission to “to promote openness, innovation and opportunity” and a manifesto describing the “principles that we believe are critical for the Internet to continue to benefit the public good.”

Let’s hack together — in a city that embraces innovation — and never sleeps. Space is limited, so sign up now, and we’ll save you a t-shirt!

Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help!

JavaScript

• SpiderMonkey Garbage Collection Tips
• Boolean
• Inheritance and the prototype chain

SpiderMonkey

• JSProperty
• JS_ExecuteRegExp
• JS_FlattenString

Developing Mozilla

• xpcshell
• Building XXX Standalone
• Using XPCOM in JavaScript without leaking

Extensions

• Extension etiquette
• Addon
• Full page zoom

XUL

• A XUL Bestiary
• The Joy of XUL
• Creating a Windows Inno Setup installer for XULRunner applications

XPCOM

• nsIWinAppHelper
• Setting up the Gecko SDK
• Components.utils.schedulePreciseGC

Interfaces

Thanks to Neil Rashbrook for contributing!

• IAccessibleRelation
• nsIXULWindow
• mozIPersonalDictionary

Plugins

• Scripting plugins
• NPN_Status
• NPRegion

CSS

Thanks to leeli and Panagiotis Tsalaportas for their contributions!

• column-fill
• -moz-box-pack
• @page

SVG

• SVGRadialGradientElement
• feSpotLight
• feComposite

HTML

Thanks to Panagiotis Tsalaportas and Neil Rashbrook for their contributions since last time.

• HTMLElement
• CanvasRenderingContext2D
• link

DOM

Thanks to Matt N. for his contribution to the DOM documentation.

• About the Document Object Model
• Using the Page Visibility API
• Printing

Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.

Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help!

JavaScript

• SpiderMonkey Garbage Collection Tips
• Boolean
• Inheritance and the prototype chain

SpiderMonkey

• JSProperty
• JS_ExecuteRegExp
• JS_FlattenString

Developing Mozilla

• xpcshell
• Building XXX Standalone
• Using XPCOM in JavaScript without leaking

Extensions

• Extension etiquette
• Addon
• Full page zoom

XUL

• A XUL Bestiary
• The Joy of XUL
• Creating a Windows Inno Setup installer for XULRunner applications

XPCOM

• nsIWinAppHelper
• Setting up the Gecko SDK
• Components.utils.schedulePreciseGC

Interfaces

Thanks to Neil Rashbrook for contributing!

• IAccessibleRelation
• nsIXULWindow
• mozIPersonalDictionary

Plugins

• Scripting plugins
• NPN_Status
• NPRegion

CSS

Thanks to leeli and Panagiotis Tsalaportas for their contributions!

• column-fill
• -moz-box-pack
• @page

SVG

• SVGRadialGradientElement
• feSpotLight
• feComposite

HTML

Thanks to Panagiotis Tsalaportas and Neil Rashbrook for their contributions since last time.

• HTMLElement
• CanvasRenderingContext2D
• link

DOM

Thanks to Matt N. for his contribution to the DOM documentation.

• About the Document Object Model
• Using the Page Visibility API
• Printing

&appId

Log Files Are Boring

Just an idea, based on hearing that build log transfers seem to consume large amounts of bandwidth. (Note that for all I know, this is already being done.)

Logs are pretty dull. In particular, two consecutive log files are usually quite similar. It’d be nice if we could take advantage of this redundancy to reduce the bandwidth/time consumed by log transfers.

rsync likes boring data

The natural thing that springs to mind is rsync. I grabbed two log files that are probably more similar to each than is really fair, but they shouldn’t be horribly unrepresentative. rsyncing one to the other found them to share 32% of their data, based on the |rsync –stat| output lines labeled “Matched data” and “Literal data”, for a speedup of 1.46x.

I suspected that rsync’s default block size is too large, and so most of the commonalities are not found. So I tried setting the block size ridiculously low, to 8 bytes, and it found them to be 98% similar. Which is silly, because it has to retrieve more block hashes at that block size than it saves. The total “speedup” is reported as 0.72x.

But the sweet spot in the middle, with a block size of 192, gives 84% similarity for a speedup of 4.73x.

compression likes boring data too

Take a step back: this only applies to uncompressed files. Simply gzipping the log file before transmitting it gives us a speedup of 14.5x. Oops!

Well, rsync can compress the stuff it sends around too. Adding a -z flag with block size 192 gives a speedup of 16.2x. Hey, we beat basic gzip!

But compression needs decent chunks to work with, so the sweet spot may be different. I tried various block sizes, and managed a speedup of 24.3x with -B 960. An additional 1.7x speedup over simple compression is pretty decent!

To summarize our story so far, let’s say you want to copy over a log file named log123.txt. The proposal is:

1. Have a vaguely recent benchmark log file, call it log_compare.txt, available on all senders and receivers. (Actually, it’d probably be a different one per build configuration, but whatever.)
2. On the server, hard link log123.txt to log_compare.txt.
3. From the client, rsync -z -B 960 log123.txt server:log123.txt

stop repeating what I say!

But it still feels like there ought to be something better. The benchmark log file is re-hashed every time you do this and the hashes are sent back over the wire, costing bandwidth. So let’s eliminate that part. Note that we’ll drop the -z from flag because we may as well compress the data during the transfer instead:

ssh server 'ln log_compare.txt log123.txt' rsync -B 960 log123.txt log_compare.txt --only-write-batch=batch.dat ssh -C server 'rsync --read-batch=- argleblargle log132.txt' < batch.dat

Note that “argleblargle” is ignored, since the source file isn’t needed.

So what’s the speedup now? Let’s only consider the bytes transmitted over the network. Assuming the compression from ssh -C has the same effect as gzipping the file locally, I get a speedup of 28.9x, about 2x the speedup of simply compressing the log file in the first place.

But wait. The block size of 960 was based on the cost of retrieving all those hashes from the remote side. We’re not doing that anymore, so a smaller block size should again be more effective. Let’s see… -B 192 gets a total speedup of 139x, which is almost exactly one order of magnitude faster than plain gzipped log files. Now we’re talking!

loose ends

Two things still bug me. One is a minor detail — the above is writing out batch.dat, then reading it back in to send over to the server. This uselessly consumes disk bandwidth. It would be better if rsync could directly read/write compressed batch files to stdin/stdout. (It can read uncompressed batches from stdin, but not write to stdout. You could probably hack it somehow, perhaps with /proc/pidN/fd/…, but it’s not a big deal. And you can just use use /dev/shm/batch.dat for your temporary filename, and remove it right after. It’d still be better if it never had to exist uncompressed anywhere, but whatever.)

The other is that we’re still checksumming that benchmark file locally for every log file we transfer. It doesn’t change the number of bytes spewed over the network, but it slows down the overall procedure. I wonder if librsync would allow avoiding that somehow…? (I think rsync uses two checksums, a fast rolling checksum and a slower precise one, so you’d need to compute both for all offsets. And reading those in would probably cost more than recomputing from the original file. But I haven’t thought too hard about this part.)

not just emacs and debuggers

I sent this writeup to Jim Blandy, who in a typically insightful fashion noticed that (1) this requires some fiddly bookkeeping to ensure that you have a comparison file, and (2) revision control systems already handle all of this. If you have one version of a file checked in and then you check in a modified version of it, the VCS can compute a delta to save storage costs. Then when you transmit the new revision to a remote repository, the VCS will know if the remote already has the baseline revision so it can just send the delta.

Or in other words, you could accomplish all of this by simply checking your log files into a suitable VCS and pushing them to the server. That’s not to say that you’re guaranteed that your VCS <em>will</em> be able to fully optimize this case, just that it’s <em>possible</em> for it to do the “right” thing.

I attempted to try this out with git, but I don’t know enough about how git does things. I checked in my baseline log file, then updated it with the new log file’s contents, then ran git repack to make a pack file containing both. I was hoping to use the increase in size from the original object file to the pack file as an estimate of the incremental cost of the new log file, but the pack file was *smaller* than either original object file. If I make a pack with just the baseline, then I end up with two pack files, but the new one is still smaller.

clients could play too

As a final thought, this idea is not fundamentally restricted to the server. You could do the same thing inside eg tbpl: keep the baseline log(s) in localStorage or IndexedDB. When requesting a log, add a parameter ?I_have_baseline_36fe137a1192. Then, at the server’s discretion, it could compute a delta from that baseline and send it over as a series of “insert this literal data, then copy bytes 3871..17313 from your baseline, then…”. tbpl would reconstruct the resulting log file, the unicorns would do their lewd tap dance, and everyone would profit.

We arrived in London safely and just a little behind schedule. No matter how frustrating aspects of air travel can be, I never cease to be amazed and grateful at how easy and cheap it is to travel halfway around the world in a little over twenty-four hours.

As usual I spent most of the time watching movies and some TV.

• The Debt: Interesting.
• In Time: Intriguing premise, decent execution.
• Boy: Quite good.
• Network: Exceedingly dull and overwrought.
• Man On Fire: OK execution of routine material.
• Mural (weird Chinese film with female spirits who don't understand men (this is a genre)): Difficult to evaluate.
• The Night Watch: Not bad.
• A Shot In The Dark: Tedious (like all the other Clouseau films).
• The Big Sleep (1946): Brilliant. More great dialogue than all the other movies put together.

This movie binge reminded me how wrong mass media is. Based on movies, you would conclude that the most common occupation is "professional assassin", that outbreaks of violence and murder tend to be ignored by the authorities, that there are no happy marriages, and that there are no Christians (barring the odd exorcist or villain). I fully understand that movies focus on the abnormal because it's more interesting, and that most people can distinguish fiction from reality, but I'm too much of a pessimist to imagine that our unconscious assumptions are perfectly firewalled from our movie and TV diet.

This past year we’ve been building the core of a Web-scale identity system. We’ve been calling it BrowserID: our name both for the technology1 and the Mozilla service that implements the technology. Today we’d like to introduce Mozilla Persona, our new name for the complete Identity offering from Mozilla: a collection of components and experiences we’re designing to manage the whole of a user’s online identity with our core values of user control, safety, and convenience.

The Persona name resonates with the idea of personhood as well as online identity as a facet of our lives, and therefore strongly tied to user identity. We’re very excited about this new name and the new features our identity system will offer. Some of the things we’re planning: an identity dashboard, user data interconnect features, and more.

What about “BrowserID?”

BrowserID remains the developer-facing name of the protocol. Websites, email providers, and browser implementors will continue to refer to the BrowserID protocol.

Over the next few months, we will begin to transition the Mozilla Web-based implementation of the BrowserID pop-up over to the new name. But don’t worry, we’ll work hard to make sure the transition is completely seamless for everyone.

Wait, what about Firefox’s Personas?

For the past few years, many Firefox users have enjoyed “Personas”—a quick and fun way to theme the background of the Firefox toolbar. The Addons team blogged about changing their name a couple of weeks ago. No doubt there will be some confusion during this transition, so if you have ideas for how to make the transition smoother, definitely let us know! We believe the long-term value of the Persona name will far outlast the short-term discomfort of change.

We hope you’re as excited about this change as we are. We look forward to an action-packed 2012 for our distributed Identity system under the Mozilla Persona umbrella!

As always, feedback and questions are always welcome on our mailing list, or by tweeting with the #browserid or #mozpersona hash-tag.

1: Some of you may remember that BrowserID came from the Verified Email Protocol. We haven’t forgotten, of course—but BrowserID has become the name of the technology nonetheless.

Mozilla gaat webapps verkopen
De Tijd
Mozilla, de vzw achter de opensource-browser Firefox, gaat via de online winkel Mozilla Marketplace web apps verkopen. Dat zijn applicatietjes die draaien in je browser, en die je bijgevolg op eender welk toestel met die browser kunt gebruiken.
Mozilla opent App Marktplaats voor ontwikkelingen voorgelegd tijdens Mobile ...Business Wire (persbericht)

alle 2 nieuwsartikelen »

Software Carpentry has 110 PowerPoint files, each containing between 20 and 120 slides—call it 5000 slides in total. I’d like to convert them to HTML5 for use with Slide Drive, the deck.js+audio slideshow tool that David Seifried is building. Here’s the breakdown:

• A few bugs in the slide decks need to be fixed—it’s a fairly small job.
• I already have audio recordings narrating the slides. A few will need to be redone to sync with bug fixes in the slides, but that’s a fairly small job.
• I also have transcripts of those recordings. They’ll need corresponding edits, and reformatting, but again, that’s fairly small.
• I don’t have time-marks synchronizing the audio with the slides. I’m sure that information is embedded in the Camtasia project files I created when making the current videos, but I don’t know how to get it out (yet).
• Exporting the main text in the slides (the bullet points) is straightforward, though a fair bit of manual touch-up will be needed to reformat it.
• Ditto for the code samples (which don’t show up with the main text, since they’re in separate text objects).

And then there are the diagrams… Roughly a third of the slides have diagrams of some kind, which makes about 1500 in all. That’s too many to redraw, and anyway, I shouldn’t have to: they’re stored in PowerPoint in some kind of vector format, so I should be able to “export as SVG” or the moral equivalent thereof.

But “should” and “can” aren’t the same thing. I can save my PowerPoint in a lot of different raster image formats, but not in a vector format like SVG. However, I can select elements of a diagram, copy them, and then paste them into a vector drawing tool like Inkscape, which indicates that something in Windows understands how to do the required format conversion.

Doing that 1500 times would be very tedious, though. What I really want is a way to automate that process, i.e., save each slide in a deck as a separate SVG that I can later open and edit. Googling turns up a couple of possibilities, but:

• The VeryDOC Powerpoint-to-SVG convert completely drops the embedded text (i.e., the captions).
• Ditto OpenOffice.org Impress—slides must be saved one at a time, and only the graphical elements come out (not the captions).
• Davisor Publishor doesn’t even export all the graphics.
• docx4j‘s pptx4j sounds like it ought to do the job, but (a) it’s a library, not a tool, so some Java would have to be written to create an actual converter, and (b) it’s not clear that it does actually do the job.

Please tell me I missed something…

Later: in response to a suggestion, I downloaded a Windows clipboard viewer and copied a diagram out of PowerPoint. The display looked like this (click the image for full-sized):

It appears to be a reference into the source file, rather than an actual representation of my boxes, arrows, and text.

WebFWD is somewhat a “startup of startups,” having launched barely 7 months ago. So if there’s one thing we encourage, it’s the ability to move, act and adapt quickly. While we’re certainly keen to read and learn, we’re also big proponents of just getting stuff done.

So we were thrilled when we learned of General Assembly’s new program, “Stop Talking. Start Making.” A little context: General Assembly has been a force for entrepreneurial good in New York over the past year, launching an entire campus devoted to startup and business fundamentals. While we’re not knocking an MBA (some of us have them :p), there’s a lot to be said for hands-on learning. And now that the Web has lowered many barriers to entry, more people than ever are clamoring to start businesses… and need some skills and training to do so.

We were particularly struck by the approach that GA takes with “Stop Talking. Start Making.” In addition to getting experts who have really done this stuff themselves to share their knowledge, GA is sharing it all online, in the context of an interactive community, and making it available for free. Bonus: WebFWD Mentor Bre Pettis is involved ;)

As part of Mozilla, we at WebFWD considerably appreciate the power of open, interactive Web environments to foster true innovation. So we’re excited to contribute to this important project.

Mozilla opent App Marktplaats voor ontwikkelingen voorgelegd tijdens Mobile ...
Business Wire (persbericht)
MOUNTAIN VIEW, Californië (VS)--(BUSINESS WIRE)--Mozilla, een non-profit organisatie die ernaar streeft de macht van het web in de handen van de mensen te leggen, heeft vandaag aangekondigd dat de Mozilla Marktplaats zal openen voor ontwikkelaars die ...

The Mozilla Labs Apps project aims to establish a people-centric Apps ecosystem that provides freedom, choice and opportunity for users and developers. We are doing this by adding key capabilities to the Web platform in the form of new Mozilla-proposed APIs and by establishing the Mozilla Marketplace as the first operating system- and device-independent market for apps based on open Web technologies like HTML5, JavaScript and CSS.

Today, we are incredibly proud to announce that the Mozilla Marketplace will open for developer submissions next week during Mobile World Congress. If you are an app developer interested in distributing and monetizing your app across device and platform silos, you should submit your app to the Mozilla Marketplace. Submitting your app will reserve your app name and give your app the chance to be featured in the launch later this year.

We believe the Web has no competition when it comes to nurturing creativity and generativity. And we cannot wait to see all the amazing apps that will be built using open Web technologies allowing developers to build apps once and deploy everywhere.

Stay tuned for more updates on the Mozilla Labs blog.

The Mozilla Labs Apps project aims to establish a people-centric Apps ecosystem that provides freedom, choice and opportunity for users and developers. We are doing this by adding key capabilities to the Web platform in the form of new Mozilla-proposed APIs and by establishing the Mozilla Marketplace as the first operating system- and device-independent market for apps based on open Web technologies like HTML5, JavaScript and CSS.

Today, we are incredibly proud to announce that the Mozilla Marketplace will open for developer submissions next week during Mobile World Congress. If you are an app developer interested in distributing and monetizing your app across device and platform silos, you should submit your app to the Mozilla Marketplace. Submitting your app will reserve your app name and give your app the chance to be featured in the launch later this year.

We believe the Web has no competition when it comes to nurturing creativity and generativity. And we cannot wait to see all the amazing apps that will be built using open Web technologies allowing developers to build apps once and deploy everywhere.

Stay tuned for more updates on the Mozilla Labs blog.

Every week I post an overview on what’s been happening in the mobile (browsing) world and is relevant to Mozilla.

• Rumours on Jelly Bean launch next quarter not likely to be true
• Tegra 3 devices coming out this quarter
• Opera bought 2 mobile advertising agencies to focus on the US and European markets
• Next version of OS X goes towards deeper integration with iOS and iCloud
• RIM released BlackBerry Playbook OS 2
• Ubuntu for Android was announced
• Browsing patterns on mobile similar during the weekdays and the weekend
• Kindle Fire accounted for 36% of tablet app sessions in Jan 2012, on par with the Samsung Galaxy Tab

Rumours on a possible launch of the next version of Android, Jelly Bean, surfaced. A release so early after Ice Cream Sandwich is believed to be not beneficial to the ecosystem and thus not likely to happen.

Nvidia confirmed that Tegra 3 devices will launch this quarter and Qualcomm offered a preview of their new 1.5 GHz dual-core Snapdragon S4, which performs impressively on benchmarks.

Opera bought 2 mobile advertising agencies, Mobile Theory and 4th Screen Advertising. The acquisition is meant to enhance the company’s monetization opportunities for the traffic flowing through its mobile browsers, Opera Mini and Opera Mobile, which together have 160 million monthly users and serve more than 100 billion page views each month. Opera also owns AdMarvel, an agency it acquired 2 years ago. Its 2 new acquisitions will focus on the US and European markets.

The next version of OS X hints towards deeper integration and convergence of Apple’s mobile and desktop platforms. New features such as a system-level notification center, a permission system for installing apps, a Sharing menu inside the browser and deeper iCloud integration make the new version of the OS resemble its mobile equivalent.

RIM released a new version of Blackberry Playbook OS. Version 2 includes a lot of features that were notably missing in the first release, including a native email client, a unified inbox, built-in calendar and contacts applications. The BlackBerry Messenger, a key differentiating feature for the OS, is still missing from the Playbook version.

Canonical announced Ubuntu for Android, a port of the operating system to run side-by-side with Android on a shared kernel. When in phone mode, the software looks and behaves like Android, and when connected to a dock, it switches to the Ubuntu environment. When connecting to a TV, the Ubuntu TV interface is activated. Canonical stated it is looking for hardware partners for this project.

People tend to browse on their phone similar amounts of time during the week compared to the weekend, reveals Opera’s latest State of the Mobile Web report. The variation between amount of unique users, page views and data transfer between weekdays and weekends, in 50 countries, as analyzed by Opera, does not surpass 10%. On the desktop, browsing declines by up to 22%.

The Kindle Fire accounted for 36% of Android tablet applications sessions in January 2012, on par with the Samsung Galaxy Tab, according to analytics firm Flurry. Amazon’s US tablet share rose from 3% in november 2011 to the current number. The other most used tablets by app usage are the Acer Transformer and the Acer Iconia Tab, each with 7%. Flurry Analytics also reported that US mobile consumers spend more time in apps than on the the Web in December 2011, with an average of 72 per day on the Web and 94 minutes per day in apps.

I’m a big fan of RSA Animate videos, and this one by Sir Ken Robinson on our education system definitely seemed to strike a chord with me.

“We have to think differently about human capacity.  We have to get over this old conception of academic, non-academic, abstract, theoretical, vocational…and see it for what it is: a myth.”

I'd like to start out by saying that, as always, this year's FOSDEM was the best FOSDEM ever...

2 entire days of talks (mostly developer oriented but not always), of booths presenting different free/open source projects, and of Belgian beer (ah, what would be FOSDEM without beer?) make up one of the best weekends you can imagine. As always, this year's edition was hosted at the ULB University in Brussels, Belgium. And under the snow, if you please!

(Picture by ElectroLab)

As each year, Mozilla had it's own Devroom with many different and interesting talks. The only thing that was really different this year was that the event was dispatched amongst 3 different buildings, whereas the previous years we were all usually dispatched between 2 main buildings. IMO it was a good idea to expand the event, because it was getting more and more packed as time went by.

(Mozilla Devroom - Picture by Julia Buchner)

I attended many talks during FOSDEM but what I can describe the best is, of course, the talk we gave with Clarista. We presented "The State of WoMoz" (slides part 1, slides part 2), and described the different projects we have already done with Women & Mozilla, as well as the upcoming projects that we are working on.

Thanks to this talk, we then met incredible and inspiring people. Amongst them, 2 wonderful women who run the Greenlight for Girls project, and with who we share the same ideas and passion: getting more girls interested in computer fields, and involving more women in Free and Open Source.

Greenlight for Girls regularly run workshops for young girls around the globe, showing them how fun and exciting technology, electronics, maths, science, etc. can be. What they do is very inspiring and I recommend you take a look at what they do here.

(WoMoz talk - Picture by Julia Buchner)

Clarista and I talked for a long time with these fantastic women and we really want to join efforts and organize events together. And if you're interested in organizing the same kind of events, all you have to do is take action and DO IT! I'm sure we'll have many interesting things going on around this, so stay tuned, more will come quickly! As a matter of fact, a follow-up about this will be published soon on the WoMoz Blog.

We also talked about continuing the PyStar Paris initiative, and running a second event. PyStar are workshops for women that teach them Python programming. For more info about the first PyStar Paris we organized, you can read this post here.

So stay tuned for that as well

To finish this post, I want to say, as always, a big "BRAVO" to FOSDEM organizers who volunteer to help out and create such a cool and BIG event.

And an extra-special thank you to Benoit Leseul (long-time Belgian contributor in the French-speaking community), who took care of almost all Mozilla logistics and organization. From dawn until evening, he was always there to lend a helping hand and help out with any possible issue or question, mastering the unexpected as if he'd done this all his life! Merci Benoit

And see you all next year!

(Sunday Night, hanging out with members from various Mozilla communities - Picture by Santiago Hollmann)