Mozilla Nederland LogoDe Nederlandse

Tor Project ontvangt 460.000 dollar aan donaties -

Nieuws verzameld via Google - za, 12/01/2019 - 13:03
Tor Project ontvangt 460.000 dollar aan donaties

Het Tor Project, verantwoordelijk voor het Tor-netwerk, heeft vorig jaar meer dan 460.000 dollar aan donaties van privépersonen ontvangen, waarvan de helft ...

Categorieën: Mozilla-nl planet

Software-update: Mozilla Firefox 64.0.2 - Computer - Downloads - Tweakers

Nieuws verzameld via Google - do, 10/01/2019 - 09:07
Software-update: Mozilla Firefox 64.0.2 - Computer - Downloads  Tweakers

Mozilla heeft een update voor versie 64 van zijn webbrowser Firefox uitgebracht, de zevende versie gebaseerd op Firefox Quantum. De browser heeft met ...

Categorieën: Mozilla-nl planet

Eric Rescorla Wins the Levchin Prize at the 2019 Real-World Crypto Conference

Mozilla Blog - wo, 09/01/2019 - 21:00

The Levchin Prize awards two entrepreneurs every year for significant contributions to solving global, real-world cryptography issues that make the internet safer at scale. This year, we’re proud to announce that our very own Firefox CTO, Eric Rescorla, was awarded one of these prizes for his involvement in spearheading the latest version of Transport Layer Security (TLS). TLS 1.3 incorporates significant improvements in both security and speed, and was completed in August and already secures 10% of sites.

Eric has contributed extensively to many of the core security protocols used in the internet, including TLS, DTLS, WebRTC, ACME, and the in development IETF QUIC protocol.  Most recently, he was editor of TLS 1.3, which already secures 10% of websites despite having been finished for less than six months. He also co-founded Let’s Encrypt, a free and automated certificate authority that now issues more than a million certificates a day, in order to remove barriers to online encryption and helped HTTPS grow from around 30% of the web to around 75%. Previously, he served on the California Secretary of State’s Top To Bottom Review where he was part of a team that found severe vulnerabilities in multiple electronic voting devices.

The 2019 winners were selected by the Real-World Cryptography conference steering committee, which includes professors from Stanford University, University of Edinburgh, Microsoft Research, Royal Holloway University of London, Cornell Tech, University of Florida, University of Bristol, and NEC Research.

This prize was announced on January 9th at the 2019 Real-World Crypto Conference in San Jose, California. The conference brings together cryptography researchers and developers who are implementing cryptography on the internet, the cloud and embedded devices from around the world. The conference is organized by the International Association of Cryptologic Research (IACR) to strengthen and advance the conversation between these two communities.

For more information about the Levchin Prize visit

The post Eric Rescorla Wins the Levchin Prize at the 2019 Real-World Crypto Conference appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

CES 2019: HTC Vive met Mozilla en AWS in VR-webbrowser - Emerce

Nieuws verzameld via Google - wo, 09/01/2019 - 14:08
CES 2019: HTC Vive met Mozilla en AWS in VR-webbrowser  Emerce

HTC VIVE heeft op de Consumer Electronics Show (CES) een samenwerking aangekondigd met Mozillas Firefox, AWS Amazon Sumerian en Fidelity ...

Categorieën: Mozilla-nl planet

Mozilla Announces Deal to Bring Firefox Reality to HTC VIVE Devices

Mozilla Blog - di, 08/01/2019 - 14:57

Last year, Mozilla set out to build a best-in-class browser that was made specifically for immersive browsing. The result was Firefox Reality, a browser designed from the ground up to work on virtual reality headsets. To kick off 2019, we are happy to announce that we are partnering with HTC VIVE to power immersive web experiences across Vive’s portfolio of devices.

What does this mean? It means that Vive users will enjoy all of the benefits of Firefox Reality (such as its speed, power, and privacy features) every time they open the Vive internet browser. We are also excited to bring our feed of immersive web experiences to every Vive user. There are so many amazing creators out there, and we are continually impressed by what they are building.

“This year, Vive has set out to bring everyday computing tasks into VR for the first time,” said Michael Almeraris, Vice President, HTC Vive. “Through our exciting and innovative collaboration with Mozilla, we’re closing the gap in XR computing, empowering Vive users to get more content in their headset, while enabling developers to quickly create content for consumers.”

Virtual reality is one example of how web browsing is evolving beyond our desktop and mobile screens. Here at Mozilla, we are working hard to ensure these new platforms can deliver browsing experiences that provide users with the level of privacy, ease-of-use, and control that they have come to expect from Firefox.

In the few months since we released Firefox Reality, we have already released several new features and improvements based on the feedback we’ve received from our users and content creators. In 2019, you will see us continue to prove our commitment to this product and our users with every update we provide.

Stay tuned to our mixed reality blog and twitter account for more details. In the meantime, you can check out all of the announcements from HTC Vive here.

If you have an all-in-one VR device running Vive Wave, you can search for “Firefox Reality” in the Viveport store to try it out right now.

The post Mozilla Announces Deal to Bring Firefox Reality to HTC VIVE Devices appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mozilla wil in 2019 verbeterde versie Thunderbird uitbrengen -

Nieuws verzameld via Google - vr, 04/01/2019 - 09:00
Mozilla wil in 2019 verbeterde versie Thunderbird uitbrengen

Mozilla zal dit jaar nog met een nieuwe versie van zijn open source e-maildienst Thunderbird komen. Niet alleen biedt die straks betere ondersteuning voor.

Categorieën: Mozilla-nl planet

MOSS 2018 Year in Review

Mozilla Blog - do, 03/01/2019 - 21:27

Mozilla was born out of, and remains a part of, the open-source and free software movement. Through the Mozilla Open Source Support (MOSS) program, we recognize, celebrate, and support open source projects that contribute to our work and to the health of the internet.

2018 was a year of change and growth for the MOSS program. We worked to streamline the application process, undertook efforts to increase the diversity and inclusion of the program, and processed a record number of MOSS applications. The results? In total, MOSS provided over $970,000 in funding to over 40 open-source projects over the course of 2018. For the first time since the beginning of the program, we also received the majority of our applications from outside of the United States.

2018 highlights

While all MOSS projects advance the values of the Mozilla Manifesto, we’ve selected a few that stood out to us this year:

    • Secure Drop — $250,000 USD
      • SecureDrop is an open-source whistleblower submission system that media organizations can install to securely accept documents from anonymous sources. It was originally built by the late Aaron Swartz and is used by newsrooms all over the world, including those at The Guardian and the Associated Press. In 2018, MOSS gave its second award to Secure Drop; to date, the MOSS program has supported Secure Drop with $500,000 USD in funding.
    • The Tor Project — $150,000 USD
      • Tor is free software and an open network that helps defend against traffic analysis, a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security. In 2018, MOSS gave its second award to help modularize key aspects of the Tor codebase; to date, the MOSS program has supported this work with $300,000 USD in funding.
    • The Processing Foundation — $69,700 USD
      • The Processing Foundation maintains p5.js, an open-source JavaScript framework that makes creating visual media with code on the web accessible to anyone, especially those without traditional computer science backgrounds. p5.js enables users to quickly prototype interactive applications, data visualizations, and narrative experiences, and share them easily on the web.
    • Dat Project — $34,000 USD
      • Dat is a nonprofit-backed data sharing protocol for applications of the future. With software built for researchers and data management, Dat empowers people with decentralized data tools. MOSS provided $34,000 USD in funding to Dat for community-building, documentation, and tooling.
Seed Awards

With an eye toward broadening participation in the MOSS program and reaching new audiences, the MOSS team decided to try something new at this year’s Mozilla Festival in London: we invited Festival attendees who work on open-source projects to join us for an event we called “MOSS Speed Dating.” For the event, we established a special MOSS committee, comprised of existing committee members, Mozilla staff, and leaders in the open-source world. Attendees were invited to “pitch” their project to three different committee members for 10 minutes each. Following the event, the committee met to discuss which projects best exemplified the qualities we look for in all MOSS projects (openness, impact, alignment with the Mozilla mission) and provided each of the most promising projects with a $5,000 seed grant to help support future development. While many of these projects are less mature than the projects we’d support with a larger, traditional MOSS award, we hope that these seed awards will assist them in growing their codebases and communities.

The 14 projects that the committee selected were:

Looking forward to 2019

In 2019, we hope to double down on our efforts to widen the applicant pool for MOSS and support a record number of projects from a diverse set of maintainers around the globe. Do you know of an open-source project in need of support whose work advances Mozilla’s mission? Please encourage them to apply for a MOSS award!

The post MOSS 2018 Year in Review appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Firefox-advertentie was onderdeel van een experiment van Mozilla -

Nieuws verzameld via Google - wo, 02/01/2019 - 09:00
Firefox-advertentie was onderdeel van een experiment van Mozilla

Eind vorig jaar meldden diverse gebruikers van browser Firefox dat ze in de desktopversie advertenties te zien kregen. Nu blijkt dat het om een experiment.

Categorieën: Mozilla-nl planet

Mozilla blaast lab nieuw leven in - Emerce

Nieuws verzameld via Google - ma, 31/12/2018 - 09:00
Mozilla blaast lab nieuw leven in  Emerce

Firefox-ontwikkelaar Mozilla heeft zijn programma Mozilla Labs nieuw leven ingeblazen, en daarbij gaat het niet langer alleen om toepassingen voor de ...

Categorieën: Mozilla-nl planet

Software-update: Mozilla Thunderbird 60.4.0 - Computer - Downloads - Tweakers

Nieuws verzameld via Google - ma, 31/12/2018 - 09:00
Software-update: Mozilla Thunderbird 60.4.0 - Computer - Downloads  Tweakers

De Mozilla Foundation heeft kort geleden versie 60.4 van Thunderbird uitgebracht. Mozilla Thunderbird is een opensourceclient voor e-mail en nieuwsgroepen, ...

Categorieën: Mozilla-nl planet

Andy McKay: Car Tracking

Mozilla planet - za, 15/12/2018 - 09:00

This week I recieved and email from the Clean Energy Vehicle program. They'd like us to install a device in our Tesla that tracks us:

"By understanding when and where EVs charge to how much energy is consumed, you can help pave the way for future drivers by ensuring that the power system is ready for a plug-in future."

The program details are here.

"GPS information is collected, but not shared at the individual level. The data is collected and stored but no one outside of FleetCarma will see an individual’s location data."

Alright so who's FleetCarma? Let's look into the terms:

"Data Collected by the C2 Device and Privacy... drive start date and time, duration of trip, trip distance... GPS coordinates of the drive,"

"With the specific exclusion of GPS coordinates when driving, an anonymized subset of the data outlined above may be shared with the Province and BC Hydro and other third party suppliers"

"GPS coordinates during driving will not be shared with any Program partners or third party suppliers except in both anonymous and aggregate form to inhibit extraction of any individual driving behaviour."

Not sure who those Program partners or third party suppliers are but GeoTab uses some sub-processors.

FletCarma will share your information:

"To affiliated entities of CrossChasm Technologies Inc., including wholly owned subsidiaries" (Whomever that is)

"When we’re legally required to provide data, such as in response to a subpoena in a civil lawsuit."

It's nice to note.

"You may also request that your Personal Information be deleted. FleetCarma will promptly respond to your request within 30 days"

At this point I can surmise that:

  • FleetCarma will know all the trips I make in the car.

  • FleetCarma be subpoenad to give up that information.

  • FleetCarma can be hacked to give up all that information.

Normally this would be a simple, hell no. But I care greatly about electric cars and the infrastructure and this has put me in a bind. The privacy problem here is one that I simply can't get around.

Categorieën: Mozilla-nl planet

Nick Cameron: What to do in Christchurch

Mozilla planet - za, 15/12/2018 - 05:17

LCA 2018 is happening in January in Christchurch (which is a great conference and has a few Rust talks this year). I'm not able to attend, but I am in town, so I hope to meet some of my internet friends (get in touch!).

I thought I'd write down a few things to do in Christchurch for those who are new to the city. Don't get your hopes up for lots of tourist fun though (unless you have time to see some of the surrounding country), it is not the most interesting city, even less so since half of it was flattened in an earthquake. For more ideas, I like the Neat Places website.

Good places to drink coffee
  • C4
  • Coffee Embassy
  • the brunch places below
Good places to drink alcohol
  • The Volsted (near-ish the university)
  • 44 Welles Street
Good places to eat brunch
  • Hello Sunday
  • Unknown Chapter
  • Supreme Supreme (if they re-open in time - they're currently closed for refurbishment)
  • Addington Coffee Co
  • Caffeine Laboratory
  • Black Betty
  • Southside Social
Good places to eat dinner
  • Rangoon Ruby (Burmese)
  • Mumbaiwala (fancy Indian street food)
  • Birkenavala (cheap and delicious Indian)
  • Little High Eatery (hipster food court, lots of options)
  • Mexico (interesting but expensive Mexican food and lots of drinks)
  • Cassels (great pizza and great beer)
Best ice cream
  • Rollickin’ Gelato
Best place to swim
  • Jellie Park - 50m outdoor pool and 2x25m indoor pools. Also a decent gym which you can use without a membership.
Best place to run
  • Hagley Park
Best beach
  • Sumner - it has a good bit of sand plus some surfing and is a nice little beach village
Good places to go nearby
  • Castle Hill (On the way to Arthur's Pass, kind of magical, nature-sculpted boulders to work amongst)
  • Arthur's Pass national park (Mountains and forests, one of NZ's lesser visited NPs, but one of my favourite)
  • Akaroa (cute tourist town (and you can swim with dolphins), drive there the long way via Governor's Bay and enjoy food and views and chocolate at She cafe, as well as a nice drive. If you like cheese, stop at Barrys Bay)
Good things to see and do in town
  • Look at the ruins of the Cathedral and wonder the new city centre.
  • Riccarton House farmers market (Saturday Morning; lots of nice things to eat and drink)
  • Walk in the Port Hills
  • The Buskers Festival (Throughout January, lots of shows)
  • Go to the beach (see above)

Any questions, ping me on twitter - @nick_r_cameron.

Categorieën: Mozilla-nl planet

Cameron Kaiser: A thank you to Ginn Chen, whom Larry Ellison screwed

Mozilla planet - za, 15/12/2018 - 04:31
Periodically I refresh my machines by dusting them off and plugging them in and running them for a while to keep the disks spinnin' and the caps chargin'. Today was the day to refurbish my Sun Ultra-3, the only laptop Sun ever "made" (they actually rebadged the SPARCle and later the crotchburner 1.2GHz Tadpole Viper, which is the one I have). Since its last refresh the IDPROM had died, as they do when they run out of battery, resetting the MAC address to zeroes and erasing the license for the 802.11b which I never used anyway. But, after fixing the clock to prevent GNOME from puking on the abnormal date, it booted and I figured I'd update Firefox since it still had 38.4 on it. Ginn Chen, first at Sun and later at Oracle, regularly issued builds of Firefox which ran very nicely on SPARC Solaris 10. Near as I can determine, Oracle has never offered a build of any Firefox post-Rust even to the paying customers they're bleeding dry, but I figured I should be able to find the last ESR of 52 and install that. (Amusingly this relic can run a Firefox in some respects more current than TenFourFox, which is an evolved and patched Firefox 45.)

To my consternation, however, there was no contributed build for 52.9, the last 52ESR. I had to walk all the way back to 52.0.2 to find the last Solaris 10 package, which was accompanied by this sad message:

This directory contains Solaris builds of Firefox 52.0.2 ESR, which are contributed by Oracle Solaris Desktop Beijing Team. If you have any problem with these builds, please send email to ginnchen at gmail dot com

This is the last contrib build before I leave Oracle.
My job is eliminated.
Thanks everyone for supporting me.

I don't know if anyone ever said to Ginn how much all that work was appreciated. Well, I'm saying it now. I hope for much greener pastures away from scum like Larry, who ruined Sun, Solaris and SPARC just by being his scummy self, and lays off good folks just so he can buy another island. Here is Ginn's last build:

To this day, in Solaris 11, Firefox 52.9 is the last Firefox available, probably using Ginn's work.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: MDN Changelog for November 2018

Mozilla planet - vr, 14/12/2018 - 18:48
Done in November

Here’s what happened in November to the code, data, and tools that support MDN Web Docs:

Here’s the plan for December:

Shipped monthly MDN payments

In September we launched MDN payments, giving MDN fans a new way to help MDN grow. On November 20th, we added the ability to schedule monthly payments.

A screenshot of the monthly payment banner, with $8/month selected.

Monthly payment banner on MDN

Potato London started work on this shortly after one-time payments launched. We kicked it off with a design meeting where we determined the features that could be delivered in 4 weeks. Potato and MDN worked closely to remove blockers, review code (in over 25 pull requests), and get it into the staging environment for testing. Thanks to everyone’s hard work, we launched a high-quality feature on schedule.

We’ve learned a lot from these payment experiments, and we’ll continue to find ways to maintain MDN’s growth in 2019.

Converted from Font Awesome to SVG

On November 6th, we deployed Schalk Neethling’s PR 5058, completing the transition from the FontAwesome webfont to inline SVG icons. There are a few icon and style changes, but the site should look the same to most users.

Different styles of notice banners with icons from MDN, showing the old Font Awesome banners on the left and the new SVG banners on the right

Banners with indicators before the change (left) and after converting to SVG

We had several reasons for this change in April, when Schalk started the project. The biggest gains were expected to be in performance and a simpler design. Over the year, we became aware that many content blockers prevent loading web fonts, and many users couldn’t see UIs that depended on icons. For example, the browser compatibility tables were unusable on mobile with Firefox Focus. This change fixes this issue.

We haven’t seen a significant performance improvement, although there may have been small improvements as this switch was rolled out over the year. This month, we explored some more radical changes, such as minimal styling and disabled JS, by shipping manually edited copies of wiki pages. These experiments will help us determine the highest impact changes for front-end performance, and provide insight into what areas to explore next.

Added browser names to compatibility tables

The new SVG icons are being used in the browser compatibility table. In the wider desktop view, we’ve added rotated browser labels (Kuma PR 5117 and KumaScript PR 997), so it is clearer which browser is which. We also launched a survey to ask visitors about their needs for compatibility data (Kuma PR 5133).

A screenshot of a compatibility table with rotated text labels and topped with a survey

The compatibility table for display has gotten even taller

The compatibility data continues to be released as an NPM package, and now a tagged release is also created, including the statistics and notable changes from the last release (BCD PR 3158).

Welcome David Flanagan

David Flanagan joined the MDN development team in November. David is the author of JavaScript: The Definitive Guide and several other books. He is a former Mozilla employee, and recently worked at Khan Academy. His skills and passions are a great fit for MDN’s mission, and we look forward to his help as we modernize and expand our tech stack. Welcome David!

Shipped tweaks and fixes

There were 248 PRs merged in November:

This includes some important changes and fixes:

35 pull requests were from first-time contributors:

Planned for December Meet in Orlando

Twice a year, all of Mozilla comes together for an All-Hands meeting. This winter’s All-Hands is in Orlando, Florida. We were in Orlando in December 2015, when Florian was proposing moving KumaScript macros to GitHub and I was deploying the BrowserCompat API to beta users. A lot changes in three years!

Many of us at MDN will be taking well-deserved breaks after the All-Hands, and will come back refreshed for 2019. We hope you and yours have an enjoyable winter break!

The post MDN Changelog for November 2018 appeared first on Mozilla Hacks - the Web developer blog.

Categorieën: Mozilla-nl planet

K Lars Lohn: Things Gateway - a Virtual Weather Station

Mozilla planet - vr, 14/12/2018 - 18:37
Today, I'm going to talk about creating a Virtual Weather Station using the Things Gateway from Mozilla and a developer account from Weather Underground.  The two combined enable home automation control from weather events like temperature, wind, and precipitation.

I've already written the code and this blog is about how to use it.  In the next blog posting, I'll talk about how the code actually works.

Goal: create a virtual Web thing to get weather data into the Things Gateway for use in rules.  Specifically, make a rule that turns a green light on when the wind speed is high enough to fly a kite.

ItemWhat's it for?Where I got itan RPi running the Things GatewayIt's our target to have the weather station provide values to the Things GatewayGeneral Download & Install Instructions
or see my own install instructions:
General Install & Zigbee setup,
Philip Hue setup,
Z-Wave setup,
TP-Link setupA laptop or desktop PCthe machine to run the Virtual Weather Station. You can use the RPi itself.My examples will be for a Linux machinea couple things set up on the Things Gateway to controlthis could be bulbs or switches I'm using Aeotec Smart Switches to run red and green LED bulbs.the webthing and configman Python3 packagesthese are libraries used by the Virtual Weather Stationsee the pip install directions belowa clone of the pywot github repositoryit is where the the Virtual Weather Station code livessee the git clone directions belowa developer key for online weather datathis gives you the ability to download data from Weather Undergroundit's free from Weather Underground
Step 1: Download and install the configman and webthing Python 3 packages.  Clone the pywot github repository in a local directory appropriate for software development. While this can be done directly on the RPi, I'm choosing to use my Linux workstation. I like its software development environment better.

$ sudo pip3 install configman
$ sudo pip3 install webthing
$ git clone
$ cd pywot
$ cd demo

So what is configman ?

This is an obscure library for configuration that I wrote years and years ago.  I continue to use it because it is really handy.  It combines command line, config files, the environment or anything conforming to the abstract type collections.Mapping to universally manage program configuration.  Configuration requirements can be spread across classes and then used for dynamic loading and dependency injection.  For more information, see my slides for my PyOhio 2014 talk: Configman.

What is webthing?

webthing is a Mozilla package for Python 3, that implements the Web Things api.  It provides a set of classes that represent devices and their properties, giving them an implementation that can be controlled over an HTTP connection.

What is pywot?

pywot is my project to create a wrapper around webthing that offers a more Pythonic interface than webthing does alone.  webthing closely follows a reference implementation written in Javascript, so it offers an API with a distinctly different idiom than most Python modules.  pywot is an attempt to pave over the idiomatic differences.

Step 2:  In the …/pywot/demo directory, there are several example files. is our focus today.  In this posting, we're just going to run it, then we'll tear it apart and analyze it in the next posting.

Get a developers account for Weather Underground.  Take note of your API key that they assign to you.  You'll need this in the next step.

Step 3: Using your WU API key, your city and state, run the program like this:

$ ./ -K YOUR_WU_API_KEY --city_name=Missoula --state_code=MT

Step 4: We're going to assume that there are two light bulbs already configured and named: Red, Green.  Add the virtual weather station to the Things Gateway. by pressing the "+" key.

Sometimes, I've noticed that the Things Gateway doesn't immediately find my Virtual Weather Station.  I've not nailed it down as to why, but something about mDNS on my network can be very slow to update - sometimes up to ten minutes.  In this case, you don't have to wait, just press "Add by URL..." and then enter the IP address of the machine running the Virtual Weather Station with this URL template: "http://IP_ADDRESS:8888"

Step 5: The Virtual Weather Station is now fetching weather data every five minutes (as controlled by the configuration value called seconds_between_polling, you can change that on the command line) .  The Things Gateway should have that data immediately:  press the "splat" on the "THING" icon for the weather station:

Step 6: Now we can make a rule to turn on the "Green" light whenever the wind speed exceeds the minimum rated speed for our kite.

Select RULES from the drop down menu.  Drag the Weather Station up into the top half of the screen; select "Wind Speed" from the drop down box; change the "<" to ">"; use the up/down buttons to set the minimum wind speed threshold.  I'm choosing 5.

Step 7: Drag the "Green" light into the other half of the blank pane, use the drop down box to select the "ON" property.

Step 8: Go to the top of the page, set a useful name to your rule, press <enter> and then use the left arrow to leave the rule editor.
Step 9:  You've now seen how to make a rule based on properties of the Weather Station.  Your task is to now make the rule for the Red light.  I made mine turn on the red light when the wind is less than 5mph - I call that calm winds.  You can make your red light rule do whatever you want.

That should be about it.

Remember that making a rule implies the creation of a converse rule.  The rule that I made above says the Green light should come on when the wind speed is greater than 5mph.  The converse rule says that wind speeds below 5mph, the light will go out.

If the wind speed was greater than five at the moment that the rule was created, there may be some counterintuitive behavior.  It appears that rules aren't applied immediately as they're created.  They trigger on an "event" that happens when a property changes value.  If the wind was greater than 5mph when the rule was created, the rule didn't yet exist when the "event" happened.  The kite light will still work once the wind speed changes again at the next five minute polling point.  Be patient.

Bonus Step:  want to run the Virtual Weather Station, but don't want to include the WU API key on the command line?  Try this:
$ ./ -K YOUR_WU_API_KEY --admin.dump_conf=config.ini

That created a config file called: ./config.ini
Open up ./config.ini in an editor and uncomment the line that has your WU API key. Save the file.  You can specify the the config file on the command line when you run the Virtual Weather Station.  Any of the parameters can be loaded from the ini file.

$ ./ -admin.conf=config.ini --city_name=Missoula --state_code=MT

Still too much typing? Instead of the config file, you could just set any/all of the parameters as environment variables:

$ weather_underground_api_key=YOUR_WU_KEY
$ city_name=Missoula
$ state_code=MT
$ ./

In my next blog post, I'm going to explain the code that runs the Virtual Weather Station in great detail.
Categorieën: Mozilla-nl planet

Andrew Halberstadt: Taskgraph Like a Pro

Mozilla planet - vr, 14/12/2018 - 18:21

Have you ever needed to inspect the taskgraph locally? Did you have a bad time? Learn how to inspect the taskgraph like a PRO. For the impatient skip to the installation instructions below.

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Socorro: migrating to Python 3

Mozilla planet - vr, 14/12/2018 - 16:00

Socorro is the crash ingestion pipeline for Mozilla's products like Firefox. When Firefox crashes, the Breakpad crash reporter asks the user if the user would like to send a crash report. If the user answers "yes!", then the Breakpad crash reporter collects data related to the crash, generates a crash report, and submits that crash report as an HTTP POST to Socorro. Socorro saves the crash report, processes it, and provides an interface for aggregating, searching, and looking at crash reports.

This blog post talks about the project migrating Socorro to Python 3. It covers the incremental steps we did and why we chose that path plus some of the technical problems we hit.

Read more… (16 mins to read)

Categorieën: Mozilla-nl planet

QMO: Firefox 65 Beta 6 Testday, December 21th

Mozilla planet - vr, 14/12/2018 - 15:56

Hello Mozillians,

We are happy to let you know that Friday, December 21th, we are organizing Firefox 65 Beta 6 Testday. We’ll be focusing our testing on:  <notificationbox> and <notification> changes and UpdateDirectory.

Check out the detailed instructions via this etherpad.

No previous testing experience is required, so feel free to join us on #qa IRC channel where our moderators will offer you guidance and answer your questions.

Join us and help us make Firefox better!

See you on Friday!

Categorieën: Mozilla-nl planet

Nick Fitzgerald: Rust and WebAssembly in 2019

Mozilla planet - vr, 14/12/2018 - 09:00

Compiling Rust to WebAssembly should be the best choice for fast, reliable code for the Web. Additionally, the same way that Rust integrates with C calling conventions and libraries on native targets, Rust should also integrate with JavaScript and HTML5 on the Web. These are the Rust and WebAssembly domain working group’s core values.

In 2018, we made it possible to surgically replace performance-sensitive JavaScript with Rust-generated WebAssembly.

I propose that we make larger-scale adoption of Rust and WebAssembly practical in 2019.

#RustWasm2019: To provide some context for this blog post, the Rust and WebAssembly domain working group is currently soliciting proposals for its 2019 roadmap. This is my proposal. I encourage you to add your voice to the discussion as well!

A Rising Tide Lifts All Boats

We should build a toolkit of loosely coupled libraries that make Rust and WebAssembly development practical. Whether you are carefully inserting a small wasm module into an existing JavaScript system, architecting a large wasm module, or starting a green-field Web application, this toolkit should make you productive.

People use high-level libraries and frameworks instead of using Web APIs directly because they want abstractions with which they can naturally express themselves. For example:

  • I prefer describing how I want the DOM to look like right now, rather than enumerating a list of modifications that will transform its current state into my desired state.
  • I prefer thinking in terms of Rust types, not about the raw, serialized bytes in a fetched HTTP response body or about object stores in Indexed DB.

In order to get to rise to that level of abstraction, we will need a diverse set of libraries for the various capabilities the Web exposes:

  • Networking, fetch, and WebSockets
  • Working with forms and <input>
  • Timers and setTimeout
  • Web GL and Web Audio
  • Persistent client storage with Indexed DB
  • A console.log-based backend for env_logger and the Rust logging facade
  • URL routing and window.history
  • Custom elements and Web components
  • Etc…

In 2018, we made using all of these things possible in that you can access the underlying JavaScript and Web APIs directly via wasm-bindgen, js-sys and web-sy, but this is equivalent to programming against the libc crate directly. In 2019, we should create higher-level abstractions that wrap the raw, underlying API to yield a better experience that is ultimately more practical. Green-field Rust and WebAssembly applications would use an umbrella crate that connects the whole toolkit together and re-exports its individual crates. Small, targeted wasm modules that are integrating back into an existing JavaScript application would pick and choose relevant libraries from the toolkit instead of depending upon the whole umbrella crate.

We should collectively build these higher-level libraries and the toolkit’s umbrella crate that connects them together. There is a ton of room here for contributors to step up and provide leadership for a particular component library. This toolkit and all of its crates should reflect our working group’s core values:

  • Fast: Let’s show everyone how fast the Web can be ;-) Zero-cost abstractions from the ground up. No wandering off the happy path to fall off a performance cliff. No frames dropped.

  • Reliable: One of the things that I love about the Rust community is the high standards we hold ourselves to, in particular for correctness. We should leverage Rust’s type system to enforce correctness, write property-based tests with quickcheck, and have comprehensive integration tests running in headless browsers. We intend to build a solid foundation, and there shouldn’t be reason to question its structural integrity.

  • Excellent integration with JavaScript and the Web: We must empower incremental Rust and WebAssembly adoption: rewriting from scratch is not practical. Plus, there is a bunch of JavaScript code that wouldn’t make sense to rewrite in Rust because it is just fine right now.

In addition to supporting our core values, our toolkit should also be:

  • Modular: Take or leave any individual crate from the toolkit. We do not want to build a monolithic, walled garden! The goal is to amplify sharing, compatibility, and improvements; reducing effort duplication across the blossoming Rust and WebAssembly ecosystem.

  • Ergonomic: Rust’s abstractions are not only zero-cost, they are also expressive! We should leverage this to build APIs that are a joy to work with. The glium crate is an excellent example of transmuting a beautiful Rust crate from a crufty API that was not designed for the Rust language.

Some of the aforementioned Web APIs are already wrapped up into high-level APIs in crates that already exist. However, few of the extant crates fulfill all of our requirements. Most commonly they are lacking modularity: we’ve seen more “frameworks” than single-purpose libraries collected into “toolkits”. Nonetheless, we should collaborate to improve existing crates and tease them apart into small, single-purpose libraries where it makes sense and everyone is on board.

Finally, the inspiration for this idea of developing a loosely coupled toolkit comes from the Rust Networking domain working group’s Tide project, and also from the Choo JavaScript project. Thanks!


Right now, wasm-pack will orchestrate your building and testing workflows, and generate a package.json file to help you integrate with JavaScript tooling. It will publish your Rust-generated WebAssembly package to NPM, making distribution easy.

But there are a few things that we intended to include in 2018 that didn’t quite make the cut:

  • Integrating and automating execution of the binaryen project’s wasm-opt tool.
  • Support for generating a single NPM package that will work both on the Web and in Node.js.
  • Allowing a library crate X to declare that it has a runtime dependency on an external NPM package, and have that reflected in the package.json that wasm-pack produces for some crate Y that transitively depends on X.
  • Including local assets (notably JavaScript snippets) into wasm-pack’s generated NPM package. Again, with support for crates that are transitively depended upon.

I suspect the latter two items in particular will be necessary for building out the toolkit.

We should finish these tasks and polish wasm-pack into a 1.0 tool. Following that, we should let experience and necessity guide our efforts.

One final note on tooling: Internet Explorer 11 is the last browser that still has non-trivial market share and doesn’t support wasm. It is mostly possible to support IE11 by using the binaryen project’s wasm2js tool to compile our wasm into JavaScript. But wasm2js is still missing some core functionality, and the whole experience of writing a Rust and wasm app while also supporting IE11 is far from turnkey. Because this is so important for actually shipping a Rust and wasm project, we shouldn’t leave this problem for users to solve via integration with external tooling: we should build support for it into our toolchain. This way we can provide that turnkey experience, and make sure that all wasm code that our toolchain emits is fully supported on Internet Explorer 11.


We must bring Rust’s fearless concurrency to the Web!

Of the languages (C, C++, and Rust) that can use shared memory threading on the Web, only Rust can safely do so. The Web APIs necessary for multithreading are stabilizing and will be enabled by default in browsers soon. We should be ready.

However, we can’t just make std::thread work transparently in wasm, due to the nature of the APIs the Web platform is exposing. For example, we can’t block the event loop indefinitely, even in a worker thread, and we need to change the global allocator to avoid waiting on locks on the main thread. See Alex’s excellent Multithreading Rust and WebAssembly write up for details.

Therefore, I think this multithreading effort will mostly involve creating a thread pool library for the whole wasm ecosystem to share, and then building channels and other concurrency abstractions on top of it. We should also get support for wasm threading and our thread pool library upstream into crates like rayon as well. This isn’t actually that different from the library and toolkit work, but it is worth singling out due to its scale, the unique nature of the problem domain, and what a huge game changer multithreading on the Web will be.


I think 2019 holds a very bright future for Rust and WebAssembly.

Categorieën: Mozilla-nl planet

Mozilla GFX: WebRender newsletter #33

Mozilla planet - do, 13/12/2018 - 11:52

Hi! The newsletter skipped a week because of Mozilla’s bi-annual allhands which took place in Orlando last week. We’ll probably skip a few others in December as a lot of the gfx folks are taking some time off. Before I get to the usual change list, I’ll continue answering the questions nic4r asked in the 31st newsletter’s comment section:

Is the interning work Glenn is doing related to picture caching?

Yes indeed. In order for picture caching to work across displaylists we must be able to detect what did not change after a new displaylist arrives. The interning mechanism introduced by Glenn in #3075 gives us this ability in addition to other goodies such as de-duplication of interned resources and less CPU-GPU data transfer.

What is blob tiling and what does it offer above normal blob rendering?

Tiling blobs means splitting blobs into square tiles. For very large blobs this means we can lazily rasterize tiles as they come into the viewport without throwing away the rest instead of either rasterizing excessively large blob images in one go or having to clip the blob against the viewport and re-rasterize everything during scrolling as the bounds of the blob change. It also lets us rasterize tiles in parallel.

Is there a bug to watch some of the document splitting work going on? My understanding is that document splitting will make the chrome more resilient against slow scene builds in the content frame? Is this right? How does this compare to push_iframe in the DL.

You can look at bug 1441308 although it doesn’t contain a lot of updates. In a nutshell, the bulk of the Gecko side work is done and there are WebRender side adjustments and some debugging to do. Currently WebRender can nest displaylists from different sources (content, UI, etc) by nesting iframes into a single document. Any change to the document more or less causes it to be re-rendered entirely (modulo caching optimizations).

Separating the UI and web content into separate documents mostly means we will update them independently and updating one won’t cause the other to be re-built and re-rendered. It will also let us render the the two in separate OS compositor windows.

One of the most complicated aspect of this is probably due to the way the browser is structured to nest the web content within the UI (there is both a background behind the web content and elements on top of it that belong to the UI). A lot of the work that went into this was to be able to split without introducing a lot of overdraw (needlessly allocating texture space for the background behind the web content and drawing it).

OMTA for color, gradients, etc? How much more of CSS can be feasibly calculated off thread and fed to WR using its Property Binding infra?

Anything is possible given enough time and motivation but with WebRender’s current architecture, any of the data that is fed directly to the shaders is a good candidate for animated property bindings. Colors are particularly appealing because it is the most commonly animated CSS property that we don’t already run as an off-main-thread animation (I don’t have the data handy though). We’ll likely tackle these nice perf optimizations after WebRender is shipped and stable.

Notable WebRender and Gecko changes
  • Bobby overhauled WebRender shader cache.
  • Bobby switched non-WebRender’s AWSY test to VMs with GPUs.
  • Kats made some Android improvements.
  • Kats made some progress on the Windows CI work.
  • Kvark removed some memcpys leading to a 5% improvement on dl_mutate.
  • Kvark improved the render target allocation scheme, improving GPU times and VRAM consumption on a lot of sites.
  • Matt added new telemetry.
  • Andrew fixed a few regressions from animated image recycling.
  • Andrew Kvark and Nical chased a crash caused by two race conditions and landed two fixes.
  • Emilio fixed transform flattening.
  • Emilio enabled warning-as-errors for rust code in CI.
  • Glenn fixed the way we track frame ids.
  • Glenn fixed eager texture cache eviction.
  • Glenn added support for picture caching.
  • Glenn started a series of changes removing clips expressed in local space which cause over-invalidation of interned primitives and prevent picture caching to work effectively across displaylist changes. See also (1), (2), (3), (4), (5).
  • Glenn added memory profile counters for interning.
  • Glenn moved the picture caching tiles to the opaque pass.
  • Sotaro removed some dead code.
  • Sotaro fixed a shutdown crash on Linux.
  • Timothy hooked up proper scale selection.
Ongoing work
  • Bobby is adding lazy initialization to D3D11 and D2D outside the GPU process to save memory.
  • Jeff and Nical are working on blob recoordination.
  • Matt is working on avoiding to render on changes within zero-opacity elements.
  • Matt is making WebRender’s behavior more similar to non-WebRender’s during catch-up compositing to make comparison easier.
  • Lee continues tracking down font related crashes and rendering issues with very large text
  • Emilio is dreaming of 3d transforms (I believe he actually used the term “nightmare”).
  • Sotaro is investigating SVG rendering bugs.
Enabling WebRender in Firefox Nightly

In about:config, set the pref “gfx.webrender.all” to true and restart the browser.

Reporting bugs

The best place to report bugs related to WebRender in Firefox is the Graphics :: WebRender component in bugzilla.
Note that it is possible to log in with a github account.

Categorieën: Mozilla-nl planet