Current Page -
Last modified Thu Feb 19 15:08:03 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 (mostly 1st Edition) 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?
Interoperability with the old nonet isn't important (no system has been running that for over two decades) - it is the ideas that are interesting. The old nonet implementation can be found online: devnonet.c and stnoether.c.
See also cec(8) and aoe(3) for other examples of protocols which run on Plan 9 without IP. There are, of course, modern alternatives to TCP with more practical application (SCTP, XTP,
SST, CSP, &c) that are interesting, but they're all much larger, and likely too much for a summer.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 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.
This project will require some experience with iOS development and a working knowledge of Objective C.
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 (mostly 1st Edition) 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?
Interoperability with the old nonet isn't important (no system has been running that for over two decades) - it is the ideas that are interesting. The old nonet implementation can be found online: devnonet.c and stnoether.c.
See also cec(8) and aoe(3) for other examples of protocols which run on Plan 9 without IP.
There are, of course, modern alternatives to TCP with more practical application (SCTP, XTP, SST) that are interesting, but they're all much larger, and likely too much for a summer.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 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.
This project will require some experience with iOS development and a working knowledge of Objective C.
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
(mostly 1st Edition) 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?Interoperability with the old nonet isn't important (no system has been running that for over two decades) - it is the ideas that are interesting. The old nonet implementation can be found online: devnonet.c and stnoether.c.
See also cec(8) and aoe(3) for other examples of 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 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.
This project will require some experience with iOS development and a working knowledge of Objective C.
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(8) and aoe(3) for other examples of 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 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.
This project will require some experience with iOS development and a working knowledge of Objective C.
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 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.
This project will require some experience with iOS development and a working knowledge of Objective C.
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.
This project will require some experience with iOS development and a working knowledge of Objective C.
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.
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.
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.
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.
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.
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.
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, it is highly recommended you 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.
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.
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, it is highly recommended you 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.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of ws(3) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
Project ideas related to compilers, development tools, or supporting libraries.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
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, it is highly recommended you 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.
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.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of
ws(3) and wsprint(8), and a set of regression tests to track lock latency.Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
Project ideas related to compilers, development tools, or supporting libraries.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
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, it is highly recommended you 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.
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.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
Project ideas related to compilers, development tools, or supporting libraries.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
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, it is highly recommended you 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.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
Project ideas related to compilers, development tools, or supporting libraries.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
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, it is highly recommended you 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.
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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
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, it is highly recommended you 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.
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 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
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, it is highly recommended you 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.
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 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
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.
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.
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 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
Welcome, potential GSoC students! We're really excited you're considering working with us this summer. Plan 9
If you're a mentor or other community member with an idea you'd be interested in helping with, please add it here.
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.
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.
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 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
Welcome, potential GSoC students!
We're really excited you're considering working with us this summer. Plan 9If you're
a mentor or other community member with an idea you'd be interested in helping with, please add it here.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.
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, 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.
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 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
Welcome, potential GSoC students!
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
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 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
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 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
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 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.
Very old versions of Plan 9 (1st and 2nd Editions) supported a networking protocol called "nonet". Plan 9 is
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
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 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 related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
Web-related ideasIdeas 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.
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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
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
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
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
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
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.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Invent a mechanism for implementing MCS locks with a compatable interface to lock(9). This requires exploting the fact that plan 9 locks must be acquired and released on the same processor. The student may wish to explot the fact that locks are typically stacked.
Rewrite the scheduler to be fundamentally per-processor, instead of per machine.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
Project ideas related to compilers, development tools, or supporting libraries.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
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
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Invent a mechanism for implementing MCS locks with a compatable interface to lock(9). This requires exploting the fact that plan 9 locks must be acquired and released on the same processor. The student may wish to explot the fact that locks are typically stacked.
Rewrite the scheduler to be fundamentally per-processor, instead of per machine.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
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.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
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
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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, 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.
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.
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. 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-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, 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're willing to mentor (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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Invent a mechanism for implementing MCS locks with a compatable interface to lock(9). This requires exploting the fact that plan 9 locks must be acquired and released on the same processor. The student may wish to explot the fact that locks are typically stacked.
Rewrite the scheduler to be fundamentally per-processor, instead of per machine.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
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.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
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
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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. 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-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, 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're willing to mentor (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.
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.
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. 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-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, 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're willing to mentor (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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Invent a mechanism for implementing MCS locks with a compatable interface to lock(9). This requires exploting the fact that plan 9 locks must be acquired and released on the same processor. The student may wish to explot the fact that locks are typically stacked.
Rewrite the scheduler to be fundamentally per-processor, instead of per machine.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
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.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
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
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
If you're interested in mentoring an idea, please add it here (and if it's also listed below, remove it from there so we don't double up). I'll (Anthony) be fixing this page up from now until the eval period is over, but the more community members we can get contributing the better.
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.
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. 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-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, 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're willing to mentor (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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Invent a mechanism for implementing MCS locks with a compatable interface to lock(9). This requires exploting the fact that plan 9 locks must be acquired and released on the same processor. The student may wish to explot the fact that locks are typically stacked.
Rewrite the scheduler to be fundamentally per-processor, instead of per machine.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
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.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
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
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
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.
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. 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-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, 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're willing to mentor (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.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
The Raspberry Pi port, initially done by Richard Miller, has proven a very popular platform for Plan 9. It works well, but there is more that could be done with the hardware. We don't have any audio support, for example, and more could be done with the video driver. If you want to go a bit farther afield, we're not doing anything with the DSI or CSI connectors (nobody really is), although that'd involve getting the right hardware. It would be particularly fun to do a project involving a creative use of the GPIO pins.
Write a lock analyzer that can detect conflicting lock usage. For example, if lock a is held when lock b is acquired, then it would be invalid to acquire lock b then lock a in another codepath.
This project is advanced in concept, but the code should be relatively straightforward.
Write a lock timing analyzer in the spirit of devws(9) and wsprint(8), and a set of regression tests to track lock latency.
Invent a mechanism for implementing MCS locks with a compatable interface to lock(9). This requires exploting the fact that plan 9 locks must be acquired and released on the same processor. The student may wish to explot the fact that locks are typically stacked.
Rewrite the scheduler to be fundamentally per-processor, instead of per machine.
Use lock analysis and automated test scripts to tune qmalloc(9), for example by providing a different set of quick-list buckets. alternatively, write a new malloc.
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.
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.
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.
Most of the work is done, but there are still some lingering issues. This is rated most difficult because this project is going to require modification (or new implementation) of the lowest levels of the go runtime.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
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
Several years ago, R C Bilson contributed a suite of programs that provided a Venti-like service using Amazon's S3. (Venti is Plan 9's archival storage system, and the Plan 9 file system fossil(4) sits above venti.) Let's pull it out of the attic, dust it off, and set to work improving it (it has got a bugs list). There are many possible directions, which can depend on the interest and experience of the student; an obvious one is adding caching to improve performance. One application would be to provide archival storage for (say) Raspberry Pi running Plan 9, or an Inferno system with a Venti client.
Venti is a Plan 9 archival data service. It would be useful for Inferno to have a simple file system implementation that uses an existing Venti for its archive and initial state. It would have a basic, straightforward implementation. Some might say naive, but Plan 9's own Fossil is fairly complicated, at least for a summer project, and in retrospect has some limitations. It could store or cache file system metadata and data locally (and optionally separately). It would allow disconnected operation. It could be fairly slow (raw performance doesn't matter at this stage).
Reading vcards and calendar information by hand is difficult, as is switching to another platform. Implement a vcard reader and calendar that work well with ned(1) and acme mail.
Ideas centered around network protocols, interoperability, and communication, including with foreign systems.
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.
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.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Project ideas that don't fit into - or span multiple of - the above catagories.
The Arduino Yún is essentially two systems in one: a MIPS-based Linux system -- Linino -- and a more-or-less traditional Arduino on the same board. The project would involve porting Plan 9 From User Space -- a.k.a plan9port -- to Linino and writing a 9p fileserver that exposes the Arduino's capabilities, such as access to the pins. It is important to also write a few sample applications showing the typical ways the fileserver is used. This project gets the extra fun of defining the interface method, since there isn't something specific the student needs to try and match. Plan9port makes this project relatively straight forward; the more ambitious option would be to replace the Linux installation outright with a Plan 9 installation.
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.
Many x86 devices such as the Intel Quark no longer support BIOS booting methods. Implement a UEFI boot loader capable of loading Plan 9, and modify the x86 kernels to be compatable with this new loader (if required).
