mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 4 maanden 1 dag geleden

Gary Kwong: Porting a legacy add-on to WebExtensions

di, 19/09/2017 - 06:03

tl;dr: Search Keys has been ported successfully and it is known as Add Search Number. Please try it! It works with Google, Yahoo (HK/TW/US), Bing, DuckDuckGo and even Wikipedia’s search page.

188279

Add Search Number

I have been using the excellent Search Keys add-on (original page) for a long time. It allows one to “go to search results by pressing the number of the search”. However, it hasn’t been updated for the better half of a decade and most features (e.g. support for Yahoo! and Bing) had broken, except for the numbers for Google Search.

Recently, there has been a push to move to the WebExtensions API, especially since Firefox 57 will stop supporting legacy XUL add-ons. Hence, I set about a quest to see what it takes to port Search Keys away from XUL, and I kept the author updated throughout.

Discoveries:

  • Using GitHub with Travis and ESLint integration was crucial for saving myself time avoiding silly syntax errors. I’m sure it could be done in your favourite online repository hosting alternative (Bitbucket/GitLab), etc.
  • Getting web-ext via npm also proved essential, along with WebExtension examples
  • You need to check if the old APIs have equivalents.
    • Search Keys was using nsIIOService which had no equivalent, but it was only used for ensure that a URL is indeed an URL, so I just did it another way (new URL = “<url>”). Thanks :MattN for the tip.
    • Another usage was for openUILinkIn, and there are similar-enough WebExtensions equivalents for this (tabs, windows).
    • (File a bug if an equivalent isn’t available, but first check for dupes)
  • Migrating an old project by another person is hard. I had to have several commits where I removed features, wither down the code to the bare minimum (my objective was just to add numbers for Google Search results), got it to work, tested, and then re-added support for Yahoo!, Bing, and even DuckDuckGo and Wikipedia.
  • Comments proved extremely helpful, in the absence of documentation.

I took about 2 days to port the add-on. Developing an add-on now has come a long way and is now much easier due to the presence of these tools (GitHub, devtools, etc.) as well as AMO being much improved ever since I started writing my first add-on (ViewAbout) almost a decade ago. Sadly, ViewAbout will unlikely be ported to WebExtensions, if ever. (Reasons are at that link)

This was tested on Firefox 55, exactly experiencing the difficulties that an add-on developer currently would face right now.

The only major caveat?

There were times when I set a breakpoint on a content script using Firefox’s Developer Tools (instantiated via web-ext). After I refresh the page, the extension would occasionally “disappear” from the devtools. I would then have to close Firefox, restart it via web-ext, re-set the breakpoint, then cross my fingers and hope that the devtools will stop at the required breakpoint.

In my experience, this has been straightforward, as the original add-on was fairly simple. I understand that for other complex add-ons, the porting process is much more complicated and take a much longer time.

What has your experience been like?

(Please note that this post does not discuss the pros and cons of whether Firefox 57 and later should use WebExtensions or not, hence cutting off legacy support, any comments on this will be removed.)


Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 200

di, 19/09/2017 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community News & Blog Posts Crate of the Week

This week's crate is rug, a crate providing arbitrary-precision integers, rationals and floating-point numbers, using GMP, MPFR and MPC. Thank you, Trevor Spiteri for the suggestion!

Submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

160 pull requests were merged in the last week

New Contributors
  • 42triangles
  • David Adler
  • Gauri Kholkar
  • Ixrec
  • J. Cliff Dyer
  • Michal Budzynski
  • rwakulszowa
  • smt923
  • Trevor Merrifield
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Upcoming Events

If you are running a Rust event please add it to the calendar to get it mentioned here. Email the Rust Community Team for access.

Rust Jobs

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

<heycam> one of the best parts about stylo has been how much easier it has been to implement these style system optimizations that we need, because Rust <heycam> can you imagine if we needed to implement this all in C++ in the timeframe we have <bholley> heycam: yeah srsly <bholley> heycam: it's so rare that we get fuzz bugs in rust code <bholley> heycam: considering all the complex stuff we're doing * heycam remembers getting a bunch of fuzzer bugs from all kinds of style system stuff in gecko <bholley> heycam: think about how much time we could save if each one of those annoying compiler errors today was swapped for a fuzz bug tomorrow :-) <njn> you guys sound like an ad for Rust

Conversation between some long-time Firefox developers.

Thanks to Josh Matthews for the suggestion.

Submit your quotes for next week!

This Week in Rust is edited by: nasa42 and llogiq.

Categorieën: Mozilla-nl planet

Mozilla Marketing Engineering & Ops Blog: MozMEAO SRE Status Report - September 19, 2017

di, 19/09/2017 - 02:00

Here’s what happened on the MozMEAO SRE team from September 5th - September 19th.

Current work MDN Migration to AWS Snippets
  • Snippets has been deployed to the Portland cluster, in addition to the Frankfurt and Tokyo clusters.

  • Some autoscaling inconsistencies between clusters were uncovered by Giorgos, which have been corrected via this PR.

  • The Snippets production traffic policy has been changed from latency-based to weighted between Frankfurt/Portland/Tokyo.

  • Giorgos also uncovered some Route 53 health check inconsistencies, and is working to make them more useful.

Upcoming Portland Deis 1 cluster decommissioning

The Deis 1 cluster in Portland decommissioning has been pushed out until next week due to support issues related to other applications.

Links
Categorieën: Mozilla-nl planet

Mike Hoye: Thirty-Five Minutes Ago

ma, 18/09/2017 - 21:36

Well, that’s done.

mhoye@ANGLACHEL:~/src/planet-content/branches/planet$ git diff | grep "^-name" | wc -l
401
mhoye@ANGLACHEL:~/src/planet-content/branches/planet$ git commit -am "The Great Purge of 2017"

Purging the Planet blogroll felt a lot like being sent to exorcise the ghosts of my own family estate. There were a lot of old names, old memories and more than a few recent ones on the business end of the delete key today.

I’ve pulled out all the feeds that errored out, everyone who isn’t currently involved in some reasonably direct capacity in the Mozilla project and a bunch of maybes that hadn’t put anything up since 2014, and I’d like the record to show that I didn’t enjoy doing any of that.

If you believe your feed was pulled in error, please file a bug so I can reinstate it directly.

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 18 Sep 2017

ma, 18/09/2017 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

The Firefox Frontier: Ad Blocker Roundup: 5 Ad Blockers That Improve Your Internet Experience

ma, 18/09/2017 - 19:46

Ad Blockers are a specific kind of software called an extension, a small piece of software that adds new features or functionality to Firefox. Using Ad Blockers, you can eliminate … Read more

The post Ad Blocker Roundup: 5 Ad Blockers That Improve Your Internet Experience appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

David Humphrey: Fixing a bug in TensorBoard

ma, 18/09/2017 - 17:56

This week I'm talking with my open source students about bugs. Above all, I want them to learn how The Bug is the unit of work of open source. Learning to orient your software practice around the idea that we incrementally improve an existing piece of code (or a new one) by filing, discussing, fixing, and landing bugs is an important step. Doing so makes a number of things possible:

  • it socializes us to the fact that software is inherently buggy: all code has bugs, whether we are aware of them yet or not. Ideally this leads to an increased level of humility
  • it allows us to ship something now that's good enough, and improve it as we go forward. This is in contrast to the idea that we'll wait until things are done or "correct."
  • it provides an interface between the users and creators of software, where we can interact outside purely economic relationships (e.g., buying/selling).
  • connected with the above, it enables a culture of participation. Understanding how this culture works provides opportunities to become involved.

One of the ways that new people can participate in open source projects is through Triaging existing bugs: testing if a bug (still) exists or not, connecting the right people to it, providing more context, etc.

As I teach these ideas this week, I thought I'd work on triaging a bug in a project I haven't touched before. When you're first starting out in open source, the process can be very intimidating and mysterious. Often I find my students look at what goes on in these projects as something they do vs. something I could do. It almost never feels like you have enough knowledge or skill to jump in and join the current developers, who all seem to know so much.

The reality is much more mundane. The magic you see other developers doing turns out to be indistinguishable from trial and error, copy/pasting, asking questions, and failing more than you succeed. It's easy to confuse the end result of what someone else does with the process you'd need to undergo if you wanted to do the same.

Let me prove it too you: let's go triage a bug.

TensorFlow and TensorBoard

One of the projects that's trending right now on GitHub is Google's open source AI and Machine Learning framework, TensorFlow. I've been using TensorFlow in a personal project this year to do real-time image classification from video feeds, and it's been amazing to work with and learn. There's a great overview video of the kinds of things Google and others are doing with TensorFlow to automate all kinds of things on the tensorflow.org web site, along with API docs, tutorials, etc.

TensorFlow is just under 1 million lines of C++ and Python, and has over 1,100 contributors. I've found the quality of the docs and tools to be first class, especially for someone new to AI/ML like myself.

One of those high quality tools is TensorBoard.

TensorBoard

TensorBoard is a Python-based web app that reads log data generated by TensorFlow as it trains a network. With TensorBoard you can visualize your network, understand what's happening with learning and error rates, and gain lots of insight into what's actually going on with your training runs. There's an excellent video from this year's TensorFlow Dev Summit (more videos at that link) showing a lot of the cool things that are possible.

A Bug in TensorBoard

When I started using TensorFlow and TensorBoard this spring, I immediately hit a bug. My default browser is Firefox, and here's what I saw when I tried to view TensorBoard locally:

Firefox running TensorBoard

Notice all the errors in the console related to Polymer and document.registerElement not being a function. It looks like an issue with missing support for Custom Elements. In Chrome, everything worked fine, so I used that while I was iterating on my neural network training.

Now, since I have some time, I thought I'd go back and see if this was fixable. The value of having the TensorBoard UI be web based is that you should be able to use it in all sorts of contexts, and in all sorts of browsers.

Finding/Filing the Bug

My first step was to see if this bug was known. If someone has already filed it, then I won't need to; it may even be that someone is already fixing it, or that it's fixed in an updated version.

I begin by looking at the TensorBoard repo's list of Issues. As I said above, one of the amazing things about true open source projects is that more than just the code is open: so too is the process by which the code evolves in the form of bugs being filed/fixed. Sometimes we can obtain a copy of the source for a piece of software, but we can't participate in its development and maintenance. It's great that Google has put both the code and entire project on GitHub.

At the time of writing, there are only 120 open issues, so one strategy would be to just look through them all for my issue. This often won't be possible, though, and a better approach is to search the repo for some unique string. In this case, I have a bunch of error messages that I can use for my search.

I search for document.registerElement and find 1 issue, which is a lovely outcome:

Searching GitHub for my issue

Issue #236: tensor board does not load in safari is basically what I'm looking for, and discusses the same sorts of errors I saw in Firefox, but in the context of Safari.

Lesson: often a bug similar to your own is already filed, but may be hiding behind details different from the one you want to file. In this case, you might unknowingly file a duplicate (dupe), or add your information to an existing bug. Don't be afraid to file the bug: it's better to have it filed in duplicate than for it to go unreported.

Forking and Cloning the repo

Now that I've found Issue #236, I have a few options. First, I might decide that having this bug filed is enough: someone on the team can fix it when they have time. Another possibility is that I might have found that someone was already working on a fix, and a Pull Request was open for this Issue, with code to address the problem. A third option is for you to fix the bug yourself, and this is the route I want to go now.

My first step is to Fork the TensorBoard repo into my own GitHub account. I need a version of the code that I can modify vs. just read.

Once that completes, I'll have an exact copy of the TensorBoard repo that I control, and which I can modify. This copy lives on GitHub. To work with it on my laptop, I'll need to Clone it to my local computer as well, so that I can make and test changes

Setting up TensorBoard locally

I have no idea how to run TensorBoard from source vs. as part of my TensorFlow installation. I begin by reading their README.md file. In it I notice a useful discussion within the Usage section, which talks about how to proceed. First I'll need to install Bazel.

Lesson: in almost every case where you'll work on a bug in a new project, you'll be asked to install and setup a development environment different from what you already have/know. Take your time with this, and don't give up too easily if things don't go as smoothly as you expect: many fewer people test this setup than do the resulting project it is meant to create.

Bazel is a build/test automation tool built and maintained by Google. It's available for many platforms, and there are good instructions for installing it on your particular OS. I'm on macOS, so I opt for the Homebrew installation. This requires Java, which I also install.

Now I'm able to try and do the build I follow the instructions in the README, and within a few seconds get an error:

$ cd tensorboard $ bazel build tensorboard:tensorboard Extracting Bazel installation... ............. ERROR: /private/var/tmp/_bazel_humphd/d51239168182c03bedef29cd50a9c703/external/local_config_cc/BUILD:49:5: in apple_cc_toolchain rule @local_config_cc//:cc-compiler-darwin_x86_64: Xcode version must be specified to use an Apple CROSSTOOL. ERROR: Analysis of target '//tensorboard:tensorboard' failed; build aborted. INFO: Elapsed time: 8.965s

This error is a typical example of the kind of problem one encounters working on a new project. Specifically, it's OS specific, and relates to a first-time setup issue--I don't have XCode setup properly.

I spend a few minutes searching for a solution. I look to see if anyone has filed an issue with TensorBoard on GitHub specifically about this build error--maybe someone has had this problem before, and it got solved? I also Google to see if anyone has blogged about it or asked on StackOverflow: you are almost never the only person who has hit a problem.

I find some help on StackOverflow, which suggests that I don't have XCode properly configured (I know it's installed). It suggests some commands I can try to fully configure things, none of which solve my issue.

It looks like it wants the full version of XCode vs. just the commandline tools. The full XCode is massive to download, and I don't really want to wait, so I do a bit more digging to see if there is any other workaround. This may turn out to be a mistake, and it might be better to just do the obvious thing instead of trying to find a workaround. However, I'm willing to spend an additional 20 minutes of research to save hours of downloading.

Some more searching reveals an interesting issue on the Bazel GitHub repo. Reading through the comments on this issues, it's clear that lots of other people have hit this--it's not just me. Eventually I read this comment, with 6 thumbs-up reactions (i.e., some agreement that it works):

just for future people. sudo xcode-select -s /Applications/Xcode.app/Contents/Developer could do the the trick if you install Xcode and bazel still failing.

This allows Bazel to find my compiler and the build to proceed further...before stopping again with a new error: clang: error: unknown argument: '-fno-canonical-system-headers'.

This still sounds like a setup issue on my side vs. something in the TensorBoard code, so I keep reading. This discussion on the Bazel Google Group seems useful: it sounds like I need to clean my build and regenerate things, now that my XCode toolchain is properly setup. I do that, and my build completes without issue.

Lesson: getting this code to build locally required me to consult GitHub, StackOverflow, and Google Groups. In other words, I needed the community to guide me via asking and answering questions online. Don't be afraid to ask questions in public spaces, since doing so leaves traces for those who will follow in your footsteps.

Running TensorBoard

Now that I've built the source, I'm ready to try running it. TensorBoard is meant to be used in conjunction with Tensorflow. In this case, however, I'm interested in using it on its own, purely for the purpose of reproducing my bug, and testing a fix. I don't actually
care about having Tensorflow and real training data to visualize. I notice that the DEVELOPMENT.md file seems to indicate that it's possible to fake some training data and use that in the absence of a real TensorFlow project. I try what it suggests, which fails:

... line 40, in create_summary_metadata metadata = tf.SummaryMetadata( AttributeError: 'module' object has no attribute 'SummaryMetadata' ERROR: Non-zero return code '1' from command: Process exited with status 1.

From having programmed with TensorFlow before, I assume here that tf (i.e. the TensorFlow Python module) is missing an expected attribute, namely, SummaryMetadata. I've never heard of it, but Google helps me locate the necessary API docs.

This leads me to conclude that my installed version of TensorFlow (I installed it 4 months earlier) might not have this new API, and the code in TensorBoard now expects it to exist. The API docs I'm consulting are for version 1.3 of the TensorFlow API. What do I have installed?

$ pip search tensorflow ... INSTALLED: 1.2.1 LATEST: 1.3.0

Maybe upgrading from 1.2.1 to 1.3.0 will solve this? I update my laptop to TensorFlow 1.3.0 and am now able to generate the fake data for TensorBoard.

Lesson: running portions of a larger project in isolation often means dealing with version issues and manually installing dependencies. Also, sometimes dependencies are assumed, as was TensorFlow 1.3 in this case. Likely the TensorBoard developers all have TensorFlow installed and/or are developing it at the same time. In cases like this a README may not mention all the implied dependencies.

Using this newly faked data, I try running my version of TensorBoard...which again fails with a new error:

... from tensorflow.python.debug.lib import grpc_debug_server ImportError: cannot import name grpc_debug_server ERROR: Non-zero return code '1' from command: Process exited with status 1.

After some more searching, I find a 10-day old open bug in TensorBoard itself. This particular bug seems to be another version skew issue between dependencies, TensorFlow, and TensorBoard. The module in question, grpc_debug_server, seems to come from TensorFlow. Looking at the history of this file, the code is pretty new, making me wonder if it is once again that I'm running something with an older API. A comment in this issue gives a clue as to a possible fix:

FYI, I ran into the same problem, and I did pip install grpc which seemed to fix the problem.

I give this a try, but TensorBoard still won't run. Further on in this issue I read another comment indicating I need the "nightly version of TensorFlow." I've never worked with the nightly version of TensorFlow before (didn't know such a thing existed), and I have no idea how to install that (the comment assumes one knows how to do this).

A bit more searching reveals the answer, and I install the nightly version:

$ pip install tf-nightly

Once again I try running my TensorBoard, and this time, it finally works.

Lesson: start by assuming that an error you're seeing has been encountered before, and go looking for an existing issue. If you don't find anything, maybe you are indeed the first person to hit it, in which case you should file a new issue yourself so you can start a discussion and work toward a fix. Everyone hits these issues. Everyone needs help.

Reproducing the Bug

With all of the setup now behind us, it's time to get started on our actual goal. My first step in tackling this bug is to make sure I can reproduce it, that is, make sure I can get TensorBoard to fail in Safari and Firefox. I also want to confirm that things work in Chrome, which would give me some assurance that I've got a working source build.

Here's my local TensorBoard running in Chrome:

TensorBoard on Chrome

Next I try Safari:

TensorBoard on Safari

And...it works? I try Firefox too:

TensorBoard on Firefox

And this works too. At this point I have two competing emotions:

  1. I'm pleased to see that the bug is fixed.
  2. I'm frustrated that I've done all this work to accomplish nothing--I was hoping I could fix it.
The Value of Triaging Bugs

It's kind of ironic that I'm upset about this bug being fixed: that's the entire point of my work, right? I would have enjoyed getting to try and fix this myself, to learn more about the code, to get involved in the project. Now I feel like I have nothing to contribute.

Here I need to challenge my own feelings (and yours too if you're agreeing with me). Do I really have nothing to offer after all this work? Was it truly wasted effort?

No, this work has value, and I have a great opportunity to contribute something back to a project that I love. I've been able to discover that a previous bug has been unknowingly fixed, and can now be closed. I've done the difficult work of Confirming and Triaging a bug, and helping the project to close it.

I leave a detailed comment with my findings. This then causes the bug to get closed by a project member with the power to do so.

So the result of my half-day of fighting with TensorBoard is that a bug got closed. That's a great outcome, and someone needed to do this work in order for this to happen. My willingness to put some effort into it was key. It's also paved the way for me to do follow-up work, if I choose: my computer now has a working build/dev environment for this project. Maybe I will work on another bug in the future.

There's more to open source than fixing bugs: people need to file them, comment on them, test them, review fixes, manage them through their lifetime, close them, etc. We can get involved in any/all of these steps, and it's important to realize that your ability to get involved is not limited to your knowledge of how the code works.

Categorieën: Mozilla-nl planet

Rabimba: LinuxCon China 2017: Trip Report

ma, 18/09/2017 - 07:56

Linux Foundation held a combination of three events in China as part of their foray into Asia early this year. It was a big move for them since this was supposed to be the first time Linux Foundation would hold an event in Asia.I was invited to present a talk on Hardening IoT endpoints. The event was held in Beijing, and since I have never been to Beijing before I was pretty excited for the talk. However, it turned out the journey is pretty long and expensive. Much more than a student like me can hope to bear. Normally I represent Mozilla in such situations, but the topic of the talk was too much into security and not aligned much with the goals of Mozilla at that moment. Fortunately, Linux Foundation gave me a Scholarship to come and speak at LinuxCon China which enabled me to attend LinuxCon and the awesome team at Mozilla TechSpeakers including Michael Ellis and Havi helped me get ready for the talk.

The event was held at China National Convention Center. It's a beautiful and enormous convention center just middle of Beijing. One of the big problems I soon realized after reaching China is, most of the services in my mobile was not working. The great wall (the firewall not the actual one) was preventing most of the Google services I had, unfortunately, that included two apps I was heavily relying on. Google Maps and Google Translate. There, of course, is a local alternative to Google Maps which is Baidu Maps, but since the interface itself also was in Chinese, it wasn't of much help to me. Fortunately, my VPN setup came into my rescue and that has been my source of relief for the next two days in China.
Pro Tip: If you have to goto china and you rely on some form of service which might be blocked in China. It's better to use a good VPN. One you know will work there or roll your own. I had rolled my own since my commercial vpn also was blocked there.
The day started with Linus Trovalds having an open discussion regarding which way Linux is moving. And with very interesting aspects and views.
One of the recurring theme in the discussion, which kept coming up was regarding how the core linux maintainer circle worked. And why it was being relied on only one those very few people. The reply was most stimulating.
The very interesting quote from him was"10 top maintainers is very strong team in an open source project" @Linus__Torvalds #linuxcon @linuxfoundation pic.twitter.com/B6TQihUTce— Rabimba Karanjai (@rabimba) June 20, 2017Among the other talks I really liked:

The other talks were interesting as well. I would have really liked to attend three more talks, namely by Greg on serverless computing on edge, by Swati on Kubernates and by Kai Zhang on container-based virtualization, but that one clashed with my own talk.

My talk was on the second day and on a relatively good time, which was especially important for me as the conference wifi was the only one where I could work on my slides.
Lesson Learned: Don't rely on Google Slides in China
Fortunately courtesy to my vpn I was able to work on it and have a backup local copy ready for the talk.
That room was pretty big, didn't see this comingWhat I did not anticipate earlier was how eager people were for the talk. In a nutshell this was how the room was looking when I took the podium.

My first reaction was: Wow that's a lot of people! Guess they are really interested in the talk!
And then: Shit! I hope my talk is as interesting as all of the super industry relevant talks going on around me in all other rooms.

Fortunately, the talk went pretty well. I always judge my talk based on how many queries, questions I get after the talk and also how many reactions in twitter. Judging on the number of queries afterwards I guessed atleast it wasn't that bad. I was though super disappointed on the complete radio silence in twitter regarding my talk. Only to realize later that twitter is also blocked in China.

To Do: Next time come up with better ways to track engagement.

My only complain here was, normally every Linux Foundation conference records your talk. LinuxCon didn't. Though they did upload all our slides, so if you want to go over a textual version of what I presented, have a sneak peak here. I will be all ears to listen to your feedback

SecurityPI - Hardening your IoT endpoints in Home. from LinuxCon ContainerCon CloudOpen China

This would have normally finished my recount of the event, but this time it didn't I finally went to a BoF session on Fedora and CentOS, and ended up having a 2 hour long discussion on the various issues Mozilla and Fedora communities face and pain points with Brian Exelbierd. We temporarily suspended the discussion with no clear path to a solution but with a notion to touch base with each other again on it.

Conclusion: LinuxCon was a perfect example of how to handle and manage a huge footfall with a multilingual audience and still make the conference good. The quality of the talks was astounding as well as speakers. I really loved my experience there. Made some great friends (I am looking at you Greg and Swati :D), had some awesome conversation.

And did I mention the speakers at the day caught up and decided we needed a memoir for us? Which happens to be us discussing everything related to Linux to Mozilla to security in Forbidden City
That in a nutshell were the speakersLike I said, one hell of a conference.
PS: If you want to talk to me about anything related to the talk, don't hesitate to get in touch using either my email or twitter.
Categorieën: Mozilla-nl planet

The Rust Programming Language Blog: impl Future for Rust

ma, 18/09/2017 - 02:00

The Rust community has been hard at work on our 2017 roadmap, but as we come up on the final quarter of the year, we’re going to kick it into high gear—and we want you to join us!

Our goals for the year are ambitious:

To finish off these goals, we intend to spend the rest of the year focused purely on “implementation” work—which doesn’t just mean code! In particular, we are effectively spinning down the RFC process for 2017, after having merged almost 90 RFCs this year!

So here’s the plan. Each Rust team has put together several working groups focused on a specific sub-area. Each WG has a leader who is responsible for carving out and coordinating work, and a dedicated chat channel for getting involved. We are working hard to divvy up work items into many shapes and sizes, and to couple them with mentoring instructions and hands-on mentors. So if you’ve always wanted to contribute to Rust but weren’t sure how, this is the perfect opportunity for you. Don’t be shy—we want and need your help, and, as per our roadmap, our aim is mentoring at all levels of experience. To get started, say hello in the chat rooms for any of the work groups you’re interested in!

A few points of order

There are a few online venues for keeping in the loop with working group activity:

  • There is a dedicated Gitter community with channels for each working group, as well as a global channel for talking about the process as a whole, or getting help finding your way to a working group. For those who prefer IRC, a good bridge is available!

  • The brand-new findwork site, which provides an entry point to a number of open issues across the Rust project, including those managed by working groups (see the “impl period” tab). Thanks, @nrc, for putting this together!

We also plan two in-person events, paired with upcoming Rust conferences. Each of them is a two-day event populated in part by Rust core developers; come hang out and work together!

As usual, all of these venues abide by the Rust code of conduct. But more than that: this “impl period” is a chance for us all to have fun collaborating and helping each other, and those participating in the official venues are expected to meet the highest standards of behavior.

The working groups

Without further ado, here’s the initial lineup! (A few more working groups are expected to arise over time.)

If you find a group that interests you, please say hello in the corresponding chat room!

Compiler team WG-compiler-errors Make Rust's error messages even friendlier. Learn more Chat WG-compiler-front Dip your toes in with parsing and syntax sugar. Learn more Chat WG-compiler-middle Implement features that involve typechecking. Learn more Chat WG-compiler-traits Want generic associated types? You know what to do. Learn more Chat WG-compiler-incr Finish incremental compilation; receive undying love. Learn more Chat WG-compiler-nll Delve into the bowels of borrowck to slay the beast: NLL! Learn more Chat WG-compiler-const Const generics. Enough said. Learn more Chat Libs team WG-libs-blitz Help finish off the Blitz before all the issues are gone! Learn more Chat WG-libs-cookbook Work on bite-sized examples to get folks cooking with Rust. Learn more Chat WG-libs-guidelines Take the wisdom from the Blitz and pass it on. Learn more Chat WG-libs-simd Provide access to hardware parallelism in Rust! Learn more Chat WG-libs-openssl Want better docs for openssl? So do we. Learn more Chat WG-libs-rand Craft a stable, core crate for randomness. Learn more Chat Docs team WG-docs-rustdoc Help make docs beautiful for everyone! Learn more Chat WG-docs-rustdoc2 Get in on a bottom-up revamp of rustdoc! Learn more Chat WG-docs-rbe Teach others Rust in the browser. Learn more Chat WG-docs-checklist Help finish the standard library documentation! Learn more Chat Dev tools team WG-dev-tools-rls Help make Rust's IDE experience first class. Learn more Chat WG-dev-tools-vscode Improve Rust's IDE experience for VSCode. Learn more Chat WG-dev-tools-clients Implement new RLS clients: Atom, Sublime, Visual Studio... Learn more Chat WG-dev-tools-IntelliJ Polish up an already-rich Rust IDE experience. Learn more Chat WG-dev-tools-rustfmt Make Rust's code the prettiest! Learn more Chat WG-dev-tools-rustup Make Rust's first impression even better! Learn more Chat WG-dev-tools-clippy It looks like you're trying to write a linter. Want help? Learn more Chat WG-dev-tools-bindgen Make FFI'ing to C and C++ easy, automatic, and robust! Learn more Chat Cargo team WG-cargo-native Let's make native dependencies as painless as we can. Learn more Chat WG-cargo-registries Going beyond crates.io to support custom registries. Learn more Chat WG-cargo-pub-deps Teach Cargo which of your dependencies affects your users. Learn more Chat WG-cargo-integration How easy can it be to use Cargo with your build system? Learn more Chat Infrastructure team WG-infra-crates.io Try your hand at a production Rust web app! Learn more Chat WG-infra-perf Let's make sure Rust gets faster. Learn more Chat WG-infra-crater Regularly testing the compiler against the Rust ecosystem. Learn more Chat WG-infra-secure Help us implement best practices for Rust's infrastructure! Learn more Chat WG-infra-host Managing the services that keep the Rust machine running. Learn more Chat WG-infra-rustbuild Streamline the compiler build process. Learn more Chat Core team WG-core-site The web site is getting overhauled; help shape the new content! Learn more Chat
Categorieën: Mozilla-nl planet

Bryce Van Dyk: Why Does Firefox Use e4 and e5 Values to Fill Memory?

zo, 17/09/2017 - 16:58

I was once talking to some colleagues about a Firefox crash bug. As we gazed at the crash report, one leaned over and pointed at the value in one of the CPU registers: 0xe5e5e5e9. “Freed memory,” he sagely indicated: “e5”.

Magic debug numbers

Using special numbers to indicate something in memory is an old trick. Wikipedia even has Wikipedia even has famous examples of such things! Neato! These numbers are often referred to as “poison” or “junk” in the context of filling memory (because they’re supposed to cause the program to fail, or be meaningless garbage).

Mozilla uses this trick (and the “poison” terminology) in Firefox debug builds to indicate uninitialized memory (e4), as well as freed memory (e5). Thus the presence of these values in a crash report, or other failure report, indicate that something has gone wrong with memory handling. But why e4 and e5?

jemalloc

jemalloc is a general purpose implementation of malloc. Firefox utilizes a modified version of jemalloc to perform memory allocation. There's a pretty rich history here, and it would take another blog post to cover how and why Mozilla use jemalloc. So I'm going to hand wave and say that it is used, and the reasons for doing so are reasonable.

jemalloc can use magic/poison/junk values when performing malloc or free. However, jemalloc will use the value a5 when allocating, and 5a when freeing, so why do we see something different in Firefox?

A different kind of poison

When using poison values, it's possible for the memory with these values to still be used. The hope is that when doing so the program will crash and you can see which memory is poisoned. However, with the 5a value in Firefox there was concern that 1) the program would not crash, and 2) as a result, it could be exploited: see this bug.

As a result of these concerns, it was decided to use the poison values we see today. The code that sets these values has undergone some changes since the above bug, but the same values are used. If you want to take a look at the code responsible here is a good place to start.

Categorieën: Mozilla-nl planet

Mitchell Baker: Busting the myth that net neutrality hampers investment

za, 16/09/2017 - 06:28

This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas.

I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers.

Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States.

The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population.

At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike.

Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use:


(Video courtesy: GSMA)

If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here.

You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Busting the myth that net neutrality hampers investment

za, 16/09/2017 - 06:03

This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas.

I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers.

Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States.

The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population.

At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike.

Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use:


(Video courtesy: GSMA)

If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here.

You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it.

The post Busting the myth that net neutrality hampers investment appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Air Mozilla: Webdev Beer and Tell: September 2017, 15 Sep 2017

vr, 15/09/2017 - 20:00

 September 2017 Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...

Categorieën: Mozilla-nl planet

David Humphrey: Why Good-First-Bugs often aren't

vr, 15/09/2017 - 18:45

Let me start by saying that I'm a huge fan of open source projects putting a Good-First-Bug type label on issues. From my own experience over the past decade trying to get students engaged in open source projects, it's often a great way to quickly find entry points for new people. Right now I've got 40 students learning open source with me at Seneca, and because I want to get them all working on bugs ASAP, you better believe that I'm paying close attention to good-first-bug labels!

Maintainers

There are a few ways that we tend to interact with good-first-bugs. First, we have project maintainers who add the label when they think they see something that might be a good fit for someone new. I've been this person, and I know that it takes some discipline to not fix every bug. To be honest, it's faster and easier to just fix small things yourself. It's also going to mean you end up having to fix everything yourself--you won't grow new contributors this way.

What you need to do instead is to write large amounts of prose of the type "Here's what you need to do if you're interested in fixing this". You need sample code, links to relevant files, screenshots, etc. so that someone who lands in this bug can readily assess whether their current skill level (or aspirational skill level), and the bug's requirements, meet.

Sometimes maintainers opt not to do this, and instead say, "I'd be willing to mentor this." The problem with this approach, in my experience, is that it becomes a kind of debt with which you saddle your future self. Are you sure you'll want to mentor this bug in 2 years, when it's no longer on your roadmap? You'd be better to "mentor" the bug upfront, and just spell out what has to happen in great detail: "Do this, this, and this." If you can't do that, the reality is it's not a good-first-bug.

New Contributors

The second way we encounter good-first-bugs is as someone looking for an opportunity to contribute. I make a habit of finding/fixing these in various projects so that I can use real examples to show my students the steps. I also tag along with my students as they attempt them, and I've seen it all. It's interesting what you encounter on this side of things. Sometimes it goes exactly as you'd hope: you make the fix and the patch is accepted. However, more often then not you run into snags.

First, before you even get going on a fix, finding a bug that isn't already being worked on can be hard. A lot of people are looking for opportunities to get started, and when you put up a sign saying "Start Here," people will! Read through the comments on many good-first-bugs and you'll find an unending parade of "I'd like to work on this bug!" and "Can you assign this to me?" followed by "Are you still working on this?" and "I'm new, can you help me get started?". That stream of comments often repeats forever, leaving the project maintainers frustrated, the contributors lost, and the bug untouched.

Expiry Dates

Once people do get started on a bug, another common problem I see is that the scope of the bug has shifted such that the problem/fix described no longer makes sense. You see a lot of responses like this: "Thanks for this fix, but we've totally refactored this code, and it's not necessary any more. Closing!" This doesn't feel great, or make you want to put more effort into finding something else to do.

The problem here wasn't that the bug was wrong...when filed. The bug has become obsolete over time. Good-first-bugs really need an expiry date. If a project isn't triaging its good-first-bugs on a somewhat regular basis, it's basically going to end up in this state eventually, with some or all of them being useless, and therefore bad-first-bugs. You're better off closing bugs like this and having no good-first-bugs listed, than to have 50 ancient bugs that no one on the project cares about, wants to review, or has time to discuss.

Good First Experience

This week I've been thinking a lot about ways to address some of the problems above. In their lab this week, I asked my students to build Firefox, and also to make some changes to the code. I had a few goals with this:

  • Build a large open source project to learn about setting up dev environments, obtaining source code, build systems, etc.
  • Gain some experience making a change and rebuilding Firefox, to prove to themselves that they could do it and to remove some of the mystery around how one does this.
  • Learn how to start navigating around in large code, see how things are built (e.g., Firefox uses JS and CSS for its front-end).
  • Have some fun doing something exciting and a bit scary

I've done this many times in the past, and often I've gone looking for a simple good-first-bug to facilitate these goals. This time I wanted to try something different. Instead of a good-first-bug, I wanted what I'll call a "Good First Experience."

A Good First Experience tries to do the following:

  • It's reproducible by everyone. Where a good-first-bug is destroyed in being fixed, a good-first-experience doesn't lose its potential after someone completes it.
  • It's not tied to the current state of the project, and therefore doesn't become obsolete (as quickly). Where a good-first-bug is always tied to the project's goals, coding practices, and roadmap, a good-first-experience is independent of the current state of the project.
  • It's meant to be fun, exploratory, and safe. Where a good-first-bug is about accomplishing a task, and is therefore defined and limited by that task, a good-first-experience can be the opposite: an unnecessary change producing an outcome whose value is measured by the participate vs the project.
Toward a Good First Experience with Firefox

I reached out to a half-dozen Mozilla colleagues for ideas on what we could try (thanks to all who replied). I ended-up going with some excellent suggestions from Blake Winton (@bwinton). Blake has a history of being whimsical in his approach to his work at Mozilla, and I think he really understood what I was after.

Based on his suggestions, I gave the students some options to try:

  • In browser/base/content/browser.js change the function OpenBrowserWindow to automatically open cat GIFs. You can alter the code like so:
function OpenBrowserWindow(options) { return window.open("http://www.chilloutandwatchsomecatgifs.com"); }
  • Look at the CSS in browser/base/content/browser.css and try changing some of the colours.

  • Modify the way tabs appear by playing with CSS in browser/themes/shared/tabs.inc.css, for example: you could alter things like min-height.

  • You could try adding a background: url(http://i.imgur.com/UkT7jcm.gif); to the #TabsToolbar in browser/themes/windows/browser.css to add something new

  • Modify the labels for menu items like "New Window" in browser/locales/en-US/chrome/browser/browser.dtd to something else.

None of these changes are necessary, prudent, or solving a problem. Instead, they are fun, exploratory, and simple. Already students are having some success, which is great to see.

Example of what students did

Nature via National Park vs. Wilderness

I was reflecting that the real difference between a good-first-experience and a real bug is a lot like experiencing nature by visiting a National Park vs. setting out in the wilderness. There isn't a right or wrong way to do this, and both have obvious advantages and disadvantages. However, what National Parks do well is to make the experience of nature accessible to everyone: manicured paths, maps with established trails to follow, amenities so you can bring your family, information. It's obviously not the same as cutting a trail into a forest, portaging your canoe between lakes, or hiking on the side of a mountain. But it means that more people can try the experience of doing the real thing in relative safety, and without a massive commitment of time or effort. It's also a mostly self-guided experience vs. something you need a guide (maintainer) to accomplish. In the end, this experience might be enough for many people, and will help bring awareness and an enriching experience. For others, it will be the beginning of bolder outings into the unknown.

I don't think my current attempt represents a definitive good-first-experience in Mozilla, but it's got me thinking more about what one might look like, and I wanted to get you thinking about them too. I know I'm not alone in wanting to bring students into projects like Mozilla and Firefox, and needing a repeatable entry point.

Categorieën: Mozilla-nl planet

The Firefox Frontier: Put your multiple online personalities in Firefox Multi-Account Containers

do, 14/09/2017 - 22:40

Our new Multi-Account Containers extension for Firefox means you can finally wrangle multiple email/social accounts. Maybe you’ve got two Gmail or Instagram or Twitter or Facebook accounts (or a few … Read more

The post Put your multiple online personalities in Firefox Multi-Account Containers appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Air Mozilla: Measuring the Subjective: The Performance Dashboard with Estelle Weyl

do, 14/09/2017 - 19:00

 The Performance Dashboard with Estelle Weyl Performance varies quite a bit depending on the site, the environment and yes, the user. And users don't check your performance metrics. Instead, they perceive...

Categorieën: Mozilla-nl planet

Air Mozilla: Measuring the Subjective: The Performance Dashboard with Estelle Weyl

do, 14/09/2017 - 19:00

 The Performance Dashboard with Estelle Weyl Performance varies quite a bit depending on the site, the environment and yes, the user. And users don't check your performance metrics. Instead, they perceive...

Categorieën: Mozilla-nl planet

About:Community: Firefox 56 new contributors

do, 14/09/2017 - 18:13

With the upcoming release of Firefox 56, we are pleased to welcome the 37 developers who contributed their first code change to Firefox in this release, 29 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Sep. 14, 2017

do, 14/09/2017 - 18:00

Reps Weekly Meeting Sep. 14, 2017 This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Sep. 14, 2017

do, 14/09/2017 - 18:00

Reps Weekly Meeting Sep. 14, 2017 This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

Pagina's