> aux/vga: vgactlw: : unknown vmware id 0740
It was picking up the wrong pci device - 15AD/0740 is a "virtual machine
communication interface", not the virtual vga controller.
Fixed by new version of /sys/src/9/pc/vgavmware.c now on sources.
I don't have the slightest clue what you mean, and tbh. I'm not that
interested ;)
Thanks Richard.
>>Â Â aux/vga: vgactlw: : unknown vmware id 0740
>
> It was picking up the wrong pci device - 15AD/0740 is a "virtual machine
> communication interface", not the virtual vga controller.
>
> Fixed by new version of /sys/src/9/pc/vgavmware.c now on sources.
>
>
>
--
Rodolfo Garc
> also, i just looked at Mg. i'm not sure why i would do 'Mg foo bar
> baz' when i can do grep '(foo|bar|baz)'
I started off wanting to do "Mg foo bar baz". It was sort of a happy
implementation accident that foo et al get to be regexps. "Mg foo
bar baz" is easier to type when they're simple strin
I see linux code doing SSE instructions. Has anyone started SSE support
for plan9 kernel yet? Will the AMD64 port contain SSE support?
--
cinap
the amd64 compiler uses only SSE.
i thought about putting it in 8[acl] and might
have asked about that here, but i think i concluded
at the time that 64-bit would appear on all boards.
for 32-bit i wouldn't bother trying to mix the 387 and SSE,
so there would be two 386 environments, old and new,
i don't want to hear anyone complain about the plan9 gui anymore, lest
they be cast into the world of LoseThos:
http://www.losethos.com/
from the website:
"The LoseThos IBM PC Operating System
x86_64, open source, free, public domain
[...]
PROMISES:
1) LoseThos will always run everything in kern
We just need some rounded edges.
http://www.creativeandlive.com/article_images//1073/siggi.jpg
On Wed, Nov 19, 2008 at 10:40 AM, andrey mirtchovski
<[EMAIL PROTECTED]> wrote:
> i don't want to hear anyone complain about the plan9 gui anymore, lest
> they be cast into the world of LoseThos:
>
>
Hi Guys,
I was rereading selected places of Rob's "Getting Dot-Dot Right"
paper and it suddenly occurred to me that the example he provides
there is something that I have always wanted to have. Here it is:
% cat /proc/125099/ns
.
mount -c /net/il/134/data /mnt/term
cd /usr
Oops! Hopefully as list moderator you will accept my apologies
for having drawn out a discussion beyond its useful time!!
You have misread my tone--it was suggestive, not assertive. Note that it
was I who raised a question, and then it was I who felt the question was
(more than) adequately an
Thanks a lot, Nathaniel Filardo. Your clean and detailed explanation is
very much appreciated. Although, Micah Stetson did post a similar, albeit
far more concise, explanation before.
Despite the impression I seem to have made, I understand--as of a few days
ago, at least--why a Plan 9 gateway
On Wed, Nov 19, 2008 at 11:40 AM, andrey mirtchovski
<[EMAIL PROTECTED]> wrote:
> i don't want to hear anyone complain about the plan9 gui anymore, lest
> they be cast into the world of LoseThos:
>
> http://www.losethos.com/
That is amazing.
--
Tom Lieber
http://AllTom.com/
I always thought 8 1/2, rio, acme and friends were more, uh, Amish UIs
than ugly UIs, but to each his or her own.
-J
The point is that you need a way for the chan to know how to reach the
file server.
At some point, IIRC, in 2nd ed. Plan B, the plan b kernel tried to maintain
the name (address) of the server for each chan and the relative path for the
file in the server.
Also, for some servers (eg. tarfs), you ne
I don't think that there is a darn thing wrong with rio, its the Audi of GUIs
On Wed, Nov 19, 2008 at 10:13 PM, Jack Johnson <[EMAIL PROTECTED]> wrote:
> I always thought 8 1/2, rio, acme and friends were more, uh, Amish UIs
> than ugly UIs, but to each his or her own.
>
> -J
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In regard to the GUI itself, it's an interesting concept. THe only
thing uglier is if it was all text.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkkkch8ACgkQuv7AVNQDs+zp7ACeJPraZQbqbzPqfnYwOoZk+six
PAwAn1iyDx7DTz1M1
Nevertheless, the same machinations that allow for transparency in
Plan 9 disallow certain functions that can be naturally provided by
a NAT implementation, or any of a number of software categories that
involve packet filtering/rewriting/inspection. For example, the one
I referred to in
d00dz, you're getting too caught-up in this whole gui thing and
failing to see the forest for the tree. take a look around on that
site. watch one or two of the demo videos, check the documentation
out...
i guarantee you, you've never seen anything like this before (except
for the part where grep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 19, 2008, at 3:25 PM, andrey mirtchovski wrote:
i guarantee you, you've never seen anything like this before (except
for the part where grep outputs direct line addresses which can
immediately be plumbed into the editor)
lol
I did mention
this brings up another question of mine, how can I install Plan B?
On Tue, Nov 18, 2008 at 9:13 PM, Federico G. Benavento
<[EMAIL PROTECTED]>wrote:
> I'd also check lucio's contrib which some stuff in
> /n/sources/contrib/lucio/sys and
> some .tgz which includes binaries in /n/sources/contrib/luc
You have to copy the discrib on top of a plan 9 one,
then configure it. In fact, I'm not sure, but there might be a full
distribution on our web page.
There are detailed manual pages (and I think there were more
detailed instructions on this list time ago). See intro and booting, IIRC.
If this is
I wouldn't go so far as to say Plan 9 "disallows" certain functions that
are implicit in NAT. As someone mentioned in the thread before, it is
certainly possible and rather easy to write something similar to
trampoline(8) to perform load balancing. Add in packet analysis to the
mix and you have ra
Can you really track fedex packages with plan b?
>Anybody have the latest hugs port?
>I looked through some changelog from andrey port to the latest Sept2006.
>There doesnt seem to be much of an update that I actually need, but I
>wanted to ask incase I decide to update andreys port.
>As an update I ported the vscm a R4RS bytecode scheme/lisp.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Take a look at this:
http://www.blazebyte.org/gnextop/
It runs a complete Linux system in a web browser, so users of the
PlayStation Portable can finally write software for it without fear of
being bricked by Sony's anti-piracy measures.
Can P
On Wed, 2008-11-19 at 20:36 +0100, Francisco J Ballesteros wrote:
> The point is that you need a way for the chan to know how to reach the
> file server.
That is a larger point here, indeed. However, my question was a simpler
one: is there any reason to show '#s/sutff' at all? Could I ever be
inte
> Ok, I can understand why devproc.c does it: it is easy to discover the
> name of the actual Chan if you know the node in /srv:
>fd = open("#s/stuff", OREAD);
>fd2chan(fd, buf, sizeof(buf));
>close(fd);
> but not the other way around. Buit why ns(1) doesn't have the above
> code?
i as
On Thu, Nov 6, 2008 at 2:53 AM, ron minnich <[EMAIL PROTECTED]> wrote:
> Just booted Plan 9 on a 1024+16 node BG/P this week. .
>
> All credit to jmk, ericvh, and charles for this fantastic test run and
> the existence of this new kernel.
What new kernel?
> Plan is to double it just a few times u
> Now, suppose IC goes to listen on TCP:80, by opening /net.alt/tcp/clone.
> The same flow of events happen, and to a certain extent, G's network stack
> thinks that the exportfs program (running on G) is listening on TCP:80.
> exportfs dutifully copies the /net data back to its client.
great post
On 11/19/08 17:41, erik quanstrom wrote:
Ok, I can understand why devproc.c does it: it is easy to discover the
name of the actual Chan if you know the node in /srv:
fd = open("#s/stuff", OREAD);
fd2chan(fd, buf, sizeof(buf));
close(fd);
but not the other way around. Buit why ns(1) doesn
>> i think the answer to your question is that it's a lot more useful
>> to know that it's #s/boot rather than /net/il/0/data.
> Really? Why? With /net/il/0/data you have an option of digging deeper and
> finding out the other end's address, etc. Or to flip the question -- what
> information does
On Nov 19, 2008, at 6:55 PM, erik quanstrom wrote:
i think the answer to your question is that it's a lot more useful
to know that it's #s/boot rather than /net/il/0/data.
Really? Why? With /net/il/0/data you have an option of digging
deeper and
finding out the other end's address, etc. Or to f
> Sure it can:
> % srv tcp!sources.cs.bell-labs.com!9fs test
> % ls /net/tcp
> /net/tcp/0
> /net/tcp/1
> /net/tcp/2
> /net/tcp/clone
> % mount -n /net/tcp/2/data /n/test
> %
; mount /net/il/0/data /n/x
mount: mount /n/x: version conversion
On Nov 19, 2008, at 7:32 PM, erik quanstrom wrote:
Sure it can:
% srv tcp!sources.cs.bell-labs.com!9fs test
% ls /net/tcp
/net/tcp/0
/net/tcp/1
/net/tcp/2
/net/tcp/clone
% mount -n /net/tcp/2/data /n/test
%
; mount /net/il/0/data /n/x
mount: mount /n/x: version c
> On Nov 19, 2008, at 7:32 PM, erik quanstrom wrote:
> >> Sure it can:
> >> % srv tcp!sources.cs.bell-labs.com!9fs test
> >> % ls /net/tcp
> >> /net/tcp/0
> >> /net/tcp/1
> >> /net/tcp/2
> >> /net/tcp/clone
> >> % mount -n /net/tcp/2/data /n/test
> >> %
> >
> > ; mou
> Perhaps my choice of wording wasn't exactly correct. Make it "does not
> function in this capacity unless modified." But there's a missed point: add
> in packet analysis and you're doing NAT. The boasted transparency of Plan 9
> is a product of bringing most (or really all?) functions, includi
On Nov 19, 2008, at 8:14 PM, erik quanstrom wrote:
On Nov 19, 2008, at 7:32 PM, erik quanstrom wrote:
Sure it can:
% srv tcp!sources.cs.bell-labs.com!9fs test
% ls /net/tcp
/net/tcp/0
/net/tcp/1
/net/tcp/2
/net/tcp/clone
% mount -n /net/tcp/2/data /n/test
%
; mount /net
On 11/20/08, Juan M. Méndez <[EMAIL PROTECTED]> wrote:
>
>
>>Anybody have the latest hugs port?
>>I looked through some changelog from andrey port to the latest Sept2006.
>>There doesnt seem to be much of an update that I actually need, but I
>>wanted to ask incase I decide to update andreys port.
> This is not the kind of system that comes with instructions.
> I started fumbling around something like this:
> term% tar xvzf alef.tgz
> term% cd sys/src
> term% ls
> term% cd alef
> term% ls
> term% mk all
>
> and you can see it goes wrong. Welcome to Adventure!
If you want a working version
On 11/6/08, ron minnich <[EMAIL PROTECTED]> wrote:
> Just booted Plan 9 on a 1024+16 node BG/P this week. .
>
> All credit to jmk, ericvh, and charles for this fantastic test run and
> the existence of this new kernel.
>
> Plan is to double it just a few times until we hit 65536 or so. Then
> the f
So how to think about it? First, it's *not* NAT, because
there's no address translation going on.
I know. I understood this after the discussions of the past few days.
What I pointed out to Anant Narayanan was that his proposed _new_
capability which involved _packet analysis_ would _have to
41 matches
Mail list logo
