Re: [9fans] Plan 9 Applying to GSoC 2021
Hello ~vidak, Quoth ~vidak : > I am currently a computer science undergrad, and I have a project > idea. Me and a few friends from the fediverse were thinking of > implementing the ActivityPub protocol (mastodon/pleroma) into plan9 as a > kind of 'social file system', or 'socialfs'. Iirc there's someone writing an ActivityPub/mastodon client for 9. I think it was julienxx²? Maybe check it out? > The idea, as I take it, would be to introduce a limited form of > hypertext into the plan9 distributed filesystem. It would also allow > access into a somewhat mature free software social network. I've written my bachelor thesis¹ about a potential hypermedia system for Plan 9. I can send it to you as a private message if you are interested in it. It's not specific to social networks, but there might be interesting ideas. I also mentioned other interesting filesystem stuff like LisFS (which provides some nice search functionality based on filesystems and regular expressions). > There are various languages we were thinking of doing the implementation > in, ultimately some flavour of scheme. Perhaps one that could compile to > C. I ♥ C, but I don't have to decide anything here. sirjofri — ¹ I plan to publish the thesis when I'm done studying, which will be in march. Until then I can't really publish it. ² julienxx is on mastodon: @julie...@fedi.9til.de . -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T00b3dc89a8df295a-M81ba032c01832102a8494164 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Plan 9 Applying to GSoC 2021
This has been my dream for the past year, I am a student(36yrs) , coming to programming after a 20year break , I was a musician for the last 6 years. I have a diploma in C from when I was 13 , other than that I'm drop out, so no Uni Degree(just a diploma in Biotech). Though I had a dream of creating an open source formally verified Linear algebra library for plan 9 , I joined the LAFF courses on edx , and though I'm early into them , I'm doing well . I don't know if I will be able to join / be accepted as a student Google’s Summer of Code program. But this would really be a dream come true! -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T00b3dc89a8df295a-M23a9c5017dc3bbb89ea74261 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Plan 9 Applying to GSoC 2021
On Jan 31, 2021, at 4:36 PM, ~vidak wrote: > > There are various languages we were thinking of doing the implementation > in, ultimately some flavour of scheme. Perhaps one that could compile to > C. There is Nils Holm’s s9fes Scheme. It is strictly an interpreter but easy to extend with C code. See https://github.com/bakul/s9fes. I had added some support for plan9 specific syscalls — more may be needed depending on what you want to do. Chibi-Scheme supposedly works on plan9 though I haven’t played with it in years. I imagine by socialFS you want to see your connections, posts, feeds, likes etc. as files or directories? Everything but the actual content display? Sounds like a fun project! -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T00b3dc89a8df295a-Maa171945b0f52c8946a6d2ff Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] GSoC 2021 project ideas (WAS: Re: Plan 9 Applying to GSoC 2021)
Anthony Sorace writes: > Hello! After a few years away, we’ll be applying to Google’s Summer of Code > program again this year. ... > 1. Project ideas. One of the key parts of the application is the > project ideas page. If you’ve got ideas that seem like they’d be a Plan 9-related: (1) Porting the Plan 9 kernel to a microkernel architecture, such as Mach. This would give Plan 9 instant access to the whole range of hardware supported by the underlying microkernel. (2) A Zoom/video conferencing application for Plan 9. Enough said. :) (3) Happauge/Brooktree BTTV/video capture drivers. AFAIK, Plan 9 can only use USB Web cams. (4) Port SANE (Scanner Access Now Easy) tools as a Plan 9 file system. That would give Plan 9 instant access to a huge range of flatbed & sheet-fed document scanners. (5) An NFS sever for Plan 9. Unix machines have a lot of trouble handling edge cases encountered on 9P filesystems (such as the number of hard links to directories). An NFS server would make it much easier for Unix/Linux and Plan 9 to get along happily. (6) Incorporating Inferno's Dis virtual machine into the Plan 9 kernel, so Plan 9 can run Dis binaries natively, without having to run the Inferno emulator (emu) as a user process. Inferno-related: (A) A 64-bit version of Dis, which was designed as a 32-bit (31-bit?) architecture. (B) Porting Inferno to modern video game consoles, such as the Nintendo Switch family. Coolness. (C) Creating a secure version of Dis. The way that Dis handles allocated/freed memory isn't particularly safe, and can leak sensitive data (such as encryption keys). It doesn't have a way to whiten memory, or to mark ranges of memory as non-swappable. This could be done by adding new VM instructions, or on a per-module basis by adding new module flags. (D) Porting Nemo/LSUB's "OSHAD" to Plan 9. OSHAD is an authentication system (implemented in Inferno) which allows you to provide passwords or acknowledge actions from a separate, wireless hand-held device. (E) A postscript/PDF viewer for Inferno. Enough said. :) Android-related: (a) An Android "app" that presents an Android phone's telephone and SMS messaging facilities as a 9P filesystem. This would enable Plan 9 and Inferno applications to place/receive voice calls and send/receive text messages across a network. This could be done by extending bhgv's existing Android port of Inferno, or as a separtate, stand-alone server app. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1c300cdbd9941edb-M8dc3d53ad2fd15c95abf0584 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] GSoC 2021 project ideas (WAS: Re: Plan 9 Applying to GSoC 2021)
someone at the land (peter bosch?) dis a haupage video capture card. i am pretty sure i have a copy of the driver and user level app somewhere. this worked on an old pci card i had at one time. -Steve On 1 Feb 2021, at 8:32 pm, cigar562hfsp952f...@icebubble.org wrote: Anthony Sorace writes: > Hello! After a few years away, we’ll be applying to Google’s Summer of Code > program again this year. ... > 1. Project ideas. One of the key parts of the application is the > project ideas page. If you’ve got ideas that seem like they’d be a Plan 9-related: (1) Porting the Plan 9 kernel to a microkernel architecture, such as Mach. This would give Plan 9 instant access to the whole range of hardware supported by the underlying microkernel. (2) A Zoom/video conferencing application for Plan 9. Enough said. :) (3) Happauge/Brooktree BTTV/video capture drivers. AFAIK, Plan 9 can only use USB Web cams. (4) Port SANE (Scanner Access Now Easy) tools as a Plan 9 file system. That would give Plan 9 instant access to a huge range of flatbed & sheet-fed document scanners. (5) An NFS sever for Plan 9. Unix machines have a lot of trouble handling edge cases encountered on 9P filesystems (such as the number of hard links to directories). An NFS server would make it much easier for Unix/Linux and Plan 9 to get along happily. (6) Incorporating Inferno's Dis virtual machine into the Plan 9 kernel, so Plan 9 can run Dis binaries natively, without having to run the Inferno emulator (emu) as a user process. Inferno-related: (A) A 64-bit version of Dis, which was designed as a 32-bit (31-bit?) architecture. (B) Porting Inferno to modern video game consoles, such as the Nintendo Switch family. Coolness. (C) Creating a secure version of Dis. The way that Dis handles allocated/freed memory isn't particularly safe, and can leak sensitive data (such as encryption keys). It doesn't have a way to whiten memory, or to mark ranges of memory as non-swappable. This could be done by adding new VM instructions, or on a per-module basis by adding new module flags. (D) Porting Nemo/LSUB's "OSHAD" to Plan 9. OSHAD is an authentication system (implemented in Inferno) which allows you to provide passwords or acknowledge actions from a separate, wireless hand-held device. (E) A postscript/PDF viewer for Inferno. Enough said. :) Android-related: (a) An Android "app" that presents an Android phone's telephone and SMS messaging facilities as a 9P filesystem. This would enable Plan 9 and Inferno applications to place/receive voice calls and send/receive text messages across a network. This could be done by extending bhgv's existing Android port of Inferno, or as a separtate, stand-alone server app. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T1c300cdbd9941edb-M627e2da16ac2f567361984f0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] GSoC 2021 project ideas
Hello, many many really cool ideas. Most of them get a big heart icon, but I don't want to repeat your ideas. So consider this one large heart for all of them ♥️. My annotations are inline. 01.02.2021 08:16:58 cigar562hfsp952f...@icebubble.org: (2) A Zoom/video conferencing application for Plan 9. Enough said. :) Afaik someone on grid wanted to try some voice chat stuff using mq, maybe. Could be helpful. (a) An Android "app" that presents an Android phone's telephone and SMS messaging facilities as a 9P filesystem. This would enable Plan 9 and Inferno applications to place/receive voice calls and send/receive text messages across a network. This could be done by extending bhgv's existing Android port of Inferno, or as a separtate, stand-alone server app. Also hellaphone might be interesting (maybe just for comparison). Afaik they removed the whole java stuff from android and replaced it with dis. They were able to do phone calls and I think they got rudimentary text messages working, too, but both directly on the phone using inferno. A native 9p interface for Android might also be a nice project. Android supports adding new protocols like ftp or smb to its native filesystem pool. I don't know the details. I also have some other project ideas like many, like a native Android gridchat client, but that's too specific, I think. I'll play around with these when I'm done studying. sirjofri -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T39aec8f3f9d8503d-Ma85d1112f2b15b2f327eb4d8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Plan 9 Applying to GSoC 2021
On Mon, 1 Feb 2021 03:26:35 -0800 Bakul Shah wrote: > Chibi-Scheme supposedly works on plan9 though I haven’t played with > it in years. Chibi is very broken on arm64 and possibly other architectures. I have attempted to fix it but didn't get far. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T00b3dc89a8df295a-M494bc387c596b211122b7ce1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Plan 9 Applying to GSoC 2021
Quoth Anthony Sorace : > 1. Project ideas. One of the key parts of the application is the > project ideas page. If you’ve got ideas that seem like they’d > be a good fit for the program, and *especially* if you’re up for > mentoring them, please think about how to describe them in > sufficient detail for a student to work on (objectives, > promising starting points, likely challenges, &c). Here's a partial list of things I've been hoping to find time for. Some are fuzzy and poorly thought out. I'd be willing to mentor most of them, given someone that I had confidence in. In no particular order: - Imlementing asan in 6l: Right now, there's no easy way to detect access to uninitialized memory on the stack, use after free, or many other common C errors in plan 9. Unix has a number of tools like the address sanitizer and valgrind. I think it would be possible to make the linkers instrument programs with checks similar to the clang address sanitizer. https://research.google.com/pubs/archive/37752.pdf This would involve getting a fairly deep understanding of how the linkers work, modifying them to add a check before every memory read and write. It would also involve writing a runtime library for it, which could possibly be put into libc besite the profiling code. - Improving dtracy: 9front has implemented a dtrace workalike called dtracy. It's already proved useful for collecting statistics systemwide, but has a few annoyances. Namely: - It does not know how to collect stack traces. - It needs manually defined tracepoints. The first issue would involve teaching the kernel how to collect the stack trace of a process -- so, parsing debug info and packing it up into something that can be sent back to userspace. The second can probably be done by marrying devtrace from 9atom with dtracy: http://man.postnix.pw/9atom/3/trace - Implementing fuzzing framework: Plan 9 programs often handle unexpected input poorly. A tool that would help root out crashes and improve reliability of plan 9 software would be very welcome. The goal would be to implement a tool similar to AFL, but running on plan 9, using the plan 9 toolchain. https://lcamtuf.coredump.cx/afl/ This may require some changes to the linker, to make profiling information granular enough to provide coverage. - Implementing syzkaller support: The reasoning is the same as above: The plan 9 kernel almost certainly has a number of undiscovered bugs, panics, and issues around mishanlding of untrusted input. An attempt to fuzz the kernel would ceratinly improve software quality. This may also involve enhancing the linker to provide more granular coverage information. https://github.com/google/syzkaller/blob/master/docs/internals.md - SSH server: For providing service to unix, this could be helpful -- at least, git/serve could use it for push and clone. This would probably be done by forking the ssh client (/sys/src/cmd/ssh.c), and making it handle the server side of communication, then doing a cleanup pass to pull out the common code. - TLS certificate chain verification: Right now, we rely on thumbprints for certificate verification. Thumbprints require manual additions for ever server that we want to communicate with in a secure and authenticated manner. We should instead handle TLS certificate chain verification in our x509 client. The LibreSSL people recently put together a test suite for certificate verification. This should be used to validate the work. - Devdraw improvements: It seems like moving devdraw to userspace is a good idea. This also allows doing some vectorized SSE draw ops that would be painful in the kernel, as well as allowing freer experimentation with toys like affine transforms, antialiasing modes, similar. - Malloc improvemnts: Our current allocator is slow, and takes a global lock on every allocation. We're leaving a lot of performance on the table, and a faster allocator need not be all that much more complex. - Arm64 go support Seems feasible. May be too small in scope, since all the code gen is there. If so, there are a bunch of improvements to the runtime that could be made. As a sporadic user of go, I'm probably not the best choice. It seems that miller or 0intro are the most prolific plan9 go
