mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Mozilla Building Voice Library for AI Training - findBIOMETRICS

Nieuws verzameld via Google - ma, 17/07/2017 - 23:14

findBIOMETRICS

Mozilla Building Voice Library for AI Training
findBIOMETRICS
speech and voice feature Called Project Common Voice, the aim is to collect voice samples from people around the world. Mozilla announced it alongside a slew of other initiatives aimed at 'raising awareness for internet health', including a live event ...

en meer »
Categorieën: Mozilla-nl planet

Mozilla is crowdsourcing a massive speech-recognition system - Fast Company

Nieuws verzameld via Google - ma, 17/07/2017 - 22:10

Fast Company

Mozilla is crowdsourcing a massive speech-recognition system
Fast Company
From Amazon's Alexa to Apple's Siri, speech recognition and response are becoming mainstays of how we interact with computers, apps, and internet services. But the technology is owned by giant corporations. Now the Mozilla Foundation, maker of the free ...

en meer »
Categorieën: Mozilla-nl planet

Mozilla Asks Everyone to Donate Their Voice | News & Opinion ... - PCMag

Nieuws verzameld via Google - ma, 17/07/2017 - 12:43

PCMag

Mozilla Asks Everyone to Donate Their Voice | News & Opinion ...
PCMag
Voice recognition systems have become a very big deal over the past few years. Without them, we wouldn't have Apple's Siri, Amazon's Alexa, or Google Now.

en meer »
Categorieën: Mozilla-nl planet

Mozilla Asks Everyone to Donate Their Voice - PCMag

Nieuws verzameld via Google - ma, 17/07/2017 - 12:43

Mozilla Asks Everyone to Donate Their Voice
PCMag
Mozilla, best known for the Firefox web browser, wants to change that. Mozilla believes voice recognition should be open to everyone and that the big corporations keeping it locked up "stifles innovation." There's no way you'd ever convince any of them ...

Categorieën: Mozilla-nl planet

استخدموا متصفّح الـ"Mozilla Firefox".. لهذه الأسباب! - قناة العالم - موقع العالم الاخباري

Nieuws verzameld via Google - ma, 17/07/2017 - 11:55

موقع العالم الاخباري

استخدموا متصفّح الـ"Mozilla Firefox".. لهذه الأسباب! - قناة العالم
موقع العالم الاخباري
يوفّر متصفّح "Firefox Focus"، سرعة أكبر في التصفّح نتيجة قيامه بحجب الإعلانات من الظهور دون الحاجة لوجود أي إضافات أو برامج مختلفة، كما يزيل أدوات التتبع والتي ...

en meer »
Categorieën: Mozilla-nl planet

Mozilla gönnt Eltern bis zu sechs Monate Auszeit – bei vollem Gehalt - t3n Magazin

Nieuws verzameld via Google - ma, 17/07/2017 - 09:08

t3n Magazin

Mozilla gönnt Eltern bis zu sechs Monate Auszeit – bei vollem Gehalt
t3n Magazin
Firefox-Hersteller Mozilla bietet jetzt sein unternehmenseigenes Mutterschaftsgeld weltweit an. 26 Wochen erhalten leibliche Mütter (der schöne Begriff dahinter heißt "childbearing", die Leistung kann also nur von Frauen beansprucht werden), immerhin ...

Categorieën: Mozilla-nl planet

Defending Net Neutrality: Millions Rally to Save the Internet, Again

Mozilla Blog - do, 13/07/2017 - 22:28

We’re fighting for net neutrality, again, because it is crucial to the future of the internet. Net neutrality serves to enable free speech, competition, innovation and user choice online.

On July 12, it was great to see such a diversity of voices speak up and join together to support a neutral internet. We need to protect the internet as a shared global public resource for us all. This Day of Action makes it clear, yet again, that net neutrality it a mainstream issue, which the majority of Americans (76% from our recent survey) care about and support.

We were happy to see a lot of engagement with our Day of Action activities:

  • Mozilla collected more than 30,000 public comments on July 12 alone — bringing our total number of public comments to more than 75,000. We’ll be sharing these with the FCC
  • Our nine hour Soothing Sounds of Activism: Net Neutrality video, along with interviews from Senators Al Franken and Ron Wyden, received tens of thousands of views
  • The net neutrality public comments displayed on the U.S. Firefox snippet made 6.8 million impressions
  • 30,000 listeners tuned in for the net neutrality episode of our IRL podcast

The Day of Action was timed a few days before the first deadline for comments to the FCC on the proposed rollback of existing net neutrality protections. This is just the first step though. Mozilla takes action to protect net neutrality every day, because it’s obviously not a one day battle.

Net neutrality is not the sole responsibility any one company, individual or political party. We need to join together because the fight for net neutrality impacts the future of the internet and everyone who uses it.

What’s Next?

Right now, we’re finishing our FCC comments to submit on July 17. Next, we’ll continue to advocate for enforceable net neutrality through all FCC deadlines and we’ll defend the open internet, just like we did with our comments and efforts to protect net neutrality in 2010 and 2014.

The post Defending Net Neutrality: Millions Rally to Save the Internet, Again appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Defending Net Neutrality: A Day of Action

Mozilla Blog - wo, 12/07/2017 - 05:59
Mozilla is participating in the Day of Action with a new podcast, video interviews with U.S. Senators, a special Firefox bulletin, and more

 

As always, Mozilla is standing up for net neutrality.

And today, we’re not alone. Hundreds of organizations — from the ACLU and GitHub to Amazon and Fight for the Future — are participating in a Day of Action, voicing loud support for net neutrality and a healthy internet.

“Mozilla is supporting the majority of Americans who believe the web belongs to individual users, without interference from ISP gatekeepers,” says Ashley Boyd, Mozilla’s VP of Advocacy. “On this Day of Action, we’re amplifying what millions of Americans have been saying for years: Net neutrality is crucial to a free, open internet.”

“We are fighting to protect net neutrality, again, because it’s crucial to the future of the internet,” says Denelle Dixon, Mozilla Chief Legal and Business Officer. “Net neutrality prohibits ISPs from engaging in prioritization, blocking or throttling of content and services online. As a result, net neutrality serves to enable free speech, competition, innovation and user choice online.”

The Day of Action is a response to FCC Commissioner Ajit Pai’s proposal to repeal net neutrality protections enacted in 2015. The FCC voted to move forward with Pai’s proposal in May; we’re currently in the public comment phase. You can read more about the process here.

Here’s how Mozilla is participating in the Day of Action — and how you can get involved, too:

Nine hours of public comments. Over the past few months, Mozilla has collected more than 60,000 comments from Americans in defense of net neutrality.

“The internet should be open for all and not given over to big business,” wrote one commenter. “Net neutrality protects small businesses and innovators who are just getting started,” penned another.

We’ll share all 60,000 comments with the FCC. But first, we’re reading a portion of them aloud in a nine-hour, net neutrality-themed spoken-word marathon.

And we’re showcasing the comments on Firefox, to inspire more Americans to stand up for net neutrality. When Firefox users open a new window today, a different message in support of net neutrality will appear in the “snippet,” the bulletin above and beneath the search bar.

It’s not too late to submit your own comment. Visit mzl.la/savetheinternet to add your voice.

A word from Senators Franken and Wyden. Senator Al Franken (D-Minnesota) and Senator Ron Wyden (D-Oregon) are two of the Senate’s leading voices for net neutrality. Mozilla spoke with both about net neutrality’s connection to free speech, competition, and innovation. Here’s what they had to say:

Stay tuned for more interviews with Congress members about the importance of net neutrality.

Comments for the FCC. Mozilla’s Public Policy team is finishing up comments to the FCC on the importance of enforceable net neutrality to ensure that voices are free to be heard. They will speak to how net neutrality fundamentally enables free speech, online competition and innovation, and user choice. Like our comments from 2010 and 2014, we will defend all users’ ability to create and consume online, and will defend the vitality of the internet. User rights should not be used in a political play.

Net neutrality podcast. We just released the second episode of Mozilla’s original podcast, IRL, which focuses on who wins — and who loses — if net neutrality is repealed. Listen to host Veronica Belmont explore the issue in depth with a roster of guests holding different viewpoints, from Patrick Pittaluga of Grubbly Farms (a maggot farming business in Georgia), to Jessica González of Free Press, to Dr. Roslyn Layton of the American Enterprise Institute.

Subscribe wherever you get your podcasts, or listen on our website.

Today, we’re amplifying the voices of millions of Americans. And we need your help: Visit mzl.la/savetheinternet to join the movement. The future of net neutrality — and the very health of the internet — depends on it.

Note: This blog was updated on July 12 at 2:30 p.m. ET to reflect the most recent number of public comments collected.

The post Defending Net Neutrality: A Day of Action appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mozilla Open Innovation Team: Reflection — Inclusive Organizing for Open Source Communities

Mozilla planet - di, 11/07/2017 - 15:08

This, the second in a series of posts reporting findings from three months of research into the state of D&I in Mozilla’s communities. The current state of our communities is a mix, when it comes to inclusivity: we can do better, and this blog post is an effort to be transparent about what we’ve learned in working toward that goal.

If we are to truly unleash the full value of a participatory, open Mozilla, we need to personalize and humanize Mozilla’s value by designing diversity and inclusion into our strategy. To unlock the full potential of an open innovation model we need radical change in how we develop community and who we include.Photo credit: national museum of american history via VisualHunt.com / CC BY-NC

We learned that while bottom-up, or grassroots organizing enables ideas and vision to surface within Mozilla, those who succeed in that environment tend to be of the same backgrounds, usually the more dominant or privileged background, and often in tenured* community roles.

*tenured — Roles assigned by Mozilla, or legacy to the community that exist without timelines, or cycles for renewal/election.

Our research dove into many areas of inclusive organizing, and three clusters of recommendations surfaced:

1. Provide Organizational Support to Identity Groups

For a diversity of reasons including, safety, friendship, mentorship, advocacy and empowerment — identity groups serve both as a safe space, and as a springboard into, and out of greater community participation — for the betterment of both. Those in Mozilla’s Tech Speakers program, spoke very positively of the opportunity, responsibility and camaraderie provided by this program, which brings together contributors focused on building speaking skills for conferences.

Building a sense of belonging in small groups, no matter focus (Tech Speakers, Women of Color, Spanish Speaking), is an inclusion methodology.” — Non-Binary contributor, Europe

Womoz (Women of Mozilla) showed up in our research an example of an identity group trying to solve and overcome systemic problems faced by women in open source. However, without centralized goals or structured organizational support for the program, communities were left on their own to define the group, its goals, who is included, and why. As a result we found vastly different perspectives, and implementations of ‘Womoz’, from successful inclusion methodologies to exclusive or even relegatory groups:

  • As a ‘label’. ‘Catch-all’ for non- male non-binary contributors.
  • A way for women to gather that aligns with cultural traditions for convening of young women — and approved by families within specific cultural norms.
  • A safe, and empowered way to meet and talk with people of the same gender-identity about topics and problems specific to women.
  • A way to escape toxic communities where discussion and opportunity is dominated by men, or where women were purposely excluded.
  • An online community with several different channels for sharing advocacy (mailing list, Telegram group, website, wiki page).
  • As a stereotypical way to reference women-only contributing in specific areas (such as crafts, non-technical) or relegating women to those areas.

For identity groups to fully flourish and to avoid negative manifestations like tokenism and relegation, the recommendation is that organizational support (dedicated strategic planning, staffing, time, and resources) should be prioritized where leadership and momentum exists, and where diversity can thrive. Mozilla is already investing in pilot for identity with staff and core contributors which is exciting progress on what we’ve learned. The full potential is that identity groups act as ‘diversity launch pads’ into and out of the larger community for benefit of both.

2. Build Project-Wide Strategies for Toxic BehaviorPhoto by Paul Riismandel BY-NC-SA 2.0

Research exposed toxic behavior as a systemic issue being tackled in many different ways, and by both employees and community leaders truly dedicated to creating healthy communities.

Insights amplified external findings into toxic behavior, that shows toxic people tend to be highly productive thus masking the true impact of their behavior which deters, and excludes large numbers of people. Furthermore, the perceived value or reliance on the work of toxic individuals and regional communities was suspected to complicate, or deter and dilute intervention effectiveness.

Within in this finding we have three recommendations:

  1. Develop regionally-Specific strategies for community organizing. Global regions with laws and cultural norms that exclude, or limit opportunity to women and other marginalized groups demonstrate the challenge of a global-approach to open source community health. Generally, we found that those groups with cultural and economic privilege within a given local context were also the majority of the people who succeeded in participation. Where toxic communities, and individuals exist, the disproportionate representation of diverse groups was magnified to the point where standard approaches to community health were not successful. Specialized strategies might be very different per region, but with investment can amplify the potential of marginalized people within.
  2. Create an organization-wide strategy for tracking decisions, and outcomes of Community Participation Guidelines violations. While some project and project maintainers have been successful in banning and managing toxic behavior, there is no central mechanism for tracking those decisions for the benefit of others who may encounter and be faced with similar decisions, or the same people. We learned of at least one case where a banned toxic contributor surfaced in another area of the project without the knowledge of that team. Efforts in this vein including recent revisions to the guidelines and current efforts to train community leaders and build a central mechanism need to be continued and expanded.
  3. Build team strategies for managing conflict and toxic behavior. A range of approaches to community health surfaced success, and struggle managing conflict, and toxic behavior within projects, and community events. What appears to be important in successful moderation and resolution is that within project-teams there are designed specific roles, with training, accountability and transparency.
3. Develop Inclusive Community Leadership Models

In qualitative interviews and data analysis, ‘gatekeeping* showed up as one of the greatest blockers for diversity in communities.

Characteristics of gatekeeping in Mozilla’s communities included withholding opportunity and recognition (like vouching), purposeful exclusion, delay of, or limiting language translation of opportunity, and well as lying about the availability or existence of leadership roles, and event invitations/applications. We also heard a lot about nepotism, as well as both passive and deliberate banishment of individuals — especially women, who showed a sharp decrease in participation over time compared with men.

*Gatekeeping is noted as only one reason participation for women decreased, and we will expand on that in other posts.

Much of this data reinforced what we know about the myth of meritocracy, and that despite its promise, meritocracy actually enables toxic, exclusionary norms that prevent development of resilient, diverse communities.

“New people are not really welcomed, they are not given a lot of information on purpose.” (male contributor, South America)

As a result of these findings, we recommend all community leadership roles be designed with accountability for community health, inclusion and surfacing the achievement of others as core function. Furthermore, renewable cycles for community roles should be required, with designed challenges (like elections) for terms that extend beyond one year, with outreach to diverse groups for participation.

The long-term goal is that leadership begins a cultural shift in community that radiates empowerment for diverse groups who might not otherwise engage.

Our next post in this series ‘We See you — Reaching Diverse Audiences in FOSS’, will be published on July 21st. Until then, check out ‘Increasing Rusts Reach an initiative that emerged from a design sprint focused on this research.

Reflection — Inclusive Organizing for Open Source Communities was originally published in Mozilla Open Innovation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Mozilla Fully Paid Parental Leave Program Officially Rolls Out Worldwide

Mozilla planet - di, 11/07/2017 - 14:59

For most countries around the world, school is out, and parents are reconnecting with their kids to enjoy road trips and long days. Many of our Mozilla employees have benefited from the expanded parental leave program we introduced last year to spend quality time with their families. The program offers childbearing parents up to 26 weeks of fully paid leave and non-childbearing (foster and adoptive parents, partners of childbearing) parents up to 12 weeks of fully paid leave.

This July, we completed the global roll out of the program making Mozilla a leader in the tech industry and among organizations with a worldwide employee base.

What makes Mozilla’s parental leave program unique

And sets us apart from other tech companies and other organizations:

  • 2016 Lookback: A benefit for employees who welcomed a child in the calendar year prior to the expanded benefit being rolled out.
  • Global Benefit: As a US-based company with employees all over the world, we chose to offer it to employees around the world — US, Canada, Belgium, Finland, France, Germany, the Netherlands, Spain, Sweden, UK, Australia, New Zealand, Taiwan.
  • Fully Paid Leave: For all parents, they’ll receive their full salary during that time.
What our Mozilla employees have to say:

“Our second son was born in January 2017. When I heard about the new policy that Mozilla will launch globally one month before, I first was not sure how that will work out with the statutory parental leave rules in Germany. But I have to say that I first enjoyed working with Rachel to work out all the details — and now I get enjoy a summer with my family. The second child has changed my life completely, it was hard to match work and family needs. I am grateful that I will have time to give back to my son and my family and grow even more closer together.”  Dominik Strohmeier, based in Berlin, Germany.  Two children, with second child born in 2017.

Chelsea Novak with baby

“Our daughter was born in 2016,” says Chelsea Novak, Firefox Editorial Lead. “When Mozilla announced this new parental leave policy we were excited for parents that were expecting in 2017, but a little sad that we missed out. Having Mozilla extend these new parental leave benefits to us was very generous and gave us some precious time with our family that we weren’t expecting.”  Chelsea and Matej Novak, both longtime Canadian Mozilla employees, based in Toronto. Two children, ages 1 and 3.

 

 

 

“I started with Mozilla in the beginning of 2016, and delivered my child that same year. When I first heard of the policy, I didn’t think the new parental leave would apply to me. Then, Rachel told me the good news. I was amazed that they would extend the parental leave policy to me so that I can take additional time off in 2017.  Mozilla is so generous to parents like myself to enjoy special moments like watching my daughter take her first steps or saying her first words.”   Jen Boscacci, based in Mountain View, California.  Two children, with second child born in 2016.

 

Maura Tuohy with baby

“Being able to take advantage of the 26 weeks of leave — and have the flexibility of when to take it — was an incredible gift for our family. Knowing that the company was so supportive made the experience as stress free as having a newborn can be! I’m so grateful to work for such a progressive and kind company — not just in policies but in culture and practice.”  Maura Tuohy, based in San Francisco.  Her first child was born in 2017.

 

 

This program helps us embrace and celebrate families of all kinds, whether its adoption and foster care, we expanded our support for both childbearing and non-childbearing parents, independent of gender or situation. We value our Mozilla employees, because juggling between work and family responsibilities is no easy feat.

The post Mozilla Fully Paid Parental Leave Program Officially Rolls Out Worldwide appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mozilla Fully Paid Parental Leave Program Officially Rolls Out Worldwide

Mozilla Blog - di, 11/07/2017 - 14:59

For most countries around the world, school is out, and parents are reconnecting with their kids to enjoy road trips and long days. Many of our Mozilla employees have benefited from the expanded parental leave program we introduced last year to spend quality time with their families. The program offers childbearing parents up to 26 weeks of fully paid leave and non-childbearing (foster and adoptive parents, partners of childbearing) parents up to 12 weeks of fully paid leave.

This July, we completed the global roll out of the program making Mozilla a leader in the tech industry and among organizations with a worldwide employee base.

What makes Mozilla’s parental leave program unique

And sets us apart from other tech companies and other organizations:

  • 2016 Lookback: A benefit for employees who welcomed a child in the calendar year prior to the expanded benefit being rolled out.
  • Global Benefit: As a US-based company with employees all over the world, we chose to offer it to employees around the world — US, Canada, Belgium, Finland, France, Germany, the Netherlands, Spain, Sweden, UK, Australia, New Zealand, Taiwan.
  • Fully Paid Leave: For all parents, they’ll receive their full salary during that time.
What our Mozilla employees have to say:

“Our second son was born in January 2017. When I heard about the new policy that Mozilla will launch globally one month before, I first was not sure how that will work out with the statutory parental leave rules in Germany. But I have to say that I first enjoyed working with Rachel to work out all the details — and now I get enjoy a summer with my family. The second child has changed my life completely, it was hard to match work and family needs. I am grateful that I will have time to give back to my son and my family and grow even more closer together.”  Dominik Strohmeier, based in Berlin, Germany.  Two children, with second child born in 2017.

Chelsea Novak with baby

“Our daughter was born in 2016,” says Chelsea Novak, Firefox Editorial Lead. “When Mozilla announced this new parental leave policy we were excited for parents that were expecting in 2017, but a little sad that we missed out. Having Mozilla extend these new parental leave benefits to us was very generous and gave us some precious time with our family that we weren’t expecting.”  Chelsea and Matej Novak, both longtime Canadian Mozilla employees, based in Toronto. Two children, ages 1 and 3.

 

 

 

“I started with Mozilla in the beginning of 2016, and delivered my child that same year. When I first heard of the policy, I didn’t think the new parental leave would apply to me. Then, Rachel told me the good news. I was amazed that they would extend the parental leave policy to me so that I can take additional time off in 2017.  Mozilla is so generous to parents like myself to enjoy special moments like watching my daughter take her first steps or saying her first words.”   Jen Boscacci, based in Mountain View, California.  Two children, with second child born in 2016.

 

Maura Tuohy with baby

“Being able to take advantage of the 26 weeks of leave — and have the flexibility of when to take it — was an incredible gift for our family. Knowing that the company was so supportive made the experience as stress free as having a newborn can be! I’m so grateful to work for such a progressive and kind company — not just in policies but in culture and practice.”  Maura Tuohy, based in San Francisco.  Her first child was born in 2017.

 

 

This program helps us embrace and celebrate families of all kinds, whether its adoption and foster care, we expanded our support for both childbearing and non-childbearing parents, independent of gender or situation. We value our Mozilla employees, because juggling between work and family responsibilities is no easy feat.

The post Mozilla Fully Paid Parental Leave Program Officially Rolls Out Worldwide appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Shing Lyu: Install Ubuntu 16.04 on ThinkPad 13 (2nd Gen)

Mozilla planet - di, 11/07/2017 - 09:48

It has been a while since my last post. I’ve been busy for the first half of this year but now I got more free time. Hopefully I can get back to my usual pace of one post per months.

My old laptop (Inhon Carbonbook, discontinued) had a swollen battery. I kept using it for a few months but then the battery squeezed my keyboard so I can no longer type correctly. After some research I decided to buy the ThinkPad 13 model because it provides descent hardware for its price, and the weight (~1.5 kg) is acceptable. Every time I got a new computer the first thing is to get Linux up and running. So here are my notes on how to install Ubuntu Linux on it.

TL;DR: Everything works out of the box. Just remember to turn off secure boot and shrink the disk in Windows before you install.

Some assumptions Before Installing Ubuntu

First we need to clean up some disk space for Ubuntu. But if you are going to delete Windows completely you can skip the following steps.

  • (In Windows) Right click on the start menu, select “PowerShell (administrator)”, then run diskmgmt.msc.
  • Right click the C: disk and select the shrink disk option.

Before we can install Ubuntu, we need to disable the secure boot feature in BIOS.

  • Press Shift+restart to be able to get into BIOS, otherwise you’ll keep booting into Windows.
  • Press Enter followed by F1 to go into BIOS during boot.
  • Disable Secure Boot.

BIOS secure_boot secure_boot_sub_menu

UEFI boot seems to work with Ubuntu 16.04’s installer, so you can keep all the UEFI options enabled in the BIOS. Download the Ubuntu installation disk and use a bootable USD disk creator that supports UEFI, for example Rufus.

Installing Ubuntu

Installing Ubuntu should be pretty straightforward if you’ve done it before.

  • Go to BIOS again and set the USB drive as top priority boot medium.
  • Boot into Ubuntu, select “Install Ubuntu”.
  • Follow the installer wizard.
  • Select “Something else” when asked how to partition the disk.
  • Create a linux-swap partition of 4GB for 8GB of RAM. I followed Redhat’s suggestion, but there are different theories out there, so use your own judgement here.
  • Create a EXT4 main disk and set the mount point to /
  • After the installer finished, reboot. You should see the GRUB2 menu. The Windows options should also work without trouble.

GRUB2

What works?

Almost everything works out of the box. All the media keys, like volume control, brightness and WiFi and Bluetooth toggle is recognized by the built-in Unity desktop. But I am using i3 so I have to set them up myself, more on this later. The USB Type-C port is a nice surprise for me. It supports charging, so you can charge with any Type-C charger. I tested Apple’s Macbook charger and it works well. I also tested Apple’s and Dell’s Type-C multi-port adapter and both works, so I can plug my external monitor and my keyboard/mouse to it so it works like a docking station.

media_key

A side note, I’m also glad to find that Ubuntu now use the Fcitx IME by default. Most of the IME bugs I found in previous versions and ibus are now gone.

What doesn’t work?

Not that I’m aware of. The only complaint I have is that the Ethernet and Wi-Fi naming method has changed somehow (e.g. enp0s31f6 instead of eth0). But I believe that is something we can fix by software. People also complain that the power button and the hinge is not very sturdy. But I guess that’s the compromise you have to make for the relatively cheap price.

power_button

More on setting up media keys for i3 window manager

Since I use the i3 window manager, I don’t have Unity to handling all my media keys’ functionality. But it’s not hard to set them up using the following i3 config:

bindsym XF86AudioRaiseVolume exec amixer -q set Master 2dB+ unmute bindsym XF86AudioLowerVolume exec amixer -q set Master 2dB- unmute bindsym XF86AudioMute exec amixer -D pulse set Master toggle # Must assign device "pulse" to successfully unmute # Only two level of brightness bindsym XF86MonBrightnessUp exec xrandr --ouptut eDP-1 --brightness 0.8 bindsym XF86MonBrightnessDown exec xrandr --ouptut eDP-1 --brightness 0.5

The only drawback is that the LED indicator on the mute buttons mighty be out of sync with the real software state.

Conclusion

Overall, ThinkPad 13 is a descent laptop for its price range. Ubuntu 16.04 works out of the box. No sweat! If you are looking for a good Linux laptop, but can’t afford ThinkPad X1 Carbon or Dell’s XPS 13/15, ThinkPad 13 might be a good choice.

Categorieën: Mozilla-nl planet

Andy McKay: Manual review of add-ons

Mozilla planet - di, 11/07/2017 - 09:00

As we start to expand WebExtension APIs beyond parity with Chrome, a common theme is appearing in bug comments when proposing new APIs. That theme is something like "we'll have to give add-ons using that API a special manual review".

Put simply, that's not happening. Either we feel comfortable with an API and everyone can use it, or we don't implement it. There won't be any special manual review process for WebExtensions for specific APIs.

Manual review has quite a few problems but bluntly, it costs Mozillians resources and time and upsets developers.

On the cost side, we've had to put an awful lot of developer and reviewer (both paid and volunteer) time into reviewing extensions. There's tools and sites supported by Mozilla to support the review process.

But more than that, loud and clear developers have told us they dislike the review process and complain about it. It causes delays and developers get upset when people (many of whom are volunteer) aren't able to turn around reviews within reasonable time scales.

Further, this makes it harder for developers because it forces developers to upload unobfuscated sources. Something that its getting harder and harder as webpack, browserify and other tools gain in popularity.

And finally manual review isn't perfect. It's hard to review code, look for all the possible security and policy problems and ensure that questionable API didn't do something we felt uncomfortable with.

Manual review has its place in Mozilla, but one thing we shouldn't be do is placing more burdens on the process. We should be aiming to streamline review and ease the burden on reviewers and developers.

The result is we've got to either say no to the API or find a way to make everyone comfortable with the API.

Categorieën: Mozilla-nl planet

Andy McKay: Mail filters

Mozilla planet - di, 11/07/2017 - 09:00

Wil posted on his blog some mail filters he uses to cope with all the incoming mail. Here's a few of mine:

Highlight mentions on mentored bugs:

Matches: from:bugzilla-daemon@mozilla.org "X-Bugzilla-Mentors" Do this: Skip Inbox, Apply label "Bugzilla/Mentored"

Filter out intermittents:

Matches: from:bugzilla-daemon@mozilla.org "X-Bugzilla-Keywords: intermittent-failure" Do this: Skip Inbox, Apply label "Bugzilla/Intermittents"

Filter down by a specific product and component:

Matches: from:bugzilla-daemon@mozilla.org "X-Bugzilla-Product: Firefox" "X-Bugzilla-Component: Extension Compatibility" Do this: Skip Inbox, Apply label "Bugzilla/Extension Compat"
Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 190

Mozilla planet - di, 11/07/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 Friends of the Forest

Our community likes to recognize people who have made outstanding contributions to the Rust Project, its ecosystem, and its community. These people are 'friends of the forest'.

Our this week's friend of the forest is Guillaume Gomez, whose influence is evident everywhere you look in Rust.

Crate of the Week

Sadly, no crate was nominated this week.

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

113 pull requests were merged in the last week

New Contributors
  • boreeas
  • Kornel
  • oyvindln
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 Style RFCs

Style RFCs are part of the process for deciding on style guidelines for the Rust community and defaults for Rustfmt. The process is similar to the RFC process, but we try to reach rough consensus on issues (including a final comment period) before progressing to PRs. Just like the RFC process, all users are welcome to comment and submit RFCs. If you want to help decide what Rust code should look like, come get involved!

The RFC style is now the default style in Rustfmt - try it out and let us know what you think!

An interesting issue:

Good first issues:

We're happy to mentor these, please reach out to us in #rust-style if you'd like to get involved

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

Unsafe is your friend! It's maybe not a friend like you would invite to your sister's wedding, or the christening of her first-born child. But it's sort of the friend who lives in the country and has a pick-up truck and 37 guns. And so you might not want to hang out with them all the time, but if you need something blown up he is there for you.

Simon Heath on game development in Rust (at 38:35 in video).

Thanks to G2P and David Tolnay for the suggestion.

Submit your quotes for next week!

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

Categorieën: Mozilla-nl planet

Niko Matsakis: Non-lexical lifetimes: draft RFC and prototype available

Mozilla planet - di, 11/07/2017 - 06:00

I’ve been hard at work the last month or so on trying to complete the non-lexical lifetimes RFC. I’m pretty excited about how it’s shaping up. I wanted to write a kind of “meta” blog post talking about the current state of the proposal – almost there! – and how you could get involved with helping to push it over the finish line.

TL;DR

What can I say, I’m loquacious! In case you don’t want to read the full post, here are the highlights:

  • The NLL proposal is looking good. As far as I know, the proposal covers all major intraprocedural shortcomings of the existing borrow checker. The appendix at the end of this post talks about the problems that we don’t address (yet).
  • The draft RFC is available in a GitHub repository:
    • Read it over! Open issues! Open PRs!
    • In particular, if there is some pattern you think may not be covered, please let me know about it by opening an issue.
  • There is a working prototype as well:
    • The prototype includes region inference as well as the borrow checker.
    • I hope to expand it to become the normative prototype of how the borrow checker works, allowing us to easily experiment with extensions and modifications – analogous to Chalk.
Background: what the proposal aims to fix

The goal of this proposal is to fix the intra-procedural shortcomings of the existing borrow checker. That is, to fix those cases where, without looking at any other functions or knowing anything about what they do, we can see that some function is safe. The core of the proposal is the idea of defining reference lifetimes in terms of the control-flow graph, as I discussed (over a year ago!) in my introductory blog post; but that alone isn’t enough to address some common annoyances, so I’ve grown the proposal somewhat. In addition to defining how to infer and define non-lexical lifetimes themselves, it now includes an improved definition of the Rust borrow checker – that is, how to decide which loans are in scope at any particular point and which actions are illegal as a result.

When combined with RFC 2025, this means that we will accept two more classes of programs. First, what I call “nested method calls”:

impl Foo { fn add(&mut self, value: Point) { ... } fn compute(&self) -> Point { ... } fn process(&mut self) { self.add(self.compute()); // Error today! But not with RFC 2025. } }

Second, what I call “reference overwrites”. Currently, the borrow checker forbids you from writing code that updates an &mut variable whose referent is borrowed. This most commonly shows up when iterating down a slice in place (try it on play):

fn search(mut data: &mut [Data]) -> bool { loop { if let Some((first, tail)) = data.split_first_mut() { if is_match(first) { return true; } data = tail; // Error today! But not with the NLL proposal. } else { return false; } } }

The problem here is that the current borrow checker sees that data.split_first_mut() borrows *data (which has type [Data]). Normally, when you borrow some path, then all prefixes of the path become immutable, and hence borrowing *data means that, later on, modifying data in data = tail is illegal. This rule makes sense for “interior” data like fields: if you’ve borrowed the field of a struct, then overwriting the struct itself will also overwrite the field. But the rule is too strong for references and indirection: if you overwrite an &mut, you don’t affect the data it refers to. You can workaround this problem by forcing a move of data (e.g., by writing {data}.split_first_mut()), but you shouldn’t have to. (This issue has been filed for some time as #10520, which also lists some other workarounds.)

Draft RFC

The Draft RFC is almost complete. I’ve created a GitHub repository containing the text. I’ve also opened issues with some of the things I wanted to get done before posting it, though the descriptions are vague and it’s not clear that all of them are necessary. If you’re interested in helping out – please, read it over! Open issues on things that you find confusing, or open PRs with suggestions, typos, whatever. I’d like to make this RFC into a group effort.

The prototype

The other thing that I’m pretty excited about is that I have a working prototype of these ideas. The prototype takes as input individual .nll files, each of which contains a few struct definitions as well as the control-flow graph of a single function. The tests are aimed at demonstrating some particular scenario. For example, the borrowck-walk-linked-list.nll test covers the “reference overwrites” that I was talking about earlier. I’ll go over it in some detail to give you the idea.

The test begins with struct declarations. These are written in a very concise form because I was too lazy to make it more user-friendly:

struct List<+> { value: 0, successor: Box<List<0>> } // Equivalent to: // struct List<T> { // value: T, // successor: Box<List<T>> // }

As you can see, the type parameters are not named. Instead, we specify the variance (+ here means “covariant”). Within the function body, we reference type parameters via a number, counting backwards from the end of the list. Since there is only one parameter (T, in the Rust example), then 0 refers to T.

(In real life, this struct would use Option<Box<List<T>>>, but the prototype doesn’t model enums yet, so this is using a simplified form that is “close enough” from the point-of-view of the checker itself. We also don’t model raw pointers yet. PRs welcome!)

After the struct definitions, there are some let declarations, declaring the global variables:

let list: &'list mut List<()>; let value: &'value mut ();

Perhaps surprisingly, the named lifetimes like 'list and 'value correspond to inference variables. That is, they are not like named lifetimes in a Rust function – which are the one major thing I’ve yet to implement – but rather correspond to inference variables. Giving them names allows for us to add “assertions” (we’ll see one later) that test what results got inferred. You can also use '_ to have the parser generate a unique name for you if you don’t feel like giving an explicit one.

After the local variables, comes the control-flow graph declarations, as a series of basic-block declarations:

block START { list = use(); goto LOOP; }

Here, list = use() means “initialize list and use the (empty) list of arguments”. I’d like to improve this to support named function prototypes, but for now the prototype just has the idea of an ‘opaque use’. Basic blocks can optionally have successors, specified using goto.

One thing the prototype understands pretty well are borrows:

block LOOP { value = &'b1 mut (*list).value; list = &'b2 mut (*list).successor.data; use(value); goto LOOP EXIT; }

An expression like &'b1 mut (*list).value borrows (*list).value mutably for the lifetime 'b1 – note that the lifetime of the borrow itself is independent from the lifetime where the reference ends up. Perhaps surprisingly, the reference can have a bigger lifetime than the borrow itself: in particular, a single reference variable may be assigned from multiple borrows in disjoint parts of the graph.

Finally, the tests support two kinds of assertions. First, you can mark a given line of code as being “in error” by adding a //! comment. There isn’t one in this example, but you can see them in other tests; these identify errors that the borrow checker would report. We can also have assertions of various kinds. These check the output from lifetime inference. This test has a single assertion:

assert LOOP/0 in 'b2;

This assertion specifies that the point LOOP/0 (that is, the start of the loop) is contained within the lifetime 'b2 – that is, we realize that the reference produced by (*list).successor.data may still be in use at LOOP/0. But note that this does not prevent us from reassigning list (nor borrowing (*list).successor.data). This is because the new borrow checker is smart enough to understand that list has been reassigned in the meantime, and hence that the borrows from different loop iterations do not overlap.

Conclusion and how you can help

I think the NLL proposal itself is close to being ready to submit – I want to add a section on named lifetimes first, and add them to the prototype – but there is still lots of interesting work to be done. Naturally, reading and improving the RFC would be useful. However, I’d also like to improve the prototype. I would like to see it evolve into a more complete – but simplified – model of the borrow checker, that could serve as a good basis for analyzing the Rust type system and investigating extensions. Ideally, we would merge it with chalk, as the two complement one another: put together, they form a fairly complete model of the Rust type system (the missing piece is the initial round of type checking and coercion, which I would eventually like to model in chalk anyhow). If this vision interests you, please reach out! I have open issues on both projects, though I’ve not had time to write in tons of details – leave a comment if something sparks your interest, and I’d be happy to give more details and mentor it to completion as well.

Questions or comments?

Take it to internals!

Appendix: What the proposal won’t fix

I also want to mention a few kinds of borrow check errors that the current RFC will not eliminate – and is not intended to. These are generally errors that cross procedural boundaries in some form or another. For each case, I’ll give a short example, and give some pointers to the current thinking in how we might address it.

Closure desugaring. The first kind of error has to do with the closure desugaring. Right now, closures always capture local variables, even if the closure only uses some sub-path of the variable internally:

let get_len = || self.vec.len(); // borrows `self`, not `self.vec` self.vec2.push(...); // error: self is borrowed

This was discussed on an internals thread; as I commented there, I’d like to fix this by making the closure desugaring smarter, and I’d love to mentor someone through such an RFC! However, it is out of scope for this one, since it does not concern the borrow check itself, but rather the details of the closure transformation.

Disjoint fields across functions. Another kind of error is when you have one method that only uses a field a and another that only uses some field b; right now, you can’t express that, and hence these two methods cannot be used “in parallel” with one another:

impl Foo { fn get_a(&self) -> &A { &self.a } fn inc_b(&mut self) { self.b.value += 1; } fn bar(&mut self) { let a = self.get_a(); self.inc_b(); // Error: self is already borrowed use(a); } }

The fix for this is to refactor so as to expose the fact that the methods operate on disjoint data. For example, one can factor out the methods into methods on the fields themselves:

fn bar(&mut self) { let a = self.a.get(); self.b.inc(); use(a); }

This way, when looking at bar() alone, we see borrows of self.a and self.b, rather than two borrows of self. Another technique is to introduce “free functions” (e.g., get(&self.a) and inc(&mut self.b)) that expose more clearly which fields are operated upon, or to inline the method bodies. I’d like to fix this, but there are a lot of considerations at play: see this comment on an internals thread for my current thoughts. (A similar problem sometimes arises around Box<T> and other smart pointer types; the desugaring leads to rustc being more conservative than you might expect.)

Self-referential structs. The final limitation we are not fixing yet is the inability to have “self-referential structs”. That is, you cannot have a struct that stores, within itself, an arena and pointers into that arena, and then move that struct around. This comes up in a number of settings. There are various workarounds: sometimes you can use a vector with indices, for example, or the owning_ref crate. The latter, when combined with associated type constructors, might be an adequate solution for some uses cases, actually (it’s basically a way of modeling “existential lifetimes” in library code). For the case of futures especially, the ?Move RFC proposes another lightweight and interesting approach.

Categorieën: Mozilla-nl planet

Mozilla Marketing Engineering & Ops Blog: MozMEAO SRE Status Report - July 11, 2017

Mozilla planet - di, 11/07/2017 - 02:00

Here’s what happened on the MozMEAO SRE team from July 5th - July 11th.

This weeks report is brief as the team is returning from the Mozilla San Francisco All Hands and vacation.

Current work Static site hosting Kubernetes
  • Our main applications are being moved to our new Frankfurt Kubernetes cluster.
Links
Categorieën: Mozilla-nl planet

J.C. Jones: Cutting over Let's Encrypt's Statistics to Map/Reduce

Mozilla planet - ma, 10/07/2017 - 22:54

We're changing the methodology used to calculate the Let's Encrypt Statistics page, primarily to better cope with the growth of Let's Encrypt. Over the past several months it's become clear that the existing methodology is less accurate than we had expected, over-counting the number of websites using Let's Encrypt, and the number of active certificates. The new methodology is more easily spot-checked, and thus, we believe, is more accurate.

We're planning to soon cut-over all data in the Let's Encrypt statistics dataset used for the graphs, and use the new and more accurate data from 3 July 2017 onward. Because of this the data and graphs will show that between 2 and 3 July the count of Active Certificates will fall ~14%, and the count of Registered Domains and Fully-Qualified Domain Names each also fall by ~7%.

Growth Discontinuity

You can preview the new graphs at https://ct.tacticalsecret.com/, as well as look at the old and new datasets, and a diff.

Shifting Methodology

These days I volunteer to process the Certificate Transparency logs for Let's Encrypt's statistics.

Previously, I used a tool to process Certificate Transparency logs and insert metadata into a SQL database, and then made queries against that SQL database to derive all of the statistics we display and use for Let's Encrypt's growth. As the database size has gotten larger, it has been increasingly expensive to maintain. The SQL methodology wasn't intended for long-term statistics, but as with most established infrastructure, it was difficult to carve out the time needed to revamp it.

The revamp is finally ready, using a Map/Reduce approach that can scale much further than a SQL database.

Why did the old way overcount?

Some of the domain overcounting appears to have been due to domains issued SAN-certificates sometimes not being purged when those certificates expire without being renewed. This only happens in cases where the domains are part of a SAN cert, and then the SAN cert is re-issued with a somewhat different set of domains. Those removed, while expired, were still counted. It appears that this seeming-edge case happened quite a lot for some hosting providers.

The active certificate overcounting is in-part due to timing of new certificates being added during nightly maintenance being essentially double-counted. Jacob pointed out that if Let's Encrypt had average issuance, for every hour maintenance takes, the active certificate count would inflate by ~5%. Maintenance with the SQL code took between 1 and 4 hours to complete each night, so this could easily account for the discrepancy in the active certificate count.

There are likely other more subtle counting errors, too.

How do we know it's better now?

The nature of the new Map/Reduce effort produces discrete lists of domains for each issuance day, which are more easily inspected for debugging, so I feel more confident in it. These domain lists are also available as (huge) datasets (which I should move to S3 for performance reasons) at https://ct.tacticalsecret.com/. Line counts in the "FQDN" and "RegDom" lists should match the figures for the most recent day's entry. At least, so far they have...

Reprocessing historical logs?

It's technically possible to re-process the historical data in Certificate Transparency for Let's Encrypt to ensure more accuracy, but I've not yet decided whether I will do this. All the data and software is public, so others could perform this effort, if desired.

Technical Details

The SQL effort moved around through 2016 from various hosting providers to get the best deal on RAM to keep the growing database in check, ultimately moving to Amazon's RDS last winter. A single db.r3.large RDS instance is handling the size well, but is quite expensive for this use case.

The new Map/Reduce effort is currently on a single Amazon m4.xlarge EC2 instance with 150 GB of disk space to hold the 90 days of raw CT log information, the daily summary files, and the 90-day summaries that populate the statistics. This EC2 instance only needs to run about 2 hours a day to catch-up on Certificate Transparency, and then produce the resulting data set. When it needs to scale upward again, I'll likely move to an Apache Spark cluster.

We'll see how fast Let's Encrypt needs it. :)

(Also posted at https://community.letsencrypt.org/t/adjustments-to-the-lets-encrypt-statistics-methodology/37866)

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 10 Jul 2017

Mozilla planet - ma, 10/07/2017 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Mozilla Reps Community: Reps Mobilizer Experiment

Mozilla planet - ma, 10/07/2017 - 15:25

During the second quarter of 2017, and in order to understand how to better identify, recruit and support mobilizers, we decided to run a small experiment with a reduced set of existing “best in class” mobilizers and walk with them during their work supporting technical communities.

Why

Reps program is a program for core mobilizers, who create, grow, sustain and engage communities around Mozilla projects. There are still improvement areas in order to become  a state of the art mobilizer program, so we wanted to identify which are these areas and which are the changes we can implement.

Participants

Bob Chao (Taiwan) – WebVR

Long time contributors, Bob has been empowering and growing different Mozilla related communities in Taiwan, more recently Rust and WebVR.

Full Report

 

Srushtika Neelakantam (India) – WebVR

Deeply involved with the WebVR community since its formation, Srushtika has been empowering the local community in India for a few years now. She has even wrote a book about WebVR.

Full Report

 

Daniele Scasciafratte (Italy) – WebExtensions

Extremely involved contributors, Daniele has been supporting the community in Italy for many years. He has been key to develop the first Addons activity for the MozActivate campaign.

Full Report

Vigneshwer Dhinakaran (India) – Rust

He has been key for the formation and growth of the Rust community in India, he is author of a book about the technology.

Full Report

 

Process Overview

We decided to use a human centered design approach to test this hypothesis. Each project started with a research phase followed by multiple iterations of potential solutions. Each iteration involved testing, reflecting on the learnings and iterating on the approach.

Overall main learnings
  1. A certain degree of understanding of the technology is needed for the mobilizer to be truly effective and understand the communities.
  2. It’s key to devote enough time to do research and understand the local environment and the potential contributors needs
    1. After a solid research, we can start thinking on which are and implement the best channels for communications between the community (sync and async) as well as information distribution (announces, materials…)
  3. There are two important areas when working with technical communities:
    1. Getting people excited about the tech and the community
    2. Keeping people engaged after the main activities take place. The top priority should be designing for the follow-up instead of the activity.
  4. Establishing a direct conversation between mobilizers and the functional area staff is key for having a correct direction and impactful outputs.
    1. Teams that work with more closed tools (slack) presented a bigger challenge

As a result of these learnings we will evaluate a set of recommendations to improve the Reps program and we will share with some early ideas soon on the Reps discourse.

Thank you Vigneshwer, Daniele, Srushtika and Bob, your work is an inspiration to all Reps and to the rest of Mozilla, you have demostrated strong leadership and an impact-oriented strategy thinking that will help others to follow your steps.

Categorieën: Mozilla-nl planet

Pagina's