Plan 9 is applying to GSoC again! The application period closes on Monday, and our formal application is in. As is the case every year, the most critical part of an application is the org's ideas page[1]. We'd love additional fleshed-out contributions for that. Since we had a little confusion on this last year, please note that we're looking specifically for well-developed ideas that would be good summer-sized projects for new contributors, from folks willing to mentor those projects (rather than "it'd be neat if someone would do X"); see the existing ideas page for examples (some of which are more developed than others, certainly!). If you're interested in mentoring, please let me know! Bringing your own project idea is great, but we can also use more experienced, eager folks to pair up with new contributors on other projects. We've got an overview page[2], and all the program details are on Google's GSoC page[3], and you might be interested in the program timeline[4] in particular. One other note, for those of you who're familiar with the program, there are a few notable changes, which Google goes into in a post[5] about them. In brief, though: - The program is now open to a lot more than just formal students - There are two project sizes: large ("traditional") and medium (like last year's) - The timing of the work is more flexible. I think these are all great (even if they make a little more work for admins and mentors!) and should be nice additions to the program. Your friendly neighborhood org admin, Anthony [1] https://p9f.org/wiki/gsoc-2022-ideas/index.html [2] http://p9f.org/wiki/gsoc/index.html [3] https://summerofcode.withgoogle.com [4] https://developers.google.com/open-source/gsoc/timeline [5] https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M45b7473d430aea7c8b74b8ab Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
On 2/18/22, Anthony Sorace <a@9srv.net> wrote: > Plan 9 is applying to GSoC again! > > [ ... ] I've done a bit of work on P9P's fontsrv as well as a version - somewhat mysteriously different - "ported" to Plan 9. If we can debate the pros and cons of effectively replacing the static availability of fonts in Plan 9 with a networked TrueType font server (as I am largely using presently, to some extent), I believe some work could be dedicated in turning fontsrv into an integral part of the Plan 9 distributions. I'll be happy to assist with mentorship in this. I'd no doubt learn much myself in the process. Lucio. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M23f605304b6f1f5c7288abc1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Good morning, I skimmed through the ideas page as well as the mails in this thread and I wanted to share my thoughts and ideas. (1) I am working on a port of 9front to the pinephone smartphone. Although it is still a long way to go I believe the project can be very interesting for UI ideas and implementations. This would also fit tbe rio alternatives idea. Let me quickly explain. Plan 9 has a unique user interface built from many components. We have heavy use of three mouse buttons, many text-based interfaces (also counting acme tags, for example), system-wide plumber support, only to mention few of those. However, some of these aspects don't make much sense on a touch device due to big thumbs and the nature of touchscreens. The idea for this would be designing an integrated, Plan 9-worthy touchscreen rio replacement for mobile devices. Ideally it can coexist with rio (i.e run inside rio windows and rio can run inside "this-window-manager" windows) and is fully compatible with existing graphical UI applications (using standard draw routines). Although the software can currently not be tested on the pinephone (I'm still working on the kernel) there are some devices with rudimentary touchscreen support (I have a working thinkpad twist with 9front) we can use for testing, and some functionality can be tested inside scaled rio windows on common Plan 9 systems. (2) Under similar circumstances (mobile device with touch input) another project might be some kinda graphical (rc) shell interface. I have an idea, and we also discussed ideas on the discord server. (3) A high-level filesystem interface for UI widgets. Many modern UI layouts can be described as a hierarchy of containers. The UI filesystem would start as an empty window, which is reflected by an empty filesystem. The user could create widget containers (hbox, vbox) by creating directories and files, as well as input boxes, buttons and more by creating files. The hierarchy would directly reflect the drawn window. The user can listen to files for button interaction and write text to labels etc.. (4) A filesystem that filters a namespace, but the file contents and not the namespace. The idea is to have a filesystem like exportfs, however, it doesn't just represent the files as is, but applies user-defined filters to the filenames/paths as well as the file contents. Imagine you have a namespace which contains markdown files that end with .md. Using this overlay filesystem you can present the same namespace, but convert the filenames using sed (from .md to .html) and when reading, the file contents (from markdown syntax to html syntax). The filesystem would be very powerful for exposing plain text data as html, encapsulating data into some predefined layout, and much more. It could essentially make any plain text filesystem available as regular web-friendly html files, convert troff source to postscript, convert plan 9 images to png, and much more. You can even present device files as json for modern web applications. Caching file contents can improve performance and reduce load. (5) Ringfs. This is a very small project and also the least powerful as far as I can say now. The general idea is that the filesystem presents the created files and when reading a file the contents point to the next file in the "ring" in alphabetical order. It's probably best explained using the following shell interaction: ; touch fileA fileB fileC ; cat fileA fileB ; cat fileB fileC ; cat fileC fileA The project is very small and probably too simple for a GSoC project. These are some ideas I thought about in the last months. Some are very small and I can imagine mentoring these smaller projects if it's not to hard. My time is rare (as for most of you I guess) and I never mentored any programmer, so I guess I'd ask more experienced people now and then. Personally I like all of these ideas and would like to work on all of them if I had enough time. sirjofri ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-M7eef49e9a147609a6fee4160 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #1: Type: text/plain, Size: 1967 bytes --] On Feb 19, 2022, at 3:02 AM, sirjofri <sirjofri+ml-9fans@sirjofri.de> wrote: > (4) A filesystem that filters a namespace, but the file contents and not the namespace. > > The idea is to have a filesystem like exportfs, however, it doesn't just represent the files as is, but applies user-defined filters to the filenames/paths as well as the file contents. > > Imagine you have a namespace which contains markdown files that end with .md. Using this overlay filesystem you can present the same namespace, but convert the filenames using sed (from .md to .html) and when reading, the file contents (from markdown syntax to html syntax). > > The filesystem would be very powerful for exposing plain text data as html, encapsulating data into some predefined layout, and much more. It could essentially make any plain text filesystem available as regular web-friendly html files, convert troff source to postscript, convert plan 9 images to png, and much more. You can even present device files as json for modern web applications. May be create a generic filter-fs that can be controlled with a script that can be updated via a control interface? Almost a mkfile like script so if a rule exists for .md -> .html, any listing will show foo.html instead of foo.md. Reading foo.html will transparently invoke a conversion program. You can get pretty clever and may be even install a src dir under /bin this way to build binaries on the fly! Or even just the presence of a mkfile in a filtered directory would be enough for this behavior. Taking this further, an installation of a new machine can be made instantaneous! Just use a local cache for all the binaries as they get built! Obviously this should be called mkfs :-) ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T745cda5087701a0d-Me5af03b18c19111f8ced87fb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription [-- Attachment #2: Type: text/html, Size: 2950 bytes --]
Quoth Bakul Shah <bakul@iitbombay.org>: > On Feb 19, 2022, at 3:02 AM, sirjofri <sirjofri+ml-9fans@sirjofri.de> wrote: > > (4) A filesystem that filters a namespace, but the file contents and not the namespace. > > > > The idea is to have a filesystem like exportfs, however, it doesn't just represent the files as is, but applies user-defined filters to the filenames/paths as well as the file contents. > > > > Imagine you have a namespace which contains markdown files that end with .md. Using this overlay filesystem you can present the same namespace, but convert the filenames using sed (from .md to .html) and when reading, the file contents (from markdown syntax to html syntax). > > > > The filesystem would be very powerful for exposing plain text data as html, encapsulating data into some predefined layout, and much more. It could essentially make any plain text filesystem available as regular web-friendly html files, convert troff source to postscript, convert plan 9 images to png, and much more. You can even present device files as json for modern web applications. > > May be create a generic filter-fs that can be controlled with a script that can be updated via a control interface? Almost a mkfile like script so if a rule exists for .md -> .html, any listing will show foo.html instead of foo.md. Reading foo.html will transparently invoke a conversion program. You can get pretty clever and may be even install a src dir under /bin this way to build binaries on the fly! Or even just the presence of a mkfile in a filtered directory would be enough for this behavior. Taking this further, an installation of a new machine can be made instantaneous! Just use a local cache for all the binaries as they get built! Obviously this should be called mkfs :-) > See, for example, execfs, here: http://felloff.net/usr/cinap_lenrek/ I use it for https://shithub.us, though it has a number of limitations. Using it as a starting point, but replacing regexes on the path with a more powerful language, would probably get quite close to what's described here. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T745cda5087701a0d-M9791daa4c063f7ae31acf876 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Quoth Anthony Sorace <a@9srv.net>: > Plan 9 is applying to GSoC again! > > The application period closes on Monday, and our formal application is in. As is the case every year, the most critical part of an application is the org's ideas page[1]. We'd love additional fleshed-out contributions for that. Since we had a little confusion on this last year, please note that we're looking specifically for well-developed ideas that would be good summer-sized projects for new contributors, from folks willing to mentor those projects (rather than "it'd be neat if someone would do X"); see the existing ideas page for examples (some of which are more developed than others, certainly!). > > If you're interested in mentoring, please let me know! Bringing your own project idea is great, but we can also use more experienced, eager folks to pair up with new contributors on other projects. > > We've got an overview page[2], and all the program details are on Google's GSoC page[3], and you might be interested in the program timeline[4] in particular. > > One other note, for those of you who're familiar with the program, there are a few notable changes, which Google goes into in a post[5] about them. In brief, though: > > - The program is now open to a lot more than just formal students > - There are two project sizes: large ("traditional") and medium (like last year's) > - The timing of the work is more flexible. > > I think these are all great (even if they make a little more work for admins and mentors!) and should be nice additions to the program. > > Your friendly neighborhood org admin, > Anthony > > [1] https://p9f.org/wiki/gsoc-2022-ideas/index.html > [2] http://p9f.org/wiki/gsoc/index.html > [3] https://summerofcode.withgoogle.com > [4] https://developers.google.com/open-source/gsoc/timeline > [5] https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html While pdffs project that was proposed last year didn't get accepted, the student that proposed it still made a lot of progress, and now that code can fully extract text from PDFs. It may be worth trying to carry that forward. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td4449edc4863e16e-Mface259247e81fb72187850d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription