On Sat Jul 18 14:41:02 EDT 2009, r...@sun.com wrote:
> In the "mom, why sky is blue" department, here's a silly question:
> is there any good reason that read(2) on a hangup channel returns
> an error, while write(2) on a hangup channel terminates an application
> (by generating a note, of course,
On Sat Jul 18 19:24:31 EDT 2009, ano...@gmail.com wrote:
> inferno's got lighter requirements in some ways, but has
> the same class of CPU requirements (more or less). if you
> have something lighter than that in mind, you might not get
> plan 9 but the ideas could still be useful. ask google abou
inferno's got lighter requirements in some ways, but has
the same class of CPU requirements (more or less). if you
have something lighter than that in mind, you might not get
plan 9 but the ideas could still be useful. ask google about
"styx on a brick" for an example of using styx (9p by
another n
On Saturday 18 July 2009 10:59:20 ron minnich wrote:
> On Sat, Jul 18, 2009 at 9:59 AM, Uriel wrote:
> > So you are on your own, you can take the code (while the site happens
> > to be up, or from a mirror), do whatever you like with it, but that is
> > all there is and all anyone can count on.
>
Phew finally got it. There was some hackery involved in the hg-git
python code since mmap wasn't supported -- i basically just implemented them
with reads; however I was considering writing an mmap module that used reads
but realized that would be misleading since it wasn't really mmap.
On Sat, 18 Jul 2009 10:20:11 PDT Skip Tavakkolian <9...@9netics.com> wrote:
> > Or is there a better idea? This certainly seems preferable
> > to RPC or plain byte pipes for communicating structured
> > values.
>
> i have some incomplete ideas that are tangentially related to this --
> more for
On Sat, Jul 18, 2009 at 1:50 PM, Adriano Verardo wrote:
> Hi, all
>
> Some time go I read about Plan9 on microcontrollers.
>
> Is this an interesting argument for the 9fans community ?
>
> adriano
>
>
The closest you'll come with Plan 9 is the ARM port.
As for microcontrollers like the Atmels, yo
Hi, all
Some time go I read about Plan9 on microcontrollers.
Is this an interesting argument for the 9fans community ?
adriano
Anthony Sorace wrote:
i, at least, would be interested to know more about what
the specific concerns are. that is, is it about availability,
future evolution, commercial support, or something else?
anthony
Mainly availability.
In the past I had some difficulties when I suggested to use FreeB
On Saturday 18 July 2009 12:50:39 Eric Van Hensbergen wrote:
> On Sat, Jul 18, 2009 at 2:37 PM, Corey wrote:
> > On Saturday 18 July 2009 12:29:29 Eric Van Hensbergen wrote:
> >> The secret plan 9 super secret
> >> society fork is yet another evolution, actually primarily motivated by
> >> bitter,
On Sat, Jul 18, 2009 at 3:50 PM, Eric Van Hensbergen wrote:
> On Sat, Jul 18, 2009 at 2:37 PM, Corey wrote:
>> On Saturday 18 July 2009 12:29:29 Eric Van Hensbergen wrote:
>>> The secret plan 9 super secret
>>> society fork is yet another evolution, actually primarily motivated by
>>> bitter, disru
On Sat, Jul 18, 2009 at 2:37 PM, Corey wrote:
> On Saturday 18 July 2009 12:29:29 Eric Van Hensbergen wrote:
>> The secret plan 9 super secret
>> society fork is yet another evolution, actually primarily motivated by
>> bitter, disruptive, and ultimately destructive community members.
>>
>
> Curios
On Saturday 18 July 2009 12:29:29 Eric Van Hensbergen wrote:
> The secret plan 9 super secret
> society fork is yet another evolution, actually primarily motivated by
> bitter, disruptive, and ultimately destructive community members.
>
Curiosity has just got the best of me.
Can you shed a little
On Sat, Jul 18, 2009 at 1:52 PM, Bakul Shah wrote:
>
> I should've mentioned this won't run on top of plan9 (or
> Unix). What I really want is alt! I brought up RPC but
> really, this is just Limbo's "chan of " idea. In the
> concurrent application where I want to use this, it would
> factor out
On Sat, Jul 18, 2009 at 9:59 AM, Uriel wrote:
>
>> Plan 9 is *not* an open source project
>
I once attended a talk where a statement was made about open source
projects being defined by their ability to fork in non-destructive
manners as a sort of evolutionary response. Plan 9's source code is
av
dorin bumbu wrote:
There are thousands of devices shipped with Microsoft Windows CE prior
to version 4 (.NET). For these devices MS never offered patches even
if these versions had lots of bugs, nor even standard C libraries
(thank God there is wcecompat). And there are lot of projects that
reach
On Sat, 18 Jul 2009 06:25:19 EDT erik quanstrom wrote:
> On Sat Jul 18 03:46:01 EDT 2009, bakul+pl...@bitblocks.com wrote:
> > Has anyone extended the idea of channels where the
> > sender/receiver are on different machines (or at least in
> > different processes)? A netcat equivalent for channe
On Sat, Jul 18, 2009 at 2:35 PM, dorin bumbu wrote:
> There are thousands of devices shipped with Microsoft Windows CE prior
> to version 4 (.NET). For these devices MS never offered patches even
> if these versions had lots of bugs, nor even standard C libraries
> (thank God there is wcecompat). A
In the "mom, why sky is blue" department, here's a silly question:
is there any good reason that read(2) on a hangup channel returns
an error, while write(2) on a hangup channel terminates an application
(by generating a note, of course, which can be ignored, but still)?
Thanks,
Roman.
P.S. And b
There are thousands of devices shipped with Microsoft Windows CE prior
to version 4 (.NET). For these devices MS never offered patches even
if these versions had lots of bugs, nor even standard C libraries
(thank God there is wcecompat). And there are lot of projects that
reached 10+ years (with wo
On Sat, Jul 18, 2009 at 9:59 AM, Uriel wrote:
> Plan 9 is *not* an open source project, it can hardly be called a
> project even: There is no release management, there is no development
> process, there is no way to know what anyone is working on, no way to
> have any idea of what changes and feat
On Sat, Jul 18, 2009 at 1:20 PM, Skip Tavakkolian<9...@9netics.com> wrote:
>> Or is there a better idea? This certainly seems preferable
>> to RPC or plain byte pipes for communicating structured
>> values.
>
> i have some incomplete ideas that are tangentially related to this --
> more for handli
> Or is there a better idea? This certainly seems preferable
> to RPC or plain byte pipes for communicating structured
> values.
i have some incomplete ideas that are tangentially related to this --
more for handling interfaces.
it seems one could write a compiler that translates an interface
de
> On Sat, Jul 18, 2009 at 4:38 AM, Akshat
> Kumar wrote:
> > The idea seems inviting at first, but have you
> > given a thought to using plumber(4) for
> > "interprocess messaging" (which is what you
> > want, from what I understand)? This seems
> > more appropriate for communication amongst
> > pr
On Sat, Jul 18, 2009 at 6:25 PM, Anthony Sorace wrote:
> Plan 9 is an open source project
The Plan 9 code base (at least the released parts of it) is open source.
Plan 9 is *not* an open source project, it can hardly be called a
project even: There is no release management, there is no developmen
On Sat, Jul 18, 2009 at 4:38 AM, Akshat
Kumar wrote:
> The idea seems inviting at first, but have you
> given a thought to using plumber(4) for
> "interprocess messaging" (which is what you
> want, from what I understand)? This seems
> more appropriate for communication amongst
> processes alien to
> As a professional user I think that Plan9 could be better than *nix for a
> large class of industrial - not time critical - applications but in
> Italy nobody use it, except of no more than a dozen of fans. The University
> doesn't
> know it at all. Of course, this is what I see. I would be h
Plan 9 is an open source project; as such, you get at least
the same baseline "guarantees" about its longevity as every
open source project enjoys: as long as someone's interested,
work can continue.
there are still Bell Labs staff who work on Plan 9, although i
don't believe they're working on it
> without
> guarantees about
> its longevity, it could be a wrong choice.
>
> How can I reply to this objection ?
i think for most companies the issues are (a) lack of people with
skills to build and maintain plan9 systems and (b) most IT departments
are used to -- and seek -- point solutions th
Hi all,
As a professional user I think that Plan9 could be better than *nix for a
large class of industrial - not time critical - applications but in
Italy nobody
use it, except of no more than a dozen of fans. The University doesn't
know it at all.
Of course, this is what I see. I would be ha
> inferno's file2chan is local too, just giving a simple interface to
> handling plain reads & writes on a file. unless i've been using it
> wrong.
i assume that import and srv could be used to export a fd?
- erik
On Sat, Jul 18, 2009 at 06:25:19AM -0400, erik quanstrom wrote:
> i think the general idea is that if you want to do this between
> arbitrary machines, you provide a 9p interface. you can think
> of 9p as a channel with a predefined set of messages. acme
> does this. kernel devices do this.
>
On Sat Jul 18 03:46:01 EDT 2009, bakul+pl...@bitblocks.com wrote:
> Has anyone extended the idea of channels where the
> sender/receiver are on different machines (or at least in
> different processes)? A netcat equivalent for channels!
i think the general idea is that if you want to do this betw
The idea seems inviting at first, but have you
given a thought to using plumber(4) for
"interprocess messaging" (which is what you
want, from what I understand)? This seems
more appropriate for communication amongst
processes alien to one another than something
so code-level like a chan extension.
Has anyone extended the idea of channels where the
sender/receiver are on different machines (or at least in
different processes)? A netcat equivalent for channels!
Actual plumbing seems easy: one can add a `proxy' thread in
each process to send a message via whatever inter process
mechanism is a
35 matches
Mail list logo
