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 students looking for GSoC-sized projects with us. Each idea includes at least a good description of the project; most also include one or more "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-app-template. 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).
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 visibility. Today, the only such program in the main distribution is rio(1). It would be useful 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. Other potentially useful starting points are Anthony's nile and Sigrid's riow
The cifs client currently in Plan 9 was written long ago and doesn't even appear to support SMB2. There appears to be a reasonable Go library for SMB which could be the basis for an updated SMB client. SMB is one of the more common protocols in use by modern NAS software; getting a modern client would enable interesting usecases such as booting from a minimal ramdisk, then mounting /usr and additional binaries from a SMB share. This project will require the student to familiarize themselves with the SMB library, a Go 9P library, and factotum (for credential storage).
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, but all were done outside the scope of the open source release. It would be useful to have some of these again. Define a few modules and implement them over the summer.
Start with the existing pq distribution and identify one or modules you'd like to add. This project can be relatively simple or very complex, depending on what you decide to implement 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. A good starting point would be to use the proto(2) format (hence the name) as used my mkfs(8) and others, although there are some obvious useful extensions for this application. 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
Your application should describe the set of extensions you think would be useful, and ideally your plan for adding those in after first establishing a working base model.
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.
Add arm64 support to go, for the newer Raspberry Pis which run arm64 versions of plan 9. This would involve:
Setting up a builder and doing the work to integrate it with the go build dashboard is optional but desirable.
A successful project will produce a working port of go which runs on amd64.
Currently, page(1) depends on ghostscript in order to render PDFs. This works, but has several problems:
There's an obvious library to use for this (mupdf), however, it is also not suitably licensed for shipping as part of the base system.
As a result, a new PDF renderer is in order.
Sigrid has done some initial work on writing the basics of a pdffs.
A student working on this will expand on the PDF parser, completing several milestones, time permitting.
This is a big project, and a working pdf2txt would be considered a success for a summer project.
Currently fossil(4) implements console commands, accessed through a pipe in /srv, often accessed manually using con(1). When the commands are scripted, expect(1) must be used to try to pattern-match any text written in response by the server. Venti(8) provides an unauthenticated HTTP service that gives access to a range of statistics. The venti protocol itself implements one or two control requests, notably "sync". The aim is to replace the command and status interfaces in each program by a 9P service. (In fossil's case it would be a different tree from the file storage trees.) That tree can then be mounted and accessed using ordinary commands such as cat and echo, but with proper error reporting (as part of 9P). If there's enough time and interest, we could do the same for cwfs(4). The Plan 9 Ports implementations should also be updated. As a small side-project, when fossil talks to a venti running on the same machine, connect them using a pipe instead of TCP/IP(!).
Project ideas related to the kernel, the various ports, or driver support. Note that ports to new hardware are always interesting, but are particularly challenging for GSoC, given both the timeline and the need to get mentor and student on the same hardware. 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.
9front has implemented a dtrace workalike called dtracy. It's already proved useful for collecting statistics systemwide, but has a number of limitations. Namely:
This project would require the selected student to:
After these two things work, there are a number of other improvements to be tackled, as the student desires:
Project ideas related to the networking, protocols, interoperability, or the web, either in Plan 9 tools providing 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 and a few have already been ported to Plan 9, for example Discount (version 2.1.8, among others). Doing the Inferno version would be a bit more ambitious, as it would involve either porting an existing implementation to Limbo or writing a new one. Use any remaining time to convert any existing wiki docs that need it.
It would be nice for Plan 9 to be able to speak mDNS/Bonjour. When in heterogeneous networks, there are various devices that utilize mDNS/Bonjour for discovery that Plan 9 currently misses. Get the protocol working and integrate it with Plan 9's existing ndb(8) infrastructure.
It would be nice to have an ActivityPub implementation for Plan 9 or Inferno. Projects addressing this could implement the raw protocol as a library, or students more familiar with Plan 9's filesystem model could take a more ambitious towards creating a "socialfs". One interesting challenge is how to integrate the ActivityPub authentication model into factotum(4).
A proposal for this idea should take care to describe the scope of the work to be done very clearly.
The sending, and receiving, requirements of email have changed since upas smtp(8) became a part of Plan 9. As more restrictive filters are in place adding support for DKIM to outgoing messages would offer one option in providing more robust email services for Plan 9 users.
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 operating 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.
Note that porting the existing FXR or LXR are almost certainly not good starting points.
syzkaller is a fuzzer written by Dmitry Vyukov. It's been used to fuzz lots of things, including Akaros, an operating system which includes a large amount of Plan 9 code. It would be good to bring it to Plan 9 proper.
Ideas centered around extending or enhancing authentication and authorization capabilities of the system.
Oauth 2 is used by a wide variety of online services. The protocol is not too complex, especially those parts that make up ~95% of the real-world usage. In Plan 9, authentication is handled by factotum(4), which means that the individual applications don't have to know the details of any particular authentication method to implement it. Unfortunately, the web-focused model of the common use of Oauth 2 creates some interesting challenges for factotum.
This project offers the opportunity to work on a core component used by many parts of the Plan 9 system, and the results would enable better interaction with a whole host of web-based services.
Often, the things you're most motivated to do are the ideas you come up with yourself.
Feel free to apply with your own suggestions!
| Last modified Sat Mar 20 08:24:46 PDT 2021 | [ Current version | Changelog | Create a new page ] |
About the server
|
|