jec@iuvax.cs.indiana.edu (02/19/88)
I have some questions about DOMAIN/OS that I think
us UNIX-type people would be interested in knowing about:
1. Will 'stty' work the way it works under UNIX?
2. Will a.out.h exist (and make sense) to programs
that depend on this sort of thing (Andrew from
CMU seems to need this, for instance)?
3. Will there be a /vmunix type of file so that
programs like xload will work?
4. Will there be an assembler?
5. Will you be able to disable dynamic libraries
so that things like 'undump' will work (TeX
distribution)?
6. Will source code be available to universities?
7. Will NFS allow files to be compiled and executed
from remote non-Apollo filesystems?
8. Will the /etc/passwd file be the real source of
account information and will it be in a readable
form? Will the password field contain the
encrypted password?
9. Will prsvr be replaced in favor of lpd (for
Berkeley printing) instead of lpd having to
rely on prsvr?
10. Will Pascal handle Berkeley pascal syntax?
11. Will subnetworking work?
12. Will NeWS/X be available?
III Usenet: iuvax!jec
UUU I UUU ARPANet: jec@iuvax.cs.indiana.edu
U I U Phone: (812) 335-7729
U I U U.S. Mail: Indiana University
U I U Dept. of Computer Science
UUUIUUU 021-E Lindley Hall
I Bloomington, IN. 47405
III (Home of the Indiana Hoosiers-- 1987 NCAA Basketball Champions)krowitz@mit-richter.UUCP (David Krowitz) (02/20/88)
Well, I can answer some things for you. There already is an assembler. It's been around for years. You have to ask for it. There is a manual listed in the documentation price list. According the the Educational Business manager, Pierre Bouchard, source code is available. This was discussed at the University SIG meeting at the last ADUS conference. Subnetting works. We've been using it for almost a year. (we're running the AEGIS TCP/IP distribution). X is available from ADUS. Both version 10 and version 11 are on the last ADUS catalog listing. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu mit-erl!mit-richter!krowitz@eddie.mit.edu mit-erl!mit-richter!krowitz@mit-eddie.arpa krowitz@mit-mc.arpa (in order of decreasing preference)
mishkin@apollo.uucp (Nathaniel Mishkin) (02/24/88)
In article <5400014@iuvax> jec@iuvax.cs.indiana.edu writes: > 1. Will 'stty' work the way it works under UNIX? Yes. In fact, the whole TTY code has been modified/rewritten to support standard Unix functionality. > 2. Will a.out.h exist (and make sense) to programs > that depend on this sort of thing (Andrew from > CMU seems to need this, for instance)? The compilers that ship with DOMAIN/OS generate object files in System V COFF format. This is not "a.out" format, but it is standard, and we needed/wanted the flexibility it offers. > 3. Will there be a /vmunix type of file so that > programs like xload will work? As I'm sure most people know, our kernel is not derived from either the AT&T or BSD Unix kernel source. Thus, while we have a file that fills exactly the same role as "/vmunix", it's likely not to be what you want. This feature falls into the same category as "/dev/kmem". We don't do it, but we have, or intend to have, procedural interfaces for doing the same thing. > 4. Will there be an assembler? Answered elsewhere. > 5. Will you be able to disable dynamic libraries > so that things like 'undump' will work (TeX > distribution)? Not something that I know of that we've considered. I imagine that one could always have bound in global libraries with programs, but perhaps that results in large object files. Seems like it'd be easy for us to make the global libraries available in "ar" format, but I don't think that's currently in our plans. > 6. Will source code be available to universities? Someone else answered this, but I don't know if that answer is correct. You'd have to check with someone who understand this sort of policy. > 7. Will NFS allow files to be compiled and executed > from remote non-Apollo filesystems? This limitation persists. The former (compilation) is conceptually easier to fix; the problem arises from the fact that the library that generates object files using mapping, rather than Stream I/O to do I/O. The latter (execution) is harder to deal with since programs are executed by mapping (parts of) the object file into the address space. Not an insurmountable problem, but one that can't be easily solved without some efficiency penalty (e.g. making the program loader copy the executable to a local temp file first). > 8. Will the /etc/passwd file be the real source of > account information and will it be in a readable > form? Will the password field contain the > encrypted password? Yes and yes. However, modifying the information will still not be done by editing "/etc/passwd". In short, this is the case because in networks of the size we support, such a scheme for maintaining account information is simply inappropriate. DOMAIN/OS supports a distributed, replicated Registry which contains all the logical contents of "/etc/passwd" (plus some more things, like information about who's allowed to change what account information). The Registry is implemented using NCS. Access and update of account information is done via NCS/RPC. The standard "getpw" calls have been reimplemented to make remote calls to Registry servers. > 9. Will prsvr be replaced in favor of lpd (for > Berkeley printing) instead of lpd having to > rely on prsvr? I don't have the answer here. > 10. Will Pascal handle Berkeley pascal syntax? Not that I know of. Will Berkeley Pascal support Apollo Pascal syntax :-) > 11. Will subnetworking work? Subnetting works and has worked for some time. > 12. Will NeWS/X be available? X will be at the core of the new DOMAIN/OS user environment. (The DM features/environment will continue to be supported, coexistent with X, for compatibility.) I have heard nothing about any plans to support NeWS, although if it's as wonderful, portable, and open as everyone says (I'm being serious, not cynical), I'm sure someone else could get it running on Apollos, if they haven't already. -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin
weber_w@apollo.uucp (Walt Weber) (02/25/88)
In article <5400014@iuvax> jec@iuvax.cs.indiana.edu writes: > > 9. Will prsvr be replaced in favor of lpd (for > Berkeley printing) instead of lpd having to > rely on prsvr? > You labor under a misconception which is quite common -- that our lpd implementation REQUIRES prsvr to be running. This is understandable, as the documentation makes this point quite clearly. The default /etc/printcap provided with domain/ix defines one printer (lp) which sends output to /com/prf for submission to the prsvr. This is to support printing from by both /com/sh users, as well as /bin/{sh,csh,ksh} users via their familiar commands, while respecting the restriction that only a single process can "own" a device for output. If you do not care about users using /com/prf and /com/prfd to submit print jobs, then you may dispense with prsvr for printers connected via serial lines. You will need to write your own printcap entry, just as you do for remote printers accessed via tcp/ip from within lpd. ...walt... -- Walt Weber PHONE: (617) 256-6600 x7004 Apollo Computer GENIE: W.WEBER Chelmsford, People's Republic of Massachusetts