Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zephyr.ens.tek.com!uw-beaver!cornell!ken From: ken@CS.Cornell.EDU (Ken Birman) Newsgroups: comp.sys.isis Subject: Re: printing ISIS 2.1 man pages Keywords: ditroff man Message-ID: <1991Jun13.130855.3543@cs.cornell.edu> Date: 13 Jun 91 13:08:55 GMT References: <214@conan.UUCP> Sender: news@cs.cornell.edu (USENET news user) Organization: Cornell Univ. CS Dept, Ithaca NY 14853 Lines: 105 Nntp-Posting-Host: turing2.cs.cornell.edu In article <214@conan.UUCP> scott@conan.UUCP (Scott Weitzenkamp) writes: >Should we have ditroff? ditroff is part of Sun release 4.1 and is actually a front end shell script that runs "itroff". In principle, troff -man should work too. ditroff is used to generate device-independent interpress, which is one of the various typesetting languages (like postscript), but you should be able to manage with just the "man" and "troff" commands. >I am having problems with some files such as man3/ISIS.3. When I try to >use troff on these files, I get semi-readable output with a lot of >garbled characters in it. The lines you showed use the special code for "bullet" (a dark circle). Sounds like you are missing a font file. Not being an expert on troff fonts lately, I am unsure that that file would be. But, I used nroff/troff for fifteen years before switching to latex and I think that ".nf" (no formatting) and "\(bu" are pretty vanilla stuff. My guess is that your configuration of SUN OS is somehow non-standard. Perhaps you should check to see if you actually have a copy of itroff around. > When I set MANPATH to include $ISIS/man, I get garbled output when I >try "man 3 ISIS", too. Probably the same problem -- a font file is wrong or not standard. I doubt that this has anything at all to do with ISIS. > Why is CC(1) included? Accidental. Someone copied it down, probably to mimic the format, and forgot to delete it. > > While we are just getting around to installing ISIS, we've been >receiving the newsgroup comp.sys.isis for over a year. I never seem >to see much traffic on comp.sys.isis, which make me very curious. Is >ISIS really that bug-free and easy to use? :-) :-) Yes and no. V2.1 is actually pretty solid, but over time problems have been found -- or introduced in several cases -- as new OS releases came out. For example, on your SUN OS system you will need to edit pr_client.c in protos and fix the "chmod" system call to use file mode 0666, and you probably just read about the business with pipes that don't break. V2.1 is old, though, and we have been working for a whole year now on extensions and improvements. By now I know of literally dozens of bugs in V2.1, most of which people don't actually run into unless they try and use BYPASS mode, but some of which are lurking and waiting to bite. We plan to do a V2.2 release sometime in the late summer or fall. Now, as to whether ISIS is easy to use: the feedback we get on this is basically very positive (hopefully some people will have emailed to you on this, but who knows). My sense is that we have a few hundred real users scattered around, perhaps 100 of these in commercial settings. I wouldn't say that ISIS turns out to be foolproof, because it is asking you to work with concurrency, lightweight threads (and stack size limits), dynamically allocated memory, and messages, and other things, and fault-tolerance. This isn't a particularly easy set of things to deal with, and even if ISIS makes it easier, lets face it: we aren't talking CS100 here... On the other hand, reasonably sophisticated, experienced programmers seem to find ISIS very straightforward and quite powerful. It certainly works effectively on the very hard aspect of this sort of distributed computing, and this is no other approach that comes close. Interestingly, I actually don't think there are any known V2.1 bugs in the protocols or the virtual synchrony model -- the key aspects of the system. The bugs we know about are more grungy kinds of things, like a failure to deal with someone removing /tmp/Isxxxx while the system is up... If you plan to use ISIS in any sort of commercial setting, I have to recommend that you use V3.0. Although the V2.2 release will fix some of the V2.1 limitations and problems, quite frankly, V2.2 is just a fixed up version of V2.1, while V3.0 is an actively used, actively supported system with ongoing development behind it. Free software has its hidden costs and if you work with V2.1 then in the long run, you will have to incur the costs of support, etc, that you aren't paying IDS to incur on your behalf. I've always been curious about this business of posting to comp.sys.isis. My conclusion is that the group has a lot of people who watch it more as a research curiosity. We do get a lot of email about bugs, etc, from people who use ISIS, but most bug reports get sent to isis-bugs@isis.com and not to the group -- which I would say is good, since nobody wants to read about some sort of silly mistake on the part of a user. You do hear about the bugs that might matter to people. The effect of all this is that comp.sys.isis seems to run in "Cornell multicast" mode. I would be happy to see more debate in this newsgroup, for example about how abcast should work when groups overlay (should multicasts to different groups be ordered in the overlap region, or is this unecessary), or about new tools (Levy's proposal on lightweight process groups, for example). But, realistically, most newsgroups don't work that way. comp.os.research gets mostly announcements of new tech reports, and comp.os.mach mostly gets postings asking about availability of Mach on the 386... at least we don't get too much of that! -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428