From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 16 Nov 2008 18:08:24 +0000 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 466db28a-ead4-11e9-9d60-3106f5b1d025 > the trite "not reinventing the wheel" is countered with > the equally trite "use the right tool for the job". both > avoid the point of carefully evaluating the engineering > problem. Deprecating IL must have had engineering reasons. Among them, I guess, that in the course of time and as applications accumulated and became more complex it dawned on the developers that TCP had always had good reason to be as complex as it were. > tcp is the perl of networking. I happen to like Perl but they say liking Perl here is like being a leper. > i think it is a bit easier. the plan 9 kernel is simplier. > but that's beside the point. plan 9 network does more > with less than bsd. /net is more expressive than sockets. > the dial interface is quite elegant. plan 9 telnet works > just fine with il and most other connection-based protocols. You seem to forget--or am I gravely mistaken?--that the network layer occurs below /net not above it--which is why Plan 9 connections can remain network agnostic--so the expressiveness of /net abstraction (if it exists outside of subjective judgment) won't ease the pain of implementing a network layer protocol. Actually, the marginal (contrast with: the ubiquity of sockets) nature of the interface you need to present to layers atop the layer you are implementing will trouble you all along the way because few people know how to present that sort of interface, there has been little experimentation in that direction outside of the small community of Plan 9 researchers, and the people who designed the network layer protocol you are implementing were more or less enamored of another abstraction (again, sockets). For the specific case of dial, dial(3) says that transport may be explicitly specified (TCP, UDP, UNIX domain sockets, and "net") which means dial sees things from above transport layer, i.e. from the application layer. In other words if you were to implement IPv6 for Plan 9 you would have to implement either TCP6 or another IPv6 transport protocol as well. The diversity of transports available in Plan 9 should not leave the impression that one can get away with _no_ transports. So, it becomes unclear again where the advantage of Plan 9 for implementing a new network protocol is. Plan 9 may have many advantages, this isn't one of them. My impression is that its edges are mostly in newer areas of computing (this "cloud" computing thingy) and _almost certainly_ not in areas already explored and exhausted to the extreme. --On Sunday, November 16, 2008 12:17 PM -0500 erik quanstrom wrote: >> And what is the "IP world?" Aren't you part of it? Does your network use >> a different transport/network layer protocol than TCP/IP? IL is >> dead--just in case you were thinking of it--because to re-invent the >> wheel was eventually perceived redundant. > > yes. several. il/ip being one of them. > > the trite "not reinventing the wheel" is countered with > the equally trite "use the right tool for the job". both > avoid the point of carefully evaluating the engineering > problem. > > tcp is the perl of networking. > >> I see no reason why implementing IPv6 for Plan 9 has to be easier than >> the same task on *BSD. What does Plan 9's dubious claim to superior >> design as an OS have to do with implementing a network layer protocol? > > i think it is a bit easier. the plan 9 kernel is simplier. > but that's beside the point. plan 9 network does more > with less than bsd. /net is more expressive than sockets. > the dial interface is quite elegant. plan 9 telnet works > just fine with il and most other connection-based protocols. > > - erik > >