Current Page -
Last modified Fri Feb 20 14:16:21 EST 2015
Welcome, potential GSoC students! We're really excited you're considering working with us this summer. Plan 9 and related technologies cover a huge range of topics. Below we've put together a list of some ideas which we think would be good candidates for stundents looking for summer-sized projects with us. Each idea includes at least a brief description and a list of "sponsors" for the idea (people who've suggested it or volunteered to work with folks on it). Ideas are rated for estimated difficulty from 1 to 5 stars (1=easy, 5=hard) and may contain links to further information or discussion.
Note! We actively encourage students to submit applications for projects not on this list, too. We've accepted such projects most of the years we've participated. Plan 9 (and its cousins) embody a different way of approaching problems, and we get most excited when we see a student (or anyone, for that matter) apply those ideas to their own set of problems. If you're going this route, stop by plan9-gsoc or 9fans to discuss your idea before you get too far into it. Ideally, that discussion will help both you and us identify a potential mentor, which will help your chances of acceptance greatly.
In addition to this ideas page, prospective students should look over our GSoC Student Expectations and be prepared to submit an application matching our GSoC Student Application. For more information, note our general GSoC page.
If you're looking for additional ideas, you might check out the todo, bugs, and ideas lists for Inferno, 9atom, and Acme-SAC (note: AcmeSAC is not in active development, but the ideas list is still interesting). These lists are more general and not everything on them will all be a good size for a summer, but they are good sources of inspiration. Some of the most promising fits are duplicated below. There's also our prior editions of this page: gsoc-2014-ideas, gsoc-2013-ideas, gsoc-2012-ideas, and gsoc-2011-ideas.
If you're a community member and you have an idea you'd be willing to act as mentor for or otherwise help out with, please add it to this page! Just follow the format given and provide a good summary of the project. If you'd like, create and link a wiki page with as much detail as you'd like (but please don't swamp this page). Please only add ideas you might be willing to mentor, co-mentor, or be backup mentor for (or have directly spoken to whoever you're marking down as mentor).
Several of these ideas have the title linked to a page containing more information on the project.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
The Plan 9 windowing system is quite different from X11. Rendering is handled by the kernel graphics driver itself, with a user-mode application responsible for window management issues like placement, sizing, labels, and visability. Today, the only such program is rio(1). It would be fun to have a few alternatives. Design and implement an alternative interface. Some popular ideas include tiling interfaces (similar to acme(1) or X11's wmii or dwm), exploring keyboard-driven control, or touch-based interaction.
A student looking to work on a project in this area should be familiar with Plan 9's existing windowing system, including rio(1) and draw(3), at a minimum. It would be good to also review some of the rio hacks found in the contrib index.
Write a program to interactively gamma correct images. This project may be too small for a summer, so please expand the scope if you plan to work on this.
A good place to start on this project is with mug(1).
This will allow navigation of radar(1) images, or google maps. The idea is to create a standalone program with no knowledge of how image navigation works, but works with an external program to identify and load images to allow for panning and zooming, such as for map navigation for a map too large to display on the screen.
HQX allows for recovery of a decent looking image from a very small and pixelated image. This could be useful stand-alone, or to allow programs like faces(1) to scale their windows. This will allow better interoperability with screens with retina resolution.
The Plan 9 kernel development is great. The kernel's a lot smaller than most of its contemporaries, very modular, with excellent segregation of portable and platform-dependent sections. If you've wanted to try kernel development in the past, but been intimidated by other systems, consider trying it here. In general, anything in here could work for Inferno, as well.
This isn't really a specific project, but Plan 9 is highly portable. We have active 386, amd64, PowerPC, ARM, and MIPS ports, and have had lots of others in the past. Got a device you think Plan 9 or Inferno would be a good fit for? That's probably a good summer-sized project.
Note: the main "gotcha" with these sorts of projects for GSoC is that you need to make sure you and your mentors have the same hardware.
Examples that have come up recently include the Arduino Yún, OLinuXino systems, and the ODROID XU3. 9fans contains innumerable other suggestions. ☺
Write a raid1 driver for sd(3). This driver should use a composable header with a generic format on both disks. (so a raid1 of raid1s ... would be possible.) It should support hot spares, and drive replacement. It should write any failures to any writable disks, so that reboots do not confuse a failed drive with a good one.
You can contrast this with the existing fs(3) driver, which provides a sort of pseudo-raid functionality. It is useful, but very limited.
Project ideas related to the web, either in Plan 9 tools providing web services or in ways to interact with Plan 9 systems.
The wikifs(4) in both Plan 9 and Inferno understand a very small set of cues when generating HTML. That set can be limiting. Replace it with something better, like Markdown. Markdown engines in C already exist, so the Plan 9 part of this shouldn't be too hard. I'd suggest doing the Inferno version as well, to make it a good summer sized project. Use any remaining time to convert any existing wiki docs that need it.
Project ideas related to compilers, development tools, or supporting libraries and infrastructure.
The LXR project has created some very useful tools for cross-referencing different source trees. This idea has been productively expanded by FXR to compare across operationg systems (FXR includes various BSDs, Linuxes, and an old Plan 9 tree). As Plan 9 evolves, it would be very useful to tree maintainers to have an easy way to find, track, and explore differences between trees. This project would be to provide tools to scan different source trees (at least the Bell Labs tree, 9atom, and 9front; possibly Inferno, Plan 9 from User Space, and others) and allow users to see specific changes, perhaps including changes over time. Your proposal should describe the interface you're thinking about providing (file server? web application?), what you think some of the important issues are, and clearly define the scope of work (for example, will you be doing multi-way diffs, or just 1-to-1 comparisons?). Multiple Plan 9 sites would be happy to host the results of this work.
The PIC32 is a mips-like 32-bit processor with a lot of capabilities, and perhaps very useful for sensors, etc. Add a flag to the linker to emit code compatable with the PIC32. This project will require that the student gain some understanding of how Ken's toolchain works before the start of the coding period.
The pq database is very modular. The principle data store is the ev module. The distribution also included a module which speaks a simple protocol to talk to an external pq server. Other modules have existed in the past to retrieve data from other sorts of servers, such as LDAP or SQL servers. It would be useful to have some of these again. Define a few modules and implement them over the summer.
This project can be relatively simple or very complex, depending on what you decide to implemnt and how smart you want to make the module.
Write a 9P file server that can be instructed to create a file tree and associate each node with external directories, files or processes. Very roughly, the prototype file tree instructions might look something like:
/ fst/ = /usr/fst/www/ edit/ snarf > /dev/snarf paste < /dev/snarf mouse | fd0rw /dev/mouse
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
Write a NATP device that can route to the same interface, or between interfaces. The NATP device should be independent of the IP stack, and be able to support both IP4 and IP6.
Very old versions of Plan 9 (1st and 2nd Editions) supported a networking protocol called "nonet", which was a local-network-only protocol designed to provide the absolute minimum needed to trasport 9p. Plan 9 is a great platform for network protocol experimentation. It would be fun to revive this, or make somethig similar. 9p has changed a bit since then, too: what's the modern minimum requirement?
See also cec and aoe for protocols which run on Plan 9 without IP.
It would be nice for Plan 9 to be able to speak Bonjour. When in heterogeneous networks, there are various services that Plan 9 cannot serve without being able to do so. Get the protocol working and integrate it with Plan 9's existing ndb/cs infrastructure.
Our TLS implementaion in libsec(2) is incomplete. In its current state, we can't use it for 9p connectsions to foreign systems. Fix that up. This should be pretty straight-forward if you've done crypo work in the past.
Plan 9 doesn't currently do any flavor of OAuth. This is obviously limiting when dealing with web services. Teach factotum how to speak the protocol. Both sides would be useful, but the client side is particularly interesting, as it will then open up a host of web resources to further Plan 9 development. There are some open questions over how to handle the interaction with the web browser, given that factotum runs in a distinct namespace. A proposal to work on this project should include implementation of a simple client to use the newly-developed capabilities.
Hosted Inferno has been used to build portable applications, especially distributed ones, but it is limited in its support for host devices. Different systems often have rather different APIs to access media devices, for instance. This project would pick one or two of the more eccentric devices from the hosted system - ie. video (from camera and/or video capture), tablet/pen controls w/pressure sensitivity, 3D mice, etc.; write separate host programs that serve a name space using 9P; and then write Inferno applications to use them. In an object-oriented fashion, there could be different instances of this project, with students working on interfaces for different target devices. There might be relevant components in lsub.org's Octopus system.
A previous GSoC project resulted in an iOS port of drawterm, the utility for accessing Plan 9 from foreign systems. This is very useful, but the port has not kept up with subsequent iOS changes. Start by bringing it up to date so it compiles and runs cleanly. Then consider how the port might be improved with additional capabilities. Authentication via Touch ID? Additional devices to expose? Pick a small number of capabilities for a proposal.
