[9fans] Scheme 9 ported to Plan 9
Scheme 9 from Empty Space (pun intended and originally a reference to the movie, not to the OS) is an interpreter for R4RS Scheme. In 2008 Bakul Shah pointed out that an interpreter with that name should run on the Plan 9 OS and helped me port it. Ever since the Plan 9 port has been in varying stages of bit rot. After all the years I finally came around to straighten out some rough edges of the Plan 9 port: - the DEL key gets you back to the prompt instead of exiting the interpreter - there is a target for system-wide installation in the mkfile (but S9 also runs in its source directory without installation) - the HELP function works properly So, if you are looking for a Scheme interpreter for Plan 9, look no further! :) http://t3x.org/s9fes Enjoy! -- Nils M Holm n m h @ t 3 x . o r g www.t3x.org
Re: [9fans] Scheme 9 ported to Plan 9
Awesome work! On 2 Jul, 2015, at 4:11 pm, Nils M Holm n...@t3x.org wrote: Scheme 9 from Empty Space (pun intended and originally a reference to the movie, not to the OS) is an interpreter for R4RS Scheme. In 2008 Bakul Shah pointed out that an interpreter with that name should run on the Plan 9 OS and helped me port it. Ever since the Plan 9 port has been in varying stages of bit rot. After all the years I finally came around to straighten out some rough edges of the Plan 9 port: - the DEL key gets you back to the prompt instead of exiting the interpreter - there is a target for system-wide installation in the mkfile (but S9 also runs in its source directory without installation) - the HELP function works properly So, if you are looking for a Scheme interpreter for Plan 9, look no further! :) http://t3x.org/s9fes Enjoy! -- Nils M Holm n m h @ t 3 x . o r g www.t3x.org
[9fans] replace p9sk1 with something better(9front)
as per http://wiki.9front.org/bounties replace p9sk1 with something better I'm looking to start on this, does anyone have thoughts on improvements? At the moment I am intending to just replace the DES keys with AES but is there any call for more structural changes? I was thinking that an overhaul using public keys might be appropriate so that the auth server would still be a trusted key holder but without secret keys having to leave the user's machine. (9front mailing list was down so im sending to 9fans instead, sorry if that's a bother)
Re: [9fans] replace p9sk1 with something better(9front)
I hadn't looked at the bounties page recently. It includes improve the tls(3) device $10 - The TLS device implements the record layer protocols of Transport Layer Security version 1.0 and Secure Sockets Layer version 3.0. It does not implement the handshake protocols, which are responsible for mutual authentication and key exchange. Wanted: more ciphers, support for user certificates, support for certificate verification. ECDSA! ECDHE! I think that I'd avoid putting the negotiation and certificate stuff (as such) in the kernel device. On 2 July 2015 at 13:57, Charles Forsyth charles.fors...@gmail.com wrote: On 2 July 2015 at 13:30, Anthony Sorace a...@9srv.net wrote: The p9sk1 *model* is great, and it'd be a real shame to drop it. There always seems to be trouble setting it up, which suggests that the documentation people typically first see might need revising (or better pointers if it exists but people don't find it).
Re: [9fans] replace p9sk1 with something better(9front)
I think just replacing des keys with AES is not worth it. there is so little data that des is quite secure (imho). replacing p9sk1 with pki is much more useful. rus posted to 9fans about wanting to do this so a terminal could cache tickets to speed auth when the auth server is remote - I cannot remember the details, sorry. also pki would allow the old 9grid ideas to resurface, if there are enough plan9 machines left :-) -Steve ps. inferno already uses pki, it would be best to be compatible unless there is a very good reason not to be. On 2 Jul 2015, at 12:37, gracc oniic...@tfwno.gf wrote: as per http://wiki.9front.org/bounties replace p9sk1 with something better I'm looking to start on this, does anyone have thoughts on improvements? At the moment I am intending to just replace the DES keys with AES but is there any call for more structural changes? I was thinking that an overhaul using public keys might be appropriate so that the auth server would still be a trusted key holder but without secret keys having to leave the user's machine. (9front mailing list was down so im sending to 9fans instead, sorry if that's a bother)
Re: [9fans] replace p9sk1 with something better(9front)
Personally, I think two separate things are called for. 1) A straight-forward update to use AES 2) Some public key system. The p9sk1 *model* is great, and it'd be a real shame to drop it. Doing the upgrade and teaching should be easy, although there's tedious work in telling all the things to start using it, The fun/interesting parts live in that second one, though. Lots of questions, starting with deciding if something existing might make sense to import (Inferno's public key system is the obvious first thing to look at there, but its details are dusty in my head). Public key systems have different enough properties that it'd be good to have both, in cases where one or the other fits the use case better.
Re: [9fans] replace p9sk1 with something better(9front)
On 2 July 2015 at 13:30, Anthony Sorace a...@9srv.net wrote: The p9sk1 *model* is great, and it'd be a real shame to drop it. There always seems to be trouble setting it up, which suggests that the documentation people typically first see might need revising (or better pointers if it exists but people don't find it).
Re: [9fans] replace p9sk1 with something better(9front)
On 2 July 2015 at 17:44, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: isn't it settled that keeping of secrets and exchange thereof are the domain of factotum? I hope so.
Re: [9fans] replace p9sk1 with something better(9front)
I think that I'd avoid putting the negotiation and certificate stuff (as such) in the kernel device. Speaking as an amateur, I'd be tempted to investigate pushing the Plan 9 paradigm further and see how hard it would be to fragment the kernel into asymmetric portions. To be more specific, something of the magnitude of TLS, or USB, ought to be constructed as a subkernel or a super-driver, able to run on GPUs in parallel with the CPU-based kernel. Thinking on my feet, I'd say the important factor would be the establishment of boundaries between modules that can only be crossed with the right type of credentials. How much of this is old hat to those of us who are close to academia I can't guess, but not having seen much mention of similar concepts, I'm curious if anything in this vein is being explored at all (I'm sure something that would appeal to me is, there are close to an infinite number of monkeys out there typing on pretty close to an infinite number of keyboards and an even more infinite number of CPUs). Lucio.
Re: [9fans] replace p9sk1 with something better(9front)
isn't it settled that keeping of secrets and exchange thereof are the domain of factotum? On Thu, Jul 2, 2015 at 6:14 AM, Charles Forsyth charles.fors...@gmail.com wrote: I hadn't looked at the bounties page recently. It includes improve the tls(3) device $10 - The TLS device implements the record layer protocols of Transport Layer Security version 1.0 and Secure Sockets Layer version 3.0. It does not implement the handshake protocols, which are responsible for mutual authentication and key exchange. Wanted: more ciphers, support for user certificates, support for certificate verification. ECDSA! ECDHE! I think that I'd avoid putting the negotiation and certificate stuff (as such) in the kernel device. On 2 July 2015 at 13:57, Charles Forsyth charles.fors...@gmail.com wrote: On 2 July 2015 at 13:30, Anthony Sorace a...@9srv.net wrote: The p9sk1 *model* is great, and it'd be a real shame to drop it. There always seems to be trouble setting it up, which suggests that the documentation people typically first see might need revising (or better pointers if it exists but people don't find it).
Re: [9fans] replace p9sk1 with something better(9front)
Wanted: more ciphers, support for user certificates, support for certificate verification. ECDSA! ECDHE! client certs, client side DHE and ECDHE already done in 9front, just take it :) -- cinap
