As part of project Async, we have been working on refactoring Firefox’ Session Restore to ensure that it does not block the main thread. Part of the work has been cleaning up the code and the data structures involved in Session Restore both to give us some maneuverability and to improve the chances of catching refactoring errors.

Unfortunately, a large number of add-ons seem to rely upon these undocumented data structures. Some of their features might therefore stop working. If you are the author of one such add-on, you should monitor carefully bug 874381 and its blockers. If you realize that we are about to break your add-on, please inform us asap, so that we can work out a solution.

If there’s one feature of Rust that is probably the most unique among languages in industry, it’s safe manual memory management.

It’s easiest to explain safe manual memory management by explaining how it differs from the memory models of other languages. There are a few different models in common use in industry languages:

• Unsafe manual memory management—These languages provide very fine-grained control over memory allocation; heap memory can be explicitly allocated and deallocated. The most important examples here are C and C++. The well-known downside of this approach is that memory safety violations can only be detected at runtime with a memory safety checker such as Valgrind or Address Sanitizer. Memory safety violations that go unchecked can lead to crashes at best and exploitable security vulnerabilities at worst.

• Full garbage collection—The majority of modern languages expose a memory model that falls into this category—the space is very diverse, ranging from Java to Go to JavaScript to Ruby to Haskell. In general, such languages place all allocations into the heap instead of the stack, although escape analysis and value types may be used to reduce the number of heap allocations. Periodically, a garbage collector scans all pointers on the stack and in the heap, judges unreachable objects dead, and reclaims them. This approach has the advantage of memory safety at compile time—the language arranges for there to be no dangling pointers, wild pointers, and so forth. The downsides, however, are:

  1. The garbage collector may run at an inconvenient time. This can be mitigated by explicit control over when the GC runs, although if the garbage collector must collect multiple threads’ heaps at the same time, this may be difficult to synchronize. This can also be mitigated by using manual memory pooling and free lists, although pooling has undesirable safety properties—much like unsafe manual memory management, there is no static guarantee that objects allocated from a pool are returned properly or that an object is not reachable when returned to the pool. Incremental and concurrent garbage collectors help here, but they are not free, as they typically require write and/or read barriers, reducing throughput.

  2. When it runs, the garbage collector must mark all pointers to discover which ones are live, reducing throughput of the application. Essentially, the GC must discover at runtime what a C++ (say) programmer knows at compile time. Not much can typically be done about this cost in fully garbage-collected languages, short of falling back to unsafe manual memory management. Pools don’t help much here, because the GC must still trace the pointers into the pool. Even pointers into the stack generally must be traced.

• Garbage collection with value types and references—This category includes languages like C#. (I believe D falls into this category as well, although I may be mistaken.) These languages are essentially garbage-collected, but they include value types which are guaranteed to be stack-allocated if in local variables. Additionally, and most importantly, they include reference parameters (and sometimes reference locals), which allow stack-allocated values to be temporarily aliased when calling another function. Effective use of value types can reduce marking and sweeping time. In general, this system is an effective addition to a garbage-collected system, allowing a good measure of additional control without much cost in complexity and no cost in memory safety. It is not, however, typically sufficient to write programs without using the garbage collector at all; the system is too simple to statically encode anything other than the most basic memory management patterns.

Where does Rust fit in? Actually, it fits into a category all to itself among industry languages (although one shared by various research languages, like Cyclone). Rust offers safe manual memory management (although some have objected to the term “manual” here). It extends the system described above as “garbage collection with value types and references” in two important ways:

1. You can allocate memory that will not be traced by the garbage collector, and free it manually if you choose. This is the feature of Rust known as “unique pointers”. Rust will automatically free memory that is uniquely owned when its owning pointer goes out of scope. It’s also easy to write a function that acts exactly as free does, so you can precisely choose when your objects die. Unique pointers are not traced by the GC (unless they point to a type that transitively contains a garbage-collected pointer), so they are an effective way to cut down marking times.

2. You can return references and place references into data structures. Like other references, these references are not traced by the garbage collector. As long as the references follow a stack discipline, meaning that they point to memory that was allocated by one of the callers of the current function, the compiler allows them to be placed anywhere. This adds a great deal of expressiveness over the reference parameter approach, and it enables a large number of programs to be written without using the garbage collector at all.

In terms of safety and performance, safe manual memory management is having your cake and eating it too. You get memory safety like a garbage-collected language, but control like that of unsafe manual memory management. But this system has its downsides as well—most importantly, complexity of implementation and interface. Learning to use references and unique pointers poses a significant learning curve. But, once the system is learned, it’s remarkably flexible, with an attractive combination of performance and safety.

There’s a fantastic set of blog posts about distributed databases and network partitioning, starting with this post explaining the perils of trying to “communicate with someone who doesn’t know you’re alive.”

The next post is about Postgres and 2-phase commit. And there are four additional posts in the series.

The whole series worth reading for anyone interested in data stores, consistency and Postgres!

After a bunch of l10n build problems, we've finally released Instantbird 1.4, which includes updates to libpurple 2.10.7 and Mozilla 20.  In particular this includes:

• Updated Twitter code that uses v1.1 of their API (v1.0 will be disabled on June 11th, 2013).
• Better character counter for Twitter (it now takes into account if URLs are embedded).
• Updated log viewer which organizes logs by date (and nests them by week, month, etc.)
• Better support for IRC bouncers.
• Support for overriding self-signed/invalid/out-of-date certificates for IRC.

If you've been using some other instant messaging client (e.g. Pidgin or Adium); I'd highly suggest giving Instantbird a try, especially if you also go on IRC. Instantbird has great IRC support! (And...if you do have issues, feel free to ping me in #instantbird on irc.mozilla.org and let me know what your issue is.)

You can download it here, or view the full release notes.

I’ve been remote with Mozilla for almost 5 years. This is very difficult, from an emotional and a shared vision perspective.

Vidyo, among other tools, have been very important in maintaining a “lifeline” to my day to day teammates.

I have one big pet peeve, which I’d like to document, so that Zandr and others can upstream this to the Vidyo team.

The Problem

Many calls have 8-12 people. Vidyo does a Brady Bunch type visualization, but at some point it starts hiding participants.

Technically, I can imagine there are several good reasons for hiding participants: Full video from all participants is a bandwidth hog, managing latency is more difficult, etc.

But humans are “out of sight, out of mind”. I’ve been in so many calls where people start speaking as though Jane is not on the call, as soon as her video window gets hidden.

“Uhmmm, I’m on the call. Vidyo is just being dumb” — Jane

“Sorry, you weren’t on my screen” — Tarzan

A workaround I use, but which is not a common practice, is to display the list of all participants on a call. I have this overlay part of my Vidyo window and it’s fugly.

Aside: How to show everyone

Click Gear icon. Click Participants.

A couple ideas

Vidyo should always display some kind of representation of each person on the call.

Low bar would be a textual list of participant names down in a new column on the left.

A better solution would be to add an avatar grid for participants who had been de-prioritized and would be hidden in the current version of the software. These avatars would be smaller, so you could fit 100% of the participants on the screen.

The small squares on the left are static. These are very cheap from a technical point of view. They give us the visual human connection, which we need.

The large squares on the right are video, just as we see today.

The avatar image would be taken a few seconds into the call via the webcam.

There would be visual feedback to a user showing their current avatar frame.

I’d love to be able to “Refresh Avatar” which would capture my current webcam view and make it a static avatar.

Or, "yet another awkwardly named class"
One of the most important tenets of Socorro is to be resilient when external resources fail. The Mozilla Socorro deployment depends on Postgres and HBase to work. However, these are two external resources that can fail.
What happens when we try to write to one of these and we find that the resource in unavailable? Earlier versions of Socorro treated the HBase and Postgres failure cases separately.
For Postgres, since it is a transactional storage system, Socorro employed the native transactional behaviors. Interacting with Postgres involves a series of steps (insert, update, delete, select) followed by commit or rollback. If one of the intervening steps were to fail, we didn't want the program to quit, nor did we want errors to be ignored. Socorro implemented a “backing off retry” behavior. On failure of a step, the code would classify failure into one of two types: retriable and fatal. In either case, a rollback would be issued. In the retry case, the code would sleep for a predetermined amount of time and then retry the transaction from the beginning. In the fatal case, there is no choice except to allow the program to shutdown.
For HBase, true transactions are not supported. However, the behavior Socorro wanted was just the same as the Postgres case: classify the failure and then, if retriable, repeat the steps until we have success. HBase doesn't have the concept of commit and rollback, but the intervening steps of a transaction may be repeated without negative consequence.
Even though the behavior was similar, the two cases were coded independently and shared no code. In the grand Configman refactoring of Socorro, the two cases were merged into one class to maximize reuse. The Postgres case was used as the canonical example. Dummy null op commit and rollback were added to the HBase connection classes to facilitate the use of the class.
How do the TransactionExectorclasses work? There are three of them with slightly different behaviors:

• TransactionExecutor
• TransactionExecutorWithLimitedBackoff
• TransactionExecutorWithInfiniteBackoff

The code can be found at: https://github.com/mozilla/socorro/blob/master/socorro/database/transaction_executor.py

These classes implement methods that accepts a function, a connection context to some resource and arbitrary function parameters. When instantiated and invoked, these classes will call the function passing it the connection and the additional parameters. The raising of an exception within the function indicates that a failure of the transaction: a rollback is automatically issued on the connection context. If the function succeeds and exits normally, then a 'commit' is issued on the connection context.

The first class in the list above is the degenerate single-shot case. It doesn't implement any retry behavior. If the function fails by raising an exception, then a rollback is issued on the connection and program moves on. Success results in a commit and the program moves on.

The latter two classes implement a retry behavior. If the function raises an exception, the Transaction class checks to see if the exception is of a type that is eligible for retry. If it is eligible, then a delay amount is selected and the thread sleeps. When it wakes, it tries to invoke the function again with the same parameters. The time delays are specified by a list of integers representing successive numbers of seconds to wait before trying again. For the class TransactionExecutorWithLimitedBackoff, when the list of time delays is exhausted the transaction is abandoned and the program moves on. The TransactionExecutorWithInfiniteBackoff will never give up, running the last time in the delay list over and over until the transaction finally succeeds or somebody kills the program.

How does the TransactionExecutor determine if an exception is eligible for retry? The connection context object is required to have a couple instance variables and methods to assist in the determination.

First, operational_exceptions defines a collection of exceptions that are eligible for the retry behavior. If one of the exceptions from this collection is raised, the retry behavior is triggered.

conditional_exceptions is a list of ambiguous exceptions that may or may not be eligible for retry. We encountered this with Postgres using psycopg2 on the ProgrammingError exception. Normally, this type of exception would not be retriable because it indicates a fundamental problem with a query such as a syntax error. Syntax errors are not retrible. However, sometimes we get network errors disguised as ProgrammingErrors; these are retriable.

If an exception found in the conditional_exceptions collection is raised, we have to further examine the error to determine if it should result in a failure or retry. The instance method is_operational_exception implemented by the connection class is used to determine in the current exception is retriable or not. In the case of Postgres, we look to the text of the exception to see if it contains the string “EOF”. We know that's a network error, not really a programming error so we can do a retry.

Is this class named poorly? Now that we've got many more external resources using this retry behavior and only Postgres is truly transactional, it seems that the name may not be right. Perhaps ExternalResourceActionRetrier?

Note

Circus is a process & socket manager. See https://circus.readthedocs.org

Photo by kennethreitz

During Django Con, I was asked how to use Circus to run & monitor a Python web application. The documentation has no single page step-by-step tutorial yet, so here goes... this blog post will be integrated into the documentation for the next release.

Installation

Circus is tested under Mac OS X and Linux, on the latest Python 2.6 and 2.7. To run a full Circus, you will also need libzmq, libevent & virtualenv.

Under Debuntu:

$ sudo apt-get install libzmq-dev libevent python-virtualenv

Create a virtualenv and install circus, circus-web and chaussette in it

$ virtualenv /tmp/circus $ cd /tmp/circus $ bin/pip install circus $ bin/pip install circus-web $ bin/pip install chaussette

Once this is done, you'll find a plethora of commands in the local bin dir.

Usage

Chaussette comes with a default Hello world app, try to run it:

$ bin/chaussette

You should be able to visit http://localhost:8080 and see hello world.

Stop Chaussette and add a circus.ini file in the directory containing:

[circus] stats_endpoint = tcp://127.0.0.1:5557 httpd = 1 [watcher:webapp] cmd = bin/chaussette --fd $(circus.sockets.web) numprocesses = 3 use_sockets = True [socket:web] host = 127.0.0.1 port = 9999

This config file tells Circus to bind a socket on port 9999 and run 3 chaussettes workers against it. It also activates the Circus web dashboard and the statistics module.

Save it & run it using circusd:

$ bin/circusd --daemon circus.ini

Now visit http://127.0.0.1:9999, you should see the hello world app.

You can also visit http://localhost:8080/ and enjoy the Circus web dashboard.

Interaction

Let's use the circusctl shell while the system is running:

$ bin/circusctl circusctl 0.7.1 circusd-stats: active circushttpd: active webapp: active (circusctl)

You get into an interactive shell. Type help to get all commands:

(circusctl) help Documented commands (type help <topic>): ======================================== add get list numprocesses quit rm start stop decr globaloptions listen numwatchers reload set stats dstats incr listsockets options restart signal status Undocumented commands: ====================== EOF help

Let's try basic things. Let's list the web workers processes and add a new one:

(circusctl) list webapp 13712,13713,13714 (circusctl) incr webapp 4 (circusctl) list webapp 13712,13713,13714,13973

Congrats, you've interacted with your Circus! Get off the shell with Ctrl+D and now run circus-top:

$ bin/circus-top

This is a top-like command to watch all your processes' memory and CPU usage in real time.

Hit Ctrl+C and now let's quit Circus completely via circus-ctl:

$ bin/circusctl quit ok Next steps

You can plug your own WSGI application instead of Chaussette's hello world simply by pointing the application callable.

Chaussette also comes with many backends like Gevent or Meinheld.

Read https://chaussette.readthedocs.org/ for all options.

Since it was founded 12 years ago this week, Wikipedia has become an indispensable part of the world’s information infrastructure. It’s a kind of public utility: You turn on the faucet and water comes out; you do an Internet search and Wikipedia answers your question. People don’t think much about who creates it, but you should. We do it for you, with love.

Wikimedia Foundation Executive Director Sue Gardner, from http://blog.wikimedia.org/2013/01/14/wikipedia-the-peoples-encyclopedia/

As Sue says, the people who create Wikipedia are terrific. I’m lucky enough to say that I’ve just wrapped up my first three months as their lawyer – as Deputy General Counsel at the Wikimedia Foundation. Consider this the personal announcement I should have made three months ago :)

Wikimania 2012 Group Photograph, by Helpameout, under CC-BY-SA 3.0.

Greenberg Traurig was terrific for me: Heather has a wealth of knowledge and experience about how to do deals (both open source and otherwise), and through her, I did a lot of interesting work for interesting clients. Giving up that diversity and experience was the hardest part of leaving private practice.

Based on the evidence of the first three months, though, I made a great choice – I’ve replaced diversity of clients with a vast diversity of work; replaced one experienced, thoughtful boss with one of equal skill but different background (so I’m learning new things); and replaced the resources (and distance) of a vast firm with a small but tight and energized team. All of these have been wins. And of course working on behalf of this movement is a great privilege, and (so far) a pleasure. (With no offense to GT, pleasure is rarely part of the package at a large firm.)

The new scope of the work is perhaps the biggest change. Where I previously focused primarily on technology licensing, I’m now an “internet lawyer” in the broadest sense of the word: I, my (great) team, and our various strong outside counsel work on topics from employment contracts, to privacy policies, to headline-grabbing speech issues, to patent/trademark/copyright questions – it is all over the place. This is both challenging, and great fun – I couldn’t ask for a better place to be at this point in my life. (And of course, being always on the side of the community is great too – though I did more of that at Greenberg than many people would assume.)

I don’t expect that this move will have a negative impact on my other work in the broader open source community. If anything, not focusing on licensing all day at work has given me more energy to work on OSI-related things when I get home, and I have more flexibility to travel and speak with and for various communities too. (I’m having great fun being on the mailing lists of literally every known open source license revision community, for example. :)

If you’d like to join us (as we work to get the next 1/2 billion users a month), there are a lot of opportunities open right  now, including one working for me on my team, and some doing interesting work at the overlap between community, tech, and product management. Come on over – you won’t regret it :)

…for their help in significantly mitigating the problems we were having with running out of memory when linking Firefox with Profile-Guided Optimization using Microsoft Visual C++. (If we’d have had to turn off PGO due to this problem, that would have made Firefox’s performance on Windows significantly worse.) Ted has the write-up.

Open Badges started as a modest experiment: build open source badge issuing software for ourselves and others. As momentum around this experiment has grown, it feels like the opportunity is bigger: we could build openness and user empowerment into how learning — and professional identity — work all across the web. With Open Badges 1.0 out there in the world, now is the right time to ask: where next for Mozilla and badges?

When Mozilla and MacArthur Foundation first started work on Open Badges about 18 months ago, the plan was to build a badge interchange standard (like SMTP for skills) and a collection of open source software for issuing and sharing badges (Badge Backpack, Open Badger, etc.). We’ve built all these things. And we’ve put up a reference implementation that Mozilla and others are using. This was really the limit of our original plan: build some basic open tech for badges and put it out there in the world.

The thing is: there has been way more excitement and pick up of badges than we expected. Even though Open Badges only launched officially in March, there are already over 800 unique providers who have issued almost 100,000 badges. We are also starting to see the development of city-wide systems where learners can pick up hundreds of different badges from across dozens of learning orgs and combine them all into a single profile. Chicago is the first city to do this (June 1), but Philadelphia and San Francisco are not far behind. And, this is just the tip of the iceberg: orgs like the Clinton Global Initiative and the National Science Foundation are focusing on badges in a way that is likely to drive even more educators to pick up the Open Badges standard, making their badges interoperable with others.

Of course, the fact that educators and policy makers are interested in badges doesn’t represent a victory in itself. It just shows momentum and buzz. The real opportunity — and the real impact — comes when learners and employers get excited about badges. Mozilla never planned to build offerings for these audiences. Increasingly, it feels like we should.

In the Internet era, people learn things online and out of school all the time. Whether you want to make a web page, knit a sweater or get better at calculus, the internet makes it easy to learn on your own or with a group of friends outside of a school setting. However, there is no good way to get credentials or recognition for this kind of learning. And, even if there was, there is no trusted, verifiable way to plug that recognition into Facebook, About.me and other places that make up your online identity. People have no good way to show ‘what they know’ online.

Similarly, employers are increasingly turning to the internet to find talent. They use sites like LinkedIn that let you search online resumes. Or, increasingly, to sites like Gild and TalentBin that use data mining to find potential hires. The problem: these services do not offer granular or variable skills profiles. And, with some of them, there are significant issues around privacy: people are being offered up as potential hires without even knowing that these sites are collecting data about them.

Mozilla could offer a distributed, open source and privacy-friendly solution to problems like these. We could help learners show their skills in all their online profiles and also help employers search for talent reliably. However, to do so, we’d have to build a Firefox-quality offering for learners and employers on top of Open Badges. While this hasn’t been our focus up til now, I’m thinking more and more that this is something we should consider.

In some ways, there is a parallel to Gecko and Firefox. Gecko provides the underlying platform for shaping standards around our vision of the web. But we need a popular consumer offering like Firefox if we want this vision to actually become relevant in the market. Right now, with Open Badges, we’re mostly just playing at the underlying standards layer. If we really want to shape how learning and professional identity work on the web, we probably need to build our own offerings directly for the people who most want and need badges.

Now is the time to be looking at where the opportunity is in this space. Momentum and demand is amongst educators is growing. More and more start ups are appearing in the badges, portfolio and skills spaces. And likelihood that badges will be important for learners and employers is growing. We need to be asking ourselves: how can Mozilla — and its values — shape this space?

With this in mind, Erin Knight is leading an effort over the next few months to look at different badges product options. She’ll be providing updates on her blog. And I’ll be summarizing here as well. If you have ideas on where Mozilla should go on all of this, we’d love to have you involved as we think this through. Comments here on this post are a good place to start.

Filed under: badges, drumbeat, education, learning, mozilla, webmakers

This is why we do what we do. (Via Arky.)

I’ve tweaked the cpp.vim file that comes with Vim 7.3 to highlight most Mozilla-specific keywords when working on the editor core. A lot of Mozilla-specific types and that can be added manually but the task gets bigger when it comes to nsI* interfaces or NS_* macros…

Most nsI* interfaces can be grabbed with find/grep/sed:

find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^\(class\|interface\)\s*nsI" '{}' \; | sed 's/\(:\|;\|,\|{\).*$//' | sed 's/^.*nsI/nsI/' | sed 's/\s*$//' | sort -u

same thing for NS_ERROR* / NS_IMPL* macros and constants:

find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^#define\s*NS_ERROR" '{}' \; | sed 's/^#define\s*//' | sed 's/\s.*$//' | sed 's/(.*$//' | sort -u find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^#define\s*NS_IMPL" '{}' \; | sed 's/^#define\s*//' | sed 's/\s.*$//' | sed 's/(.*$//' | sort -u

Here’s the resulting cpp.vim file including the ~900 Mozilla-specific lines (ouch!). Copy it to your ~/.vim/syntax/ directory and voilà, your C++ files should be much more colorful.

Now it’d be really great if:

• we had omni-completion for the nsI* interfaces instead of just the keywords;
• we had a similar file (keywords + omni-completion) for JavaScript — mostly for the DOM API
• this file could be generated automatically — say, with DXR;
• this file could be included in the Mozilla tree (e.g. a .vimrc file in the top source dir).

To all Vim fanboys among the Mozilla community: I’d love to get your input about that. Maybe we could start a “vim-moz-syntax” project on github or something?

EDIT: (2013-05-19)

• this work is now available on github: https://github.com/mozfr/mozilla.vim
• there’s been an article about this in Russian: http://softdroid.net/Vim-Syntax-Highlighting

I have the privilege of having my desk located around a bunch of really intelligent people from the Mozilla Services team. They've been talking a lot about all the new technologies around server provisioning. One that interested me is Docker.

Docker is a pretty nifty piece of software. It's essentially a glorified wrapper around Linux Containers. But, calling it that is doing it an injustice.

Docker interests me because it allows simple environment isolation and repeatability. I can create a run-time environment once, package it up, then run it again on any other machine. Furthermore, everything that runs in that environment is isolated from the underlying host (much like a virtual machine). And best of all, everything is fast and simple.

For my initial experimentation with Docker, I decided to create an environment for building Firefox.

Building Firefox with Docker

To build Firefox with Docker, you'll first need to install Docker. That's pretty simple.

Then, it's just a matter of creating a new container with our build environment:

curl https://gist.github.com/indygreg/5608534/raw/30704c59364ce7a8c69a02ee7f1cfb23d1ffcb2c/Dockerfile | docker build

The output will look something like:

FROM ubuntu:12.10 MAINTAINER Gregory Szorc "gps@mozilla.com" RUN apt-get update ===> d2f4faba3834 RUN dpkg-divert --local --rename --add /sbin/initctl && ln -s /bin/true /sbin/initctl ===> aff37cc837d8 RUN apt-get install -y autoconf2.13 build-essential unzip yasm zip ===> d0fc534feeee RUN apt-get install -y libasound2-dev libcurl4-openssl-dev libdbus-1-dev libdbus-glib-1-dev libgtk2.0-dev libiw-dev libnotify-dev libxt-dev mesa-common-dev uuid-dev ===> 7c14cf7af304 RUN apt-get install -y binutils-gold ===> 772002841449 RUN apt-get install -y bash-completion curl emacs git man-db python-dev python-pip vim ===> 213b117b0ff2 RUN pip install mercurial ===> d3987051be44 RUN useradd -m firefox ===> ce05a44dc17e Build finished. image id: ce05a44dc17e ce05a44dc17e

As you can see, it is essentially bootstrapping an environment to build Firefox.

When this has completed, you can activate a shell in the container by taking the image id printed at the end and running it:

docker run -i -t ce05a44dc17e /bin/bash # You should now be inside the container as root. su - firefox hg clone https://hg.mozilla.org/mozilla-central cd mozilla-central ./mach build

If you want to package up this container for distribution, you just find its ID then export it to a tar archive:

docker ps -a # Find ID of container you wish to export. docker export 2f6e0edf64e8 > image.tar # Distribute that file somewhere. docker import - < image.tar

Simple, isn't it?

Future use at Mozilla

I think it would be rad if Release Engineering used Docker for managing their Linux builder configurations. Want to develop against the exact system configuration that Mozilla uses in its automation - you could do that. No need to worry about custom apt repositories, downloading custom toolchains, keeping everything isolated from the rest of your system, etc: Docker does that all automatically. Mozilla simply needs to publish Docker images on the Internet and anybody can come along and reproduce the official environment with minimal effort. Once we do that, there are few excuses for someone breaking Linux builds because of an environment discrepancy.

Release Engineering could also use Docker to manage isolation of environments between builds. For example, it could spin up a new container for each build or test job. It could even save images from the results of these jobs. Have a weird build failure like a segmentation fault in the compiler? Publish the Docker image and have someone take a look! No need to take the builder offline while someone SSH's into it. No need to worry about the probing changing state because you can always revert to the state at the time of the failure! And, builds would likely start faster. As it stands, our automation spends minutes managing packages before builds begin. This lag would largely be eliminated with Docker. If nothing else, executing automation jobs inside a container would allow us to extract accurate resource usage info (CPU, memory, I/O) since the Linux kernel effectively gives containers their own namespace independent of the global system's.

I might also explore publishing Docker images that construct an ideal development environment (since getting recommended tools in the hands of everybody is a hard problem).

Maybe I'll even consider hooking up build system glue to automatically run builds inside containers.

Lots of potential here.

Conclusion

I encourage Linux users to play around with Docker. It enables some new and exciting workflows and is a really powerful tool despite its simplicity. So far, the only major faults I have with it are that the docs say it should not be used in production (yet) and it only works on Linux.

Globaleaks 0.2 Alpha is out.

Globaleaks is an open source project aimed at creating a worldwide, anonymous, censorship-resistant, distributed whistle-blowing platform. It enables organizations interested in running whistle-blowing initiatives to setup their own safe zone, where whistle-blowers and recipients can exchange data.

2 Years ago I helped out with the development of Globaleaks 0.1. And although I am not active anymore, I really support the initiative behind it. Now with the HERMES Center for Transparency and Digital Human Rights backing it up, it has grown a lot and shaped up to be a very organized and thought through project.

TL;DR:

• Full rewrite
• More flexible and extensible
• Linux ready-made system and network hardened installation
• Written in python using twisted
• New Frontend

Try it out:

Try out the demo. It is pretty straight forward.

Help out:

As young project, Globaleaks can use some help fixing bugs. Just head to the wiki and read through it. It is pretty straight forward, and explains the modules, security concepts and set up instructions.

Globaleaks already has Debian and Ubuntu ready packages. An easy way to help out is to set up a  PPA for us on Launchpad.

Get in touch:

You can contact the Globaleaks team at info () globaleaks org or on IRC on #globaleaks at irc.oftc.net

Here are some screenshots of the new frontend

Congratulations you are using Tor

Receiver selection page

The submission receipt

Configuring a receiver

Configuring a context

In part 01 of these series, I showed why is it important to always define the language and the direction of all HTML content and not rely on the defaults: The content may get embedded in a document with different direction and be displayed incorrectly.

This issue is laughably easy to avoid: If you are writing the content, you are supposed to know in what language it is written, so if it’s English, just write <html lang=”en” dir=”ltr”> even though these seem to be the defaults. Nineteen or so characters that ensure your content is readable and not displayed backwards. Please do it always and tell all your friends to do it.

The problem is that you don’t only have to explicitly set the language and the direction, but, as silly as it sounds, you have to set them correctly, too. A more subtle, but nevertheless quite frequent and disruptive bug is displaying presumably, but not actually, translated content in a different direction. This happens quite frequently when a website supports the browser language detection feature, known as Accept-Language:

1. The web server sees that the browser requests content in Hebrew.
2. The web server sends a response with <html lang=”he” dir=”rtl”>, but because the website is not actually translated, the text is shown in the fallback language, which is usually English.
3. The user sees the content just like this numbered list, which I intentionally set to dir=”rtl”: with the numbers and the punctuation on the wrong side, and possibly invisible, because English is not a right-to-left language.

Of course, it can go even worse. Arrows can point the wrong way and buttons and images can overlap and hide each other, rendering the page not just hard to read, but totally unusable.

This bug is also an example of the Software Localization Paradox: It manifests itself when Accept-Language is not English, but most developers install English operating systems and don’t bother to change the preferred language settings in the browser, so they never see how this bug manifests itself. The site developers don’t bother to test for it either.

The solution, of course, is to set a different language and direction only if the site is actually translated, and not to pretend that it’s translated if it’s not.

Here are two examples of such brokenness. Both sites are important and useful, but hard to use for people whose Accept-Language is Hebrew, Persian or Arabic.

Here’s how the Mozilla Developer Network website looks in fake Hebrew:

Mozilla Developer Network website, in English, but right-to-left

Notice how the full stops are on the left end and how the text overlaps the images in the tiles on the right-hand side. This is how it is supposed to look, more or less:

Mozilla Developer Network home page in English, left-to-right

I manually changed dir=”rtl” to dir=”ltr” using the element inspector from Firefox’s developer tools and I also had to tweak a CSS class to move the “mozilla” tab at the top.

The above troubles are reported as bug 816443 – lang and dir attributes must be used only if the page is actually translated.

After showing an example of a web development bug from a site for, ahem, web developers, here is an even funnier example: The home page of Unicode’s CLDR. That’s right: Unicode’s own website shows text with incorrect direction:

The Unicode CLDR website, in English but right-to-left

The only words translated here are “Contents” (????) and “Search this site” (????? ???? ??), which is not so useful. The rest is shown in English, and the direction is broken: Notice the strange alignment of the content and the schedule table. A few months ago that table was so broken that its content wasn’t visible at all, but that was probably patched.

Here’s how it is supposed to look:

The CLDR home page in English, appropriately left-to-right

I tried reporting the CLDR home page direction bug, but it was closed as “out-of-scope”: The CLDR developers say that the Google Sites infrastructure is to blame. This is frustrating, because as far as I know Google Sites doesn’t have a proper bug reporting system and all I can do is write a question about that direction problem in the Google Sites forum and hope that somebody notices it or poke my Googler friends.

One thing that I will not do is switch my Accept-Language to English. Whenever I can, I don’t just want to see the website correctly, but to try to help my neighbor: see the possible problems that can affect other users who use different language. Somebody has to break the Software Localization Paradox.

Filed under: Firefox, Free Software, localization

Backstory

Every 3 months, we at Mozilla have to reset our LDAP passwords. The system helpfully sends the first reminder 2 weeks before your password expires, then the second reminder 1 week before your password expires and the last reminder 2 days before your password expires.

Sometimes time passes by faster than you know and you end up with a Locked out of LDAP account.

The 3 month LDAP password reset is such a large part of our lives that I propose it become a standard unit of measure for elapsed time.

Usage

Used in casual conversation:

Pat: Hi!

Jordan: Hi!

Pat: I haven't seen you before. How long have you been at Mozilla?

Jordan: I've been here for 6 LDAP password resets.

Pat: Oh, weird. I've been here for 7. Good to meet you! Would you like a banana?

Jordan: Would I ever!

Used in casual conversation on IRC:

<patbot> anyone use less? <corycory> i only use sass. it's the best. * riledupriley has quit (Quit: riledupriley) <patbot> :( <hugbot> (patbot) * r1cky has joined #casualconversationexample <r1cky> morning! <nigelb> r1cky: hai! <nigelb> Ah, it's nearly mfbt. <mtjordan> sure. been using it for 3 ldap password resets. <mtjordan> patbot: why do you ask?

Used in Bugzilla comments:

Jordan [:jordan] 1 day ago Comment 0 [reply] [-] Readonly mode causes the site to ISE. Pat [:pat] 1 day ago Comment 1 [reply] [-] I looked into it. Turns out we haven't used readonly mode in at least 4 LDAP password resets. I think we just need to add a fake authentication module. Easy peasy.

Used when joining a new group:

From: Pat To: some-group@mozilla.org Subject: Welcome Jordan to some-group! Hi all! I'd like to welcome Jordan to some-group! Jordan brings expertise that is invaluable. I'm excited! Yay! Jordan: Tell us about yourself! Pat From: Jordan To: some-group@mozilla.org Subject: Re: Welcome Jordan to some-group! Hi! I'm excited to join some-group! Hopefully I bring something useful to the table. I've been at Mozilla for 7 LDAP password resets, I like top-posting and I make a mean cold brew coffee. Looking forward to my first meeting! Jordan On Blah blah blah at blah blah blah, Pat wrote: > Hi all! > > I'd like to welcome Jordan to some-group! Jordan brings > expertise that is invaluable. I'm excited! Yay! > > Jordan: Tell us about yourself! > > Pat

Used in an email to everyone@ about departing:

Dear everyone! It is with sadness that I tell you I'm leaving as of next Friday. As you know, I've been with Mozilla for 32 LDAP password resets and frankly, I'm totally out of usable Sherlock Holmes story titles, so I'm off to new challenges. I will miss you all.

[Comments]

Sometimes web pages display brief warning boxes at the top with "learn more" links. The learn more link in a specific warning box should go to a page specifically about that warning with, in rough order:

1. screenshot of warning box
2. quoted full text of the warning (for searchability / search engine discovery)
3. detailed text answering:
   • how could have the issue occurred?
   • what should the user do to resolve the issue?
   • how can the user avoid the issue in the future?

E.g. the "Learn more ›" link in the yellow warning box in this screenshot:

links to: https://support.twitter.com/articles/82050-i-m-having-trouble-confirming-my-email which:

• Neither has screenshot nor text of warning
• Covers several topics unrelated to the warning
• Does not answer the above questions

And could be improved by linking to a specific page about this particular warning, containing the above points 1-3, and answering all three questions in point 3.

Related: Scary Twitter warning: "... removed the email address from your account...

In response to my post earlier this week on Tinderbox’s end-of-life, reader Carsten Mattner asked:

Reading [your post], I couldn’t figure out what replaced Tinderbox for the Mozilla builds. What feeds tbpl? Does Mozilla not use Tinderbox to build continuously?

When I left Mozilla in 2007, there was a Release Engineering project in progress to actively replace Tinderbox (Client) with buildbot. So in short, no, Mozilla does not use Tinderbox Client to drive its continuous integration builds, and hasn’t for some time.

Do they still use buildbot today?

I didn’t know the answer to that question, so I tracked down Coop on IRC, who graciously gave me a few minutes of his time to answer exactly that.

He said:

• Mozilla currently uses “95% buildbot, with 5% Jenkins for random small projects”
• There are multiple buildbot masters that drive the buildbot clients
• Unlike the out-of-the-box buildbot master setup, the masters query a job scheduling database instead of monitoring source control for changes themselves; they then report their results to a database, which tbpl (and other services) use to generate their reports/dashboards; the buildbot master waterfall pages aren’t accessible to the external world (which makes sense, because they include unsecured administrative functionality1)
• There are about 60 masters right now, but Coop said “number keeps growing though, so we need to rethink the whole solution”

So there’s your answer, Carsten!

_______________
1 A long standing criticism of mine, among others?

I’ve got a Beer & Tell to give about alembic. Alembic is a migration tool that works with SQLAlchemy. I’m using it for database migrations with PostgreSQL.

So, here’s what I want to say today:

• Written by SQLAlchemy wiz Mike Bayer
• Here’s the tutorial. Socorro is now using alembic in production with SQLAlchemy 0.6.x. I’m hoping to get us upgraded to 0.8.x soon.
• Here’s what running an upgrade in production for Socorro looks like. Awesome right?
• Here’s what a migration looks like.
• Here’s a configuration file.
• Generating a migration from the command line might look something like:
  alembic revision -m "bug XXXXXX Add a new table" --autogenerate

The most difficult thing to deal with so far are the many User Defined Functions that we use in Socorro. This isn’t something that any migration tools I tested deal well with.

Happy to answer questions! And I’ll see about making a longer talk about this transition soon.

cross-posted from the Webmaker blog

We use Bugzilla to work open and get stuff done

Webmaker, like many Mozilla projects, uses an issue tracker called Bugzilla for filing tickets and getting stuff done. These two new pages provide tips and tricks for filing bugs, and for getting the most out of Bugzilla:

1. Bugzilla for Webmaker — the best place to start. How to file a Webmaker bug, plus simple tweaks for making Bugzilla easier to use.
2. Bugzilla for Webmaker: PRO TIPS – for digging deeper. How to make it easier for users to file tickets, tagging, searching and tracking bugs, Frequently Asked Questions and more.

Anyone can create, comment or contribute to a ticket

We work open. Webmaker is an open source, non-profit project powered by a global community of friendly humans like you. Anyone can create a ticket, comment on a ticket, and contribute. Just because it’s called a “bug” doesn’t necessarily mean there’s something wrong. It could just be a to-do, or a suggestion. All your tickets are welcome — don’t worry if you’re doing it right. We’re a friendly community, and we want your ideas!