>that avoids the exploding 9vx problem. But we need to get a real fix.
i'm sure i posted the real fix to the list (essentially issuing CLD at specific
points).
i installed u9fs on my linux machine to can use 9p server, and added
lines to /etc/services and to /etc/inetd.conf too and it listens to 564
port as expected, but there is a problem with the authentication, when i
do 9p -a 192.168.1.2 ls /home , i got 9p: mount: u9fs: rhosts
authentication fail
I have, on my linux machine:
/etc/services:
u9fs 564/tcp 9fs
/etc/inetd.conf:
u9fs stream tcp nowait root /home/ruda/bin/u9fs u9fs -a p9any
/etc/u9fs.key: 3 lines:
local
I don't remember if I had to do anything on my plan9 machine.
And it somehow works. But I have neve
one more note:
;ls -l /etc/u9fs.key
lrwxrwxrwx 1 root root 25 2009-07-31 20:30 /etc/u9fs.key ->
/home/ruda/ruzne/u9fs.key
;ls -l /home/ruda/ruzne/u9fs.key
-r 1 root root 20 2009-07-30 15:35 /home/ruda/ruzne/u9fs.key
On 3 September 2010 11:07, Rudolf Sykora wrote:
> I have, on my linux ma
unknown wrote:
i installed u9fs on my linux machine to can use 9p server, and added
lines to /etc/services and to /etc/inetd.conf too and it listens to
564 port as expected, but there is a problem with the authentication,
when i do 9p -a 192.168.1.2 ls /home , i got 9p: mount: u9fs: rhosts
aut
I downloaded Plan9port today, and found thewre is no pipefile.
It's not good to me, because I need ktrans.☺
Is it difficult to implement REGEND for p9p's rfork?
Or anything other difficulties are there for pipefile.c?
Kenji
On Fri, Sep 3, 2010 at 8:21 AM, wrote:
> I downloaded Plan9port today, and found thewre is no pipefile.
> It's not good to me, because I need ktrans.☺
>
> Is it difficult to implement REGEND for p9p's rfork?
> Or anything other difficulties are there for pipefile.c?
I think the main difficulty w
> thanks for this. sleep(1) helped only rarely,
> sleep(10) helps most of the time. unfortunately
> then there's a race between the invoked program
> turning off echo and 9term turning it back on.
> so "sudo sh" is pretty likely to echo the password
> with the sleep in there.
>
> what a mess.
i
You'll also have to include Charles's CLD fix. Regarding sched.c, what
do you call a real fix ?
I mean, this hack just works isn't it ?
Phil;
it's done and available. This tree also includes the hack in sched.c
that avoids the exploding 9vx problem. But we need to get a real fix.
ron
On Fri, Sep 3, 2010 at 1:21 AM, Charles Forsyth wrote:
>>that avoids the exploding 9vx problem. But we need to get a real fix.
>
> i'm sure i posted the real fix to the list (essentially issuing CLD at
> specific points).
>
>
I missed it. If you can point me to it I'll give it a try.
ron
Hello,
I have basically 3 questions:
1) is there a native lbl (for symbolic labels in text documents), or
do I have to grab the unix tarball and somehow compile that? (How?
Using APE? Never tried that before...)
2) I heard and read that the 'ms' troff macros are not suitable for
longer documents
>2) I heard and read that the 'ms' troff macros are not suitable for
>longer documents (I want to write my PhD thesis), as opposed
>supposedly to the 'me' macros (which, however are not in plan9, I
>believe). Can anybody give me their opinion?
i don't see the problem. i've used -ms without fuss on
> 2) I heard and read that the 'ms' troff macros are not
> suitable for
> longer documents (I want to write my PhD thesis), as
> opposed
> supposedly to the 'me' macros (which, however are not in
> plan9, I
> believe). Can anybody give me their opinion?
There should be some macro packages out ther
>There should be some macro packages out there that
>fit particular universities' requirements.
oh. if there were whacky requirements (i think the main one
for me was a now-obsolete requirement for 1.5 spacing) i tweaked
settings as required. it was fairly minor effort (and i don't
typically under
I've recently had the need for a very simple 8086 interpreter,
with which I can do some assembly testing (so it should
allow me to enter the basic opcodes and their operands,
such as MOV AL, 0x21 etc.). I found 8i in contrib/rsc
which seems to have been taken from aki's 8i, but that just
seems lik
I've used bochs to do bios debugging. You have to enable a few things
but you can get an assembly trace.
Another option is qemu with a gdb port set up.
The turnaround on assembling and running is fast enough that you may
not really need an interpreter.
ron
On Fri, Sep 3, 2010 at 3:21 PM, Akshat Kumar
wrote:
> I've recently had the need for a very simple 8086 interpreter,
> with which I can do some assembly testing (so it should
> allow me to enter the basic opcodes and their operands,
> such as MOV AL, 0x21 etc.). I found 8i in contrib/rsc
> which
On Fri, Sep 3, 2010 at 1:36 PM, Russ Cox wrote:
> I wrote 8i. If you keep poking around in contrib/rsc
> you'll also find 86a and 86b which are different variants
> of an 8086 assembler.
Ah, I'm sorry for miscrediting!
I grabbed both 86a and 86b - it seems that some code is
missing from 86a: mai
On Sep 3, 2010, at 11:16 AM, Rudolf Sykora wrote:
3) Although eqn produces worse result than TeX, I like the way
formulae are input, and thus have used it. Sometimes I need bold
italics, which I achieve by overstriking. This isn't ideal, maybe
using a special bold italics font would be better. Ha
I'm working on a audio driver for kw (openrd) as a warmup for other more
useful drivers (do something easy before something hard), and I've come
to the point where to do anything more requires talking to the audio
codec. According to various linux patches, this is done over I²C. Has
anyone done any
By I²C, you mean Immediate Command/Response Interface of HDAudio controller?
Though Immediate Command/Response Interface should work, CORB/RIRB is
the recommended way to send/receive commands/responses from the codec.
If you do use Immediate mode, please refer to the updated HDAudio spec
that cla
On Fri Sep 3 19:09:18 EDT 2010, 9p...@imu.li wrote:
> I'm working on a audio driver for kw (openrd) as a warmup for other more
> useful drivers (do something easy before something hard), and I've come
> to the point where to do anything more requires talking to the audio
> codec. According to vari
> They have the added advantage of the exponent after the I.
>
> Reminds me of the degrees of infinity.
>
> So instead of sucketh-null, I guess they are sucketh-1?
so you're working on a new concurrent language for plan 9?
- erik
On Fri, Sep 3, 2010 at 5:11 PM, erik quanstrom wrote:
> the main thing they have in common is that they both pass
> at least one of ron's "how to tell if a specification sucks" tests.
> :-)
They have the added advantage of the exponent after the I.
Reminds me of the degrees of infinity.
So i
Our university has an iS² project. iS² stands for Innovative Support
Services. The project's goal is to maximize efficiencies. It's used as
the excuse to fire a few support personnel.
hmm. oops. that was supposed to be private.
andrey courtesy of the department of redundancy dept.
> So instead of sucketh-null, I guess they are sucketh-1?
ROFLOL!!!
Glibc /bin/date on Linux runs around 140 system calls. A quick pass
with ratrace shows that plan 9 /bin/date has 10.
The conclusion is clear: plan 9 date has way too much overhead. It's
1/14 the number of system calls of Glibc; why's it so big?
A quick pass on getpid() fixes the problem:
#includ
28 matches
Mail list logo
