From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: a@9srv.net To: 9fans@cse.psu.edu Subject: Re: [9fans] cpu server In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Date: Sat, 7 Feb 2004 17:26:33 -0500 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: d166acfa-eacc-11e9-9e20-41e7f4b1d025 wow, charles. excelent write-up. just a few additions i'm compelled to make, based on recent experience and first impressions. when i was first exposed to plan 9, i was a unix admin. the very first thing that struck me about it was /lib/ndb. plan 9 was build with networks in mind, and as such the handling of them is so far superior to, well, everything else as to be operating at a different level entirely. no more changing host names in 3-5 different places, no more worrying about if my dns data was synched with my arp data and so on. designing the system around the idea of being network-centric meant dealing with and organizing a network was simple, even when not making use of the advanced networking capabilities the system presents. the small stuff falls out of doing doing the big stuff right. a few days later i had my second big "whoa" moment with plan 9 while while looking at aux/listen. tcp7 and tcp9 just blew my mind. i could write network listeners! in like three lines!!! wereas something like xinetd is (arguably; or not) an incremental step up from inetd on modern unix systems, aux/listen is something else entirely. i've written cross-protocol port forwarding in two lines of shell code. the amount of times since then that i've wished for aux/listen on whatever unix i was working on at the time is beyond number. it's not just incremental; it's totally different. and it works stand-alone, too. again: the small stuff falls out of doing the big stuff right. and plan 9 does the big stuff right. =E3=82=A2