Mozilla Nederland LogoDe Nederlandse

Mozilla Reps Community: Reps Weekly Call – July 16th 2015

Mozilla planet - vr, 17/07/2015 - 14:04

Last Thursday we had our weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.


  • Webmaker tools.
  • Featured events.
  • What’s Council up to this week?
  • Whistler Recap take two.
AirMozilla video

Detailed notes

Shoutouts to the Uganda Community, all Moslem Mozillians and Nuke.

Webmaker tools

Bobby (@secretrobotron) joined that call to remind that there are plans to take down Appmaker & Popcorn Maker, but simply “move” Thimble & Goggles. Don’t expect these to be accessible after August 31st.

They are building a way to users to access their old makes — they will all be stored indefinitely.

Read and share the old blog post if you haven’t already.

Reach out to Bobby if you have more questions.

Featured events
  • MozFest East Africa (17th to 19th). Kampala, Uganda.
  • Hack in India (18th, 19th). Bangalore, India.
  • OSCON (21st, 24th). Portland, USA.
  • Campus Party Mexico (22nd to 26th). Zapopan, Mexico
  • Campus Party Recife (22nd to 26th). Olinda, Brazil.

Don’t forget to add your event to Discourse, and share some photos, so it can be shared on Reps Twitter account.

What’s up with Council this week?

These are some of the initiatives Council is working this week:

  • Brainstorm about recognition.
  • RoTM June blog post in the works.
  • Mentor selection process 2.0 (shared on reps-general)
  • Blog post about Reps work at Whistler Work Week.
Whistler Recap take two

We have some videos and articles about this Work Week that we recommend to check.

More blog posts about Whistler:

Raw etherpad notes.

Don’t forget to comment about this call on Discourse and we hope to see you next week!

Categorieën: Mozilla-nl planet

Gregory Szorc: Prompting to Run mach mercurial-setup

Mozilla planet - vr, 17/07/2015 - 13:35

Earlier this week, I landed some changes to the Firefox development environment that aggressively make mach prompt to run mach mercurial-setup. Full details in bug 1182677.

As expected, the change resulted in a fair amount of whining and bemoaning among various Firefox developers. I wanted to take some time to explain why we moved forward, even though we knew not everyone would like the feature.

My official job title at Mozilla is Developer Productivity Engineer. My job is to make you do your job better.

I've been an employee at Mozilla for four years and in that time I've witnessed a surprising lack of understanding around version control tools. (I don't think Mozilla is significantly different from most other companies here.) I find that a significant number of people are practicing sub-optimal version control workflows because they don't know any better (common) or because they are unwilling to change from learned habits.

Furthermore, Mercurial is a highly customizable tool. A lot of Mozillians have spent a lot of time developing useful extensions to Mercurial that enable Mozillians to use Mercurial more effectively and to thus become more productive. The latest epic time-saving hack is Nick Alexander's work to make Fennec build 80% faster by having deep integration with version control.

mach mercurial-setup is almost two years old. Yet, when assisting my fellow Mozillians with Mercurial issues, my "have you run mach mercurial-setup?" question is still often met with blank stares followed by "wait, there's a mach mercurial-setup?!" What's even more frustrating is people wrongly believing that Mercurial can't do things like rebasing and then spreading misinformation about the lackings of Mercurial. (Mercurial has many advanced features disabled out of the box so new users don't footgun themselves.)

Just like Firefox would be irrelevant if it didn't have millions of users, your awesome tool is mostly irrelevant if you are its only user. That's why when I hear of someone say they created an amazing tool for themselves or modified a third party tool without sending the improvements upstream, my blood pressure rises a little. It rises because here this person did something awesome and they or some limited subset of people who happened to be following the person on Twitter or reading their blog at that point in time managed to a) know about the tool b) take the effort to install it. The uptake rate is insanely low and return on investment for that tool is low. It results in duplication of effort. I find this painfully frustrating because I want everyone to have easy access to the best tools available. This requires that tools are well advertised and easy to install and use.

The primary goal of mach mercurial-setup is to make it super easy for anyone to have an optimal Mercurial experience. It was apparent to me that despite mach mercurial-setup existing, numerous people didn't know it existed or weren't using it. Your awesome tool isn't very awesome unless people are using it. And a lot of the awesome tools people have built around Mercurial at Mozilla weren't being utilized and lots of productivity wins were thus being unrealized. Forcefully pushing mach mercurial-setup onto people is thus an attempt to unlock unrealized productivity wins and to make people happier about the state of their tools.

I'm not thrilled that mach's prompting to run mach mercurial-setup is as disruptive as it is. It's bad user experience. I know better. But, (and this is explained somewhat in the bug), other solutions are more complicated and have other gotchas. The current, invasive implementation was the easiest to implement and has the biggest bang for the buck in terms of adoption. We knew people would complain about it. But from my perspective, it was do this or do nothing. And nothing hadn't been very effective. So we did something.

There has been lots of feedback about the change this week. Most surprising to me is the general sentiment of "I don't want something automatically changing my hgrc file." I find this surprising because mach mercurial-setup puts the user firmly in control by prompting before doing anything, thus respecting user choice and avoiding gotchas and unwanted changes. It's clear this property needs to be advertised a bit more so people aren't scared to run mach mercurial-setup and don't spread fear, uncertainty, and doubt about the tool to others. (I also find it somewhat surprising people would think this in the first place: I'd like to think we'd implicitly trust most Mozillians to implement tools that respect user choice and don't do malicious things.)

Like all software, things can and will change. The user experience of this new feature isn't terrific. We'll iterate on it. If you want to help enact change, please file a bug in Core :: mach (for now) and we'll go from there.

Thank you for your patience and your understanding.

Categorieën: Mozilla-nl planet

Zero Day Weekly: Mozilla smash Flash, FireEye's pain, US identity theft bill ... - ZDNet

Nieuws verzameld via Google - vr, 17/07/2015 - 13:23


Zero Day Weekly: Mozilla smash Flash, FireEye's pain, US identity theft bill ...
Mozilla's support team has made the decision to block all versions of Flash Player from Firefox until Adobe releases a patch. The block, announced by head of Firefox support Mark Schmidt, comes in response to the recent discovery of two critical zero ...

Categorieën: Mozilla-nl planet

Adam Lofting: Working on CRM

Mozilla planet - vr, 17/07/2015 - 13:17

I’m writing a couple of blog posts today. This first is a belated note about my work on CRM for MoFo, and how I ended up doing this.

Slides from my presentation to MoFo on our All Staff call in June.

In the second quarter of the year, my Metrics work was pretty quiet while we were prototyping the new Webmaker Android App, and the Learning Networks team was in planning mode for Mozilla Clubs. There was some strategic work to do, but at this stage in the product life-cycle, data-driven decision making isn’t a useful tool. I never actually ran out of things to do, but was keen to spend my time on things that had the most impact.

So I was looking around for projects to help with. Talking to David Ascher, I explained that the projects that engaged me most were the complex ones that combined the needs and views of many different teams. This was also a moment of realisation for me that this was true of every job I’ve held. I like connecting things, including differing points of view.

The MoFo CRM project has been on the table(s) for a while now, but it never gained momentum for legitimate organisational reasons. All our teams needed some form of CRM, but even those with the biggest requirements didn’t have spare capacity to supply CRM tools to the rest of the teams. The more a team tried to coordinate with others, the more complex it was to solve for their own use case. It was everyone’s problem, and no-one’s problem.

So my proposal was to have a ‘product manager’ to look after CRM as an internal service to the org; Centralise ownership of the complexity rather than making it everyone’s problem. That way teams can think about the benefits of using the CRM rather than the complexity of building it. And after reviewing the plan with our Ops leadership, I picked up this task.

It’s been a couple of month’s since then, and I’ve had hundreds of hours of conversations with people across Mozilla about CRM. The project is living up to my request of ‘complex’, but I’m also pleased we’ve started doing the work. Although CRM includes more than it’s fair share of ‘Enterprise IT’, we’re keeping our workflow inline with the agile methods we apply to our own products and projects.

But it’s a difficult project to track, with many plates that need to keep spinning. I noticed this most after being offline with my family for two weeks then coming back to work. It took me a few days to get up to speed on each of the CRM pieces. So this week I’ve been working on documentation that’s easier to follow.

The project is now split into seven projects, and the current status of each, and the next steps with links to github issues for tracking and discussion can now all be found in one place. Building on Matt Thomson’s hard work organizing many Mozilla things, I’m using this wiki/etherpad combo as my working doc: CRM Plan of Record.

Categorieën: Mozilla-nl planet

Emily Dunham: Outage postmortem: Replacing Rust Buildbot's outdated cert

Mozilla planet - vr, 17/07/2015 - 09:00
Outage postmortem: Replacing Rust Buildbot’s outdated cert

At the end of the day on July 14th, 2015, the certificate that Rust’s buildbot slaves were using to communicate with the buildmaster expired. This broke things. The problem started at midnight on July 15th, and was only fully resolved at the end of July 16th. Much of the reason for this outage’s duration was that I was learning about Buildbot as I went along.

Here’s how the outage got resolved, just in case anyone (especially future-me) finds themself Googling a similar problem.


Categorieën: Mozilla-nl planet

Mozilla Firefox OS R&D team in Taiwan loses staff - DigiTimes - Digitimes

Nieuws verzameld via Google - vr, 17/07/2015 - 06:41

Mozilla Firefox OS R&D team in Taiwan loses staff - DigiTimes
Mozilla COO and Taiwan general manager Gon Li have resigned and set up a new company and recruited about 30 engineers from the Mozilla Firefox OS R&D team in Taiwan, almost suspending the R&D operation, according to industry sources.

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla y Facebook le declaran la guerra a Adobe Flash - Diario El Siglo

Nieuws verzameld via Google - vr, 17/07/2015 - 02:38

Termómetro en linea

Mozilla y Facebook le declaran la guerra a Adobe Flash
Diario El Siglo
Hubo un tiempo en el que uno de los programas más famosos de animación de la historia de la informática era indispensable. Pasó de Macromedia a Adobe hace justo diez años pero sus problemas derivados de ataques y vulnerabilidades ha puesto en ...
Flash regresa a Mozilla FirefoxTermómetro en linea
Mozilla Bloqueó a Adobe FlashEl Diario 24
Adobe Flash regresa a Mozilla Firefox tras el 'destierro'Noticias
alle 39 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Bobby Holley: Must be This Tall to Write Multi-Threaded Code

Mozilla planet - vr, 17/07/2015 - 02:00

David Baron put this up in Mozilla’s San Francisco office a while back:

Must be This Tall to Write Multi-threaded Code

This is cute way of saying that writing safe concurrent code is, at present, rocket science. This is unfortunate, because the future of computing is shaping up to be all about concurrency. Fundamental engineering constraints like power usage are steering microprocessor manufacturers away from single-core architectures. If the fastest chips have N cores, a mostly-single-threaded program can only harness (1/N)th of the available resources. As N grows (and it is growing), parallel programs will win.

We want to win, but we’ll never get there if it’s rocket science (despite the industry-leading density of rocket scientists hacking on Gecko). Buggy multi-threaded code creates race conditions, which are the most dangerous and time-consuming class of bugs in software. And while we have some new superpowers to help us react when they inevitably occur, debugging racey code is still incredibly costly. To succeed, we need to prevent races from happening in the first place.

Why do races occur? Opinions differ, but I argue the following:

Races are endemic to most large software projects because the traditional synchronization primitives are inadequate for large-scale systems.

Let me explain.

Small-scale systems are easy to build and maintain. So long as the details can all fit in the heads of a small number of programmers, it’s relatively easy to shuffle things around to meet requirements and verify that all the pieces interact properly.

Large-scale systems are a different story. Many cooks in many interdependent kitchens necessitate strong, assertable rules that allow programmers to reason about the unknowable. These rules provide a baseline level of order, but to be truly useful, they need to be predictable: different programmers should be able to invent similar or identical rules by deriving them from a small set of core principles, such that everyone can make reasonable predictions about the high-level behavior of code they haven’t read.

Software engineering at this level is an art, whose core mission is to find the right abstraction - one that naturally offers guidance and solutions for the problems that need to be solved (especially the ones that don’t exist yet). The wrong abstraction is painful and error-prone. The right one is a never ending stream of goodness from which all answers flow.

Locks don’t lend themselves to these sorts of elegant principles. The programmer needs to scope the lock just right so as to protect the data from races, while simultaneously avoiding (a) the deadlocks that arise from overlapping locks and (b) the erasure of parallelism that arise from megalocks. The resulting invariants end up being documented in comments:

// These variables are protected by monitor X: ... // These variables are only accessed on thread Y: ...

And so on. When that code is undergoing frequent changes by multiple people, the chances of it being correct and the comments being up to date are slim.

There’s a familiar story that has repeated itself many times throughout Gecko’s history:

  1. Engineering leadership sees benefits to accessing some component on multiple threads, and kicks off an effort to make it thread-safe.
  2. The component becomes incredibly complex and difficult to maintain. Quality suffers, engineers avoid touching it, and improvements slow to a trickle.
  3. The component is now plagued with problems. The owner comes up with an elegant new design that solves most of the problems, but needs to forbid multi-threaded access to make it work. This is deemed a good trade-off by everyone, and the component becomes non-thread-safe once again.

At first glance, this constant retreat from thread-safety by seasoned programmers looks pretty grim for a multi-core future. However, these programmers aren’t fleeing concurrency itself - they’re fleeing concurrent access to the same data. That is to say, safe and scalable parallelism is achievable by minimizing or eliminating concurrent access to shared mutable state.

In this approach, threads own their data, and communicate with message-passing. This is easier said than done, because the language constructs, primitives, and design patterns for building system software this way are still in their infancy. Rust is designed from the ground up to facilitate this, and uses its type system to enforce single ownership of data. We’re already using some Rust in Gecko, but we’re not going to be rid of C++ anytime soon. So it’s critical to explore ways to incrementally add safe concurrency in C++.

During the first half of this year, I did a tour of duty with the Multimedia Playback Team to help rebuild the heavily-threaded decoding and playback pipeline to be less racey. To solve the problems I encountered there, I built some new tools and primitives that ended up being game-changers in our ability to easy write easy and correct concurrent code.

More on that next time.

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: Decisive moment for net neutrality in Europe

Mozilla planet - vr, 17/07/2015 - 01:54


Yesterday, the European Union moved one step closer to enacting real net neutrality across the continent. The European Parliament’s Industry, Research, and Energy Committee (ITRE) approved an agreement on the Telecom Single Market Regulation (TSM), after drawn out negotiations between the three EU policymaking branches: the Parliament, the Council, and the Commission. This draft legislation includes proposed rules specifying that all traffic must be treated equally as well as rules prohibiting paid prioritization and blocking.

The ITRE Committee will vote in the fall to formally adopt the text and it will then move to the full Parliament plenary for a final vote. However, amendments can be offered before both the ITRE vote and the plenary vote, and the European Council (the body representing EU member states) must also ratify the final text before it becomes law.

While the current rules are ambiguous in places and give significant deference to national regulatory authorities, overall this is a significant step to protect the open Internet in Europe. We urge European policymakers to finish strong and enact clear, enforceable rules against blocking, discrimination, and fast lanes.


After years of negotiations, the E.U. Telecom Single Market Regulation (which includes proposed net neutrality rules) is nearing completion. If passed, the Regulation will be binding on all E.U. member states. The policymakers – the three European governmental bodies:  the Parliament, the Commission, and the Council – are at a crossroads: implement real net neutrality into law, or permit net discrimination and in doing so threaten innovation and competition. We urge European policymakers to stand strong, adopt clear rules to protect the open Internet, and set an example for the world.

At Mozilla, we’ve taken a strong stance for real net neutrality, because it is central to our mission and to the openness of the Internet. Just as we have supported action in the United States and in India, we support the adoption of net neutrality rules in Europe. Net neutrality fundamentally protects competition and innovation, to the benefit of both European Internet users and businesses. We want an Internet where everyone can create, participate, and innovate online, all of which is at risk if discriminatory practices are condoned by law or through regulatory indifference.

The final text of European legislation is still being written, and the details are still gaining shape. We have called for strong, enforceable rules against blocking, discrimination, and fast lanes are critical to protecting the openness of the Internet. To accomplish this, the European Parliament needs to hold firm to its five votes in the last five years for real net neutrality. Members of the European Parliament must resist internal and external pressures to build in loopholes that would threaten those rules.

Two issues stand out as particularly important in this final round of negotiations: specialized services and zero-rating. On the former, specialized services – or “services other than Internet access services” – represent a complex and unresolved set of market practices, including very few current ones and many speculative future possibilities. While there is certainly potential for real value in these services, absent any safeguards, such services risk undermining the open Internet. It’s important to maintain a baseline of robust access, and prevent relegating the open Internet to a second tier of quality.

Second, earlier statements from the E.U. included language that appeared to endorse zero-rating business practices. Our view is that zero-rating as currently implemented in the market is not the right path forward for the open Internet. However, we do not believe it is necessary to address this issue in the context of the Telecom Single Market Regulation. As such, we’re glad to see such language removed from more recent drafts and we encourage European policymakers to leave it out of the final text.

The final text that emerges from the European process will set a standard not only for Europe but for the rest of the world. It’s critical for European policymakers to stand with the Internet and get it right.

Chris Riley, Head of Public Policy
Jochai Ben-Avie, Internet Policy Manager

Categorieën: Mozilla-nl planet

David Rajchenbach Teller: What have I done since last July?

Mozilla planet - vr, 17/07/2015 - 00:38

School year 2014-2015 is ending. It’s time for a brief report.

Session Restore

As I announced last year, I am mostly inactive on Session Restore these days. However, I am quite happy to have landed « Bug 883609 – Make Backups Useful ». This has considerably improved the resilience of Session Restore against a variety of accidents.

Besides this, I have mostly been reviewing and mentoring a few contributors.

For Q3, I will try to help Allasso (one of our contributors) land bug 906076, which we hope can improve a lot the startup speed for users with many tabs or tab groups.

Performance Monitoring

My biggest code contribution for the past 6 months is Performance Monitoring. Firefox Nightly now has a module (PerformanceStats.jsm/nsIPerformanceStats) dedicated to monitoring the performance of Firefox, webpages and add-ons in real-time. While there are a number of improvements I wish to land, this is already powerful enough to implement about:performance (a top-like utility for Firefox), the slow add-on watcher (which has progressively grown into something actually useful), and slow add-on Telemetry.

I am currently working on making measures faster and decreasing even further the number of false alerts, as well as ensuring that everything works nicely with e10s. Oh, and I have a new UX design for about:performance which I hope you will like.

Also, I have passed on the data to the AMO team so that they can start publishing the performance of add-ons to their authors.

Async Tooling

I have been less active on Async Tooling recently, in large part because most of the tooling we needed has landed, and the rest is now in the hands of the DevTools team. My main contribution has been DOM Promise Uncaught Error monitoring, which was both one of the blockers to port our code from Promise.jsm to DOM Promise, and a primitive necessary for the DevTools team.

My second contribution was modifying our (then) reference implementation of Promise, all our test suites and quite a number of individual tests to handle the case of uncaught asynchronous errors. I have had relatively little feedback on this, but this serves me almost for every single patch I write.

Other than that, I have landed the PromiseWorker, which is designed to make using ChromeWorkers simpler, and I have both landed and mentored a number of improvements to Sqlite.jsm, in particular error-reporting and clean async shutdown, as well as maintenance fixes to OS.File.

I do not have specific plans for the near future of Async Tooling.


One year ago, I joined the effort to overhaul Places, our implementation of bookmarks, history, keywords, etc. Unfortunately, this effort is far from over, as all the participants (starting with my reviewer) keep being preempted for higher-priority work. However, we did manage to land a number of improvements. I contributed History.jsm, a (not complete yet) reimplementation of the History API, with a nicer API and off the main thread database access.

I also refactored Places to handle asynchronous shutdown sequence.

In the near future, I plan to finish and land a non-blocking reimplementation of the Forget button (and Sanitize dialog). I do not have other short-term plans for Places.


Shutdown has kept me quite busy this past 12 months. On one side, AsyncShutdown has been improved, made easier to use and debug post-mortem, and extended to support async shutdown of C++-based features. On another side, I have implemented a Dashboard to track AsyncShutdown timeouts and trends, which has saved my life a few times – in particular, when I fixed the crashes caused by Avast, and when I helped pinpoint and fix the topcrashers for Firefox 33.

Also, I landed the Shutdown Terminator, which turns shutdown hangs into actionable crashes, and also lets us track the duration of successful shutdowns (hint: if it takes more than 10 seconds, you’re as good as crashed).

I do not have short-term plans for Shutdown, although if I find time, I might try and make it crash a bit faster.


Community also ate plenty of my time. My main involvement was mentoring a number of bugs (I lost track of the number, probably a 10-20) and welcoming new potential contributors both on #introduction and through the contribute form. As a note, while mentoring is almost always a pleasure, welcoming new contributors is a huge time sink with very little return on effort. More on this in another blog post.

I also dedicated time and effort to Teaching Open-Source to University students, with mixed results. Students who had signed up by themselves gave me great feedback, while students who had been assigned to the course without having any choice did not prove as pleasant to work with. While I hope to reproduce the experience eventually, this will not be with the same University.

The French Firefox OS launch, going to present (and actually sell) the first Firefox OS phones to entirely non-technical crowds, was also an interesting experience. I don’t know if it was useful in the end, but it was certainly fun.

Finally, while I haven’t found a good place to mention it, this year will be remembered also for Je Suis Charlie, both the initial terrorist attacks and the entirely predictable law on mass surveillance that just passed in France.

In the near future, I plan to continue mentoring bugs, but I will be less active on the contribute form – rather, I am lending a hand to the Participation team’s effort to replace the contribute form with something much better.

Categorieën: Mozilla-nl planet

Ben Kero: Goodbye Mozilla

Mozilla planet - vr, 17/07/2015 - 00:23

It is with a heavy heart that I’m announcing the resignation of my position at Mozilla. Last month marked my 5th year here, and over that time I’ve met some of the most intelligent and driven people in the world. I’m proud to have known you and worked alongside you these years.

I am leaving my responsibilities in the capable hands of my teammates. Although I will no longer be here, the work will still get done.

I’d like to thank all of you who helped me along the way. In particular, the release engineering team for introducing me to the reality of operations at an impressive scale. I’d also like to thank IT for teaching me how large of a scope an org can have, and for civilizing this operations cowboy. I also owe a great appreciation and shout-out to my teammates in Developer Services (especially fubar and hwine) who have had my back through some rough outages.

Lastly, I’d like to thank my managers for giving me direction and always keeping me on course:

Justin Fitzhugh
Matthew Zeier
Phong Tran
Corey Shields
Shyam Mani
Jake Maul
Laura Thomson
Lawrence Mandel

Post-Mozilla I’ll be moving on to other software development and operations work. Since free software is one of my passions you’ll certainly see me around. If you’re curious as to what I’m up to next feel free to send me a private message.

Feel free to reach out to me on IRC, Facebook, Twitter, or in meatspace. If you see me at a conference, don’t hesitate to come say hello. My personal email address is

My last day will be Friday (2015-07-17).

Thank you,

Ben Kero
Senior Systems Administrator, Developer Services

Categorieën: Mozilla-nl planet

Air Mozilla: Making the Web More Private (Maybe)

Mozilla planet - do, 16/07/2015 - 23:00

Making the Web More Private (Maybe) Making the web more private (maybe) -- from refer(r)er policies Franziskus Kiefer Introduces referrer attributes for navigation and embedding elements that allow fine grained control...

Categorieën: Mozilla-nl planet

Air Mozilla: Migrations Don't Suck!

Mozilla planet - do, 16/07/2015 - 23:00

Migrations Don't Suck! Anhad Jai Singh talks about why migrations don't suck if done properly, how to do them, and what you gain from them.

Categorieën: Mozilla-nl planet

Air Mozilla: Intern Presentations

Mozilla planet - do, 16/07/2015 - 23:00

Intern Presentations 2 San Francisco interns will be presenting the projects they worked on this summer. Franziskus Kiefer Making the web more private (maybe) -- from refer(r)er...

Categorieën: Mozilla-nl planet

Air Mozilla: Making the Web More Private (Maybe)

Mozilla planet - do, 16/07/2015 - 23:00

Making the Web More Private (Maybe) Making the web more private (maybe) -- from refer(r)er policies Franziskus Kiefer Introduces referrer attributes for navigation and embedding elements that allow fine grained control...

Categorieën: Mozilla-nl planet

Air Mozilla: Migrations Don't Suck!

Mozilla planet - do, 16/07/2015 - 23:00

Migrations Don't Suck! Anhad Jai Singh talks about why migrations don't suck if done properly, how to do them, and what you gain from them.

Categorieën: Mozilla-nl planet

Thunder-faced Mozilla lifts Flash Firefox block after 0-days plugged - The Register

Nieuws verzameld via Google - do, 16/07/2015 - 22:30

The Register

Thunder-faced Mozilla lifts Flash Firefox block after 0-days plugged
The Register
Mozilla has lifted its blanket block on Flash in Firefox following the release of security updates by Adobe on Tuesday. Although the short-term block has been lifted, the whole flap appears to have re-energised efforts at Mozilla to work on Flash ...
Flash now too dangerous to run on Firefox, Mozilla saysSydney Morning Herald
Google and Mozilla pull the plug on Adobe FlashDaily Mail
Google and Mozilla Disable Flash Over Security ConcernsWall Street Journal (blog)
alle 562 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Air Mozilla: Permission to copy : GRANTED

Mozilla planet - do, 16/07/2015 - 22:30

 GRANTED Michael Layzell, a Mozilla intern working in Toronto talks about eradicating Flash from GitHub, preparing permissions for the future, and ensuring the correctness of our...

Categorieën: Mozilla-nl planet

Air Mozilla: Permission to copy : GRANTED

Mozilla planet - do, 16/07/2015 - 22:30

 GRANTED Michael Layzell a Mozilla intern working in Toronto talks about eradicating Flash from GitHub, preparing permissions for the future, and ensuring the correctness of our...

Categorieën: Mozilla-nl planet

Flash regresa a Mozilla Firefox - Tecnología - - CNNExpansió

Nieuws verzameld via Google - do, 16/07/2015 - 22:00

Yahoo Finanzas España

Flash regresa a Mozilla Firefox - Tecnología -
Mozilla vetó a Flash luego de que se descubrieran dos vulnerabilidades críticas en el código del complemento. Los agujeros en el software Flash podían permitir que alguien controlara tu computadora de forma remota y la infectara con malware.
Google, Mozilla y Facebook dan la razón a Steve Jobs y piden la muerte de ...Yahoo Finanzas España
Mozilla Firefox y Facebook se unen a la guerra contra Flash - WebAdictosWebAdictos

alle 22 nieuwsartikelen »
Categorieën: Mozilla-nl planet