Re: Rust in the kernel
Ludovic Courtès writes: > Hi, > > Akib Azmain Turja skribis: > >>> (During that time, interested readers can also take a stab at improving >>> support for the Hurd, which relies on that revolutionary technology >>> called “address spaces” to ensure Memory Safety™ among other things!) >>> >>> Ludo’. >>> >> >> Why "address spaces" is a revolutionary technology? All kernels (except >> the "Hello, World!" ones) use it. > > That was an ironic remark from my part. Virtual memory management and > address spaces are not revolutionary at all: that’s how we protect > processes from stomping onto each other’s toes since the 70’s. > > If the goal really is to improve OS reliability through a > multi-person-year effort, then I believe pouring that effort into a > microkernel-based design would be more fruitful. My 2¢! > > Ludo’. I agree, but it's very hard because the hardware vendors tend to keep things secret, and unfortunately there isn't enough people interested in Hurd. -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
Hi, Akib Azmain Turja skribis: >> (During that time, interested readers can also take a stab at improving >> support for the Hurd, which relies on that revolutionary technology >> called “address spaces” to ensure Memory Safety™ among other things!) >> >> Ludo’. >> > > Why "address spaces" is a revolutionary technology? All kernels (except > the "Hello, World!" ones) use it. That was an ironic remark from my part. Virtual memory management and address spaces are not revolutionary at all: that’s how we protect processes from stomping onto each other’s toes since the 70’s. If the goal really is to improve OS reliability through a multi-person-year effort, then I believe pouring that effort into a microkernel-based design would be more fruitful. My 2¢! Ludo’.
Re: Rust in the kernel
July 5, 2022 11:36 AM, "Akib Azmain Turja" wrote: > jbra...@dismail.de writes: > >> July 5, 2022 12:48 AM, "Akib Azmain Turja" wrote: >> >>> jbra...@dismail.de writes: >> >> July 4, 2022 1:36 PM, "Akib Azmain Turja" wrote: >> >> Ludovic Courtès writes: >> >> Hi! >> >> Leo Famulari skribis: >> The effort to use the Rust programming language within the Linux kernel >> is progressing and may be realized in the next few months: >> >> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e >> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel >> >> Within Guix, we'll need to adapt our kernel build processes in order to >> support this. >> >> Although I help with updating and configuring the kernel builds, I won't >> be able to participate in the "Rust in the kernel" effort for Guix. >> >> Understood… >> So, interested volunteers should begin organizing :) >> >> Yup! >> >> Now, concretely, how long will it take before key parts of the kernel >> are written in Rust? Hopefully a long time, no? Per the article above, >> it’s starting small, with Rust usage in well-defined locations. >> >> This is not to say that we shouldn’t start organizing, but rather that >> we still have a bit of time ahead. >> >> (During that time, interested readers can also take a stab at improving >> support for the Hurd, which relies on that revolutionary technology >> called “address spaces” to ensure Memory Safety™ among other things!) >> >> Ludo’. >> "Address spaces"! What's that? Sorry for asking without searching the >> internet first, but the Hurd designers are so creative that a few >> understand the concepts and join the community, so there is a little >> chance (if any) that I'll find any useful information on that. >> >> From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html >> >> The Hurd is built in a very modular fashion. Other Unix-like kernels >> (Linux, for example) are also modular in that they allow loading >> (and unloading) some components as kernel modules, but the Hurd goes >> one step further in that most of the components that constitute the >> whole kernel are running as separate user-space processes and are thus >> using different address spaces that are isolated from each other. >> This is a multi-server design based on a microkernel. It is not >> possible that a faulty memory dereference inside the TCP/IP stack >> can bring down the whole kernel, and thus the whole system, which >> is a real problem in a monolithic Unix kernel architecture. >> >> Some visual explantions: >> >> https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg >> >> The Hurd is on the right in this image. >>> Thanks, now I understand Ludo' was saying about virtual address space, >>> achieved using paging. >> >> Essentially, if your fileserver somehow gets hacked, the attacker >> cannot magically access your TCP/IP stack, because your TCP/IP is not >> in the some "software zone" as your fileserver. So microkernels like >> the Hurd are usually considered more secure and better designed >> than monolithic kernels like Linux. However, monolithic kernels >> will usually be faster than microkernels. >>> I know microkernels are theorically slow due to the heavy use IPC. But >>> is it really impossible for well written microkernel to beat a well >>> written monolithic kernel? L4 is super-fast, is it still slower than >>> Linux? >> >> Probably a little, but I am not an expert in that area. >> >> GNU Mach, which is what the Hurd runs on. Is slower that Linux. >> There was an attempt to port the Hurd to L4 before. It is >> deemed not possible by the current hurd developers. > > Yes, I know that Mach is one of the slowest kernels. BTW, what's the > status of Viengoos? I believe that Viengoos is essentially dead. I do not believe that anyone is actively working on it. More info is available here: http://www.gnu.org/software/hurd/history/port_to_another_microkernel.html > >>> >> >> -- >> Akib Azmain Turja >> >> This message is signed by me with my GnuPG key. It's fingerprint is: >> >> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 >>> -- >>> Akib Azmain Turja >>> >>> This message is signed by me with my GnuPG key. It's fingerprint is: >>> >>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 > > -- > Akib Azmain Turja > > This message is signed by me with my GnuPG key. It's fingerprint is: > > 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
Re: Rust in the kernel
>BTW, what's the status of Viengoos? The author put it on indefinite hiatus and no one else has the expertise (and/or interest) to continue to work on it.
Re: Rust in the kernel
>GNU Mach, which is what the Hurd runs on. Is slower that Linux. There was an attempt to port the Hurd to L4 before. It is deemed not possible by the current hurd developers. This was done with an older L4 (Pistachio, I think) that lacked capabilities in the kernel. Doing it with SEL4 has not been thoroughly investigated.
Re: Rust in the kernel
jbra...@dismail.de writes: > July 5, 2022 12:48 AM, "Akib Azmain Turja" wrote: > >> jbra...@dismail.de writes: >> >>> July 4, 2022 1:36 PM, "Akib Azmain Turja" wrote: >>> >>>> Ludovic Courtès writes: >>> >>> Hi! >>> >>> Leo Famulari skribis: >>>> The effort to use the Rust programming language within the Linux kernel >>>> is progressing and may be realized in the next few months: >>>> >>>> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e >>>> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel >>>> >>>> Within Guix, we'll need to adapt our kernel build processes in order to >>>> support this. >>>> >>>> Although I help with updating and configuring the kernel builds, I won't >>>> be able to participate in the "Rust in the kernel" effort for Guix. >>> >>> Understood… >>>> So, interested volunteers should begin organizing :) >>> >>> Yup! >>> >>> Now, concretely, how long will it take before key parts of the kernel >>> are written in Rust? Hopefully a long time, no? Per the article above, >>> it’s starting small, with Rust usage in well-defined locations. >>> >>> This is not to say that we shouldn’t start organizing, but rather that >>> we still have a bit of time ahead. >>> >>> (During that time, interested readers can also take a stab at improving >>> support for the Hurd, which relies on that revolutionary technology >>> called “address spaces” to ensure Memory Safety™ among other things!) >>> >>> Ludo’. >>>> "Address spaces"! What's that? Sorry for asking without searching the >>>> internet first, but the Hurd designers are so creative that a few >>>> understand the concepts and join the community, so there is a little >>>> chance (if any) that I'll find any useful information on that. >>> >>> From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html >>> >>> The Hurd is built in a very modular fashion. Other Unix-like kernels >>> (Linux, for example) are also modular in that they allow loading >>> (and unloading) some components as kernel modules, but the Hurd goes >>> one step further in that most of the components that constitute the >>> whole kernel are running as separate user-space processes and are thus >>> using different address spaces that are isolated from each other. >>> This is a multi-server design based on a microkernel. It is not >>> possible that a faulty memory dereference inside the TCP/IP stack >>> can bring down the whole kernel, and thus the whole system, which >>> is a real problem in a monolithic Unix kernel architecture. >>> >>> Some visual explantions: >>> >>> https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg >>> >>> The Hurd is on the right in this image. >> >> Thanks, now I understand Ludo' was saying about virtual address space, >> achieved using paging. >> >>> Essentially, if your fileserver somehow gets hacked, the attacker >>> cannot magically access your TCP/IP stack, because your TCP/IP is not >>> in the some "software zone" as your fileserver. So microkernels like >>> the Hurd are usually considered more secure and better designed >>> than monolithic kernels like Linux. However, monolithic kernels >>> will usually be faster than microkernels. >> >> I know microkernels are theorically slow due to the heavy use IPC. But >> is it really impossible for well written microkernel to beat a well >> written monolithic kernel? L4 is super-fast, is it still slower than >> Linux? > > Probably a little, but I am not an expert in that area. > > GNU Mach, which is what the Hurd runs on. Is slower that Linux. > There was an attempt to port the Hurd to L4 before. It is > deemed not possible by the current hurd developers. Yes, I know that Mach is one of the slowest kernels. BTW, what's the status of Viengoos? > > >> >>>> -- >>>> Akib Azmain Turja >>>> >>>> This message is signed by me with my GnuPG key. It's fingerprint is: >>>> >>>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 >> >> -- >> Akib Azmain Turja >> >> This message is signed by me with my GnuPG key. It's fingerprint is: >> >> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
July 5, 2022 12:48 AM, "Akib Azmain Turja" wrote: > jbra...@dismail.de writes: > >> July 4, 2022 1:36 PM, "Akib Azmain Turja" wrote: >> >>> Ludovic Courtès writes: >> >> Hi! >> >> Leo Famulari skribis: >>> The effort to use the Rust programming language within the Linux kernel >>> is progressing and may be realized in the next few months: >>> >>> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e >>> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel >>> >>> Within Guix, we'll need to adapt our kernel build processes in order to >>> support this. >>> >>> Although I help with updating and configuring the kernel builds, I won't >>> be able to participate in the "Rust in the kernel" effort for Guix. >> >> Understood… >>> So, interested volunteers should begin organizing :) >> >> Yup! >> >> Now, concretely, how long will it take before key parts of the kernel >> are written in Rust? Hopefully a long time, no? Per the article above, >> it’s starting small, with Rust usage in well-defined locations. >> >> This is not to say that we shouldn’t start organizing, but rather that >> we still have a bit of time ahead. >> >> (During that time, interested readers can also take a stab at improving >> support for the Hurd, which relies on that revolutionary technology >> called “address spaces” to ensure Memory Safety™ among other things!) >> >> Ludo’. >>> "Address spaces"! What's that? Sorry for asking without searching the >>> internet first, but the Hurd designers are so creative that a few >>> understand the concepts and join the community, so there is a little >>> chance (if any) that I'll find any useful information on that. >> >> From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html >> >> The Hurd is built in a very modular fashion. Other Unix-like kernels >> (Linux, for example) are also modular in that they allow loading >> (and unloading) some components as kernel modules, but the Hurd goes >> one step further in that most of the components that constitute the >> whole kernel are running as separate user-space processes and are thus >> using different address spaces that are isolated from each other. >> This is a multi-server design based on a microkernel. It is not >> possible that a faulty memory dereference inside the TCP/IP stack >> can bring down the whole kernel, and thus the whole system, which >> is a real problem in a monolithic Unix kernel architecture. >> >> Some visual explantions: >> >> https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg >> >> The Hurd is on the right in this image. > > Thanks, now I understand Ludo' was saying about virtual address space, > achieved using paging. > >> Essentially, if your fileserver somehow gets hacked, the attacker >> cannot magically access your TCP/IP stack, because your TCP/IP is not >> in the some "software zone" as your fileserver. So microkernels like >> the Hurd are usually considered more secure and better designed >> than monolithic kernels like Linux. However, monolithic kernels >> will usually be faster than microkernels. > > I know microkernels are theorically slow due to the heavy use IPC. But > is it really impossible for well written microkernel to beat a well > written monolithic kernel? L4 is super-fast, is it still slower than > Linux? Probably a little, but I am not an expert in that area. GNU Mach, which is what the Hurd runs on. Is slower that Linux. There was an attempt to port the Hurd to L4 before. It is deemed not possible by the current hurd developers. > >>> -- >>> Akib Azmain Turja >>> >>> This message is signed by me with my GnuPG key. It's fingerprint is: >>> >>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 > > -- > Akib Azmain Turja > > This message is signed by me with my GnuPG key. It's fingerprint is: > > 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
Re: Rust in the kernel
Ludovic Courtès writes: > Hi! > > Leo Famulari skribis: > >> The effort to use the Rust programming language within the Linux kernel >> is progressing and may be realized in the next few months: >> >> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e/ >> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/ >> >> Within Guix, we'll need to adapt our kernel build processes in order to >> support this. >> >> Although I help with updating and configuring the kernel builds, I won't >> be able to participate in the "Rust in the kernel" effort for Guix. > > Understood… > >> So, interested volunteers should begin organizing :) > > Yup! > > Now, concretely, how long will it take before key parts of the kernel > are written in Rust? Hopefully a long time, no? Per the article above, > it’s starting small, with Rust usage in well-defined locations. > > This is not to say that we shouldn’t start organizing, but rather that > we still have a bit of time ahead. > > (During that time, interested readers can also take a stab at improving > support for the Hurd, which relies on that revolutionary technology > called “address spaces” to ensure Memory Safety™ among other things!) > > Ludo’. > Why "address spaces" is a revolutionary technology? All kernels (except the "Hello, World!" ones) use it. By the way, what basic features are lacking (read available) in the Hurd port? Last time when I checked the pre-built disk image, I found that it completely breaks after a reboot. I mailed at help-guix list[1], but got no response. [1]: https://lists.gnu.org/archive/html/help-guix/2021-09/msg00043.html -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
jbra...@dismail.de writes: > July 4, 2022 1:36 PM, "Akib Azmain Turja" wrote: > >> Ludovic Courtès writes: >> >>> Hi! >>> >>> Leo Famulari skribis: >> >> The effort to use the Rust programming language within the Linux kernel >> is progressing and may be realized in the next few months: >> >> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e >> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel >> >> Within Guix, we'll need to adapt our kernel build processes in order to >> support this. >> >> Although I help with updating and configuring the kernel builds, I won't >> be able to participate in the "Rust in the kernel" effort for Guix. >>> Understood… >> >> So, interested volunteers should begin organizing :) >>> Yup! >>> >>> Now, concretely, how long will it take before key parts of the kernel >>> are written in Rust? Hopefully a long time, no? Per the article above, >>> it’s starting small, with Rust usage in well-defined locations. >>> >>> This is not to say that we shouldn’t start organizing, but rather that >>> we still have a bit of time ahead. >>> >>> (During that time, interested readers can also take a stab at improving >>> support for the Hurd, which relies on that revolutionary technology >>> called “address spaces” to ensure Memory Safety™ among other things!) >>> >>> Ludo’. >> >> "Address spaces"! What's that? Sorry for asking without searching the >> internet first, but the Hurd designers are so creative that a few >> understand the concepts and join the community, so there is a little >> chance (if any) that I'll find any useful information on that. > > From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html > > The Hurd is built in a very modular fashion. Other Unix-like kernels > (Linux, for example) are also modular in that they allow loading > (and unloading) some components as kernel modules, but the Hurd goes > one step further in that most of the components that constitute the > whole kernel are running as separate user-space processes and are thus > using different address spaces that are isolated from each other. > This is a multi-server design based on a microkernel. It is not > possible that a faulty memory dereference inside the TCP/IP stack > can bring down the whole kernel, and thus the whole system, which > is a real problem in a monolithic Unix kernel architecture. > > Some visual explantions: > > https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg > > The Hurd is on the right in this image. Thanks, now I understand Ludo' was saying about virtual address space, achieved using paging. > > Essentially, if your fileserver somehow gets hacked, the attacker > cannot magically access your TCP/IP stack, because your TCP/IP is not > in the some "software zone" as your fileserver. So microkernels like > the Hurd are usually considered more secure and better designed > than monolithic kernels like Linux. However, monolithic kernels > will usually be faster than microkernels. I know microkernels are theorically slow due to the heavy use IPC. But is it really impossible for well written microkernel to beat a well written monolithic kernel? L4 is super-fast, is it still slower than Linux? > >> -- >> Akib Azmain Turja >> >> This message is signed by me with my GnuPG key. It's fingerprint is: >> >> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
July 4, 2022 1:36 PM, "Akib Azmain Turja" wrote: > Ludovic Courtès writes: > >> Hi! >> >> Leo Famulari skribis: > > The effort to use the Rust programming language within the Linux kernel > is progressing and may be realized in the next few months: > > https://lwn.net/SubscriberLink/899182/6c831b90eaee015e > https://www.memorysafety.org/blog/memory-safety-in-linux-kernel > > Within Guix, we'll need to adapt our kernel build processes in order to > support this. > > Although I help with updating and configuring the kernel builds, I won't > be able to participate in the "Rust in the kernel" effort for Guix. >> Understood… > > So, interested volunteers should begin organizing :) >> Yup! >> >> Now, concretely, how long will it take before key parts of the kernel >> are written in Rust? Hopefully a long time, no? Per the article above, >> it’s starting small, with Rust usage in well-defined locations. >> >> This is not to say that we shouldn’t start organizing, but rather that >> we still have a bit of time ahead. >> >> (During that time, interested readers can also take a stab at improving >> support for the Hurd, which relies on that revolutionary technology >> called “address spaces” to ensure Memory Safety™ among other things!) >> >> Ludo’. > > "Address spaces"! What's that? Sorry for asking without searching the > internet first, but the Hurd designers are so creative that a few > understand the concepts and join the community, so there is a little > chance (if any) that I'll find any useful information on that. >From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html The Hurd is built in a very modular fashion. Other Unix-like kernels (Linux, for example) are also modular in that they allow loading (and unloading) some components as kernel modules, but the Hurd goes one step further in that most of the components that constitute the whole kernel are running as separate user-space processes and are thus using different address spaces that are isolated from each other. This is a multi-server design based on a microkernel. It is not possible that a faulty memory dereference inside the TCP/IP stack can bring down the whole kernel, and thus the whole system, which is a real problem in a monolithic Unix kernel architecture. Some visual explantions: https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg The Hurd is on the right in this image. Essentially, if your fileserver somehow gets hacked, the attacker cannot magically access your TCP/IP stack, because your TCP/IP is not in the some "software zone" as your fileserver. So microkernels like the Hurd are usually considered more secure and better designed than monolithic kernels like Linux. However, monolithic kernels will usually be faster than microkernels. > -- > Akib Azmain Turja > > This message is signed by me with my GnuPG key. It's fingerprint is: > > 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
Re: Rust in the kernel
Ludovic Courtès writes: > Hi! > > Leo Famulari skribis: > >> The effort to use the Rust programming language within the Linux kernel >> is progressing and may be realized in the next few months: >> >> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e/ >> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/ >> >> Within Guix, we'll need to adapt our kernel build processes in order to >> support this. >> >> Although I help with updating and configuring the kernel builds, I won't >> be able to participate in the "Rust in the kernel" effort for Guix. > > Understood… > >> So, interested volunteers should begin organizing :) > > Yup! > > Now, concretely, how long will it take before key parts of the kernel > are written in Rust? Hopefully a long time, no? Per the article above, > it’s starting small, with Rust usage in well-defined locations. > > This is not to say that we shouldn’t start organizing, but rather that > we still have a bit of time ahead. > > (During that time, interested readers can also take a stab at improving > support for the Hurd, which relies on that revolutionary technology > called “address spaces” to ensure Memory Safety™ among other things!) > > Ludo’. > "Address spaces"! What's that? Sorry for asking without searching the internet first, but the Hurd designers are so creative that a few understand the concepts and join the community, so there is a little chance (if any) that I'll find any useful information on that. -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
Hi! Leo Famulari skribis: > The effort to use the Rust programming language within the Linux kernel > is progressing and may be realized in the next few months: > > https://lwn.net/SubscriberLink/899182/6c831b90eaee015e/ > https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/ > > Within Guix, we'll need to adapt our kernel build processes in order to > support this. > > Although I help with updating and configuring the kernel builds, I won't > be able to participate in the "Rust in the kernel" effort for Guix. Understood… > So, interested volunteers should begin organizing :) Yup! Now, concretely, how long will it take before key parts of the kernel are written in Rust? Hopefully a long time, no? Per the article above, it’s starting small, with Rust usage in well-defined locations. This is not to say that we shouldn’t start organizing, but rather that we still have a bit of time ahead. (During that time, interested readers can also take a stab at improving support for the Hurd, which relies on that revolutionary technology called “address spaces” to ensure Memory Safety™ among other things!) Ludo’.
Re: Rust in the kernel
On Thu, Jun 30, 2022 at 12:37:54PM -0400, Leo Famulari wrote: > Within Guix, we'll need to adapt our kernel build processes in order to > support this. An update on GCC support for Rust: https://lwn.net/Articles/899385/ signature.asc Description: PGP signature
Rust in the kernel
The effort to use the Rust programming language within the Linux kernel is progressing and may be realized in the next few months: https://lwn.net/SubscriberLink/899182/6c831b90eaee015e/ https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/ Within Guix, we'll need to adapt our kernel build processes in order to support this. Although I help with updating and configuring the kernel builds, I won't be able to participate in the "Rust in the kernel" effort for Guix. So, interested volunteers should begin organizing :) signature.asc Description: PGP signature
