Re: [9fans] Fwd: Go, Rust, Plan 9, and more

[fulton]

Quoth Romano :
> Some publicity from O'Reilly!
> 
>  Original Message 
> From: O'Reilly Programming Newsletter 
> Sent: April 10, 2021 5:00:40 PM UTC
> To: un...@cpan.org
> Subject: Go, Rust, Plan 9, and more
> 
> O’Reilly Programming Newsletter
> 
> 04/10/2021 -- In This Issue:
> 
> * Rust and Go: Better together
> * Safe systems programming in Rust
> * PHP's Git server hacked to add backdoors to PHP source code
> * Plan 9
> * Common antipatterns in Go
> * Linus Torvalds on where Rust will fit into Linux
> * The mobile performance inequality gap
> * tail -F /dev/newsletter
> 
> View this information in your browser: 
> https://get.oreilly.com/index.php/email/emailWebview?mkt_tok=MTA3LUZNUy0wNzF8W7MnRCYhvMPWx_Z2fVffpb92P5muC3-jGle8YL1a5tmyOyI2PhSveoE3o4APs1MIBlA2uqLYQg8JcJLZcEBnbkCUYDYYQfKK04GWPogBaXMXsA_id=14643
> 
> 
> 
> This message was sent to un...@cpan.org. You are receiving this because 
> you're a customer of O'Reilly Media, or you've signed up to receive email 
> from us. We hope you found this message to be useful. However, if you'd 
> rather not receive future emails of this type from O'Reilly, please manage 
> your preferences or unsubscribe here: 
> https://get.oreilly.com/email-preferences.html?utm_medium=email_source=topic+optin_campaign=awareness_content=20210410+prog+nl
> 
> Read our Privacy Policy: https://www.oreilly.com/privacy.html
> 
> Did someone forward this to you? Sign up here: 
> https://www.oreilly.com/emails/newsletters/?utm_medium=email_source=topic+optin_campaign=awareness_content=20210410+prog+nl
> 
> O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 
> (707) 827-7000
> 
> 
> 
> .

Nice! Love to see stuff like this.

--
Fulton fulton.software!fulton

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2ab6b1ab91af33eb-M6d66de6d2f3151fdff489d41
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Fwd: Go, Rust, Plan 9, and more

[Romano]

Some publicity from O'Reilly!


 Original Message 
From: O'Reilly Programming Newsletter 
Sent: April 10, 2021 5:00:40 PM UTC
To: un...@cpan.org
Subject: Go, Rust, Plan 9, and more

O’Reilly Programming Newsletter

04/10/2021 -- In This Issue:

* Rust and Go: Better together
* Safe systems programming in Rust
* PHP's Git server hacked to add backdoors to PHP source code
* Plan 9
* Common antipatterns in Go
* Linus Torvalds on where Rust will fit into Linux
* The mobile performance inequality gap
* tail -F /dev/newsletter


View this information in your browser: 
https://get.oreilly.com/index.php/email/emailWebview?mkt_tok=MTA3LUZNUy0wNzF8W7MnRCYhvMPWx_Z2fVffpb92P5muC3-jGle8YL1a5tmyOyI2PhSveoE3o4APs1MIBlA2uqLYQg8JcJLZcEBnbkCUYDYYQfKK04GWPogBaXMXsA_id=14643



This message was sent to un...@cpan.org. You are receiving this because you're 
a customer of O'Reilly Media, or you've signed up to receive email from us. We 
hope you found this message to be useful. However, if you'd rather not receive 
future emails of this type from O'Reilly, please manage your preferences or 
unsubscribe here: 
https://get.oreilly.com/email-preferences.html?utm_medium=email_source=topic+optin_campaign=awareness_content=20210410+prog+nl

Read our Privacy Policy: https://www.oreilly.com/privacy.html

Did someone forward this to you? Sign up here: 
https://www.oreilly.com/emails/newsletters/?utm_medium=email_source=topic+optin_campaign=awareness_content=20210410+prog+nl

O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 (707) 
827-7000




.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2ab6b1ab91af33eb-Mbb45684a9ac638f993fc3046
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Fwd: NFS suicide on RPi3 and RPi4 9front, but works on RMiller's Plan9.

[ori]

Quoth Shiro :
> Hello,
> 
> I’m not sure I’m reporting to the appropriate place.  Please advise.  And 
> apologies in advance if I’m spamming this group.
> 

This is fine, but 9fr...@9front.org is probably
better for 9front specific questions.

As far as uploading information -- 9front ships
with webpaste, so it's easy to get text uploaded,
which would let people copy values.

> Photo 3: acid is pointing to line 431.  From above, n is too large
> to be a strlen.  I suspect it actually failed in memmove(), but
> I’m not sure — I’ve only got 2 months on Plan9/9front and this is
> the first time I do acid.

Acid just shows whole words, so you're seeing 64
bits of a 32 bit value.  If you look closely,
you'll actually notice that the top bits in 'n'
are also the bottom bits of 'dat'

It's a bit unfortunate, you either have to tell
acid how to format the type, or you have to know
that you just need to ignore the top bits.

Anyawys, the faulting address is

addr=0x100061fa0 pc=37930

Which shows up in R4. Given that *almost* the same
addresses (0x61fa0) in the other registers.  It
looks like it could be stack corruption.

Is this easy to reproduce?  Are you using the
binary from the last release, or is it your own
build?


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T995ec2230d16bd0b-M13cd1034eae8ce315d7a78eb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Fwd: [9front] IWP92020 Announcement

[Rodrigo G . López]

sorry, didn't notice the cross-post.

-- Forwarded message -
From: Rodrigo G. López 
Date: Tue, Jan 14, 2020, 6:36 AM
Subject: Re: [9front] IWP92020 Announcement
To: <9fr...@9front.org>


DC1301 is repeated on the front page.

i'm very glad to see this, i will sign up once i get all my documents in
order (soon).


-rodri

On Tue, Jan 14, 2020, 3:17 AM  wrote:

> IWP92020 is happening. Submit papers and sign up here:
>
> http://iwp9.org
>
> Hope to see you there!
>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42a12e6ce5294c72-Md352f78dee4047603ff7b426
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Fwd: [PLUG] Brian Kernighan speaking at Princeton ACM tomorrow night

[Calvin Morrison]

Of interest to anyone in New Jersey.

-- Forwarded message -
From: Walt Mankowski 
Date: Wed, 12 Dec 2018 at 11:24
Subject: [PLUG] Brian Kernighan speaking at Princeton ACM tomorrow night
To: 


Hi everyone,

Brian Kernighan will be speaking at the Princeton ACM meeting tomorrow
night. Dr. Kernighan worked at Bell Labs in the early days of Unix and
is currently a professor of Computer Science at Princeton
University. He's the co-author of The C Programming Language, The Unix
Programming Environment, and many other books. He's also the "K" in
AWK.

I've seen Kernighan speak before on a number of different subjects and
he's a fantastic speaker. Sadly I can't go because my company holiday
party is tomorrow night, but I encourage you to go if you can make
it. Directions are in the PDF linked in the forwared email below.

Walt

- Forwarded message from Dennis Mancl  -

Date: Wed, 12 Dec 2018 10:52:08 -0500
From: Dennis Mancl 
To: princeton-acm-not...@listserv.acm.org
Subject: ACM Princeton Chapter - reminder of Dec. 13 meeting

Upcoming Princeton ACM/ IEEE Computer Society Meetings and Events

Thursday Dec. 13 - "Too Many Numbers," Brian Kernighan, Princeton Univ., 8:00pm

-

PRINCETON ACM / IEEE-CS CHAPTERS
DECEMBER 2018 JOINT MEETING

   Too Many Numbers - new book by Brian Kernighan

Brian Kernighan is our December speaker -- he will be talking about
his new book, "Millions, Billions, Zillions".  The target audience of
this book is "all of us" -- even diehard math-phobes will learn some
ideas, shortcuts, and strategies to work with the numbers that are
trying to fool us.

Books on sale:  Labyrinth Books will be selling copies of Brian's book
at the meeting (cash and credit cards accepted) – and there will be an
opportunity after the meeting to get the author to autograph the book.

   Date: Thursday December 13, 2018, 8:00pm
 (refreshments at 7:30pm)
   Place: Princeton University Computer Science Building
 Large Auditorium, Room CS 104
 35 Olden Street, Princeton NJ
   Information: Dennis Mancl (908) 285-1066
   On-line meeting notice:  http://PrincetonACM.acm.org/meetings/mtg1812.pdf

All ACM / IEEE-CS meetings are open to the public. Students and their
parents are welcome.  There is no admission charge.

- End forwarded message -
___
Philadelphia Linux Users Group --http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
-BEGIN PGP SIGNATURE-

iF0EABECAB0WIQR31NgdxH1o+p6eanxd8Z4rZ6e1hAUCXBE2KgAKCRBd8Z4rZ6e1
hGgTAJwKOviUD5+jGEA+so6C7HAZeo1ZvgCgs7Kg8uZgpm2YAFdEp+PFAOn0R+w=
=PQnL
-END PGP SIGNATURE-

[9fans] FWD: Role of factotum(4) in Inferno security

[cigar562hfsp952fans]

Hi, 9fans,

I recently posted this to the Inferno list.  I still haven't gotten any
replies after almost a week.  Since factotum originated on Plan 9, I'm
re-posting this to 9fans.  Hopefully, someone in 9-landia will be able
to provide some insight into what factotum does on Inferno.  Thanks!

 SNIP  SNIP  SNIP =
From: clasp126hfsp64...@icebubble.org
To: inferno-os 
Subject: Role of factotum(4) in Inferno security
Date: Sat, 01 Dec 2018 20:44:01 +

So, I've been reading about security in Inferno.  There are many
complex, interacting pieces, and lots of docs (and source code) to read.
But once you get it all in your head, it makes sense.  It's actually
quite elegant.

One thing which still confuses me, however, is the function of
factotum(4) on Inferno.  Factotum->mount, in the factotum(2) module,
allows Inferno to mount file systems exported from Plan 9, using the
factotum(4) file system to authenticate with the Plan 9 server.  The
"-9" option to mount(1), as described in bind(1), makes this
functionality fully available from the Inferno command-line.  However,
there doesn't appear to be any corresponding Factotum->export in
factotum(2) that uses factotum(4) to authenticate attach requests (made
with Tauth ).  Accordingly, neither export(4) nor styxlisten(1) have
anything which would correspond to the "-9" option of mount(1).  Is
factotum(4) on Inferno used only for mounting from Plan 9?  Why not for
exporting to Plan 9?

factotum(4) on Inferno only implements a few authentication protocols
(p9sk1, p9any, pass, and infauth, according to the man page).  Looking
at the actual code, however, it also appears to support "rsa" (as used
by SSH) and "authquery" (whatever that is).  It doesn't appear to
support any of the other authentication protocols (such as apop, cram,
chap, mschap, etc.) available on Plan 9's factotum(4).  So, how is one
supposed to do things like APOP on Inferno?  Currently, it looks like
I'd have to run Inferno under emu, hosted on either Plan 9 or plan9port,
and import factotum(4) from the host OS.  (In other words, no APOP when
running Inferno on bare hardware.)

Lastly, I see that Inferno's factotum(4) supports an "infauth"
authentication protocol which (presumably) encapsulates Inferno's
auth(6) protocol.  But Keyring->auth (cf. keyring-auth(2)) doesn't
appear to have any option to delegate the Station-to-Station protocol to
factotum(4).  Yes, I see that the keyring module, which does the STS, is
implemented in C and hard-linked into the kernel/emu.  But I don't see
any place where "proto=infauth" keys in factotum(4) are actually used by
the system.  The factotum(4) in plan9port doesn't support the "infauth"
authentication protocol, either.  So, if nothing uses "proto=infauth",
then why is it there?

Any insights would be greatly appreciated.  Thanks!

Re: [9fans] Fwd: ubiquitous environment?

[Francisco J Ballesteros]

a mixture of clive macos and plan9ports

> On 9 Mar 2018, at 01:45, Aram Hăvărneanu  wrote:
> 
>> I don't think anyone is running it anymore.
>> At least, I'm not running it.
>> Sorry.
> 
> What do you run?
> 
> -- 
> Aram Hăvărneanu
> 

Re: [9fans] Fwd: ubiquitous environment?

[Sean Callanan]

Most likely http://lsub.org/ls/clive.html
Looks fun!

Sean

On Thu, Mar 8, 2018 at 4:45 PM, Aram Hăvărneanu  wrote:

> > I don't think anyone is running it anymore.
> > At least, I'm not running it.
> > Sorry.
>
> What do you run?
>
> --
> Aram Hăvărneanu
>
>

Re: [9fans] Fwd: ubiquitous environment?

[岡本健二]

I once used octopus.
It uses inferno as the middle layer of graphics, which made the
octopus somewhat complicated, I felt.   I'm not against the inferno,
however, octopus could make the graphics much easier and simpler.
Therefore, using inferno made the purpose unclear I thought.
That's the reason I left from the octopus.

sorry nemo.

Kenji


2018-03-08 21:38 GMT+09:00 Rudolf Sykora :

> On 3 March 2018 at 20:27, Francisco J Ballesteros  wrote:
> > Octopus would run on Plan 9, although we used inferno for (hosted)
> terminals,
> > and it used Op as the protocol (a descendant of 9p like everyone else),
>
> Ok. So does anybody use octopus these days?
> Why not? (Who wouldn't like a ubiquitous environment?)
> What do the authors of octopus use instead these days? (Clive seems
> to me to serve a completely different purpose.)
>
> It seems the octopus environment uses a tile-like management
> of its windows, unlike rio, where windows can overlap.
> Has anybody done any experiments to arrive at a rio-like feel?
>
> How is it with the need for inferno?
> (I tried to install octopus now on 9front. Unfortunately it asks me
> too many questions I am, at this moment, unable to answer---I do
> not understand them.)
>
> Thanks
> Ruda
>
>

Re: [9fans] Fwd: ubiquitous environment?

[FJ Ballesteros]

I don't think anyone is running it anymore.
At least, I'm not running it.
Sorry.

> El 8 mar 2018, a las 13:38, Rudolf Sykora  escribió:
> 
>> On 3 March 2018 at 20:27, Francisco J Ballesteros  wrote:
>> Octopus would run on Plan 9, although we used inferno for (hosted) terminals,
>> and it used Op as the protocol (a descendant of 9p like everyone else),
> 
> Ok. So does anybody use octopus these days?
> Why not? (Who wouldn't like a ubiquitous environment?)
> What do the authors of octopus use instead these days? (Clive seems
> to me to serve a completely different purpose.)
> 
> It seems the octopus environment uses a tile-like management
> of its windows, unlike rio, where windows can overlap.
> Has anybody done any experiments to arrive at a rio-like feel?
> 
> How is it with the need for inferno?
> (I tried to install octopus now on 9front. Unfortunately it asks me
> too many questions I am, at this moment, unable to answer---I do
> not understand them.)
> 
> Thanks
> Ruda
> 

Re: [9fans] Fwd: ubiquitous environment?

[Rudolf Sykora]

On 3 March 2018 at 20:27, Francisco J Ballesteros  wrote:
> Octopus would run on Plan 9, although we used inferno for (hosted) terminals,
> and it used Op as the protocol (a descendant of 9p like everyone else),

Ok. So does anybody use octopus these days?
Why not? (Who wouldn't like a ubiquitous environment?)
What do the authors of octopus use instead these days? (Clive seems
to me to serve a completely different purpose.)

It seems the octopus environment uses a tile-like management
of its windows, unlike rio, where windows can overlap.
Has anybody done any experiments to arrive at a rio-like feel?

How is it with the need for inferno?
(I tried to install octopus now on 9front. Unfortunately it asks me
too many questions I am, at this moment, unable to answer---I do
not understand them.)

Thanks
Ruda

Re: [9fans] Fwd: ubiquitous environment?

[Ethan Grammatikidis]

On Sat, Mar 3, 2018, at 4:22 PM, Rudolf Sykora wrote:
> Hello,
> 
> I am not sure this email ever made it to the forum,
> hence I decided to ask once more...
> 
> Thanks for any comments...
> 
> -- Forwarded message --
> From: Rudolf Sykora 
> Date: 16 June 2016 at 10:30
> Subject: ubiquitous environment?
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> 
> 
> Hello, everyone,
> 
> I read the following some time ago and now got back to it.
> It's from an interview with Russ Cox.
> https://usesthis.com/interviews/russ.cox/
> 
> --
> The thing I miss most about Plan 9 was the way that no matter which
> computer you sat down at, you had the same environment. Because we
> were working off a shared file server - there were no local disks on
> the Plan 9 workstations - you could go home and log in and all your
> work was there waiting. Of course, it only worked because we had good,
> fast connectivity to the file server, and only file state - not
> application state - transferred, but it was still a huge win.
> 
> Today it's taken for granted that everyone has local files on disk and
> you need programs like Unison or Dropbox (or for the power users,
> Mercurial or Git) to synchronize them, but what we had in Plan 9 was
> completely effortless, and my dream is to return to that kind of
> environment. I want to be working on my home desktop, realize what
> time it is, run out the door to catch my train, open my laptop on the
> train, continue right where I left off, close the laptop, hop off the
> train, sit down at work, and have all my state sitting there on the
> monitor on my desk, all without even thinking about it.
> --
> 
> Has anyone tried a setup like that? -- Having a server at work and
> working on it even from home/anywhere? And how is it set up? Does it mean
> that wherever you sit you somehow mount the window system to get
> to the exactly same state that you left the machine in?
> (Ie. something like a screen/tmux but supplied by the system itself?)
> 
> Thanks for any comments!
> 
> Ruda
> 

Indeed. I liked this, although I always wished application state would 
transfer too. I imagined a sort of sam with multiple samterms, but I never 
did anything about it. I'm starting to now, but I expect it won't be ready 
for about a year, and I'm not working in C or (directly) for Plan 9.

I've been thinking about phones and tablets too, so I was a little bit excited 
to see Inferno for Android. The person behind it seems enthusiastic, capable, 
and a hard worker. He'd like to work on Inferno full-time. 

https://github.com/bhgv/Inferno-OS_Android
https://github.com/bhgv/Inferno-OS_Android/releases

I haven't got involved myself for a few 
reasons: I don't like Limbo very much, I wasn't totally satisfied with Plan 9
and assume Inferno would have similar limits, and I'd just started my own 
major project before it was announced. I have hopes that retaining the 
principles of simple, unified, networkable interfaces with a different 
approach will yield better results, but I have a lot of exploration to do 
before I 
have anything concrete to say.


-- 
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9fans] Fwd: ubiquitous environment?

[Ethan Grammatikidis]

On Sun, Mar 4, 2018, at 7:17 AM, Francisco J Ballesteros wrote:
> All sources were made public and you have links in the web pages, eg., 
> http://lsub.org/export/osrc.zip for the octopus.
> Should anyone be bored and need something to read, drop me a line if you 
> can't find them.
> HTH

Oh, thank you. I could never seem to find the web pages, only one or two pdfs. 
Maybe they hide from search engines? Or maybe I never searched very well 
because I'm always doing 3 things at once anyway.

Re: [9fans] Fwd: ubiquitous environment?

[cigar562hfsp952fans]

Rudolf Sykora  writes:

> environment. I want to be working on my home desktop, realize what
> time it is, run out the door to catch my train, open my laptop on the
> train, continue right where I left off, close the laptop, hop off the
> train, sit down at work, and have all my state sitting there on the
> monitor on my desk, all without even thinking about it.

It sounds like you want to check out Nemo's work, over at LSUB, on the
Octopus, Olive, Omero, and Plan B:

http://lsub.org/export/oman.pdf
http://lsub.org/export/otut.pdf
http://lsub.org/ls/export/octopus.pdf
http://lsub.org/ls/export/omero.pdf
http://lsub.org/ls/export/uidemo.pdf
http://lsub.org/who/nemo

etc.

They seem to WRITE a lot about and demo their ideas, but I've never been
able to find anything from them that's actually usable.  (If anyone can
find actual code/documentation, please post so the rest of us can
benefit from it.  Thanks!)

Re: [9fans] Fwd: ubiquitous environment?

[Skip Tavakkolian]

Microtik RB450G port was done by Geoff and was in the main Labs report.

All the info needed for a Vocore2 port are in the open; my effort has been
limited to "thoughts and prayers".

On Mar 3, 2018 3:44 PM, "hiro" <23h...@gmail.com> wrote:

> A Microtik RB tftp/bootp
> loads a cpu kernel; it is the token MIPS machine (maybe VCore2 is
supported
> some day).

This sounds really interesting, did you mention this before and are
there more details somewhere?

Re: [9fans] Fwd: ubiquitous environment?

[hiro]

also, i'd like to use 9p instead of cifsd on the 9front server to
reach those files from the windows environment (what the file explorer
and non-drawterm programs see :)).

Re: [9fans] Fwd: ubiquitous environment?

[hiro]

it just keeps on breaking. it does reconnect after you press cancel or
ok (i don't remember), but it always keeps a while and when you have
files open or transfers happening you have to start again when
everything below breaks.

On 3/4/18, Steve Simon  wrote:
> i see.
>
> i would have thought/hoped that windows would remake the cifs session when
> windows comes out if standby, using cached credentials, so  other than being
> a bit slow to start,  cifs to the plan9 server should come back.
>
> i guess i am missing something.
>
> -Steve
>
>
> On 3 Mar 2018, at 23:32, hiro <23h...@gmail.com> wrote:
>
>>> also, i would have thought you could build a windows drawterm which also
>>> included the code from exportfs so you could use 9fs and aan to get at
>>> the
>>> files on your windows box.
>>
>> we don't use exportfs for this any more, but yes, i already use the
>> equivalent feature for this direction.
>> i want to also be able to use the windows file explorer to access the
>> 9front server through drawterm somehow (opposite direction), because
>> then the cifs mount doesn't get killed by window's inability to keep
>> the network connections running. 127.0.0.1 (drawterm) should always
>> stay up, and drawterm would take care of the rest :)
>
>
>

Re: [9fans] Fwd: ubiquitous environment?

[Steve Simon]

i see.

i would have thought/hoped that windows would remake the cifs session when 
windows comes out if standby, using cached credentials, so  other than being a 
bit slow to start,  cifs to the plan9 server should come back.

i guess i am missing something.

-Steve


On 3 Mar 2018, at 23:32, hiro <23h...@gmail.com> wrote:

>> also, i would have thought you could build a windows drawterm which also
>> included the code from exportfs so you could use 9fs and aan to get at the
>> files on your windows box.
> 
> we don't use exportfs for this any more, but yes, i already use the
> equivalent feature for this direction.
> i want to also be able to use the windows file explorer to access the
> 9front server through drawterm somehow (opposite direction), because
> then the cifs mount doesn't get killed by window's inability to keep
> the network connections running. 127.0.0.1 (drawterm) should always
> stay up, and drawterm would take care of the rest :)

Re: [9fans] Fwd: ubiquitous environment?

[hiro]

> A Microtik RB tftp/bootp
> loads a cpu kernel; it is the token MIPS machine (maybe VCore2 is supported
> some day).

This sounds really interesting, did you mention this before and are
there more details somewhere?

Re: [9fans] Fwd: ubiquitous environment?

[hiro]

octopus concepts were a real showoff, though so far i only managed to
use Op a lot, to mount mechiel's ircfs and display it in wm/irc. it
worked very well.

Re: [9fans] Fwd: ubiquitous environment?

[hiro]

> also, i would have thought you could build a windows drawterm which also
> included the code from exportfs so you could use 9fs and aan to get at the
> files on your windows box.

we don't use exportfs for this any more, but yes, i already use the
equivalent feature for this direction.
i want to also be able to use the windows file explorer to access the
9front server through drawterm somehow (opposite direction), because
then the cifs mount doesn't get killed by window's inability to keep
the network connections running. 127.0.0.1 (drawterm) should always
stay up, and drawterm would take care of the rest :)

Re: [9fans] Fwd: ubiquitous environment?

[Skip Tavakkolian]

You can dump the acme session at will and reload it to restore the session;
that combined with pxeloading a term or using drawterm, you almost don't
have to worry about losing your work or where you are. You can also use P9P
acme and import/fusemount the the Plan 9 fileserver with the same effect.

My home setup is a couple of Intel atom servers; one for Auth/Fileserver
(fossil+venti) and the other is a CPU (with a backup venti).  There are a
couple of RPi3's pxeloading the term kernel.  A Microtik RB tftp/bootp
loads a cpu kernel; it is the token MIPS machine (maybe VCore2 is supported
some day).  There are a couple of dormant (and noisy) x86 rackmount servers
that pxeboot cpu's for when I need a bit more oomph. Linux and MacOS
laptops have P9P and drawterm. I tend to fusemount the filesystem when I'm
using those.


On Sat, Mar 3, 2018 at 8:22 AM, Rudolf Sykora 
wrote:

> Hello,
>
> I am not sure this email ever made it to the forum,
> hence I decided to ask once more...
>
> Thanks for any comments...
>
> -- Forwarded message --
> From: Rudolf Sykora 
> Date: 16 June 2016 at 10:30
> Subject: ubiquitous environment?
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
>
>
> Hello, everyone,
>
> I read the following some time ago and now got back to it.
> It's from an interview with Russ Cox.
> https://usesthis.com/interviews/russ.cox/
>
> --
> The thing I miss most about Plan 9 was the way that no matter which
> computer you sat down at, you had the same environment. Because we
> were working off a shared file server - there were no local disks on
> the Plan 9 workstations - you could go home and log in and all your
> work was there waiting. Of course, it only worked because we had good,
> fast connectivity to the file server, and only file state - not
> application state - transferred, but it was still a huge win.
>
> Today it's taken for granted that everyone has local files on disk and
> you need programs like Unison or Dropbox (or for the power users,
> Mercurial or Git) to synchronize them, but what we had in Plan 9 was
> completely effortless, and my dream is to return to that kind of
> environment. I want to be working on my home desktop, realize what
> time it is, run out the door to catch my train, open my laptop on the
> train, continue right where I left off, close the laptop, hop off the
> train, sit down at work, and have all my state sitting there on the
> monitor on my desk, all without even thinking about it.
> --
>
> Has anyone tried a setup like that? -- Having a server at work and
> working on it even from home/anywhere? And how is it set up? Does it mean
> that wherever you sit you somehow mount the window system to get
> to the exactly same state that you left the machine in?
> (Ie. something like a screen/tmux but supplied by the system itself?)
>
> Thanks for any comments!
>
> Ruda
>
>

Re: [9fans] Fwd: ubiquitous environment?

[Kurt H Maier]

On Sat, Mar 03, 2018 at 07:13:57PM +, Steve Simon wrote:
> 
> personally i think this idea will become more and more important as we get 
> fiber to the home, local storage will become a thing of the past. 

I remember hearing this sentiment with '9600 baud modems' standing in
for 'fiber to the home.'  

If anything kills local storage, it will be vendor lock within the
android and ios worlds.  Banking on change being caused by *improved*
infrastructure is hanging your jacket on a shaky nail.

khm

Re: [9fans] Fwd: ubiquitous environment?

[Francisco J Ballesteros]

Octopus would run on Plan 9, although we used inferno for (hosted) terminals, 
and it used Op as the protocol (a descendant of 9p like everyone else),
Plan B was more a modified Plan 9 system with name spaces replaced and the 
early ideas of the Octopus window system implemented.

No need to apologize, I'm glad you remember the system :-)
Thanks for your comment about it.

> On 3 Mar 2018, at 20:23, Steve Simon  wrote:
> 
> My appologies for misreprisenting your system.
> 
> Would octopus run on plan9 or was the planB boxes or the
> streamlined filesystem api intrinsic to tos implmenetation?
> 
> -Steve
> 

Re: [9fans] Fwd: ubiquitous environment?

[Steve Simon]

My appologies for misreprisenting your system.

Would octopus run on plan9 or was the planB boxes or the
streamlined filesystem api intrinsic to tos implmenetation?

-Steve

Re: [9fans] Fwd: ubiquitous environment?

[Francisco J Ballesteros]

In octopus you didn't have to "save" the state. The window system was kept 
running at a server, including the layout you were using.
It was nice, and I miss it. II'll have to do something about it when I get some 
time.


> On 3 Mar 2018, at 20:13, Steve Simon  wrote:
> 
> i am pretty sure nemo’s octopus window system in planB had a way to save and 
> restore its state so you could migrate your sessions from one terminal to 
> another.
> 
> also, i would have thought you could build a windows drawterm which also 
> included the code from exportfs so you could use 9fs and aan to get at the 
> files on your windows box.
> 
> one bit that rangboom added was to be able to mount a filesystem  on windows 
> from plan9. the windows IFS subsystem id not simple or friendly.
> 
> personally i think this idea will become more and more important as we get 
> fiber to the home, local storage will become a thing of the past. 
> 
> -Steve
> 
> 
>> On 3 Mar 2018, at 17:41, hiro <23h...@gmail.com> wrote:
>> 
>> I have 9front running on a server at ovh france, my workstation is a
>> windows 7 machine with drawterm in autostart. drawterm itself is run
>> with -p option so that it can make use of AAN, which recovers broken
>> TCP connections e.g. after resuming from sleep in the mornings or
>> during any network state changes (windows frequently resets TCP
>> connections even if it wouldn't be needed).
>> 
>> This way my rio windows always stay open on windows, even though all
>> the windows network shares, vnc sessions, ssh stuff break every time
>> and have to be painstakingly reconnected.
>> If I could make the drawterm files accessible to windows (you rangboom
>> people please step forward), then I could mount the cifs share on
>> 9front, and then mount that on windows via drawterm to have more
>> stable connectivity to my windows shares.
>> I hope the rangboom people will share their technology so we won't
>> have to port cifsd to drawterm instead.
>> 
>> if i am in the train and on my laptop i can log into the same server.
>> i have a little LTE wifi router that maintains a tunnel to france so i
>> can keep on using the same IP when my laptop and phone leave the house
>> (actually AAN wouldn't even be needed for mobility if it wasn't for
>> crappy low NAT timeouts during temporary connection problems and
>> sleep).
>> 
>> Since my laptop is a separate terminal with it's own rio session,
>> sadly the rio windows are not synced. As Russ mentioned though i have
>> access to the same files.
>> You have to be careful with open sam windows in case they have unsaved
>> changes, but the dropbox people have the same merge conflicts. As a
>> windows user I learned to save my files instead. :)
>> 
>> It would be nice to have less local state (i.e. rio windows, devdraw).
>> Multiple approaches could be used quite easily.
>> One of them that is very curious is mycroftiv's ANTS project, which
>> separates the state of rio rc windows from the graphical environment.
>> 
>> acme also has state-saving functionality. it needs to be killed or
>> told to though. in my scenario it wouldn't get killed cause my session
>> survives, and i don't want it to close on one side normally :)
>> 
>> no idea if sam has anything for this, so right now i advocate
>> discipline instead.
> 
> 

Re: [9fans] Fwd: ubiquitous environment?

[Steve Simon]

i am pretty sure nemo’s octopus window system in planB had a way to save and 
restore its state so you could migrate your sessions from one terminal to 
another.

also, i would have thought you could build a windows drawterm which also 
included the code from exportfs so you could use 9fs and aan to get at the 
files on your windows box.

one bit that rangboom added was to be able to mount a filesystem  on windows 
from plan9. the windows IFS subsystem id not simple or friendly.

personally i think this idea will become more and more important as we get 
fiber to the home, local storage will become a thing of the past. 

-Steve


> On 3 Mar 2018, at 17:41, hiro <23h...@gmail.com> wrote:
> 
> I have 9front running on a server at ovh france, my workstation is a
> windows 7 machine with drawterm in autostart. drawterm itself is run
> with -p option so that it can make use of AAN, which recovers broken
> TCP connections e.g. after resuming from sleep in the mornings or
> during any network state changes (windows frequently resets TCP
> connections even if it wouldn't be needed).
> 
> This way my rio windows always stay open on windows, even though all
> the windows network shares, vnc sessions, ssh stuff break every time
> and have to be painstakingly reconnected.
> If I could make the drawterm files accessible to windows (you rangboom
> people please step forward), then I could mount the cifs share on
> 9front, and then mount that on windows via drawterm to have more
> stable connectivity to my windows shares.
> I hope the rangboom people will share their technology so we won't
> have to port cifsd to drawterm instead.
> 
> if i am in the train and on my laptop i can log into the same server.
> i have a little LTE wifi router that maintains a tunnel to france so i
> can keep on using the same IP when my laptop and phone leave the house
> (actually AAN wouldn't even be needed for mobility if it wasn't for
> crappy low NAT timeouts during temporary connection problems and
> sleep).
> 
> Since my laptop is a separate terminal with it's own rio session,
> sadly the rio windows are not synced. As Russ mentioned though i have
> access to the same files.
> You have to be careful with open sam windows in case they have unsaved
> changes, but the dropbox people have the same merge conflicts. As a
> windows user I learned to save my files instead. :)
> 
> It would be nice to have less local state (i.e. rio windows, devdraw).
> Multiple approaches could be used quite easily.
> One of them that is very curious is mycroftiv's ANTS project, which
> separates the state of rio rc windows from the graphical environment.
> 
> acme also has state-saving functionality. it needs to be killed or
> told to though. in my scenario it wouldn't get killed cause my session
> survives, and i don't want it to close on one side normally :)
> 
> no idea if sam has anything for this, so right now i advocate
> discipline instead.

Re: [9fans] Fwd: ubiquitous environment?

[hiro]

I have 9front running on a server at ovh france, my workstation is a
windows 7 machine with drawterm in autostart. drawterm itself is run
with -p option so that it can make use of AAN, which recovers broken
TCP connections e.g. after resuming from sleep in the mornings or
during any network state changes (windows frequently resets TCP
connections even if it wouldn't be needed).

This way my rio windows always stay open on windows, even though all
the windows network shares, vnc sessions, ssh stuff break every time
and have to be painstakingly reconnected.
If I could make the drawterm files accessible to windows (you rangboom
people please step forward), then I could mount the cifs share on
9front, and then mount that on windows via drawterm to have more
stable connectivity to my windows shares.
I hope the rangboom people will share their technology so we won't
have to port cifsd to drawterm instead.

if i am in the train and on my laptop i can log into the same server.
i have a little LTE wifi router that maintains a tunnel to france so i
can keep on using the same IP when my laptop and phone leave the house
(actually AAN wouldn't even be needed for mobility if it wasn't for
crappy low NAT timeouts during temporary connection problems and
sleep).

Since my laptop is a separate terminal with it's own rio session,
sadly the rio windows are not synced. As Russ mentioned though i have
access to the same files.
You have to be careful with open sam windows in case they have unsaved
changes, but the dropbox people have the same merge conflicts. As a
windows user I learned to save my files instead. :)

It would be nice to have less local state (i.e. rio windows, devdraw).
Multiple approaches could be used quite easily.
One of them that is very curious is mycroftiv's ANTS project, which
separates the state of rio rc windows from the graphical environment.

acme also has state-saving functionality. it needs to be killed or
told to though. in my scenario it wouldn't get killed cause my session
survives, and i don't want it to close on one side normally :)

no idea if sam has anything for this, so right now i advocate
discipline instead.

[9fans] Fwd: ubiquitous environment?

[Rudolf Sykora]

Hello,

I am not sure this email ever made it to the forum,
hence I decided to ask once more...

Thanks for any comments...

-- Forwarded message --
From: Rudolf Sykora 
Date: 16 June 2016 at 10:30
Subject: ubiquitous environment?
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>


Hello, everyone,

I read the following some time ago and now got back to it.
It's from an interview with Russ Cox.
https://usesthis.com/interviews/russ.cox/

--
The thing I miss most about Plan 9 was the way that no matter which
computer you sat down at, you had the same environment. Because we
were working off a shared file server - there were no local disks on
the Plan 9 workstations - you could go home and log in and all your
work was there waiting. Of course, it only worked because we had good,
fast connectivity to the file server, and only file state - not
application state - transferred, but it was still a huge win.

Today it's taken for granted that everyone has local files on disk and
you need programs like Unison or Dropbox (or for the power users,
Mercurial or Git) to synchronize them, but what we had in Plan 9 was
completely effortless, and my dream is to return to that kind of
environment. I want to be working on my home desktop, realize what
time it is, run out the door to catch my train, open my laptop on the
train, continue right where I left off, close the laptop, hop off the
train, sit down at work, and have all my state sitting there on the
monitor on my desk, all without even thinking about it.
--

Has anyone tried a setup like that? -- Having a server at work and
working on it even from home/anywhere? And how is it set up? Does it mean
that wherever you sit you somehow mount the window system to get
to the exactly same state that you left the machine in?
(Ie. something like a screen/tmux but supplied by the system itself?)

Thanks for any comments!

Ruda

[9fans] Fwd: DNS

[Skip Tavakkolian]

It looks like 9fans messages are getting processed again.  I asked this a
couple of weeks ago.

-- Forwarded message -
From: Skip Tavakkolian 
Date: Mon, Mar 20, 2017 at 12:26 AM
Subject: DNS
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>


It seems Plan 9 dns can't resolve www.paypal.com correctly;  I'm not sure
why.

Can anyone with a 9front installation try this to see if it resolves to the
an IP address (i.e. see a final "answer" output)?

ndb/dnsdebug www.paypal.com

Thanks,
-Skip

Re: [9fans] Fwd: Multiplexing Styx/9P2000 over TCP connections

[Charles Forsyth]

> So, I've been looking at the source code of Inferno, and I've noticed
> that, when mount(1) wants to connect to a Styx/9P2000 server on a remote
> machine, it generally opens up a new TCP connection... one for each new
> mount... even if it's just an additional connection to the same service
> on the same remote host.

Yes, although as someone observed, you can share that connection by
mounting it in different name spaces. Inferno doesn't provide Plan 9's srv
but sys->mount takes a file descriptor for any suitable connection
(not just a network connection, and not just tcp/ip)  and so it can be done
there too.

> Recalling the specification for 9P2000, the protocol supports the
> multiplexing of multiple 9P2000 clients/"sessions" onto a single,
> multiplexed, session with the server.  In theory, all a 9P2000
> multiplexer would have to do is map tags and fids so that different
> clients don't use the same values, and negotiate a common version and
> msize in the Tversion/Rversion transactions.  All the functionality of
> the protocol, including access control using afids, would be preserved.

The kernel's "mount driver" does the multiplexing for several clients
at one level. Only one Tversion exchange is done per connection,
and the kernel generates unique fids and tags as is required.

Plan 9's cpu server typically does multiplex many clients, even different
client IDs,
on the same connection from that cpu server to a shared file server (eg,
fossil/venti).
Each Tattach fid will typically be authorised to a given uname/aname pair
by a Tauth
and subsequent authentication exchange.

/srv/boot is where the initial connection is posted, and it's then shared
by a line such as

mount -a #s/boot /

in /lib/namespace, connecting the server at the far end to / in a union
mount.
(The actual line in /lib/namespace is more elaborate, but that's the
essence.)

There is an assumption that the kernel is trustworthy, and won't
deliberately
or inadvertently use a fid that's authenticated to one uname/aname in a 9p
request
resulting from another user's system call.

> I'd assumed, since the protocol allows for this, that this sort of
> multiplexing was done by the Plan 9 and Inferno kernels.  Is that not
> the case?  And if not, then why not?

It is done, by the mount driver in the kernel. Other specialised
applications
can also multiplex requests, although there aren't many examples.
Several provide different forms of shared cache.

> To take a stab at answering my own question, I suspect that it might
> have something to do with the Station to Station protocol and SSL setup
> done on a connection prior to exchanging Styx messages.  ...

When a connection is made to a remote machine, the connection itself
might also be authenticated (usually mutually), but that happens before
9P proper begins. The principal authenticated at that connection level
essentially speaks for all
users that use that connection, including any that later authenticate
over that connection using Tauth inside 9P. Thus, a shared cpu server
speaks for all users that share its file server connection. (There is a
little
mechanism on Plan 9 to control the "speakfor" role.) Put another way,
if you share a cpu server with other users, you're relying on the probity
of the provider of the service not to cheat. (This isn't different from many
other shared services.) Obviously there are other ways for a shared
cpu service to cheat because it controls the machine so it's not
particularly a 9P problem.

> In fact, while complying fully with the 9P2000 specification, it should
> also be possible to multiplex sessions in the REVERSE direction
> (connections from clients on the remote "server" host BACK to servers
> listening on the local "client" host) over the same TCP connection used
> to carry the "forward" (local --> remote) sessions.

> Now that I've been typing about this for a few paragraphs, it occurs to
> me that a multiplexer like this could probably be implemented as a
> system service running in userspace, without much (if any) extra support
> from the kernel.

Yes, you can easily write a 9P multiplexor at user level.
In fact, I think Roger Peppe wrote a library to support writing 9P
multiplexing in Inferno, but
I can't find it now. (9P and Styx are now the same protocol.)

A little different: several years ago, I needed a way for a 9P machine
exporting a service
to become a 9P client for the remote, as a way of getting a certain type of
streaming.
Note that 9P message types have a low-order bit that gives the direction,
and normally one end only sends types with 0 and receives types with 1,
while the other only sends types with 1 and receives types with 0.
Thus a 9P message multiplexor looking only at the low-order bit can split
the stream into two 9P conversations, going the opposite way to each other,
so at each end there's a 9P client and server, but part of the same logical
conversation
(the flipside of the original conversation).

As sometimes 

Re: [9fans] Fwd: Multiplexing Styx/9P2000 over TCP connections

[Charles Forsyth]

On 3 March 2016 at 02:09,  wrote:

> I recently posted the following to the Inferno mailing list (but
> received no response).  I'm re-posting here, as this applies to Plan 9
> just as much as to Inferno, anyway...
>

Sorry. You asked some interesting questions but I was busy with something
else
when I first saw it, and then it slipped my mind.

Re: [9fans] Fwd: Multiplexing Styx/9P2000 over TCP connections

[Kenny Lasse Hoff Levinsen]

On plan9, you use srv to add the connection as a file to /srv, then mount the 
file. Mount does not make TCP connections (although srv can call mount for you 
as a convenience feature).

Multiplexing requires ensuring that tag and fid collisions do not occur, either 
with coordination or translation tables. I do not believe that the kernel needs 
this multiplex, as it seems like an uncommon scenario. Why would you mount the 
same fs twice on the same machine? Also, as you mentioned, a userspace process 
could handle this easily of needed.

Best regards,
Kenny Levinsen

> On 3. mar. 2016, at 03.09, cigar562hfsp952f...@icebubble.org wrote:
> 
> I recently posted the following to the Inferno mailing list (but
> received no response).  I'm re-posting here, as this applies to Plan 9
> just as much as to Inferno, anyway...
> 
>> So, I've been looking at the source code of Inferno, and I've noticed
>> that, when mount(1) wants to connect to a Styx/9P2000 server on a remote
>> machine, it generally opens up a new TCP connection... one for each new
>> mount... even if it's just an additional connection to the same service
>> on the same remote host.
>> 
>> Recalling the specification for 9P2000, the protocol supports the
>> multiplexing of multiple 9P2000 clients/"sessions" onto a single,
>> multiplexed, session with the server.  In theory, all a 9P2000
>> multiplexer would have to do is map tags and fids so that different
>> clients don't use the same values, and negotiate a common version and
>> msize in the Tversion/Rversion transactions.  All the functionality of
>> the protocol, including access control using afids, would be preserved.
>> In fact, while complying fully with the 9P2000 specification, it should
>> also be possible to multiplex sessions in the REVERSE direction
>> (connections from clients on the remote "server" host BACK to servers
>> listening on the local "client" host) over the same TCP connection used
>> to carry the "forward" (local --> remote) sessions.
>> 
>> I'd assumed, since the protocol allows for this, that this sort of
>> multiplexing was done by the Plan 9 and Inferno kernels.  Is that not
>> the case?  And if not, then why not?
>> 
>> To take a stab at answering my own question, I suspect that it might
>> have something to do with the Station to Station protocol and SSL setup
>> done on a connection prior to exchanging Styx messages.  But it seems to
>> me that S2S and SSL init could also be multiplexed by the kernel, or
>> even transacted over a temporary TCP connection established solely for
>> initializing the Styx session.  That is to suggest that a client could
>> connect directly to a server, execute S2S, close that connection,
>> provide the SSL parameters and shared secret to the kernel, then push
>> the Styx messages (including any afid) through the kernel multiplexer.
>> The kernel could then send the client's Styx messages over the
>> multiplexed connection using the SSL parameters specified by the client.
>> 
>> I'd imagine that there could be some latencey issues that might result
>> from an approach like this, i.e. if an interactive session were
>> conducted over the same connection as a large file transfer.  But
>> there's nothing to stop a client from establishing its own TCP
>> connection (or, at the very least, asking the kernel to allocate a
>> second multiplexed connection).  Still, multiplexing Styx sessions could
>> have some advantages, such as when traversing firewalls where there are
>> limits on the number of simultaneous TCP connections or timeouts on
>> individual connections.  Multiplexing sessions would help "keep alive"
>> such TCP connections.  It would also help protect encrypted
>> communication from traffic analysis.
>> 
>> Now that I've been typing about this for a few paragraphs, it occurs to
>> me that a multiplexer like this could probably be implemented as a
>> system service running in userspace, without much (if any) extra support
>> from the kernel.
>> 
>> So, do Plan 9 or Inferno already do anything like this?  If not, do you
>> think it would be a smart thing to implement?  I'm curious to hear other
>> people's thoughts on this.
> 

[9fans] Fwd: Multiplexing Styx/9P2000 over TCP connections

[cigar562hfsp952fans]

I recently posted the following to the Inferno mailing list (but
received no response).  I'm re-posting here, as this applies to Plan 9
just as much as to Inferno, anyway...

> So, I've been looking at the source code of Inferno, and I've noticed
> that, when mount(1) wants to connect to a Styx/9P2000 server on a remote
> machine, it generally opens up a new TCP connection... one for each new
> mount... even if it's just an additional connection to the same service
> on the same remote host.
>
> Recalling the specification for 9P2000, the protocol supports the
> multiplexing of multiple 9P2000 clients/"sessions" onto a single,
> multiplexed, session with the server.  In theory, all a 9P2000
> multiplexer would have to do is map tags and fids so that different
> clients don't use the same values, and negotiate a common version and
> msize in the Tversion/Rversion transactions.  All the functionality of
> the protocol, including access control using afids, would be preserved.
> In fact, while complying fully with the 9P2000 specification, it should
> also be possible to multiplex sessions in the REVERSE direction
> (connections from clients on the remote "server" host BACK to servers
> listening on the local "client" host) over the same TCP connection used
> to carry the "forward" (local --> remote) sessions.
>
> I'd assumed, since the protocol allows for this, that this sort of
> multiplexing was done by the Plan 9 and Inferno kernels.  Is that not
> the case?  And if not, then why not?
>
> To take a stab at answering my own question, I suspect that it might
> have something to do with the Station to Station protocol and SSL setup
> done on a connection prior to exchanging Styx messages.  But it seems to
> me that S2S and SSL init could also be multiplexed by the kernel, or
> even transacted over a temporary TCP connection established solely for
> initializing the Styx session.  That is to suggest that a client could
> connect directly to a server, execute S2S, close that connection,
> provide the SSL parameters and shared secret to the kernel, then push
> the Styx messages (including any afid) through the kernel multiplexer.
> The kernel could then send the client's Styx messages over the
> multiplexed connection using the SSL parameters specified by the client.
>
> I'd imagine that there could be some latencey issues that might result
> from an approach like this, i.e. if an interactive session were
> conducted over the same connection as a large file transfer.  But
> there's nothing to stop a client from establishing its own TCP
> connection (or, at the very least, asking the kernel to allocate a
> second multiplexed connection).  Still, multiplexing Styx sessions could
> have some advantages, such as when traversing firewalls where there are
> limits on the number of simultaneous TCP connections or timeouts on
> individual connections.  Multiplexing sessions would help "keep alive"
> such TCP connections.  It would also help protect encrypted
> communication from traffic analysis.
>
> Now that I've been typing about this for a few paragraphs, it occurs to
> me that a multiplexer like this could probably be implemented as a
> system service running in userspace, without much (if any) extra support
> from the kernel.
>
> So, do Plan 9 or Inferno already do anything like this?  If not, do you
> think it would be a smart thing to implement?  I'm curious to hear other
> people's thoughts on this.

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Tiago Natel]

2016-02-01 20:03 GMT-02:00 :

> > Is there a reason why lib9p doesn't have a clunk function pointer in Srv
> struct?
>
> what about Srv.destroyfid()?
>
>   Destroyfid
>When a Fid's reference count drops to zero (i.e., it
>has been clunked and there are no outstanding requests
>referring to it), destroyfid is called to allow the
>program to dispose of the fid->aux pointer.
>
>
Thanks for your help! I'd tried using destroyfid to achieve what I need but
failed. I tried today again implement with destroyfid but realized that it
will not fully support what I need.

I'm using a file server for exchange data between 9P clients. When a new
file is created, I create a plan9 channel and two threads (one for handle
reads and other for writes), a write(2) to the file is translated into a
sendp and a read(2) is translated into a recvp on the channel. The channel
could be buffered or not, and then I want to maintain data allocated (aux
related data) anyway, because the file server is a queueing system when
channel have a buffer bigger than zero.

Apart from that, I want to know how many clients have each file opened to
update my stats file. It's possible in any way without a clunk callback?

I'm trying to replace a rabbitmq server with this system, but I have a
requirement for some way of monitoring of queues size, performance of
channels, number of clients connected to each channel (file on dchan), etc,
I need this kind of information for make a comparison with the current
queue system...

Thanks!

--
> cinap
>
>

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Skip Tavakkolian]

i'd recommend studying 9pserve.c in plan9port.

On Tue, Feb 2, 2016 at 10:17 AM Tiago Natel 
wrote:

> 2016-02-01 20:03 GMT-02:00 :
>
>> > Is there a reason why lib9p doesn't have a clunk function pointer in
>> Srv struct?
>>
>> what about Srv.destroyfid()?
>>
>>   Destroyfid
>>When a Fid's reference count drops to zero (i.e., it
>>has been clunked and there are no outstanding requests
>>referring to it), destroyfid is called to allow the
>>program to dispose of the fid->aux pointer.
>>
>>
> Thanks for your help! I'd tried using destroyfid to achieve what I need
> but failed. I tried today again implement with destroyfid but realized that
> it will not fully support what I need.
>
> I'm using a file server for exchange data between 9P clients. When a new
> file is created, I create a plan9 channel and two threads (one for handle
> reads and other for writes), a write(2) to the file is translated into a
> sendp and a read(2) is translated into a recvp on the channel. The channel
> could be buffered or not, and then I want to maintain data allocated (aux
> related data) anyway, because the file server is a queueing system when
> channel have a buffer bigger than zero.
>
> Apart from that, I want to know how many clients have each file opened to
> update my stats file. It's possible in any way without a clunk callback?
>
> I'm trying to replace a rabbitmq server with this system, but I have a
> requirement for some way of monitoring of queues size, performance of
> channels, number of clients connected to each channel (file on dchan), etc,
> I need this kind of information for make a comparison with the current
> queue system...
>
> Thanks!
>
> --
>> cinap
>>
>>

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[cinap_lenrek]

> I'm using a file server for exchange data between 9P clients. When a new
> file is created, I create a plan9 channel and two threads (one for handle
> reads and other for writes), a write(2) to the file is translated into a
> sendp and a read(2) is translated into a recvp on the channel. The channel
> could be buffered or not, and then I want to maintain data allocated (aux
> related data) anyway, because the file server is a queueing system when
> channel have a buffer bigger than zero.

It is hard to say without seeing the code, but this construction sounds wrong
as recvp() in Srv.read would block the 9p read loop causing you to
not process any other 9p requests when one client is blocked in a read.
You also want to handle flushes otherwise you cannot interrupt/cancel
the blocked read. You can handle this by chaining the Req's that you
cannot satisfy immidiately in a linked list and respond to them from some
other proc or thread once you have data the client could read.

What do you mean by client? You could have multiple Srv's with each
client having its own network connection to it. Or it could mean multiple
attaches (mounts) and a single Srv. Or you it could mean you mean *someone*
reading the file and the state about a "Client" is in the Fid. Anyway,
it sounds like the problem you'r having with destroyfid() is that it doenst
give you access to information whoever is the client of the file closed no?

--
cinap

[9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Tiago Natel]

Someone here can help me?

-- Forwarded message --
From: Tiago Natel 
Date: 2016-02-01 19:17 GMT-02:00
Subject: lib9p: Add clunk callback to Srv struct
To: 9fr...@9front.org


Hello folks,

Is there a reason why lib9p doesn't have a clunk function pointer in Srv
struct?

I have a file server project using Srv and I want to know when no one
client have a specific file opened.

One way that I was able to get this working was forking 9front and adding a
clunk callback to Srv structure. See the commit below:

https://bitbucket.org/tiago4orion/plan9front/commits/5e1141f0a4aa98310cb0e2382c5c78c60fe73b4f

My project usage of the clunk routine is here:
https://bitbucket.org/tiago4orion/dchan/src/60dc3e45eb28c8a8289c177680120ef7f44e0925/fs.c?fileviewer=file-view-default#fs.c-680

This makes sense? Or is there better ways to achieve this?
And if that makes sense, it can go upstream?

Thanks.

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[cinap_lenrek]

> Is there a reason why lib9p doesn't have a clunk function pointer in Srv 
> struct?

what about Srv.destroyfid()?

  Destroyfid
   When a Fid's reference count drops to zero (i.e., it
   has been clunked and there are no outstanding requests
   referring to it), destroyfid is called to allow the
   program to dispose of the fid->aux pointer.

--
cinap

Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct

[Skip Tavakkolian]

> I have a file server project using Srv and I want to know when no one
> client have a specific file opened.

i believe since you're using alloctree and passing in the destroy function, you 
don't need it. 

Re: [9fans] Fwd: how to change login user on 9pi?

[Richard Miller]

 my content of /n/9fat/cmdline.txt is:
 readparts=1 nobootprompt=local user=kokamoto ipconfig='-g 192.168.11.1 ether 
 /net/ether0 192.168.11.17 255.255.255.0' kbmap=/boot/jp
 
 So, how I can change the login user?

Just delete 'user=kokamoto'.

Re: [9fans] Fwd: how to change login user on 9pi?

[kokamoto]

Thanks Richard.

 Just delete 'user=kokamoto'.

Wow, that's easy enough.
I tried user='', and got confused.

Kenji

Re: [9fans] Fwd: Seiki 4k + RPi + Plan9

[Richard Miller]

 1. You will need one plan9 fix:

Now available as /n/sources/patch/bcm-mmukmap-bug - I hope somebody
can apply this on sources.

Re: [9fans] Fwd: Building a Raspberry Pi image / Keyboard support

[Kurt H Maier]

Quoting erik quanstrom quans...@quanstro.net:


oh, editors have a 40 year head start.  rpi can't possibly have reached
that level of tedium yet, can they have?


I think Eternal-September saturation levels may have effected a bit of
a steeper curve on the who-cares charts

khm

Re: [9fans] Fwd: Building a Raspberry Pi image / Keyboard support

[Richard Miller]

 By the way, how I can arrage the correct time in this system?
 I don't mean the /adm/timezone/local, because
 in the usual PC, we can change it at BIOS screen.

Unlike a PC, the raspberry pi doesn't have a battery-backed
real time clock.  If you configure a kernel without the 'fakertc'
device, it will prompt you to enter the time and date when you
power on.  For me this was too annoying, which is why I made the
fakertc device.  With a network connection, the time should be
corrected by aux/timesync soon after booting.

Re: [9fans] Fwd: Building a Raspberry Pi image / Keyboard support

[Skip Tavakkolian]

there are RTC modules for the pi (talk over i2c, based on DS1307
or DS3231). i use them with linux distro's and they seem to work fine.



On Mon, Jul 7, 2014 at 6:59 AM, Richard Miller 9f...@hamnavoe.com wrote:

  By the way, how I can arrage the correct time in this system?
  I don't mean the /adm/timezone/local, because
  in the usual PC, we can change it at BIOS screen.

 Unlike a PC, the raspberry pi doesn't have a battery-backed
 real time clock.  If you configure a kernel without the 'fakertc'
 device, it will prompt you to enter the time and date when you
 power on.  For me this was too annoying, which is why I made the
 fakertc device.  With a network connection, the time should be
 corrected by aux/timesync soon after booting.

Re: [9fans] Fwd: Building a Raspberry Pi image / Keyboard support

[Bakul Shah]

On one RPi I am using a GPS module. I need to add support for its PPS signal 
for more accurate time keeping.

 On Jul 7, 2014, at 7:39 AM, Skip Tavakkolian skip.tavakkol...@gmail.com 
 wrote:
 
 there are RTC modules for the pi (talk over i2c, based on DS1307 or DS3231). 
 i use them with linux distro's and they seem to work fine.
 
 
 
 On Mon, Jul 7, 2014 at 6:59 AM, Richard Miller 9f...@hamnavoe.com wrote:
  By the way, how I can arrage the correct time in this system?
  I don't mean the /adm/timezone/local, because
  in the usual PC, we can change it at BIOS screen.
 
 Unlike a PC, the raspberry pi doesn't have a battery-backed
 real time clock.  If you configure a kernel without the 'fakertc'
 device, it will prompt you to enter the time and date when you
 power on.  For me this was too annoying, which is why I made the
 fakertc device.  With a network connection, the time should be
 corrected by aux/timesync soon after booting.
 

Re: [9fans] Fwd: Building a Raspberry Pi image / Keyboard support

[kokamoto]

 real time clock.  If you configure a kernel without the 'fakertc'

Thanks Richard.
Yes, I wondered what is this when compiling 9pi.☺

 fakertc device.  With a network connection, the time should be
 corrected by aux/timesync soon after booting.

I made over a LAN to wireless bridge yesterday.
When it'd be arrived, I can try it.

Your 9pi is very nice Plan 9 terminal, indeed.
I'm now considering to make a box by myself.
This is because I don't feel them charm than pi itself, 
which we can get from the market now.  
All them are too plasticy and boxy to me.
If could have a time of course.

Kenji

Re: [9fans] Fwd: Building a Raspberry Pi image / Keyboard support

[Skip Tavakkolian]

raspberry pi boxes and discussions about them are as varied and
entertaining as program editors.




On Mon, Jul 7, 2014 at 4:53 PM, kokam...@hera.eonet.ne.jp wrote:

  real time clock.  If you configure a kernel without the 'fakertc'

 Thanks Richard.
 Yes, I wondered what is this when compiling 9pi.☺

  fakertc device.  With a network connection, the time should be
  corrected by aux/timesync soon after booting.

 I made over a LAN to wireless bridge yesterday.
 When it'd be arrived, I can try it.

 Your 9pi is very nice Plan 9 terminal, indeed.
 I'm now considering to make a box by myself.
 This is because I don't feel them charm than pi itself,
 which we can get from the market now.
 All them are too plasticy and boxy to me.
 If could have a time of course.

 Kenji

Re: [9fans] Fwd: Building a Raspberry Pi image / Keyboard support

[erik quanstrom]

 raspberry pi boxes and discussions about them are as varied and
 entertaining as program editors.

oh, editors have a 40 year head start.  rpi can't possibly have reached
that level of tedium yet, can they have?

- erik

Re: [9fans] Fwd: 9pi on qemu failure

[Richard Miller]

 This works though with a linux kernel compiled for the raspberry, e.g.
 from http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/ 
 wget http://xecdesign.com/downloads/linux-qemu/kernel-qemu

I would bet that linux kernel isn't actually configured for the
raspberry pi -- it will be for a generic arm1176.  The pi's processor isn't
an arm1176 exactly; it's a Broadcom bcm2835 videocore gpu, with an arm
core grafted on.  It's highly unlikely that qemu knows how to emulate
this well enough for a native bcm kernel like 9pi to run successfuly.
The emulating raspberry pi the easy way is not really emulating the
pi, just using a generic arm kernel to run linux software from a
raspberry pi linux distribution image.

If you want to run 9pi, I recommend buying a raspberry pi.  They aren't
expensive, and native Plan 9 is a much more rewarding experience.

Re: [9fans] Fwd: 9pi on qemu failure

[Richard Miller]

 I've tried to run 9pi from richard miller on qemu but failed
 ...
 does anyone have the s9pi kernel image that corresponds to this?
 i don't so i can't connect this failure to the source.

Looking at file dates, that was an old kernel which came from
9pi.img-old.gz .  I've now replaced 9pi (and added a corresponding
s9pi) with the kernel from the newer 9pi.img.gz, to reduce confusion.

[9fans] Fwd:

[David Leimbach]

http://fiorentinix.altervista.org/ajbev3.php

Re: [9fans] Fwd:

[David Leimbach]

This is not from me.  I just received a bunch of mail from myself on a few 
email accounts at about this time.

Sent from my iPhone

On Jan 15, 2013, at 4:17 AM, David Leimbach leim...@gmail.com wrote:

 http://fiorentinix.altervista.org/ajbev3.php
 

Re: [9fans] Fwd:

[David Leimbach]

It just occurred to me this could be the backup software I use on my Mac that 
runs overnight Its java based client may have done some bad things

Sent from my iPhone

On Jan 15, 2013, at 4:17 AM, David Leimbach leim...@gmail.com wrote:

 http://fiorentinix.altervista.org/ajbev3.php
 

Re: [9fans] Fwd:

[hiro]

And I thought you guys were still using fossil and venti *g*

On 1/15/13, David Leimbach leim...@gmail.com wrote:
 It just occurred to me this could be the backup software I use on my Mac
 that runs overnight Its java based client may have done some bad things

 Sent from my iPhone

 On Jan 15, 2013, at 4:17 AM, David Leimbach leim...@gmail.com wrote:

 http://fiorentinix.altervista.org/ajbev3.php

Re: [9fans] Fwd:

[ron minnich]

On Tue, Jan 15, 2013 at 4:17 AM, David Leimbach leim...@gmail.com wrote:
 http://fiorentinix.altervista.org/ajbev3.php


so, what is that place?

ron

Re: [9fans] Fwd:

[David Leimbach]

Sent from my iPhone

On Jan 15, 2013, at 6:17 AM, ron minnich rminn...@gmail.com wrote:

 On Tue, Jan 15, 2013 at 4:17 AM, David Leimbach leim...@gmail.com wrote:
 http://fiorentinix.altervista.org/ajbev3.php
 
 so, what is that place?
 
 ron
 
No idea

Re: [9fans] Fwd:

[Matthew Veety]

It doesn't render in mothra.

Re: [9fans] Fwd:

[erik quanstrom]

On Tue Jan 15 11:47:31 EST 2013, mve...@gmail.com wrote:
 It doesn't render in mothra.

cat is just as equiped to take on the modern web.

- erik

Re: [9fans] Fwd:

[Kurt H Maier]

On Tue, Jan 15, 2013 at 11:58:59AM -0500, erik quanstrom wrote:
 On Tue Jan 15 11:47:31 EST 2013, mve...@gmail.com wrote:
  It doesn't render in mothra.
 
 cat is just as equiped to take on the modern web.

cat can render images?

Re: [9fans] Fwd:

[Stephen Wiley]

Page can render images.
Inline images are for pomp aristocrats with lots of spare bandwidth laying 
around.

--Stephen
On Jan 15, 2013, at 12:26 PM, Kurt H Maier wrote:

 On Tue, Jan 15, 2013 at 11:58:59AM -0500, erik quanstrom wrote:
 On Tue Jan 15 11:47:31 EST 2013, mve...@gmail.com wrote:
 It doesn't render in mothra.
 
 cat is just as equiped to take on the modern web.
 
 cat can render images?
 

Re: [9fans] Fwd:

[Kurt H Maier]

On Tue, Jan 15, 2013 at 02:39:02PM -0500, Stephen Wiley wrote:
 Page can render images.
 Inline images are for pomp aristocrats with lots of spare bandwidth laying 
 around.

This is an outrage.  I was promised html parsing and in-line images with
cat.

Re: [9fans] Fwd:

[Jack Johnson]

On Tue, Jan 15, 2013 at 11:04 AM, Kurt H Maier kh...@intma.in wrote:
 This is an outrage.  I was promised html parsing and in-line images with
 cat.

Best mailing list message ever. :)

-J

Re: [9fans] Fwd:

[steve]

oh, that's easy, you just need to use the -v option to cat...

On 15 Jan 2013, at 20:04, Kurt H Maier kh...@intma.in wrote:

 On Tue, Jan 15, 2013 at 02:39:02PM -0500, Stephen Wiley wrote:
 Page can render images.
 Inline images are for pomp aristocrats with lots of spare bandwidth laying 
 around.
 
 This is an outrage.  I was promised html parsing and in-line images with
 cat.

Re: [9fans] Fwd:

[Matthew Veety]

It seems to be mothra's spam blocker doing it. 

On Jan 15, 2013, at 17:03, hiro 23h...@gmail.com wrote:

 Oh, I didn't know it was mothra's fault, I thought it was my DNS spam blocker.
 

[9fans] Fwd: Gathering for Uriel. Need photos!!!

[hiro]

-- Forwarded message --
From: Marie Hogfors marie.hogf...@gmail.com
Date: Mon, Nov 26, 2012 at 3:15 PM
Subject: Gathering for Uriel. Need photos!!!
To: anu_kotam...@hotmail.com, z...@incoherencia.com, 23h...@gmail.com,
frisco.rami...@gmail.com, death.proof.butter...@gmail.com,
thewhiteti...@gmx.net, s...@9front.org


Dear all of You,

On the 12 of January, two days after Uriels birthday, we will arrange
a gathering for Uriel. (Some of you have heard it before. Sorry if I
repeat myself.)

We will heat up and decorate my little Gallery. On the wall there will
be a pictureshow  (with photos of Uriel that I hope you all will send
me) and we will listen to the music he himseif has chosen and we will
drink to each others wellbeeing and in memeory of Uriel.

Thereafter we will go to a beautiful place with big oaks to spread
some seads for the birds that his mothers has sent to me.
 Back home we will have a meal and I hope a more jolly time
together. Ureil wanted us to celebrate! So let us have a good
 meal and a nice
time together.
I have once more contacted Uriels mother and asked her if she wouldn´t
like to come to chose what she wants from his belongings and take part
in the gathering. What ever happens in that respect, we will
distribute his belongings early in the morning the 12 and I hope it
will be done in a nice way. In advance we will put aside those things
that Uriel has mentioned and the small less valuable things you
already have mentioned. Then we draw lots, 1 2 3 One after another
we chose what he or she wants, then we go the other way round 3.2.1...
Do not expect to much...Let it be a nice quiet moment!

And above all we do not know what Uriels mother really wants. First
she asked me not to distribute anything and then she has said that she
wants nothing, but I can´t accept that as a final answer, until I have
got it once more confirmed from her.

About lodging: Andrea asked me if I knew a place. I hesitated...  but
my answer is now that you can all sleep in the bigger room. There is a
dubbelbed,and a sofa and we can bring in Uriels bed, the rest will
have to sleep on the floor. The kitchen and other rooms, I think, we
will need for sorting things up.

 Welcome all of you and please  contact those I have no mail
address to and mail me an answer hopefully with photos of Uriel.
For today,
Marie
P.S. The colourful ribbons I have asked permission to take aside. You
will get some pieces each.

[9fans] Fwd: Initial call for participation 7th International Plan 9 Workshop, Dublin, Ireland, November 14-16, 2012

[Nemo]

[I'm sending this on behalf of Eric Jul. Thus, the From is wrong :). ]

Dear Inferno/Plan 9 fans.

Attached is the initial call for participation for the 7th International 
Plan 9 Workshop, Dublin, Ireland, November 14-16, 2012.

Please note that the workshop this time takes place in November and that 
we are hoping for some good demos besides the usual program.
We have also planned a good social program in Dublin.


Sincerely,

Eric Jul

Title: 7th International Workshop on Plan 9










  



  

Initial Call for Participation7th International Workshop on Plan 9
November 14  16, 2011
Bell Labs Ireland
Alcatel-Lucent
Blanchardstown Business and Technology Park
Snugborough Road, Blanchardstown
Dublin 15, Republic of Ireland




  



Important Dates -
Paper Submission -
Program -
WIP Submission -
Registration -
Location  Travel -
Accommodation -
Posters



Purpose
The workshop aims to bring together researchers, developers and students working on 
Plan 9 from Bell Labs or related systems,
platforms, and projects, to discuss a wide range of system and application ideas
and issues.
 
Previous issues: 1st IWP9 (2006), 
Rey Juan Carlos University, Madrid, Spain; 

2nd IWP9 (2007), Bell Labs, NJ, United States;

3rd IWP9 (2008), University of Thessaly, Volos, Greece;

4th IWP9 (2009), University of Georgia, Athens, GA, United States;

5th IWP9 (2010), Seattle, WA, United States;

6th IWP9 (2011), Universidad Rey Juan Carlos, Fuenlabrada, Madrid, Spain.



Important Dates
Oct 15: Paper submission deadline 
Oct 24: Paper acceptance notification
Oct 25: Works in progress and demos submission deadline	(may be subject to change) 
Nov  1: WIP/Demos acceptance notification	(may be subject to change)		
Nov  5: Registration deadline	(may be subject to change)		
Nov  6: Camera ready version		(may be subject to change)	
Nov 14-16: Workshop in Dublin	



Paper Submission (preliminary instructions subject to minor changes) 
Papers of up to 15 pages must be sent to iwp9papers at ericjul.dk 
in PDF or PS format.  The call for papers is not here yet.
Please do not forget to include the e-mail address of the contact author.  
Submissions will be acknowledged via e-mail (please allow for a small delay).
Papers must be visually similar to Plan 9 papers that can be found 
at /sys/doc/9/ in order to compile a homogeneous proceedings book.  
See for example this paper. 
These macros and this mkfile
can be used to duplicate this look.
Please keep this look and feel, use the same fonts and do not include page numbers.  

For accepted papers, besides the PDF/PS file, it would be nice, if authors could provide 
a LaTeX (or troff) source as to facilitate the compilation of the proceedings printable version.
This is not mandatory.
In the worst case, page numbers and a toc will be added by hand. You might, however, have to compensate
for this at an Irish pub.
The workshop proceedings will be published in electronic form.
We are also considering the edition of a printed version with ISBN, to be distributed during 
the workshop.



Preliminary Schedule for Program 

June 14th:
14:00   Registration (and coffee)
16:00   Welcome + keynote
17:00   Demos
19:00   Intro to Irish pub + pub dinner
22:00   Live Irish Session music at music pub

June 15th
09:30   panel: news from new systems: osprey, inferno-ports, and nix
11:00	  talks
12:00   Lunch at nearby Market (bring coat in case of rain)
14:00   talks/demos
18:00   Irish Microbrew
20:00   Dinner at restaurant (TBD)

June 15th
9:30talks
13:00   lunch at Bell Labs
14:00   talks
15:30   concluding remarks




Demos Submission 
We solicit interesting demos.
Send a description, include a time limit for your demo.




WIP Submission 
WIP of up to 3 pages must be set to iwp9wip at ericjul.dk 
in PDF or PS format.  
Please do not forget to include the e-mail address of the contact author.  
Submissions will be acknowledged via e-mail (please allow for a small delay).
Formatting requirements are the same as for papers.




Program and Proceedings
Printed copies of the proceedings
will be provided to all participants and authors.
An electronic copy will be made available.



Registration
The registration deadline is Oct 10th, 2011.  To register, please send an 
e-mail to iwp9reg at lsub.org
with your name, affiliation and e-mail address, one per line.  



Location  Travel



Location  Travel
Bell Labs Ireland is located in Alcatel-Lucents building in the
Blanchardstown Business and Technology Park approximately 12 km from the center of
Dublin and approximately 15 km from the Dublin airport.
The schedule is so that you may arrive at the Dublin airport by 2-3pm on Wednesday
and fly out on Friday afternoon on flights departing at 6pm or later.

How to get there from the airport (full details later):
>From the Dublin airport, Bell 

Re: [9fans] Fwd: Initial call for participation 7th International Plan 9 Workshop, Dublin, Ireland, November 14-16, 2012

[erik quanstrom]

On Thu Sep  6 13:40:16 EDT 2012, n...@lsub.org wrote:

 [I'm sending this on behalf of Eric Jul. Thus, the From is wrong :). ]
 
 Dear Inferno/Plan 9 fans.
 
 Attached is the initial call for participation for the 7th International 
 Plan 9 Workshop, Dublin, Ireland, November 14-16, 2012.
 
 Please note that the workshop this time takes place in November and that 
 we are hoping for some good demos besides the usual program.
 We have also planned a good social program in Dublin.

cool!

- erik

Re: [9fans] Fwd: Initial call for participation 7th International Plan 9 Workshop, Dublin, Ireland, November 14-16, 2012

[arisawa]

2011?

Kenji Arisawa

On 2012/09/07, at 2:38, Nemo wrote:

 [I'm sending this on behalf of Eric Jul. Thus, the From is wrong :). ]
 
 Dear Inferno/Plan 9 fans.
 
 Attached is the initial call for participation for the 7th International 
 Plan 9 Workshop, Dublin, Ireland, November 14-16, 2012.
 
 Please note that the workshop this time takes place in November and that 
 we are hoping for some good demos besides the usual program.
 We have also planned a good social program in Dublin.
 
 
 Sincerely,
 
 Eric Jul
 
 7th International Workshop on Plan 9 preliminary call.htm
 

Re: [9fans] Fwd: Initial call for participation 7th International Plan 9 Workshop, Dublin, Ireland, November 14-16, 2012

[erik quanstrom]

On Thu Sep  6 20:01:22 EDT 2012, aris...@ar.aichi-u.ac.jp wrote:
 2011?
 
 Kenji Arisawa
 
 On 2012/09/07, at 2:38, Nemo wrote:
 
  [I'm sending this on behalf of Eric Jul. Thus, the From is wrong :). ]
  
  Dear Inferno/Plan 9 fans.
  
  Attached is the initial call for participation for the 7th International 
  Plan 9 Workshop, Dublin, Ireland, November 14-16, 2012.
  
  Please note that the workshop this time takes place in November and that 
  we are hoping for some good demos besides the usual program.
  We have also planned a good social program in Dublin.

no, 2012.  see iwp9.org ... currently with very little information.  :-)

- erik

Re: [9fans] Fwd: Call for Papers: LASER 2012?Learning from Authoritative Security Experiment Results

[tlaronde]

On Tue, Jan 10, 2012 at 10:19:36PM -0800, ron minnich wrote:
 This is kind of a fun one: stuff that DID NOT work. I like the basic idea

I generally learn more from what I do wrong than from what I do right---
sometimes because when it works, it is not absolutely for the reasons
I had explicitely in view... so the lesson is less than zero.

And there is the classical joke about the experiment on a flea:

Researcher tells the flea: jump!---and the flea jumps.
He cuts one leg. Jump!---and the flea, with more difficulty, jumps.
He cuts another leg. Jump!---after some time and great efforts, it
jumps.
He cuts one more. Jump!---and the flea doesn't jump.

Scientific conclusion: when one cuts legs to a flea, it becomes deaf.
-- 
Thierry Laronde tlaronde +AT+ polynum +dot+ com
  http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Fwd: Call for Papers: LASER 2012—Learning from Authoritative Security Experiment Results

[Wes Kussmaul]

On Tue, 2012-01-10 at 22:19 -0800, ron minnich wrote:
 This is kind of a fun one: stuff that DID NOT work. I like the basic
 idea ... 

  “failures” may actually provide clues to even more significant
 results than the original experimenter had intended. The research is
 useful, even though the results are unexpected.

When Mario Salvadori gave his grandmother a copy of his new book, _Why
Buildings Stand Up_, she thanked him and said but I'd much rather know
why buildings fall down.

That remark was the catalyst for his next book, _Why Buildings Fall
Down_.

[9fans] Fwd: Call for Papers: LASER 2012—Learning from Authoritative Security Experiment Results

[ron minnich]

This is kind of a fun one: stuff that DID NOT work. I like the basic idea
...

ron

-- Forwarded message --
From: Edward Talbot edward.tal...@gmail.com
Date: Tue, Jan 10, 2012 at 1:48 PM
Subject: Call for Papers: LASER 2012—Learning from Authoritative Security
Experiment Results
To: Ronald Minnich rminn...@gmail.com


Ron -

I hope all is well with you!

I'm on the Organizing Committee for the subject workshop.  The Call For
Papers for the workshop has been released and is attached and copied below.

Your efforts to insure that this CFP is widely distributed are appreciated.


The workshop website is http://www.cert.org/laser-workshop/

Thanks for your time and consideration.

Ed
--
Edward B. Talbot
Cell: (925) 667-5994
Google Voice: (925) 452-7827

*LASER 2012—Learning from Authoritative Security Experiment Results*



The goal of this workshop is to provide an outlet for publication of
unexpected research results in security—to encourage people to share not
only what works, but also what doesn’t.  This doesn’t mean bad research—it
means research that had a valid hypothesis and methods, but the result was
negative. Given the increased importance of computer security, the security
community needs to quickly identify and learn from both success and
failure.

`Journal papers and conferences typically contain papers that report
successful experiments that extend our knowledge of the science of
security, or assess whether an engineering project has performed as
anticipated. Some of these results have high impact; others do not.
Unfortunately, papers reporting on experiments with unanticipated results
that the experimenters cannot explain, or experiments that are not
statistically significant, or engineering efforts that fail to produce the
expected results, are frequently not considered publishable, because they
do not appear to extend our knowledge.  Yet, some of these “failures” may
actually provide clues to even more significant results than the original
experimenter had intended. The research is useful, even though the results
are unexpected.

Useful research includes a well-reasoned hypothesis, a well-defined method
for testing that hypothesis, and results that either disprove or fail to
prove the hypothesis.  It also includes a methodology documented
sufficiently so that others can follow the same path. When framed in this
way, “unsuccessful” research furthers our knowledge of a hypothesis and
testing method. Others can reproduce the experiment itself, vary the
methods, and change the hypothesis; the original result provides a place to
begin.

As an example, consider an experiment assessing a protocol utilizing
biometric authentication as part of the process to provide access to a
computer system. The null hypothesis might be that the biometric technology
does not distinguish between two different people; in other words, that the
biometric element of the protocol makes the approach vulnerable to a
masquerade attack. Suppose the null hypothesis is not rejected. It would
still be worth publishing this result. First, it might prevent others from
trying the same biometric method. Second, it might lead them to further
develop the technology—to determine whether a different style of biometrics
would improve matters, or if the environment in which authentication is
being attempted makes a difference.  For example, a retinal scan may be a
failure in recognizing people in a crowd, but successful where the users
present themselves one at a time to an admission device with controlled
lighting, or when multiple “tries” are included. Third, it might lead to
modifying the encompassing protocol so as to make masquerading more
difficult for some other reason.

Equally important is research designed to reproduce the results of earlier
work. Reproducibility is key to science, to validate or uncover errors or
problems in earlier work. Failure to reproduce the results leads to a
deeper understanding of the phenomena that the earlier work uncovers.

The workshop focuses on research that has a valid hypothesis and
reproducible experimental methodology, but where the results were
unexpected or did not validate the hypotheses, where the methodology
addressed difficult and/or unexpected issues, or that identified previously
unsuspected confounding issues.

We solicit research and position papers addressing these issues, especially
(but not exclusively) on the following topics:

·Unsuccessful research in experimental security

·Methods, statistical analyses, and designs for security experiments

·Experimental confounds, mistakes, mitigations

·Successes and failures in reproducing the experimental techniques
and/or results of earlier work

Extended abstracts, full position papers, and research submissions should
be 6–10 pages long including tables, figures, and references. Please use
the ACM Proceedings Format at
http://www.acm.org/sigs/publications/proceedings-templates (Option 1, 

[9fans] Fwd: nvram on a diskless cpu server

[Akshat Kumar]

I asked this of nemo, should have
forwarded here as well:


-- Forwarded message --
Hi Francisco,

Doesn't authsrv itself write to the raw data file
you provide in `nvram=' in plan9.ini? Otherwise,
what would be the format to do so manually?

Also, what does device name mean in this case?
#u/ep... or #S/sdU...?


Thanks,
ak

On Sun, Jul 10, 2011 at 3:34 PM, Francisco J Ballesteros n...@lsub.org wrote:
 write to the raw disk, and use the device name for nvram in plan9.ini

 On Mon, Jul 11, 2011 at 12:20 AM, Akshat Kumar
 aku...@mail.nanosouffle.net wrote:
 Sure, but how do mounting and reading and all
 that jazz, work on boot?

 On Sun, Jul 10, 2011 at 3:13 PM, ron minnich rminn...@gmail.com wrote:
 yeah, the usb would be a great place to store it! Then you can easily
 rewrite the key ...

 ron

Re: [9fans] Fwd: nvram on a diskless cpu server

[ron minnich]

term% cd /tmp
term% dd -bs 512 -count 1  /dev/zero  nvram
1+0 records in
1+0 records out
term% nvram=nvram
term%  xd nvram
000     
010     

etc.

term% auth/wrkey
bad nvram key
bad authentication id
bad authentication domain
authid: xyz
authdom: abc
secstore key:
password:
term% cat nvram
1��@�123�xyztabc/term%  xd nvram
000  31d90c00 028140e2  
010  31323300   9f78
020  797a   
030    0074 61626300
040     

etc.

It pays to make the nvram file len 512 bytes or you have to set
nvramlen in plan9.ini and who wants to do that.

Note the nvram=nvram step ... it is needed.

ron
p.s. No points for guessing the password I used :-)

[9fans] Fwd: cifsd

[Sergey Kornilovich]

Thanks, now everything works fine.

But if you want that windows clients can connect any vacfile (in /lib/vac or
$home/lib/vac), you must modify the file /bin/9fs.

This is: vacfs -m /n/`{basename $1.vac} `{cat $score}
To this: vacfs -p -m /n/`{basename $1} `{cat $ score}
(-p Disables permission checking)
If anyone knows a more elegant way to do it, I'll be glad to hear.



14 апреля 2011 г. 1:06 пользователь cinap_len...@gmx.de написал:

 with further thought... i removed the pipe code and now redirect
 /sys/log/cifsd to stdout/stderr of /bin/9fs and just do a wait() call
 to see if it terminates. i think this is the cleanest thing todo and doesnt
 leak any filedescriptors into 9fs...

 the changed code in question is in share.c of the cifsd.tgz tarball.

 --
 cinap


 -- Пересылаемое сообщение --
 From: Sergey Kornilovich roo...@gmail.com
 To: cinap_len...@gmx.de
 Date: Wed, 13 Apr 2011 23:54:32 +0400

 Subject: Re: [9fans] cifsd

 cat /bin/service/tcp445
 #!/bin/rc
 exec /bin/ip/cifsd -t -d -f /sys/log/cifsd.debug

 ps|grep cifsd
 bootes 374 0:00 0:00 212K Pread cifsd
 bootes 908 0:00 0:00 212K Pread cifsd
 bootes 1391 0:00 0:00 212K Pread cifsd
 none 2332 0:00 0:00 212K Pread cifsd
 none 2527 0:00 0:00 212K Pread cifsd

 tail -f /sys/log/cifsd.debug
 started [2527]
 [72] SMB_COM_NEGOTIATE
 [0] PC NETWORK PROGRAM 1.0
 [1] LANMAN1.0
 [2] Windows for Workgroups 3.1a
 [3] LM1.2X002
 [4] LANMAN2.1
 [5] NT LM 0.12
 [6] SMB 2.002
 [7] SMB 2.???
 respond: err=0

 [73] SMB_COM_SESSION_SETUP_ANX
 bs=8000 cap=d4 user=KROK dom=KROK os= lanman=
 auth successfull
 [75] SMB_COM_TREE_CONNECT_ANDX
 mapshare \\192.168.1.200\IPC$ - IPC IPC$ /dev/null
 [ff] SMB_COM_NO_ANDX_COMMAND
 respond: err=0

 [73] SMB_COM_SESSION_SETUP_ANX
 bs=8000 cap=d4 user=KROK dom=KROK os= lanman=
 [75] SMB_COM_TREE_CONNECT_ANDX
 mapshare \\192.168.1.200\VAC - A: vac /n/vac


 13 апреля 2011 г. 23:24 пользователь cinap_len...@gmx.de написал:

 check with ps that there are no broken cifsd processes for
 bootes... if there are, run acid pid and type lstk() to get
 a stacktrace...

 if this is not the case...  lets enable more debugging to figure out
 whats going on...

 add -d -f /sys/log/cifsd.debug option to /bin/service/tcp445 command line.

 create a world writable append only file in /sys/log

 touch /sys/log/cifsd.debug
 chmod a+wa /sys/log/cifsd.debug

 --
 cinap


 -- Пересылаемое сообщение --
 From: Sergey Kornilovich roo...@gmail.com
 To: cinap_len...@gmx.de
 Date: Wed, 13 Apr 2011 23:13:22 +0400
 Subject: Re: [9fans] cifsd
 You are right.
 To test, I changed the file 9fs adding:

 case vac
 vacfs /lib/vac/1.vac
 but
 C: \ net use Y: \\192.168.1.200\vac
 pause for 1 minute
 System error 64 has occurred.

 The specified network name is no longer available.
 I run cifsd -t
 /sys/log/cifsd
 server Apr 13 22:43:45 (nil\nil) started [908]
 server Apr 13 22:43:45 (nil\bootes) auth successfull
 server Apr 13 22:43:45 (nil\bootes) mapshare \\192.168.1.200\IPC$ - IPC
 IPC$ /dev/null
 server Apr 13 22:43:45 (nil\bootes) mapshare \\192.168.1.200\VAC - A:
 vac /n/vac


 2011/4/13 cinap_len...@gmx.de

 cifsd expetcts that the 9fs $foo command mounts the filesystem to
 /n/$foo where $foo is derived from the smb share name by turning all
 upper case characters to lower case.

 so if 9fs vac.1 mounts to /n/1 instead of /n/vac.1 you will get a
 empty directory in cifsd because it will look in /n/vac.1.

 but this does not explain the error 64...

 do you logon to the cifsd server with the right plan9 user name?  have
 you tried running the 9fs command as the same user?

 do you see anything in /sys/log/cifsd?

 --
 cinap


 -- Пересылаемое сообщение --
 From: Sergey Kornilovich roo...@gmail.com
 To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net
 Date: Wed, 13 Apr 2011 13:54:34 +0400
 Subject: Re: [9fans] cifsd

 Trying to connect the vac file through cifsd.
 net use Y: \ \ 192.168.0.190 \ 1.vac (/ lib/vac/1.vac exist and 9fs
 1.vac command mount 1.vac in / n / 1)
 But on the windows client receives:
 C: \ net use Y: \ \ 192.168.0.190 \ 1.vac
 pause for 1 minute
 System error 64 has occurred.

 The specified network name is no longer available.

 Show you how to do it right?

 P.S. Local connection works fine.
 C: \ net use Y: \ \ 192.168.0.190 \ local
 The command completed successfully.

 2010/9/22 David Leimbach leim...@gmail.com



 On Tue, Sep 21, 2010 at 5:35 PM, Akshat aku...@mail.nanosouffle.netwrote:

 Just for the official record: cifsd works perfectly fine with Windows
 7.

 Cinap's approach to the problem of packet-based protocols is elegant,
 efficient, and through the invent of printf-alike functions, fits well 
 with
 the Plan 9 programming suite/style.


  Looks like a LinkedIn recommendation!  I would use this but I've been
 happily windows free for years now.  Windows 7 seems to be drawing people
 back in, but I'm not sure I want to make the leap yet.  Depends if Apple
 turns Mac 

[9fans] Fwd: plan9 go output faults on 9vx with rfork

[ron minnich]

Pavel built a reproducer and sent it to me:


-- Forwarded message --
From: Pavel Zholkover paulz...@gmail.com
Date: Mon, Jan 17, 2011 at 12:24 PM
Subject: Re: plan9 go output faults on 9vx with rfork
To: ron minnich rminn...@gmail.com


Hi Ron!

I think I've traced the cause of the crash. It is unfortunately the
syscall semacquire.
The following C program will crash vanilla 0.12 9vx and the one I
compiled from your branch:

#include u.h
#include libc.h

static long l=1;

void main(int argc, char *argv[]) {
       int i;

       semacquire(l, 1);

       for(i=0; i  99; i++)
               ;

       semrelease(l, 1);
       exits(nil);
}

---

Got peace and quite and a bulkhead seat to PHX, so had time to look.

The problem was that cmpswap was never set to anything in 9vx, so the
first time canacquire was used, well,
kaboom, since canacquire was NULL.

Changes can be seen here:
https://bitbucket.org/rminnich/vx32/changeset/c7ba21bd847c

My fix is in 9vx/main.c to do this:
cmpswap = oscmpswap;

What's oscmpswap? Well, for darwin, it is defined in 9vx/os/cmpswap.c

You can see the rest of the changes; you can also see that this won't
build on Linux until we fix it; left as an exercise for the reader, or
until I get back home and fix it.

The reproducer no longer crashes 9vx. Now, the question is, what's
next to make Go work on 9vx?

ron

[9fans] Fwd: Fix for using Plan9 compose sequences with Spanish keyboards in X

[pmarin]

Spanish keyboards use different keysyms which are generated by the
following dead keys:

asciitilde →  dead_tilde
grave  → dead_grave
asciicircum → dead_circumflex
apostrophe → dead_acute

The attached awk script can be used to fix the output of 'mklatinkbd -x':

 mklatinkbd -x $PLAN9/lib/keyboard | awk -f spkeys.awk $HOME/.XCompose

Cheers.
Pmarin


spkeys.awk
Description: Binary data

[9fans] Fwd: [TYPES/announce] Postdoc opportunities at UPenn, Harvard, and Northeastern

[James Chapman]

I thought this might interest some 9fans.

James

-- Forwarded message --
From: Benjamin Pierce bcpie...@cis.upenn.edu
Date: Tue, Aug 24, 2010 at 4:44 PM
Subject: [TYPES/announce] Postdoc opportunities at UPenn, Harvard, and
Northeastern
To: types-annou...@lists.seas.upenn.edu, Coq Club
coq-c...@pauillac.inria.fr, Study on Mechanized Metatheory for the
Masses group prov...@lists.seas.upenn.edu


[ The Types Forum (announcements only),
    http://lists.seas.upenn.edu/mailman/listinfo/types-announce ]

Applications are invited for postdoc positions in the areas of
programming languages, formal verification, operating systems, and
hardware design at the University of Pennsylvania, Harvard
University, and Northeastern University.

The hosting project, SAFE (Semantically Aware Foundation Environment),
is part of CRASH, a larger DARPA-funded effort to design new computer
systems that are highly resistant to cyber-attack, can adapt after a
successful attack in order to continue rendering useful services, can
learn from previous attacks how to guard against and cope with future
attacks, and can repair themselves after attacks have succeeded.  It
offers a rare opportunity to rethink the hardware / OS / software
stack from a completely clean slate, with no legacy constraints
whatsoever.

Specifically, we aim to build a suite of modern operating system
services that embodies and supports fundamental security
principles—including separation of privilege, least privilege, and
mutual suspicion—down to its very bones, without compromising
performance.  Achieving this goal demands an integrated effort
focusing on (1) processor architectures, (2) operating systems, (3)
formal methods, and (4) programming languages and compilers -- coupled
with a co-design methodology in which all critical system layers are
designed together, with a ruthless insistence on simplicity, security,
and verifiability at every level.

The ideal candidate will have a Ph.D. in Computer Science, a
combination of strong theoretical and practical interests, and
expertise in two or more of the following areas: programming
languages, security, formal verification, operating systems, and
hardware design.  The position is for one year in the first instance,
with possible renewal up to four years.  Starting date is negotiable.
Applications from women and members of other under-represented groups
are particularly welcome.

To apply, please send a CV, research statement, and the names of three
people who can be asked for letters of reference to Benjamin Pierce
(bcpie...@cis.upenn.edu).  Inquiries can be directed to any of the
PIs:

  Andre Dehon (Penn)
  Greg Morrisett (Harvard)
  Benjamin Pierce (Penn)
  Olin Shivers (Northeastern)
  Jonathan Smith (Penn)

[9fans] [Fwd: Mentor Summit - Dates Confirmed, Holding Pattern for Now (longish but important)]

[Roman V Shaposhnik]

Datewise this looks like a pretty good potential for continuation
of the IWP9 '09 ;-)

Thanks,
Roman.
---BeginMessage---

Hello everyone,

We have confirmed that we'll hold our annual mentor summit on the 24 
25 October this year at the Googleplex in Mountain View, California.
Assume we will also have the pre-summit festivities on the evening of
the 23rd for locals and those who arrive in town early and are not
eaten by jet lag.

As usual, we will be inviting mentoring organizations to send 2
mentors and will make more room for locals who do not require travel
assistance based on space. In other words, we will be keeping a wait
list for local folks again and opening up room for folks on the wait
list as we get closer to the event.

We have not yet determined the following:

- which organizations will be invited (but it's looking good for all
150 from this year so far)
- how much funding will be provided for travel assistance to each
organization
- which hotel we will be using, domain vs. wild palms vs. both
- what meals we will be serving
- summit hours
- schedule of sessions during summit hours

So as you can see, beyond the dates we haven't determined much of
anything. Really, that's OK, as we have two months to figure all that
out and for all of you to buy your plane tickets.

What I'd like to ask now is that all you folks to talk amongst
yourselves to determine who would be best served by representing your
organization at the summit.

If you have never been to a summit, please check out the wiki [0] and
search the archives of this list for more data. Those of you who would
like to share a bit about summits past, please do so in this thread.
For those who would rather not hear the discussion, please mute/
autoarchive/otherwise filter.

If one of you would like to start a page on the wiki for the 2009
summit to begin capturing session ideas and all that jazz. If someone
would like to also copy over the basic content like location
(Googleplex!), airport info, etc and let folks know that is done, we
could begin updating it with our collective wisdom (like the fact that
a limo is now cheaper than a cab from SFO - eek!).

So for now, holding pattern. More info after 1 September, but perhaps
a week or two after that, so patience please.

Cheers,
LH

[0] - https://gsoc-wiki.osuosl.org/index.php/Main_Page

username - mentor
password - yourock


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Summer of Code Mentors List group.
To post to this group, send email to 
google-summer-of-code-mentors-l...@googlegroups.com
To unsubscribe from this group, send email to 
google-summer-of-code-mentors-list+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en
-~--~~~~--~~--~--~---

---End Message---

[9fans] Fwd: [coreboot] ELC 2009 videos and slides

[ron minnich]

some interesting talks in here, esp. the boot time reduction one.

ron


-- Forwarded message --
From: Peter Stuge pe...@stuge.se
Date: Sat, Aug 8, 2009 at 7:28 AM
Subject: [coreboot] ELC 2009 videos and slides
To: coreb...@coreboot.org


http://free-electrons.com/blog/elc-2009-videos/


Some I found particularly interesting:

Quantitative analysis of system initialization in embedded Linux
systems, by Andre Puschmann
http://tree.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFiledo=gettarget=ELC09_boottime_reduction.pdf

Building Embedded Linux Systems with Buildroot, by Thomas Petazzoni
http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFiledo=gettarget=buildroot.pdf

Ksplice: Rebootless kernel updates, by Jeff Arnold (if new to you)
http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFiledo=viewtarget=elc2009-ksplice.pdf


//Peter

--
coreboot mailing list: coreb...@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[9fans] Fwd: p9p acme: incredibly slow typing in tag line for file.

[Russ Cox]

moving to plan9port-dev.
http://bitbucket.org/rsc/plan9port/issue/5/acme-typing-at-1-char-sec-on-ubuntu-904

Subject: [9fans] p9p acme: incredibly slow typing in tag line for file.


From: ron minnich rminn...@gmail.com
Date: Sun, Jun 28, 2009 at 1:04 AM
To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net


I am unable to type at more than about one char per second (I am not
making this up) in p9p acme in the tag line for a file. Only for file
tag lines, not other tag lines, and it's all fine in the actual file
window.

This is ubuntu 9.04. Any hints welcome.

thanks

ron


--
From: Jason Catena jason.cat...@gmail.com
Date: Sun, Jun 28, 2009 at 10:35 PM
To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net


I just pulled down the latest versions with hg, compiled, and don't
see this problem on my Ubuntu 9.04 box.  No appreciable difference in
typing rate for tags for files, directories, or shell-output windows,
or their bodies.

I have seen this kind of response time, but for the whole interface,
because I exported an X-display through VPN from Red Hat to Windows XP
with Cygwin/X.

Does the same delay occur if you write into the tag file under
/mnt/acme?  I don't actually know the source code base that well, but
it seems like it would help narrow things down if writes to the tag
file showed up faster than input from the display.

Jason Catena


--
From: Russ Cox r...@swtch.com
Date: Mon, Jun 29, 2009 at 8:46 AM
To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net


The file tags tend to get redrawn in full after every
change rather than incrementally like the body does.
It has to do with the tag resize calculations, which
I haven't gotten quite right.

That said, you should be able to redraw the tag
more than once per second.  Is this with a remote
X or some other high latency connection to the
underlying graphics?

Russ

--
From: ron minnich rminn...@gmail.com
Date: Mon, Jun 29, 2009 at 12:53 PM
To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net


Right on my laptop. But ubuntu 9.04 is known to have X issues and I
did not know if this was another one.

ron


--
From: Micah Stetson mi...@cnm-vra.com
Date: Tue, Jul 14, 2009 at 12:46 PM
To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net


Has anybody figured this one out?  I just updated to Ubuntu 9.04 and
I'm seeing exactly the behavior Ron describes.  Typing in a file tag
(not a column tag) takes a noticeable amount of time per character --
varying between maybe 200ms and 1000ms by my guess.  Sometimes I get
the same delay in win and directory window tags, sometimes not.  In
any case, typing in the window body is fast.  Also, resizing the acme
window takes far too long -- maybe a couple of seconds.  I think the
time is linear in the number of files I have open in acme.  Somebody
asked whether writing to acme/n/tag was slow as well -- it doesn't
look like it.  Acme's still usable, since most of my text entry is in
window bodies, but it sure is a pain.

Thanks for any help anybody has to offer,

Micah

[9fans] Fwd: FOSS Dev Camp, OS Camp, and more!

[ron minnich]

While it says best and brightest I'm going anyway. :-)

Planning to be there for coreboot and plan 9. I've registered for
those topics or whatever it is you do. Anyway I have tried to put
those names on the board.

Hope some of you can make it.

ron


-- Forwarded message --
From: Gareth J. Greenaway gar...@socallinuxexpo.org
Date: Mon, Jul 6, 2009 at 3:56 PM
Subject: FOSS Dev Camp, OS Camp, and more!
To: gar...@socallinuxexpo.org


Greetings everyone!

I hope that everyone is doing well and doing good things.  I wanted to
just touch base with everyone and let you know about some exciting
things that I'm working on and would like everyone to be apart of.

The basic idea behind FOSS Dev Camp is to gather developers of free 
open source software together to collaborate, share ideas, and generally
improve FLOSS software across the board.  This collaborate could be
between developers of desktop environments, various distributions or
even distribution package maintainers working with upstream developers.
 The event also gives a unique opportunity for users, allowing them to
present bugs and features requests to developers in a in-person setting.

The nature of this event is such that it can and should occur multiple
times a year and multiple locations.  Software development moves very
quickly, especially free  open source software development.  My
ultimate vision is that a FDC instance will occur before each and every
FOSS related event around the world.

To kick things off, the folks at both Open Source World (Don Marti -
Open Source World) and Linux Con (Angela Brown and Amanda McPherson -
Linux Foundation) have generously offered to host FOSS Dev Camp at their
 upcoming shows, Open Source World and Linux Con respectively.  I have
also been talking with Michael Tougeron who is organizing OS Camp being
held at OSCON 2009 about incorporating some FDC ideas into OS Camp.  If
anyone is planning on attending any of these events, I would encourage
you to also attend both FOSS Dev Camp  OS Camp.

The FDC web site[1] is online with information about the upcoming events
as well as the wiki[2] for attendees to add what content they are
interested in seeing and doing at the events.

Please pass this information along to anyone who you think might be
interested!  Any questions, please do not hesitate to ask.

Thanks!
Gareth

1.  http://www.fossdevcamp.org
2.  http://www.fossdevcamp.org/wiki

--
Gareth J. Greenaway g...@socallinuxexpo.org
Voice - 877-831-2569 x130
Southern California Linux Expo
http://www.socallinuxexpo.org

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Robert Raschke]

On Mon, Apr 6, 2009 at 7:00 PM, maht mattmob...@proweb.co.uk wrote:

 SeaForth is dead already

 http://colorforth.com/vTPL.htm

 http://colorforth.com/S40.htm


These docs aren't dated. And I remember a lot of discussion about 1 -
2 years ago about the patent issues surrounding Chuck Moore's work. So
I'm wondering if this info is outdated. The Forth Usernet group seems
to indicate that these chips are fine and dandy.

Robby

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Alexander Clouter]

Robert Raschke rtrli...@googlemail.com wrote:
 On Mon, Apr 6, 2009 at 7:00 PM, maht mattmob...@proweb.co.uk wrote:

 SeaForth is dead already

 http://colorforth.com/vTPL.htm

 http://colorforth.com/S40.htm

 
 These docs aren't dated. And I remember a lot of discussion about 1 -
 2 years ago about the patent issues surrounding Chuck Moore's work. So
 I'm wondering if this info is outdated. The Forth Usernet group seems
 to indicate that these chips are fine and dandy.
 
For whatever it's worth:

a...@berk:~$ wget -S --spider http://colorforth.com/S40.htm
Spider mode enabled. Check if remote file exists.
--2009-04-07 11:47:19--  http://colorforth.com/S40.htm
Resolving colorforth.com... 207.217.125.50
Connecting to colorforth.com|207.217.125.50|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Tue, 07 Apr 2009 10:47:20 GMT
  Server: Apache
  Last-Modified: Mon, 06 Apr 2009 19:52:50 GMT 
  ETag: 2e6982-849-49da5d92
  Accept-Ranges: bytes
  Content-Length: 2121
  Keep-Alive: timeout=10, max=100
  Connection: Keep-Alive
  Content-Type: text/html
Length: 2121 (2.1K) [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.

a...@berk:~$ wget -S --spider http://colorforth.com/vTPL.htm
Spider mode enabled. Check if remote file exists.
--2009-04-07 11:47:21--  http://colorforth.com/vTPL.htm
Resolving colorforth.com... 207.217.125.50
Connecting to colorforth.com|207.217.125.50|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Tue, 07 Apr 2009 10:47:21 GMT
  Server: Apache
  Last-Modified: Mon, 06 Apr 2009 19:48:29 GMT ---
  ETag: 172cd95-688-49da5c8d
  Accept-Ranges: bytes
  Content-Length: 1672
  Keep-Alive: timeout=10, max=100
  Connection: Keep-Alive
  Content-Type: text/html
Length: 1672 (1.6K) [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.


Cheers

-- 
Alexander Clouter
.sigmonster says: You will receive a legacy which will place you above want.

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[maht]

These docs aren't dated. 


they appeared in the last week or so, before that was a page saying TPL 
pulled funding  and sacked Moore

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Robert Raschke]

On Tue, Apr 7, 2009 at 3:24 PM, maht mattmob...@proweb.co.uk wrote:

 These docs aren't dated.

 they appeared in the last week or so, before that was a page saying TPL
 pulled funding  and sacked Moore


Catching up with my online reading and the Forth group is indeed full
of this since the weekend.

It is just weird, all very deja vu. The previous generation of Moore's
designs went through a similar quagmire to nowhere.

Robby

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[maht]

It is just weird, all very deja vu. The previous generation of Moore's
designs went through a similar quagmire to nowhere.

Robby


  

poor man, how stressful is that !

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[maht]

SeaForth is dead already

http://colorforth.com/vTPL.htm

http://colorforth.com/S40.htm


Bruce Ellis wrote:

Please share your experience.

http://groups.google.com/group/casella

brucee

On Thu, Mar 19, 2009 at 8:45 PM, Pavel Klinkovsky
pavel.klinkov...@gmail.com wrote:
  

I am playing with the FORTHdrive (SEAforth-24 chip) for half a year.
We are testing it for a signal processing.

I can confirm it is a wonderful chip.
But it needs a little bit different view to the programming. ;-)

Pavel






  

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Jeff Sickel]

It's just a flesh wound.

On Apr 6, 2009, at 1:00 PM, maht mattmob...@proweb.co.uk wrote:


SeaForth is dead already

http://colorforth.com/vTPL.htm

http://colorforth.com/S40.htm

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Bruce Ellis]

What a shame - tho there is a certain charm in owning a custom
computer that can't be replicated. Hopefully there will be a firesale
of stuff. There can't be many in the wild, mine is serial number 30 -
what's your Jeff?

brucee

On Tue, Apr 7, 2009 at 4:00 AM, maht mattmob...@proweb.co.uk wrote:

 SeaForth is dead already

 http://colorforth.com/vTPL.htm

 http://colorforth.com/S40.htm


 Bruce Ellis wrote:

 Please share your experience.

 http://groups.google.com/group/casella

 brucee

 On Thu, Mar 19, 2009 at 8:45 PM, Pavel Klinkovsky
 pavel.klinkov...@gmail.com wrote:


 I am playing with the FORTHdrive (SEAforth-24 chip) for half a year.
 We are testing it for a signal processing.

 I can confirm it is a wonderful chip.
 But it needs a little bit different view to the programming. ;-)

 Pavel

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New

[Icarus Sparry]

On Thu, 19 Mar 2009 03:43:34 +, Bruce Ellis wrote:

 There is new fun in Casella land. 9fans with Forth experience are
 needed.
 
 Feel free to join the Casella group.
 
 -- Forwarded message -- From: brucee
 bruce.el...@gmail.com
 Date: Thu, Mar 19, 2009 at 2:21 PM
 Subject: New Chip (SEAforth 40C18) - New Challenge To: Casella
 case...@googlegroups.com
 
 There are a few of these floating around in Plan9 / Casella land. Looks
 to me like a great control chip with lotsa goodies. This means that
 Casella doesn't need another computer for control/input/output.
 
 http://www.intellasys.net/index.php?
option=com_contenttask=viewid=60Itemid=75
 
 Mine arrived on Monday. Haven't played with it. There will be 9P on it
 before you read this message by another keen enthusiast.
 
 Sounds sound.
 
 brucee

Before one spends too much time on this, I would suggest a quick visit to 
comp.lang.forth for the thread Chuck Moore news and also 
www.colorforth.com.

Clearly there are problems, and message 
7f7fc71-a87f-4d08-86c0-42d14742d...@r33g2000yqn.googlegroups.com
asserts (without proof) that Intellasys has closed its doors for the last 
month.

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Bruce Ellis]

I don't trust penguins. But it's worth a try. I haven't installed the
linux goo on my pusbox - if tiger wasn't house trained he would do
more than bark at it when it thrashes crazy.

But yes. Read the spec and come up with ideas. Move this to Casella
group if we have enough enthusiasts.

brucee

On Thu, Mar 19, 2009 at 5:21 PM, Jeff Sickel j...@corpus-callosum.com wrote:

 On Mar 18, 2009, at 11:47 PM, Bruce Ellis wrote:

 The chip is a totally insane challenge. But looks like a lot of fun
 and functionality.


 What do you say to a linuxemu as the first pass?  At least that keeps
 us in the realm of using the official Forth environment until we gain
 enough leverage for promoting our own tool chain...

 If that's the case, can usb/usbd; usb/disk should recognize the target well
 enough for current usage (just a FAT disk) and pass that through to
 linuxemu...

 -jas

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Bruce Ellis]

Please share your experience.

http://groups.google.com/group/casella

brucee

On Thu, Mar 19, 2009 at 8:45 PM, Pavel Klinkovsky
pavel.klinkov...@gmail.com wrote:
 I am playing with the FORTHdrive (SEAforth-24 chip) for half a year.
 We are testing it for a signal processing.

 I can confirm it is a wonderful chip.
 But it needs a little bit different view to the programming. ;-)

 Pavel

[9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Bruce Ellis]

There is new fun in Casella land. 9fans with Forth experience are needed.

Feel free to join the Casella group.

-- Forwarded message --
From: brucee bruce.el...@gmail.com
Date: Thu, Mar 19, 2009 at 2:21 PM
Subject: New Chip (SEAforth 40C18) - New Challenge
To: Casella case...@googlegroups.com

There are a few of these floating around in Plan9 / Casella land.
Looks to me like a great control chip with lotsa goodies. This means
that Casella doesn't need another computer for control/input/output.

http://www.intellasys.net/index.php?option=com_contenttask=viewid=60Itemid=75

Mine arrived on Monday. Haven't played with it. There will be 9P on it
before you read this message by another keen enthusiast.

Sounds sound.

brucee

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[David Leimbach]

Wow... 40 cores of forthy-goodness.  Makes me wish I'd spent more time with
forth than I have so far (well almost).
Dave

On Wed, Mar 18, 2009 at 8:37 PM, Bruce Ellis bruce.el...@gmail.com wrote:

 There is new fun in Casella land. 9fans with Forth experience are needed.

 Feel free to join the Casella group.

 -- Forwarded message --
 From: brucee bruce.el...@gmail.com
 Date: Thu, Mar 19, 2009 at 2:21 PM
 Subject: New Chip (SEAforth 40C18) - New Challenge
 To: Casella case...@googlegroups.com

 There are a few of these floating around in Plan9 / Casella land.
 Looks to me like a great control chip with lotsa goodies. This means
 that Casella doesn't need another computer for control/input/output.


 http://www.intellasys.net/index.php?option=com_contenttask=viewid=60Itemid=75

 Mine arrived on Monday. Haven't played with it. There will be 9P on it
 before you read this message by another keen enthusiast.

 Sounds sound.

 brucee

Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge

[Bruce Ellis]

The chip is a totally insane challenge. But looks like a lot of fun
and functionality.

The company is cool too. Ask me if you need a contact. I flippantly
asked for 64 cores for a chess machine. There is apparently an
unannounced board with two chips - 80 cores.

I'm not sure any human should have to program it manually so tool
fiends please collaborate on this - the linux tool kit is
unimpressive. First to glenda it wins a t-shirt.

brucee

On Thu, Mar 19, 2009 at 3:36 PM, David Leimbach leim...@gmail.com wrote:
 Wow... 40 cores of forthy-goodness.  Makes me wish I'd spent more time with
 forth than I have so far (well almost).
 Dave

 On Wed, Mar 18, 2009 at 8:37 PM, Bruce Ellis bruce.el...@gmail.com wrote:

 There is new fun in Casella land. 9fans with Forth experience are needed.

 Feel free to join the Casella group.

 -- Forwarded message --
 From: brucee bruce.el...@gmail.com
 Date: Thu, Mar 19, 2009 at 2:21 PM
 Subject: New Chip (SEAforth 40C18) - New Challenge
 To: Casella case...@googlegroups.com

 There are a few of these floating around in Plan9 / Casella land.
 Looks to me like a great control chip with lotsa goodies. This means
 that Casella doesn't need another computer for control/input/output.


 http://www.intellasys.net/index.php?option=com_contenttask=viewid=60Itemid=75

 Mine arrived on Monday. Haven't played with it. There will be 9P on it
 before you read this message by another keen enthusiast.

 Sounds sound.

 brucee

[9fans] Fwd: Re: devtrace release time

[gdiaz]

---BeginMessage---
On Wed, Dec 17, 2008 at 4:07 PM, ron minnich rminn...@gmail.com wrote:

 The Masses are Revolting!


You said it! They stink on ice!

-History of the World, Part I.

---End Message---

Re: [9fans] Fwd: Drawterm problems

[Randall Bohn]

I've built drawterm successfully from the CVS sources on Ubuntu x86
and Gentoo x86. It also builds on Win32 if you install Mingw and MSYS
(in that order). I use devfs_win32.c from /n/sources/contrib/
cinap_lenrek.

rsbohn