Re: [9fans] Do we have a catalog of 9P servers?
If there were no real routers and the world still used bang paths you wouldn't be thinking about overlay networks the way you do. Does your thinking fall under the same category of fallacy? By the way, I think you have missed the meaning of raison d'etre. There is a necessity, a problem, somebody responds, solves the problem. NAT (or TCP/IP, or Plan 9) emerges. --On Saturday, November 15, 2008 11:57 PM -0700 andrey mirtchovski [EMAIL PROTECTED] wrote: 5. If you need NAT weigh the options of doing it. It may turn out that importing /net is the best choice for your application. Or it may turn out otherwise. /net has a raison d'etre--regular NAT, too. If regular NAT hadn't been invented you wouldn't be thinking in terms of regular NAT, therefore you wouldn't be needing NAT. Post hoc ergo propter hoc. (you'll find it under logical fallacy on wikipedia)
Re: [9fans] Do we have a catalog of 9P servers?
aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22 This is absolutely interesting. Upon reading trampoline(8) it seemed to me that port forwarding, or rather the more general case of _traffic_ forwarding, is being implemented outside of any NAT. And in this case you don't have an imported /net and the fabled transparency. The gateway is being tinkered with. I can't right away know whether any address translation is done--I don't have access to the source of trampoline(8) and the man page doesn't mention any such thing. Is your serving machine (_not_ gateway) using a non-routable or a routable IP address? If you say you're using this I trust it must be working well for SSH (that's the protocol you're forwarding, right?) Does it also work for non-passive FTP? The ugly NAT implementations, e.g. on Linux, that have been criticized on this thread are _mandated_ by RFC 1631 to deal with even non-passive FTP and other badly designed protocols that exchange network layer awareness at application layer (NAT does that by extending upwards into application layer). The criticism has largely been based on misunderstanding the circumstances and on the air of vainglory that seems to surround some 9fans (those funny gnu guys, eh?). as usual, plan9 lets you combine simple commands to provide all sorts of interesting functionality. Add to the above that the simple command line you use is mutatis mutandis available on nearly every UNIX clone: http://www.openbsd.org/faq/pf/rdr.html#tcpproxy This of course has nothing to do with real NAT and the complex requirements of hassle-free port forwarding. The poor man's proxy can be created with many combinations of user space tools. there you have it, port forwarding without the need to reset all your connections (my d-link router does it). My D-Link router's virtual servers, i.e. destinations for port forwarding, entries can be updated without any harm to existing connections. I presume either your router is irredeemably old or there's a glitch in the firmware that could be fixed by updating. Mine is a DSL-2500U, Linux-based. --On Saturday, November 15, 2008 10:15 PM -0200 Felipe Bichued [EMAIL PROTECTED] wrote: as usual, plan9 lets you combine simple commands to provide all sorts of interesting functionality. on my plan9 gateway i often have to do something like: aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22 there you have it, port forwarding without the need to reset all your connections (my d-link router does it). On Sat, Nov 15, 2008 at 8:07 PM, Eris Discordia [EMAIL PROTECTED] wrote: It would be helpful if you can quote exactly the part on which you are requesting my opinion. This part: It actually does qualify. I believe (though I could be wrong) state information and communication buffers are the biggest memory spending for network operations. There _could_ be a trade-off between the transient NAT with its processing power toll and the persistent /net-import with its memory cost. However, systems like FreeBSD pre-allocate and always keep a number of network buffers so the processing power toll for transience almost vanishes if the kernel is fine-tuned for its load. By contrast, on a large network /net-import strategy could make a powerful gateway unavoidable because every machine on the network will need a session with the gateway even if it only rarely communicates with the outside world, unless you implement an uglier-than-NAT client-side dial-on-demand. And this: There is a huge difference. Almost as much difference there is between NAT and RSVP. Where importing /net is compared to RSVP because it uses a persistent application layer overlay to do a job that is usually done with transient connections. In case of RSVP there's a motive to do that, in case of NAT, well, NAT solutions already exist and work pretty well--I've actually been saying that /net-imported may be useful (!= usable) for some applications I don't know about but very probably not for NAT. What field? Out of the field := clueless, a soccer player who follows the ball outside the field I am only familiar with Linux implementation. Which is only a small subset of iptables, right? Yes. And that's the NAT that *I* and a million Linux lemming out there are familiar with. Not right. As late as SuSE v9.0 people used the much lighter and less sophisticated masquerading ipmasq which didn't involve iptables (beginning with v10's iptables became the default). It was the Linux equivalent of the sort of half-assed NAT that importing /net will give you. Easy but incomplete. In case of iptables as I pointed out before you have at your disposal a very sophisticated tool--that you put the tool to uses it is too big for is mostly your fault. There are many other Linux NAT solutions that do NAT proper. data structures to do its job. I'll leave it up to you to see how much memory gets wasted on each connection. Do you claim
Re: [9fans] Do we have a catalog of 9P servers?
Eris, are you telling, that plan9 is not suited to all the problems of all badly designed and bloated software? Oh goddess, that's horrible. What is this thing you're searching for? Have you tried it with XML?
Re: [9fans] Do we have a catalog of 9P servers?
NAT's raison d'etre is that IP is broken, NAT doesn't completely solve this problem, and creates a whole new set of problems that will plague the world until a new version of IP can be deployed (which interestingly enough, is made much more complicated by the prevalence of NAT itself). In the meantime Plan 9 and /net make it much easier to work around IP's limitations because network stacks can be shared easily across systems, and much more importantly by being completely network protocol agnostic, part of the beauty of importing /net is that you might not even be using IP to reach your gateway, and that applications don't care what network protocols either your local host or the gateway speak. The IP world has been trying to move to IPv6 for almost a decade, and it will be at least that long before the migration is done, plus it will be a painful and cumbersome process with lots of wasted resources along the way. In the Plan 9 world, migrating to a new network protocol is pretty much a non-issue, which as I think somebody pointed out, is not hard to accomplish over a weekend. Peace uriel P.S.: I have zero interest in discussing NAT or IPv6, if you are interested go watch the talks at Google's IPv6 conference, and you will see how much misery NAT is causing. On Sun, Nov 16, 2008 at 12:45 PM, Eris Discordia [EMAIL PROTECTED] wrote: If there were no real routers and the world still used bang paths you wouldn't be thinking about overlay networks the way you do. Does your thinking fall under the same category of fallacy? By the way, I think you have missed the meaning of raison d'etre. There is a necessity, a problem, somebody responds, solves the problem. NAT (or TCP/IP, or Plan 9) emerges. --On Saturday, November 15, 2008 11:57 PM -0700 andrey mirtchovski [EMAIL PROTECTED] wrote: 5. If you need NAT weigh the options of doing it. It may turn out that importing /net is the best choice for your application. Or it may turn out otherwise. /net has a raison d'etre--regular NAT, too. If regular NAT hadn't been invented you wouldn't be thinking in terms of regular NAT, therefore you wouldn't be needing NAT. Post hoc ergo propter hoc. (you'll find it under logical fallacy on wikipedia)
Re: [9fans] Do we have a catalog of 9P servers?
On Sun, Nov 16, 2008 at 8:39 PM, Eris Discordia [EMAIL PROTECTED] wrote: aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22 And in this case you don't have an imported /net and the fabled transparency. Obviously, a linux server is going to have a hard time importing /net (in a useful way, at least until Glendix gets there). -sqweek
[9fans] nat
Obviously, a linux server is going to have a hard time importing /net (in a useful way, at least until Glendix gets there). i've got a lot of folk in the house who run whatever. i'd really like to decommission the non-plan 9 machine. the one thing i need from it is nat. (and i don't want to be stuck fiddling more stuff on the dsl appliance.) doing nat just isn't that hard. i just need to find the time. this is about a summer-of-code sized project. i don't think it would require anything from the kernel. - erik
Re: [9fans] nat
i've got a lot of folk in the house who run whatever. i'd really like to decommission the non-plan 9 machine. the one thing i need from it is nat. (and i don't want to be stuck fiddling more stuff on the dsl appliance.) doing nat just isn't that hard. i just need to find the time. this is about a summer-of-code sized project. i don't think it would require anything from the kernel. I beg to differ. NAT adds complications to the already complex IP. Adding NAT to the Plan 9 IP stack can only make it more fragile, why not leave the job to the appliances that have been designed and constructed to deal with the problem and have been subject to very broad testing? ++L
Re: [9fans] nat
perhaps you forgot to read the part where i said i don't think this would require anything from the kernel; the ip would not need modification. OK, I read it and promptly forgot it because none of the canonical implementations of NAT I am familiar with seem to be able to operate without kernel help. Such canonical implementations tend to hook onto the routing code (I'm not an authority, but I used to pay a lot of attention to these details in a previous life) and are often carefully micro-optimised because NAT (and IP filtering) tends to be quite resource-intensive. Running NAT at user level would, assuming I'm not totally off base, be quite expensive and the hardware on which it runs would have to be pretty powerful. To crown it all, NAT still interferes very negatively with some of the more modern protocols (VoIP comes to mind, but I have only a superficial understanding, so please take this with a pinch of salt) and special arrangements have to be made to deal with the problem. Eris raised that question for FTP, a well-known example of NAT's shortcomings, no matter where it is shoehorned. In my opinion, in Unix proxies are better solutions and in Plan 9 we all know what to look for. For the traditional workstation configurations, there is no easy answer. What do you (Coraid?) use NAT for, exactly? ++L
Re: [9fans] Do we have a catalog of 9P servers?
Eris, are you telling, that plan9 is not suited to all the problems of all badly designed and bloated software? Oh goddess, that's horrible. What is this thing you're searching for? Have you tried it with XML? Yes and no. The badly designed and bloated software is in large part a relic of Bell Labs' previous experimentation with numerous people's graffiti on it. I have no reason to believe Bell Labs' not-so-current experimentation is any more saintly and free of blemish than the previous. In time somebody will come up with the Plan 9 Haters Handbook. Perhaps you can give this book a try on the subject of Bell Labs' infallibility: http://www.privateline.com/Gehani/index.htm If someone at Bell Labs reads this I will be very much grateful if they tell the list and me about what happened to ODE. --On Sunday, November 16, 2008 1:49 PM +0100 hiro [EMAIL PROTECTED] wrote: Eris, are you telling, that plan9 is not suited to all the problems of all badly designed and bloated software? Oh goddess, that's horrible. What is this thing you're searching for? Have you tried it with XML?
Re: [9fans] nat
Running NAT at user level would, assuming I'm not totally off base, be quite expensive and the hardware on which it runs would have to be pretty powerful. most people have plenty of power to spare on their cpu servers and feeding a dsl modem at 10mbit/sec is really trivial these days. were you thinking of natting 1gbit? - erik
Re: [9fans] Do we have a catalog of 9P servers?
[...] NAT's raison d'etre is that IP is broken [...] That's very far from truth. In this case IP's only fault is lack of exceptional foresight. Who'd think someday every kids' toy would claim a network address? As for NAT, you know very well it has uses entirely unrelated to IP's limitations. systems, and much more importantly by being completely network protocol agnostic, part of the beauty of importing /net is that you I believe every application layer protocol ought to be, and most of them are, network protocol agnostic. Nothing miraculous there--it's just following the basic guidelines of layered network design. Except perhaps 9P's simplicity has allowed it to make fewer assumptions about the underlying network, no doubt because it has never been deployed in real-world situations (BG/L and Coraid don't count). The IP world has been trying to move to IPv6 for almost a decade, and it will be at least that long before the migration is done, plus it will be a painful and cumbersome process with lots of wasted resources along the way. What keeps the world from migrating is first and foremost inertia: IPv4 just does the job, creating some adventures every once in while. There's also the problem of appliances with their proprietary software. From the mainstream-OS standpoint by the end of 2002 every major operating system featured a IPv6 stack. The last one to catch up was Windows whose production quality stack didn't come out until Vista (actually it was present in WS2K3, but that's a different story). 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. In the Plan 9 world, migrating to a new network protocol is pretty much a non-issue, which as I think somebody pointed out, is not hard to accomplish over a weekend. 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? *BSD's case took some years and many dedicated developers to come to fruition. Plan 9's case is still in the making. Try this: http://www.google.com/search?q=ipv6+site:9fans.net P.S.: I have zero interest in discussing NAT or IPv6, if you are interested go watch the talks at Google's IPv6 conference, and you will see how much misery NAT is causing. Okay. That you have cared to write a response is kind enough. Thank you. --On Sunday, November 16, 2008 2:25 PM +0100 Uriel [EMAIL PROTECTED] wrote: NAT's raison d'etre is that IP is broken, NAT doesn't completely solve this problem, and creates a whole new set of problems that will plague the world until a new version of IP can be deployed (which interestingly enough, is made much more complicated by the prevalence of NAT itself). In the meantime Plan 9 and /net make it much easier to work around IP's limitations because network stacks can be shared easily across systems, and much more importantly by being completely network protocol agnostic, part of the beauty of importing /net is that you might not even be using IP to reach your gateway, and that applications don't care what network protocols either your local host or the gateway speak. The IP world has been trying to move to IPv6 for almost a decade, and it will be at least that long before the migration is done, plus it will be a painful and cumbersome process with lots of wasted resources along the way. In the Plan 9 world, migrating to a new network protocol is pretty much a non-issue, which as I think somebody pointed out, is not hard to accomplish over a weekend. Peace uriel P.S.: I have zero interest in discussing NAT or IPv6, if you are interested go watch the talks at Google's IPv6 conference, and you will see how much misery NAT is causing. On Sun, Nov 16, 2008 at 12:45 PM, Eris Discordia [EMAIL PROTECTED] wrote: If there were no real routers and the world still used bang paths you wouldn't be thinking about overlay networks the way you do. Does your thinking fall under the same category of fallacy? By the way, I think you have missed the meaning of raison d'etre. There is a necessity, a problem, somebody responds, solves the problem. NAT (or TCP/IP, or Plan 9) emerges. --On Saturday, November 15, 2008 11:57 PM -0700 andrey mirtchovski [EMAIL PROTECTED] wrote: 5. If you need NAT weigh the options of doing it. It may turn out that importing /net is the best choice for your application. Or it may turn out otherwise. /net has a raison d'etre--regular NAT, too. If regular NAT hadn't been invented you wouldn't be thinking in terms of regular NAT, therefore you wouldn't be needing NAT. Post hoc ergo propter hoc. (you'll find it under logical fallacy on wikipedia)
Re: [9fans] Do we have a catalog of 9P servers?
Obviously, a linux server is going to have a hard time importing /net (in a useful way, at least until Glendix gets there). Of course, which means dependence of network layer operations on an application layer protocol in a heterogeneous--you aren't plan9ing to take over the world, are you?--is most meaningless and non-standard. --On Monday, November 17, 2008 12:09 AM +0900 sqweek [EMAIL PROTECTED] wrote: On Sun, Nov 16, 2008 at 8:39 PM, Eris Discordia [EMAIL PROTECTED] wrote: aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22 And in this case you don't have an imported /net and the fabled transparency. Obviously, a linux server is going to have a hard time importing /net (in a useful way, at least until Glendix gets there). -sqweek
Re: [9fans] Do we have a catalog of 9P servers?
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
Re: [9fans] nat
most people have plenty of power to spare on their cpu servers and feeding a dsl modem at 10mbit/sec is really trivial these days. were you thinking of natting 1gbit? Needless to say, very capable (Linux-based) DSL modems with highly configurable built-in switch, router, NAT, and firewal are dirt cheap. Why not use one? Use D-Link and you can buy two for the price of one ;-) If you are brand-sensitive try Linksys or Netgear, though they are known to be picky. In case you insist on implementing NAT I assure you that you have at least one intent reader for any comments on how implementing NAT on Plan 9 differs from UNIX clones. --On Sunday, November 16, 2008 11:49 AM -0500 erik quanstrom [EMAIL PROTECTED] wrote: Running NAT at user level would, assuming I'm not totally off base, be quite expensive and the hardware on which it runs would have to be pretty powerful. most people have plenty of power to spare on their cpu servers and feeding a dsl modem at 10mbit/sec is really trivial these days. were you thinking of natting 1gbit? - erik
Re: [9fans] Do we have a catalog of 9P servers?
I have no reason to believe Bell Labs' not-so-current experimentation is any more saintly and free of blemish than the previous. In time somebody will come up with the Plan 9 Haters Handbook. Surely, there has been enough traffic here to emphasise that Plan 9 contains some good, fresh ideas in many cases to address Unix's original failures of vision? The perfect operating system isn't even a pipe dream, specially when hardware converges to a lowest-common-denominator variety of CPU design with legacy going back generations and the common consensus is to inflate the kernel with as many features as it can possibly contain, irrespective of their actual merit, nevermind their mutual incompatibilities. Plan 9 is not saintly and I fail to see how you could have arrived at the perception that anyone here considers it so. Our own frustration (mine, at any rate) is that none of the more popular alternatives to Plan 9 has geared itself up to discard, as Plan 9 has, the baggage that makes Unix an inferior operating system and worse, that by refusing to see the need to do so the Unix-perpetuating community is condemning users to suffer unnecessarily. In this respect Plan 9 shows some of the way, it is annoying that it goes largely unacknowledged, specially as this becomes an obstacle to any further research in that direction. Information Technology has always been very complex and consequently prone to failures; sometimes spectacular failures, more often at the level of mere inconveniences. At the same time, computing power has increased phenomenally, making it possible for information technologists to aspire to grandiose products. The nett effect is an impossibly huge quantity of software of very dubious quality, partially moderated by the audience that uses it, an audience that is hardly competent to judge its quality and, worse, is conditioned to accept mediocre products because it is not aware of any alternatives. For that matter, there may be no alternatives, but that is a self-perpetuating situation. Ii is no more than a delusion that the audience will supply the quality, a delusion originating from the sheer magnitude of the audience. The result: Windows, Linux, FreeBSD and all the other offerings in diminishing popularity. Plan 9, initially, bucked this trend, aiming for simplicity and accuracy rather than quantity. Sadly, that's not a great survival trait _in_the_current_context_. Reminds me of the Great Reptiles. They ruled the world until conditions demanded different properties (furry skin? small size? warm blood? viviparous? whatever) and then they perished. My hope is that Plan 9 is more like a small furry mammal than something destined for estinction. But that is because I have considerable investment, technical and emotional, in it, not because it is a holy grail. I approve of its new properties and, being somewhat more discriminating than Mother Nature (or Natural Selection), I believe they are improvements in an abstract, not just, maybe not even, in a pragmatic, survival-oriented fashion. Maybe I'm looking at esthetics when the rest of the world is looking for performance. In my philosophy, civilisation is the ability to transcend the practical and seek something more satisfying; mathematics is more beneficial than physics, Plan 9 is more beautiful than Linux. But not saintly, not perfect, not the product of infallible wisdom. Not even more useful, any more than, say, Michelangelo's David is useful. Plan 9 is the product of artistry, the best I have been exposed to, which is not to say that there aren't sculptures out there that may be deemed greater than Michelangelo's. But, in a subjective fashion, Plan 9 is better than the obvious contenders, where it is clear that the developers have followed totally different esthetic principles and, sadly, have overlooked certain fundamentals that are in my opinion totally non-negotiable simply because they have been revealed and shown to be valuable. You want something else, you're extremely lucky to exist in a world with many choices. Make the most of them. ++L
Re: [9fans] Do we have a catalog of 9P servers?
On Sun, Nov 16, 2008 at 9:17 AM, erik quanstrom [EMAIL PROTECTED] wrote: 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. I don't think the main point is simplicity, although it is nice. The big point to me: network object names are not binary objects but pathnames. Which is why a 386 can mount /net from a ppc and dump the routing tables. With a shell script. So, as has been pointed out many times: 1. Cost to migrate all unix apps to ipv6: let's just say high -- we won't know until they've all moved. 2. Cost to migrate all unix apps to infiniband addresses with 20-octet MAC addresses: high. SIX YEARS LATER, you still have to manually patch all of dhcpd to manage 20-octet MAC addresses. And some parts of the Linux kernel still dont' always agree with other parts about what an IB mac address looks like. 3. Cost to migrate Plan 9 apps to either of these: *zero*. They're pathnames. I still recall how unhappy many of us were when we got BSD sockets with binary names. It was just nausea-inducing. It didn't have to be that way: /dev/tcp was being worked on for Unix at the time, but it just didn't quite work out. /proc was in the future at that point ... Plan 9 restored sanity: names of things are paths, not obscure binary structures that could not be used without htons and their ilk. But the brokenness of the bsd interface is so ingrained that most people take it for granted: you can't name a socket like you name a file -- who says? ron
Re: [9fans] Do we have a catalog of 9P servers?
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 [EMAIL PROTECTED] 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
Re: [9fans] Do we have a catalog of 9P servers?
Finally, one very remarkable remark sighs deeply. Ron Minnich clarifies what _is_ indeed the advantage of Plan 9. I hope those who have followed this thread so far at last see what I was driving at. The edge of Plan 9 was never in kernel space but in user space. To put it in the abstract terms I understand: existence of a neutral scheme of networking is the _one_ and _only_, and _huge_ advantage of Plan 9. It is not coding practice, clarity of vision, being favored by hackers of the old, protocol X of Y repute, ease of implementing a protocol, or any other obscure, subjective non-technicality that distinguishes your beloved OS, 9fans--it's the complete network neutrality of the OS. UNIX invented pipes that originally began and ended on one machine (ever wondered why everyone remembers UNIX with pipes?). That was application neutrality of I/O (what is a computer's most important task? to transmute I till it's O). Plan 9 invented pipes that began and ended on any machine. That was network (and application) neutrality of I/O. The next step towards free-form computing. Thank you very much, Ron Minnich. I am edified. --On Sunday, November 16, 2008 10:01 AM -0800 ron minnich [EMAIL PROTECTED] wrote: On Sun, Nov 16, 2008 at 9:17 AM, erik quanstrom [EMAIL PROTECTED] wrote: 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. I don't think the main point is simplicity, although it is nice. The big point to me: network object names are not binary objects but pathnames. Which is why a 386 can mount /net from a ppc and dump the routing tables. With a shell script. So, as has been pointed out many times: 1. Cost to migrate all unix apps to ipv6: let's just say high -- we won't know until they've all moved. 2. Cost to migrate all unix apps to infiniband addresses with 20-octet MAC addresses: high. SIX YEARS LATER, you still have to manually patch all of dhcpd to manage 20-octet MAC addresses. And some parts of the Linux kernel still dont' always agree with other parts about what an IB mac address looks like. 3. Cost to migrate Plan 9 apps to either of these: *zero*. They're pathnames. I still recall how unhappy many of us were when we got BSD sockets with binary names. It was just nausea-inducing. It didn't have to be that way: /dev/tcp was being worked on for Unix at the time, but it just didn't quite work out. /proc was in the future at that point ... Plan 9 restored sanity: names of things are paths, not obscure binary structures that could not be used without htons and their ilk. But the brokenness of the bsd interface is so ingrained that most people take it for granted: you can't name a socket like you name a file -- who says? ron
Re: [9fans] Do we have a catalog of 9P servers?
I think Eris is saying that this makes Plan 9's resource requirements grow with the number of hosts behind the gateway -- not just with the number of connections through it like Linux. I don't quite follow. If by resources you mean process related resources than I would agree. My very first comment didn't have anything to do with process related resources. I did mean the extra processes, and I assumed that was what Eris was referring to. And for the TCP related resources I maintain that the amount of overhead in Plan9's case is definitely comparable to a Linux's case. Right. Micah
[9fans] failed exportfs
I'm missing something really obvious. I want to export part of my local namespace to do this I run: aux/listen1 -tv tcp!*!1979 exportfs -S /srv/npesurv listen started incoming call for tcp!*!1979 from 66.112.249.148 in /net/tcp/40 when I try to mount I get: term% 9fs tcp! myserver!1979 post... srv tcp!myserver!1979: mount failed: EOF receiving fversion reply what am I messing up?
Re: [9fans] failed exportfs
On Mon, Nov 17, 2008 at 9:14 AM, Noah Evans [EMAIL PROTECTED] wrote: aux/listen1 -tv tcp!*!1979 exportfs -S /srv/npesurv term% 9fs tcp! myserver!1979 post... srv tcp!myserver!1979: mount failed: EOF receiving fversion reply You need /bin/exportfs, aux/listen1 doesn't search the path. -sqweek
[9fans] anybody have the latest hugs port?
Hi all Anybody have the latest hugs port? I looked through some changelog from andrey port to the latest Sept2006. There doesnt seem to be much of an update that I actually need, but I wanted to ask incase I decide to update andreys port. As an update I ported the vscm a R4RS bytecode scheme/lisp. I also updated the umb-scheme port to support sparse matrix. Not really tested to do anything, but it compiles under ape :) fernan -- http://www.fernski.com
Re: [9fans] Do we have a catalog of 9P servers?
That isn't happening. All we have is one TCP connection and one small program exporting file service. I see. But then, is it the small program exporting file service that does the multiplexing? I mean, if two machines import a gateway's /net and both run HTTP servers binding to and listening on *:80 what takes care of which packet belongs to which HTTP server? The Plan 9 kernel doesn't do load balancing like that. (Why should it?) To do it in Plan 9, you'd write a small program that listened on a particular address and multiplexed connections to a list of other addresses. It wouldn't be hard -- aux/trampoline is halfway there. I think you're still thinking of importing /net in terms of NAT. It can be used to solve some of the same problems, but it isn't the same at all. Exportfs (the small program above) doesn't know that it's exporting a network stack or any kind of special files because the files in /net aren't special. The network stack doesn't know it's being used by a different computer -- it just sees exportfs reading and writing its files. The HTTP server doesn't know it's using somebody else's network stack, it's just reading and writing files in /net that it expects to work a certain way. The only component that knows there's a network stack being forwarded from one machine to another is the person at the controls. This is nothing like NAT. No packets are rewritten, and no code exists solely to support one computer using another's network stack. So FTP and other protocols that frustrate NAT work without special treatment. The same principal obviates the need for port forwarding. (In Plan 9 networks, that is.) Micah
Re: [9fans] those funny gnu guys
* erik quanstrom [EMAIL PROTECTED] wrote: Hi, this is just stupifying: http://tech.slashdot.org/comments.pl?sid=1029797cid=25761431 gcc is a mess, right. But is there an usable alternative ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ -
[9fans] D-Bus ...
Hi folks, I'm just curious what you think about D-Bus ... http://www.freedesktop.org/wiki/Software/dbus cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] D-Bus ...
im a linux developer but i hate it... On Mon, Nov 17, 2008 at 2:35 PM, Enrico Weigelt [EMAIL PROTECTED] wrote: Hi folks, I'm just curious what you think about D-Bus ... http://www.freedesktop.org/wiki/Software/dbus cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- Lay low and nourish in obscurity
Re: [9fans] those funny gnu guys
On Mon, Nov 17, 2008 at 2:06 PM, Enrico Weigelt [EMAIL PROTECTED] wrote: * erik quanstrom [EMAIL PROTECTED] wrote: Hi, this is just stupifying: http://tech.slashdot.org/comments.pl?sid=1029797cid=25761431 gcc is a mess, right. But is there an usable alternative ? cu there is llvm im more inclined towards hacking on ACK though -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- Lay low and nourish in obscurity
