mozilla

Mozilla Nederland Logo De Nederlandse Mozilla gemeenschap

Mozilla, Duck Dynasty, Chick-fil-A, and the politicization of everything - Daily Caller

Nieuws verzameld via Google - ti, 22/04/2014 - 20:18

Daily Caller

Mozilla, Duck Dynasty, Chick-fil-A, and the politicization of everything
Daily Caller
Unfortunately, this rule of etiquette that has governed civil society for ages seems to be quickly evaporating in the world of commerce, as highlighted by the now notorious case of Mozilla CEO Brendan Eich. This impolite seed should be quickly uprooted ...
Freedom to marry, freedom to disagree: a public statementWashington Post
Freedom to Marry, Freedom to DissentRealClearPolitics
There Should Be No 'Punishment' Phase When a Culture War EndsReason (blog)

alle 4 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Manish Goregaokar: I've been selected for Google Summer of Code 2014!

Mozilla planet - ti, 22/04/2014 - 12:06
I've been selected for GSoC 2014!

My project is to implement XMLHttpRequest in Servo (proposal), under Mozilla (mentored by the awesome Josh Matthews)

Servo is a browser engine written in Rust. The Servo project is basically a research project, where Mozilla is trying to rethink the way browser engines are designed and try to make one which is more memory safe (The usage of Rust is very crucial to this goal), and much more parallel. If you'd like to learn more about it, check out this talk or join #servo on irc.mozilla.org.

What is GSoC?Google Summer of Code is a program by Google that helps jumpstart involvement in open source amongst students. Organizations are invited to float their own open source projects, and students float project proposals. If selected, you get to code the project over the summer, working closely with the mentor. It's supposed to be a great experience, and I'm glad I'll get to be a part of it this year!
Who else got selected?
One purpose of this post was to recognize all my friends and college-mates who got selected:

Mozillia India friendsOther IITB-ians
Categorieën: Mozilla-nl planet

Manish Goregaokar: Getting started with bug-squashing for Firefox

Mozilla planet - ti, 22/04/2014 - 11:20
So over the past few months I've been trying to contribute a bit to Mozilla (mainly Firefox). Last August there was a MozBoot session at IIT Bombay which helped me get over the learning curve.

First off, a big thanks to @Debloper (and @hardfire) for showing me the basics. The process is intimidating, though once you've done it with help, it becomes pretty natural. These Mozilla reps got me past that intimidation point, so I'm really grateful for that.

This post is basically an tutorial on how to get started. It's basically an in-depth version of this tutorial, which I feel misses a few things.

Note that I am still a beginner at this, comments on how to improve this post/my workflow appreciated.

Ok, let's get started.

Step 1: Identifying a bug you want to fixFirstly, make an account on https://bugzilla.mozilla.org/. You'll need it later. Browse the bug lists on the site, looking for bugs that seem fixable. Look for bugs marked as "good first bug", which have a status of "NEW".
Of course, this is a bit cumbersome to do and there are a lot of  bugs which are nontrivial or have a lot of discussion baggage which you may not want to go through. Fortunately, there are some tools out there that greatly help in searching for bugs.

Firstly, there's What Can I Do For Mozilla?. This is an interactive questionnaire that helps you find out which portions of Mozilla or Firefox you may be able to comfortably contribute to. Note that this is not just Firefox, though if you select the HTML or JS categories you will be presented with the Firefox subcategory which contains various entries.

This doesn't help find bugs as much as it helps you find the areas of the codebase that you might want to look at.

However, there is a different tool that is built specifically for this purpose; to look for easy bugs given one's preferences and capabilities. It's called Bugs Ahoy, and it lets you tick your preferences and programming languages to filter for bugs. It also has two insanely useful options, one that lets you filter out assigned bugs, and one that tells it to look for "good first bugs" ("simple bugs"). "Good first bug"s on Bugzilla are easy bugs which are kept aside for new users to try their hand at. There is a mentor for these bugs, who is a very active community member or employee. These mentors help you through the rest of the process, from where you need to look in the code to how to put up a patch. I've found that the mentors are very friendly and helpful, and the experience of being mentored on a bug is rather enjoyable.

Make sure the bug isn't assigned to anyone, and look through the comments and attachments for details on the status of the bug. Some bugs are still being discussed, and some bugs are half-written (it's not as easy to use these for your first bug). If you need help on choosing a bug, join #introduction on irc.mozilla.org. There are lots of helpful people out there who can give feedback on your chosen bug, and help you get started.

Step 2: Finding the relevant bits of codeIf this is a mentored bug, you usually can ask the mentor in a comment on the bug for help. Be sure to get it assigned to you! If the mentor doesn't respond in a few days, use the needinfo box at the bottom of the page:

Type the username (usually preceded by a colon somewhere in the full name string), and a suggestion box should pop up with various users. Pick your mentor out from the list, and ask for help in the comment box.
If you want to look for the code yourself, Mozilla Cross-Reference is a great tool. For Firefox, you probably want the mozilla-central subtree. With MXR, you can easily search the codebase for text, variable names, and regexes.
For most UI changes, you can track the code down by first looking for nearby strings.  For example, if you want to look at the code for the where-do-I-save-downloads preference which is preceded with the text "Save files to", the search result leads to a dtd file, which defines the entity saveTo.label as the string. (Remember, all displayed strings will be in a localization file). Searching for saveTo.label turns up main.xul. Now that you've found this, you can dig deeper by looking at the event handling and figuring out where the relevant javascript is, or you can look around this same file and figure out how it works, depending on what you want to fix.
I've not really made any changes to the C++ yet, only the toolkit and UI javascript, so I can't comment on how one can find the C++ code relevant to a bug. But you can always ask around in IRC or ask your mentor (if any) for help.

Step 3: Downloading and building the codeSee also: Simple Firefox build
Not all bugs need a build. Some are quite easy to do without having a full copy of the code or a build, and while you'll eventually want to have both of these, it is possible to hold this off for a while, depending on the bug. While it's easier to create patchfiles when the system is all set up, I will address patching without the full code in the next section.

Downloading can be done in two ways. Both require Mercurial to be installed (sudo apt-get mercurial works).



One way is to simply hg clone https://hg.mozilla.org/mozilla-central. This will download the full repository. However, if you don't think your internet connection will be stable, download the mozilla-central bundle from here and follow the steps given there. Note that Mercurial is a bit different from Git, so you may wish to read up on the basics.

To build firefox , you first need to setup your build environment. If you already have Mercurial and Python installed on Linux/OSX, the build environment setup is simply ./mach bootstrap, run from the root directory of the cloned repository. For setting it up on Windows or for other corner cases, go here.

Once done, go to the root directory of the firefox code and run ./mach build. After your first build, you can run incremental builds (that only build the files you ask it to, and rebuilds any files depending on it) by using ./mach build <list of filepaths>, eg ./mach build browser/components/preferences/. You can specify both folders and files to the incremental build.

Note that for some javascript files, you have to build their containing directory — so if your changes aren't getting reflected in the incremental build, try building the directory they are in.


Step 4: Getting a patchSee also: How to submit a patchMercurial Queues
So by this point you will have figured out the fix and modified the code so that you have a partial (for a multifaceted bug) or full fix of the bug. At this point you can submit the patch for review. For this, you need to have a patch to submit first!

Creating patches with hg
If you have the full cloned repository, first add these lines to your ~/.hgrc to enable the mercurial queues extension with the proper settings.
[ui]
username = Firstname Lastname

[defaults]
qnew = -Ue

[extensions]
mq =

[diff]
git = 1
unified = 8
showfunc = 1


Once done, navigate to the firefox source tree and run hg qqueue -c somequeuenamehere. This will create a named patch queue that you can work on.

Now, run hg qnew patchname.patch and then hg qpush patchname.patch. This creates a new patch by that name in the .hg/patches-queuename folder, and pushes it onto the curretly applied stack of patches. You can update its contents with the changes made to the code by  hg qrefresh or simply hg qref.  This patch is the one that you can submit in step 5.

When you run hg qnew, it will ask you to enter a commit message. Write the bug name and a short description of the patch ("Bug 12345 - Frob the baz button when foo happens"), and add a ";r=nameofreviewer". In case of mentored bugs, the uername of the mentor will be your reviewer. If not, you'll have to find a reviewer (more details on this later, for now you may leave this blank and edit it in the patch file later). Note that the default editor for this is usually vim, so you have to press Ins before typing text and then Esc followed by a :x and Enter to save.

Advanced usage
In case of complicated bugs or bugs which already have a patch, you can queue the patches up. Simply use hg qnew to create patches and  hg qpush or hg qpop to move up and down the patch queue (this will change the code to reflect the currently active patch, and hg qref will update that same patch)

If you want to work on a different bug in parallel, you just have to pop all current patches out, and create a new patch queue with hg qqueue -c. You can then switch between the queues with hg qqueue queuename.


Creating patches without hg
Since the full repository takes a really long time to download and unpack, it's useful to have a different way of making patches so that the download doesn't become a blocking step.

For preliminary patches, with just one file
This is if you want to submit a patch that can be reviewed fr feedback but not checked in as a final patch. I wouldn't recommend using this method, but I'll keep these instructions here just in case.

If you're just editing one file, put the old version and the new version side by side, and run diff -u oldfile newfile >mypatch.patch in the same directory. Now, open the patch file and edit the paths to match the relative filepath of the edited file from the root firefox directory (eg if you edited main.xulold to main.xul, replace both names with browser/components/preferences/main.xul)

Proper patches
Put the files in a directory, and then run git init on the files. Now, git add *  and then git commit -m "commit message" to commit the files.
After this, make your changes to the files. Then, run git diff -U8 >output.patch . Edit the patch and change the a/filename and b/filename lines to be a/path/to/filename and b/path/to/filename. The paths here are relative with respect to the root directory.

Now, add the following to the top of the patch

# HG changeset patch
# Parent parenthash
# User Firstname Lastname email@something.com>
Bug 12345 - Frob the baz button when foo happens; r=jawsSet the commit message as described in the above section for creating patches with hg.

As for the parent hash, you can ignore and remove the line (or get it by going to the mozilla-central hg repository and copying the hash of the tip commit).

Step 5: Submitting the patch, and the review processSee also: Getting reviews
Now that you're at this stage, the rest is pretty smooth sailing. Find the "add attachment"  link on the bugzilla page:

Upload the attachment, give it a descriptive name ("Patch for barring the foo", though sometimes I just use "Patch 0.1"), and make sure the "patch" checkbox is ticked

Now, you also need to ask for review. Click the dropdown next to the review menu, and set it to "?" ("requesting review"). Put the username of your reviewer in the "Requestee" box (and use the autosuggest to get the email address). If you don't know who to ask for review:
  • If the bug is mentored, your mentor will be able to review your code. Usually the mentor name will turn up in the "suggested reviewers" dropdown box in bold, too.
  • If the bug isn't mentored, you still might be able to find reviewers in the suggested reviewers dropdown. The dropdown is available for bugs in most firefox and b2g components.
  • Otherwise, ask around in IRC or check out the hg logs of the file you modified (start here) to find out who would be an appropriate reviewer.
  • A list of module owners and peers for each module can be found here (the Firefox and Toolkit ones are usually the ones you want). These users are allowed to review code in that module, so make sure you pick from those. If you mistakenly pick someone else, they'll usually be helpful enough to redirect the review to the right person.

Usually, on the first bug, your review will be canceled ("r-"). This is nothing to be worried about, the mentors (and/or reviewers) are very helpful and will let you know exactly what can be improved in the process. This is one of the things I like about Mozilla; everyone's quite helpful!
Once you fix the nits and other changes requested from you, re-upload the attachment (mark the old one as obsolete).
At one point, the review will be granted, and the code will be checked in. Once that happens, the bug will get marked as resolved. And you're done with your first bug!
Categorieën: Mozilla-nl planet

Jonathan Protzenko: Shutting down my (now redundant) comm-central clone on github

Mozilla planet - ti, 22/04/2014 - 09:33

This is just a public service announcement: I'm shutting down the comm-central repository on github I've been maintaining since 2011. Please use the official version: they share the same hashes so it's just a matter of modifying the url in your .git/config. Plus, the official repo has all the cool tags baked in.

(Turns out that due to yet-another hg repository corruption, the repo has been broken since early March. Since no one complained, I suspect no one's really using this anymore. I'm pretty sure the folks at Mozilla are much better at avoiding hg repository corruptions than I am, so here's the end of it!).

Categorieën: Mozilla-nl planet

Jonathan Protzenko: Shutting down my (now redundant) comm-central clone on github

Thunderbird - ti, 22/04/2014 - 09:33

This is just a public service announcement: I'm shutting down the comm-central repository on github I've been maintaining since 2011. Please use the official version: they share the same hashes so it's just a matter of modifying the url in your .git/config. Plus, the official repo has all the cool tags baked in.

(Turns out that due to yet-another hg repository corruption, the repo has been broken since early March. Since no one complained, I suspect no one's really using this anymore. I'm pretty sure the folks at Mozilla are much better at avoiding hg repository corruptions than I am, so here's the end of it!).

Categorieën: Mozilla-nl planet

Justin Dolske: Satellite Radio

Mozilla planet - ti, 22/04/2014 - 07:25

In my last blog post, I wrote about how I helped fund the launch of a satellite via KickStarter, and that after launch I would have more to say about receiving radio signals from it. This is that update.

The good news is that SpaceX’s Falcon 9 finally launched last Friday. It’s had two delays since the originally scheduled date of March 30th. No big deal, it happens. Here’s the launch video, showing liftoff, onboard rocketcam, staging, and separation of the Dragon cargo capsule: (YouTube)

This is the CRS-3 flight — the 3rd  Commercial Resupply Service flight hauling cargo to the International Space Station. With the retirement of the Space Shuttle, CRS flights are the only US vehicles going to ISS, although other countries have their own capabilities. This is also the first flight where SpaceX has successfully flown the first stage back to Earth for a landing (albeit in the ocean, for safety, as it’s still experimental). Usually rockets like this are expendable – they just reenter the atmosphere and burn up. But SpaceX plans to fly them back to reuse the hardware and enable lower costs. It’s a pretty stunning concept. There’s no video of CRS-3′s Falcon 9 returning (yet?), just two tweets confirming it was successful. But it just so happens they did a test flight last week that demonstrates the idea: (YouTube)

So back to to satellite I funded: KickSat. The “carrier” was successfully deployed, and the first telemetry packets have been received and decoded. In a couple of weeks (May 4th) it will deploy its 104 “Sprite” nanosatellites, which will each start broadcasting their own unique signals. Things are off to a great start!

The slightly bad news is that I haven’t been completely successful in capturing Kicksat broadcasts with my own ground equipment. Yet.

It’s challenging for a few reasons…

The biggest factor is that the signals are inherently just not very strong, due to power limitations. The KickSat carrier is a 3U cubesat, with limited area for solar-cells. It periodically broadcasts a brief telemetry packet with a 1-watt radio, which is what I’m trying to capture.

And of course the Sprites it carries are even smaller, and will only be transmitting with a mere 10mW of power. The silver area in the Sprite I’m holding below is where the solar cell goes. (It turns out that satellite-grade solar cells are export-restricted under US law, so the sample units shipped without ‘em!)

Such faint signals need some modestly specialized (but still off-the-shelf) equipment to enable reception. I’ve got a yagi antenna and low-noise amplifier, as recommended on the KickSat wiki. Successfully making use of it is a little tricky, though. You need to use orbit tracking tools (e.g. gpredict or via Heavens Above) to know when a satellite pass will occur, and where in the local sky its path will be. Yagis are directional, and thus need to be pointed (at least roughly) to the right place. Not every pass is directly overhead, and if it’s too low on the horizon it may be too hard to receive (due to strength or interference).

Additionally, KickSat only broadcasts a short packet once every 30 or 250 seconds (depending on what mode it’s in), and during a pass it’s only above the horizon for a few minutes. That makes for a rather ephemeral indication that it’s even there. Blink and it’s gone! My location has about 4 pass opportunities a day, but not all are useful.

Oh, and did I mention I’m doing this all with a cheap $20 RTL2832U software defined radio?! Heck, the coax cables connecting my dongle to the antenna cost more than the radio itself!

I decided to start off by first trying to catch signals from some other satellites. I went through AMSAT’s status page and DK3WN’s fantastic satellite blog and gathered a list of a couple dozen satellites known to be active on the same 70cm (~435Mhz) band KickSat is using.

My first success was HO-68 (aka Hope Oscar 68 aka XW-1). This is a Chinese satellite launched in 2009, broadcasting a fairly constant 200mW telemetry “beacon” in morse code. Picking out the dotted line in the GQRX waterfall display was pretty easy, even though it’s not exactly on the expected 435.790Mhz frequency due to inaccuracies in my radio and doppler shift(!).

This is what it sounds like: WAV | OGG. Why is the tone shifting? The gradual lowering is doppler shift. The abrupt jumps upward are just from me adjusting the radio tuning to keep it audible. My morse code skills are terrible, but I replayed it enough times to convince myself that it starts out with the expected “BJ1SA XW XW” (the radio sign and initials of its name), per the page describing the signal format. For the lazy, that’s – . . . / . – - – / . – - – - / . . . / . – / – . . – / . – - / – . . – / . – - in morse code.

Next up was FO-29.

Here’s a screengrab of gpredict, showing the predicted path low in the sky, from the southeast to north.

It’s got a stronger 1-watt beacon, which wasn’t too hard to spot. Here I’ve switched from GQRX on OS X to SDRSharp on Windows. It has more features, plugins, and makes it easy to zoom in on a signal. The signal with doppler-shift is readily apparent as a diagonal line.

Audio of FO-29′s beacon: WAV | OGG. Despite the stronger transmitter, the received signal is weaker (probably due to being low on the horizon), and the the morse code is sufficiently fast that I’m not able to decode it by ear. (There’s an app for automatic decoding, but I haven’t tried it yet.)

And lastly… *drumroll*… After a number of unsuccessful attempts to receive KickSat’s signal, I finally caught it today! There was a nearly-overhead pass in the afternoon, so the as-received signal strength was optimal.

I pointed my antenna upwards, tilted it to my clear northeast view, tuned SDRSharp to the 437.505 MHz KickSat frequency, and waited. This is one of the usecases where software radio is really useful… While waiting, I was was recording the entire raw ~2Mhz slice of bandwidth around that frequency. That’s 4.5GB for the 7 minutes I was recording. I actually missed the transmission the first time, as it’s indicated about 23kHz lower than expected (again, due to hardware inaccuracies and doppler shift). But no big deal, I just replayed the recorded data and fine tuned things to the right spot.

Here’s what it sounds like: WAV | OGG. Unlike the steady stream of analog dit-dahs from HO-68 and FO-29, this is just 2 seconds of digital “noise”, like you would hear from a dialup modem. In fact, it’s exactly what you’d hear from an old modem. KickSat is using the 1200bps AFSK-modulated format, which is apparently still widely used in amateur packet radio. There are decoders available to extract the digital data (GQRX has one built in, and SDRSharp output can be piped to the qtmm AFSK1200 decoder).

If you’ve got SDRSharp, here’s the raw IQ data for the packet (ZIP, 60.3MB). I cropped the data to just the relevant portion. Alas, I can’t seem to get the decoder to recognize the packet. :( I’m not quite sure what the problem is yet… I’ve successfully decoded other AFSK data with this setup, so I suspect my signal was just too weak/noisy. Could be poor antenna pointing, but this was an easy pass. Some folks have had success with improving SNR with shielding, but I haven’t been able to replicate their results. There are a number of knobs and dials in SDRSharp to adjust manual/automatic gain control, so I might need to tweak that. (Unfortunately difficult, as there are only a few brief chances a day to catch KickSat.) It’s also possible that this is just slightly beyond the capabilities of a $20 RTL2832U dongle. Other options exist. I’d love to get a HackRF SDR board, but they’re not available yet. The FUNcube Dongle Pro+ can be had for about $200, but from comparisons I’m not sure exactly how much better it is in this band, or if it’s worth it. I’d love to hear opinions from hams who know this stuff better, or have tried both!

Amusing aside: while poking around in the 70cm band for interesting things, I stumbled across Santa Clara County’s ARES/RACES packet radio BBS. (Apparently, Ted, that is indeed still a thing!) In fact, FO-29 is actually an orbiting BBS! It’s quaintly amusing in the Internet Age, but when it launched in 1990 it must have been amazing. I had just upgraded to a 2400bps modem and discovered FidoNet and UUCP to reach beyond the local area code BBS systems.

That’s it for now. Over the next few weeks I’ll be refining my equipment and skills, and hope to capture some solid transmissions by the time my Sprite deploys. That will be even tougher to catch, but it’s a fun challenge!


Categorieën: Mozilla-nl planet

Pascal Finette: Anatomy of a Speech

Mozilla planet - ti, 22/04/2014 - 01:21

A few weeks ago I was invited to speak at the World Business Dialogue in Cologne, Germany on “Tech for Good”.

As part of my speech I prepared speaking notes for the deck I was using. Below you’ll find the raw notes – this is the completely unedited version I wrote to prepare myself for the speech a day before the event itself.

I figured it might be fun to get a peek into the ugly underbelly of making a public speech.

[1] Good afternoon. Let’s talk a bit about what I mean when I talk about technology for good, why it’s important and why I am so passionate about it that I spent considerable amounts of my time working on it.

[2] Over the last century we experienced a rapidly accelerating curve of progress - all driven by technology. We long left the linear growth path and are on an accelerated exponential curve.

You might have heard of Moore’s Law: Intel’s founder Gordon Moore predicted that computers will double in speed about every two years. That’s linear growth. And it’s not true for a lot of technologies anymore - we far exceed this growth pattern.

Let me give you just two examples:

[3] 5 Exabytes of information, that’s a one with 18 zeros, is the amount of information all of mankind produced since the beginning of time until the year 2003.

In 2010 we produced the same amount of information every two days.

Last year we produced those 5 exabytes every 10 minutes.

[4] When the human genome project first sequenced the full human genome we spend about 10 years and 3 billion dollars on it. That was around the year 2000.

In 2006 we brought the price down to $10 million dollars and a few months of sequencing time.

This year you can get your genome sequenced for a mere $1,000 in just a few hours.

[5] These are all exponential trends. They happen in industry after industry - and yet, as humans, we are poorly equipped to identify them.

Take this curve of mobile phone adoption over time: Every single time an expert made a projection their prognosis was way off - and linear. We kept saying: We have reached the tipping point, technology doesn’t get any cheaper, faster or better anymore by the same rate we saw before. And we were wrong.

So why is this important? Because we need to push the envelop to solve some of the worlds most intractable problems.

[6] In 2050 we will have 9 billion people on this planet. To feed them we need to grow agricultural output by 2% year over year. Current technology only produces a 1% year over year gain.

[7] Today 3 billion people live on less than $2.5 a day - that’s about half what your cup of fancy Starbucks coffee cost you.

[8] Currently 800 million people don’t have access to clean drinking water. Not running water in their homes - any form of clean drinking water even from a well 10 miles away.

[9] 2.5 billion people around the world don’t have access to sanitation. Which effectively means open defecation - which results in countless health issues.

[10] We need to create 600 million new jobs in the next 15 years to sustain current employment rates.

And yet…

[11] When it comes to technology too many of us focus on building the next version of this.

Let me give you a few examples of technology solving real world problems at scale:

[12] 30% of all water pumps in the 3rd world don’t work. Nobody knows which ones. The movie which plays again and again is: Aid organizations go into a village, build a well, leave and a year or so later the well doesn’t work anymore.

[13] A San Francisco startup builds this sensor which measures water flow speed and even monitors water quality, sends this information wirelessly to a central command center and allows, for the first time, so see which wells operate well, which need servicing and so on. These sensors cost less than $30 and are currently deployed in Africa by Charity Water.

[14] Or take vaccination: 20% of all vaccines administered in the 3rd world are spoiled due to a break in the cold chain. In the best case this leads to ineffective vaccines, in the worst case it kills people. In any case - it leads to massive challenges if we want to eradicate diseases.

[15] A Boston-based startup developed this wirelessly controlled sensor which monitors temperature every few minutes, sends the data to a server and allows not only to find out if a particular vaccine is spoiled but also where in the chain it spoiled and thus allows, for the first time, to fix and optimize cold chains.

[16] And take natural disasters. One of the big challenges in disaster areas is that often vital infrastructure such as roads is destroyed. To get intel and aid into these regions we fly helicopters and airplanes - very expensive, hard to pull off (you need a working air strip etc), complicated.

[17] This copter-drone, developed by a team at Singularity University costs $2000, delivers up to 20 pounds of medication and provides valuable on-the-ground intel to aid workers.

[18] In summary: We need to develop new and novel ways to solve some of the worlds largest problems. Those solutions need to be deployed at scale. Technology is our ticket out of this situation. Pushing the curve towards exponential growth is what’s needed.

[19] And make no mistake: This is not only charity but good business. People who live on $2.50 a day still spend those $2.50. They just can’t buy good products at the moment. These are markets with hundreds of millions and billions of people.

Categorieën: Mozilla-nl planet

Mozilla, Brandeis and Free Expression - New York Times

Nieuws verzameld via Google - ti, 22/04/2014 - 01:16

Mozilla, Brandeis and Free Expression
New York Times
I agree with Ross Douthat about the lack of the most important kind of “diversity” — diversity of ideas — in those very places that preach the most about diversity: universities (“Diversity and Dishonesty,” column, April 13). As he says, the ...

Google Nieuws
Categorieën: Mozilla-nl planet

Vergelijkbare No-Script extensie voor de Opera browser? - Security.nl

Nieuws verzameld via Google - mo, 21/04/2014 - 21:46

Vergelijkbare No-Script extensie voor de Opera browser?
Security.nl
Allereerst bedoel je neem ik aan de Internet browser FireFox van het bedrijf Mozilla. Ten tweede heb ik nergens gelezen dat er voor FireFox meer aanvalssectoren zijn dan andere browsers. Daarnaast zijn juist de vele instellingen die je in FireFox kan ...

Google Nieuws
Categorieën: Mozilla-nl planet

Instantbird: Google Summer of Code 2014 has Commenced!

Thunderbird - mo, 21/04/2014 - 21:00

Instantbird again has the pleasure of participating in Google Summer of Code under the Mozilla umbrella. In the past we’ve had a variety of exciting projects and this year is no different. Three students will be working with us this summer:

Saurabh Anand (sawrubh), mentored by Patrick Cloke (clokep), will aim to add support for reliable file transfer to Instantbird using FileLink as a fallback to standard file transfer.

Mayank Kumar (mayanktg), mentored by Benedikt P. (Mic), will be adding voice and video support to Instantbird by integrating WebRTC for XMPP. WebRTC makes it easy for us to have real-time communication without the use of additional plugins.

Nihanth Subramanya (nhnt11), who last year added the “awesometab“, will be looking to improve loading of conversations and history under the guidance of aleth. He will work on adding the ability to search across all logs of a contact and loading the previous context of a conversation when scrolling (“infinite scroll”).

Please feel free to stop by #instantbird on irc.mozilla.org to say hello and congratulate our students! Thanks again to Mozilla for allowing us to participate in Google Summer of Code with them!

Categorieën: Mozilla-nl planet

Frédéric Harper: YulDev, connecting with other developers

Mozilla planet - mo, 21/04/2014 - 17:46

 

YulDev

Montreal’s Developers, would you like to have more occasions to network with your peers, no matter which technology they are using? If it’s the case, YulDev is for you: a new monthly meetup where you can network with developers, and talk about whatever you like. The simplicity of just discussing code (or anything else) with a drink (juice, coffee, beer, glass of wine…) and other developers.

We are lucky in Montreal: there are many user groups for developers! Most of them have one point in common: they often focus on one technology or a group of related ones, and the primary goal is to learn from a speaker. Like you, I have much interest when it comes to technology, but I also have limited time in a week. Therefore, I cannot attends all the user groups or events I would like too, and I feel I’m missing opportunity to meet new amazing developers. With this in mind, I created YulDev, a Montreal style (French & English) user group or I should say, networking group as there will be no presentation (maybe greetings from your host in the beginning, but nothing else). In a 6@8 formula, the goal of this monthly event is to mingle, talk with people you know, and of course, meet new one. You never know what will happen next: new job, new friend, possible customer, a startup idea, interest in a new language, discovering a new user group you did not know about, and of course, an amazing evening with great developers.

So don’t wait, join the group, share about it with your co-workers, and RSVP for our first meetup in May. Don’t underestimate the power of networking in our industry!

P.S.: If you are the lead of a group for developers in Montreal or a media, and would like to promote YulDev, please let me know. If you are a company, and would like to sponsor the group, let’s talk about it (more information soon about our needs).


--
YulDev, connecting with other developers is a post on Out of Comfort Zone from Frédéric Harper

Related posts:

  1. User groups: learn, meet and share Please note that this blog post talk about Make Web...
  2. So you want to find a co-founder for your startup idea in Montreal? I’ve got asked quite often about the startup industry in...
  3. Empower Mobile Web Developers with JavaScript & WebAPI at PragueJS HTML5 is a giant step in the right direction: it...
Categorieën: Mozilla-nl planet

Joel Maher: Hi Vikas Mishra, welcome to the Mozilla community!

Mozilla planet - mo, 21/04/2014 - 14:38

I remember right before the winter break where I was off for a couple of weeks to end the year, A new person showed up and started working on some of my bugs. This was Vikas and he was eager and motivated to do a lot of great things.  Fast forward to today, and I still chat with Vikas weekly in irc.  When he gets a break from school and other activities of interest, he will be hunting for bugs to fix and usually knocking them out 3 or 4 at a time. In fact, I was surprised when I did a query on bugzilla, and on github to see that he is involved in a variety of projects at Mozilla such as Phonebook, Marionette, Talos, and test automation.

I wanted to learn more about Vikas, so I asked him some questions

Tell me about where you live?

Currently I live in Goa, India which is famous for its beaches and attracts many tourists from both India as well as foreign nationals. The best thing about this place is my campus which feels like a home away from home now. I like this place for its beautiful weather, its beaches and ever friendly nature of people living here. This place has brought  a lot of changes in my personality and has given me a chance to make some new friends who are always ready to help.

Tell me about your school?

I am a first year undergraduate student at Birla Institute of Technology and Science Pilani, Goa Campus (popularly known as BITS Pilani Goa) pursuing Msc.(Hons) Economics. I am enrolled in a dual degree scheme offered by my college where in I get an option to take a B.E degree depending on my first year’s performance and I hope to get a C.S major. My favorite subject so far has been Computer Science as I’ve always been fascinated towards computers and love to code

How did you get involved with Mozilla?

My first interaction with the Mozilla community was when I started using firefox few years back. Last December I decided to start contributing to some open source organizations and searched for organizations to start with and decided to go with Mozilla. I started with Mozilla since its a very large community so there’s always lots of help available. My experience with Mozilla community so far has been absolutely great, I had no idea how the open source community works and was afraid to ask silly questions as I thought people wont have time to answer those questions. I remember when I was assigned my first bug and Joel Maher was my mentor, while setting the local environment I kept on getting errors and used to pastebin those to him and it took me hours to set it up but he was totally cool with it even though I  myself was annoyed with those ever lasting errors. Even now I get stuck at some places but he’s always there to help me. Besides him there are other members too who have helped a lot and are always ready to help if required. My experience so far has been brilliant and am looking forward to learning new things and meeting some great people in the future as well.

What hobbies and activities do you enjoy doing?

Nowadays I spend most of my time coding and learning new stuff. I love the concept of open source software and love to interact with the community and gain valuable experience. Besides coding I enjoy playing football, cricket, and am a complete movie buff. I also love to hang out with friends and spend time with them.

Where do you see yourself in 5 years?

Down the lane in 5 years I see myself as a software engineer working for Mozilla (preferably in the Ateam) solving problems and developing new tools.

What advice would you give someone?

Although I don’t see myself as someone who can advise about life but If someone asked me I’ll advise him/her to enjoy life to the fullest and do whatever he/she loves to do no matter what others expect them to do and if they are related to the software industry obviously I’ll advise them to contribute to the open source community :)

 

I have enjoyed watching Vikas learn his way around Mozilla.  If you have worked with him, you probably already know why I have enjoyed my interactions with him, if you haven’t had the chance to work with him, say hi in irc, his nick is :mishravikas.


Categorieën: Mozilla-nl planet

Will Kahn-Greene: Dennis v0.3.11 released! Fixes and Python 3 support

Mozilla planet - mo, 21/04/2014 - 14:00
What is it?

Dennis is a Python command line utility (and library) for working with localization. It includes:

  • a linter for finding problems in strings in .po files like invalid Python variable syntax which leads to exceptions
  • a statuser for seeing the high-level translation/error status of your .po files
  • a translator for strings in your .po files to make development easier
v0.3.11 released!

v0.3.11 adds Python 3 support (there might be problems, but it's working for me) and adds error detection for the case where there's a } but no {.

Definitely worth updating!

8 out of 11 people who have heard of Dennis and continue to ignore its baby mews of wonderfulness also have a severe allergy to rainbows and kittens.

Categorieën: Mozilla-nl planet

HITBSecConf/Haxpo 2014

Mozilla-NL nieuws - mo, 21/04/2014 - 13:06
Date: woensdag, 28 mei, 2014 - 08:00 tot vrijdag, 30 mei, 2014 - 17:00Wie: OpenbaarTags: ExternMozillabooth

http://haxpo.nl/hitb2014ams-haxpo/

Imagine an area dedicated to hackerspaces;
makers with 3D printers, laser cutters and other fabrication goodies coupled with TOOOL‘s Lock Picking Village, HITB and Mozilla’s HackWEEKDAY developer hackathon, a hackerspaces challenge featuring LEGO Mindstorms EV3, our Capture the Flag ‘live hacking’ competition and topped off by a 3 day IT exhibition featuring Microsoft and Google as the main anchors.

Categorieën: Mozilla-nl planet

Want Marriage Equality? Follow the Obama/Biden Model, Not the Mozilla Model. - Slate Magazine (blog)

Nieuws verzameld via Google - snein, 20/04/2014 - 17:06

Slate Magazine (blog)

Want Marriage Equality? Follow the Obama/Biden Model, Not the Mozilla Model.
Slate Magazine (blog)
In the days since Brendan Eich quit Mozilla, supporters of same-sex marriage have debated the wisdom of using pressure to punish their opponents. Eich, an executive with no known record of antigay bias in the workplace, was forced out for having ...

en meer »
Categorieën: Mozilla-nl planet

Nick Cameron: Rust for C++ programmers - part 2: control flow

Mozilla planet - snein, 20/04/2014 - 10:45
IfThe `if` statement is pretty much the same in Rust as C++. One difference is that the braces are mandatory, but brackets around the expression being tested are not. Another is that `if` is an expression, so you can use it the same way as the ternary `?` operator in C++ (remember from last time that if the last expression in a block is not terminated by a semi-colon, then it becomes the value of the block). There is no ternary `?` in Rust. So, the following two functions do the same thing:
fn foo(x: int) -> &'static str {
    let mut result: &'static str;
    if x < 10 {
        result = "less than 10";
    } else {
        result = "10 or more";
    }
    return result;
}

fn bar(x: int) -> &'static str {
    if x < 10 {
        "less than 10"
    } else {
        "10 or more"
    }
}The first is a fairly literal translation of what you might write in C++. The second is in better Rust style.

You can also write `let x = if ...`, etc.

LoopsRust has while loops, again just like C++:fn main() {
    let mut x = 10;
    while x > 0 {
        println!("Current value: {}", x);
        x -= 1;
    }
}There is no do...while loop in Rust, but we do have the `loop` statement which just loops forever:fn main() {
    loop {
        println!("Just looping");   
    }
}Rust has `break` and `continue` just like C++.For loopsRust also has `for` loops, but these are a bit different. Lets say you have a vector of ints and you want to print them all (we'll cover vectors/arrays, iterators, and generics in more detail in the future. For now, know that a `Vec<T>` is a sequence of `T`s and `iter()` returns an iterator from anything you might reasonably want to iterate over). A simple `for` loop would look like:fn print_all(all: Vec<int>) {
    for a in all.iter() {
        println!("{}", a);
    }
}If we want to index over the indices of `all` (a bit more like a standard C++ for loop over an array), you could dofn print_all(all: Vec<int>) {
    for i in range(0, all.len()) {
        println!("{}: {}", i, all.get(i));
    }
}Hopefully, it is obvious what the `range` and `len` functions do. Switch/MatchRust has a match expression which is similar to a C++ switch statement, but much more powerful. This simple version should look pretty familiar:fn print_some(x: int) {
    match x {
        0 => println!("x is zero"),
        1 => println!("x is one"),
        10 => println!("x is ten"),
        y => println!("x is something else {}", y),
    }
}There are some syntactic differences - we use `=>` to go from the matched value to the expression to execute, and the match arms are separated by `,` (that last `,` is optional). There are also some semantic differences which are not so obvious: the matched patterns must be exhaustive, that is all possible values of the matched expression (`x` in the above example) must be covered. Try removing the `y => ...` line and see what happens; that is because we only have matches for 0, 1, and 10 and obviously there are lots of other ints which don't get matched. In that last arm, `y` is bound to the value being matched (`x` in this case). We could also write:fn print_some(x: int) {
    match x {
        x => println!("x is something else {}", x)
    }
}Here the `x` in the match arm introduces a new variable which hides the argument `x`, just like declaring a variable in an inner scope.

If we don't want to name the variable, we can use `_` for an unnamed variable, which is like having a wildcard match. If we don't want to do anything, we can provide an empty branch:fn print_some(x: int) {
    match x {
        0 => println!("x is zero"),
        1 => println!("x is one"),
        10 => println!("x is ten"),
        _ => {}
    }
}Another semantic difference is that there is no fall through from one arm to the next.

We'll see in later posts that match is extremely powerful. For now I want to introduce just a couple more features - the 'or' operator for values and `if` clauses on arms. Hopefully an example is self-explanatory:fn print_some_more(x: int) {
    match x {
        0 | 1 | 10 => println!("x is one of zero, one, or ten"),
        y if y < 20 => println!("x is less than 20, but not zero, one, or ten"),
        y if y == 200 => println!("x is 200 (but this is not very stylish)"),
        _ => {}
    }
}Just like `if` expressions, `match` statements are actually expressions so we could re-write the last example as:fn print_some_more(x: int) {
    let msg = match x {
        0 | 1 | 10 => "one of zero, one, or ten",
        y if y < 20 => "less than 20, but not zero, one, or ten",
        y if y == 200 => "200 (but this is not very stylish)",
        _ => "something else"
    };

    println!("x is {}", msg);
}Note the semi-colon after the closing brace, that is because the `let` statement is a statement and must take the form `let msg = ...;`. We fill the rhs with a match expression (which doesn't usually need a semi-colon), but the `let` statement does. This catches me out all the time.

Motivation: Rust match statements avoid the common bugs with C++ switch statements - you can't forget a `break` and unintentionally fall through; if you add a case to an enum (more later on) the compiler will make sure it is covered by your `match` statement.Method callFinally, just a quick note that methods exist in Rust, similarly to C++. They are always called via the `.` operator (no `->`, more on this in another post). We saw a few examples above (`len`, `iter`). We'll go into more detail in the future about how they are defined and called. Most assumptions you might make from C++ or Java are probably correct.
Categorieën: Mozilla-nl planet

Rizky Ariestiyansyah: Tnotify, a Terminal Notification

Mozilla planet - snein, 20/04/2014 - 05:42
Hello guys, this is short post to tell you about tnotify the easiest, most attractive way to fire off notifications from your terminal. This application is available on ruby gem repository, you know why...
Categorieën: Mozilla-nl planet

Gervase Markham: 10 Year Blogaversary

Mozilla planet - sn, 19/04/2014 - 21:12

10 years ago today, I started blogging.

At the time, I thought I was rather late to the blogging party. In hindsight, it seems not. Since then, through one change of host (thanks, Mozillazine!), there have been 1,463 posts (including this one), and 11,486 comments. Huge thanks to everyone who’s read and/or commented (well, if you commented without reading, not so much) in the last 10 years. It’s uncertain whether I or the blog will last another 10 (the Lord is in control of that) but here’s to however long it is!

Categorieën: Mozilla-nl planet

Sylvestre Ledru: Firefox 29 beta 8 to beta 9

Mozilla planet - sn, 19/04/2014 - 18:59

For the last beta for Desktop, this beta is smaller than the previous. This beta mostly fixes the remaining critical bugs including a critical Netflix bug with Silverlight. Some search configuration bugs with Bing and Yahoo have been fixed.

  • 34 changesets
  • 56 files changed
  • 490 insertions
  • 270 deletions

ExtensionOccurrences cpp16 h10 js8 html8 xml3 jsm2 in2 css2 xul1 sjs1 nsi1 ini1 idl1

ModuleOccurrences content13 browser10 gfx7 js5 widget4 extensions4 toolkit3 security3 mobile3 xpcom2 netwerk1 ipc1

List of changesets:

Tim TaubertBug 966843 - Fix intermittent browser_615394-SSWindowState_events.js hangs. r=smacleod, a=test-only - 7938ad1529f9 Jeff GilbertBug 892990 - Cap waiting time for wait-for-composite in WebGL reftests. r=bjacob, a=test-only - a27d9f49afac Matt WoodrowBug 988309 - Add nsRenderingContext constructor for a DrawTarget. r=roc, a=sledru - 843dc71f729b Matt WoodrowBug 991767 - Use Moz2D for printing surfaces. r=roc, a=sledru - 55422890fb8f Nicholas HurleyBug 994344 - Prevent access of null mDB in seer. r=mcmanus, a=sledru - e24aafe4dffd Nathan FroydBug 993546 - Refactor malloc-wrapping memory reporter implementations. r=njn, a=abillings, ba=noidlchanges - c8f1a4f5ca4d Mike ConleyBug 996186 - Customize mode briefly makes titlebar transparent during transition. r=Gijs, a=sylvestre - caf2147c04f4 Gijs KruitboschBug 987792 - increase panel buttons' labels' clip rect height, r=jaws, a=sylvestre - 23311c5022ea Mike ConleyBug 996148 - With tabs in titlebar disabled, the private browsing mask can be incorrectly positioned in certain modes. r=MattN. a=gavin. - 5a2fd00c18e0 Richard NewmanBug 941744 - Remove Send Tab intent filter from RELEASE_BUILDs. r=nalexander, a=sylvestre - b30d5dfe0421 Dan GlastonburyBug 966630 - Clamp level to TexImage operations to [0..31]. r=jgilbert, a=abillings - 17432cc5074d Jan de MooijBug 995607 - Fix an AutoDebugModeInvalidation issue. r=shu, a=abillings - 838a0ac967ae Marty RosenbergBug 982398 - Make sure a script isn't lazy before calling it. r=jandem, a=sledru - d5a00d84b8d6 Mike ConnorBug 958883 - Use HTTPS for Yahoo searches, part 1. r=gavin, a=sledru - c5d91a0d3a2e Mike ConnorBug 958883 - Use HTTPS for Yahoo searches, part 2. r=mfinkle, a=sledru - 38f6b630f2cd Mike ConnorBug 984530 - Bing search tags are not working properly. r=mfinkle, a=sledru - 148684fea6d4 Mike ConnorBug 983723 - Yahoo search tags are not working properly. r=mfinkle, a=sledru - 4873bad57984 Sean StanglBug 856796 - Attempt detection of YARR bug. r=till, a=sledru - 51375c4deaf6 Matt WoodrowBug 995065 - Backout Bug 947227 on the release branches. r=jgilbert, a=sledru - cea0324a3ac6 Robert StrongBug 996960 - Add new RTL languages to locales.nsi - Uyghur ug and Urdu ur. r=ehsan, a=sledru - 92cae49290ae Camilo VieccoBug 987816 - verifying with certificateUsageVerifyCA always return failure. r=dkeeler a=lsblakk - b192379d4d65 Masayuki NakanoBug 964718 Don't dispatch DOM event if internal event doesn't need that. Otherwise, implement Duplicate() method r=smaug, a=sylvestre - aaf5030cbf98 Olli PettayBug 957666 - Send back a huge retry reconnection time in delayedServerEvents.sjs. r=ehsan, a=test-only - 3051963e5ec3 Nicolas B. PierronBug 992968. r=efaust, a=sledru - df4f53346f73 Tim TaubertBug 947570 - Disable browser_597071.js until rewritten for Marionette. r=smacleod, a=test-only - 85e9ba2c9371 Patrick BrossetBug 993190 - Use the outline highlighter on fennec. r=miker, a=sledru - ddbb75065940 Mike ConnorBug 997179 - Bing is not present in default search engines. r=mfinkle, a=sledru - bd52a0b3dc58 Tim TaubertBug 824021 - Don't clear set of windows to resurrect on write when receiving messages. r=yoric, a=test-only - 5f78c1ba85e3 Ralph GilesBug 995289 - Use fmod to wrap custom waveform phase. r=padenot a=sledru - 3b65e1a1c52a Monica ChewBug 997759: Prefs for phishing and malware tables are comma-sep lists (r=gcp,ba=sledru) - 034a63535df0 Sebastian HengstBug 997625 - Sync panel: Checkbox for syncing passwords enabled (not disabled) while sync credentials need reauth r=ttaubert a=sylvestre - 0add478cf3b4 Bobby HolleyBug 994335 - Null-check aProtoDoc in nsXULPrototypeScript::Serialize. r=smaug, a=sledru - 7f0030f9aac0 Matthew NoorenbergheBug 988156 - Backout fd0d0f6002dc (Bug 846566) for causing fullscreen videos on Netflix to appear black. r=smichaud a=sylvestre - 9ce31b9cd02d Tim TaubertBug 996159 - Fix sync config section on Windows with 125% DPI. r=gavin a=sylvestre - bd6fdc0dcac0

r= means reviewed by
a= means uplift approved by

Previous changelogs:

Original post blogged on b2evolution.

Categorieën: Mozilla-nl planet

Nick Cameron: Rust for C++ programmers - an intermission - why Rust

Mozilla planet - sn, 19/04/2014 - 00:54
I realise that in terms of learning Rust, I had jumped straight to the 'how' and skipped the 'why'. I guess I am in enough of a Rust bubble that I can't imagine why you wouldn't want to learn it. So, I will make a bit more of an effort to explain why things are how they are. Here I will try to give a bit of an overview/motivation.

If you are using C or C++, it is probably because you have to - either you need low-level access to the system, or need every last drop of performance, or both. Rust aims to do offer the same level of abstraction around memory, the same performance, but be safer and make you more productive.

Concretely, there are many languages out there that you might prefer to use to C++: Java, Scala, Haskell, Python, and so forth, but you can't because either the level of abstraction is too high - you don't get direct access to memory, you are forced to use garbage collection, etc. - or there are performance issues - either performance is unpredictable or its simply not fast enough. Rust does not force you to use garbage collection, and as in C++, you get raw pointers to memory to play with. Rust subscribes to the 'pay for what you use' philosophy of C++. If you don't use a feature, then you don't pay any performance overhead for its existence. Furthermore, all language features in Rust have predictable (and usually small) cost.

Whilst these constraints make Rust a (rare) viable alternative to C++, Rust also has benefits: it is memory safe - Rust's type system ensures that you don't get the kind of memory errors which are common in C++ - memory leaks, accessing un-initialised memory, dangling pointers - all are impossible in Rust. Furthermore, whenever other constraints allow, Rust strives to prevent other safety issues too - for example, all array indexing is bounds checked (of course, if you want to avoid the cost, you can (at the expense of safety) - Rust allows you to do this in unsafe blocks, along with many other unsafe things. Crucially, Rust ensures that unsafety in unsafe blocks stays in unsafe blocks and can't affect the rest of your program). Finally, Rust takes many concepts from modern programming languages and introduces them to the systems language space. Hopefully, that makes programming in Rust more productive, efficient, and enjoyable.

I would like to motivate some of the language features from part 1. Local type inference is convenient and useful without sacrificing safety or performance (it's even in modern versions of C++ now). A minor convenience is that language items are consistently denoted by keyword (`fn`, `let`, etc.), this makes scanning by eye or by tools easier, in general the syntax of Rust is simpler and more consistent than C++. The `println!` macro is safer than printf - the number of arguments is statically checked against the number of 'holes' in the string and the arguments are type checked. This means you can't make the printf mistakes of printing memory as if it had a different type or addressing memory further down the stack by mistake. These are fairly minor things, but I hope they illustrate the philosophy behind the design of Rust.
Categorieën: Mozilla-nl planet

Pages