[net.sources] compare.F

jsq@ut-sally.UUCP (08/14/83)

                                     - 22 -



               System V  binary  licenses  are  available,   and   the
          Berkeley  distribution  is  also  available on two RK07 disk
          packs.

               For  those  unfamiliar  with  VAXen,   _I_n_s_t_a_l_l_i_n_g   _a_n_d
          _O_p_e_r_a_t_i_n_g   _4._1_C _B_S_D   contains  sections  on  VAX  hardware
          terminology and disk formatting which have  no  counterparts
          in  _S_e_t_t_i_n_g  _U_p  _t_h_e  _U_N_I_X _S_y_s_t_e_m (the System V installation
          guide).

               Both systems provide  a  disk  formatter.   The  _f_o_r_m_a_t
          command  provided with System V will format RP06 and RM03/05
          disks.  The formatter of 4.1C and  4.2  formats  almost  any
          non-DEC UNIBUS or MASSBUS drive, and also includes RM03s and
          RM05s, i.e., any disk with the BSC bit in  the  header.   It
          cannot  handle  RP06, RP07, or UDA50s, but the DEC formatter
          can do those.

               We had no real problems booting  either  system.   (The
          System III boot bugs seem to be fixed in System V.)

          3.2  Configuration

               Both systems are relatively easy to configure.

               System V includes driver support for  most  devices  of
          interest, including the RM05, RM80, and RP04/5/6/7 disks.

               4.1C BSD supports all of the  devices  just  mentioned,
          plus   many   others,   and   also   understands   the  full
          interconnection architecture of  the  VAX,  so  that  it  is
          possible to have, say, two RP06's on one MASSBUS and another
          on a second, and the system may be permitted  to  decide  at
          configuration time which MASSBUS's the RP06's are on.

               System V is configured by running  the  _c_o_n_f_i_g  program
          against  a  system description file; entries in the file are
          checked against a list of supported devices in  /etc/master.
          The  _v_c_f  command  may  then  be  used in standalone mode to
          verify address  and  interrupt  information  in  the  kernel
          object against the actual hardware present on the system.

               4.1C and 4.2 are configured with a _c_o_n_f_i_g program  too,
          but  this  one  works markedly differently.  The sources are
          arranged in such a way that several different  kernels  (for
          the  same or different machines) can easily be made from the
          same  sources.   Things  such  as  network  node  names  are
          parameterized at run time so that the same kernel can easily
          run on several machines with the same CPU  and  peripherals.
          If  desired,  a  generic kernel (such as on the distribution
          tape) can be configured that will  find  likely  devices  at











                                     - 23 -



          startup.

               System V  still  requires  hand-setting   of   numerous
          parameters,  such  as the number of process, file, and inode
          table slots, while 4BSD (4.1 and later) decides  appropriate
          values for these parameters on the basis of one number:  the
          number of users the machine is  to  support.   (The  default
          rules can be overridden, of course.)

          3.3  Transition

               The transition from 4.1BSD to 4.1C BSD (or 4.2)  should
          not   be   very   troublesome.    Though   the  file  system
          implementation is quite different,  the  user  interface  is
          almost  identical,  especially  since system calls that have
          been replaced are simulated.  The long file  names  are,  of
          course,  not  a  problem.   The  new  directory format might
          appear to be, but there should be few  programs  other  than
          system  ones  (which  are  supplied)  that  read directories
          directly.

               Directions   for   the   transition   are   given    in
          _I_n_s_t_a_l_l_i_n_g/_O_p_e_r_a_t_i_n_g  _4._2_b_s_d under the section ``Upgrading a
          4BSD System,'' and _A _4._1_a  _U_s_e_r'_s  _G_u_i_d_e  _t_o  _4._1_c  provides
          useful user orientation.

               There are no provisions for  upgrading  from  a  system
          previous  to  4BSD,  such  as  3.0 or 32V, though this could
          presumably be done with sufficient investment of effort.

               System V is distributed  with  a  document,  _T_r_a_n_s_i_t_i_o_n
          _A_i_d_s,   designed  to  assist  the  system  administrator  in
          changing from System III to System V.

               Especially crucial transition topics include:  hardware
          support  changes  (esp.  lack  of DH-11 support); whether to
          convert to a 1K file system; conversion to the  new  archive
          format;   and   conversion   of   objects   or  (preferably)
          recompilation of sources for user programs to accomodate the
          new headers and object file format.


          4.  Sources and Documentation

               There has been a  large  amount  of  reorganization  of
          sources, documentation, and associated support since 32V.
















                                     - 24 -



          4.1  Make

               System V includes the  extended  _m_a_k_e,  which  features
          many  additional  default rules to handle common conditions,
          to the point that many  compilations  require  no  makefile.
          Additions  are  also  present which handle archives and SCCS
          files (see below) and make use of environment variables  and
          defaults.   Most system programs may be rebuilt by using the
          collection of :mk command files located in the source tree.

               The 4.1C BSD _m_a_k_e seems to be very much in  the  flavor
          of  V.7.   Rebuilding the whole source tree is as easy as in
          System V, however, and is recommended to be done frequently.

          4.2  SCCS

               System V includes the PWB Source  Code  Control  System
          (SCCS),  not  available  in  4.1C BSD.   4.2  is  rumored to
          include RCS, a public-domain rendering of SCCS.

          4.3  Sources

               System V preserves the changes to the names  of  source
          directories  and  files  which  System III  introduced  (the
          kernel ``sys''  subdirectory  becomes  ``os'',  and  ``dev''
          becomes  ``io'').   However,  since  there is an appropriate
          makefile (or :mk command file) for almost everything  it  is
          possible  to  go  to  the appropriate parent directory for a
          software package and let _m_a_k_e do the work.

               The 4.1C sources,  both  user  and  kernel,  have  been
          radically  reorganized in order to simplify recompilation of
          the entire system and  to  promote  portability.   There  is
          generally  a  source directory subtree corresponding to each
          directory containing  objects,  e.g.,  /usr/src/usr.bin  for
          /usr/bin,  making sources easy to locate.  Good use has been
          made of symbolic links, in order  to  avoid  duplication  of
          sources,  and  to  allow keeping certain pieces (such as the
          kernel sources) on  whatever  file  system  is  appropriate,
          e.g.,  /usr/include/sys  is  a  symbolic link to /sys/h, and
          /sys is itself a symbolic link to /usr/sys.

               The kernel  sources  have  all  the  VAX-specific  code
          separated  out into different directories and files from the
          portable code.  The user sources have  also  been  similarly
          organized  for  portability.   The C library, in particular,
          has been redone.  One would expect 4.1C to be as portable to
          another 32-bit machine as 32V or System V.

               There is a rather widespread problem in  Berkeley  code
          consisting  of  the  use  of the type int when long, or even











                                     - 25 -



          off_t, or especially time_t is meant.  This works  fine,  as
          long  as  you  never try to run such code on a machine where
          int is smaller than 32 bits.  (This problem is  not  evident
          in  the  kernel,  but rather, in application programs.) This
          problem is perhaps less prevalent in 4.1C than in 4.1.

               Fairness  requires  mentioning  that  there  are   also
          numerous  places  in  the documentation where it is asserted
          that int is 32 bits,  on  the  grounds  that  machines  with
          smaller  word  sizes  are  not  sufficient  for  many of the
          functions 4BSD supports.

          4.4  Documentation

               Berkeley provides  the  traditional  _U_n_i_x  _P_r_o_g_r_a_m_m_e_r'_s
          _M_a_n_u_a_l,  volumes  I, IIA, and IIB, plus an additional volume
          of papers written at Berkeley and related  directly  to  the
          Berkeley  parts  of  the  system.   The  documents  come  as
          duplication quality  masters  of  8-1/2  by  11  inch  pages
          suitable  for  ordinary  three-ring  looseleaf binders.  The
          first volume has of course been updated  and  is  also  kept
          on-line for easy access.

               System V   has   largely   reorganized    the    system
          documentation.  Volume  one  has  been divided into a _U_s_e_r'_s
          _M_a_n_u_a_l, an _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _M_a_n_u_a_l,  and,  peripherally,  the
          _O_p_e_r_a_t_i_n_g  _S_y_s_t_e_m _E_r_r_o_r _M_e_s_s_a_g_e _M_a_n_u_a_l.  Most of the classic
          UNIX papers which appear  in  volume  two  in  the  Berkeley
          distribution  have  been pieced together to form such things
          as a _D_o_c_u_m_e_n_t _P_r_o_c_e_s_s_i_n_g _G_u_i_d_e and a _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e.  All
          in  all,  there  are  twelve  documents  furnished  with the
          purchase of a System V license; extra copies are for sale by
          Western Electric Software Sales and Marketing.

               It is  disappointing  to  note  that  not  all  of  the
          documentation  is  provided  on  the  distribution  tape,  a
          feature  considered  critical  by  some  (e.g.   the  sight-
          impaired).


          5.  Groups and Identifiers

               4.1C changes the implementation of groups  and  related
          identifiers sufficiently to motivate this section.

          5.1  Groups

               System V uses the old V7/32V group scheme: a  user  may
          have  access to a login group (specified in /etc/passwd) and
          also to several other groups (as permitted  by  /etc/group),
          but may be in only one group at a time.











                                     - 26 -



               In 4.1C, the same files in the same  formats  determine
          what   groups  a  user  is  allowed  in,  but  the  user  is
          immediately put in _a_l_l of them at login: there is no  _n_e_w_g_r_p
          command.   The  _g_r_o_u_p_s  command lists the groups you are in.
          The maximum  number  of  simultaneous  groups  is  a  system
          compile-time  parameter,  and  the  default  is  eight.  The
          _s_e_t_g_r_o_u_p_s system call can be used (by superuser) to set  the
          groups for a process.

               In  both  systems,  each  file  has  a   single   group
          associated  with it to determine group read, write, execute,
          and setgid permissions.  System V creates a new file in  the
          effective  group  of  the  process, whereas 4.1C creates the
          file in the group of its parent directory.

               Both systems have _c_h_g_r_p (both command and system  call)
          to  change  the  group of an existing file.  4.1C allows the
          user to change the group of a file he owns to be any of  the
          groups  to  which  he  belongs.  System V allows the user to
          change the user and group id  of  any  file  he  owns,  thus
          giving  the file away.  4BSD does not, apparently because of
          the existence of disk space quotas, which System V lacks.

          5.2  Identifiers

               Berkeley has extended  the  setuid  and  setgid  system
          calls in 4.1C to allow setting the effective id to the value
          of the real id, as well as the reverse.  This is very useful
          for things like network server daemons, which may now switch
          permissions between superuser privileges  and  those  of  an
          ordinary  user,  and back, in a single process.  This (along
          with the  socket  IPC  and  non-blocking  I/O)  allows  many
          daemons  to be implemented as one process where formerly two
          were required.

               Group ids and process ids are 32 bit integer quantities
          in  4.1C.   The high order 16 bits of the process id are not
          yet used, but probably  will  be  with  the  development  of
          distributed applications.


          6.  File Systems

               Both systems have file  systems  different  from  their
          predecessors  and  each  other.  Though the comments in this
          section may make the  differences  seem  extreme,  the  user
          interface  is  not much changed in either case from 32V, and
          we have had no trouble transferring files  between  the  two
          systems  with  either  _t_a_r  or  _c_p_i_o  (though _c_p_i_o had to be
          ported to 4.1C first, of course).