Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ron minnich]

On Sun, May 12, 2024 at 10:55 PM ibrahim via 9fans <9fans@9fans.net> wrote:

>
>
> Please correct me if I'm wrong.
> Permalink
> 
>

In my opinion? you are wrong. And that's as far as I will stay involved in
this discussion.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M918765fe95c422bafdedbbf1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ron minnich]

On Sun, May 12, 2024 at 8:53 PM ibrahim via 9fans <9fans@9fans.net> wrote:

> Not a single developer who uses plan9 for distributed systems, commercial
> products will dare to use a system like 9front as the sources. The reason
> is quite simple :
>
> You ignore copyrights as you please and distributed 9front under an MIT
> license long before Nokia as the owner of it decided to do so. You did that
> at a time when plan9 was placed under GPL
>

I do not agree with what you are saying here. I was involved in the license
discussions starting in 2003, and was involved in both the GPL release and
the more recent MIT license release. The choice of license, both times, was
made by the same person in Bell Labs, even as the Bell Labs corporate
parent changed. In fact, in 2013, we were *required* to use the GPL,
whereas in the later release, the GPL was specifically mentioned as a
license we could *not* use. I won't pretend to understand why.

At no time in all this was there any evidence of incorrect behavior on the
part of 9front. None. Zip. Zero. Zed. They have always been careful to
follow the rules.

Further, when people in 9front wrote new code, they released it under MIT,
and Cinap among others was very kind in letting Harvey use it.

So, Ibrahim,  I can not agree with your statement here.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M3d0b948ec892b2d0de94a895
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] troll paper

[ron minnich]

The  author of the paper not only helped get the conference going this
year, he worked hard this and last year to make sure our youtube channel
worked. He also has done a lot of work to get faculty from U. Bamberg in
Germany on board. The author was a major part of making IWP9 2024 go so
well.

He's also done a lot to get the Unix version of the cpu command as good as
it is today.

I think there is a place for a slightly off the wall talk like this.

Don't like it? Don't watch it. Want talks more to your liking? Look for the
next CFP for IWP9, and please contribute something! I'm looking forward to
it.


On Fri, Apr 12, 2024 at 3:05 AM Anthony Martin  wrote:

> "Do we really have to have our own kernel? What are
> the benefits?" ...
> 
> The IWP9 paper titled "centre, left and right" looks like
> a complete troll. Was it generated by an LLM? I read the
> whole thing and it was a waste of time. Zero stars, would
> not recommend.
> 
> Institutional Academy of the Academic Institute, lol.
> 
> The vetting process needs some work, lads.
> 
> Cheers,
>   Anthony

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Md3d1e5463ea018bbdc1a0bf5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[ron minnich]

openat gives you the effect of 'cd path; open file' without having to cd. I
don't see a lot of benefit to it unless you're opening a lot of files at
that path.

My first reaction, assuming you have a lot of files in that directory, was
something like
bind /dir /n/x and then just open /n/x/file... for a lot of files.

This would work for any system call that takes a path.

The question I had was, can I get the benefit of *at without doing what
linux is doing, namely, for all system calls with a path, make an '...at'
version.
I am guessing so, though I'm not sure it's as efficient.


On Fri, Apr 5, 2024 at 8:19 PM  wrote:

> My two cents on this:
>
> What you _would_ want for this would be the ability to walk from the existing 
> fd, however the limits of 9p walk make this a bit impossible to implement in 
> a great way in my opinion. From walk(5):
>
> The fid must represent a directory unless zero path name elements(for just 
> cloning the fid) are specified. The fid must be valid in the current session 
> and must not have been opened for I/O by an open or create message.
>
> Since not every fid is eligible for being walked from, in order to implement 
> opanat() in any way that would be better than just batching the fd2path and 
> open would be to keep a "last directory" associated, like what we do with the 
> string used to open it. Also worth mentioning that fd2path is not without its 
> own problems, it's possible that the namespace has changed since the file has 
> been opened so the same path may not work the second time. So tagging the 
> last directory Chan would be "more correct", but I am not sure how useful 
> this is.
>
> Answering some other comments made:
>
> As I understand it from the rationale section on the linux man page, the
> call exists to avoid a race condition between checking that a directory
> exists and doing something to a path containing it. An additional motivator
> is providing the effect of additional current working directories notably
> for Linux threads (which presumably don't have their own. I think
> 'threads'  (processes that share memory) on Plan 9 do???).
>
>
> Each process has it's own current working directory:
>
> % pwd
> /home/moody
> % @{cd /}
> % pwd
> % /home/moody
>
> This is all based on the assumption that holding a file/directory open keeps 
> it alive and in existence... which on Plan 9, I think it doesn't, does it? As 
> I understand it, remove can remove a file or directory that is open, which is 
> not like UNIX/Linux...
>
>
> Depends on the file server implementation, I find that for more synthetic
> files they are indeed kept alive as long there is someone with a reference
> to the fid. This is identifiable if all the cleanup happens on
> clunks(destroyfid in lib9p), which only happen when a fid's refcount hits
> zero. For non-synthetic or more "disk" file servers the behavior can
> differ. Cwfs does not keep the data around, readers that attempt to read a
> deleted file, even if they already have a reference open to it will result
> in a phase error. However 9front's ramfs keeps the data around.
>
> My test for this was as follows:
> win1% echo 'something' >/tmp/test
> win2%  win1% rm /tmp/test # observe the error(if any) on win2
>
> So you really can't assume either case.
>
>
> Thanks,
> moody
>
> P.S.
> I apologize for the formatting, it seems my emails are not making it to
> the list when I attempt to send them from my mail server so I had to copy
> this response in to the web form.  I would like to figure out why if
> possible.
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M3c953ec4ad1db560805d02b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] openat()

[ron minnich]

not so much what I want, I'm curious about ideas people have about
implementing it that I would not think of.

On Fri, Apr 5, 2024 at 1:38 PM Gorka Guardiola  wrote:

> Hmm sorry. Now I see what you want. Not to rewalk. You can use the chan of
> the dirfd and walk just the remainder cloning it and creating a new one.
> That way the openat provides the guarantees you want.
>
> On Fri, Apr 5, 2024, 22:15 Gorka Guardiola  wrote:
>
>> I mean, if you want a new syscall jus copy or call the implementation of
>> these.
>>
>>
>> On Fri, Apr 5, 2024, 22:12 Gorka Guardiola  wrote:
>>
>>> ¿Isn't that fd2path, strcat and open?
>>> Or am I misunderstanding something?
>>>
>>> On Fri, Apr 5, 2024, 21:51 ron minnich  wrote:
>>>
>>>> One of the folks I worked with, when we pulled a big chunk of plan 9
>>>> into akaros, commented that he had implemented openat on akaros.
>>>>
>>>> I don't want this to turn into a debate on the merits of openat; I am
>>>> more curious: if you went to implement openat on Plan 9, how would you go
>>>> about it? I have a few ideas but I'm more interested in your ideas.
>>>>
>>>> Thanks
>>>>
>>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M43026122c2960e83ab07e80b>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0445ed55bee993d4cfbd3450
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] openat()

[ron minnich]

One of the folks I worked with, when we pulled a big chunk of plan 9 into
akaros, commented that he had implemented openat on akaros.

I don't want this to turn into a debate on the merits of openat; I am more
curious: if you went to implement openat on Plan 9, how would you go about
it? I have a few ideas but I'm more interested in your ideas.

Thanks

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-Mf6adaa9f7c07518efcb7a293
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] A few questions about 9p

[ron minnich]

Tflush is harder than it looks, given that it is part of a giant race
condition. Will you get the R for the message you are flushing right after
you send Tflush? What happens at the server? It's fun.

Perhaps one of the biggest uses of 9p, globally, was google's gvisor, which
runs an unimaginably large (to me anyway :-) amount of compute in Google
Cloud. gvisor: https://gvisor.dev/docs/,  Comparison here:
https://www.scitepress.org/Papers/2021/104405/104405.pdf

I suspect more bytes moved through 9p on gvisor in a day than moved on all
other platforms since 2000. All I can say is, it's a lot.

gvisor used to use 9p (my fault :-) and, although we started with Andrey
and Lucho's go9p, at some point it was replaced by Chris Koch's
implementation. It's quite good.

You can see how Chris handled Tflush here:
https://github.com/hugelgupf/p9/blob/main/p9/handlers.go#L104

I'd argue that this may be the most real-world-tested Tflush handler you'll
see. I have seen Tflush handlers that just return, having done nothing, and
it's possible that in many cases, that's good enough. But Chris's code is
VERY heavily tested with real workloads.

I also know, as I saw it many times, that the Plan 9 kernel Tflush could at
times get extremely confused. When we ported it to Akaros, we even saw
cases where Tflush would run out of control and exhaust the XID space,
sending flush after flush as fast as it could create them.

Finally, due to some issues with 9p that could not be fixed, the gvisor
engineers created a new protocol, LISA,
https://github.com/google/gvisor/tree/master/pkg/lisafs, worth reading.

HTH

ron
p.s. FYI, when we first started gvisor, we had it in mind that it could
support Plan 9 binaries, and planned accordingly, but that was never tested.

On Mon, Oct 31, 2022 at 4:15 PM ibrahim via 9fans <9fans@9fans.net> wrote:

> I have read the manuals and also searched for this question here without
> finding an answer (perhaps I missed it) :
>
> 1) question about flush :
>
> Lets say there was a pending message with tag=1234 and the client of my
> server sent a flush message with a tag=1450. During the travel of the flush
> the server sent a response to the message tagged 1234 cause it finished.
>
> The manual states that the client has to forget about the flush message as
> if never sent. Does that mean that message tagged with 1450 which is now
> ignored by the server won't be replied (no error reply and no success reply
> cause if the server would reply with rflush the client would take this as
> if the flush succeeded due to the manual page).
>
> Can a client reuse a tag from an unanswered flush message immediatly (in
> the example tag 1450)
>
> 2) tversion
>
> A client sends tversion while in the middle of a running session.  Is it
> right to abort/ignore/close/flush all possibly pending messages from the
> prior session ?
>
> The next question is regarding msize[4] in tversion. How should a server
> respond when msize suggested from the client is to small like
> msize-IOHDRSIZE< one min_stat_size ?
>
>
> Thanks in advance ;)
>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M2d06525b5c16d6549e9beed9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] How can I compile c code written for plan9 in ANIS C compiler

[ron minnich]

ah found one. This was for one instance of where mach was used. It
basically says if mach is used in a function, put a declaration of m at the
start of the function.

@mr exists@
typedef Mach; // only needed once per semantic patch
idexpression Mach *m;
function f;
position p;
identifier d;
@@
f@p(...){
<+...
m->d
...+>
}

@@
function mr.f;
position mr.p;
@@

f@p(...) {
++ Mach *m = machp();
...
}

spatch is pretty amazing.


On Tue, Oct 11, 2022 at 12:32 PM ron minnich  wrote:

> we used the coccinnelle tool (spatch) to convert about 1.4M lines of Plan
> 9 code to C11 for harvey. It was not perfect, but it did get a lot right.
>
> This even got pretty complex: in amd64 Plan 9, r14 and r15 are dedicated
> to up and mach.
> This is not portable, so we wanted to make it explicit. So in any function
> that used up, for example, we had an spatch to add Proc *up = externup();
> declaration to those functions. spatch is powerful. references to m->
> where replaced with machp().
>
> We also removed the embedded lock structs, with spatches like this:
> @  @
> expression E;
> @@
> -incref(E)
> +incref(>ref)
>
> This actually *maybe* found a bug, in which there was an ambiguity when a
> struct contained two embedded lock (e.g. Lock and Qlock) types and the
> compiler had to pick the right one to apply the lock/unlock to. It looked
> to us like Plan 9 might have picked the wrong one, but we were never sure.
>
> anyway, this is one path to converting plan 9 code. Or you can just go to
> https://github.com/Harvey-OS/harvey/tree/GPL-C11, where it already is
> done.
>
>
>
> On Mon, Oct 10, 2022 at 1:52 AM Steve Simon  wrote:
>
>> re: p9p for windows
>>
>> Sean Quinlan did a p9p-line port for windows called 9pm, It was seen (it
>> seems) as a port of sam with some simple command line tools
>> rather than a complete plan9 toolkit. its available here:
>> https://netlib.org/research/ as sam.exe
>>
>> There was an attempt at a p9p for windows by Russ Cox, it was a very
>> elegant solution having a p9p dll but suffererd from fragility
>> (a bug in the dll took all your p9p applications down), and split brain
>> problems (p9p applications understood plan9 style binds and mounts,
>> native windows applications did not. As a result development stalled.
>>
>> Its possible that this could be re-awakened using a windows IFS
>> (Installable File System) driver to allow windows applications to see a
>> plan9 style file structure (the 9: drive :-) and perhaps starting p9p as
>> a windows service. This sounds neat but would be a considerable
>> amount of work.
>>
>> This is available here:
>> https://web.archive.org/web/20070221202050/http://swtch.com/usr/local/plan9/9pm/README
>>
>> There was a later implementation by Michael Teichgräber which is a
>> complete port of plan9ports to windows, in a similar style to the
>> posix implementations, this works very well, though, like outher p9p
>> implementations it has a bit of a split brain feel to it.
>>
>> This is here: https://github.com/knieriem/pf9
>>
>> I took a rather different approach as I used plan9 as my desktop for
>> years but needed windows for some work related applications.
>>
>> I did a minimal port of the plan9 command line applications to wondows
>> and wrote a cpu(1) line client and server which allowed me to
>> warp a plan9 terminal to MS windows, in the same directory but running
>> rc(1); I also used remote desktop to get a modern web browser.
>> This was very comfortable environment for what i needed.
>>
>> This is here http://www.quintile.net/magic/webls?dir=/quintile.net/pkg
>> 9win.tbz
>>
>> These days I work on a Mac so plan9ports does all I need, and sadly I
>> hardly ever touch real plan9 any more :-(
>>
>> -Steve
>>
>>
>>
>> > I think there are two ports of plan 9 utilities to windows, one of them
>> includes old (2nd ed?), and other one is a more modern port.
>> >
>> > https://code.google.com/archive/p/plan9port-windows
>> 
>> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T422378fc25787720-Mef61e79840761b466a422d9a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] How can I compile c code written for plan9 in ANIS C compiler

[ron minnich]

we used the coccinnelle tool (spatch) to convert about 1.4M lines of Plan 9
code to C11 for harvey. It was not perfect, but it did get a lot right.

This even got pretty complex: in amd64 Plan 9, r14 and r15 are dedicated to
up and mach.
This is not portable, so we wanted to make it explicit. So in any function
that used up, for example, we had an spatch to add Proc *up = externup();
declaration to those functions. spatch is powerful. references to m->
where replaced with machp().

We also removed the embedded lock structs, with spatches like this:
@  @
expression E;
@@
-incref(E)
+incref(>ref)

This actually *maybe* found a bug, in which there was an ambiguity when a
struct contained two embedded lock (e.g. Lock and Qlock) types and the
compiler had to pick the right one to apply the lock/unlock to. It looked
to us like Plan 9 might have picked the wrong one, but we were never sure.

anyway, this is one path to converting plan 9 code. Or you can just go to
https://github.com/Harvey-OS/harvey/tree/GPL-C11, where it already is done.



On Mon, Oct 10, 2022 at 1:52 AM Steve Simon  wrote:

> re: p9p for windows
>
> Sean Quinlan did a p9p-line port for windows called 9pm, It was seen (it
> seems) as a port of sam with some simple command line tools
> rather than a complete plan9 toolkit. its available here:
> https://netlib.org/research/ as sam.exe
>
> There was an attempt at a p9p for windows by Russ Cox, it was a very
> elegant solution having a p9p dll but suffererd from fragility
> (a bug in the dll took all your p9p applications down), and split brain
> problems (p9p applications understood plan9 style binds and mounts,
> native windows applications did not. As a result development stalled.
>
> Its possible that this could be re-awakened using a windows IFS
> (Installable File System) driver to allow windows applications to see a
> plan9 style file structure (the 9: drive :-) and perhaps starting p9p as a
> windows service. This sounds neat but would be a considerable
> amount of work.
>
> This is available here:
> https://web.archive.org/web/20070221202050/http://swtch.com/usr/local/plan9/9pm/README
>
> There was a later implementation by Michael Teichgräber which is a
> complete port of plan9ports to windows, in a similar style to the
> posix implementations, this works very well, though, like outher p9p
> implementations it has a bit of a split brain feel to it.
>
> This is here: https://github.com/knieriem/pf9
>
> I took a rather different approach as I used plan9 as my desktop for years
> but needed windows for some work related applications.
>
> I did a minimal port of the plan9 command line applications to wondows and
> wrote a cpu(1) line client and server which allowed me to
> warp a plan9 terminal to MS windows, in the same directory but running
> rc(1); I also used remote desktop to get a modern web browser.
> This was very comfortable environment for what i needed.
>
> This is here http://www.quintile.net/magic/webls?dir=/quintile.net/pkg
>   9win.tbz
>
> These days I work on a Mac so plan9ports does all I need, and sadly I
> hardly ever touch real plan9 any more :-(
>
> -Steve
>
>
>
> > I think there are two ports of plan 9 utilities to windows, one of them
> includes old (2nd ed?), and other one is a more modern port.
> >
> > https://code.google.com/archive/p/plan9port-windows
> 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T422378fc25787720-M2f414023b6a6afb2ebeda37e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] possible factotum device?

[ron minnich]

https://github.com/tillitis/tillitis-key1

we got handed these at OSFC. The app it comes with:
https://github.com/tillitis/tillitis-key1-apps/blob/main/signerapp/main.c

which they use to implement an ssh agent. The device looks like a serial.
It's a lattice FPGA and the bitstream (which you can change) is a picorv32.

But could we write a different app, which would implement factotum? Be
aware you are memory constrained.

Anyway, thought this might be of interest.

ron

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te1b96bbd77d07612-M704ab25c7cb97d00c37053f1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9p server to multiply 9p messages?

[ron minnich]

On Tue, May 31, 2022 at 11:29 AM hiro <23h...@gmail.com> wrote:
>
> so virtiofs is not using 9p any more?
>
> and with 10 million parallel requests, why shouldn't 9p be able to
> deliver 10GB/s ?!

Everyone always says this. I used to say it too.

9p requires a certain degree of ordering -- as Andrey once pointed
out, it's not productive to close a file, then write it. So there is a
tricky ordering requirement you need to get right, due to Plan 9 being
stateful.

The way we use 9p in Plan 9, as a general purpose protocol for
everything, like devices, requires that each Tread or Twrite occur in
order, but also requires that each T be retired before the next T is
issued. devmnt does  this. If you don't do this, hardware can get
confused (e.g. ordering of Twrite followed by Tread followed by Twrite
needs to be maintained. E.g. you don't want to issue the Tread before
you know the Twrite happened.  E.g. pre-posting 100 Treads to
/dev/mouse is not a good idea if you suddenly want to do a Twrite in
the middle of it).

This is why 9p starts to perform poorly in networks with high
bandwidth*delay products -- if you watch the net traffic, you see each
T op  on fid blocked by the previous Reply (by devmnt).

I never figured out a way to fix this without fixing devmnt -- by
removing its general nature.

But, more to the point, whether or not 9p should be able to do all
these parallel requests and get high performance, nobody has yet done
it. The only numbers ever reported for making high bandhwidth*delay
networks better were in Floren's thesis, when he added Tstream.

After 20+ years of this discussion, I start to wondering whether it's
harder than it looks.

ron

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M71f56ad40eb62ce87f0917e3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9p server to multiply 9p messages?

[ron minnich]

On Mon, May 30, 2022 at 12:21 AM Bakul Shah  wrote:
> 9p itself is low performance but that is a separate issue.

Bakul, what are the units? It might be helpful to quantify this
statement. Are you possibly conflating Plan 9 file systems being slow
and 9p being slow?

As Rob pointed out in 2013, "If go install is slow on Plan 9, it's
because Plan 9's file system is
slow (which it is and always has been)", so slowness in Plan 9 file
systems is to be expected.

9p itself does have its limits, which is why Bell Labs Antwerp started
an effort in 2011 to replace it, but the new work never went very far.

I also know of a number of efforts in the virtualization world where
9p was discarded for performance reasons. It's hard to argue with the
100x performance improvement that comes with virtiofs, for example.

Gvisor is replacing 9p: https://github.com/google/gvisor/milestone/6.
Although, in the latter case, I would argue the problem is more with
Linux limitations than 9p limitations -- linux can't seem to walk more
than one pathname component at a time, for example, since it has the
old school namei loop.

But I'm wondering if you have a measurement with numbers.

For rough order of magnitude, HPC file systems can deliver 10 Gbytes/
second for file reads nowadays, but getting there took 20 years of
work. When we ran Plan 9 on Blue Gene, with the 6 Gbyte/second
toroidal mesh connect for each node, we never came remotely close to
that figure.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M410e08e9297838b9bb37bb5a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9p server to multiply 9p messages?

[ron minnich]

not for 9p, but in 1993, when Gene Kim interned with me at the
Supercomputing Research Center, we did this:
https://www.semanticscholar.org/paper/Bigfoot-NFS-%3A-A-Parallel-File-Striping-NFS-Server-(-Kim/19cb61337bab7b4de856fcbf29b55965647be091,
similar in spirit to your idea.

The core idea was that we distributed the files over the set of
servers, and replicated directory trees to avoid the usual troubles:
we did not want to implement a metadata server. So each NFS request
was fanned out to 32 machines, vector rpc style, and because the
networks of that time were so slow, it was not that much slower than
you'd expect.

It worked, it gave us what was at the time a really big NFS server,
the paper got rejected twice at usenix, the original full paper is
long lost, the code? probably lost too.

It was available from super.org in 1993, but ... that's not on the
wayback machine.

On Sat, May 28, 2022 at 11:45 AM Skip Tavakkolian
 wrote:
>
> Interesting idea!
>
> This assumes the downstream servers have identical namespace hierarchy; right?
>
> State management could be messy or impossible unless some sort of
> transaction structure is imposed on the {walk, [open/create,
> read/write]|[stat/wstat], clunk} sequences, where the server that
> replies to walk first, gets that transaction.
>
> On Sat, May 28, 2022 at 9:04 AM  wrote:
> >
> > Has anybody considered (or maybe even implemented) a 9p server to
> > multiply incoming 9p messages to 2 or more 9p servers?
> > Maybe with 2 different strategies for responding to the original request?
> > 1. respond as soon as at least 1 response from one of the 9p servers
> > is received,
> > 2. respond only after all responses had been received.
> > thanks!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M7413556639c5150cb4c6e116
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] licence question

[ron minnich]

This one statement: "Berkeley stopped their distribution of BSD
systems right after they were forced to remove the toolchain." is
completely wrong. I just asked the people who were there, on TUHS, and
they confirmed my memory: DARPA funding for BSD support ended in 1995,
and that was probably the biggest factor in ending the UCB activities
in BSD.

I think it's important to verify claims with primary sources. Many of
those people are still alive.

On Wed, Feb 2, 2022 at 8:27 AM  wrote:
>
> Quoth Wes Kussmaul :
> >
> > Hiro, you have absolutely hit the nail on the head.
> >
> > So, how do you add rationality and reliability to the
> > dpkg-app/play-store idea?
> >
> > Answer: emulate the ways this has been done for centuries in the
> > physical world.
> 
> I'd like to think we've progressed past the point
> of physical violence against vendors, but perhaps
> you've got a point.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M2872803886afea8401ef9223
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] licence question

[ron minnich]

On Sat, Jan 29, 2022 at 6:19 PM ibrahim via 9fans <9fans@9fans.net> wrote:

> As far as I recall OpenBSD (Theo dR) was interested in BSD licensed compilers 
> at that time and that didn't happen.

That happened about 10 years earlier. The effort I am talking about
with jmk was 2013; the dustup with Theo was circa 2003:

See this discussion: https://groups.google.com/g/comp.os.plan9/c/0j5Xa_Bu_fs

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M16bc42b19c0abc62d8fcb603
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] licence question

[ron minnich]

"Why do you think p9f asked for a relicensing of plan9 while it was
already gpl licensed a few years ago ? Both are redistributable but
the MIT version is also usable for closed source commercial projects
while the GPL version is not. Does this matter ? Yes of course it
matters for people or companies. Its sometimes amusing to see
developers taking legal issues lightly."

A little historical note here, speaking as the person who got both
those releases done.

The late jmk and I labored over a period of many months in 2013 to get
Plan 9 out under a BSD license. In the end, the copyright holder at
that time required that we distribute it, via UC Berkeley, under the
GPL. No choice. It was that or nothing. Those negotiations involved
many people, and it almost did not happen at all.

The p9f process was not a relicensing, it was a transfer of ownership
of the code.  One condition of the transfer, was that the GPL was
explicitly named as a license we should not use. All agreed that the
MIT license was a good one.

So it's not really correct to say anyone asked for a relicensing to
this or that specific license. The choice of license was always under
the control of whoever owned Bell Labs, and the code base, at that
time.

ron

On Sat, Jan 29, 2022 at 4:10 PM hiro <23h...@gmail.com> wrote:
>
> even if it won't be used, it can still serve as example. there's sense
> in that for some people.
>
> there aren't many real-world products/solutions based on plan9, so
> people who are interested to learn from others don't have so much
> choice.
> every addition can be potentially useful for somebody in the community.
> no harm done generally, as long as you give no false hopes...
>
> as i said, users tend to find unexpected, unintended ways of making
> use of things.
>
> On 1/30/22, ibrahim via 9fans <9fans@9fans.net> wrote:
> > What I meant was that there is no sense in sharing the code for a special
> > purpose kiosk app.
> >
> > For people who are interested search for
> >
> > gpl infringement tv boxes
> >
> > You will find many examples of companies who took gpl too lightly and got
> > sued by FSF. The more users a product has which used GPL without making the
> > code available the higher the risk gets that they get sued. FSF isn't as
> > weak as many think they are.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M6750785ec749b2e318804a0f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

[ron minnich]

The LPL is dead. It died when all the Plan 9 IP was transferred to the
foundation.

Nokia is out of the picture.

So let's realign this discussion a bit. The Plan 9 source formerly
owned by Nokia is owned by the foundation. That source is released
under the MIT license.

As for the inclusion of source not owned by the foundation, if that
source has a license (e.g. MIT) which allows other projects, including
the foundation's Plan 9 project,  to include it in a distribution or
repo, then that is ok. As per common practice, and up to the
discretion of the author, the files typically include a license header
and copyright notice.

I'm not understanding the issue here. This is all pretty settled
stuff: source code under one copyright and an MIT license which
includes other source code covered by a different copyright and an MIT
license.

ron

On Wed, Mar 31, 2021 at 4:10 AM Anonymous AWK fan via 9fans
<9fans@9fans.net> wrote:
> > > As I interpret it, we'd need Nokia to re-release Plan 9 under a Lucent
> > > Public License version 1.03 which would be the MIT license for
> > > contributions to be relicensed (if I'm interpreting it correctly the
> > > GPL release of Plan 9 couldn't apply to contributions either.)
> >
> > I Am Not A Lawyer, and I don't doubt that the P9 foundation can
> > get good lawyers.  But, once _ownership_ of the copyright was transferred
> > to the P9F, they can do what they want with it, including publishing
> > under the MIT license.  There should not be a need to involve Nokia
> > any further.
> 
> The problem is Nokia doesn't own the contributions, so they can't transfer
> them to the P9F, but the LPL says they have the right to update the LPL,
> or was this right transferred to the P9F too?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M1271fb6cec1bac34d939ace4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Can compile Plan9 C compiler for windows10?

[ron minnich]

Nxm built kencen toolchain on Linux.

https://github.com/rminnich/NxM

We could build all of plan9 on Linux. You might be able to start there and
produce .Exe's.

Not tested for quite some time now. Derived from nix.



On Sun, Mar 28, 2021, 6:17 AM  wrote:

> uh inferno's 8c compiles .exe file?
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M358adda89b2451539ae22e17
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] rbind

[ron minnich]

I've been looking for source to rbind, and Aki no longer has it. If anyone
still has it can you ping me off list and let me know?

thanks

ron

[9fans] Plan 9 BOF at Usenix with a slight difference

[ron minnich]

I'm giving a talk at Usenix in Santa Clara in 2 weeks on u-root, and I'll
be setting up a Plan 9 BOF (assuming there is room) with a difference:
we're going to demo the GPL'ed Plan 9 code base booting on a small amd64
cluster (assuming it's working by then!). The system is built with gcc,
although some of us are advocating moving to clang. A full build of all
libraries, binaries, and kernels takes about 2-3 minutes. It's now possible
to debug the kernel, including setting breakpoints and examining
structures, with gdb when you are running under qemu. If you're at Usenix
drop on by and see what you think.

If you want to know more you can contact me off-list.

Thanks

Ron

[9fans] code.google.com/p/nix-os

[ron minnich]

is now at github.com/rminnich/nix-os

Just for historical interest.

ron

Re: [9fans] hgfs

[ron minnich]

has anyone looked at camlistore as a starting point? Written in Go,
which means it works on Plan 9.

ron

Re: [9fans] hgfs

[ron minnich]

I'm beginning to remember why I redirected this list to /dev/null. I
think I'm going to resume.

Enjoy your ever-shrinking place in the world, folks; it's clear that
you enjoy it. It's also clear that nobody else cares any more.

ron

Re: [9fans] syscall 53

[ron minnich]

I have a different perspective. There are millions of chromebooks out
there updating all the time, from the firmware to the kernel to the
root file system to everything. It all works.

If you are telling me that the upgrade technology of Plan 9 can not
handle an automatic upgrade, fine; we have the proof.

If you are telling me Plan 9 should not or never will be able to
handle an automatic upgrade, and is going to require a heads up email
for each kernel change, I have a hard time taking that seriously.

This is not a human communication problem. It's a technology problem,
trivially solved for many years now by many systems.

ron

Re: [9fans] syscall 53

[ron minnich]

Ah well, back to 'm' for this thread, and I now accept that this
community is unwilling to solve this simple problem, as so many others
have.  Bummer.

ron

Re: [9fans] syscall 53

[ron minnich]

I've been watching the discussion but was hesitant to jump in. But
somebody asked me to say a thing or two.

We put the nsec() system call into NxM because, any way you cut it, it
provides better accuracy than the open/read/close path, particularly
when there's lots of stuff running, and the apps we care about need
that improved precision. Yes, this is measured. Just saying 'use tsc'
ignores the lack of portability of that mechanism, as well as the
other issues that have been found over the years with time registers
(core tsc synchronization, effects from power management, interaction
with virtualization, and so on). You don't have to look very long to
see that the work the kernel does for the three-system-call version is
far higher than the simple nsec system call -- yep, looks simple in
the library, and, nope, lots more going on in the kernel, more than 3x
as much. There are a few uses that break the 'it should look like a
file' model and I think this is one of them. Getting accurate,
jitter-free time is essential to making good decisions in many cases.

Nevertheless, I had not intended to push on the system call idea very
hard. As long as people were happy, there did not seem to be much
reason. So I stopped worrying about it over a year ago.

A recent discussion on golang-dev provided the final impetus: it was
recommended that if the nsec call were available on Plan 9, the Go
ports should use it. That was enough for me to put in a request for
one more review of the patch (which patch I did not put in, BTW), and
the good folks at BL felt the idea was OK, so in it went.

So it's in. It's an architecture neutral kernel interface get time in
nanoseconds in a which-core-are-you-on independent manner. It can be
made faster: on NxM the plan was to put a very fast path in the system
call assembly and return the nsec in %rax, and do the memmove in user
mode, so as to avoid any validaddr or address alignment overhead. A
true system call allows optimizations that the open/read/close
interface can not.

I'm sorry to hear that it caused trouble. That said, the problems were
due (IMHO) to a limitation in the update mechanism, not to the
inclusion of a new system call. The limitation is rarely encountered
because the situation is rarely encountered. The right way to update
the system when the kernel adds a new system call is pretty clear:
kernel first. Updating binaries before kernels is clearly wrong and
shows something could be done better. I think it's a good time to
review how the update path works and fix it.

So, it's good for Go and anything else which wants reasonable accuracy
on time without having to muck with architecture-dependent registers.
It's trivial to add. We found it helped a lot on NxM. The quality of
the results you get are hard if not impossible to equal with the
current interface. The old path still works. I think we're all going
to be ok.

ron

Re: [9fans] syscall 53

[ron minnich]

On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth
charles.fors...@gmail.com wrote:

 Jitter says something about (in)consistency of time periods or intervals. It
 will be a function of scheduling decisions, not the overhead of a single
 call.
 In Nix, on an AP core, sure, because there isn't any scheduling. When there
 is scheduling of any sort,
 it's the scheduling that results in the jitter, not either of these two time
 implementations, surely.
 You could clearly say faster, but I'm not convinced about jitter-free.
 For instance, you can still be pre-empted for variable
 time between the invocation of nsec, its arrival in the kernel, and on
 return from the kernel before and after return from nsec.
 Preventing that is a scheduling matter, with both implementations.

I did not want to make this too long, but, sure, everything you say is
quite correct. It's why we considered taking the implementation even
further on NxM, but we stopped that project before we got to that
point. There are way more opportunities for the introduction of jitter
with the old system as opposed to the new, because there are far more
places that you might get to where scheduling can occur. In other
words, again, you're right as rain in what you're saying.

What can I say? We measured it on NxM, were disappointed with the
results from the old way, and happy(er) with the new way.

And, again, I was not inclined to act on any of this until the
discussion on the golang-dev list, which boiled down to:
if you can do it with a single system call, you should with a
response of we put in a patch, was not accepted yet.. I just renewed
the request to reexamine the patch.

ron

Re: [9fans] waitfree

[ron minnich]

On Mon, May 19, 2014 at 3:05 PM, erik quanstrom quans...@quanstro.net wrote:

 the documentation appears not to cover this completely.


Hmm. You put documentation and completely in the same sentence. Agents
are converging on your house. Run!

There's always an undocumented progress engine somewhere in the works.

ron

[9fans] linking a program to run at a high address

[ron minnich]

I've done this, and I've forgotten how. I need to tell 6l to link a
program to run at

0x7f00

I've tried various combos of -T, -R, and -D and am failing to get the
right result ... any hints to revive my poor memory would be welcome.

ron

Re: [9fans] linking a program to run at a high address

[ron minnich]

you need to give more credit to the compiler :-)

the address I'm using is in the low half of the address space.

But I'll wait for Charles to weigh in and tell us what's what.

ron

[9fans] what arch

[ron minnich]

somebody referred me to the discussion.

Sometimes we found people wanted to build on their existing OS (Linux,
OSX, whatever) in a cross-build way, and, further, didn't want to do
that in a VM, because they had tools they liked.

github.com/rminnich/NxM is the last snapshot of the Sandia/BL fork,
and it has scripts and instructions to crossbuild it all on Linux.
It's not elegant but it works. At the time, we used Gerrit and Jenkins
for our control and validation. For each commit, gerrit would kick off
a jenkins run, which would do the full build from scratch, boot in
qemu, and run a set of regression tests. Gerrit would -1 the patch if
the jenkins pass did not work.

Full build, starting from nothing, of tools, libs, bin, kernels, was
about two minutes on Linux. If you added gs into the mix, it was more
like 4 minutes IIRC. Ran fine on amd64.

Also, from the Akaros side, we've extended the Plan 9 MSI code to
support MSI-X and tested it on real hardware; works fine. This allowed
us to stop worrying about ACPI; you don't need it if you do MSI-X.
Relief! And MSI-X is in some ways easier than MSI.

There's also a first cut at a vm device. I realize there's no love
lost for Akaros in this group, but you're welcome to the code. I've
also started porting oprofile into Akaros in a way that would allow
its use in Plan 9. We need to substantially improve the TCP stack
(which comes from Plan 9).

One suggestion I'd like to float here: the LPL is a problem for both
BSD and GPL worlds (see Theo's notes from 2003 on that issue). It
might be useful for new from-scratch software to be released under
3-clause BSD; or under the Inferno license for that matter. In other
words, if you don't have to use the LPL, use 3-clause BSD instead. One
person has already very kindly allowed us to use their drivers in
Akaros with the LPL replaced with 3-clause BSD.

Anyway, congrats on the GSOC and good luck.

ron

Re: [9fans] what arch

[ron minnich]

On Fri, May 9, 2014 at 1:51 PM, Bakul Shah ba...@bitblocks.com wrote:

 Full plan9 *native* build of the kernel, libs and bin on a
 /RapsberryPi/ is about 4 minutes

GOOD. Why not have a web page? The great plan 9 build shootout. Nobody
would be happier than me if Linux always lost.

ron

Re: [9fans] what arch

[ron minnich]

On Fri, May 9, 2014 at 2:46 PM, Charles Forsyth
charles.fors...@gmail.com wrote:

 On 9 May 2014 21:37, ron minnich rminn...@gmail.com wrote:

 under the Inferno license for that matter


 that's usually MIT

Yeah. Either 3 clause BSD or MIT work. Many others don't. So whichever
one of those floats your boat, those of you have authored new software
might consider relicensing under one of them. Again, just a
suggestion.

ron

[9fans] misinformation in the discussion about the GPL release of Plan 9

[ron minnich]

Just thought I'd toss out a correction, because lots of statements are
being made by people who don't know much about the whys and wherefores
of the recent UCB announcement of a GPL'ed release or how we got here.

The license, and the manner in which the distro is being managed, were
specified by Alcatel-Lucent. UCB graciously agreed to take on the role
they have taken on. This was not a small effort on either side.

Folks at Bell Labs (and me) put in a lot of time over the last 2
quarters to try to find a way to fix a problem, namely, that the LPL
has been off-putting for many potential users, only in part because it
is incompatible with the GPL. We sought a more standard license. It
was not easy.

The LPL could not be made compatible with the GPL in finite time. Yes,
the web pages all mention one clause; I found out the hard way that
was only *one* issue. There are many more.

I would certainly hope that people can use this distro as a basis for
further work.

I think Alcatel-Lucent, UC Berkeley, and Jim McKie are owed much
thanks for their willingness to revisit this issue, and their
persistence in achieving the outcome.

ron

Re: [9fans] gcc not an option for Plan9

[ron minnich]

I'll happily pay the price of bigger binaries for things such as the %v format.

I don't write hello, world that often, or even care about its size when I do.

One demo we used to do for Unix was show we could write an executable
program that was 2 bytes. It was cute. Did it matter, in the end? Not
really. But we used to call 4k programs bloated.

I have  a hard time worrying about 1M binaries on $200 machines with
12 GB/s memory bandwidth and 4G memory.
It's 2013.

ron

Re: [9fans] Scheme

[ron minnich]

bitbucket.org
search for bakul
https://bitbucket.org/bakul/s9fes

Re: [9fans] acid on linux; easiest-to-set-up virtual machine

[ron minnich]

vbox is a useful bit paperweight. Maybe you have too many bits, and
they might float away. Use vbox to hold them down. If you ever need
the bits vbox is holding down, then you can set those bits free by
removing vbox.

I think it has some other alleged use but I have not had much luck with that.

ron

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] I need some EDID

[ron minnich]

On Tue, Oct 23, 2012 at 8:54 AM, John Floren j...@jfloren.net wrote:
 Everybody, PLEASE, restrain yourselves and send the EDID output to Ron
 directly, not to 9fans.

Yes, good point. Also please send with subject
EDID

and you can send the text inline, not as an attachment, thanks

ron

Re: [9fans] 9grid?

[ron minnich]

On Tue, Oct 23, 2012 at 1:22 PM, Don A. Bailey
d...@capitolhillconsultants.com wrote:

 I'm interested in the code for managing grid nodes and delegating tasks.

Real code? talk to charles.

Or now that Go works, you could look at some of those packages.

ron

Re: [9fans] Xen4 status

[ron minnich]

if you're running xen you're almost certainly using a linux in dom0.
Given that, kvm is usually a better bet.

ron

[9fans] I need some EDID

[ron minnich]

so, if any of you have X11 running, and could do this:
xrandr --verbose

and send the output to me, subject
EDID

I would NOT be forever in your debt, and I will NOT put your name in
lights, but I would appreciate it :-)

ron

Re: [9fans] Xen4 status

[ron minnich]

Yes, starting about 5 years ago people began to move to KVM for many
reasons. And some very smart people have made it very very fast.

If you run 9front, you can take advantage of its virtio drivers, and
use the kvm tool instead of qemu. That's a big win right there. But
qemu+kvm is quite good in any event.

ron

Re: [9fans] syscall tracing: errstr

[ron minnich]

On Tue, Aug 28, 2012 at 9:18 AM, erik quanstrom quans...@quanstro.net wrote:

 i'd removed the _X syscalls about 3 months ago from both nix
 and plan 9 since they really seem useless at this point (especially
 in nix) and therefore i removed it from the tracing.

definitely makes sense if the calls are gone not to print them ...

ron

Re: [9fans] syscall tracing: errstr

[ron minnich]

People occasionally pull old binaries from the archive and they still
run. I think it'd be nice if they could still be traced as well as
still run.

If a syscall is supported, then it should be possible to trace it.

ron

[9fans] graphics

[ron minnich]

This just hit phoronix:
http://www.phoronix.com/scan.php?page=news_itempx=MTE1NDc

I'm extracting a driver from linux for use in coreboot, using the
semantic patch tool. The goal is to let coreboot draw a splash screen
in the first 200 milliseconds or so after power on. I've got a lot of
bits working, as I explained in my question to the list. Graphics
drivers are, I am finding, a very hard thing to extract, esp. the
intel drivers, as the GPUs are very complex, and the hardware more so:
every link needs to be trained. This is not vga ... it gets messy.

This is not the same as a shim to let you run source. It's rewriting
source with semantic patches, and it's much more powerful.

It has occurred to me more than once that one could use this same
technique to programatically create native hardware
drivers for plan 9 and avoid vesa.

You might even be able to get coccinnelle running on plan 9 with
cinap's excellent linuxemu tool so you can do the patch.

ron

Re: [9fans] nix at lsub

[ron minnich]

On Mon, Apr 16, 2012 at 10:32 AM, Noah Evans noah.ev...@gmail.com wrote:

 I think those of us sticking with hg are doing so more for social
 reasons than technical ones.

There are technical reasons as well. But, let it suffice to say that
the tree is forked, and let it go at that.

ron

Re: [9fans] Plan 9 rejected from GSoC 2012

[ron minnich]

coreboot got rejected too and we had 5 years in a row. Don't feel bad.
I think they're trying to make sure that they don't get the same
players year after year, which is a good idea IMHO.

ron

[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] xcpu.org

[ron minnich]

expires tomorrow. I don't intend to renew, anybody want it?

ron

[9fans] xcpu.org is taken

[ron minnich]

Wow, that was fast. Anyway, it's taken.

thanks

ron

Re: [9fans] venti and contrib: RFC

[ron minnich]

I doubt anyone would object if you want to change the text and submit
to the website owners.

ron

Re: [9fans] venti and contrib: RFC

[ron minnich]

but john, the whole your venti would easily fit in even a small server
memory, now and forever ;)

ron

Re: [9fans] fun with replica and pull

[ron minnich]

On Tue, Dec 20, 2011 at 5:23 AM, erik quanstrom quans...@quanstro.net wrote:

 if you're feeling like a really big hammer, why not run pull
 once, run through sed/awk/whatever to generate a complete
 list of -s'es and run pull again?

 disgusting, no?

it reminds me of why we went with hg on the NIX tree.

ron

Re: [9fans] hg over ssh

[ron minnich]

On Thu, Dec 15, 2011 at 1:44 PM, Troy Cauble troycau...@gmail.com wrote:

  remote: abort: Bad file number
  abort: no suitable response from remote hg!

for fun, run under ratrace and you'll see the problem. This may be the
top of stack problem but I am not sure. I just don't recall.

ron

Re: [9fans] Building Go on Plan 9

[ron minnich]

On Fri, Dec 2, 2011 at 12:49 AM, Francisco J Ballesteros n...@lsub.org wrote:
 Well, that's actually the approach Ron would choose for nix.
 IIRC, there were a bunch of mkfiles added to the std. go tree
 to make it compile, but I may be mistaken.
 Ron knows better.

My first hope was pretty much what others have said here: parallel
mkfiles to the Makefiles, because I expected they would change slowly
if at all. Andrey and I did get this going, and a simple
mk install
in go/src
sufficed to build and install all Go packages and produce some working
binaries, however that approach is not going to be accepted, because
it requires mkfiles in the Go source tree.

For the record, it takes a surprisingly small amount of effort to make
this work, once you know what is going on. Oh, and, there are some
bugs in the Go source that are uncovered when one builds on NIX. I've
submitted one fix and have one or two more in the works. The work has
not been in vain.

I think we need to be realistic about how much we can influence the Go
mainline source. I keep seeing comments on 9fans about how we can
change the way the Go source is written/built/managed, and those
comments envision some signiifcant changes. To repeat, I have been
told in no uncertain terms that changing the way Go is set up to
accommodate great Plan 9 ideas is just not going to happen, and that
our footprint in the Go source tree must remain very small. I think
that is the correct approach on the part of the Go team.

We have made minor changes on NIX to accomodate Go. Simple examples:
/*/mkfile
have an entry for the name of the Go compiler. There is a /go directory.

Based on the Python experience, where Plan 9's python is always far
behind the leading edge, I still believe that it is best if the
following always worked:

hg clone the-official-go-tree go
cd go/src
./some-shell-script

I do not think it makes sense to have Go source distributed as part of
the Plan 9 distro or contrib mechanism as that approach has not worked
well (in my view) for Python. Again, what I'd like to have is a Go
that always builds on Plan 9 from the mainline go source tree,
without having to dump in lots of patch files and other junk or change
the Makefiles. Andrey and I worked toward a build with zero changes
model. We did not get done and decided to wait for Go 1 anyway because
the number of Makefiles will be greatly reduced in Go 1 -- I expect
there will be less than 10 or so.

I believe the Go authors will accept a single shell script or two and
a go/9/include tree as part of the standard distro, so we need to
think in those terms. What I have in go/9/include today are some u.h
files, and that and a very simple set of changes should suffice to let
us build Go on Plan 9 with *zero* changes from the standard go source.

I hope that last paragraph was not too confusing.

Thanks

ron

Re: [9fans] Building Go on Plan 9

[ron minnich]

On Fri, Dec 2, 2011 at 6:33 AM, Anthony Martin al...@pbrane.org wrote:

 modify ape/make.

That strikes me as a good approach. The Go Makefiles do use very
standard Plan 9 like idioms but there are a few things they do that
looked gmake-dependent to me. There are very few of them however.

ron

Re: [9fans] troff book

[ron minnich]

I've done papers and books in latex forever (don't want to say how
long). At the time, I was a troff refugee, having gotten annoyed with
troff on unix after a few years.

when I was at lsub last may, I got used to their nice scripts and such
and now would much rather do short papers in troff than anything else.
My new rule is  20 pages,  1 chapter, no need for complex math, do
troff. Else, do latex. Part of the reason is being that the open
source community has, as usual, come up with 50 ways to do anything in
latex, most incompatible with the other, and in many cases latex and
pdflatex are mutually exclusive: latex and pdflatex either fail to
produce the same output, or, worse, can not accept the same input.
tex/latex, once clean and small, are now a beast, like unto most other
open source stuff nowadays. Troff has the virtue of having changed
little in that time.

Now if someone can do a set of IEEE macros for troff 

Irony alert! The Bell Labs journal now requires submissions in *word*.

ron

Re: [9fans] Building Go on Plan 9

[ron minnich]

On Fri, Dec 2, 2011 at 9:58 AM, Francisco J Ballesteros n...@lsub.org wrote:
 +1 for using parallel mkfiles.

as I say, I liked this too, but it fails the zero changes rule.

But we'll let the guys doing the work make the rules. First one to
produce a useable Go tree wins -- if, that is, they make updates
from the mainline go tree easy.

Be aware that no go tree I know of passes the Go test suite, yet. Lots
of fun ahead.

Anthony, you do know that there is a mk based version of Go that builds, right?

ron

Re: [9fans] go v. mk

[ron minnich]

nobody is stopping you from doing anything. go for it.

ron

Re: [9fans] go v. mk

[ron minnich]

On Fri, Dec 2, 2011 at 4:06 PM, Steve Simon st...@quintile.net wrote:
  It can't be that
 hard to parse out DIR= from there and turn it into a native mkfile.

 Ok, its not that simple but perhaps somthing along the lines of
 /sys/src/cmd/mk/mkconv could help?

Did you try it? Might be worth trying it. We did. But maybe it's time
to try things first and then send email :-)

ron

Re: [9fans] Building Go on Plan 9

[ron minnich]

On Thu, Dec 1, 2011 at 11:54 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
 There's nothing wrong with mk.  It's just that
 I highly doubt we could get a separate set of
 mkfiles included in the Go distribution.

 Have you tried?  It's a non-invasive change, and once they are set up it's
 unlikely they will need to be updated often.



I've tried. The answer is no. No mkfiles in the tree. I've not
watched this thread. Is this another totally different approach?

ron

Re: [9fans] Fortran growing in absolute number of users

[ron minnich]

A guy I know at LANL just mandated C++ for all codes, no more Fortran.

There are no hard and fast rules.

That article is an advertisement, so treat it as such :)

ron

Re: [9fans] 9vx instability

[ron minnich]

On Thu, Nov 24, 2011 at 10:25 AM, erik quanstrom quans...@quanstro.net wrote:
 This, to be honest, doesn't say much.
 However, recently I stumbled over this:
 http://www.sptechweb.com/content/article.aspx?ArticleID=35742print=true

 geoff did cwfs, and has done more to maintain the system
 than the rest of us put together.  he has my respect for that.

 thanks, geoff.

Absolutely. What was interesting when I was frequently updating
sysfromiso was watching the continuous flow of improvements in code
from Bell Labs. But in the Plan 9 style, the number of lines changed
could be small in number, yet potent in impact. Plan 9 is very much
alive. It lacks the near continuous code churn of many open source
projects -- a virtue! -- while continuing to add new support for new
hardware and code improvements. Changes are not made for change sake;
they are made because they make real improvements in the system. It's
hard not to like that.

ron

Re: [9fans] 9vx instability

[ron minnich]

Um, cinap, just FYI, I was not aiming at you or anyone else in
particular. Sorry if it sounded that way.

It's a holiday here, and not many other places, but still ... happy
-day everyone!

ron

Re: [9fans] Let's get VM configs onto the Wiki.

[ron minnich]

On Thu, Nov 24, 2011 at 1:16 PM, Bakul Shah ba...@bitblocks.com wrote:

 But I am not a fan of Wikis. Usually a wiki ends up being an
 unstructured collection of useful facts that can go stale as
 it takes a lot of effort to keep it organized.

Would be interesting if every wiki entry came with an expiration date,
and entries just went away or no longer appeared. So much of what I
find on wikis is completely wrong any more.

ro

Re: [9fans] Plan 9 Related Work

[ron minnich]

use either one. Let us know how it goes :-)

ron

Re: [9fans] Returning to Plan 9: Virtualization, Distributions

[ron minnich]

If you're serious about booting a 64-bit os you need NIX. But you're
not going to get graphics.

ron

Re: [9fans] Returning to Plan 9: Virtualization, Distributions

[ron minnich]

There's confusion here, and I am partly to blame ...

if you get googlecode.com/p/nix-os

you'll get a file system image that will be usable on a 32-bit
machine. We use it with 9vx. That image includes all the bits you need
to build and boot a NIX kernel. The intent of this distro is to allow
32-bit users to create 64-bit kernels and test. So the nix-os repo is
designed to let you set up on a 32-bit machine and bootstrap a
separate 64-bit machine. We thus envision you having more than one
system available.

I use it as follows:
hg clone http://googlecode.com/p/nix-os nix-os
cd nix-os
./9vx.OSX10.6 -r . -u rminnich
(get on the machine)
objtype=386
cd /sys/src/ape/lib
mk install
cd /sys/src
objtype=amd64
mk install
cd /sys/src/nix/k10
mk install

You are then good to go, unless I missed a step. You need some 386
bits from ape to build the 64-bit code.

We've set up nix-os root file system to play nice with 9vx, which is
why we include a 9vx for osx in the file system.

so to repeat: nix-os is a mercurial image of a root file system for
32-bit nodes, and it is intended to make it easy for you to boot
64-bit nodes. We assumed that you had at least one 32-bit and one
64-bit system.

I hope this helps a little.

ron

Re: [9fans] 9vx instability

[ron minnich]

If you're on linux, you should consider kvm + kvmtool + plan 9.

vx32 is incomplete. It has many problems. Nobody's had the time to
really fix it. It's nice that it works but you should not assume that
it's a solid piece of software; it's not.

ron

Re: [9fans] 9vx instability

[ron minnich]

just normal usage, mk install and such in the nix release, and there
are times that memory corruption happens. There's been a race in there
forever, and sometimes you hit it, and things start to go south.

ron

Re: [9fans] Aki's drawterm-fb, THX/THNX img

[ron minnich]

x11 is not that big of an impact on a netbook. I suspect your real
problem is some horrible X desktop a la Gnome.

Get something like FLWM (very light weight) or Rio and run 9vx in that
environment. I've done that and it's very fast.

The drawterm-fb had issues and I don't recommend you spending a lot of
time to try to find it.

ron

Re: [9fans] all you yacc experts

[ron minnich]

The bisonerrors script is 124 lines. This email thread is now 724
lines. I figure when the number of lines of this thread is 10x the
size of the bisonerrors script it would be nice to replace the endless
discussion with some code :-)

ron

[9fans] Errata and Addendum: A standard also sucks if it includes the word advanced

[ron minnich]

I'm looking at a mainboard manual and I see this in the table of contents:
Advanced ACPI Configuration

Which, expanded, is
Advanced Advanced Configuration and Power Interface Configuration

Man. Does the advanced distribute?
Advanced Advanced Advanced Configuration and Advanced Power Advanced
Interface Advanced Configuration

Or just do something like this:
A^2PCIC

Either way, it must be really really great!

Or maybe it just really really sucks. I vote for the latter. So we
have another new rule for Standards That Suck.

ron

[9fans] all you yacc experts

[ron minnich]

Go is pretty solid on 386 and I'm slowly puzzling my way through NIX support.

One thing that stands in the way of full native build is the bison issue.

If somebody wants to look at enhancing yacc so that the extra bison
bits can be supported, that would probably do the trick. I have no
idea of the level of effort, I have not looked.

We could run bison under linuxemu; I don't think this approach is as
good because it still leaves us a bit dependent on some outside force
for bison binaries. But that might be a good stopgap.

I'm looking forward to Go 1 because I'm pretty sure that most of what
we've had to do for this version of Go will go away :-)

I'm still amused that the best way to write portable C is to just ship
a reasonable C compiler with Go and use gcc to build that C compiler,
and then compile your portable C with it :-)

Thanks

ron

Re: [9fans] all you yacc experts

[ron minnich]

i'm well aware we can tweak go and remove better error messages. that
doesn't count IMHO. We're working to get to the point where we don't
tweak the go source at all and it just builds. I don't see the point
in making a go for Plan 9 that is in some way compromised. So, getting
back to my original comment, if somebody wants to dig into this it
would be helpful.

ron

Re: [9fans] all you yacc experts

[ron minnich]

On Fri, Nov 11, 2011 at 12:54 PM, Bakul Shah ba...@bitblocks.com wrote:

 Might it be worth looking Merr or iyacc?  Porting bison to
 plan9 seems like a hugh punishment for a quick hack:-)
 Implementing Jeffery's directly in yacc might benefit other
 parsers as well.

If it's worth a look then I hope someone looks. I'm more trying to push that
than having this discussion :-)

I think porting bison is the wrong way to go, personally.

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

This is due to something bad that happened in my fusion (which has at
this point totally gone away -- blown venti).

I just fixed it, go ahead and give it another try.

ron

On Tue, Nov 1, 2011 at 9:57 AM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
 i pulled the sources about 8 hours ago for another environment and
 tried to build. it stops in /go/src/cmd/gotest due to a missing
 'mk.go'. inspecting Makefile and mkfile shows that GOFILES includes
 'make.go' in Makefile and 'mk.go' in mkfile -- neither exists. i think
 this might be an unfinished change. removing the dependency from
 mkfile result in a couple of undefined names in gotest.go.

 install ../cmd/gotest
 INSTALL FAIL ../cmd/gotest
 /go/src/pkg
 mk: don't know how to make 'mk.go' in directory /go/src/cmd/gotest
 mk: echo install ../cmd/gotest ...  : exit status=rc 8582: 1
 mk: for (i in ...  : exit status=rc 272: rc 909: mk 911: error

 On Mon, Oct 31, 2011 at 8:11 AM, ron minnich rminn...@gmail.com wrote:
 A number of us have been working on a native Go port for plan 9.

 The big goal is to do this in a way that makes tracking Go source a
 non-problem, and to eventually just have these changes part of the
 standard Go tree, so there is no work at all.

 we're pretty close, thanks to previous work others have done on the Go port.

 You can try it.

 Right now, due to a few bison and bash dependencies, there are files
 we can not generate. These are supplied as part of the repo.

 cd
 hg clone https://code.google.com/p/rminnich-9go go
 bind -ac . /
 cd /go
 cd 9/prebuilt
 rc install
 cd /go/src
 mk install

 You've now got all commands and the toolchain. Now you can help us fix this:

 goinstall bitbucket.org/rminnich/forth (or any package)

 fails with an odd error. use ratrace -c on that command to see what
 sequence produces this error.

 Be sure to use the google code tools to mark bugs and submit fixes.

 I am going to be doing an update from the main go tree into this repo
 soon. This will likely break things. This working branch will be
 tagged 'audrey'.

 thanks

 ron

[9fans] native (mostly) go for plan9

[ron minnich]

A number of us have been working on a native Go port for plan 9.

The big goal is to do this in a way that makes tracking Go source a
non-problem, and to eventually just have these changes part of the
standard Go tree, so there is no work at all.

we're pretty close, thanks to previous work others have done on the Go port.

You can try it.

Right now, due to a few bison and bash dependencies, there are files
we can not generate. These are supplied as part of the repo.

cd
hg clone https://code.google.com/p/rminnich-9go go
bind -ac . /
cd /go
cd 9/prebuilt
rc install
cd /go/src
mk install

You've now got all commands and the toolchain. Now you can help us fix this:

goinstall bitbucket.org/rminnich/forth (or any package)

fails with an odd error. use ratrace -c on that command to see what
sequence produces this error.

Be sure to use the google code tools to mark bugs and submit fixes.

I am going to be doing an update from the main go tree into this repo
soon. This will likely break things. This working branch will be
tagged 'audrey'.

thanks

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

you forgot to
cd /go/src
. 9setup


On Mon, Oct 31, 2011 at 9:41 AM, Stanley Lieber
stanley.lie...@gmail.com wrote:
 On Mon, Oct 31, 2011 at 10:11 AM, ron minnich rminn...@gmail.com wrote:

 [snip]

 You can try it.

 Thanks, Ron.

 I ran into some problems:

 piro% cd
 piro% ls
 acme.dump
 bin
 books
 dump
 go
 gout
 img
 lib
 mkfile
 paint
 tmp
 piro% bind -ac . /
 piro% cd /go
 piro% cd 9/prebuilt
 piro% rc install
 piro% cd /go/src
 piro% mk install
 cmd
 cc
 warning: skipping missing include file: /src/9bootstrap.mk: '/src'
 directory entry not found
 ar vu cc.a8 y.tab.8 lex.8 mac.8 dcl.8 acid.8 godefs.8 bits.8 com.8
 scon.8 funct.8 sub.8 com64.8 dpchk.8 omachcap.8
 gc
 warning: skipping missing include file: /src/9bootstrap.mk: '/src'
 directory entry not found
 $HOST_CC '-DGOOS='^$GOOS^'' '-DGOARCH='^$GOARCH^''
 '-DGOROOT='^$GOROOT^'' '-DGOVERSION='^$GOVERSION^''
 ../../lib9/goos.c
 rc: null list in concatenation
 mk: $HOST_CC '-DGOOS='^$GOOS^'' '-DGOARCH='^$GOARCH^'' ...  : exit
 status=rc 4238: error
 mk: for (i in ...  : exit status=rc 4227: rc 4235: mk 4237: error
 mk: for (i in ...  : exit status=rc 4219: rc 4221: mk 4223: error
 piro% grep -e '\/src' *
 Make.cmd:include $(QUOTED_GOROOT)/src/Make.common
 Make.pkg:include $(QUOTED_GOROOT)/src/Make.common
 all.bash:       echo 'all.bash must be run from $GOROOT/src' 12
 clean.bash:     echo 'clean.bash must be run from $GOROOT/src' 12
 clean.bash:     $MAKE -C $GOROOT/src/$i clean
 ditunix:(cd $GOROOT/src/libbio  make install)
 ditunix:(cd $GOROOT/src/lib9   make install)
 ditunix:(cd $GOROOT/src/./cmd/6l  sh -x ./ditunix)
 ditunix:(cd $GOROOT/src/./cmd/8a  sh -x ./ditunix)
 ditunix:(cd $GOROOT/src/./cmd/8l  sh -x ./ditunix)
 ditunix:(cd $GOROOT/src/./cmd/cc  sh -x ./ditunix)
 ditunix:(cd $GOROOT/src/./cmd/gc  sh -x ./ditunix)
 ditunix:(cd $GOROOT/src/./pkg/  sh ./deps.bash  cp Make.deps mk.deps)
 make.bash:      echo 'make.bash must be run from $GOROOT/src' 12
 make.bash:sed -e s|@CC@|$CC|  $GOROOT/src/quietgcc.bash  
 $GOBIN/quietgcc
 make.bash:      cd $GOROOT/src/pkg;
 make.bash:bash $GOROOT/src/clean.bash
 mk.cmd: $GOROOT/src/mk.common
 mk.pkg: $GOROOT/src/mk.common
 quietgcc.bash:# The master for this file is $GOROOT/src/quietgcc.bash
 run.bash:       builtin cd $GOROOT/src/$1
 sudo.bash:      sudo cp $GOROOT/src/cmd/$i/6$i /usr/local/bin/6$i
 piro% GOROOT=/go
 piro% mk install
 cmd
 cc
 ar vu cc.a8 y.tab.8 lex.8 mac.8 dcl.8 acid.8 godefs.8 bits.8 com.8
 scon.8 funct.8 sub.8 com64.8 dpchk.8 omachcap.8
 gc
 8c '-DGOOS='^$GOOS^'' '-DGOARCH='^$GOARCH^''
 '-DGOROOT='^$GOROOT^'' '-DGOVERSION='^$GOVERSION^''
 ../../lib9/goos.c
 rc: null list in concatenation
 mk: 8c '-DGOOS='^$GOOS^'' '-DGOARCH='^$GOARCH^'' ...  : exit
 status=rc 4288: error
 mk: for (i in ...  : exit status=rc 4253: rc 4273: mk 4275: error
 mk: for (i in ...  : exit status=rc 4245: rc 4247: mk 4249: error

 -sl

Re: [9fans] native (mostly) go for plan9

[ron minnich]

On Mon, Oct 31, 2011 at 10:41 AM, andrey mirtchovski
mirtchov...@gmail.com wrote:
 /386/bin/go/8c -Iplan9 -I386 -Iplan9/386 -I . amd64/traceback.c
 8c 5781: suicide: sys: trap: fault write addr=0x3007ebf4 pc=0x00015e5a
 mk: /386/bin/go/8c -Iplan9 -I386 ...  : exit status=rc 5779: 8c 5781:
 sys: trap: fault write addr=0x3007ebf4 pc=0x00015e5a

 i'm not seeing this in either 9vx or a plan9 vm... what are compiling on?



I'm willing to bet it's 9vx ... there's something bad going on in there.

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

On Mon, Oct 31, 2011 at 10:45 AM, Stanley Lieber
stanley.lie...@gmail.com wrote:
 On Mon, Oct 31, 2011 at 12:41 PM, andrey mirtchovski
 mirtchov...@gmail.com wrote:
 /386/bin/go/8c -Iplan9 -I386 -Iplan9/386 -I . amd64/traceback.c
 8c 5781: suicide: sys: trap: fault write addr=0x3007ebf4 pc=0x00015e5a
 mk: /386/bin/go/8c -Iplan9 -I386 ...  : exit status=rc 5779: 8c 5781:
 sys: trap: fault write addr=0x3007ebf4 pc=0x00015e5a

 i'm not seeing this in either 9vx or a plan9 vm... what are compiling on?

 9front in vmware.

ah, not something I can help with, certainly ...

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

Would be interesting if, from 9front, you could:
9fs sources
bind /n/sources/plan9/386/bin/8c /bin/8c

and see if it breaks.

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

On Mon, Oct 31, 2011 at 12:44 PM, Stanley Lieber
stanley.lie...@gmail.com wrote:
 On Mon, Oct 31, 2011 at 2:32 PM, ron minnich rminn...@gmail.com wrote:
 Would be interesting if, from 9front, you could:
 9fs sources
 bind /n/sources/plan9/386/bin/8c /bin/8c

 and see if it breaks.

 ron

 Exact same result.

hmm, interesting. We'll have to see if anyone else hits it then,
you're the first lucky winner. Don't you hate it when that happens ...

sorry

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

btw, I just moved us up to tip Lyndon found out how to kill the cpp errors.

Builds fine, go programs (some of them) run fine.

If anybody wants to work out why pkgt/syscall/exec_plan9.go is closing
fd 6 twice when goinstall tries to fire off the mk command, would be
good to know.

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

On Mon, Oct 31, 2011 at 3:10 PM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
 awesome job!  compiled fine. i'm running godoc and now rewriting some
 cgi's in go. many thanks to everyone  involved.

OK, now, the current problem with syscall/exec_plan9.go is that it is
a little too eager to close FDs. It's doing the close by hand because
it's not possible on Plan 9 to take an fd and set to to close-on-exec
-- that's only done on  open on Plan 9 (on unix the code does an
fcntl). But if an FD is used twice for a child -- as it is with
combined stdout/stderr -- then the close closes the fd before it can
be dup'ed a second time. Bad.

I did the lazy thing and commented out the erroneous close for now.
The easy fix is to track the fds to be closed in a map and then close
them all later. That's next. Another possibility is to allow '#d/*ctl'
to be writeable and implement a
closeonexec
control message for fds. But maybe that's  just too much. It is
certainly easy to do, but is that kind of feature something we want to
add?

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

On Mon, Oct 31, 2011 at 3:10 PM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
 awesome job!  compiled fine. i'm running godoc and now rewriting some
 cgi's in go. many thanks to everyone  involved.

Keep us posted on any problems you hit. Also, if you want to track
tip, I just did a pull.I just committed more fixes from Andrey and
Lyndon.

Finally, anybody who wants to attack the need for prebuilt files,
well, we'd love it.

Finally: if you have a file system shared from unix to Plan 9, a
second way to build the prebuilt files:
cd go/src
sh ditunix

hmm, ditunix, what a name. Long ago I named everything 'doit'. Too
much typing. So it became dit. And ditunix should then be obvious.

Also, a very useful thing would be for someone to just diff the
standard go tree and this tree, looking for any issues, because at
some point we want to get this back into the main go tree.

ron

Re: [9fans] native (mostly) go for plan9

[ron minnich]

well, I could be really lazy. I think this would work.

given an fd, say 6
newfd = open('#d/6, OREXEC|permissions)
close(fd)
then dup the newfd. The newfd will close when you leave.

Problem: what are the permissions for the old fd ...

ron

Re: [9fans] nanosleep()?

[ron minnich]

On Thu, Oct 27, 2011 at 9:07 PM, Lucio De Re lu...@proxima.alt.za wrote:
 In porting the prof command from the Go distribution (src/cmd/prof),
 absence of the nanosleep() function seems to be the final stumbling
 block, at least for compilation purposes.  Any suggestions on how to
 implement it?

well, it is unlikely to say the least that the OSes we have will let
you sleep for precisely one nanosecond. I'd be surprised if they even
hit a microsecond reliably ...

For a first pass, you could create a nanosleep for plan 9 that rounds
to milliseconds and then use sleep()

ron

Re: [9fans] tcl, 9p

[ron minnich]

Well, I did 9p clients for testing 15 years ago. It might have been
the right thing then; I was even making nfs clients in tcl back then.

Would I do it again?

No

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

you need to dig a lot more than that!

What distro? What OS? did you look in the file to see what was going on?

If something this simple stops you this much, this may not be the
right project for you to take on.

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

On Wed, Sep 21, 2011 at 3:06 PM, Ethan Grammatikidis
eeke...@fastmail.fm wrote:
 On Sat, 17 Sep 2011 11:26:49 -0700
 Joel Armstrong joelcarmstr...@gmail.com wrote:

 The phone won't beep or anything

 Does it not have audio?



I'm not sure I understand the point of your question, but I'm not sure
you understand the issues surrounding your question :-)

I mean, of course it has audio. It's a phone.

ron

Re: [9fans] Nemo book

[ron minnich]

On Thu, Sep 15, 2011 at 8:46 PM, Jens Staal staal1...@gmail.com wrote:

 Alternatively - would a newlib approach be a better bet to get
 binutils/gcc going? I have been trying to read up on it and to try to
 locate the syscall information I need from plan9 libc. If anyone got
 any pointers on how to do this, it would be appreciated :)

I was unsure of the cross compiler idea. Was this to run on linux to
create plan 9 binaries?

If you really want to do that, just go ahead and port the plan 9 c
compilers etc. to unix. I did the amd64 linker in about 10 minutes.
It's very straightforward C code, far easier to port than the sort of
stuff you find in the GNU world -- someone once complained on this
list that Plan  9 C code was some sort of old usage or something --
they did not realize that was a *virtue*. The ?c would be a bit longer
to do but probably not much. Then you can compile all Plan 9 code on
Unix-like systems to target Plan 9.

That may not be what you meant.

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

On Mon, Sep 19, 2011 at 10:25 AM, John Floren j...@jfloren.net wrote:
 On Sat, Sep 17, 2011 at 3:05 PM, ron minnich rminn...@gmail.com wrote:
 What would truly be interesting, since we don't need to reboot to
 switch modes, would be a button to
 do just that ...


 It's really easy to switch modes from the shell.

 To go from zygote to Inferno:

 stop zygote
 stop media
 start media-inferno
 start inferno

 To go from inferno to zygote:

 stop inferno
 stop media-inferno
 killall emu-g
 start media
 start zygote

 Adding an appropriate menu item in Inferno would allow you to switch
 back to the Java UI easily. Might be a little tougher on the Java side
 to go to Inferno, without being connected to a PC.

yeah, android is so powerful, eh? You can't just exit it.

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

but showing that menu on the inferno side would be very neat.

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

OK, more data this morning.

Since the cyanogen upgrade, no linux vm I have on OSX/VMWare can
enumerate the phone over USB. This is a very common problem as
revealed by any search.

On the one linux box I have, the phone is enumerated as a USB storage.
There may be some setting I need to reset ... but that box, having
been turned off since april, seems to have decided it can't do wifi
more ... so, that's not an option at present!

I did try downloading the android sdk on a clean vmware-based linux
platform. No fastboot in there. So far the only fastboot I have is the
one I built from source during android bootcamp.

You can NOT install inferno from anything but Linux. There are a few
linux tool dependencies in th scripts that can not be satisfied (yet)
on a mac. I am going to see what is possible.

I continue to be amused that all these Java write once run
everywhere environments always come with a huge stack of this CPU,
this OS, this version programs without which they can not function.
Hmm. All I need with inferno is emu. Maybe inferno can teach them some
things :-)

Finally, it's a linux phone: I keep thinking I ought to be able to do
the install scripts on the phone, not on some other box and download
them. If I can figure out where to plug in an SD card -- it claims to
have one! -- I might just give that a go.

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

joel, on osx, some scripts are not there. I was more concerned about
this than the flash failures because I'm not sure what they do.

sh: mkbootimg: command not found

Where did your version of this one come from? It's nowhere on my machine.

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

Slight correction:
git clone https://github.com/CyanogenMod/android_system_core
cd android_system_core/
cd libmincrypt/
gcc -I../include/ -o sha.o -c sha.c
mv sha.o ../mkbootimg/
cd ../mkbootimg/
gcc -I../include/ -c mkbootimg.c
gcc -o mkbootimg mkbootimg.o sha.o

Although most of you will get that.

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

A few corrections.

 $ adb shell mount -o remount,rw /
 $ adb push boot-inferno.img

adb push work/boot-inferno.img /boot-inferno.img

 $ adb shell
 Now you'll be in an Android shell.
 android$ cat /proc/mtd
 This will hopefully give you a list of mtd devices and their names.
 We only care about the one called boot.
 android$ cat /dev/zero  /dev/mtd/boot device from above
 The zeroing step may not be necessary, but I've never tried flashing
 the boot manually without it.

It is hard to believe it is needed. The reason is the erase state of
flash is all 1s, not all zeros. Cat'ing zeros onto the flash is
probably not what you want: it corresponds to an all-bits-burned
state, not an all-bits-cleared state. In this case when you the next
step:

 android$ flash_image boot /boot-inferno.img

The mtd driver will likely erase the flash (to all 1s!) and then burn it :-)


 Then reboot and it should work.

android continues to work. But no inferno at present. I get the nice
white screen, but if I touch it, well, it's blank after a bit.



The parallel_push script did not work that well for me, I had to push
dis/ by hand. I think it would be better to copy the tar file over and
untar it -- would avoid mac silliness with case in the names, as well.

Anyway, I'm booted. I've taken notes and will post them later.

I think I'm still missing lots of stuff so I may just push the tar
file and untar it.

ron

Re: [9fans] Announcing Inferno for Android phones

[ron minnich]

OK, I just adb pushed the tar file over and untar'ed and things were
more complete.

So it's up on my nexus-s too. John, would recommend putting OSX and
linux versions of fastboot and mkbootimg into the tar file or on the
web page.

I can tell it's inferno because I hit a button and get instant
response. This is somewhat unlike the java-based experience, although
of course I'm not about to stop using android for good ... just for
most of the time :-)

What would truly be interesting, since we don't need to reboot to
switch modes, would be a button to
do just that ...

All right folks, it's there. Now it's time to contribute! You can see
the limitations, and this is a very hackable system. Somebody want to
write a gps device so I can cat my GPS coords and see if that creates
a number I can dial :-)

ron