[9fans] Re: Are the Infernospaces gone?
j...@plan9.bell-labs.com
>of these great ideas on other OSes (dare I say Linux), in an OS heterogeneous
>network.
Alef is gone.
Lucio De Re
>
> Alef is gone.
That seems a pity. I, for one, found it intriguing and exciting. What
does that do for ACME? Where did ACME lead? Have the Oberon graphics
found their way in there?
Ah, well, no doubt we'll find out before long.
One possibility that comes to mind, though, may be to lobby the
marketing people, if the engineers are willing to tell us who they
are :-) Not that I don't see the futility of it, as they are
probably used to dealing with giant organisations, but, typically,
here in South Africa, the head of marketing is likely to be
approachable.
++L
Lucio De Re
(as a total non-sequitur) :-(
>
> One possibility that comes to mind, though, may be to lobby the
> marketing people, if the engineers are willing to tell us who they
> are :-) Not that I don't see the futility of it, as they are
> probably used to dealing with giant organisations, but, typically,
> here in South Africa, the head of marketing is likely to be
> approachable.
>
hopefully will have the ear of marketing back in the States.
Sorry about the disjointedness: too much or too little coffee. I'll
go get another fix right now :-)
++L
for...@vitanuova.com
>Or have I just reinvented inferno?
i'd say the need for it or something like it hasn't gone away.
>for...@caldo.demon.co.uk wrote:
>> <snip>
>> The most useful aspect of Infernospaces (from our point of view outside)
>> was that it incorporated non-Inferno systems into an Inferno world
>> without having to have them run Inferno.
><snip>
my posting to comp.os.inferno unfortunately had some ambiguous prepositions,
i was also a little too subtle in my wording, and unfortunately, you
didn't quote the whole thing here, so that sentence gives quite the wrong
impression out of context, namely that i thought there was something wrong
about `having to have [non-Inferno systems] run Inferno', which would be silly
of me, given that the hosted mode was one of the key points about Inferno!
generally, I (or we, really since it includes others at Vita Nuova)
take the view that InfernoSpaces was simultaneously too little and too much.
It was `too much' for small devices, where (by contrast) 9p/styx looks fine,
and offered `too little' beyond that really to improve the structuring, implementation
and portability of cross-platform applications. uncomfortable all round.
in the Inferno/Plan9 milieu Vita hopes to provide things that more effectively attack
the limited part of the problem where (we thought) InfernoSpaces meant well.
for...@vitanuova.com
>Or have I just reinvented inferno?
>for...@caldo.demon.co.uk wrote:
>> <snip>
>> The most useful aspect of Infernospaces (from our point of view outside)
>> was that it incorporated non-Inferno systems into an Inferno world
>> without having to have them run Inferno.
><snip>
my posting to comp.os.inferno unfortunately had some ambiguous prepositions,
and i was also a little too subtle in my wording, but worse, you unfortunately
didn't quote the whole thing here, leaving the impression that i might
have thought more of InfernoSpaces than i did (or do), or that i thought
there was something fundamentally wrong with the hosted principle behind
Inferno. i'd better spell it out a bit more.
generally, I (or we, really since it includes others at Vita Nuova)
take the view that InfernoSpaces was simultaneously too little and too much.
It was `too much' for small devices, where (by contrast) 9p/styx looks fine,
and offered `too little' beyond that really to improve the structuring, implementation
and portability of cross-platform applications. i know where Infernospace has
gone, but i haven't heard what will become of it. in the Inferno/Plan9 milieu
we hope to provide something that attacks the part of the problem where
j...@plan9.bell-labs.com
>
>That seems a pity. I, for one, found it intriguing and exciting. What
>does that do for ACME? Where did ACME lead? Have the Oberon graphics
>found their way in there?
My memory may be a little fuzzy on this but if I remember correctly there were
only 3 substantial programmes written in Alef - acme, rio and the IP stack. The
IP stack found its way back into the kernel and the other two were converted to
use a new thread library.
>Ah, well, no doubt we'll find out before long.
Hopefully, yes.
for...@vitanuova.com
>>marketing people, if the engineers are willing to tell us who they
i'd quite strongly advise keeping calm and quiet,
and leaving it up to the people in the company
that know how the company works. it's bound to be less troublesome
in the long run. lobbying could well be counter-productive.
complete lack of interest expressed in it could well be more useful;
they'll think that no one is interested so it can't be up to much,
and might as well be released. lobby them, and they'll begin to worry
that there might well be something in it!
Lucio De Re
>
> >>One possibility that comes to mind, though, may be to lobby the
> >>marketing people, if the engineers are willing to tell us who they
>
> i'd quite strongly advise keeping calm and quiet,
Well, that's what worked in the past, so far from me to stir, but
times have changed and the Open Source movement is acquiring quite
a lot of legitimacy and respect.
Unless I'm much mistaken, I see two fundamental problems with
releasing Brazil as a commercial product: (a) preparing the
distribution into a shrink-wrap format and (b) providing the support
that a paying public would be demanding.
On the other hand, setting up a CVS repository and assigning one
staff member to moderate source updates would, in my opinion, be
considerably simpler and hopefully within a moderate budget. In
return, Bell Labs would get both feedback and improvements well in
excess of their investment. If one then gets something like
StarOffice ported to the platform, the benefits become a lot more
visible.
I have little doubt that an Open Source Plan 9 would attract a lot
of attention, even if released in a very scrappy form.
Interestingly, it's the shrink-wrapping of Linux that's given Red
Hat the momentum to IPO, and it is not to be excluded that somebody
like David Butler may be able to invest the effort to do likewise
under a Plan 9 banner (David, I hope I am not insulting you :-).
The biggest hurdle, again strictly in my opinion, is the culture
of dealing only with large corporates that AT&T seems to have always
suffered from and no doubt Lucent has inherited. Here it is hard
for me to offer any suggestions on how to surmount it.
Anyway, here's to a successful release. Given the plummeting of the
South African currency against the US dollar, I sincerely hope the
release will be priced considerably below the US$ 350 I paid for it a
few years back (and I got a flawed manual, too :-(
++L
Anthony Sorace
well, the first problem is the name. Brazil is dead; long live
Plan 9. they don't even call it that "inside" any more. it seems
to have just been a transitional name to disambiguate the 2nd
edition, as released, from what they did to it next. but WRT the
problems you cited:
//(a) preparing the distribution into a shrink-wrap format
this is only as big an issue as they chose to make it, although
(hopefuly) the choice will impact what they charge for it. if,
for example, they set up some sort of source repository (as
you suggest later), there isn't really much work on this front,
as people know they're getting the "current" state of things.
on the other end of the scale, they could ship CDs with fully
functional systems for various architectures on them. they've
already said they're not going that extreme, but there are
degrees between those options, obviously.
//(b) providing the support that a paying public would be demanding.
again, depends at least partly on (a). also, note that Linux
(as well as most GNU projects and [Net,Free,Open]BSD) had a
respectable community (in terms of size, anyway) even before
Red Hat and IBM came along and started offering official,
comercial support. For my part, i don't really know how much
more i'd want, beyond having fairly direct access to jmk,
presotto, rob, etc. as we do here. and that's to say nothing
of the many other excelent people on this list.
//StarOffice ported to [Plan 9]...
oh, lord. i suppose one could make an argument for it being
good for the platform's future, but it's still a scary idea.
//I sincerely hope the release will be priced considerably
//below the US$ 350 I paid for it a few years back
here, here! a good price for comercial use, but i'm not a
corporation! i want to be able to run the new edition in my
house, for personal use. $350's a bit high for that.
: anothy;
Scott Schwartz
| Plan 9. they don't even call it that "inside" any more.
Despite that, I scheduled the Usenix BOF with the title
"Plan 9/Brazil/Inferno", on the theory that it will be a
good time to explain the history and fate of each.
G. David Butler
>times have changed and the Open Source movement is acquiring quite
>a lot of legitimacy and respect.
True, especially since Sun has released Solaris source; but it is not
"open" in the same way as Linux. Plan 9 is "open" too, but in a
different way. There is nothing that keeps us from adding to the
system and sharing that code (we do it all the time). And it is even
more "open" than Solaris because we can create derivative works that
change the API as necessary (e.g. my create(2) change.) The real
problem with Plan 9 over Linux or Solaris has to do with what can
be done with the resulting system. The license disallows commercial
use.
>
>Unless I'm much mistaken, I see two fundamental problems with
>releasing Brazil as a commercial product: (a) preparing the
>distribution into a shrink-wrap format and (b) providing the support
>that a paying public would be demanding.
That is an understatement! Why would the paying public buy Plan 9?
This a question I would like to talk more about... maybe at the
BOF session?
>
>On the other hand, setting up a CVS repository and assigning one
>staff member to moderate source updates would, in my opinion, be
>considerably simpler and hopefully within a moderate budget. In
>return, Bell Labs would get both feedback and improvements well in
>excess of their investment. If one then gets something like
>StarOffice ported to the platform, the benefits become a lot more
>visible.
Again, without the ability to use the resulting system for more than
sending e-mail at home, why do it? Why port StarOffice, or even
Microsoft Office (once they are split from the OS, heh heh), if
you can't sell it?
>
>I have little doubt that an Open Source Plan 9 would attract a lot
>of attention, even if released in a very scrappy form.
It is "open" now, and how much attention has it attracted? Linux got
attention because the ~5,000 ISPs found it was an inexpensive way to
run their servers. Can they use Plan 9 for that? No. In fact, while
I was CTO of an ISP (Internet America NASDAQ:GEEK) is when I got very
interested in Plan 9. I found the distributed model a great way to
scale a large user base needing mail, news and web services. I had
to scrap the project because Plan 9 could not be used in a commercial
setting.
>
>Interestingly, it's the shrink-wrapping of Linux that's given Red
>Hat the momentum to IPO, and it is not to be excluded that somebody
>like David Butler may be able to invest the effort to do likewise
>under a Plan 9 banner (David, I hope I am not insulting you :-).
Not at all. I have been working for some time on Plan 9 and looking
for ways to legally use the system other than to impress my friends
and torture this list's members. :)
>
>The biggest hurdle, again strictly in my opinion, is the culture
>of dealing only with large corporates that AT&T seems to have always
>suffered from and no doubt Lucent has inherited. Here it is hard
>for me to offer any suggestions on how to surmount it.
Absolutely! I have been working with AT&T/Lucent for many years to
get something other than the shrinkwrap license that gives us some
interesting tools but doesn't allow us to do more than play with them.
But enough complaining! After 4 long years of negotiating with
Lucent I (as a representative of a corporation set up for this
purpose) have finally secured a redistribution license for the '95
and (if there is one) the upcoming release of Plan 9. I cannot
discuss the financial details of the agreement (except to say it
was expensive). But it makes it possible for end users worldwide
to get a sublicense to use Plan 9 commercially.
I have a few ideas of how to proceed with this new tool, but I'm
hoping to gather a bunch of feedback at USENIX. Do you all think
one BOF session going to be enough?
David Butler
g...@dbSystems.com
Jim Choate
On Fri, 5 May 2000, G. David Butler wrote:
> It is "open" now, and how much attention has it attracted? Linux got
> attention because the ~5,000 ISPs found it was an inexpensive way to
> run their servers. Can they use Plan 9 for that?
I can attest to this. I've known of Plan 9 almost since day 1. I've also
been involved with Linux since '92. If you look in the back of a 1st or
2nd ed. "Running Linux" you'll find my system listed as a mirror and I am
also the founder of the Central Texas Linux User Group in 1994. I was
FORCED to select Linux over Plan 9 solely because of the licensing with
respect to my consulting. I currently run 14 machines in my home office,
mostly running Linux. They are ix86, Sparc, RS/6000, Amiga, and Atari
(solely for file transfer capability, no dev). I've also converted several
hundred people to Linux over the years I truly wish I could have given
them Plan 9 instead.
Had the Plan 9 license not been non-commercial I'd have been using it. If
Plan 9 is going to release Open Source then my current plan is to jump to
that and start developing there. I also hope to start a Plan 9 user group
when that happens as well.
> But enough complaining! After 4 long years of negotiating with
> Lucent I (as a representative of a corporation set up for this
> purpose) have finally secured a redistribution license for the '95
> and (if there is one) the upcoming release of Plan 9. I cannot
> discuss the financial details of the agreement (except to say it
> was expensive). But it makes it possible for end users worldwide
> to get a sublicense to use Plan 9 commercially.
Where do I buy a license?
> I have a few ideas of how to proceed with this new tool, but I'm
> hoping to gather a bunch of feedback at USENIX. Do you all think
> one BOF session going to be enough?
I'll be working on an anonymous remailer and the replacement of DES as the
default encryption mechanism. I'll also be using it with my robots and
rockets (packet radio).
____________________________________________________________________
The future is downloading. Can you hear the impact?
O[rphan] D[rift>]
Cyber Positive
The Armadillo Group ,::////;::-. James Choate
Austin, Tx /:'///// ``::>/|/ rav...@ssz.com
www.ssz.com .', |||| `/( e\ 512-451-7087
-====~~mm-'`-```-mm --'-
--------------------------------------------------------------------
Lucio De Re
>
I originally said:
> >Well, that's what worked in the past, so far from me to stir, but
> >times have changed and the Open Source movement is acquiring quite
> >a lot of legitimacy and respect.
>
> True, especially since Sun has released Solaris source; but it is not
> "open" in the same way as Linux. Plan 9 is "open" too, but in a
> different way. There is nothing that keeps us from adding to the
> system and sharing that code (we do it all the time). And it is even
> more "open" than Solaris because we can create derivative works that
> change the API as necessary (e.g. my create(2) change.) The real
> problem with Plan 9 over Linux or Solaris has to do with what can
> be done with the resulting system. The license disallows commercial
> use.
>
Agreed, even though you and I have differing views on the usefulness
of commercial use: Linux took off long before it found a commercial
purpose, although you may be correct that much of its impetus comes
from (more recent) commercial use.
As for code-sharing, it is restricted to the elite that acquired
the licence in the first place (does Tom Duff have a licenced copy,
or an exemption? :-) :-)
I think the price of Plan 9 is the primary stumbling block, Linux
caught on because it was free, not just open. OpenDOS isn't making
much progress either, despite its Open-ness. On the other hand,
the *BSDs are an interesting issue: they have followers, no doubt
more than Plan 9, but nothing like Linux. Something to do with
available toys, early in the game, and easy acceptance of all
contributions, a lesson that's hard for purists to accept; Plan 9
may well suffer from such fate once it is opened up.
In summary, (a) a free Plan 9 would have created a much greater
momentum (I might have mentioned this before, I discovered Plan 9
from the RC shell that Linux came out with originally), (b)
applications, specially flashy ones, are what trigger interest,
novelty and ease of development are much lower in the ladder (has
anyone ported GCC - shudder - to Plan 9?); (c) it must be possible,
nay, easy, to contribute to the code base, as many in this forum
have demonstrated, nothing like public recognition to encourage
more contributions. Am I repeating the lesson in Eric Raymond's
"The cathedral and the Bazaar?"
> >
> >Unless I'm much mistaken, I see two fundamental problems with
> >releasing Brazil as a commercial product: (a) preparing the
> >distribution into a shrink-wrap format and (b) providing the support
> >that a paying public would be demanding.
>
> That is an understatement! Why would the paying public buy Plan 9?
> This a question I would like to talk more about... maybe at the
> BOF session?
>
I'd love to be there, but that's right out of my league. By all
means let's thrash it out here (I'd better do something about my
e-mail first, the present arrangement is driving me nuts :-).
Personally, I'd like to see a BSD-style licence, even with Lucent
getting a cut. Or GDB, for that matter. I guess we should discuss
that option too.
> >
> >On the other hand, setting up a CVS repository and assigning one
> >staff member to moderate source updates would, in my opinion, be
> >considerably simpler and hopefully within a moderate budget. In
> >return, Bell Labs would get both feedback and improvements well in
> >excess of their investment. If one then gets something like
> >StarOffice ported to the platform, the benefits become a lot more
> >visible.
>
> Again, without the ability to use the resulting system for more than
> sending e-mail at home, why do it? Why port StarOffice, or even
> Microsoft Office (once they are split from the OS, heh heh), if
> you can't sell it?
>
That's where we see things differently, but I think it is merely
a matter of expression. Yourself have added features to Plan 9
with only your personal comfort in mind. Had I access to StarOffice
sources, I may well consider porting it to a platform I am pleased
with and use daily. Keep in mind that I am still striving to have
a single screen and keyboard on my desk, and that I find multibooting
totally unfeasible, probably because the Plan 9 philosophy has
gotten to me, right under my skin. Don't underestimate the religious
value _that_ may have.
I do hear your concern with commercial viability, though. But I
couldn't sell StarOffice, although I could provide installation
services, support and consulting to make a living. What I need is
to be able to justify installing my client's applications under
Plan 9/Brazil/Inferno, and do so legally, then I can charge for my
further contributions.
> >
> >I have little doubt that an Open Source Plan 9 would attract a lot
> >of attention, even if released in a very scrappy form.
>
> It is "open" now, and how much attention has it attracted? Linux got
> attention because the ~5,000 ISPs found it was an inexpensive way to
> run their servers. Can they use Plan 9 for that? No. In fact, while
> I was CTO of an ISP (Internet America NASDAQ:GEEK) is when I got very
> interested in Plan 9. I found the distributed model a great way to
> scale a large user base needing mail, news and web services. I had
> to scrap the project because Plan 9 could not be used in a commercial
> setting.
>
Again, we'll just have to disagree here, probably for want of hard
data. My view is that the ISPs moved to Linux because of price,
first, and momentum, second. I accept that deploying Plan 9 is
out of the question, but commercial use of Linux only occurred
because of the personal computing community that had already taken
shape. I had NetBSD at the ISP I started (PiX, in Johannesburg)
replaced with Linux because the new technical manager was more
comfortable with it. Admittedly, if Linux could not be seen as a
contender for commercial use, it would have had less impact (the
Plan 9-effect, shall we call it?) but I think you exaggerate its
importance, no matter how solid a block it is.
That said, I agree wholeheartedly with you that commercial use is
a necessity, I just hope it does not cloud the issue to the point
where _only_ commercial use is viable.
> >
> >Interestingly, it's the shrink-wrapping of Linux that's given Red
> >Hat the momentum to IPO, and it is not to be excluded that somebody
> >like David Butler may be able to invest the effort to do likewise
> >under a Plan 9 banner (David, I hope I am not insulting you :-).
>
> Not at all. I have been working for some time on Plan 9 and looking
> for ways to legally use the system other than to impress my friends
> and torture this list's members. :)
>
Well, you made at least one friend or convert - does that make me
a sado-masochist?
> But enough complaining! After 4 long years of negotiating with
> Lucent I (as a representative of a corporation set up for this
> purpose) have finally secured a redistribution license for the '95
> and (if there is one) the upcoming release of Plan 9. I cannot
> discuss the financial details of the agreement (except to say it
> was expensive). But it makes it possible for end users worldwide
> to get a sublicense to use Plan 9 commercially.
>
I guess I may as well ask here: Do you need a very enthusiastic
software engineer with lots of experience (read "old") and some
rather old-fashioned views?
> I have a few ideas of how to proceed with this new tool, but I'm
> hoping to gather a bunch of feedback at USENIX. Do you all think
> one BOF session going to be enough?
>
... and if not, I'll gladly provide my services remotely, at South
African rates.
> David Butler
> g...@dbSystems.com
Good luck, glad to see that there's still a bit of cloak-and-daggering
going on, and it works!
++L
Richard Uhtenwoldt
a major win, but what you end up with is still not as good as
an open-source license, from my point of view.
the success of Linux depended not only on core OS hackers but also on the
many thousands who made a small contribution: adopted the OS when it was
still difficult to install and use, wrote a driver for an obscure
device, ported a small program, wrote a Mini-HOWTO, packaged up programs
as RPMs or DEBs. I'm writing from the point of view of a potential
small-contributor to Plan 9.
G. David Butler writes:
> [Solaris] is not
>"open" in the same way as Linux. Plan 9 is "open" too, but in a
>different way. There is nothing that keeps us from adding to the
>system and sharing that code (we do it all the time). And it is even
>more "open" than Solaris because we can create derivative works that
>change the API as necessary (e.g. my create(2) change.)
"we do it all the time" is not a guarantee that Plan 9's owner will not
interfere with your doing it in the future. worse: Plan 9's owner can
probably prevent you from continuing to distribute improvements we have
already made.
licensees of Unix in the 70s and early 80s exchanged works derived from
Unix "all the time", the most famous such distribution being BSD. after
Unix had become commercially important and the regulations that prevented
them from entering the computing market were lifted, ATT changed their
attitude toward this practice, with the result that BSD entered legal
limbo for years, during which time it was unclear whether BSD was legal
to use or whether BSD had a future. today Linux has 10 times the number
of users as BSD, and commentators other than I have cited the period of
legal limbo as a reason.
moreover, source code for IBM's mainframe OSes were made available for
many years to IBM's customers. these customers shared their changes all
the time. in fact, the mainframers were the only ones who could afford
regularly to attend the OS-specific conferences that were the best way
for programmers to share their changes before the Internet became
available for this purpose. then IBM stopped making source code
available, to slow down their competitors, the plug-compatible
manufacturers. this raised such a cry that IBM had to relent partially,
by making the source available on microfilm. still, that was enough
of a restriction to interfere with users' ability to enjoy fully
the fruits of changes that had already been made and shared.
can anyone read the current shrinkwrap license for Plan 9 and assure me
that if I were to invest my time modifying Plan 9 that I would
always be able to make those changes (in the form of modified source
code or diff or boodle) available on the Web or via FTP? I do not think
so because even diffs and boodles are considered by our courts to be
derived works.
the reply that if my changes are any good then Plan 9's owner will
incorporate them into future versions of Plan 9 will not assuage me, for
it lets the owner capture too much of my work: I do not despise the
profit motive and I do not flinch from paying Plan 9's $350 price, but I
do not think it is good for my society for me to choose to devote my
creativity and mental energy in ways that can be "captured" by
profit-motivated businessmen and lawyers (or power-motivated
politicians, btw).
Steve Kilbane
there was a huge base of existing applications. It worked because people
wanted to do at home the same things they'd been doing at work or at
college, without spending the money on expensive hardware and software.
Granted, linux couldn't fill that niche straight away, but because it
was a UNIX clone, the potential was obvious.
At the moment, there isn't a similar need for Plan 9 or Inferno. They're
solutions looking for a problem.
steve
oka...@granite.cias.osakafu-u.ac.jp
>IP stack found its way back into the kernel and the other two were converted to
>use a new thread library.
Does this mean Plan 9 peoples abandoned concurrent programming, and
joined to the ordinal threading scheme? I'd like to know the reason...
Kenji
rob pike
and sets of libraries across an ever-growing list of architectures. The
concurrent programming aspects of Alef were simulated by a new thread
library for C, and that is what we use now. The syntax isn't as pretty but
the semantics is very close.
-rob
Russ Cox
Concurrent programming is alive as ever,
but is accomplished via a thread library for
C that provides most of Alef's functionality
(procs, tasks, buffered and unbuffered channels).
The benefits are that there need not be
two copies of each library now, and the programs
are more easily portable to other architectures
(there was no Alef compiler for the 68000, for
instance) as well as other operating systems
(the thread library has been ported to Linux).
The drawbacks are you lose type checking
on channel communication and a little bit of
syntactic sugar. They're not particularly
noticeable in practice.
Russ
oka...@granite.cias.osakafu-u.ac.jp
It seems Plan 9 has been changed in large extent, which makes me interesting
to see its new release. I thought that concurrent programming is very easy
to learn for programming multiple processor systems, and am happy this is
remained in the new release. In addition, threading the now the main stream,
and it is also good for us that we can choose both. ^_^
When I learned Alef, I wondered how they'll combine object oriented
programming to Plan 9 in future. If the threading library in C is the
solution, then what about this?
Kenji
Bengt Kleberg
> After 4 long years of negotiating with
> Lucent I (as a representative of a corporation set up for this
> purpose) have finally secured a redistribution license for the '95
> and (if there is one) the upcoming release of Plan 9.
Congratulations. Do you have a Swedish/Scandinavian/European re-seller?
Best Wishes, Bengt
===============================================================
Everything aforementioned should be regarded as totally private
opinions, and nothing else. be...@softwell.se
``His great strength is that he is uncompromising. It would make
him physically ill to think of programming in C++.''
Bengt Kleberg
> Alef is gone.
Has it been replaced? Or just left a whole after itself...
Douglas A. Gwyn
> Alef is gone.
Does the forthcoming new release of Plan 9 include Limbo/dis etc.?
Leo Caves
that other important libraries, on which most applications
in plan9 rely, have also been ported?
(in another, but related context, acme was rewritten to *nix (as wily),
via a reimplementation of (part of?) the plan9 graphics library)
if other elements of the "environment" of plan9 have been made portable
then this might provide a route for not only the "ideas" of plan9,
but also *actual tools*, to disseminate into the wider community.
I guess key here would be the namespace interface and tools
(because there is already a port of 9p to *nix?).
[ hence my original comment about "9spaces" or some such ]
With these tools, one might have the heart of plan9 (but perhaps not the soul).
Leo
PS: I mourn Alef.
I did not program with it (only limbo), but bought the rationale
for its existence from the plan9 team.
I'm glad that the thread library to implement the CSP-like concurrency
exists, but other languages features, such as loadable
modules etc will be missed.
As for "syntactic sugar", it is sometimes these elements that make
for the excitement in the new environment (they "feel" different
to make an oblique reference to "Pike's Polemic").
Yes, you can achieve the same through other means, but the clarity,
elegance and transparency may be compromised (dangerous things to say without
seeing the new thread library interface definitions)
Will there be a garbage collector in the (new) plan-9 C-compiler/run-time?
Although, this was not part of Alef, it made (makes) limbo a pleasure.
pres...@plan9.bell-labs.com
no
Bengt Kleberg
> And, while I'm on the subject, where did Acme go?
I am (always) using wily.
Lucio De Re
>
> > Does this mean Plan 9 peoples abandoned concurrent programming, and
> > joined to the ordinal threading scheme? I'd like to know the reason...
>
> Alef is a "concurrent language" because it is concurrency-friendly,
> but concurrent programming can be done in C without the help of the
> language syntax.
>
Yes, I've seen it done using setjmp/longjmp constructs, which is
really not elegant. Alef provided a lot of really slick facilities.
Maybe it is possible to release the Alef port to Irix under Open
Source? I have a feeling that releasing Alef in this manner may
well have a deep effect on open source developments (it would no
doubt be bastardised into Alef++ and so on, but I really haven't
found anything that addresses concurrent programming as elegantly
as Alef/Limbo do).
And, while I'm on the subject, where did Acme go? It had a lot of
potential, most of it still waiting to be discovered.
++L
Russ Cox
that other important libraries, on which most applications
in plan9 rely, have also been ported?
Libbio and some of the C library has been ported
(see the Newsqueak distribution on Rob's home page).
Unless someone beats me to it, I have plans of
trying to get much of what's left ported this
summer; a friend here at school is also interested,
so it has a decent chance of happening.
Part of those plans include tidying up a
new ``libXg'', as discussed before (or maybe
on sam-fans; I forget).
I guess key here would be the namespace interface and tools
(because there is already a port of 9p to *nix?).
[ hence my original comment about "9spaces" or some such ]
Many of the tools stand without the per-process
namespaces. That's why I think the ported libraries
would be useful. It's not clear to me how to implement
something like 9spaces usefully. As Dave mentioned,
Dong has built 9P support into FreeBSD, and now
we know someone is doing one for Linux too. But there's
still no per-process namespace. I started something
akin to what you've been calling 9spaces a while
back, and it worked fine for a single process, but
that's not particularly interesting. Many of the reasons
you would want a ``9spaces'' is to get some of the
more interesting tools, which rely heavily not only
on mounting 9P services but on having per-process
namespaces (e.g. rio or acme). You just can't
pull off the namespace sharing across a fork/exec in
user space. And supporting them in the kernel
opens up a new class of security and other problems.
I just don't see how to do 9spaces without ending
up with Plan 9 in Unix's clothing. Taste aside, that's
an enormous amount of work.
Russ
Roman V. Shaposhnick
> Many of the tools stand without the per-process
> namespaces. That's why I think the ported libraries
> would be useful. It's not clear to me how to implement
> something like 9spaces usefully. As Dave mentioned,
> Dong has built 9P support into FreeBSD, and now
> we know someone is doing one for Linux too. But there's
> still no per-process namespace. I started something
has been done at a kernel level already, but the real problem
is userspace. Thus, I guess that from 2.4 Linux will be an
ideal environment to do that kind of porting.
Thanks,
Roman.
Alexander Viro
Heh ;-) Three sets of patches before we get proper namespaces. Kernel
_does_ support everything needed right now, I'll just have to merge
union-mount patch and add a new flag to clone(2) (==rfork()). BTW, the
last set fed into the tree (hopefully to be there in pre7-7) includes the
equivalent of bind(2) and support for disjoint mount trees.
So you will get namespaces - I didn't look too deep into the porting that
work to 4.4, but for Linux the thing is coming. And it's cleaner than
1995 vintage Plan 9 one - e.g. our design handles ".." for any mount
graphs in the right way, ditto for pwd, etc. I'ld love to compare the
thing with current Plan 9 stuff - hopefully during the USENIX. So if
anybody is interested...
Douglas A. Gwyn
> Part of those plans include tidying up a
Please send me e-mail at my work address <gw...@arl.mil>
so I can send you our current "sam"'s libXg, which is
undoubtedly out of sync with the official one but has
some important improvements that should be merged in.
Ishwar Rattan
Russ Cox wrote:
> >only 3 substantial programmes written in Alef - acme, rio and the IP stack. The
> >IP stack found its way back into the kernel and the other two were converted to
> >use a new thread library.
>
> Does this mean Plan 9 peoples abandoned concurrent programming, and
> joined to the ordinal threading scheme? I'd like to know the reason...
>
> Concurrent programming is alive as ever,
> but is accomplished via a thread library for
> C that provides most of Alef's functionality
> (procs, tasks, buffered and unbuffered channels).
>
> The benefits are that there need not be
> two copies of each library now, and the programs
> are more easily portable to other architectures
> (there was no Alef compiler for the 68000, for
> instance) as well as other operating systems
> (the thread library has been ported to Linux).
^^^^^^^^^^^^^
Where can I find this port?
- ishwar
for...@vitanuova.com
>>graphs in the right way, ditto for pwd, etc. I'ld love to compare the
what is `the right way'?
Alexander Viro
See the comment in pwd(1) for the wrong one ;-) In our variant effect
of bind() can't be distinguished from the effect of fresh mount() - you
are getting a tree spliced onto the point in your namespace and that's it.
And no, we don't create a new dentry tree. The main idea being that we
added a new class of objects - mount nodes and use them to represent mount
linkage. Namespace is represented as a tree of mount nodes and each node
refers to a couple of dentries - mountpoint and root, that is. These
dentries belong to the forset - each tree comes from a filesystem and this
forest is the same for everyone. You have to deal with pairs (mount node,
dentry) to identify points in the namespace. That's the basic idea - doing
that required some changes to our data structures, etc., but pain was
surprisingly small. Implementing the namei(), bind(), etc. with these data
structures is more or less an obvious exercise. Union-mounts are done with
a special kind of mount node that anchors the cyclic list of components'
nodes. To avoid special-casing for covered directory we add into this list
a node with root equal to dentry of covered directory (in effect, bind the
covered directory into the union).
One difference being that our equivalent of bind() binds only the chunk
that contains the object we are binding. If /foo and /foo/bar/baz
are mountpoints and you bind /foo/bar onto /barf you will _not_ get
/barf/baz as a mountpoint. For one thing, if you want "recursive"
behaviour of bind() (a-la Plan 9 one) you can emulate it in userland,
unless there are _real_ loops. And these are rather bad idea - say ls -lR
and watch it running forever... In our case you can bind / onto /mnt and
that will not create any loops - you'll have the same effect as you would
get from mounting the root filesystem onto /mnt.
So there... I consider this tradeoff (non-recursive behaviour of bind())
worth the things it gives. YMMV. With that data structure per-process
namespaces become absolutely trivial - nothing cares whether the mount
nodes form a connected graph or not. So it's a matter of garbage-collector
(plain refcounting) and cloning the tree + switching your pwd, etc. in our
equivalent of rfork() (clone(2)). BFD...
If you need more details - feel free to ask, I'll be only happy to discuss
them. I'm really curious about the implementation in current Plan 9
kernel - would be interesting to compare...
There were rather, erm, funny moments - we had to support fchdir(2), for
one. And link(2). And full-blown rename(2) <stream of expletives>. Oh,
well - it took long, but it had been done...
rob pike
that contains the object we are binding.
I think this is a big conceptual mistake. It means that the effect of the bind
depends on the invisible underlying structure of the name space rather than
its visible appearance. Since the point of a name space is to give intuitive
names to arbitrary structure, your design is sure to confuse. Worse, I
think it negates the reasons for the exercise.
As an example, our /bin and /dev directories are complex union directories.
The ability to rebind /bin or /dev en masse is a boon for programs that wish
to construct private name spaces, for security or other purposes. In your
world, programs that wish to do this must reconstruct the union directories,
a serious obstacle for things like shell scripts.
I understand your desire to avoid loops, but a) it's easy to make the tools
that walk trees robust against loops and b) it's not nearly as big a deal as
you think (well, your phrase is "rather bad", hardly a rallying cry in support
of your design). You're second-guessing yourself into a confusing situation,
appealing to the implementation to argue for the behavior you provide
instead of offering transparent, clean behavior.
-rob
dh...@plan9.bell-labs.com
> Heh ;-) Three sets of patches before we get proper namespaces. Kernel
> _does_ support everything needed right now, I'll just have to merge
> union-mount patch and add a new flag to clone(2) (==rfork()). BTW, the
> last set fed into the tree (hopefully to be there in pre7-7) includes the
> equivalent of bind(2) and support for disjoint mount trees.
How do you deal with the rather obvious security problems, eg:
$ bind passwd /etc/passwd
$ su - root
?
Do setuid programs get a fresh name space?
Note that Plan 9 doesn't have setuid...
Alexander Viro
On Tue, 9 May 2000 dh...@plan9.bell-labs.com wrote:
> vi...@math.psu.edu writes:
> > Heh ;-) Three sets of patches before we get proper namespaces. Kernel
> > _does_ support everything needed right now, I'll just have to merge
> > union-mount patch and add a new flag to clone(2) (==rfork()). BTW, the
> > last set fed into the tree (hopefully to be there in pre7-7) includes the
> > equivalent of bind(2) and support for disjoint mount trees.
>
> How do you deal with the rather obvious security problems, eg:
>
> $ bind passwd /etc/passwd
> $ su - root
For bind you need either to be root or to have write permissions on
object you bind onto. Maybe it's too conservative - hell knows, I wanted
to put the variant that would not open obvious holes. We can relax it
later, but for now that should be OK.
Alexander Viro
On Tue, 9 May 2000, rob pike wrote:
> One difference being that our equivalent of bind() binds only the chunk
> that contains the object we are binding.
>
> I think this is a big conceptual mistake. It means that the effect of the bind
> depends on the invisible underlying structure of the name space rather than
> its visible appearance. Since the point of a name space is to give intuitive
> names to arbitrary structure, your design is sure to confuse. Worse, I
> think it negates the reasons for the exercise.
Hmm... OK, so how do you deal with the situation when / is bound onto /mnt
and luser does chdir("mnt"); n times? You either have to open a DoS
(kernel memory exhaustion) _or_ forget what n was.
> As an example, our /bin and /dev directories are complex union directories.
> The ability to rebind /bin or /dev en masse is a boon for programs that wish
> to construct private name spaces, for security or other purposes. In your
> world, programs that wish to do this must reconstruct the union directories,
> a serious obstacle for things like shell scripts.
Having bind(1) able to reproduce that structure is trivial. So I don't
think that it's going to be a problem for scripts - none of your examples
actually would create a loop, so bind(1) would be quite happy. However,
> I understand your desire to avoid loops, but a) it's easy to make the tools
> that walk trees robust against loops and b) it's not nearly as big a deal as
> you think (well, your phrase is "rather bad", hardly a rallying cry in support
> of your design). You're second-guessing yourself into a confusing situation,
> appealing to the implementation to argue for the behavior you provide
> instead of offering transparent, clean behavior.
... I would like to know how do you deal with the situation described
above. The problem is not implementation-dependent. Again, I can provide
bind(1) that does the same thing as your bind(1) unless you are trying to
create a loop. And shell scripts don't do plain syscalls...
for...@vitanuova.com
i'm glad i asked.
Russ Cox
and luser does chdir("mnt"); n times? You either have to open a DoS
(kernel memory exhaustion) _or_ forget what n was.
You have users. They can do whatever they want.
The only difference between denial of service and
legitimate use is intent. You're trying to protect against
things that you can't fully, at the cost of crippling
the functionality. There are other ways to induce
kernel memory exhaustion too. The only way to
protect against all of them is to not let the users
do anything.
... I would like to know how do you deal with the situation described
above. The problem is not implementation-dependent. Again, I can provide
bind(1) that does the same thing as your bind(1) unless you are trying to
create a loop. And shell scripts don't do plain syscalls...
To avoid loops, keep a hash table of where you've
been, and don't go to places more than once. Use
some unique identifier (in Plan 9, the qid and mount
point; in Linux, the inode number perhaps?).
How would bind(1) reproduce the structure?
Is there a way to look at the current namespace?
What if the directories I bound before have been
unmounted from where they came from?
Russ
rob pike
and luser does chdir("mnt"); n times? You either have to open a DoS
(kernel memory exhaustion) _or_ forget what n was.
Resources will get used up. As with any abuse of system services, bind has
the potential to exhaust resources. That alone is not sufficient reason to reject
a design; otherwise fork() and malloc() wouldn't exist.
Having bind(1) able to reproduce that structure is trivial. So I don't
think that it's going to be a problem for scripts - none of your examples
actually would create a loop, so bind(1) would be quite happy. However,
Making the command do the work instead of the system call gets you
into the kind of problems that confuse people. If bind only works
cleanly as a command, then programs that call on it through the
library will behave differently from seemingly equivalent shell
scripts. Phooey. Why in the shell can I cd somewhere but not chdir
there? Because cd is a bucket of shell magic, but chdir is a system
call. Such distinctions don't make a system perspicuous.
This discussion is about implementation. Back up a level. What are
your goals? Plan 9's per-process name space builds on and interacts
with other system facilities to get its power. Linux doesn't have
user-level file systems, for example; what's the advantage? If all
you get is the ability to replace $PATH with a unioned /bin, it's not
worth the trouble. If on the other hand you want to build interesting
name spaces that can be shared across the network, as in Plan 9, your
design leaves a lot to be desired.
-rob
Alexander Viro
On Tue, 9 May 2000, Russ Cox wrote:
> Hmm... OK, so how do you deal with the situation when / is bound onto /mnt
> and luser does chdir("mnt"); n times? You either have to open a DoS
> (kernel memory exhaustion) _or_ forget what n was.
>
> You have users. They can do whatever they want.
> The only difference between denial of service and
> legitimate use is intent. You're trying to protect against
> things that you can't fully, at the cost of crippling
> the functionality. There are other ways to induce
> kernel memory exhaustion too. The only way to
> protect against all of them is to not let the users
> do anything.
>
> ... I would like to know how do you deal with the situation described
> above. The problem is not implementation-dependent. Again, I can provide
> bind(1) that does the same thing as your bind(1) unless you are trying to
> create a loop. And shell scripts don't do plain syscalls...
>
> To avoid loops, keep a hash table of where you've
> been, and don't go to places more than once. Use
> some unique identifier (in Plan 9, the qid and mount
> point; in Linux, the inode number perhaps?).
?
Excuse me? "Don't go" as in? Again,
cat crash_it <<EOF
#!/bin/sh
cd /
while true; do cd mnt; done
EOF
chmod +x crash_it
bind / /mnt
./crash_it
- at which point is it supposed to fail and in which way?
> How would bind(1) reproduce the structure?
> Is there a way to look at the current namespace?
Currently cat /proc/mounts, but it will move into different place.
> What if the directories I bound before have been
> unmounted from where they came from?
And? You bind it from the place where it is bound _to_ and to heck
with where it came from.
Anyway, /me whistles and adds recursive bind(), which fails with -ELOOP if
you are trying to create one, clones the subtree of mount tree othervise.
There are races I don't want to think of right now and in the kernel I can
make it atomic to needed degree. I still think that it will end up in
userland, but that will require more accurate looking into the thing.
I still would like to see a use for loop-creating bind (oriented loop,
that is).
Alexander Viro
On Tue, 9 May 2000, rob pike wrote:
> Making the command do the work instead of the system call gets you
> into the kind of problems that confuse people. If bind only works
> cleanly as a command, then programs that call on it through the
> library will behave differently from seemingly equivalent shell
> scripts. Phooey. Why in the shell can I cd somewhere but not chdir
> there? Because cd is a bucket of shell magic, but chdir is a system
> call. Such distinctions don't make a system perspicuous.
OK, here you obviously have a point. Recursive variant added, returns
-ELOOP on loop creation.
> This discussion is about implementation. Back up a level. What are
> your goals? Plan 9's per-process name space builds on and interacts
> with other system facilities to get its power. Linux doesn't have
> user-level file systems, for example; what's the advantage? If all
First of all, it has, but that's not a real point. The thing I've
described came from the need to clean VFS up and close a bunch of really
unpleasant races. The fact that it gives something rather similar to
namespaces was a win, but frankly, I've realized where it was moving to
pretty late in the game.
There is a bunch of stuff that immediately wins from that. Horror knows as
devfs, for one. Another monster: Linux procfs. Been there, cleaned parts
of that and it was _not_ a pretty work. It also allows to keep the whole
directory tree in dcache (seriously cuts down on the cruft, removes a lot
of code duplication), etc.
Filesystems in the kernel are getting more light-weight than they used to
be and that's a good thing, e.g. because that allows drivers to populate
their own small trees without bothering with a lot of mess. And if you
will look at the contents of /proc on a Linux box you'll see why it is a
Good Thing(tm) for us - taking the bloody thing apart would be a big win.
IOW, what happens is a big cruftectomy. Since results happen to resemble
the stuff you've done in Plan 9 I'm obviously interested in looking into
your ideas - you've been in these places and have a pretty rare thing.
Taste, that is...
> you get is the ability to replace $PATH with a unioned /bin, it's not
Ahem... Thank you, but there are more serious needs.
> worth the trouble. If on the other hand you want to build interesting
> name spaces that can be shared across the network, as in Plan 9, your
> design leaves a lot to be desired.
Maybe. Again, the main goal was to clean the things up and fix a bunch of
very unpleasant holes. The fact that results resemble namespaces was,
well, interesting enough. If we can do per-process namespaces easily
(read: it comes for free) - well, why not? I can see uses for that beyond
the extermination of $PATH. I certainly see uses for these mechanisms in
the kernel. And doing userland filesystems is definitely possible - such
things exist.
Mark C. Otto
I'm not sure but hasn't Limbo replaced Alef as the concurrent system
programming language?
mco
owner...@cse.psu.edu wrote:
>
> From: oka...@granite.cias.osakafu-u.ac.jp@cse.psu.edu on 05/08/2000 12:55
> PM ZE9
>
> Please respond to 9f...@cse.psu.edu
>
> To: 9f...@cse.psu.edu
> cc:
> Subject: Re: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
>
> >only 3 substantial programmes written in Alef - acme, rio and the IP
> stack. The
> >IP stack found its way back into the kernel and the other two were
> converted to
> >use a new thread library.
>
> Does this mean Plan 9 peoples abandoned concurrent programming, and
> joined to the ordinal threading scheme? I'd like to know the reason...
>
> Kenji
Douglas A. Gwyn
> ... Why in the shell can I cd somewhere but not chdir there?
> Because cd is a bucket of shell magic, but chdir is a system
> call. Such distinctions don't make a system perspicuous.
A couple of weeks ago we had yet another UNIX user get bit by
the combination of chdir("..") and symbolic links:
$ pwd
/a/b
$ cd ..
$ rm -rf b
$ pwd
/d
$ ls -l /a
... b -> /d/e ...
$ # Drat! I've just removed the wrong set of files, d/b!
It was this sort of thing, which occurs a *lot* when one maintains
multiple sets of similar files, that long ago drove me to change
BRL's version of the Bourne shell to keep track of the current
working directory so that (a) "pwd" (shell builtin) reflected the
path that had been used to reach the CWD and (b) "cd" (shell
builtin) would handle a ".." path component by removing the deepest
preceding ordinary component (other details were also taken care of).
In actual use, this behavior was much nicer than the original
behavior (that merely passed cd's argument to kernel chdir() and
had to reconstruct a path for "pwd" by massive kludgery in user mode)!
From that experience I concluded that the current working directory
ought to be maintained by the kernel as a path, not (just) an inode
index, and chdir() should canonicalize the path as described above.
(There doesn't seem to be any need to test whether the target node
exists; that will turn up later when a file is opened.) getcwd()
then has a near-trivial implementation, and user-mode utilities
can implement "cd" and "pwd" by simply making system calls.
Sorry for the long story, but I think it has some bearing on the
question of the "right" way to do "bind" etc.
Noel Hunt
Can you describe what has been changed? There was some interesting
stuff in the jerq libraries in 8th Edition Unix, that never got
into libg and libXg, which `pads' relied on for instance...
Lucio De Re
>
> In actual use, this behavior was much nicer than the original
> behavior (that merely passed cd's argument to kernel chdir() and
> had to reconstruct a path for "pwd" by massive kludgery in user mode)!
>
> >From that experience I concluded that the current working directory
> ought to be maintained by the kernel as a path, not (just) an inode
> index, and chdir() should canonicalize the path as described above.
> (There doesn't seem to be any need to test whether the target node
> exists; that will turn up later when a file is opened.) getcwd()
> then has a near-trivial implementation, and user-mode utilities
> can implement "cd" and "pwd" by simply making system calls.
>
Sounds cool. No harm keeping the inode information at the same time,
as long as there's some way to tell that it is valid. Then one also
gets backwards compatibility. I like this concept, it broadens one's
scope without cramping one.
More interestingly, it neatly removes the need for ".." altogether,
doesn't it? And any ambiguity this may lead to. ".." can then
become merely a notation, extendable: "..." for two levels up, etc
(I think Novell first thought of that) and overloadable (hm, what if
I create a ".." or "..." entry to point to where _I_ want to go?!
> Sorry for the long story, but I think it has some bearing on the
> question of the "right" way to do "bind" etc.
Definitely food for thought. Other than kernel size, I see little
reason why this was not considered in the original specification
(except lack of vision long before hard and soft links were
introduced), and even less reason for not going in that direction.
++L
rob pike
Gwyn:
From that experience I concluded that the current working directory
ought to be maintained by the kernel as a path, not (just) an inode
index, and chdir() should canonicalize the path as described above.
Plan 9 does this now. I'm presenting a paper about path names in Plan 9
at the Usenix in June.
De Re:
More interestingly, it neatly removes the need for ".." altogether,
doesn't it?
Perhaps, but not in Plan 9, which still walks the ".." and then has an
algorithm to match the result with the path name generated lexically.
Details in June.
-rob