diffs for June 2 FAQ posting
Conor P. Cahill
cpcahil at virtech.uucp
Mon Jun 3 05:35:54 AEST 1991
*** 9105 Sun May 5 22:43:28 1991
--- 9106 Sun Jun 2 15:28:58 1991
***************
*** 17,23 ****
posting, the Frequently Asked Questions posting in comp.unix.questions,
and finally the various postings in news.announce.newusers.
! Last Modified: $Id: freq.ques,v 1.9 91/05/05 22:42:42 cpcahil Exp $
This article includes answers to:
--- 17,23 ----
posting, the Frequently Asked Questions posting in comp.unix.questions,
and finally the various postings in news.announce.newusers.
! Last Modified: $Id: freq.ques,v 1.10 91/06/02 15:26:27 cpcahil Exp $
This article includes answers to:
***************
*** 51,56 ****
--- 51,60 ----
25. Where can I get the K-Shell (aka ksh)?
26. What dos-under-unix product will work with ESIX?
27. How do I correctly configure the various STREAMS parameters?
+ 29. What can I do if VP/IX doesn't recognize my video hardware
+ correctly?
+ 30. What systems support more than 16MB of memory?
+ 31. Why doesn't my brand spanking new Logitech mouse work?
Before I start on the answers, I will state that there is NO GUARANTEE as
***************
*** 103,136 ****
DELL UNIX (SVR3&4) DELL Computer Corp 800-426-5150
ESIX Everex 415-683-2068
ISC UNIX (SVR3) Interactive Systems ???
! Mach Mt Xinu ???
! Microport UNIX (SVR3&4) Microport ???
! SCO UNIX & Xenix Santa Cruz Operation 800-726-8649
UHC UNIX (SVR4) UHC 713-782-2700
3. Is there a binary BSD port for the 386 available anywhere?
! No. However, SVR4 has many BSDisms including symbolic links, job
control, BSD file system, sockets (implemented on top of streams).
It will also contain the SunOS memory mapped files, the Korn shell,
and many other nifty things.
! SVR4 is currently shipping from Microport, UHC, and DELL. Intell
had been shipping SVR4, but has handed its UNIX marketing efforts
over to ISC. ISC has announced that it will begin shipping SVR4
! in April. SCO has no plans to ship a SVR4 product, but "will include
SVR4 features in its SVR3.2 product."
One thing that should be noted here is that the System V R4 release
has MAJOR changes over the R3 releases and won't be stable for a while.
! If you want a stable system, I would suggest that you continue to use
! SVR3.2 until SVR4 stablizes (another 6mos to a year).
BSD 4.4 will support the 386 architecture as a base system. This
means that vendors will have a base BSD system that could be used
to make a BSD binary release for this architecture. There are
! several reasons why this probably won't occur:
1. SVR4 will be enough BSD to satisfy most people
--- 107,148 ----
DELL UNIX (SVR3&4) DELL Computer Corp 800-426-5150
ESIX Everex 415-683-2068
ISC UNIX (SVR3) Interactive Systems ???
! Mach Mt Xinu 415-644-0146
! 4.3BSD Mt Xinu 415-644-0146
! Microport UNIX (SVR3&4) Microport 800-FOR-UNIX
! SCO UNIX & Xenix Santa Cruz Operation 800-SCO-UNIX
UHC UNIX (SVR4) UHC 713-782-2700
3. Is there a binary BSD port for the 386 available anywhere?
! Mt Xinu's Mach386 product is a full 4.3BSD binary product. Its support
! for PC devices is somewhat limited (althought they say they are working
! on supporting more devices), it doesn't support a DOS under UNIX,
! and there is no intent on providing binary compatibility with other
! 386 UNIX products.
!
! Otherwise, SVR4 has many BSDisms including symbolic links, job
control, BSD file system, sockets (implemented on top of streams).
It will also contain the SunOS memory mapped files, the Korn shell,
and many other nifty things.
! SVR4 is currently shipping from Microport, UHC, DELL, and ESIX. Intel
had been shipping SVR4, but has handed its UNIX marketing efforts
over to ISC. ISC has announced that it will begin shipping SVR4
! in June. SCO has no plans to ship a SVR4 product, but "will include
SVR4 features in its SVR3.2 product."
One thing that should be noted here is that the System V R4 release
has MAJOR changes over the R3 releases and won't be stable for a while.
! The "current" release is SVR4 version 3. Be sure that you get this
! version from a vendor because it should be much more stable then the
! previous versions.
BSD 4.4 will support the 386 architecture as a base system. This
means that vendors will have a base BSD system that could be used
to make a BSD binary release for this architecture. There are
! several reasons why this *probably* won't occur:
1. SVR4 will be enough BSD to satisfy most people
***************
*** 154,166 ****
much of the BSD kernel, it still requires a standard BSD licensing
(which is actually a requirement for an AT&T version 7 license).
- At least one company (Mt Xinu) has announced that they will support
- (and distribute) the MACH source code (assuming you have the
- appropriate license) AND has announced the availability of a binary
- product based upon the same. Support for various PC devices is
- somewhat limited and they (Mt Xinu) see this as a developers
- product, not an end-user product.
-
4. What hardware works with brand X Unix and/or X11
The correct answer to this is a recommendation to call the
--- 166,171 ----
***************
*** 218,225 ****
Asynch Solution). The current version of this driver is 2.08.
The Readme for the FAS driver suggests that you also replace the
! 16450 uart chips on your asynch card with 16550s (I think the
! cost runs around $20). The 16550s provide a 16 byte FIFO which
allows operation at high speeds without loosing characters.
SCO Unix, ESIX, and ISC UNIX are all reputed to support the 16550
--- 223,230 ----
Asynch Solution). The current version of this driver is 2.08.
The Readme for the FAS driver suggests that you also replace the
! 16450 uart chips on your asynch card with 16550s (I think the cost
! runs around $20 per chip). The 16550s provide a 16 byte FIFO which
allows operation at high speeds without loosing characters.
SCO Unix, ESIX, and ISC UNIX are all reputed to support the 16550
***************
*** 370,376 ****
to be a mechanism to stop a run-away process from eating up all the
disk space available on your system.
! For UNIX versions prior to SVR4:
Both SCO Unix and SCO Xenix start out with a ulimit of 2097152 which
means that you probably won't have a problem with the ulimit on
--- 375,396 ----
to be a mechanism to stop a run-away process from eating up all the
disk space available on your system.
! NOTE: if you intend to change your ulimit AND you have a cron logging
! enabled, you should edit the logchecker program in /usr/lib/cron so
! that it places a reasonable limit on the cron log.
!
! For UNIX versions prior to SVR3.2 (386/ix 1.0.* is the specific one
! that I am referring to, although this probably applies to others):
!
! 1. Edit /usr/include/sys/param.h and change the #define for CDLIMIT
! to the appropriate number. The default is:
!
! #define CDLIMIT (1L<<14)
!
! For those of you who are interested, this variable is used within
! the /etc/conf/modules/kernel/space.c file.
!
! For UNIX versions based upon SVR3.2 and Xenix:
Both SCO Unix and SCO Xenix start out with a ulimit of 2097152 which
means that you probably won't have a problem with the ulimit on
***************
*** 394,401 ****
ULIMIT xxxxx
where xxxxx is the limit you desire. Note that this step can
! be performed in the kernel configuration software (i.e.: kconfig
! for 386/ix).
3. Edit /etc/default/login to delete the ULIMIT line.
--- 414,420 ----
ULIMIT xxxxx
where xxxxx is the limit you desire. Note that this step can
! be performed in the kernel configuration software (i.e.: idtune)
3. Edit /etc/default/login to delete the ULIMIT line.
***************
*** 677,682 ****
--- 696,705 ----
I have overridden the default number of inodes created on
the filesystem.
+ For Esix you might want to use /etc/ffs/mkfs (which builts a
+ "fast" file system). If you use this mkfs, you won't need to
+ run step o (make lost+found).
+
j. Label the file systems:
labelit /dev/rdsk/0s3 a disk0
***************
*** 732,738 ****
full newsfeed and have never seen the problem). Binary patches
have been posted to this group for several of the SVR3 OSs.
! It is not know if the problem still exists in the SVR4 products.
If you have it, write hate mail to your supplier's expensive QA
department... It has been known for years.
--- 755,764 ----
full newsfeed and have never seen the problem). Binary patches
have been posted to this group for several of the SVR3 OSs.
! ESIX has a patch (# 320D013.Z) available on thier BBS (714-259-3013)
! that should fix this problem on thier non-fast file system.
!
! It is not known if the problem still exists in the SVR4 products.
If you have it, write hate mail to your supplier's expensive QA
department... It has been known for years.
***************
*** 890,896 ****
In looking at this output, the key factors are CONFIG, MAX, and
FAIL. The ideal is to keep the CONFIG numbers approx 20% higher
than your MAX (which will keep FAILs at zero). Of course, the
! numbers represented under max an fail columns are only since
the last time you rebooted, so you should keep track of the
highest values you have seen.
--- 916,922 ----
In looking at this output, the key factors are CONFIG, MAX, and
FAIL. The ideal is to keep the CONFIG numbers approx 20% higher
than your MAX (which will keep FAILs at zero). Of course, the
! numbers represented under max and fail columns are only since
the last time you rebooted, so you should keep track of the
highest values you have seen.
***************
*** 898,903 ****
--- 924,975 ----
use idtune or kconfig to change the parameters (or edit the
/etc/conf/cf.d/stune file), rebuild the kernel and see how
things improve.
+
+ 28. Can I use gcc for my development so that I don't have to buy a
+ development system from the OS vendor?
+
+ This is not an option. GCC requires the host include files and
+ libraries in order to be able to compile software. These files
+ are only included in the host development system.
+
+ 29. What can I do if VP/IX doesn't recognize my video hardware correctly?
+
+ Try commenting out the EGAROM and VGAROM lines in the
+ vpix.cnf file (remember this is normally a per-user file so you
+ have to make the change in each copy). If this works, make the
+ same change in /usr/vpix/defaults/vpix.cnf so that any new
+ users will get the change.
+
+ 30. What systems support more than 16MB of memory?
+
+ For UNIX versions prior to SVR4:
+
+ The following systems support more than 16 MB in some form or
+ fasion on both ISA and EISA bus systems:
+
+ AT&T UNIX
+ SCO UNIX
+ DELL UNIX
+
+ However, because it is supported on ISA systems, it uses a
+ paging algorithm to bring high memory pages down below 16MB
+ when they are needed for BUS i/o actions.
+
+ ISC UNIX (with an EISA patch) provides support for > 16MB on
+ EISA systems only. With version 2.3 they intend to support FULL
+ EISA buss mastered DMA to anywhere in memory.
+
+
+ 31. Why doesn't my brand spanking new Logitech mouse work?
+
+ This is caused by the fact that Logitech (in thier infinite
+ wisdom) changed from emulating a Mouse Systems mouse to
+ emulating a Microsoft mouse. So if you want to use one of
+ the new mice, configure it as a Microsoft mouse.
+
+ NOTE: If you are using an older Logitech mouse and sometimes
+ have problems getting ISC's X to communicate with it, reconfigure
+ it as a Mouse Systems mouse and all your problems will go away.
----------------------------------------------------------------------------
If you have suggestions or corrections for any of these answers, please send
--
Conor P. Cahill (703)430-9247 Virtual Technologies, Inc.
uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160
Sterling, VA 22170
More information about the Comp.unix.sysv386
mailing list