From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] Some Plan9 questions From: "Russ Cox" In-Reply-To: <20030211223619.29018.qmail@scsi1.moonshynecomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 11 Feb 2003 19:13:48 -0500 Topicbox-Message-UUID: 5852ffcc-eacb-11e9-9e20-41e7f4b1d025 > 1) My main question is how much compatibility is there between Plan9 and > other UNIX-based operating systems, like BSD, Linux, etc.? That includes > running applications that were developed for Linux, BSD, and UNIX systems in > general. > 2) If Plan9 does not run applications that other UNIX operating systems can > run, how hard is it to port the code over? > 3) How hard is it for someone who is coming from a more common UNIX OS to > get used to Plan9? This isn't an answer to any one of these questions but at the same time it addresses all of them. As Scott said, you have to come at Plan 9 with an open mind. System interfaces that are felt unnecessary or clunky are not implemented, and this makes Plan 9 nice but also makes it not Unix. ANSI C code typically is easy to compile. Once you get into heavily POSIX code, things get harder. The graphics and networking models are completely different (much simpler), so graphics code almost never ports, and network code only sometimes ports (if it uses select, you've got your work cut out for you, though APE can make that easier). I don't know what your level of interest in IRC is, but it's a good recent example. On most systems if you wanted an IRC client you'd just port some other IRC client and end up with an IRC client. But Plan 9 isn't really a good base for running external programs. There's no X11, there's only rudimentary cursor addressing, so you'd have to port a command-line program. (If you want to run a Unix program, that's what Unix is for.) The Plan 9 way to attack the problem would be to step back and wonder whether there was a simpler and/or more general interface that might be good. I occasionally use IRC and AIM and ICQ, and would like to be able to do so in Plan 9 rather than switching to Windows XP. I wrote an ICQ implementation six years ago, but it ran in a window by itself and I'd always forget about it, and it still didn't really fit well with the rest of the system. A few months ago I started thinking about this again, and have slowly (a few hours here and there, very occasionally) been building a generic chat file system interface: /* * Chat file system. Conventionally mounted on /net to provide /net/chat, * for some value of chat. * * clone open and read to obtain new connection * n connection directory * ctl control messages (like connect user) * data retrieved data * err last error * local local name * remote remote name or channel * status connection state * who list of people in chat room * ... other protocol-specific files * * The connect message typically takes the following possible addresses: * * #channel a channel * chat room a chat room * user a user * *snoop* all traffic * *mop* traffic with nowhere else to go * * It would be more true to form if there weren't a *mop* but instead * you announced chat!you and then listened for connections. * The *mop* is good enough. * * The data file returns messages one at a time. The messages are attr=value * lists that can be parsed with the attribute parsing routines in auth.h [sic]. * Typical attributes include: * * src who is sending the message * dst destination for message (you, a chat room) * cmd command being sent * args other arguments */ I have an IRC implementation of this pretty much done, and I plan to do an AIM TOC implementation too. Once you've got this as a building block, it's easy to build whatever interfaces you want on top of it. I have a fairly nice Acme gui pretty much done. (Because of Acme and win, it's hardly any code.) You could build a really simple gui using rio windows (using the same code, actually) with one window per conversation. In a pinch, con -l 'irc!#plan9' would work reasonably, and it's great for debugging. Another nice thing is that suppose you want to write some sort of 'bot. It could be something complicated, or something as trivial as logging a particular chat session (or all your chat sessions). Since all the programs can use the fs interface, none of them have to worry much about the details of connection setup or anything like that. And one connection can be shared between many programs without any extra effort. While there will probably be slight differences in syntax and the frills commands that can be executed on each network, the core interface is the same meaning that I'll have multiprotocol guis for free. I think the end result is that it will fit well with the rest of the system and be more pleasant to use than most standalone clients. > 6) Is there going to be another release? If so, any idea when? In a sense, the fourth edition release is the release to end all releases. System updates are now distributed via a Plan 9 file server on the internet, sources.cs.bell-labs.com. We put changes out much closer to as they occur than ever before. Some of us run generic installations as our day-to-day system, which provides incentive to keep sources and the internal Bell Labs system in sync. There are no really big changes planned at the moment. 9P2000 was the big addition for the fourth release and we're still coming to terms with a lot of that. If big changes happen down the road then maybe that would be another number. But releases in the small happen very frequently. Russ