Re: [9fans] 9vx and local file systems

Re: [9fans] 9vx and local file systems

[erik quanstrom]

> - The messiest bit, though, is venti and networking.
> boot/boot figures it needs to set up the loopback
> interface for venti.  But /net/ipifc doesn't exit
> and boot/boot considers this fatal.  I suppose
> the Right Way(tm) to is to implement /net/ipifc
> and have it translate operations to the underlying
> network stack, but that seems an awful lot of
> work, for rather few applications.  The not so
> right way would be to fake it, providing the
> interface, but just pretend all the messages
> succeed.  But I copped out.  I made one change
> to boot/boot.  Now if it fails to open /net/ipifc/clone,
> it's not fatal.

the fact that the networking works differently is
a problem for a number of other applications, too.
dns, snoopy, aoe, cec come immediately to mind
as useful stuff that won't work with 9vx.

my inclination would be to give 9vx a proper
ethernet device, but that idea has been discussed
already.

i just wonder if all the coding around the fact
that the 9vx network is different is going to pay off.

- erik

Re: [9fans] 9vx and local file systems

[Roman V. Shaposhnik]

On Fri, 2008-07-18 at 15:00 -0400, erik quanstrom wrote:
> my inclination would be to give 9vx a proper
> ethernet device, but that idea has been discussed
> already.

I was about to ask this very question (and say THANK YOU
to Russ for another awesome piece of software), but now
that you've mentioned it could you, please, elaborate
on why implementing proper ethernet was rejected?

Thanks,
Roman.

P.S. Either that or just a pointer to the existing
discussion ;-)

Re: [9fans] 9vx and local file systems

[erik quanstrom]

>> my inclination would be to give 9vx a proper
>> ethernet device, but that idea has been discussed
>> already.
>
> I was about to ask this very question (and say THANK YOU
> to Russ for another awesome piece of software), but now
> that you've mentioned it could you, please, elaborate
> on why implementing proper ethernet was rejected?

http://9fans.net/archive/2008/07/310

to paraphrase with my understanding, the feeling is that
9vx will be easier to admin if the host takes care of the
networking, dns, etc.  that makes sense for many applications.

but what i'd really like is a drawterm replacement with its own
local devices.  without local devices, there isn't much of an
advantage over drawterm — unless your cpu server many
ms away.  graphics over the internet can be a bummer.

- erik

Re: [9fans] 9vx and local file systems

[ron minnich]

On Fri, Jul 18, 2008 at 1:20 PM, erik quanstrom <quanstro@coraid.com> wrote:

> but what i'd really like is a drawterm replacement with its own
> local devices.  without local devices, there isn't much of an
> advantage over drawterm — unless your cpu server many
> ms away.  graphics over the internet can be a bummer.
>

Well, I use vx32 as a terminal for both lguest and remote machines. No
real need for venfi/fossil. For edit, I import; to build etc. I cpu in
an acme window so i get the error stuff.

don't really want fossil/venti on vx32 yet, too slow (I tried it some
time last week). But it's a great terminal, much nicer than drawterm
for me.

ron

Re: [9fans] 9vx and local file systems

[Russ Cox]

> but what i'd really like is a drawterm replacement with its own
> local devices.  without local devices, there isn't much of an
> advantage over drawterm — unless your cpu server many
> ms away.  graphics over the internet can be a bummer.

Like I said before, please add the local devices you want.
Just don't make them mandatory.

Russ

Re: [9fans] 9vx and local file systems

[Russ Cox]

> i just wonder if all the coding around the fact
> that the 9vx network is different is going to pay off.

You've spent more time talking about this than
it would have taken to just implement the extra
pieces you want or need, like /net/ipifc and /net/ether.
The low-level OS grunge work is already done thanks
to p9p.  It's just a few lines of code.

Or, if you are so inclined, you can port the entire
existing Plan 9 IP stack.  That's more than just a
few lines of code.

Either way, complaining isn't nearly as effective as doing.

Russ

Re: [9fans] 9vx and local file systems

[Francisco J Ballesteros]

I have used octopus to access my plan 9 system over links
with 150ms of RTT  I admit "graphics" are mostly faces and simple
vector graphics. Considering that for file viewers you copy
the files to a viewer device in the terminal, it all behaves reasonably.

The drawback is that you get very nervous regarding losing your
system due to power outages at the university :)

> advantage over drawterm — unless your cpu server many
> ms away.  graphics over the internet can be a bummer.
>
> - erik
>
>
>

Re: [9fans] 9vx and local file systems

[erik quanstrom]

>> but what i'd really like is a drawterm replacement with its own
>> local devices.  without local devices, there isn't much of an
>> advantage over drawterm — unless your cpu server many
>> ms away.  graphics over the internet can be a bummer.
>>
>
> Well, I use vx32 as a terminal for both lguest and remote machines. No
> real need for venfi/fossil. For edit, I import; to build etc. I cpu in
> an acme window so i get the error stuff.

what's the advantage over drawterm in this configuration?

- erik

Re: [9fans] 9vx and local file systems

[ron minnich]

On Fri, Jul 18, 2008 at 6:31 PM, erik quanstrom <quanstro@quanstro.net> wrote:

> what's the advantage over drawterm in this configuration?
>

latency. The interactive program (e.g. acme) is on my machine, not on
a remote machine. Rio is local. And so on.

ron

Re: [9fans] 9vx and local file systems

[Russ Cox]

>> Well, I use vx32 as a terminal for both lguest and remote machines. No
>> real need for venfi/fossil. For edit, I import; to build etc. I cpu in
>> an acme window so i get the error stuff.
>
> what's the advantage over drawterm in this configuration?

In the case you quote, you'd have many of the advantages
of a standalone Plan 9 terminal, like local handling of graphics
and the mouse, the ability to connect to many machines
simultaneously, the ability to withstand those machines
rebooting, and so on.  It depends a lot on what you're doing.

Here's another example.

For about seven years I had the luxury of running Plan 9
as my day-to-day system, but I couldn't easily keep doing
that and work with the people around me at MIT; around
2003, I gave it up and switched to FreeBSD and Linux.
(You'll note that's when the p9p CVS logs begin.)
I haven't booted an actual Plan 9 terminal in a couple of years.

Since then, I've had the smaller luxury of running Plan 9
as a venti server, now atop some nice hardware we bought
from Coraid.  The Coraid box has a tiny, slow IDE flash disk
for a root file system, fine for holding a few binaries but
not really usable as a general file system.  To build the binaries,
I have a second Plan 9 server with a bigger, faster root disk.
I've used drawterm to connect to it, edit and compile venti,
and submit patches.  As I look forward to finishing at MIT,
I can't leave Plan 9 boxes for others to deal with.  A few months
ago, I converted the main venti server (the Coraid hw) to run
FreeBSD, which is what all our other servers run.  That leaves
the second Plan 9 server, which I still use for the occasional
drawterm session to submit a patch to sources.  But when I
leave MIT, I can't reasonably keep using that machine as my
own personal server.  It'll have to be a group server running
FreeBSD.

The advantage of 9vx over drawterm, for me, is that 9vx
doesn't require a cpu server.

9vx is how I'm going to deal with not having my own
personal Plan 9 cpu server to drawterm into.  Having a local
Plan 9 install, stored right in my non-Plan 9 home directory,
lets me keep using and occasionally contributing to Plan 9
without having to maintain and house a server.
I haven't spent quite enough time setting up a comfortable
9vx that I could stop using drawterm today, but maybe
tomorrow.

Russ

[9fans] (no subject)

[kokamoto]

> The advantage of 9vx over drawterm, for me, is that 9vx
> doesn't require a cpu server.

You are not using Plan 9 anymore then, rather you are using something
similar to Plan 9.

I felt that Plan 9 is abused by 9vx, which I felt at first glance, but
at that time I didn't want to say this...

I prefer drawterm because it stands in the Plan 9 world.

Kenji   --just my opinion--

Re: [9fans] (no subject)

[a]

// You are not using Plan 9 anymore then, rather you are
// using something similar to Plan 9.

I don't think it's that simple. I understand the value of running a
native Plan 9 installation (self-sufficiency is an almost universal
value), but we don't hear the same complaints when we look at
Inferno: stuff built from /emu is just as much "real" Inferno as
stuff built from /os. We don't think of using the other hardware
virtualizers as not being "real" Plan 9, even the ones that take
kernel modifications.

9vx just feels like cheating because it's so much easier.

Anthony

Re: [9fans] 9vx vs drawterm

[Tim Wiess]

>> The advantage of 9vx over drawterm, for me, is that 9vx
>> doesn't require a cpu server.
>
> You are not using Plan 9 anymore then, rather you are using something
> similar to Plan 9.
>
> I felt that Plan 9 is abused by 9vx, which I felt at first glance, but
> at that time I didn't want to say this...
>
> I prefer drawterm because it stands in the Plan 9 world.

While I haven't yet gotten the chance to play with it, personally I
felt 9vx is really a normal P9 terminal, whereas drawterm is not.
Because it doesn't run natively makes no difference.

[9fans] Sam

[Benjamin Huntsman]

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

the 9pm version is still the latest Sam for Windows, right?

Thanks!

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2120 bytes --]