Re: Interesting
The OSI disappoints me.
For example, if I give a CD with plan9 to someone for money (thus “Commercial Distribution”) and he sues Lucent, then they can sue me for any court damages, which it is left up to me to recover from the claimant. This pretty onerous — I doubt it will let Debian package this up (as redistributors would shy away from it like a hot potato). This is just from the terms I read — there seems to be a legal minefield in that license 😦
I am fairly certain I read this paper back in 2001 when I still had a Plan9 fetish.
I’ve since outgrown the fetish, but still enjoy the ideas surounding Plan9.
same here. i’d like to see some of the ideas extended even further than plan9 does, though… it seems they’re still limiting themselves in terms of the “sharing” paradigm…
why use a single fileserver, or a single cpu server? why not have -every- CPU on the network pool, with the local CPU taking precedence on local processes of course? same goes for disk space. am I completely off the ball on this? it seems entirely doable even maybe just with plan9 as it exists now and a bit of scripting / network auto-configuration.
Optimizations by binary interfaces?
I noticed that a lot of the stuff in Linux /proc filesystem is similar to Plan 9’s use of namespaces. Any relationship?
The paper is from 1993. What happened to Plan 9 during the last 12 years?
Some operations involving file access and writing/reading textual stuff (like writing commands to the process’s ctl file) may be time-consuming and inefficient. Was any thought given to creation of streamlined and efficient binary interface, which is however based upon and is equivalent to the less-efficient interface? How (if at all) can this be done without destruction of the conceptual purity of Plan 9 filesystem and namespaces?
Not everything – process manipulation (e.g. fork) is still done in the traditional way.
I found it pretty consistent; anything specifically you object to?
Yes. Very few systems are actually trees. Dags, maybe, but not trees. Putting in a tree representation just annoys me, maybe just because it’s overdone. It is possible to represent a dag using a filespace-type-thing, but people then tend to think of fixed roots and such, which goes contrary to the whole spirit of the thing.
Also, plan9 came awfully close to a nice object-capability system. But the lack of a clear method-invocation (read/write does NOT cut it) kind of ruined that.
Plan9 is heartwarming. So much is done right. I love the way that the windowing system provides the same interface it consumes, literally providing a bunch of “virtual terminals” (windows) inside of the terminal where it is running. So that you can run it recursively. Or, because nearly everything is routed through the same filesystem protocol, you can graft on almost anything from a machine across the network—filesystem, mouse, terminal, etc.
It’s a bit weird to use, though. The notion of “users” is a bit different than in unix,… IIRC it is very difficult to set up a Plan9 machine and give people “shell accounts.” I got so far as setting up Plan9 running on bare hardware at the XCF. Vmware makes it incredibly easy to play with, tho.
Interesting
I think someone should make a free clone of plan 9 😉
Comment by moshez — February 21, 2005 @ 4:45 PM |
Re: Interesting
The license (http://cm.bell-labs.com/plan9dist/license.html) appears to be OSI approved, so maybe it’s not *entirely* evil 😉
Comment by mulix — February 21, 2005 @ 4:50 PM |
Re: Interesting
The OSI disappoints me.
For example, if I give a CD with plan9 to someone for money (thus “Commercial Distribution”) and he sues Lucent, then they can sue me for any court damages, which it is left up to me to recover from the claimant. This pretty onerous — I doubt it will let Debian package this up (as redistributors would shy away from it like a hot potato). This is just from the terms I read — there seems to be a legal minefield in that license 😦
Comment by moshez — February 21, 2005 @ 5:00 PM
Re: Interesting
Yikes.
Comment by mulix — February 21, 2005 @ 7:07 PM
I am fairly certain I read this paper back in 2001 when I still had a Plan9 fetish.
I’ve since outgrown the fetish, but still enjoy the ideas surounding Plan9.
Comment by the_p0pe — February 21, 2005 @ 10:59 PM |
same here. i’d like to see some of the ideas extended even further than plan9 does, though… it seems they’re still limiting themselves in terms of the “sharing” paradigm…
why use a single fileserver, or a single cpu server? why not have -every- CPU on the network pool, with the local CPU taking precedence on local processes of course? same goes for disk space. am I completely off the ball on this? it seems entirely doable even maybe just with plan9 as it exists now and a bit of scripting / network auto-configuration.
Comment by reverius42 — February 22, 2005 @ 3:38 AM |
Optimizations by binary interfaces?
I noticed that a lot of the stuff in Linux /proc filesystem is similar to Plan 9’s use of namespaces. Any relationship?
The paper is from 1993. What happened to Plan 9 during the last 12 years?
Some operations involving file access and writing/reading textual stuff (like writing commands to the process’s ctl file) may be time-consuming and inefficient. Was any thought given to creation of streamlined and efficient binary interface, which is however based upon and is equivalent to the less-efficient interface? How (if at all) can this be done without destruction of the conceptual purity of Plan 9 filesystem and namespaces?
Comment by tddpirate — February 22, 2005 @ 10:16 PM |
HATE HATE HATE.
Why did they have to shoehorn everything into a hierarchical form?
Comment by taral — February 24, 2005 @ 12:12 AM |
Not everything – process manipulation (e.g. fork) is still done in the traditional way.
I found it pretty consistent; anything specifically you object to?
Comment by mulix — February 24, 2005 @ 1:06 PM |
Yes. Very few systems are actually trees. Dags, maybe, but not trees. Putting in a tree representation just annoys me, maybe just because it’s overdone. It is possible to represent a dag using a filespace-type-thing, but people then tend to think of fixed roots and such, which goes contrary to the whole spirit of the thing.
Comment by taral — February 24, 2005 @ 8:28 PM
Also, plan9 came awfully close to a nice object-capability system. But the lack of a clear method-invocation (read/write does NOT cut it) kind of ruined that.
Comment by taral — February 24, 2005 @ 8:29 PM
Plan9 is heartwarming. So much is done right. I love the way that the windowing system provides the same interface it consumes, literally providing a bunch of “virtual terminals” (windows) inside of the terminal where it is running. So that you can run it recursively. Or, because nearly everything is routed through the same filesystem protocol, you can graft on almost anything from a machine across the network—filesystem, mouse, terminal, etc.
It’s a bit weird to use, though. The notion of “users” is a bit different than in unix,… IIRC it is very difficult to set up a Plan9 machine and give people “shell accounts.” I got so far as setting up Plan9 running on bare hardware at the XCF. Vmware makes it incredibly easy to play with, tho.
Comment by nibot — April 15, 2005 @ 6:18 AM |