Mozilla Nederland LogoDe Nederlandse

Mozilla Roadshow Event: To μέλλον του Ίντερνετ και της VR έρχεται στην Αθήνα ... - Huffington Post Greece

Nieuws verzameld via Google - ma, 22/05/2017 - 12:52

Mozilla Roadshow Event: To μέλλον του Ίντερνετ και της VR έρχεται στην Αθήνα ...
Huffington Post Greece
Εξαιρετικά ενδιαφέρουσες ματιές σε αυτά που επιφυλάσσει το μέλλον για το Ίντερνετ θα έχουν την ευκαιρία να ρίξουν όσοι παρευρεθούν στο Mozilla Developer Roadshow που διοργανώνεται στις 25 Μαΐου στην Αθήνα, στον Κινηματογράφο Δαναός.

Categorieën: Mozilla-nl planet

Software-update: Mozilla Firefox 53.0.3 - Tweakers

Nieuws verzameld via Google - za, 20/05/2017 - 07:26


Software-update: Mozilla Firefox 53.0.3
Mozilla Firefox 2013 logo (75 pix) Mozilla heeft versie 53.0.3 van zijn webbrowser Firefox uitgebracht, 53.0.1 is nooit verschenen. In versie 53 zijn verbeteringen aangebracht met betrekking tot het weergeven van afbeeldingen, wat in minder vastlopers ...

Categorieën: Mozilla-nl planet

Mozilla enters net neutrality lobbying fight - The Hill

Nieuws verzameld via Google - vr, 19/05/2017 - 17:55

The Hill

Mozilla enters net neutrality lobbying fight
The Hill
Internet nonprofit Mozilla is jumping in on the Washington, D.C., influence fight over the fate of net neutrality. In a lobbying disclosure form released on Monday, the company said that it would be hiring Kountoupes Denham LLC, a D.C. consultancy to ...

en meer »
Categorieën: Mozilla-nl planet

Mozilla confirms that Flash will be 'Ask to Activate' starting with Firefox 55 - The INQUIRER

Nieuws verzameld via Google - vr, 19/05/2017 - 14:40


Mozilla confirms that Flash will be 'Ask to Activate' starting with Firefox 55
MOZILLA HAS taken another big step on the road to finally eradicating that puss-oozing skank Flash from the face of the earth. As planned, from Firefox 55, the malevolent has-been plug-in will be "Ask to Activate" meaning that each instance of Flash ...

Categorieën: Mozilla-nl planet

One Step Closer to a Closed Internet

Mozilla Blog - do, 18/05/2017 - 18:10
Today, the FCC voted on Chairman Ajit Pai’s proposal to repeal and replace net neutrality protections enacted in 2015. The verdict: to move forward with Pai’s proposal


We’re deeply disheartened. Today’s FCC vote to repeal and replace net neutrality protections brings us one step closer to a closed internet.  Although it is sometimes hard to describe the “real” impacts of these decisions, this one is easy: this decision leads to an internet that benefits Internet Service Providers (ISPs), not users, and erodes free speech, competition, innovation and user choice.

This vote undoes years of progress leading up to 2015’s net neutrality protections. The 2015  rules properly place ISPs under “Title II” of the Communications Act of 1934, and through that well-tested basis of legal authority, prohibit ISPs from engaging in paid prioritization and blocking or throttling of web content, applications and services. These rules ensured a more open, healthy Internet.

Pai’s proposal removes the 2015 protections and re-re-classifies ISPs under “Title I,” which courts already have determined is insufficient for ensuring a truly neutral net. The result: ISPs would be able to once again prioritize, block and throttle with impunity. This means fewer opportunities for startups and entrepreneurs, and a chilling effect on innovation, free expression and choice online.

Net neutrality isn’t an abstract issue — it has significant, real-world effects. For example, in the past, without net neutrality protections, ISPs have imposed limits on who can FaceTime and determined how we stream videos, and also adopted underhanded business practices.

So what’s next and what can we do?

We’re now entering a 90-day public comment period, which ends in mid-August. The FCC may determine a path forward as soon as October of this year.

During the public comment period in 2015, nearly 4 million citizens wrote to the FCC, many of them demanding strong net neutrality protections.  We all need to show the same commitment again.

We’re already well on our way to making noise. In the weeks since Pai first announced his proposal, more than 100,000 citizens (not bots) have signed Mozilla’s net neutrality petition at And countless callers (again, not bots) have recorded more than 50 hours of voicemail for the FCC’s ears. We need more of this.

We’re also planning strategic, direct engagement with policymakers, including through written comments in the FCC’s open proceeding. Over the next three months, Mozilla will continue to amplify internet users’ voices and fuel the movement for a healthy internet.

The post One Step Closer to a Closed Internet appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Improving Internet Security through Vulnerability Disclosure

Mozilla Blog - wo, 17/05/2017 - 17:29
Supporting the PATCH Act for VEP Reform


Today, Mozilla sent a letter to Congress in support of the Protecting Our Ability to Counter Hacking Act (PATCH Act) that was just introduced by Sen. Cory Gardner, Sen. Ron Johnson, Sen. Brian Schatz, Rep. Blake Farenthold, and Rep. Ted Lieu.

We support the PATCH Act because it aims to codify and make the existing Vulnerabilities Equities Process more transparent. The Vulnerabilities Equities Process (VEP) is the U.S. government’s process for reviewing and coordinating the disclosure of new vulnerabilities learns about.

The VEP remains shrouded in secrecy, and is in need of process reforms to ensure transparency, accountability, and oversight. Last year, I wrote about five important reforms to the VEP we believe are necessary to make the internet more secure. The PATCH Act includes many of the key reforms, including codification in law to increase transparency and accountability.

For background, a vulnerability is a flaw – in design or implementation – that can be used to exploit or penetrate a product or system. We saw an example this weekend as a ransomware attack took unpatched systems by surprise – and you’d be surprised at how common they are if we don’t all work together to fix them. These vulnerabilities can put users and businesses at significant risk from bad actors. At the same time, exploiting these same vulnerabilities can also be useful for law enforcement and intelligence operations. It’s important to consider those equities when the government decides what to do.

If the government has exploits that have been compromised, they must disclose them to tech companies before those vulnerabilities can be used widely and put users at risk. The lack of transparency around the government’s decision-making processes here means that we should improve and codify the Vulnerabilities Equities Process in law. Read this Mozilla Policy blog post from Heather West for more details.

The internet is a shared resource and securing it is our shared responsibility. This means technology companies, governments, and even users have to work together to protect and improve the security of the internet.

We look forward to working with the U.S. government (and governments around the world) to improve disclosure of security vulnerabilities and better secure the internet to protect us all.



The post Improving Internet Security through Vulnerability Disclosure appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

WannaCry is a Cry for VEP Reform

Mozilla Blog - ma, 15/05/2017 - 21:28

This weekend, a vulnerability in some versions of the Windows operating system resulted in the biggest cybersecurity attack in years. The so-called “WannaCry” malware relied on at least one exploit included in the latest Shadow Brokers release. As we have repeated, attacks like this are a clarion call for reform to the government’s Vulnerabilities Equities Process (VEP).

The exploits may have been shared with Microsoft by the NSA. We hope that happened, as it would be the right way to handle a vulnerability like this. Sharing vulnerabilities with tech companies enables us to protect our users, including the ones within the government. If the government has exploits that have been compromised, they must disclose them to software companies before they can be used widely putting users at risk. The lack of transparency around the government’s decision-making processes here means that we should improve and codify the Vulnerabilities Equities Process in law.

The WannaCry attack also shows the importance of security updates in protecting users. Microsoft patched the relevant vulnerabilities in a March update, but users who had not updated remain vulnerable. Mozilla has shared some resources to help users update their software, but much more needs to be done in this area.

The internet is a shared resource and securing it is our shared responsibility. This means technology companies, governments, and even users have to work together to protect and improve the security of the internet.

The post WannaCry is a Cry for VEP Reform appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Karl Dubost: [worklog] Edition 066. Removing knots

Mozilla planet - ma, 15/05/2017 - 01:05
webcompat life
  • Often tracking protection is confusing for people. I always wonder if it's because people are put in front of it in failure situation. Basically you discover something is not working because the site breaks, and you are later on told it is because of tracking protection. It's a negative feeling feature which doesn't show itself when everything is fine. I wonder if there would be a way to reverse that feeling. Something like, an individual site report on the blocking and a daily or weekly stats dashboard explaining what has been blocked. "Congratulations, Tracking Protection has blocked this week X of this, Y of that."
  • Webcompat Minutes published
webcompat issues dev Interesting read


Categorieën: Mozilla-nl planet

Five Customer Experience Insights From T-Mobile, Patagonia, Mozilla ... - Forbes

Nieuws verzameld via Google - zo, 14/05/2017 - 17:14


Five Customer Experience Insights From T-Mobile, Patagonia, Mozilla ...
I was lucky enough to attend Collision, a tech and start up conference in New Orleans just over a week ago. Now, a pure tech and start up conference is not usually my thing so whilst there were all sorts of fascinating start-ups, interesting ...

Categorieën: Mozilla-nl planet

Manish Goregaokar: Mentally Modelling Modules

Mozilla planet - zo, 14/05/2017 - 02:00

The module and import system in Rust is sadly one of the many confusing things you have to deal with whilst learning the language. A lot of these confusions stem from a misunderstanding of how it works. In explaining this I’ve seen that it’s usually a common set of misunderstandings.

In the spirit of “You’re doing it wrong”, I want to try and explain one “right” way of looking at it. You can go pretty far1 without knowing this, but it’s useful and helps avoid confusion.

First off, just to get this out of the way, mod foo; is basically a way of saying “look for or foo/ and make a module named foo with its contents”. It’s the same as mod foo { ... } except the contents are in a different file. This itself can be confusing at first, but it’s not what I wish to focus on here. The Rust book explains this more in the chapter on modules.

In the examples here I will just be using mod foo { ... } since multi-file examples are annoying, but keep in mind that the stuff here applies equally to multi-file crates.

Motivating examples

To start off, I’m going to provide some examples of Rust code which compiles. Some of these may be counterintuitive, based on your existing model.

pub mod foo { extern crate regex; mod bar { use foo::regex::Regex; } }


use std::mem; pub mod foo { // not std::mem::transmute! use mem::transmute; pub mod bar { use foo::transmute; } }


pub mod foo { use bar; use bar::bar_inner; fn foo() { // this works! bar_inner(); bar::bar_inner(); // this doesn't // baz::baz_inner(); // but these do! ::baz::baz_inner(); super::baz::baz_inner(); // these do too! ::bar::bar_inner(); super::bar::bar_inner(); self::bar::bar_inner(); } } pub mod bar { pub fn bar_inner() {} } pub mod baz { pub fn baz_inner() {} }


pub mod foo { use bar::baz; // this won't work // use baz::inner(); // this will use self::baz::inner; // or // use bar::baz::inner pub fn foo() { // but this will work! baz::inner(); } } pub mod bar { pub mod baz { pub fn inner() {} } }


These examples remind me of the “point at infinity” in elliptic curve crypto or fake particles in physics or fake lattice elements in various fields of CS2. Sometimes, for something to make sense, you add in things that don’t normally exist. Similarly, these examples may contain code which is not traditional Rust style, but the import system still makes more sense when you include them.


The core confusion behind how imports work can really be resolved by remembering two rules:

  • use foo::bar::baz resolves foo relative to the root module ( or
    • You can resolve relative to the current module by explicily trying use self::foo::bar::baz
  • foo::bar::baz within your code3 resolves foo relative to the current module
    • You can resolve relative to the root by explicitly using ::foo::bar::baz

That’s actually … it. There are no further caveats. The rest of this is modelling what constitutes as “being within a module”.

Let’s take a pretty standard setup, where extern crate declarations are placed in the the root module:

extern crate regex; mod foo { use regex::Regex; fn foo() { // won't work // let ex = regex::Regex::new(""); let ex = Regex::new(""); } }

When we say extern crate regex, we pull in the regex crate into the crate root. This behaves pretty similar to mod regex { /* contents of regex crate */}. Basically, we’ve imported the crate into the crate root, and since all use paths are relative to the crate root, use regex::Regex works fine inside the module.

Inline in code, regex::Regex won’t work because as mentioned before inline paths are relative to the current module. However, you can try ::regex::Regex::new("").

Since we’ve imported regex::Regex in mod foo, that name is now accessible to everything inside the module directly, so the code can just say Regex::new().

The way you can view this is that use blah and extern crate blah create an item named blah “within the module”, which is basically something like a symbolic link, saying “yes this item named blah is actually elsewhere but we’ll pretend it’s within the module”

The error message from this code may further drive this home:

use foo::replace; pub mod foo { use std::mem::replace; }


The error I get is

error: function `replace` is private --> src/ | 3 | use foo::replace; | ^^^^^^^^^^^^

There’s no function named replace in the module foo! But the compiler seems to think there is?

That’s because use std::mem::replace basically is equivalent to there being something like:

pub mod foo { fn replace(...) -> ... { ... } // here we can refer to `replace` freely (in inline paths) fn whatever() { // ... let something = replace(blah); // ... } }

except it’s actually like a symlink to the function defined in std::mem. Because inline paths are relative to the current module, saying use std::mem::replace works as if you had defined a function replace in the same module, and you can refer to replace() without needing any extra qualification in inline paths.

This also makes pub use fit perfectly in our model. pub use says “make this symlink, but let others see it too”:

// works now! use foo::replace; pub mod foo { pub use std::mem::replace; }

Folks often get annoyed when this doesn’t work:

mod foo { use std::mem; // nope // use mem::replace; }

As mentioned before, use paths are relative to the root module. There is no mem in the root module, so this won’t work. We can make it work via self, which I mentioned before:

mod foo { use std::mem; // yep! use self::mem::replace; }

Note that this brings overloading of the self keyword up to a grand total of four! Two cases which occur in the import/path system:

  • use self::foo means “find me foo within the current module”
  • use foo::bar::{self, baz} is equivalent to use foo::bar; use foo::bar::baz;
  • fn foo(&self) lets you define methods and specify if the receiver is by-move, borrowed, mutably borrowed, or other
  • Self within implementations lets you refer to the type being implemented on

Oh well, at least it’s not static.

Going back to one of the examples I gave at the beginning:

use std::mem; pub mod foo { use mem::transmute; pub mod bar { use foo::transmute; } }


It should be clearer now why this works. The root module imports mem. Now, from everyone’s point of view, there’s an item called mem in the root.

Within mod foo, use mem::transmute works because use is relative to the root, and mem already exists in the root! When you use something, all child modules will see it as if it were actually belonging to the module. (Non-child modules won’t see it because of privacy, we saw an example of this already)

This is why use foo::transmute works from mod bar, too. bar can refer to the contents of foo via use foo::whatever, since foo is a child of the root module, and use is relative to the root. foo already has an item named transmute inside it because it imported one. Nothing in the parent module is private from the child, so we can use foo::transmute from bar.

Generally, the standard way of doing things is to either not use modules (just a single, or, if you do use modules, put nothing other than extern crates and mods in the root. This is why we rarely see shenanigans like the above; there’s nothing in the root crate to import, aside from other crates specified by extern crate. The trick of “reimport something from the parent module” is also pretty rare because there’s basically no point to using that (just import it directly!). So this is not the kind of code you’ll see in the wild.

Basically, the way the import system works can be summed up as:

  • extern crate and use will act as if they were defining the imported item in the current module, like a symbolic link
  • use foo::bar::baz resolves the path relative to the root module
  • foo::bar::baz in an inline path (i.e. not in a use) will resolve relative to the current module
  • ::foo::bar::baz will always resolve relative to the root module
  • self::foo::bar::baz will always resolve relative to the current module
  • super::foo::bar::baz will always resolve relative to the parent module

Alright, on to the other half of this. Privacy.


So how does privacy work?

Privacy, too, follows some basic rules:

  • If you can access a module, you can access all of its pub contents
  • A module can always access its child modules, but not recursively
    • This means that a module cannot access private items in its children, nor can it access private grandchildren modules
  • A child can always access its parent modules (and their parents), and all their contents
  • pub(restricted) is a proposal which extends this a bit, but it’s experimental so we won’t deal with it here

Giving some examples,

mod foo { mod bar { // can access `foo::foofunc`, even though `foofunc` is private pub fn barfunc() {} } // can access `foo::bar::barfunc()`, even though `bar` is private fn foofunc() {} } mod foo { mod bar { // We can access our parent and _all_ its contents, // so we have access to `foo::baz`. We can access // all pub contents of modules we have access to, so we // can access `foo::baz::bazfunc` use foo::baz::bazfunc; } mod baz { pub fn bazfunc() {} } }

It’s important to note that this is all contextual; whether or not a particular path works is a function of where you are. For example, this works4:

pub mod foo { /* not pub */ mod bar { pub mod baz { pub fn bazfunc() {} } pub mod quux { use foo::bar::baz::bazfunc; } } }

We are able to write the path foo::bar::baz::bazfunc even though bar is private!

This is because we still have access to the module bar, by being a descendent module.

Hopefully this is helpful to some of you. I’m not really sure how this can fit into the official docs, but if you have ideas, feel free to adapt it5!

  1. This is because most of these misunderstandings lead to a model where you think fewer things compile, which is fine as long as it isn’t too restrictive. Having a mental model where you feel more things will compile than actually do is what leads to frustration; the opposite can just be restrictive.

  2. One example closer to home is how Rust does lifetime resolution. Lifetimes form a lattice with 'static being the bottom element. There is no top element for lifetimes in Rust syntax, but internally there is the “empty lifetime” which is used during borrow checking. If something resolves to have an empty lifetime, it can’t exist, so we get a lifetime error.

  3. When I say “within your code”, I mean “anywhere but a use statement”. I may also term these as “inline paths”.

  4. Example adapted from this discussion

  5. Contact me if you have licensing issues; I still have to figure out the licensing situation for the blog, but am more than happy to grant exceptions for content being uplifted into official or semi-official docs.

Categorieën: Mozilla-nl planet

Eric Shepherd: Doing what doesn’t come naturally

Mozilla planet - vr, 12/05/2017 - 16:30

I’ve been writing developer documentation for 20 years now, 11 of those years at Mozilla. For most of those years, documentation work was largely unmanaged. That is to say, we had management, and we had goals, but how we reached those goals was entirely up to us. This worked well for me in particular. My brain is like a simple maze bot in some respects, following all the left turns until it reaches a dead end, then backing up to where it made the last turn and taking the next path to the right, and repeating until the goal has been reached.

This is how I wrote for a good 14 or 15 years of my career. I’d start writing about a topic, linking to APIs, functions, other guides and tutorials, and so forth along the way—whether they already existed or not. Then I’d go back through the page and click the first link on the page I just created, and I’d make sure that that page was solid. Any material on that page that needed to be fixed for my new work to be 100% understood, I’d update. If there were any broken links, I’d fix them, creating and writing new pages as needed, and so forth.

How my mind wants to do it

Let’s imagine that the standards gurus have spoken and have decided to add to a new <dial> element to HTML, providing support for creating knobs and speedometer-style feedback displays. My job is to document this element.

I start by creating the main article in the HTML reference for <dial>, and I write that material, starting with a summary (which may include references to <progress>, <input>, and other elements and pages). It may also include links to articles I plan to create, such as “Using dial elements” and “Displaying information in HTML” as well as articles on forms.

As I continue, I may wind up with links to subpages which need to be created; I’ll also wind up with a link to the documentation for the HTMLDialElement interface, which obviously hasn’t been written yet. I also will have links to subpages of that, as well as perhaps for other elements’ attributes and methods.

Having finished the document for <dial>, I save it, review it and clean it up, then I start following all the links on the page. Any links that take me to a page that needs to be written, I write it. Any links that take me to a page that needs content added because of the new element, I expand them. Any links that take me to a page that is just horribly unusably bad, I update or rewrite as needed. And I continue to follow those left-hand turns, writing or updating article after article, until eventually I wind up back where I started.

If one of those pages is missing an example, odds are good it’ll be hard to resist creating one, although if it will take more than a few minutes, this is where I’m likely to reluctantly flag it for someone else to do later, unless it’s really interesting and I am just that intrigued.

By the time I’m done documenting <dial>, I may also have updated badly out of date documentation for three other elements and their interfaces, written pages about how to decide on the best way to represent your data, added documentation for another undocumented element that has nothing to do with anything but it was a dead link I saw along the way, updated another element’s documentation because that page was where I happened to go to look at the correct way to structure something, and I saw it had layout problems…

You get the idea.

How I have to do it now

Unfortunately, I can’t realistically do that anymore. We have adopted a system of sprints with planned work for each sprint. Failing to complete the work in the expected amount of time tends to get you dirty looks from more and more people the longer it goes on. Even though I’m getting a ton accomplished, it doesn’t count if it’s not on the sprint plan.

So I try to force myself to work on only the stuff directly related to the sprint we’re doing. But sometimes the line is hard to find. If I add documentation for an interface, but the documentation for its parent interface is terrible, it seems to me that updating that parent interface is a fairly obvious part of my job for the sprint. But it wasn’t budgeted into the time available, so if I do it, I’m not going to finish in time.

The conundrum

That leaves me in a bind: do strictly what I’m supposed to do, leaving behind docs that are only partly usable, or follow at least some of those links into pages that need help before the new content is truly usable and “complete,” but risk missing my expected schedule.

I almost always choose the latter, going in knowing I’m going to be late because of it. I try to control my tendency to keep making left turns, but sometimes I lose myself in the work and write stuff I am not expected to be doing right now.

Worse, though, is that the effort of restraining myself to just writing what’s expected is unnatural to me. My brain rebels a bit, and I’m quite sure my overall throughput is somewhat lower because of it. As a result: a less enjoyable writing experience for me, less overall content created, and unmet goals.

I wonder, sometimes, how my work results would look if I were able to cut loose and just go again. I know I have other issues slowing me down (see my earlier blog post Peripheral neuropathy and me), but I can’t help wondering if I could be more productive by working how I think, instead of doing what doesn’t come naturally: work on a single thing from A to Z without any deviation at all for any reason.

Categorieën: Mozilla-nl planet

Marcia Knous: It is all about community

Mozilla planet - vr, 12/05/2017 - 15:57
This past weekend's l10n/Nightly workshop reminded me about how great it is meeting Mozillians that work on various aspects of our project. I had some interesting conversations with various communities, about lots of different topics. I don't work specifically with localizers, but it was interesting to hear some of the challenges they face when they have to translate terms in Firefox.marcia and the Mozilla Ugandan communityThese face to face meetups are the best part of working at Mozilla. Although we were mostly in our own spaces in the office, during the lunches and dinners we got to explore some far ranging topics. Some of the communities also brought some "sweets" to the event, which was wonderful.marcia and the Mozilla Persian communityThanks to Jeff, Delphine, Flod, Axel, Peiying, Theo, Pascal, and Clara for all their hard work putting the Paris event together and coordinating the logistics. It was truly a great event!
Categorieën: Mozilla-nl planet

Daniel Pocock: Thank you to the OSCAL team

Mozilla planet - vr, 12/05/2017 - 15:26

The welcome gift deserves its own blog post. If you want to know what is inside, I hope to see you at OSCAL'17.

Categorieën: Mozilla-nl planet

Daniel Pocock: Kamailio World and FSFE team visit, Tirana arrival

Mozilla planet - vr, 12/05/2017 - 11:48

This week I've been thrilled to be in Berlin for Kamailio World 2017, one of the highlights of the SIP, VoIP and telephony enthusiast's calendar. It is an event that reaches far beyond Kamailio and is well attended by leaders of many of the well known free software projects in this space.

HOMER 6 is coming

Alexandr Dubovikov gave me a sneak peek of the new version of the HOMER SIP capture framework for gathering, storing and analyzing messages in a SIP network.

exploring HOMER 6 with Alexandr Dubovikov at Kamailio World 2017

Visiting the FSFE team in Berlin

Having recently joined the FSFE's General Assembly as the fellowship representative, I've been keen to get to know more about the organization. My visit to the FSFE office involved a wide-ranging discussion with Erik Albers about the fellowship program and FSFE in general.

discussing the Fellowship program with Erik Albers

Steak and SDR night

After a hard day of SIP hacking and a long afternoon at Kamailio World's open bar, a developer needs a decent meal and something previously unseen to hack on. A group of us settled at Escados, Alexanderplatz where my SDR kit emerged from my bag and other Debian users found out how easy it is to apt install the packages, attach the dongle and explore the radio spectrum.

playing with SDR after dinner

Next stop OSCAL'17, Tirana

Having left Berlin, I'm now in Tirana, Albania where I'll give an SDR workshop and Free-RTC talk at OSCAL'17. The weather forecast is between 26 - 28 degrees celsius, the food is great and the weekend's schedule is full of interesting talks and workshops. The organizing team have already made me feel very welcome here, meeting me at the airport and leaving a very generous basket of gifts in my hotel room. OSCAL has emerged as a significant annual event in the free software world and if it's too late for you to come this year, don't miss it in 2018.

OSCAL'17 banner

Categorieën: Mozilla-nl planet

Mozilla houdt Thunderbird dan toch in leven -

Nieuws verzameld via Google - vr, 12/05/2017 - 10:35

Mozilla houdt Thunderbird dan toch in leven
De Mozilla Foundation zal e-maildienst Thunderbird dan toch niet van de hand doen. Het koepelbedrijf boven de Mozilla Corporation dat webbrowser Firefox maakt, heeft beslist dat het de dienst zal blijven ondersteunen, zolang die de groei van de browser ...

Categorieën: Mozilla-nl planet

Ehsan Akhgari: Quantum Flow Engineering Newsletter #9

Mozilla planet - vr, 12/05/2017 - 08:26
It’s been 10 weeks since I have started writing these newsletters (the number in the title isn’t an off by one error, there was a one week hiatus due to a work week!). We still have quite a bit of work ahead of us, but we have also accomplished a good amount. Finding a good metric for progress is hard, but we live and breathe in Bugzilla, so we use a bug-based burn-down chart. As you can see, we are starting to see a decrease in the number of open bugs, and this is as we are actively adding tens of new bugs to the pool in the weekly triage meetings. The other thing that this burn-down chart shows is that we need help! Very recently Kan-Ru came up with the great idea of creating the qf-bugs-upforgrabs tracker bug. These are reasonably self-contained bugs that require less specific domain knowledge and can be worked on by anyone in a reasonable time frame. Please consider taking a look at the dependency list of that bug to see if something interests you! (The similarity of this tacker bug to photon-perf-upforgrabs isn’t an accident!)
On the telemetry hang reports data collection, the new data from hangs of 128ms or longer have been coming in, but there have been some wrinkles in actually receiving this data, and also in receiving the hang data correlated to user interactivity. Michael Layzell has been tirelessly at work on the BHR backend to make it suit our needs, and has been discovering the edges of computation limits in order to symbolicate the BHR reports on (now moved to AWS!). I realized we haven’t had a performance mini-story for a while — I sort of dropped the ball on that. Running over this bug made me want to talk about a pretty well known sort of slowness in C++ code, virtual functions. The cost of virtual functions comes from several different aspects, firstly they effectively prevent the compiler from doing inlining the function which enables a host of compiler optimizations, essentially by enabling the compiler to see more of the code and optimize more effectively based on that. But then there is the runtime cost of the function, which mostly comes from the indirect call. The majority of the performance penalty here on modern hardware is due to branch midpredictions when different implementations of a virtual function get called at a call site. You should remember that on modern desktop processors, the cost of a branch misprediction can be around 15-20 cycles (depending on the processor) so if what your function does is very trivial and it has many overrides that can be called in hot code chances are that you are spending a considerable amount of time waiting for the instruction cache misses on the calls to the virtual function in question. Of course, finding which virtual functions in your program are these expensive ones requires profiling the workloads you care about improving, but always keep an eye for this problem as unfortunately the object-oriented programming model in C++ really encourages writing code like this. This is the kind of issue that a native profiler is probably more suitable for discovering, for example if you are using a simple native sampling profiler these issues typically show up as a long amount of time being spent on the first instruction of the virtual function being called (which is typically an inexpensive instruction otherwise.) Now it’s time to acknowledge the work of all of you who have helped in improving the performance of the browser in the last week. As always, I hope I’m not forgetting anyone:
Categorieën: Mozilla-nl planet

Gervase Markham: Eurovision Bingo (chorus)

Mozilla planet - vr, 12/05/2017 - 00:11

Some people say that all Eurovision songs are the same. (And some say all blog posts on this topic are the same…) That’s probably not quite true, but there is perhaps a hint of truth in the suggestion that some themes tend to recur from year to year. Hence, I thought, Eurovision Bingo.

I wrote some code to analyse a directory full of lyrics, normally those from the previous year of the competition, and work out the frequency of occurrence of each word. It will then generate Bingo cards, with sets of words of different levels of commonness. You can then use them to play Bingo while watching this year’s competition (which is on Saturday).

There’s a Github repo, or if you want to go straight to pre-generated cards for this year, they are here.

Here’s a sample card from the 2014 lyrics:

fell cause rising gonna rain world believe dancing hold once every mean LOVE something chance hey show or passed say because light hard home heart

Have fun :-)

Categorieën: Mozilla-nl planet

Daniel Stenberg: The curl user survey 2017

Mozilla planet - do, 11/05/2017 - 23:15

The annual survey for curl and libcurl users is open. The 2017 edition has some minor edits since last year but is mostly the same set of questions used before. To help us detect changes and trends over time.

If you use curl or libcurl, in any way, shape or form, please consider spending a few minutes of your precious time on this. Your input helps us understand where we are and in which direction we should go next.

Fill in the form!

The poll is open fourteen days from Friday May 12th until midnight (CEST) May 26th 2017. All data we collect is non-personal and anonymous.

To get some idea of what sort of information we extract and collect from the results, have a look at the analysis of last year’s survey.

Categorieën: Mozilla-nl planet

Mozilla verhoogt beloningen voor bugmeldingen in websites -

Nieuws verzameld via Google - do, 11/05/2017 - 19:56

Mozilla verhoogt beloningen voor bugmeldingen in websites
Mozilla heeft de beloningen voor hackers en onderzoekers die kwetsbaarheden in en andere Mozilla-sites rapporteren verhoogd. In 2004 was Mozilla één van de eerste organisaties die een "bug bounty program" lanceerde voor het melden van ...

Categorieën: Mozilla-nl planet

Air Mozilla: Firefox DevTools London Meetup May 2017

Mozilla planet - do, 11/05/2017 - 19:00

Firefox DevTools London Meetup May 2017 Introducing Firefox Developer Tools (DevTools), devtools.html and associated projects such as the new debugger and console.

Categorieën: Mozilla-nl planet