scott@conan.UUCP (Scott Weitzenkamp) (06/13/91)
We recently downloaded ISIS Version 2.1 from UUNET, and have sucessfully compiled it (on a Sun 4 running SunOS 4.0.3c) and printed the PostScript documentation. I am now trying to print some of the man pages. We have Transcript, but do not appear to have ditroff. Should we have ditroff? Is ditroff a part of SunOS and/or Transcript? For the sake of simplicity, I will refer to the directory we have ISIS in (/usr/local/isis/isisv2.1) as $ISIS. In $ISIS/man I see a script named "all" which runs "ditroff -man -P gossip" on all the relevant man pages (why is CC.1 included, by the way?). I am able to print most of the files (such as man1/isis.1) by using troff with a command like: "troff -t -man isis.1 | lpr -t". 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 problems lines in man3/ISIS.3 appear to start with stuff like The following are the ISIS manual pages included in section 3: .nf \bu ISIS -- general introduction to ISIS \bu address -- address manipulation routines \bu bcast -- basic broadcast interface \bu bcast_l -- extended broadcast interface \bu bypass -- bypass broadcast interface \bu cl_dump -- making human-readible status dumps within ISIS When I set MANPATH to include $ISIS/man, I get garbled output when I try "man 3 ISIS", too. I'm no troff wizard, so I'd appreciate any help or tips anyone can give me. I apologize if this is an old question, but we are ISIS novices (so far :-). 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? :-) :-) -- Thanks in advance... Scott Weitzenkamp, Talarian Corporation, Mountain View, CA uunet!talarian!scott (415) 965-8050 "Welcome to the late show, starring NULL and void" -- Men At Work
ken@CS.Cornell.EDU (Ken Birman) (06/13/91)
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
rcbc@cs.cornell.edu (Robert Cooper) (06/13/91)
In article <214@conan.UUCP>, scott@conan (Scott Weitzenkamp) writes: >Is ISIS really that bug-free and easy to use? :-) :-) Why don't you tell us after you've played with it for a while! -- Robert Cooper
rogere@ogicse.ogi.edu (Roger Ellingson) (06/14/91)
In article <1991Jun13.130855.3543@cs.cornell.edu> ken@CS.Cornell.EDU (Ken Birman) writes: >Now, as to whether ISIS is easy to use: the feedback we get on this >is basically very positive... >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......... Speaking from a research ISIS installation viewpoint: (no commercial ISIS experience) Agreed! We have just completed a graduate level distributed systems course here at OGI. Using ISIS for class project programming support has been a real boon for student implementation of distributed algorithms. (Comment: Until one tries to implement their own ordered communication support, they might not appreciate how much benefit ISIS is!) We have ISIS running on three different `sites', Sun, uVax, and Sequent, and have found it to be robust, well documented and simple to install and maintain. When and if trivial bugs have been discovered, the ISIS group at Cornell has been extremely prompt in explanation, suggested fixes, pointers, etc. The ISIS group has contributed and maintains a cohesive online set of related research papers which IMHO is unsurpassed in accommodating understanding both theory and implementation of key distributed programming abstractions---ordered multicast and corresponding communication groups. >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)... Still chomping on this one. >new tools (Levy's proposal on lightweight process groups, for example). Sorry, but is there a reference for the above proposal? Anyway, just one poor man's living testimonial, Roger Ellingson, rogere@cse.ogi.edu
hooft@prleds1.prl.philips.nl (Van Hooft PJG) (06/15/91)
In <1991Jun13.130855.3543@cs.cornell.edu> ken@CS.Cornell.EDU (Ken Birman) writes: >In article <214@conan.UUCP> scott@conan.UUCP (Scott Weitzenkamp) writes: >>Should we have ditroff? . . >>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. Perhaps breaking the \(bu-lines up, with the \(bu on a separate line, will help. -peter Peter van Hooft Philips Research Labs, Eindhoven, the Netherlands Email: hooft@prl.philips.nl SERI: HOOFT:NLWAYA01 Voice: +31 40744327 X400: /PN=p.j.g.vanhooft/O=research/PRMD=philips400/ADMD=400/C=nl/