[9fans] Plan 9 != Inferno... right?

[9fans] Plan 9 != Inferno... right?

[Tod Beardsley]

Hi 9fans --

I'm just about ready to take the plunge (again) into Plan 9 for file
serving in my home network, partly because fossil seems like a
superior file system for lots of reads, rare writes, and cheap disks
(mp3 jukebox), and partly because I've had a quasi-mystical
fascination with Plan 9 for several years, but never made the move.

So, over the last few days, I've been consuming all I can on the
current direction and development of Plan 9. Along the way, I've
started to get the impression that Inferno is perhaps a better way to
go for a newbie like me to the whole rio/acme/fossil Way. Is this
mistaken? They don't appear to be the same thing, and searching the
last six months of archives show that there isn't a lot of Inferno
talk here. But they do appear very closely related, and there /is/
some level of Limbo talk.

So, if Plan 9 applications are increasingly being written in Limbo,
and Limbo is "more native" on Inferno, should a bare newbie persist
with Plan 9, or should he simply start off with Inferno?

Not tryng to troll, honest. I suspect the answer is, "get used to Plan
9 or Limbo, then make a more informed decision later," since it's
starting to look like the differences are only in the details and new
users aren't likely to notice them early.

--
todb@planb-security.net | ICQ: 335082155 | Note: Due to Google's
privacy policy <http://tinyurl.com/5xbtl> and the United States'
policy on electronic surveillance <http://tinyurl.com/muuyl>,
please do not IM/e-mail me anything you wish to remain secret.

Re: [9fans] Plan 9 != Inferno... right?

[Brian L. Stuart]

> I'm just about ready to take the plunge (again) into Plan 9 for file

Welcome to the pool.  The water's great.

> started to get the impression that Inferno is perhaps a better way to
> go for a newbie like me to the whole rio/acme/fossil Way. Is this
> mistaken?

For rio/acme/fossil, you do want to go Plan 9 and not
Inferno.  Inferno's windowing system isn't rio, but acme
is there.  Unless I'm out of the loop on something,
there isn't a fossil port to Inferno, though I think
there's a venti port.

> They don't appear to be the same thing, and searching the
> last six months of archives show that there isn't a lot of Inferno
> talk here.

That's partly because there's a separate Inferno list.  And
you're right that they're not the same, but are closely
related.  The original Inferno kernel was based on (and
used code from, I think) the Plan 9 kernel that was current
at the time.  So as you might guess there are a lot of
design elements that are common.  But at the same time,
there are a lot of pretty major differences.  I'd say
they're both worth diving into.

BLS

Re: [9fans] Plan 9 != Inferno... right?

[a]

Inferno (and Limbo) has its own mailing list. Talk on those topics
isn't particularly discouraged here, as there's obviously lots of
overlap in both ideas and community, but it mostly lives on
elsewhere.

They're conceptually very similar, and share much of their
implementation. There are important differences, however.
Limbo only really runs within Inferno (which can then run on top
of Plan 9, FreeBSD, Windows, whatever), and you can't run
user-mode C code in Inferno.

If you're looking for rio and fossil in particular, you need to use
Plan 9 (or 9vx). There is an acme for Inferno. If you want
something to fill a semi-traditional server or workstation role,
you probably want Plan 9. If you want a neat application
programming environment, or an environment for embedded
systems, you probably want Inferno. But neither are always
true.

Most of the time i wish the two were more similar. Or maybe
more interchangable.

Re: [9fans] Plan 9 != Inferno... right?

[Roman V. Shaposhnik]

On Thu, 2008-11-20 at 17:55 +0000, Brian L. Stuart wrote:
> That's partly because there's a separate Inferno list.  And
> you're right that they're not the same, but are closely
> related.  The original Inferno kernel was based on (and
> used code from, I think) the Plan 9 kernel that was current
> at the time.

Speaking of which, is Styx just a different name for 9P2000 or
are there still some little differences?

Thanks,
Roman.

Re: [9fans] Plan 9 != Inferno... right?

[Brian L. Stuart]

> Speaking of which, is Styx just a different name for 9P2000 or
> are there still some little differences?

Someone correct me if I'm wrong, but I think it
goes like this.  The original 9P and Styx were
just different enough that they couldn't interoperate.
That was part of the motivation for 9P2000.  So
now it's almost the same as Styx, except for
the Inferno authentication.  So if you're talking
9P2000 to an Inferno machine and the server
doesn't expect authentication, it'll work.

BLS

Re: [9fans] Plan 9 != Inferno... right?

[a]

> So now [9p]'s almost the same as Styx, except for
> the Inferno authentication.

I think a more precise way of saying it is that in 9p2000 and
the new styx, authentication has been moved outside the
protocol proper. styx==9p now; the names are used by
convention to imply the auth method, if any.

Re: [9fans] Plan 9 != Inferno... right?

[Brian L. Stuart]

> I think a more precise way of saying it is that in 9p2000 and
> the new styx, authentication has been moved outside the
> protocol proper. styx==9p now; the names are used by
> convention to imply the auth method, if any.

You're right.  I stand corrected.  For some reason I
had thought that the Tauth message was different,
but I see that in both man pages it just carries
the afid obtained by an exchange not specified by
the protocol.

BLS

Re: [9fans] Plan 9 != Inferno... right?

[Tod Beardsley]

Thanks heaps for your responses. Plan 9 it is then. Expect a lot of
really irritating questions over the next few weeks. :)

On Thu, Nov 20, 2008 at 3:05 PM, Brian L. Stuart <blstuart@bellsouth.net> wrote:
>> I think a more precise way of saying it is that in 9p2000 and
>> the new styx, authentication has been moved outside the
>> protocol proper. styx==9p now; the names are used by
>> convention to imply the auth method, if any.
>
> You're right.  I stand corrected.  For some reason I
> had thought that the Tauth message was different,
> but I see that in both man pages it just carries
> the afid obtained by an exchange not specified by
> the protocol.
>
> BLS
>
>
>
>



--
todb@planb-security.net | ICQ: 335082155 | Note: Due to Google's
privacy policy <http://tinyurl.com/5xbtl> and the United States'
policy on electronic surveillance <http://tinyurl.com/muuyl>,
please do not IM/e-mail me anything you wish to remain secret.

Re: [9fans] Plan 9 != Inferno... right?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Thu, Nov 20, 2008 at 2:54 PM, Tod Beardsley <todb@planb-security.net>wrote:

> Thanks heaps for your responses. Plan 9 it is then. Expect a lot of
> really irritating questions over the next few weeks. :)
>

Often times, googling to find the answer to irritating questions can keep
repetitive traffic down... however then we'd just bitch and moan about
linux, the fact that no one contributes anything, or doesn't share source
for stuff... so why not just ask the questions again?  This list is good on
the re-runs of everything else :-)

Dave


>
> On Thu, Nov 20, 2008 at 3:05 PM, Brian L. Stuart <blstuart@bellsouth.net>
> wrote:
> >> I think a more precise way of saying it is that in 9p2000 and
> >> the new styx, authentication has been moved outside the
> >> protocol proper. styx==9p now; the names are used by
> >> convention to imply the auth method, if any.
> >
> > You're right.  I stand corrected.  For some reason I
> > had thought that the Tauth message was different,
> > but I see that in both man pages it just carries
> > the afid obtained by an exchange not specified by
> > the protocol.
> >
> > BLS
> >
> >
> >
> >
>
>
>
> --
> todb@planb-security.net | ICQ: 335082155 | Note: Due to Google's
> privacy policy <http://tinyurl.com/5xbtl> and the United States'
> policy on electronic surveillance <http://tinyurl.com/muuyl>,
> please do not IM/e-mail me anything you wish to remain secret.
>
>

[-- Attachment #2: Type: text/html, Size: 2351 bytes --]