Plan 9 from Bell Labs

Plan 9 is an operating system from Bell Labs, originally written by many of the same folks who wrote Unix. It uses a common protocol for resource access, extending the concept of “everything is a file” much further than Unix was able to. Its light weight and pervasive resource sharing capabilities make it well suited for a variety of purposes; it currently runs on supercomputers and embedded systems, workstations and appliances.

Inferno is a sister project to Plan 9, taking the same core ideas (and much of the kernel code), adding a virtual machine, and allowing the system to run on even lighter hardware and as an application on top of other operating systems. User-mode code is written in the concurrent programing language Limbo.

Plan 9 and Inferno have spawned a number of other projects, including Plan 9 from User Space (a port of many of the Plan 9 libraries and utilities to POSIX environments), 9vx (a virtual Plan 9 kernel using the vx32 VM), several Inferno derivatives, and several applications using the 9p protocol in various contexts.

In GSoC, we are serving as an umbrella organization for technologies related to or deriving from the operating system Plan 9 from Bell Labs. Most of our projects center around either the Plan 9 or Inferno operating systems, but we’re open to proposals from any technology in the family.

http://9fans.net/

LPL 1.02

We hope to offer students exposure to some novel approaches to well-known problems, while gaining for ourselves the opportunity to attract new ideas and new contributors.

Plan 9 and related technologies solve several common problems in ways that are very different from common practice, often with remarkable results. The concurrent programming model we use is well-established in Computer Science theory, but has (until recently) been largely neglected in most of the industry. The distributed computing model we use relies on a simple protocol applied pervasively, rather than a plethora of special-purpose protocols. Even small things like history and job control get solved at different places in the system. We believe this elegant and powerful approach can be very educational for students.

Our novel approach to solving these problems often yields very interesting results when students can apply the ideas to their own problems or areas of interest. We love to get students thinking about different approaches to things, and especially love to see projects come from outside our own suggestions. The students who’re most likely to stick with the community are those who find early on that they can use Plan 9 to help them solve real problems.

We have participated twice.

In 2007, we got lots of things wrong, resulting in a very mixed experience for everyone involved. We were lucky enough to get some very good new community members out of the experience, but our project success rate was poor, as was subsequent integration of both code and students.

In 2009, we took a much better approach to the opportunity, with better results for almost everyone involved. Most projects went very well, pretty much as planned. Two failed, one due to the student getting another job and one for personal reasons. Our improved internal communication - both between mentors and students and mentors and admins - allowed us to detect problems earlier and react to them. One project in particular was in jeopardy by midterms, but thanks to good internal communication and quick responsiveness, we were able to recover. The majority of our 2009 students - including one of our two failed projects - remain active community members today.

The primary lesson from last year was in the value of frequent mentor-student and mentor-admin communication (thankfully, this was a lesson reinforced by success rather than failure in this case). We were also reminded again of the value of the structure of the program and the reality of deadlines.

2007: 8/13 2009: 5/7

Not applicable.

http://www.plan9.bell-labs.com/wiki/plan9/gsoc-2010/index.html

9fans@9fans.net gets discussion for Plan 9 itself and various related things, including some overlap with other lists. inferno-list@vitanuova.com is the main list for Inferno discussion, and plan9port-dev@googlegroups.com is used for Plan 9 from User Space.

Discussion of GSoC-specific issues - logistics, project ideas, mentor pairing, &c - mostly happens on plan9-gsoc@googlegroups.com.

On freenode, #plan9, #inferno, #plan9-gsoc

Most of the year-round discussion happens in #plan9 or #inferno, for the respective technology set. Discussions specific to GSoC projects or logistics happen in #plan9-gsoc. We also have a mentors-only channel.

Name and Email Address

Your full name and a valid email address. This will be our primary way of contacting you initially.

Chat/IM IDs

Provide the ID and the network it’s on, for example “afsorace on AIM, anth on freenode”. You’ll need to provide at least one of these, and are strongly encouraged to be on freenode (IRC) as a lot of project discussions happen there. Once we get to that stage, you’ll need to agree with your mentor on some real time method of communication.

Phone number

We’ll only use this after exhausting all other means of contact (and once before accepting students, to verify it). Please enter a full international phone number.

Bio, Resumé, or C.V.

Help us get to know you better. Tell us about your skills, experience, and interest. We’d like to see some pointers to code you’ve written, either from your own projects or projects you’ve contributed to. We’re especially interested in things which help us see why you’re a good match for the particular project you’re applying for.

Why are Plan 9 and related technologies interesting to you?

Plan 9 has lots of great ideas, but they’re different from what you find in other environments; we want to make sure you’re not coming in expecting Unix. What is it about Plan 9 (or related technologies) that you find intriguing? Have you used them before? Which ones (Plan 9, Inferno, v9fs, &c)? Have you read the papers?

Proof of Installation

We want to ensure that you understand the basics of using the system, and are not going to be surprised by not finding another Unix clone. There are a few easy ways to demonstrate the familiarity we’re looking for. Bell Labs maintains a system, sources.cs.bell-labs.com, with public 9P access. Demonstrate that you’ve got a working Plan 9, Inferno, or Plan 9 from User Space installation: submit a patch (just adding your face to the /lib/faces database would be fine, although actual code would be even better) or just append your name to /n/sources/contrib/anothy/tmp/gsoc. Don’t be afraid of asking for help; stop by

plan9 on Freenode and we’ll help you out.

Project Title and Description

Tell us about the specific project you’d like to work on. If you’ve picked something from our ideas page, please make the title match what’s on that page. Regardless, you should be able to describe the project in your own words (even if it’s just to show us you understand what an existing idea is looking for). Especially if your proposal is your own idea, be sure to include enough detail so that we understand your idea.

Suggested Mentor

If you’ve spoken to someone in our community about this project, and they’ve agreed to mentor you for the summer, list them here. This is optional, but is particularly valuable if you’re proposing a project not on our list. If it is on our ideas list, we can mostly figure this out.

We look for people with long, positive relationships with our community. Technical expertise is obviously important, but as this is a community-building exercise rather than just hiring a bunch of temps, community involvement trumps technical brilliance.

On the technical side, we look for mentors with relevant domain experience. Partly due to Plan 9’s function as a general-purpose operating system, our community benefits from a wide range of users, from folks building supercomputers to appliances. Finding a mentor who’s familiar not only with Plan 9 but with the area the student will be working in is key.

We also have a mild selection bias towards folks who either have participated as mentors before or have experience in academic environments. After our experience in 2007 of finding some technically wonderful mentors who weren’t so great at working with students, this gives us more confidence in our selections.

Prevention is the first line of defense. We’re very clear with our mentors that they are expected to have pretty much constant communication with their students, and that any lapses should be flagged as soon as they’re noticed. We encourage all our students to be on IRC regularly and watch for changes there. Mentors are advised that real-time communication (like IM) can usually do a better job of verifying student activity than asynchronous means (like email).

In addition to email and IM addresses, we collect phone numbers as a final safety net. We verify them before students are accepted.

Again, prevention is the most important step. We’ve learned well the importance of selecting mentors who are both committed and capable (as mentors, not just technically). This was a problem for us in 2007, but not at all in 2009.

We also mandate regular communication between the mentors and admins (at a minimum; preferably with the rest of the community, as well) to detect any problems early so we can start to address them before they impact any student’s experience.

As a further safety net, each project will be assigned a backup mentor who will be following progress along with the mentor. Also, when we had disappearing mentors in 2007, our community, particularly via IRC, was able to pick up the slack well.

Good mentor selection is an important part of this. By picking mentors with strong existing community ties, we encourage students to “piggy-back” on those.

In addition, over the past 2-3 years, we’ve seen the growth of a number of different projects for related technologies, especially Inferno branches (but also within Plan 9).

The visible output is, of course, the code. Seeing that code have a future is the best way to get students excited about continuing with the project. We have a defined upstream path for the three major projects under our umbrella. Not every student project ends up in the main Plan 9 distribution, but we’ve now got several examples of other places for code to live. Some code from previous summer projects have continued outside the main distribution, and we expect that to continue.

Continuation in the community also depends largely on relationships formed during the summer. We encourage our mentors to stay in contact with their students beyond the summer. Also, encouraging our students to participate in discussions on IRC before and during the coding period has produced good results with bonding with the broader community. The IRC channel has also been very good for supporting, discussing, and exploring ideas and alternatives that don’t end up in the mainline distribution.

We’re very thankful for the chance to participate in 2009, and hope that we’ve demonstrated our ability to provide a productive and enjoyable experience for students. We’re looking forward to an even better year in 2010.

Also, you all rock!