[9fans] wiki...

[9fans] wiki...

[Ethan Grammatikidis]

On 11 Apr 2011, at 2:51 pm, David Leimbach wrote:

> I posted some on the wiki about how I got the guruplug working for
> me...

How do you find things on the wiki? I came across this today. My
first thought was to look in the other_hardware page where I found
mention of the Shevaplug and Guruplug but no links so I looked in the
news page and only found a link to Nemo's home website... :)

Google simply can't find the word "guruplug" anywhere on
www.plan9.bell-labs.com despite there being a clear link chain to a
wiki page which has it, so that's no use.

I guess I can mount and search the wiki, when it's up. I hope that
works. :)

If I can find the pages and edit the wiki I'd make links and maybe
fix up some obsolete info too. Do I need an account to edit the wiki?
I would check but sources went down in between my mounting it and cd-
ing into it. That's the 2nd time that's happened in the last few
weeks. I think the other time was when I tried to mount the wiki too.

Re: [9fans] wiki...

[pmarin]

http://plan9.bell-labs.com/wiki/plan9/Guruplug/index.html
I spend 2 second to find it, but is true that the wiki have search issues.

On Sat, Apr 23, 2011 at 6:43 AM, Ethan Grammatikidis
<eekee57@fastmail.fm> wrote:
>
> On 11 Apr 2011, at 2:51 pm, David Leimbach wrote:
>
>> I posted some on the wiki about how I got the guruplug working for me...
>
> How do you find things on the wiki? I came across this today. My first
> thought was to look in the other_hardware page where I found mention of the
> Shevaplug and Guruplug but no links so I looked in the news page and only
> found a link to Nemo's home website... :)
>
> Google simply can't find the word "guruplug" anywhere on
> www.plan9.http://plan9.bell-labs.com/wiki/plan9/Guruplug/index.htmlbell-labs.com despite there being a clear link chain to a wiki
> page which has it, so that's no use.
>
> I guess I can mount and search the wiki, when it's up. I hope that works. :)
>
> If I can find the pages and edit the wiki I'd make links and maybe fix up
> some obsolete info too. Do I need an account to edit the wiki? I would check
> but sources went down in between my mounting it and cd-ing into it. That's
> the 2nd time that's happened in the last few weeks. I think the other time
> was when I tried to mount the wiki too.
>
>

Re: [9fans] wiki...

[smiley]

Ethan Grammatikidis <eekee57@fastmail.fm> writes:

> On 11 Apr 2011, at 2:51 pm, David Leimbach wrote:
>
>> I posted some on the wiki about how I got the guruplug working for
>> me...
>
> How do you find things on the wiki? I came across this today. My first
> thought was to look in the other_hardware page where I found  mention
> of the Shevaplug and Guruplug but no links so I looked in the  news
> page and only found a link to Nemo's home website... :)

There's a wiki page index:

http://www.plan9.bell-labs.com/wiki/plan9/Wiki_index

You can also:

9fs wiki && cd /mnt/wiki

The wiki pages should all be listed in that directory, with spaces in
their names converted to underscores.

> Google simply can't find the word "guruplug" anywhere on
> www.plan9.bell-labs.com despite there being a clear link chain to a
> wiki page which has it, so that's no use.

Google can't find much at all regarding Plan 9.  (Well, not for any of
the searches I've done.)  I don't think google has learned that we exist
yet.  ;)

> up some obsolete info too. Do I need an account to edit the wiki?  I

Nope.  Anyone with srv(4) can mount it.  The standard way to edit it is
via Acme.  'Local 9fs wiki' and then 'Wiki'.

In theory.

When I try this, I am able to pull up the wiki pages.  But I only have
about 60 seconds to get in, make my changes, and Put them.  If I take
any longer than that, I get all sorts of "hangup" errors.  I have to
close out the Wiki windows, 9fs and Wiki back in, and try again to make
the changes faster.  Guess the fids go stale or something.  It'd be nice
to know why the wiki drops out so quickly, though.

I had sources go down in the middle of contrib/install'ing tex.  Now
THAT was frustrating.  contrib(1) doesn't handle partially installed
packages very well at all.  Say, where is the canonical community bug
tracker for Plan 9, anyway?

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] wiki...

[Ethan Grammatikidis]

On 24 Apr 2011, at 5:48 am, smiley@zenzebra.mv.com wrote:

> Ethan Grammatikidis <eekee57@fastmail.fm> writes:
>
>> On 11 Apr 2011, at 2:51 pm, David Leimbach wrote:
>>
>>> I posted some on the wiki about how I got the guruplug working for
>>> me...
>>
>> How do you find things on the wiki? I came across this today. My
>> first
>> thought was to look in the other_hardware page where I found  mention
>> of the Shevaplug and Guruplug but no links so I looked in the  news
>> page and only found a link to Nemo's home website... :)
>
> There's a wiki page index:
>
> http://www.plan9.bell-labs.com/wiki/plan9/Wiki_index

An index which is only linked from the front page.. well ok, it's a
lot better than no index.

>
> You can also:
>
> 9fs wiki && cd /mnt/wiki
>
> The wiki pages should all be listed in that directory, with spaces in
> their names converted to underscores.

This is what I would have done if sources hadn't gone down.

>
>> Google simply can't find the word "guruplug" anywhere on
>> www.plan9.bell-labs.com despite there being a clear link chain to a
>> wiki page which has it, so that's no use.
>
> Google can't find much at all regarding Plan 9.  (Well, not for any of
> the searches I've done.)  I don't think google has learned that we
> exist
> yet.  ;)
>
>> up some obsolete info too. Do I need an account to edit the wiki?  I
>
> Nope.  Anyone with srv(4) can mount it.  The standard way to edit
> it is
> via Acme.  'Local 9fs wiki' and then 'Wiki'.

Good to know.

>
> In theory.

:)

Incidentally, 9front exists in part because plan 9 theory differs
from practice too often. Unfortunately it's only a few weeks old and
has a grand total of 6 wiki pages, some of which are jokes.

>
> When I try this, I am able to pull up the wiki pages.  But I only have
> about 60 seconds to get in, make my changes, and Put them.  If I take
> any longer than that, I get all sorts of "hangup" errors.  I have to
> close out the Wiki windows, 9fs and Wiki back in, and try again to
> make
> the changes faster.  Guess the fids go stale or something.  It'd be
> nice
> to know why the wiki drops out so quickly, though.

If I only get 60 seconds I certainly will not be helping to fix up
the wiki!

>
> I had sources go down in the middle of contrib/install'ing tex.  Now
> THAT was frustrating.  contrib(1) doesn't handle partially installed
> packages very well at all.  Say, where is the canonical community bug
> tracker for Plan 9, anyway?

Contrib doesn't handle many unexpected things well, don't use it in
9vx if root is on the host filesystem. IIRC it's based on replica(1)
which rather requires ideal circumstances for correct behaviour.

Re: [9fans] wiki...

[hiro]

In http://plan9.bell-labs.com/robots.txt you will find:

User-agent: *
Disallow: /

Re: [9fans] wiki...

[Ethan Grammatikidis]

On 24 Apr 2011, at 9:16 am, hiro wrote:

> In http://plan9.bell-labs.com/robots.txt you will find:
>
> User-agent: *
> Disallow: /

*facepalm* I wondered if this was the case; didn't think to check.
Anyone have any idea why this is there?

Re: [9fans] wiki...

[Balwinder S Dheeman]

On 04/26/11 12:03, Ethan Grammatikidis wrote:
>
> On 24 Apr 2011, at 9:16 am, hiro wrote:
>
>> In http://plan9.bell-labs.com/robots.txt you will find:
>>
>> User-agent: *
>> Disallow: /
>
> *facepalm* I wondered if this was the case; didn't think to check.
> Anyone have any idea why this is there?

Very simple, since the webmaster have already allowed some bots and
disallowed everyone else ;)

You need to read/analyze the whole robots.txt indeed.

--
Balwinder S "bdheeman" Dheeman
(http://werc.homelinux.net/contact/)

Re: [9fans] wiki...

[Ethan Grammatikidis]

On 4 May 2011, at 11:40 am, Balwinder S Dheeman wrote:

> On 04/26/11 12:03, Ethan Grammatikidis wrote:
>>
>> On 24 Apr 2011, at 9:16 am, hiro wrote:
>>
>>> In http://plan9.bell-labs.com/robots.txt you will find:
>>>
>>> User-agent: *
>>> Disallow: /
>>
>> *facepalm* I wondered if this was the case; didn't think to check.
>> Anyone have any idea why this is there?
>
> Very simple, since the webmaster have already allowed some bots and
> disallowed everyone else ;)
>
> You need to read/analyze the whole robots.txt indeed.

Now I've read it I can't understand why Google can't find anything
under /wiki. Even if it did, that robots.txt isn't all that pleasant,
blindly disallowing everyone who isn't google or msn, more or less. O.o

Re: [9fans] wiki...

[dexen deVries]

On Wednesday 04 of May 2011 17:37:41 Ethan Grammatikidis wrote:
> On 4 May 2011, at 11:40 am, Balwinder S Dheeman wrote:
> > On 04/26/11 12:03, Ethan Grammatikidis wrote:
> >> On 24 Apr 2011, at 9:16 am, hiro wrote:
> >>> In http://plan9.bell-labs.com/robots.txt you will find:
> >>> 
> >>> User-agent: *
> >>> Disallow: /
> >> 
> >> *facepalm* I wondered if this was the case; didn't think to check.
> >> Anyone have any idea why this is there?
> > 
> > Very simple, since the webmaster have already allowed some bots and
> > disallowed everyone else ;)
> > 
> > You need to read/analyze the whole robots.txt indeed.
> 
> Now I've read it I can't understand why Google can't find anything
> under /wiki. Even if it did, that robots.txt isn't all that pleasant,
> blindly disallowing everyone who isn't google or msn, more or less. O.o



I believe we need an ``Allow: /'' below the long list of `Disallows' in the 
User-agent: Googlebot, User-agent: msnbot section. Otherwise, only the final 
``Disallow: /'' matches, and in effecet, every robot is cut off.


Or, better, just let any robots crawl the site. Web isn't only about google 
and msn anymore ;-)

(*cough* http://duckduckgo.com/ *cough*)

-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816

Re: [9fans] wiki...

[smiley]

dexen deVries <dexen.devries@gmail.com> writes:

> I believe we need an ``Allow: /'' below the long list of `Disallows' in the
> User-agent: Googlebot, User-agent: msnbot section. Otherwise, only the final
> ``Disallow: /'' matches, and in effecet, every robot is cut off.

I rather like mine own robots.txt (http://www.icebubble.org/robots.txt).
As members of the "alternative OS" crowd, you may appreciate its design.

Incidentally, the wiki employs a very good anti-spam technology: edits
to it can only be made over 9P.  (The HTTP edit mechanism isn't
enabled.)  The wiki's lack of spidering also means it wouldn't be a very
valuable target even IF spambots could edit it over HTTP.

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] wiki...

[Balwinder S Dheeman]

On 05/04/2011 09:09 PM, Ethan Grammatikidis wrote:
>
> On 4 May 2011, at 11:40 am, Balwinder S Dheeman wrote:
>
>> On 04/26/11 12:03, Ethan Grammatikidis wrote:
>>>
>>> On 24 Apr 2011, at 9:16 am, hiro wrote:
>>>
>>>> In http://plan9.bell-labs.com/robots.txt you will find:
>>>>
>>>> User-agent: *
>>>> Disallow: /
>>>
>>> *facepalm* I wondered if this was the case; didn't think to check.
>>> Anyone have any idea why this is there?
>>
>> Very simple, since the webmaster have already allowed some bots and
>> disallowed everyone else ;)
>>
>> You need to read/analyze the whole robots.txt indeed.
>
> Now I've read it I can't understand why Google can't find anything under
> /wiki. Even if it did, that robots.txt isn't all that pleasant, blindly
> disallowing everyone who isn't google or msn, more or less. O.o

May be either the robots.txt is incorrect or Google and MSN/Bing are
interpreting it in wrong manner.

I maintain anu.homelinux.net and werc.homelinux.net sites, mine
robots.txt files are quite simple and I never ever facing these servers
being chocked by any such bot.

--
Balwinder S "bdheeman" Dheeman
(http://werc.homelinux.net/contact/)

Re: [9fans] wiki...

[erik quanstrom]

> I maintain anu.homelinux.net and werc.homelinux.net sites, mine
> robots.txt files are quite simple and I never ever facing these servers
> being chocked by any such bot.

i think it's a mistake to generalized from a sample size of
1 or 2 to the whole world.  give 'em a break.

- erik

Re: [9fans] wiki...

[erik quanstrom]

> >
> > I had sources go down in the middle of contrib/install'ing tex.  Now
> > THAT was frustrating.  contrib(1) doesn't handle partially installed
> > packages very well at all.  Say, where is the canonical community bug
> > tracker for Plan 9, anyway?
>
> Contrib doesn't handle many unexpected things well, don't use it in
> 9vx if root is on the host filesystem.

don't blame replica for the fact that 9vx's default root is strange.
maybe you should blame 9vx.

> IIRC it's based on replica(1)
> which rather requires ideal circumstances for correct behaviour.

partial installs are easy to recover from.  i just used it friday to sort
out a file system that had a contrib package listed as installed, but it
hadn't been.

- erik

[9fans] contrib(1) WAS: Re: wiki...

[smiley]

erik quanstrom <quanstro@quanstro.net> writes:

>> IIRC it's based on replica(1)
>> which rather requires ideal circumstances for correct behaviour.
>
> partial installs are easy to recover from.  i just used it friday to sort
> out a file system that had a contrib package listed as installed, but it
> hadn't been.

It *would* be easy if contrib(1) properly indicated the install status
of a package.  As it is right now, contrib/install marks a package as
installed and THEN goes about installing it.  If anything fails, the
install will still be marked as having been successful.  A subsequent
contrib/install for the same package will snubly claim that the package
has already been installed and refuse to run.  You have to supply the
'-f' switch to make the install complete.  However, doing this requires
(1) knowing that the install broke, and (2) that all the packages
dependencies have been met (because -f also overrides dependency
checking).  contrib(1) doesn't provide any way to check if a package is
up to date, like replica/changes.  Having a contrib(1) wrapper for
replica/changes (say, 'contrib/changes') would be very handy.  (And
simple to write.)

As for prematurely marking packages as successfully installed...

This:

    cat > $cfg <<!
    ...
    exec /bin/contrib/pull $name

should probably be replaced with something like:

    cat > $cfg.part <<!
    ...
    /bin/contrib/pull $name
    if(~ -$status -) mv $cfg.part $cfg
    if not {
        echo install failed >[1=2]
        rm $cfg.part
        exit 'oh, crap'
    }

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] contrib(1) WAS: Re: wiki...

[erik quanstrom]

> should probably be replaced with something like:
>
>     cat > $cfg.part <<!
>     ...
>     /bin/contrib/pull $name
>     if(~ -$status -) mv $cfg.part $cfg
>     if not {
>         echo install failed >[1=2]
>         rm $cfg.part
>         exit 'oh, crap'
>     }

why don't you email the author directly?

- erik

Re: [9fans] contrib(1) WAS: Re: wiki...

[smiley]

erik quanstrom <quanstro@quanstro.net> writes:

>> should probably be replaced with something like:
>>
>>     cat > $cfg.part <<!
>>     ...
>>     /bin/contrib/pull $name
>>     if(~ -$status -) mv $cfg.part $cfg
>>     if not {
>>         echo install failed >[1=2]
>>         rm $cfg.part
>>         exit 'oh, crap'
>>     }
>
> why don't you email the author directly?

Because I have no idea who the maintainer is or how to contact them.  (I
was hoping they would see my post.)  All I know is that the author is
"fgb" on sources.

$ finger fgb@sources.cs.bell-labs.com
[sources.cs.bell-labs.com]
finger: connect: Connection refused

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] contrib(1) WAS: Re: wiki...

[Federico G. Benavento]

I'm still alive, do you have a patch?

On Sun, Apr 24, 2011 at 5:52 PM,  <smiley@zenzebra.mv.com> wrote:
> erik quanstrom <quanstro@quanstro.net> writes:
>
>>> should probably be replaced with something like:
>>>
>>>     cat > $cfg.part <<!
>>>     ...
>>>     /bin/contrib/pull $name
>>>     if(~ -$status -) mv $cfg.part $cfg
>>>     if not {
>>>         echo install failed >[1=2]
>>>         rm $cfg.part
>>>         exit 'oh, crap'
>>>     }
>>
>> why don't you email the author directly?
>
> Because I have no idea who the maintainer is or how to contact them.  (I
> was hoping they would see my post.)  All I know is that the author is
> "fgb" on sources.
>
> $ finger fgb@sources.cs.bell-labs.com
> [sources.cs.bell-labs.com]
> finger: connect: Connection refused
>
> --
> +---------------------------------------------------------------+
> |E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
> |Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
> +---------------------------------------------------------------+
>
>



-- 
Federico G. Benavento

Re: [9fans] contrib(1) WAS: Re: wiki...

[smiley]

"Federico G. Benavento" <benavento@gmail.com> writes:

> I'm still alive, do you have a patch?

Aye.

7c7
<       echo $*
---
>       echo $* >[2=1]
69c69
< cat > $cfg <<!
---
> cat > $cfg.part <<!
95c95
<       exec /n/sources/contrib/fgb/root/rc/bin/contrib/pull $name
---
>       prog=/n/sources/contrib/fgb/root/rc/bin/contrib/pull
97c97,102
<       exec /bin/contrib/pull $name
---
>       prog=/bin/contrib/pull
> if($prog $name) mv $cfg.part $cfg
> if not {
>       rm $cfg.part
>       fatal contrib/pull failed
> }

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] contrib(1) WAS: Re: wiki...

[erik quanstrom]

> 7c7
> <       echo $*
> ---
> >       echo $* >[2=1]

if you want stderr, this should be

	echo $* >[1=2]

- erik

Re: [9fans] contrib(1) WAS: Re: wiki...

[smiley]

erik quanstrom <quanstro@quanstro.net> writes:

>> 7c7
>> <       echo $*
>> ---
>> >       echo $* >[2=1]
>
> if you want stderr, this should be
>
> 	echo $* >[1=2]

Yes, you are right, I got fd 1 and fd 2 backwards.

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+

Re: [9fans] contrib(1) WAS: Re: wiki...

[Iruatã Souza]

On Sun, Apr 24, 2011 at 11:11 AM,  <smiley@zenzebra.mv.com> wrote:
> erik quanstrom <quanstro@quanstro.net> writes:
>
>>> IIRC it's based on replica(1)
>>> which rather requires ideal circumstances for correct behaviour.
>>
>> partial installs are easy to recover from.  i just used it friday to sort
>> out a file system that had a contrib package listed as installed, but it
>> hadn't been.
>
> It *would* be easy if contrib(1) properly indicated the install status
> of a package.  As it is right now, contrib/install marks a package as
> installed and THEN goes about installing it.  If anything fails, the
> install will still be marked as having been successful.  A subsequent
> contrib/install for the same package will snubly claim that the package
> has already been installed and refuse to run.  You have to supply the
> '-f' switch to make the install complete.  However, doing this requires
> (1) knowing that the install broke, and (2) that all the packages
> dependencies have been met (because -f also overrides dependency
> checking).  contrib(1) doesn't provide any way to check if a package is
> up to date, like replica/changes.  Having a contrib(1) wrapper for
> replica/changes (say, 'contrib/changes') would be very handy.  (And
> simple to write.)
>
> As for prematurely marking packages as successfully installed...
>
> This:
>
>    cat > $cfg <<!
>    ...
>    exec /bin/contrib/pull $name
>
> should probably be replaced with something like:
>
>    cat > $cfg.part <<!
>    ...
>    /bin/contrib/pull $name
>    if(~ -$status -) mv $cfg.part $cfg
>    if not {
>        echo install failed >[1=2]
>        rm $cfg.part
>        exit 'oh, crap'
>    }
>
> --

you've done all the research, why don't you send a patch?

Re: [9fans] contrib(1) WAS: Re: wiki...

[Yaroslav]

Doesn't contrib/pull complete an unfinished installation?

2011/4/24  <smiley@zenzebra.mv.com>:
> erik quanstrom <quanstro@quanstro.net> writes:
>
>>> IIRC it's based on replica(1)
>>> which rather requires ideal circumstances for correct behaviour.
>>
>> partial installs are easy to recover from.  i just used it friday to sort
>> out a file system that had a contrib package listed as installed, but it
>> hadn't been.
>
> It *would* be easy if contrib(1) properly indicated the install status
> of a package.  As it is right now, contrib/install marks a package as
> installed and THEN goes about installing it.  If anything fails, the
> install will still be marked as having been successful.  A subsequent
> contrib/install for the same package will snubly claim that the package
> has already been installed and refuse to run.  You have to supply the
> '-f' switch to make the install complete.  However, doing this requires
> (1) knowing that the install broke, and (2) that all the packages
> dependencies have been met (because -f also overrides dependency
> checking).  contrib(1) doesn't provide any way to check if a package is
> up to date, like replica/changes.  Having a contrib(1) wrapper for
> replica/changes (say, 'contrib/changes') would be very handy.  (And
> simple to write.)
>
> As for prematurely marking packages as successfully installed...
>
> This:
>
>    cat > $cfg <<!
>    ...
>    exec /bin/contrib/pull $name
>
> should probably be replaced with something like:
>
>    cat > $cfg.part <<!
>    ...
>    /bin/contrib/pull $name
>    if(~ -$status -) mv $cfg.part $cfg
>    if not {
>        echo install failed >[1=2]
>        rm $cfg.part
>        exit 'oh, crap'
>    }
>
> --
> +---------------------------------------------------------------+
> |E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
> |Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
> +---------------------------------------------------------------+
>
>



-- 
- Yaroslav

Re: [9fans] wiki...

[erik quanstrom]

> When I try this, I am able to pull up the wiki pages.  But I only have
> about 60 seconds to get in, make my changes, and Put them.  If I take
> any longer than that, I get all sorts of "hangup" errors.  I have to
> close out the Wiki windows, 9fs and Wiki back in, and try again to make
> the changes faster.  Guess the fids go stale or something.  It'd be nice
> to know why the wiki drops out so quickly, though.

i can confirm this problem.

- erik

Re: [9fans] wiki...

[Richard Miller]

> Say, where is the canonical community bug
> tracker for Plan 9, anyway?

mailto://9trouble@plan9.bell-labs.com