Subject: Linux-Misc Digest #819
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Wed, 16 Mar 94 02:13:19 EST

Linux-Misc Digest #819, Volume #1                Wed, 16 Mar 94 02:13:19 EST

Contents:
  Re: *** DON'T READ THIS BEFORE POSTING *** (R Yeung)
  flush /dev/audio (Mark Skouson)
  Re: linux on cdrom (Eberhard Moenkeberg)
  Problems with Linux 1.0 (Paul Tomblin)
  Opinions wanted about SCO-unix (vs AIX/Linux). (Patrik Larsson)
  4.4BSD-Lite (Was: BSD vs. Linux) (James W. Adams)

----------------------------------------------------------------------------

From: rky57514@uxa.cso.uiuc.edu (R Yeung )
Subject: Re: *** DON'T READ THIS BEFORE POSTING ***
Date: 15 Mar 1994 15:55:51 GMT

ron@draconia.hacktic.nl (Ron Smits) writes:

>At  the moment many  people who are totally  unknown to Unix/Linux and
>the net are switching over to Linux and are getting access by either a
>provider  like hacktic in the Netherlands  or because the company they
>work  for starts to  provide  it.  These people  usually  don't have a
>faintest  clue where to start  looking  for FAQ's,  Readme's or  local
>help. In my immediate surroundings I can  name at least fifteen people
>who have started using Linux in the last year, mainly because they see
>the possibilities  of it on my  system.  The closest that these people
>have seen of datacommunication is  a BBS. I  can usually help them out
>(their system is  after all a software clone  of my system) So  at the
>moment   they don't see   the   need to go   to   these groups to  get
>assistance.

>These people  need to be  assisted  to have  _*fun*_ with  Linux,  and
>scaring them away  when their first posting is  answered  by some rude
>flame or a form letter from some automated moderator stating that they
>have   been a bad   boy:) is  a   sure way  of  killing  the more then
>expontential growth of Linux.

>I don't  mind answering  questions  here on  the net   and I  have the
>feeling that their are  a lot of people   that don't mind  reading and
>answering  questions. I  think that   the people  who  are so terribly
>concerning about the flood of questions from newbies and get irritated
>about it  should  think about  not reading the  col.help and  col.misc
>group. Maybe a new group should br created for them where they can sit
>back and relax   not being disturbed  by the  numerous and re-occuring
>questions of newbies. 

>I have  stated  it  before  in other   postings the  last weeks,  keep
>col.help the way it is, keep answering questions  from newbies and not
>so newbies, and keep  reminding them in an  easy, friendly and polite!
>manner of the existance of FAQ's, Readme's and HOWTO's. 

>just my nickle's worth (Here in the Netherlands we don't have cents anymore)

>               Ron Smits
>               ron@draconia.hacktic.nl
>               Ron.Smits@Netherlands.NCR.COM

>/*-( My opinions are my opinions, My boss's opinions are his opinions )-*/
>/*-(                They might not be the same                         -*/


I completely agree!  One of greatest strengths of Linux is these groups.
It kept me involved in Linux back during my first experiences (SLS 1.01).
Without the help I received from many of the more experienced Linuxers out
there, I would have surely given up on Linux long ago.  I was impressed by
the enthusiasm and willingness to help others shown by those who replied to my
many messages.

Like Ron, I don't mind answering questions on the net, when I can.  I think
flaming newbies for their questions does not help Linux at all.  Everyone
had to start somewhere.  FAQs and other docs should still be made the 
primary sources of information, but when someone posts a question, I don't
think flaming him or yelling "Read the FAQs" helps anyone.  Why do the
people who complain about newbies read c.o.l.help and c.o.l.misc anyway?
It seems that these people don't need any help and they apparently don't
want to be bothered by other people's questions.  I would just avoid these
groups if it annoyed me that much.  I'm grateful that these groups even 
exist!

Answering questions politely and perhaps pointing them to the correct 
sources for information would be of greater benefit to all of us.  Remember,
after all, that the purpose of the c.o.l.help group IS to answer questions
and help out others!


Raymond Yeung 
Nimbus@uiuc.edu

------------------------------

From: skouson@baloo.ee.byu.edu (Mark Skouson)
Subject: flush /dev/audio
Date: 15 Mar 1994 15:44:45 -0700




I am trying to run rplay and there is a provision for flushing /dev/audio for
some systems, but not for linux.  I looked in ioctl.h and couldn't find any 
command that would let me flush the audio device.  I can't use fflush because 
fflush requires a file pointer and I only have a file descripter.

Mark Skouson

skouson@gecko.ee.byu.edu

------------------------------

Date: Mon, 14 Mar 94 20:01:52 +0100
From: Eberhard_Moenkeberg@p27.rollo.central.de (Eberhard Moenkeberg)
Subject: Re: linux on cdrom


Hello Joel and all others,

on 12.03.94 Joel Goldberger wrote to All in USENET.COMP.OS.LINUX.MISC:

JG> In article <CMFAAr.n1s@sbu.edu> cmckay@sbu.edu (Phantom) writes:
>> I would like to know what is a good company that has
>> the latest version of linux and a reasonable price on
>> cdrom.

JG> Gee, that sounds like us !  We just released a disc containing the
JG> complete contents of sunsite & tsx taken on 18 February.

That sounds unbelievable (sunsite is about 600 MB, tsx holds more than
300 MB) - but it is like Joel said: he has eliminated all tsx files
which are on sunsite, too, and created soft links instead.

Good work! And damned cheap! And info@infomagic.com really is answering...

Greetings ... Eberhard


------------------------------

From: ptomblin@gandalf.ca (Paul Tomblin)
Subject: Problems with Linux 1.0
Date: 15 Mar 1994 18:08:39 -0500

I installed the Linux 1.0 kernel on two machines.  Both are running stock SLS
1.03 installations except for the kernel - until today they were both running
pl14f.

On the first one, I had no problems.  It was able to talk to the network
fine, all my programs worked fine.  So I installed it on the second one.  The
second one is a bit different because it's got two ethernet cards (eth0 and
eth1).  The subnet mask is set up and everything, so that if everything
works, eth0 talks to 134.22.80.0 (the corporate network) and everything else,
while eth1 talks to 134.22.88.0 and 134.22.89.0 (the test network).

Both machines NFS mount disks from one machine that is on 134.22.80.0 network
and one machine that is on 134.22.89.0.  However, when I rebooted with the
new kernel, it refused to talk to the machine on 134.22.89.0.  It still
talked to 134.22.80.0 ok.  I couldn't mount, ping, or telnet to or from the
134.22.89.134 machine.

I'm pretty sure ifconfig and route both say exactly the same things they did
under pl14f.  I didn't change anything in the /etc directory.

This is what they say under pl14f (I can't print what it says under 1.0,
since I couldn't get to that machine from here when it was under 1.0)

punt:/# ifconfig
lo        IP ADDR 127.0.0.1  BCAST 127.255.255.255  NETMASK 255.255.255.0
          MTU 2000  METRIC 0  POINT-TO-POINT ADDR 0.0.0.0
          FLAGS: 0x0049 ( UP LOOPBACK RUNNING )
 
eth0      IP ADDR 134.22.80.18  BCAST 134.22.255.255  NETMASK 255.255.254.0
          MTU 1500  METRIC 0  POINT-TO-POINT ADDR 0.0.0.0
          FLAGS: 0x0043 ( UP BROADCAST RUNNING )
 
eth1      IP ADDR 134.22.89.18  BCAST 134.22.255.255  NETMASK 255.255.254.0
          MTU 1500  METRIC 0  POINT-TO-POINT ADDR 0.0.0.0
          FLAGS: 0x0043 ( UP BROADCAST RUNNING )
punt:/# route
Kernel routing table
Destination net/address   Gateway address           Flags RefCnt    Use Iface
default                   router                    UGN        0      7 eth0
canoe.gandalf.ca          lrnetlab.gandalf.ca       UGHDM      0      8 eth0
network                   *                         UN         0    393 eth0
134.22.88.0               *                         UN         0      0 eth1
localhost                 *                         UH         0     12 lo

If anybody has any suggestions, or needs some more info, send me email.

-- 
Paul Tomblin, Head - Automation Design Group.
Gandalf Canada Limited
This is not an official statement of Gandalf, or of Vicki Robinson.
"To err is human, but to really foul things up requires the root password"

------------------------------

Crossposted-To: comp.unix.advocacy,biz.sco.general
From: d0bpl@dtek.chalmers.se (Patrik Larsson)
Subject: Opinions wanted about SCO-unix (vs AIX/Linux).
Date: Wed, 16 Mar 1994 00:17:21 GMT

   A business associate of mine needs information about the
differences between the various Unixes for PCs (PS/2).


   What are the pros and cons for SCO-unix in general, and
compared to AIX (and maybe Linux) in particular?

   Any pointers to documents or specifications is great, and
personal opinions are very much appriciated!

   This is a serious question, no flames please.


   Thanks in advance!


      // Patrik

------------------------------

Crossposted-To: comp.unix.bsd
From: jwa@yog-sothoth.dcrt.nih.gov (James W. Adams)
Subject: 4.4BSD-Lite (Was: BSD vs. Linux)
Date: Tue, 15 Mar 1994 23:18:19 GMT

In article <2m2kem$f29@mhaau.inhouse.compuserve.com> dneedham@csi.compuserve.com (Douglas Wade Needham) writes:
>[...]
>Now all I am really waiting (re: drooling) for is for it to be moved over
>to BSD4.4 now that the suit is settled. 8)  Just MHO.

All this hoopla over 4.4BSD-Lite has me a bit confused.  According to
the release announcement letter for 4.4BSD-Alpha, 4.4 Lite was to be
essentially Net-2 with bug fixes, some enhancements and support for
additional architectures, with no new kernel files and only a few
additional programs.  Most of the real improvements in 4.4BSD were in
the kernel interfaces and filesystems, code which the letter distinctly
implied would *not* be in 4.4 Lite.

Since the so-called "settlement" doesn't permit distribution of
4.4BSD-Encumbered without the customary USL source license, it seems to
me that most of this work will end up benefiting only those whose
pockets are deep enough to have a USL UNIX source license.

Has this situation changed, or am I correct in assuming that the change
in BSDI from Net-2 to 4.4-Lite will result in minimal functional
benefit?

For the sake of discussion, I have included the relevant portions of the
4.4 Alpha release announcement below:


=======================================================================

Licensing info:  Pauline Schwartz
                 Distribution Coordinator
                 Computer Systems Research Group
                 Computer Science Division, EECS
                 University of California
                 Berkeley, California 94720
                 (510) 642-7780
                 pauline@cs.berkeley.edu
                 
=======================================================================



UNIVERSITY OF CALIFORNIA, BERKELEY

COMPUTER SYSTEMS RESEARCH GROUP
COMPUTER SCIENCE DIVISION, EECS
BERKELEY, CALIFORNIA 94720
(510) 642-7780


Dear Colleague:

July 7, 1992

We are happy to send you information about our June 1992 release of
4.4BSD-alpha.  This release represents our expectations for the final
interfaces that will be present in 4.4BSD.  Our goal in making this
release available is to get feedback on any problems in the design or
implementation of the new facilities, and to allow adventurous sites to
gain experience with the new interfaces in 4.4BSD.

This distribution is NOT intended to be used on production systems; nor
is it intended for sites without enough local expertise to find and fix
any problems that are encountered. It is intended to be used to provide
an advance look at some of the facilities and interfaces that we will be
distributing in 4.4BSD. We are interested in getting feedback on the
problems that you find and also any compatibility problems that you
encounter in converting your applications to run on this release. While
we hope that the interfaces in this release will not change before the
final release of 4.4BSD, we will make changes that we feel are necessary
to fix problems that arise during the alpha release period (at least in
part based on feedback from this test group). Where possible, we will
minimize changes that will break applications ported to this release.
The code in this distribution may be redistributed and used in released
products. However, you are strongly encouraged to upgrade any code that
you use from this distribution to the similarly-licensed distribution of
the 4.4BSD code within one year of its release.

Only limited support can be provided by our group.  Specifically, we
cannot provide help with installation of this software on other
systems, although we are, of course, interested in hearing of problems
that you encounter.

We are planning on releasing two versions of the software,
4.4BSD-Encumbered and 4.4BSD-Lite. The 4.4BSD-Encumbered distribution is
available only to sites with UNIX/32V, System III, or System V source
licenses with USL/AT&T. The 4.4BSD-Encumbered distribution is a complete
distribution in the style of 4.3BSD and contains the complete source for
the Berkeley Distribution.

The 4.4BSD-Lite distribution will be a distribution that is copyrighted
by the University of California and others, but may be freely
redistributed. It will be available to anyone and requires no previous
license either from USL/AT&T or The Regents of the University of
California. Its license agreement and content will be similar to that of
the two BSD Networking Releases. The 4.4BSD-Lite distribution will
contain only a few additional programs and no additional kernel files
from the Second Networking release done in June 1991. However, it will
contain support for additional architectures and will have many bug fixes
and performance enhancements. The distribution will include both software
developed at Berkeley and also much of software contributed by
authors outside Berkeley.

Only the 4.4BSD-Encumbered distribution is available at this time. The
4.4BSD-Lite distribution is not available at this time; we will send out
a mailing to notify you when it is available.

The enclosed information is designed to serve two purposes. The first
purpose is to acquaint you with the details of our distribution so you
can decide whether you would like to receive it.  The second purpose is
to tell you how to obtain our distribution.

What is 4.4BSD?

This software distribution is provided on one 6250bpi 1/2" 9-track tape
or one 8mm Exabyte cassette only. The 4.4BSD-Encumbered distribution
contains complete source as well as binaries for the HP9000/300 series of
workstations. The 4.4BSD-Lite distribution will contain only freely
redistributable sources. As the sources do not comprise a complete
system, no binaries will be included.

The architectures that are supported include:

HP 9000/300 68000-based workstations

Intel 386/486-based machines (ISA/AT or EISA bus only)

Sony News MIPS-based workstations

Omron Luna 68000-based workstations

DECstation 3100 and 5000 MIPS-based workstations

Sparcstation I & II SPARC-based workstations

The distribution does not include the machine support for the Tahoe and
VAX architectures found in previous BSD distributions. Our primary
development is on the HP9000/300 series machines. The other
architectures are being developed and supported by people outside the
university. Consequently, we are not able to directly test or maintain
these other architectures, so cannot comment on their robustness,
reliability, or completeness.

The major new facilities available in the 4.4BSD release are a new
virtual memory system, a log-structured filesystem, enhancement of the
local filesystems to support files and filesystems that are up to 2^63
bytes in size, the addition of ISO/OSI networking support, a freely
redistributable implementation of NFS, and the conversion to and
addition of the IEEE Std1003.1 ("POSIX") facilities and many of the
IEEE Std1003.2 facilities. In addition, many new utilities and additions
to the C library are present as well.  The kernel sources have been
reorganized to collect all machine-dependent files for each architecture
under one directory, and most of the machine-independent code is now
free of code conditional on specific machines. The user structure and
process structure have been reorganized to eliminate the statically-
mapped user structure and to make most of the process resources
sharable by multiple processes. The system and include files have been
converted to be compatible with ANSI C, including function prototypes
for most of the exported functions. There are numerous other changes
throughout the system.

The new virtual memory implementation is derived from the MACH operating
system developed at Carnegie-Mellon, and was ported to the BSD kernel
at the University of Utah. The MACH virtual memory system call interface
has been replaced with the "mmap"-based interface described in the
"Berkeley Software Architecture Manual" (see UNIX Programmer's Manual,
Supplementary Documents, PS1:6). The interface is similar to the
interfaces shipped by several commercial vendors such as Sun, Convex
Computer Corp. and USL/AT&T. The integration of the new virtual
memory is functionally complete, but still has serious performance
problems under heavy memory load. The internal kernel interfaces have
not yet been completed and the memory pool and buffer cache have not yet
been merged. Some of these changes are expected before the release of
4.4BSD.

The ISO/OSI Networking consists of a kernel implementation of transport
class 4 (TP-4), connectionless networking protocol (CLNP), and
802.3-based link-level support (hardware-compatible with Ethernet). We
also include support for ISO Connection-Oriented Network Service, X.25,
TP-0. The session and presentation layers are provided outside the kernel
by the ISO development environment (ISODE). Included in this development
environment are file transfer and management (FTAM), virtual terminals
(VT), a directory services implementation (X.500), and miscellaneous
other utilities.

A new virtual filesystem interface has been added to the kernel to
support multiple filesystems. In comparison with other interfaces, the
Berkeley interface has been structured for more efficient support of
filesystems that maintain state (such as the local filesystem). The
interface has been extended with support for stackable filesystems done
at UCLA. These extensions allow for filesystems to be layered on top of
each other and allow new vnode operations to be added without requiring
changes to existing filesystem implementations.

In addition to the local "fast filesystem", we have added an
implementation of the network filesystem (NFS) that fully
interoperates with the NFS shipped by Sun and its licensees. Because our
NFS implementation was implemented using only the publicly available
NFS specification, it does not require a license from Sun to use in
source or binary form. By default it runs over UDP to be compatible with
Sun's implementation. However, it can be configured on a per-mount basis
to run over TCP. Using TCP allows it to be used quickly and efficiently
through gateways and over long-haul networks. Using an extended
protocol, it supports Leases to allow a limited callback mechanism that
greatly reduces the network traffic necessary to maintain cache
consistency between the server and its clients.

A new log-structured filesystem has been added that provides near
disk-speed output and fast crash recovery. It is still experimental in
the alpha release, though we hope to have enough experience with it to
recommend it for production use by the time of the final 4.4BSD release.
We have also added a memory-based filesystem that runs in pageable
memory, allowable large temporary filesystems without requiring dedicated
physical memory.

The quota system has been rewritten to support both user and group
quotas (simultaneously if desired). Quota expiration is based on time
rather than the previous metric of number of logins over quota. This
change makes quotas more useful on fileservers onto which users seldom
login.

The 4.4BSD distribution contains most of the interfaces specified in the
IEEE Std1003.1 system interface standard. The biggest area of change is a
new terminal driver. The terminal driver is similar to the System V
terminal driver with the addition of the necessary extensions to get the
functionality previously available in the 4.3BSD terminal driver. 4.4BSD
also adds the IEEE Std1003.1 job control interface, which is similar to
the 4.3BSD job control interface, but adds a security model that was
missing in the 4.3BSD job control implementation. Other additions
include IEEE Std1003.1 signals, FIFOs, byte-range file locking, and saved
user and group identifiers.

There are several new tools and utilities included in this release. A
new version of make allows much-simplified makefiles for the system
software and allows compilation for multiple architectures from the same
source tree (which may be mounted read-only). Notable additions to the
libraries include functions to traverse a filesystem hierarchy,
database interfaces to btree and hashing functions, a new, fast
implementation of stdio and a radix sort function. The additions to the
utility suite include greatly enhanced versions of programs that display
system status information, implementations of various traditional
tools described in the IEEE Std1003.2 standard, and many others.

We have been tracking the IEEE Std1003.2 shell and utility work and have
included prototypes of many of the proposed utilities. Because most of
the traditional utilities have been replaced with implementations
conformant to the POSIX standards, you should realize that the utility
software may not be as stable, reliable or well documented as in
traditional Berkeley releases. In particular, almost the entire manual
suite has been rewritten to be freely redistributable and, in many
instances, it does not correctly reflect the current state of the
software. It is also worth noting that, in rewriting this software, we
have generally been rewarded with significant performance
improvements. Most of the libraries and header files have been converted
to be compliant with ANSI C. The default compiler (gcc) is a superset of
ANSI C, but supports traditional C as a command-line option. The system
libraries and utilities all compile with either ANSI or traditional C.

Work has also progressed in several other areas. Several important
enhancements have been added to the TCP/IP protocols including TCP
header prediction and serial line IP (SLIP) with header compression. The
routing implementation has been completely rewritten to use a
hierarchical routing tree with a mask per route to support the arbitrary
levels of routing found in the ISO protocols. The routing table also
stores and caches route characteristics to speed the adaptation of the
throughput and congestion avoidance algorithms.

The Kerberos (version 4) authentication software has been integrated
into much of the system (including NFS) to provide the first real
network authentication on BSD.

This release includes several important structural kernel changes. The
kernel uses a new internal system call convention; the use of global
("u-dot") variables for parameters and error returns has been
eliminated, and interrupted system calls no longer abort using non-local
goto's (longjmp's). A new sleep interface separates signal handling from
scheduling priority, returning characteristic errors to abort or restart
the current system call. This sleep call also passes a string describing
the process state, which is used by the ps(1) program. The old sleep
interface can be used only for non-interruptible sleeps. The sleep
interface (tsleep) can be used at any priority, but is only
interruptible if the PCATCH flag is set. When interrupted, tsleep
returns EINTR or ERESTART.

Many data structures that were previously statically allocated are now
allocated dynamically. These structures include mount entries, file
entries, user open file descriptors, the process entries, the vnode
table, the name cache, and the quota structures.

The End of BSD from Berkeley

As you may already have heard, the CSRG is going to go away after the
final release of 4.4BSD. For the following reasons, clearly the CSRG
cannot continue in its present form.

Funding has become increasingly time-consuming and difficult. We are
spending more and more of our time obtaining funding, time that we would
prefer to spend working on BSD. As many of you are intimately aware,
computer corporations are actively seeking ways to reduce discretionary
outlays. Also, as UNIX vendors have developed their own research
groups, the work of the CSRG has become less necessary to them.
Finally, making BSD freely redistributable has resulted in fewer
distributions sold, as other organizations sell our releases for less
money.

Support within the University of California has declined as BSD has
become less widely used internally. Victims of our own success, many of
the features once found only in BSD are now available from every
vendor.

The system has become too large and complex for a group of four to
architect and maintain. In particular, losing Mike Karels has made it
obvious to us that the group is below critical mass for developing and
distributing a complete UNIX system.

We are making the 4.4BSD-alpha distribution available now. We will spend
the summer and some part of the fall cleaning up the release and make
the final 4.4BSD release available in the fall. When the final release
happens is mostly dependent on when our current funding runs out. At
that time we will close down the group. We would really like to have six
months to finish up 4.4BSD. The amount of time that we get is largely a
function of how many of you purchase the alpha distribution. So, if you
are planning to get 4.4BSD when it comes out, please consider buying an
alpha distribution with an upgrade option instead. That way your money
will go to support the final 4.4BSD release.

BSD has always been a community effort, and, as a community effort, does
not rely on a small group of people in Berkeley to keep it going. BSD
will not go away, but will live on through the free software and
commercial efforts of many people. We thank you for your support over
the years, your funding, and, of course, the software you've contributed
to make the BSD system what it is today!

How to obtain 4.4BSD-Encumbered

To obtain 4.4BSD-Encumbered we require execution of the Berkeley License
Agreement (6/92). In addition, foreign licensees must execute Addendum
Number One for Foreign Licensees in ordering 4.4BSD-Encumbered. The fee
is $2000.00 for 4.4BSD-Encumbered.

Because we are a research and development organization and not a
commercial organization, we make our research results available for a
small license fee. We distribute only the whole system "As Is" and cannot
send individual pieces of the system. We are required by the University
of California to have a formal license arrangement with each
organization to which we distribute. All material is considered licensed
material regardless of its availability from other sources that make
such material publicly available. In addition, for 4.4BSD-Encumbered,
we are required to secure a copy of the AT&T Software Agreement with
your organization and confirm it with AT&T before the software can be
shipped.

[...details of licensing edited out for brevity]



                                 Sincerely yours,


                                 Marshall Kirk McKusick
                                 Research Computer Scientist
                                 Computer Systems Research Group




--
  James W. Adams     --     Bioinformatics and Molecular Analysis Section
  Building 12A, Room 2013              jwa@alw.nih.gov, uunet!nih-csl!jwa
  National Institutes of Health
  Bethesda, MD 20892                          "Spay the Children"

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Misc Digest
******************************
