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 contributors 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. New this year, GSoC supports two different sizes of project (~175 hours and ~350 hours), so we've split the list into "medium" and "large" lists. Several items could productively be expanded or trimmed down to move from one category to another; we've included some suggestions there.
If you're looking for additional ideas, you might check out Inferno's issues list, or Acme-SAC's issues list. These lists are much more general and not everything on them will all be a good size for a summer, but they are good sources of inspiration. There's also our prior editions of this page: gsoc-2021-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're willing to mentor (or have directly spoken to whoever you're marking down as mentor).
These are expected to fill aboout ~175 hours of a contributor's time.
The Plan 9 windowing system is quite different from what's typical n other envronments. 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
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 by 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.
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 most likely involve a new Markdown interpreter in Limbo. Ths project should also provde a method to convert existing wiki docs.
This project could be expanded to a larger size with some combination of doing both the Plan 9 and Inferno versions (rather than picking one), and possibly exploring different output types (Anthony has a draft of a version that generates gemtext, for example).
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.
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 final Bell Labs tree, 9legacy, 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.
These are more like the "traditional" GSoC projects, and are expected to fill about ~350 hours of a contributor's time.
fossil(4) implements console commands by a console service served 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(!).
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.
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.
Edwood is a reimplementation of acme in Go. It is currently fully functional but has a number of shortcomings. Most of these are probably decent large-sized projects oon their own, but some might be productively combined:
Syntax coloring
Support for colored glyphs is probably a decent mid-sized project on its own; support for external coloring servers might be large on its own.
Rich textAcme's always had just a single font in each frame; adding support for variable fonts in a single frame would be a good large project. Supporting external layout servers could be another interesting large project.
GPU-based rendering (large) Remote display [split like Sam]sam(1) has long had a "-r" which lets you run the display portion of the proogram on a different host than the actual edting, which is useful in lots of envronments. Acme's never had this, which is a shame. Add it.
It could also use a port back to Plan 9. Win needs a decent Go implementation.
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 Feb 19 22:41:09 PST 2022 | [ Current version | Changelog | Create a new page ] |
About the server
|
|