[9fans] channels across machines
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 available. One issue would be for the two sides to identify a specific channel. I imagine something like the following would work. // on the client: chan = chanconnect(host:port, elemsize, nelem); // on the server: x = chanbind(port, elemsize, nelem); chan = chanaccept(x); // to allow multiple connections Or one can build this on top of a socket or file descriptor. Another issue is endianness (unless all processors are the same type). Yet another issue is sending variable size things. In a single address space you can pass a pointer + may be a size but that trick doesn't work across process (or machine boundaries) -- so pretty much have to add some marshalling/unmarshalling that knows about types. Or is there a better idea? This certainly seems preferable to RPC or plain byte pipes for communicating structured values. Thanks! --bakul
[9fans] channels across machines
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. at least, in terms of Plan 9 ak
Re: [9fans] channels across machines
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 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. however inferno provides file2chan http://www.vitanuova.com/inferno/man/2/sys-file2chan.html. of course, somebody has to provide the 9p interface, even if that's just posting a fd to /srv. if you wanted to do something like file2chan in plan 9 and c, you're going to have to marshal your data. this means that chanconnect as specified is impossible. (acme avoids this by using text only. the kernel devices keep this under control by using a defined byte order and very few binary interfaces.) i don't know how you would solve the naming problems e.g. acme would have using dial-string addressing (i assume that's what you ment; host-port addressing is ip specific.). what would be the port-numbering huristic for allowing multiple acmes on the same cpu server? after whittling away problem cases, i think one is left with pipes, and it seems pretty clear how to connect things so that chan - pipe - chan. one could generalize to multiple machines by using tools like cpu(1). - erik
Re: [9fans] channels across machines
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. however inferno provides file2chan http://www.vitanuova.com/inferno/man/2/sys-file2chan.html. of course, somebody has to provide the 9p interface, even if that's just posting a fd to /srv. if you wanted to do something like file2chan in plan 9 and c, you're going to have to marshal your data. this means that chanconnect as specified is impossible. [...] after whittling away problem cases, i think one is left with pipes, and it seems pretty clear how to connect things so that chan - pipe - chan. one could generalize to multiple machines by using tools like cpu(1). 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. what i like about file2chan is that you can return your own error strings. as far is i know, that's not possible with pipes. if it is possible, i'm very interested to learn how it's done. mjl
Re: [9fans] channels across machines
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
[9fans] Question about Plan9 project
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 happy if the picture were different. Speaking with my clients I see that almost all appreciate Plan9. But, even if some of them defined it fascinating, the common sense is that, without guarantees about its longevity, it could be a wrong choice. How can I reply to this objection ? Reading the thread about plan9.bell-lab.com I understand that Bell Labs are no more directly committed in the project. Is it correct ? Adriano
Re: [9fans] Question about Plan9 project
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 happy if the picture were different. Speaking with my clients I see that almost all appreciate Plan9. But, even if some of them defined it fascinating, the common sense is that, without guarantees about its longevity, it could be a wrong choice. How can I reply to this objection ? coraid sells storage appliances based on plan 9 and employs people specficly to work on plan 9. there's also quite a bit of work that goes on at bell labs with the blue gene project. and i'm quite sure there are other serious applications that i'm not as aware of. - erik
Re: [9fans] channels across machines
On Sat, Jul 18, 2009 at 4:38 AM, Akshat Kumaraku...@mail.nanosouffle.net 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 one another than something so code-level like a chan extension. Acme does this. at least, in terms of Plan 9 ak
Re: [9fans] Question about Plan9 project
On Sat, Jul 18, 2009 at 6:25 PM, Anthony Soraceano...@gmail.com 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 development process, there is no way to know what anyone is working on, no way to have any idea of what changes and features to expect in the future or when, or when any given bug might be fixed, or even a bug database for that matter, nor a way to know what changes have been made or why (other than computing your own diffs based on past snapshots). 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. uriel ; 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 for its own sake (at least not officially). i don't believe ALU has made any sort of corporate commitment to the OS, that's true. the longevity of any open source OS is based on the community surrounding it; this is as true for Plan 9 as it is for Linux and most of the BSDs (and various other things). our community is way smaller than those, but my sense is we're stronger in many ways than we've been for most of the OS's life (we've got less Bell Labs involvement than we did for the first half, but a broader range of contributors). Plan 9 ships in at least one commercial product, which wasn't true for most of its life (i can only think of those 2e-based video systems from earlier; anyone else?), and is used in some really large research projects by people outside the Labs. 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
Re: [9fans] channels across machines
On Sat, Jul 18, 2009 at 4:38 AM, Akshat Kumaraku...@mail.nanosouffle.net 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 one another than something so code-level like a chan extension. Acme does this. the plumber is pretty far from a channel. a channel has one input and one output. the plumber has one input and many ouputs and uses a dynamic ruleset to route messages. let's not confuse them. however, the fact that plumber implements a fs and the import(4) and cpu(1) illustrates how one could use a pipe to build a inter-machine chan-like mechanism. i say chan-like because this ignores data marshalling. - erik
Re: [9fans] channels across machines
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 definition (e.g. IDL) into a server and a client library; 9p(2) and ioproc(2) can be readily used in the generated code to do the tricky stuff. the main part then becomes how to translate the calls across. conventionally the server for an interface with an ID of X (e.g. GUID) is posted to /srv/X. for a given method bar in interface foo, writing to /n/foo/bar ( /srv/X mounted on /n/foo) would invoke foo:bar wherever it is. obviously when the reader/writer are generated, the types and sizes of parameters are known. -Skip
Re: [9fans] channels across machines
On Sat, Jul 18, 2009 at 1:20 PM, Skip Tavakkolian9...@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 handling interfaces. it seems one could write a compiler that translates an interface definition (e.g. IDL) into a server and a client library; 9p(2) and ioproc(2) can be readily used in the generated code to do the tricky stuff. the main part then becomes how to translate the calls across. conventionally the server for an interface with an ID of X (e.g. GUID) is posted to /srv/X. for a given method bar in interface foo, writing to /n/foo/bar ( /srv/X mounted on /n/foo) would invoke foo:bar wherever it is. obviously when the reader/writer are generated, the types and sizes of parameters are known. Reminds me of the http interface to venti, which has things like /set/variable and /plot/variable
Re: [9fans] Question about Plan9 project
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 workarounds, of course), and still in production. I don't think the risk of using Plan 9 is greather than the risk assumend by those who developed with WCE prior to 4. Dorin On Sat, Jul 18, 2009 at 4:10 PM, Adriano Verardoa.vera...@tecmav.com wrote: 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 happy if the picture were different. Speaking with my clients I see that almost all appreciate Plan9. But, even if some of them defined it fascinating, the common sense is that, without guarantees about its longevity, it could be a wrong choice. How can I reply to this objection ? Reading the thread about plan9.bell-lab.com I understand that Bell Labs are no more directly committed in the project. Is it correct ? Adriano
[9fans] i/o on a hangup channel asymmetry
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 btw, is there any way to make UNIX (POSIX) behave like Plan9 read(1)? The EOF on a hangup channel is actually misleading, its not that the channel can be ever resumed...
Re: [9fans] Question about Plan9 project
On Sat, Jul 18, 2009 at 2:35 PM, dorin bumbubumbudo...@gmail.com 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 reached 10+ years (with workarounds, of course), and still in production. I don't think the risk of using Plan 9 is greather than the risk assumend by those who developed with WCE prior to 4. I was going to say something to that effect -- Plan 9 is by and large pretty stable, and on the same hardware, even no updates would leave you with a fairly reliable system. Dorin On Sat, Jul 18, 2009 at 4:10 PM, Adriano Verardoa.vera...@tecmav.com wrote: 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 happy if the picture were different. Speaking with my clients I see that almost all appreciate Plan9. But, even if some of them defined it fascinating, the common sense is that, without guarantees about its longevity, it could be a wrong choice. How can I reply to this objection ? Reading the thread about plan9.bell-lab.com I understand that Bell Labs are no more directly committed in the project. Is it correct ? Adriano
Re: [9fans] channels across machines
On Sat, 18 Jul 2009 06:25:19 EDT erik quanstrom quans...@quanstro.net 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 channels! 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. however inferno provides file2chan http://www.vitanuova.com/inferno/man/2/sys-file2chan.html. of course, somebody has to provide the 9p interface, even if that's just posting a fd to /srv. if you wanted to do something like file2chan in plan 9 and c, you're going to have to marshal your data. this means that chanconnect as specified is impossible. (acme avoids this by using text only. the kernel devices keep this under control by using a defined byte order and very few binary interfaces.) i don't know how you would solve the naming problems e.g. acme would have using dial-string addressing (i assume that's what you ment; host-port addressing is ip specific.). what would be the port-numbering huristic for allowing multiple acmes on the same cpu server? after whittling away problem cases, i think one is left with pipes, and it seems pretty clear how to connect things so that chan - pipe - chan. one could generalize to multiple machines by using tools like cpu(1). First of all, thanks for all the responses! 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 type idea. In the concurrent application where I want to use this, it would factor out a bunch of stuff and simplify communication. The chanconnect(host:port) syntax was to get the idea across. A real building block might look something like this: int fd = get a pipe end to something somehow Chan c = fd2chan(fd, marshalling functions); Ideally I'd generate relevant struct definitions and marshalling functions from the same spec. -- bakul
Re: [9fans] Question about Plan9 project
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 reached 10+ years (with workarounds, of course), and still in production. I don't think the risk of using Plan 9 is greather than the risk assumend by those who developed with WCE prior to 4. I absolutely agree. In fact I use whatever I consider good without taking into account whether or not it is largely used. The problem arise when I must share the decision with clients who are not skilled enough to distinguish among market share and real quality. adriano
Re: [9fans] Question about Plan9 project
On Sat, Jul 18, 2009 at 9:59 AM, Urielurie...@gmail.com 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 available, and anyone that thinks they can do a better job is welcome to fork it, repackage the distribution, mirror it, support it, and so forth. People will naturally flock to better solutions. This is the very heart of open source. Conforming to Google's idea of open source, or the Linux Community's model, or the GNU religion is in no way essential to open source. What is essential is that the community works out what works best on its own and evolves through forking and merging and different approaches which work best at different times. Forks are already in place. Inferno is very much a fork of Plan 9, Octopus is a fork of Inferno. Brucee has his own fork (or perhaps forks?) of Inferno. p9p and 9vx are also forks after a fashion. These forks often contribute fixes and improvements back to respective parents, and some times they don't. The secret plan 9 super secret society fork is yet another evolution, actually primarily motivated by bitter, disruptive, and ultimately destructive community members. All things are valid, evolution only moves forward with action. We have our fork, we are proceeding with it as we best see fit -- that's our prerogative. Unhappy? Restless? Bored? Go forth and fork -- IMHO, this is a research operating system, its here to play with, learn and explore. If you aren't interested in those things, you'll be disappointed or worse. -eric
Re: [9fans] channels across machines
On Sat, Jul 18, 2009 at 1:52 PM, Bakul Shahbakul+pl...@bitblocks.com 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 type idea. In the concurrent application where I want to use this, it would factor out a bunch of stuff and simplify communication. The chanconnect(host:port) syntax was to get the idea across. A real building block might look something like this: int fd = get a pipe end to something somehow Chan c = fd2chan(fd, marshalling functions); getting a pipe end to something somehow is why you really want to leverage the namespace as a 9p file system. host:port is really a legacy concept that often locks you into a way of thinking or a particular transport. The typed channels (or for that matter file system interfaces) is an interesting topic, and there have been some folks thinking about it, but I'm not sure they are ready to share their thoughts yet. -eric
Re: [9fans] Question about Plan9 project
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 more light on this super secret fork?
Re: [9fans] Question about Plan9 project
On Sat, Jul 18, 2009 at 2:37 PM, Coreyco...@bitworthy.net 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. Curiosity has just got the best of me. Can you shed a little more light on this super secret fork? No. :) -eric
Re: [9fans] Question about Plan9 project
On Sat, Jul 18, 2009 at 3:50 PM, Eric Van Hensbergeneri...@gmail.com wrote: On Sat, Jul 18, 2009 at 2:37 PM, Coreyco...@bitworthy.net 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. Curiosity has just got the best of me. Can you shed a little more light on this super secret fork? No. :) -eric Well, I'm sure you can, but if you told us, you'd have to kill us.
Re: [9fans] Question about Plan9 project
On Saturday 18 July 2009 12:50:39 Eric Van Hensbergen wrote: On Sat, Jul 18, 2009 at 2:37 PM, Coreyco...@bitworthy.net 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. Curiosity has just got the best of me. Can you shed a little more light on this super secret fork? No. :) Ok - well at any rate, it is now publicly known that there is at least one 'super secret' Plan 9 fork in process. Paranoia is a disease unto itself, and may I add, the person... standing next to you... may not be who they appear to be - so take precaution. - Primus
Re: [9fans] Question about Plan9 project
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 FreeBSD instead of Linux, Unix instead of VMS etc etc in a production environments, because a largely used product is considered more reliable. From this point of view, of course. Support is also an issue The usual questions are about bug fixes and so on. But these are not problems because it's quite easy to prove that the support is good, the system is stable etc etc. Instead, can happen that some hardware supported by Plan9 is not supplied by italian reseller and vice versa. This can (sometimes) be a problem for the end user. Unbelievable but true, a driver (or a patch to a driver or whatever else) done by an italian is not considered as good as the stuff from the original site. It is a psychological problem I have often to face with. adriano
[9fans] About Plan9 on small systems
Hi, all Some time go I read about Plan9 on microcontrollers. Is this an interesting argument for the 9fans community ? adriano
Re: [9fans] About Plan9 on small systems
On Sat, Jul 18, 2009 at 1:50 PM, Adriano Verardoa.vera...@tecmav.com 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, you might have better luck with native Inferno--that can run in as little as 1 MB of RAM. John -- I've tried programming Ruby on Rails, following TechCrunch in my RSS reader, and drinking absinthe. It doesn't work. I'm going back to C, Hunter S. Thompson, and cheap whiskey. -- Ted Dziuba
Re: [9fans] channels across machines
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 handling interfaces. it seems one could write a compiler that translates an interface definition (e.g. IDL) into a server and a client library; 9p(2) and ioproc(2) can be readily used in the generated code to do the tricky stuff. the main part then becomes how to translate the calls across. I did something like this (map a file of ascii struct defns to C++ classes that included serialization/deserialization) for the only company both of us have worked in! These days I am likely to just use s-exprs if the choice is mine. The joy of sexpr :-) On Sat, 18 Jul 2009 14:32:30 CDT Eric Van Hensbergen eri...@gmail.com wrote: getting a pipe end to something somehow is why you really want to leverage the namespace as a 9p file system. Indeed but it is a separable concern (just like authentication).
[9fans] git on plan9
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. I think altering the hg-git code is the best option and i've done it in such a way that its isolated so it can be easily updated from mainstream. Let me know if you want it. ++james rator_gade% hg clone git://zen-sources.org/zen/THE.git destination directory: THE.git fetching from : git://zen-sources.org/zen/THE.git importing Hg objects into Git Counting objects: 1592, done. Compressing objects: 0% (1/1185) Compressing objects: 1% (12/1185) Compressing objects: 2% (24/1185) Compressing objects: 3% (36/1185) Compressing objects: 4% (48/1185) Compressing objects: 5% (60/1185) Compressing objects: 6% (72/1185) Compressing objects: 7% (83/1185) Compressing objects: 8% (95/1185) Compressing objects: 9% (107/1185) Compressing objects: 10% (119/1185) Compressing objects: 11% (131/1185) Compressing objects: 12% (143/1185) Compressing objects: 13% (155/1185) Compressing objects: 14% (166/1185) Compressing objects: 15% (178/1185) Compressing objects: 16% (190/1185) Compressing objects: 17% (202/1185) Compressing objects: 18% (214/1185) Compressing objects: 19% (226/1185) Compressing objects: 20% (237/1185) Compressing objects: 21% (249/1185) Compressing objects: 22% (261/1185) Compressing objects: 23% (273/1185) Compressing objects: 24% (285/1185) Compressing objects: 25% (297/1185) Compressing objects: 26% (309/1185) Compressing objects: 27% (320/1185) Compressing objects: 28% (332/1185) Compressing objects: 29% (344/1185) Compressing objects: 30% (356/1185) Compressing objects: 31% (368/1185) Compressing objects: 32% (380/1185) Compressing objects: 33% (392/1185) Compressing objects: 34% (403/1185) Compressing objects: 35% (415/1185) Compressing objects: 36% (427/1185) Compressing objects: 37% (439/1185) Compressing objects: 38% (451/1185) Compressing objects: 39% (463/1185) Compressing objects: 40% (474/1185) Compressing objects: 41% (486/1185) Compressing objects: 42% (498/1185) Compressing objects: 43% (510/1185) Compressing objects: 44% (522/1185) Compressing objects: 45% (534/1185) Compressing objects: 46% (546/1185) Compressing objects: 47% (557/1185) Compressing objects: 48% (569/1185) Compressing objects: 49% (581/1185) Compressing objects: 50% (593/1185) Compressing objects: 51% (605/1185) Compressing objects: 52% (617/1185) Compressing objects: 53% (629/1185) Compressing objects: 54% (640/1185) Compressing objects: 55% (652/1185) Compressing objects: 56% (664/1185) Compressing objects: 57% (676/1185) Compressing objects: 58% (688/1185) Compressing objects: 59% (700/1185) Compressing objects: 60% (711/1185) Compressing objects: 61% (723/1185) Compressing objects: 62% (735/1185) Compressing objects: 63% (747/1185) Compressing objects: 64% (759/1185) Compressing objects: 65% (771/1185) Compressing objects: 66% (783/1185) Compressing objects: 67% (794/1185) Compressing objects: 68% (806/1185) Compressing objects: 69% (818/1185) Compressing objects: 70% (830/1185) Compressing objects: 71% (842/1185) Compressing objects: 72% (854/1185) Compressing objects: 73% (866/1185) Compressing objects: 74% (877/1185) Compressing objects: 75% (889/1185) Compressing objects: 76% (901/1185) Compressing objects: 77% (913/1185) Compressing objects: 78% (925/1185) Compressing objects: 79% (937/1185) Compressing objects: 80% (948/1185) Compressing objects: 81% (960/1185) Compressing objects: 82% (972/1185) Compressing objects: 83% (984/1185) Compressing objects: 84% (996/1185) Compressing objects: 85% (1008/1185) Compressing objects: 86% (1020/1185) Compressing objects: 87% (1031/1185) Compressing objects: 88% (1043/1185) Compressing objects: 89% (1055/1185) Compressing objects: 90% (1067/1185) Compressing objects: 91% (1079/1185) Compressing objects: 92% (1091/1185) Compressing objects: 93% (1103/1185) Compressing objects: 94% (1114/1185) Compressing objects: 95% (1126/1185) Compressing objects: 96% (1138/1185) Compressing objects: 97% (1150/1185) Compressing objects: 98% (1162/1185) Compressing objects: 99% (1174/1185) Compressing objects: 100% (1185/1185) Compressing objects: 100% (1185/1185), done. Total 1592 (delta 455), reused 1128 (delta 286) importing Git objects into Hg at: 0/116 at: 100/116 updating working directory 241 files updated, 0 files merged, 0 files removed, 0 files unresolved rator_gade%
Re: [9fans] Question about Plan9 project
On Saturday 18 July 2009 10:59:20 ron minnich wrote: On Sat, Jul 18, 2009 at 9:59 AM, Urielurie...@gmail.com wrote: snip 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. So, let's revise this one too.. I, Uriel, taking up Noah Evans offer, will be forking the code base and releasing an OS called Plan-U. I will provide servers that resolve all the problems seen with the bell labs server, and I will take on the task, with my friends, of providing all the things I see lacking in the current setup. I sent Uriel a message off-list asking him about this, and he preferred to answer them in public. I basically volunteered to help him out, were he to embark on the effort, because I am also interested in seeing a version of Plan 9 with a less... sterile, clean-room environment; and into an environment that's a little more open to experimental change which may fall outside the current sensibilities and needs of the prevailing primary movers and shakers of the currently existing Plan 9 community; and something perhaps a bit more closer to a more open and accessible, community driven development model. This is not to fault Plan 9 as it exists now, but simply to scratch a different itch than what appears to be in the fore-front of the current 'official' Plan 9 distribution. Seems like it's something that's been needed for awhile in order to help prevent ideological schisms; but apparently no one's tried it yet? I'm much too new here to have any desire whatsoever to contribute to noise or flames, I respect everyone's positions and opinions equally even where they differ from my own. Not too mention I'm very new to Plan 9, so I lack experience. Cheers
Re: [9fans] About Plan9 on small systems
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 about styx on a brick for an example of using styx (9p by another name) on a really small embedded device to export underlying capabilities. the big difference is that inferno requires no mmu. these days i think the bright line would be 32-bit cpus. it would be quite difficult to get either one of them working well on a 8- or 16-bit cpu. - erik
Re: [9fans] i/o on a hangup channel asymmetry
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, which can be ignored, but still)? hmm. from a quick read of port/sysfile.c, i think the precise behavior might depend on the underlying device. if devtab[m-c-type]-bread/bwrite are (ultimately) based on qbread and qbwrite, i read qio as saying that neither should generate a note. perhaps i've been asleep at the swtch, but i don't recall seing writes on closed channels terminate programs with a note. - erik
