On Fri, Jul 18, 2008 at 1:45 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> On Jul 17, 2008, at 8:28 PM, erik quanstrom wrote:
>> i suppose you could also type
>
> ctl+m
interestingly this only works in some versions of acme and sam.
it seems to work ok under plan 9, and in inferno's acme,
but
very, very cool. thanks for the link, ron.
i wonder if richard feynman (who is mentioned) might
have criticized the ops/s vs. time graph on p. 5 for being
overly fit to one end point -- the accounting machines
in the lower left?
has anyone continued this graph to more recent times?
- erik
> interestingly this only works in some versions of acme and sam.
> it seems to work ok under plan 9, and in inferno's acme,
> but not in p9p or acme sac.
There are two different issues here. One is getting
an actual \r to the program in question (acme, sam, etc.)
and the second is how that progr
On Fri, Jul 18, 2008 at 4:49 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> very, very cool. thanks for the link, ron.
>
> i wonder if richard feynman (who is mentioned) might
> have criticized the ops/s vs. time graph on p. 5 for being
> overly fit to one end point -- the accounting machines
> i
A little while back Russ suggested that someone might
want to look into making 9vx boot using a native
fossil/venti file system partition for root. For
anyone who's interested, as of this morning, that
is working. It's a little kludgy in places, but
mostly it's not too bad. When I've cleaned it
> - 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
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 mentio
Hello all,
I proposed a patch which turns off hw acceleration for vga if you boot
in VMware.
But now I find out that it is necessary to do the same in installation tree.
So, if anybody can, please, correct this file /386/bin/aux/vmware on
installation CD (add 1 line):
#!/bin/rc
if(aux/isvmware -
>> 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 i
On Fri, Jul 18, 2008 at 1:20 PM, erik quanstrom <[EMAIL PROTECTED]> 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 interne
> 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 wan
> 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
> A little while back Russ suggested that someone might
> want to look into making 9vx boot using a native
> fossil/venti file system partition for root. For
> anyone who's interested, as of this morning, that
> is working. It's a little kludgy in places, but
> mostly it's not too bad. When I've
why can't venti and fossil on the same machine be connected by a pipe?
why can't venti and fossil on the same machine be connected by a pipe?
> why can't venti and fossil on the same machine be connected by a pipe?
That would be far too logical.
Sape
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
> > - boot/boot did bad things if the localroot
> > wasn't set, so when using boot/boot it's now .
>
> What bad things did it do? The code is supposed
> to cope gracefully with localroot == nil. I'd rather
> fix the code that couldn't cope.
Ah, that means I need to remember. As you get older,
>> 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 lgues
On Fri, Jul 18, 2008 at 6:31 PM, erik quanstrom <[EMAIL PROTECTED]> 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
>> 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 t
21 matches
Mail list logo
