from wikipedia:
"Plan 9 from Bell Labs is a distributed operating system, primarily
used for research."
but it doesnt say anything more about the distributed part.
I have recently found a big interest in concurrency, distributed
systems and multicore-programming.
So is Plan 9 good for a multicor
On Mon, Jul 14, 2008 at 4:45 PM, ssecorp <[EMAIL PROTECTED]> wrote:
> from wikipedia:
> "Plan 9 from Bell Labs is a distributed operating system, primarily
> used for research."
>
> but it doesnt say anything more about the distributed part.
>
> In what way does it make it easy?
Plan 9 makes it e
In addition to sqweek's good reply:
The "distributed" part also refers to how a typical installation is
structured. The system responsible for authenticating you, your
file server, the cpu server you run processes on, and the terminal
you're typing at may well all be distinct computers, but for the
> erik quanstrom wrote:
>>> I'm serving drives to WinXP64 via AOE with http://winaoe.org/
i've been ignoring this driver. i'm worthless at windows.
(it's the small blessings, right?) but now that i've taken
a look, i naively wonder about some things.
i think i see why syscalls take so long when
Hi,
Doing some fiddling around, I wrote a simple 9p server to answer
the Tversion message with an Rversion or Rerror. The thing is,
once the *version comm is done, I terminate the server. At this
point, the 9p driver seems not to clean up resulting in the modules
having an increasing number of re
On Mon, Jul 14, 2008 at 1:45 AM, ssecorp <[EMAIL PROTECTED]> wrote:
> from wikipedia:
> "Plan 9 from Bell Labs is a distributed operating system, primarily
> used for research."
>
> but it doesnt say anything more about the distributed part.
>
> I have recently found a big interest in concurrency,
> If libthread is able to grab real processors per thread and get them
> scheduled, one's concurrent style code ultimately ends up having potential
> to run in parallel on those cores/processors.
due to the specific meaning of "thread" in the thread
library, this statement is misleading.
only pro
On 7/14/08, sqweek <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 14, 2008 at 4:45 PM, ssecorp <[EMAIL PROTECTED]> wrote:
> > from wikipedia:
> > "Plan 9 from Bell Labs is a distributed operating system, primarily
> > used for research."
> >
> > but it doesnt say anything more about the distributed
> $ ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches
> non-TLS reference in vxa/zlib/ezlib.vo
> /lib/libc.so.6: could not read symbols: Bad value
> make: *** [vxa/zlib/ezlib] Error 1
> $
Install the cross compilers and change the top-level Makefrag
to use vx32-gcc and vx32-ld.
file(1):
BUGS
It can make mistakes.
thanks for playing.
russ
On Mon, 2008-07-14 at 17:08 +0800, sqweek wrote:
> On Mon, Jul 14, 2008 at 4:45 PM, ssecorp <[EMAIL PROTECTED]> wrote:
> > from wikipedia:
> > "Plan 9 from Bell Labs is a distributed operating system, primarily
> > used for research."
> >
> > but it doesnt say anything more about the distributed pa
> I have a problem with one specific e-mail in p9p acme Mail: only some
> part of it is displayed (~1/2) when I open it (right click) in acme
> Mail. According to mutt, the encoding is iso-8859-15 and I can read it
> fine there.
> There does not seem to be anything special in the first line which i
On Mon, 2008-07-14 at 08:45 +, ssecorp wrote:
> from wikipedia:
> "Plan 9 from Bell Labs is a distributed operating system, primarily
> used for research."
>
> but it doesnt say anything more about the distributed part.
>
> I have recently found a big interest in concurrency, distributed
> sy
> Hello. Regarding my previous question, the file /n/sources/contrib/
> pietro/xd.out shows a bug in xd regarding characters that can't be
> printed with the %c format. There should be no space between a non-
> printing and a printing character; but the two spaces screw the rest
> of the line
> > Plan 9 makes it easy via 9p, its file system/resource sharing
> > protocol. In plan 9, things like graphics and network drivers export a
> > 9p interface (a filetree). Furthermore, 9p is network transparent
> > which means accesses to remote resources look exactly like accesses to
> > local re
If you look more closely at the alignment of the characters to the hex
values you will see that xd thinks Q has character code 0x525 and R
has character code 3. It should look more like
% xd -c -x bad
000 e0Q R S \n
0 e0515253 0a00
005
On Jul 14, 2008, at 12:43 PM, Russ C
> If you look more closely at the alignment of the characters to the hex
> values you will see that xd thinks Q has character code 0x525 and R
> has character code 3. It should look more like
>
> % xd -c -x bad
> 000 e0Q R S \n
> 0 e0515253 0a00
> 005
-x by itself doesn't
% 9p read mail/mbox/40/raw |grep -i '^content'
Content-Type: text/plain; charset=
Content-Transfer-Encoding: 8bit
Does it mean that the character set is in iso-8859-15 but the sender
of the message somehow set it wrongly in the headers to be iso-8859-1?
Hence mailfs is failing at trying to convert
> If you look more closely at the alignment of the characters to the hex
> values you will see that xd thinks Q has character code 0x525 and R
> has character code 3. It should look more like
>
> % xd -c -x bad
> 000 e0Q R S \n
> 0 e0515253 0a00
> 005
The -c and -x format
one thing that has bugged me in the past: upas relies on file -m to
determine the type of attachments, but file only reads the first block
of the file, so if you've got a utf-8 file with the first non-ascii character
beyond the 8192nd byte, you get corrupted mail.
IMHO for the -m option, file shou
> % 9p read mail/mbox/40/raw |grep -i '^content'
> Content-Type: text/plain; charset=
> Content-Transfer-Encoding: 8bit
>
> Does it mean that the character set is in iso-8859-15 but the sender
> of the message somehow set it wrongly in the headers to be iso-8859-1?
> Hence mailfs is failing at try
Hello,
I have been looking and the implementation of channels/alt in Plan9, and I have
a question. Does lock()/unlock() work across procs (not just threads)? For
example, in channel.c there is a static Lock *channel_lock. Does this provide
exclusive to channel data across procs?
I assume y
On 7/13/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I've added kbin to pcf, so the set of distributed kernels with kbin in
> them is now pc, pccd, pcdisk and pcf.
I noticed, after a pull, that the corresponding binaries haven't been
updated. Just thought I'd mention it, in case they were
un
> one thing that has bugged me in the past: upas relies on file -m to
> determine the type of attachments, but file only reads the first block
> of the file, so if you've got a utf-8 file with the first non-ascii character
> beyond the 8192nd byte, you get corrupted mail.
>
> IMHO for the -m optio
> I have been looking and the implementation of channels/alt in Plan9,
> and I have a question. Does lock()/unlock() work across procs (not
> just threads)? For example, in channel.c there is a static Lock
> *channel_lock. Does this provide exclusive to channel data across
> procs?
>
> I assum
// But do you know of any part [of Plan 9] that would be
// beneficial for highly-SMP systems?
Beneficial compared to what, I guess. I agree with your
comment that most of the pressure is on the application
rather than the kernel. The kernel's biggest contribution here
is keeping processes inexpen
On Mon, 2008-07-14 at 12:35 -0400, erik quanstrom wrote:
> > > Plan 9 makes it easy via 9p, its file system/resource sharing
> > > protocol. In plan 9, things like graphics and network drivers export a
> > > 9p interface (a filetree). Furthermore, 9p is network transparent
> > > which means access
On Mon, 2008-07-14 at 16:08 -0400, [EMAIL PROTECTED] wrote:
> // But do you know of any part [of Plan 9] that would be
> // beneficial for highly-SMP systems?
>
> Beneficial compared to what, I guess.
Lets say a typical Linux kernel.
> The kernel's biggest contribution here is keeping processes
> // But do you know of any part [of Plan 9] that would be
> // beneficial for highly-SMP systems?
one difference from many of the others is that plan 9, both kernel and
applications,
were written with multiprocessors in mind, at least up to 32 or so, so data
structure
locking was included as th
> I have been looking and the implementation of channels/alt in Plan9,
> and I have a question. Does lock()/unlock() work across procs (not just
> threads)? For example, in channel.c there is a static Lock *channel_lock.
> Does this provide exclusive to channel data across procs?
Yes: Locks are
> locks are not necessary between threads in the same proc
> because only one of them can run at a time and they are
> cooperatively scheduled.
It is important to note that using cooperatively scheduled threads
doesn't automatically mean you don't need locking. If your
threads can go to sleep wit
On Jul 14, 2008, at 1:13 PM, erik quanstrom wrote:
-x by itself doesn't output the hex codes
for bytes, it outputs the hex codes for 4 byte
integers. i think you're thinking of this command
line instead
; xd -c -1x bad
000 e0 Q R S \n
0 e0 51 52 53 0a
On Jul 14, 2008, at 1:22 P
// Not just inexpensive, but also better aligned with how
// they use compute resources (virtual vs. physical threads)
// and memory resources.
Hrm. I know about the memory/cache issues, but it sounds
like there's more on the CPU side I don't know much about.
Is there more here beyond the memory q
On Mon, Jul 14, 2008 at 4:33 PM, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote:
> the day. I don't think that Plan9 scheduler has had an
> opportunity to be tuned for such an environment. Same goes for
> virtual memory page related algorithms.
The scheduling code does have a heuristic for processo
34 matches
Mail list logo
