Subject: Linux-Activists Digest #34
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Mon, 6 Apr 92 21:00:12 EDT

Linux-Activists Digest #34, Volume #2             Mon, 6 Apr 92 21:00:12 EDT

Contents:
  Re: line printer deamon for Linux, any suggestions? (Harold Tomlinson)
  Re: File system naming conventions (Harold Tomlinson)
  IMPORTANT: gcc 2.1, libc.a 2.1a and Linux (Hongjiu Lu -- Graduate Student)
  IMPORTANT: gcc 2.1, libc.a 2.1a and Linux (Hongjiu Lu -- Graduate Student)
  directory tree (Mike Ching)
  directory tree (Mike Ching)
  Re: Compilers (c t wilson)
  Re: Linux Drivers and Kernel question. (Duty Programmer)
  Re: Beginner's Guide: Installation (Jim Winstead Jr.)

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

From: [email-masked] (Harold Tomlinson)
Subject: Re: line printer deamon for Linux, any suggestions?
Date: 6 Apr 92 22:57:39 GMT

(Note:: The following is my opinion only and assumes that there is a
future for Linux that involves useful work.  I don't have a copy of
Linux yet and can only share from experience with Ultrix, RiscOs, and
SunOs.) 

:) Now I need a line printer deamon.  I wrote a small deamon with lpd, lpr,
:) lprm and lpq a few months ago for MINIX.  It is a simple deamon, only made
:) for one queue.  I am not familiar with real UNIX printer deamons, I know
:) how to use lpr, lpq and lprm, that's all.

  Have you heard of plpd?  There is a set of programs that are in the
public domain which work slightly better than lpd/lpr/lpq/lpc/lprm/pac.

:) My deamon will be started by lpr and then runs until the queue is empty.
:) When there is nothing to print, no deamon runs and no resources are
:) wasted.  It supports multiple kinds of paper, because I sometimes change
:) between single sheets and endless paper.  It has no priority classes, no
:) net interface, no printcap, no multiple queues with job scheduling or
:) things like that.

  These are nice features.  Do you think it will save that much to
have the daemon die as opposed to having swap out util needed?  What
about the overhead of startup?  *nix "lpd" is not a big resource user.
When started, it reads the /etc/printcap file, then checks the printer
queues listed there (usually /usr/spool/<printername>).  If it runs
out of stuff to print, it goes to sleep for a while.  This usually
gets it swapped out.

:) -  Would you prefer a standard system V deamon?

  Personally, I think you should look at the plpd set.  Perhaps it
will be a small-effort port.

:) -  Do you think a Linux specific deamon with special support for typical
:)    PC problems (multiple kinds of paper etc.) may be better?

  We handle multiple forms with multiple queues, not a great way, but
it works.  The other option is to use the "-C" option and have the
output-filter (see printcap(5)) check for that then send the setup
string to the printer.

:) -  I don't know how printcap works, I only know it is a termcap like
:)    database for printer capabilities.  Do you think it is useful, do you
:)    use it and can you give me more informations about it?

  It's not that difficult.  The manuals with the plpd set helps you to
understand it better.  Yes, it is useful.  Very.  It allows you to
configure the following options:  
(NOTE: IMHO: U=useful, N=not useful, D=doesnt matter, V=vital)

        af      where to keep track of who printed and how much (D)
        br      set baud rate on serial printer port            (V)
        cf      special filter                                  (D)
        df      special filter (TeX)                            (D)
        dn      binary for printer daemon. (daemon name)        (D)
        du      userid for daemon                               (D)
        fc      clear tty flags. ie reset serial line           (U)
        ff      string to use for form feed, ie CR vs CRLF      (U)
        fo      form-feed on open.  send a preceeding ff        (U)
        fs      set tty flags.   ie reset serial line           (U)
        gf      special filter                                  (D)
        ic      non-standard ioctrl                             (D)
        if      input filter - format and print header page     (U)
        lf      where to log errors                             (U)
        lo      name of lock file                               (D)
        lp      device for printer. /dev/tty01 or whatever      (V)
        mc      maximum copies                                  (U)
        mx      maximum file size, ensure that /tmp has room    (U)
        nc      remove control characters                       (U)
        nf      special filter                                  (D)
        of      output filter, format document                  (U)
        pl      page length                                     (U)
        pw      page width                                      (U)
        sb      short banner, one line only                     (U)
        sc      supress copies                                  (U)
        sd      spool directory                                 (V)
        sf      suppress form feeds                             (U)
        sh      suppress banner page                            (U)
        st      printer status file name                        (U)
        
  There are other options which are even less useful or may not be
relivant to a PC-*nix.

  (I can send you an anotated sample printcap if you want to
understand it.)

:) -  I thought about running the spool files through compress, the printer
:)    is so slow, that uncompressing should not need much CPU power.  Any
:)    comments?

  Usually not benificial, most files are so small they are not worth
compressing.  If they are large enough to warrent compression, you
would be spending a lot of time compressing only to uncompress before
printing.  There is also an option in the standard "-s" option to
lpr which uses symlinks instead of copying the file to the spool
directory.  

:) -  My lpr does not know any filter options.  Do you consider them to be
:)    useful?  Any suggestions, standards on how to implement them?

  Again, check plpd.  Why reinvent the sports car?  Filters are vital.
For example, if you have a postscript printer, you have to use the
"of" in the printcap to specify a filter that will convert the header
page to postscript.  The "of" (output filter) also sends setup
information to the printer if you so desire.  The the rest of the
document should be sent through the "if" (input filter) which can
check to see if it is postscript and convert if needed.

  If you don't use filters, you are assuming the world has the same
printer as you.  

:) -  My lpr does not change the incoming data in any way, no \n to \r\n
:)    expansion, no tab expansion, no line break after a fixed number of
:)    characters etc. Ok?

  Yes.  lpr should not touch the file.  It should only copy it to the
spool directory (if required) and go away.  lpd checks the spool
directories every once in a while to see if there are any files.  lpr
also creates a "control file"  ...

paralandra> l /usr/spool/laser2/
total 11
   1 drwxrwxrwx  2 root          512 Apr  6 17:31 ./
   1 -rw-rw----  1 daemon        103 Apr  6 17:31 cfA075paralandra
   5 -rw-rw----  1 haroldt      4832 Apr  6 17:31 dfA075paralandra
   1 -rw-r-----  1 root            4 Apr  6 17:31 .seq
   1 -rwxr--r--  1 root            4 Apr  2 14:49 lock*
   1 -rw-rw-rw-  1 root           26 Mar  2 16:14 laser2_status
   1 drwxr-xr-x 18 daemon        512 Jan 15 10:53 ../
   0 -rw-rw-rw-  1 root            0 May 15  1991 laser2_log
   0 -rw-rw-rw-  1 root            0 May 15  1991 laser2_acct

  The file beginning with "cf" contains information needed by lpd.  lpd
looks for this file, reads it, and prints to the printer associated
with this dir (from the printcap file).  If there are changes to be
made, it will be by the "of" and/or "if" specified in the printcap.

:) I set the \n -> \r\n menu entry on my printer, so I can print usual text
:) files without converting them.

:) I am waiting for your suggestions, what would you appreciate to see in a
:) line printer deamon package?
:) 
:) Michael

  Again, I'd strongly suggest finding out about plpd.  It seems
confusing at first but is well worth knowing.  If you want the
information I can dig it up and send it to you.

  I don't remember where it came from, nor do I know if there is a
newer version available, but, if nothing else, this information will
help you to understand the lpd suite.  Please do, it would help.  

--
# Harold Tomlinson                      ##      [email-masked] #
# Computing & Communications Services   ##      (416)736-5257-33802         #
# YORK UNIVERSITY, Ont, CANADA          ##      ########################### #

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

From: [email-masked] (Harold Tomlinson)
Subject: Re: File system naming conventions
Date: 6 Apr 92 23:13:59 GMT

In article <[email-masked]> [email-masked] (Michael Haardt) writes:

:)
:)   -  Where should the swap file/partition be?  I saw /swap, but personally,
:)      I would appreciate /dev/swap for various reasons.

  I'm not certain yet how you are partitioning the disk.  I'd agree
with you on the /dev/swap but again, look to the future.  Will you
allow for a /dev/swap0, /dev/swap1...?  Are you using an fstab to
determine the partition mounts and can it (as with some versions of
*nix) include an additional swap partition?  

  Are you using a swap "file" or "partition"?  This makes a big
differance.  If you use a file, then I'd stick to /dev/swap.  If a
partition, then why mount it?

:)   -  If there is more than one device which should be mounted temporarily,
:)      /mnt is not enough.  I recently saw /mnt/exch0, /mnt/exch1 ...

  If more than one device is being mounted temporarily, it is up to
the user as to where to put it.  Usually, on Paralandra (DecStation
2100) I create a /mnt0,/mnt1... if I need more than one temporary mount.

:)   -  I don't like the various links of gcc, cc, gas, as, gcc-as etc.  gcc is
:)      the system compiler, why not just using cc, as, ld and putting cc1 in
:)      /usr/lib?  Concerning cpp, I am not sure.  I am used to see it in either
:)      /lib or /usr/lib, but never in /usr/bin.  But then again, I think it is
:)      very different to e.g. cc1 in meaning of being an internal compiler pass.
:)      Many programs use it as usual command, so /usr/bin might be better.

  No.  At least, not by convention.  Things in /usr/bin, if I'm not
mistaken, are things that users run.  Things like diff, du, make, and
sleep.  Things in /usr/lib and things that objects (in  /usr/bin) and
*not users* run.  Things like lpd, atrun, cron...

  Things in /bin are both for users and for the system.  Not that it
matters, except if you want to stick to the conventional *nix.  At
boot time only the root partition is mounted, so only /bin is
available.  In system installation, cc is needed so it appears in
/bin.  (So do other things that you need, for example, if you boot
"single user mode".)

:)   -  The floppy devices: Why not using the MINIX naming conventions?  /dev/at0
:)      would be /dev/fd0-dshd5in, /dev/PS1 would be /dev/fd1-dshd3in.  I can
:)      post the complete MINIX floppy names, but I think not all of them are
:)      implemented in Linux.
:)
:)   Any comments?
:)
:)   Michael
:)

  Sounds good to me.  If we can tell at a glance what the device is,
that's nice.  Under Ultrix, all disks are "rz".  rz0c could be my
floppy or my hard drive.  How it's handled and mounted is determined
from the /etc/fstab.  I like having a differant name better.

--
# Harold Tomlinson                      ##      [email-masked] #
# Computing & Communications Services   ##      (416)736-5257-33802         #
# YORK UNIVERSITY, Ont, CANADA          ##      ########################### #

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

From: [email-masked] (Hongjiu Lu -- Graduate Student)
Crossposted-To: alt.os.linux
Subject: IMPORTANT: gcc 2.1, libc.a 2.1a and Linux
Date: 6 Apr 92 21:15:00 GMT

Hi,

I heard there were some problems with binaries linked with my new ld.
That is caused by the new a.out.h introduced with Linus's second patch.
The new a.out.h is compatible with the old one, But not vice versa.

My new ld (binutils.tar.Z) uses the new a.out.h. The binaries
linked by it can only run under the kernel with Linus's second patch,
which has to be built by the old ld.

Any programs using the old a.out.h, e.g., gdb, will not recognize the
binaries linked by the new ld. You can either use the old ld or use
the new version compiled with the new a.out.h.

From Linus's second patch, we are moving to VFS. As a result, there
will be some changes in libc.a. That means next release of gcc 2.x and
libs will not run under the kernel below Linus's second patch to 0.95a.
I strongly recommend you move to 0.95a with Linus's second patch if you
haven't done so.

H.J.

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

From: [email-masked] (Hongjiu Lu -- Graduate Student)
Crossposted-To: alt.os.linux
Subject: IMPORTANT: gcc 2.1, libc.a 2.1a and Linux
Date: 6 Apr 92 21:15:00 GMT

Hi,

I heard there were some problems with binaries linked with my new ld.
That is caused by the new a.out.h introduced with Linus's second patch.
The new a.out.h is compatible with the old one, But not vice versa.

My new ld (binutils.tar.Z) uses the new a.out.h. The binaries
linked by it can only run under the kernel with Linus's second patch,
which has to be built by the old ld.

Any programs using the old a.out.h, e.g., gdb, will not recognize the
binaries linked by the new ld. You can either use the old ld or use
the new version compiled with the new a.out.h.

From Linus's second patch, we are moving to VFS. As a result, there
will be some changes in libc.a. That means next release of gcc 2.x and
libs will not run under the kernel below Linus's second patch to 0.95a.
I strongly recommend you move to 0.95a with Linus's second patch if you
haven't done so.

H.J.

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

From: [email-masked] (Mike Ching)
Crossposted-To: alt.os.linux
Subject: directory tree
Date: 6 Apr 92 17:20:38 GMT

I am just getting Linux installed and would like to use a "standard"
directory tree if possible so that I don't have to edit makefiles
any more than necessary. The installation script creates src and bin
directories in several places and it's not clear what usually goes
in them. Any suggestions?

Mike Ching

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

From: [email-masked] (Mike Ching)
Crossposted-To: alt.os.linux
Subject: directory tree
Date: 6 Apr 92 17:20:38 GMT

I am just getting Linux installed and would like to use a "standard"
directory tree if possible so that I don't have to edit makefiles
any more than necessary. The installation script creates src and bin
directories in several places and it's not clear what usually goes
in them. Any suggestions?

Mike Ching

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

From: [email-masked] (c t wilson)
Subject: Re: Compilers
Date: 6 Apr 92 23:01:15 GMT

In article <[email-masked]>, [email-masked] (Nate Williams) writes:
> In article <[email-masked]> [email-masked] (Ajay Shah) writes:
> >Come on... it's $130 for a 4 Meg SIMM.
> 
> Yeah, but you have to buy 4 x 4-Meg simms to work on a 32bit machine.
> 
> After shipping that's around $500.  But, you can buy 4 1-Meg Simms, if 
> you still have slots left.
> 

Where do YOU buy your memory?!?!?!?  My 4 meg, 32 bit simm (80 ns) cost about
half that AFTER shipping.  Not only that, I found an even better price ($210 
before shipping) after I ordered..

> 
> Nate
> -- 
> :-):-):-):-):-):-):-):_):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-)
> :-)Inet: [email-masked]  :-) Sys. Mgr. - GIS lab : Earth Sci.:-)
> :-)Bnet: osynw@MTSUNIX (Painfully slow):-) The guy blamed for everything   :-)
> :-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-)

Tom Wilson                                 <[email-masked]>

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

From: [email-masked] (Duty Programmer)
Subject: Re: Linux Drivers and Kernel question.
Date: 7 Apr 92 00:04:33 GMT
Reply-To: [email-masked]

In article <[email-masked]>, [email-masked] (Erik Fichtner) writes:
|> *someone* out there with enough space to produce one good working binary.. 
|> X isn't something you need to have the source online for, IMHO... once it's 
|> working, leave it alone..  (No, i'm obviously not an X junkie.. i just need
|> xv and some other graphics manipulation tools and that's it. virtual consoles
|> are faster than point-and-click)  
|>  

Yes, but there's just no substitute to having everything visible on the screen
at the same time. Certainly there is no need for people to compile X individually.

What I've been wondering is this: I suspect many of us would love to have X running
on isolated PCs: is it possible to cut out all the X networking stuff ? Would this
reduce the size of the server by very much ? Then we could have 2 X binaries to ftp ...

rab
-- 
========================================================================
Richard Brown                     | E-mail: [email-masked]
School of Physics                 | Phone : +61 3 344 5081
University of Melbourne           | Fax   : +61 3 347 4783
Parkville Victoria AUSTRALIA 3052 | Telex : AA35185

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

From: [email-masked] (Jim Winstead Jr.)
Subject: Re: Beginner's Guide: Installation
Date: 7 Apr 92 00:44:16 GMT

In article <[email-masked]> [email-masked] (Joseph Dougherty) writes:
>In article <[email-masked]> [email-masked] (I Reid) writes:
>
>       In reading through this informative post, I discovered only one real
>major error. In the table where you point out the minor numbers of the hard
>disk partitions, there is an error that should be corrected.:
>
>>>>
>        For a hard disk the major number (offset 509) is always 3, and the
>    minor number (offset 508) is a combination of primary or secondary HD
>        drive and partition details (see FAQ for details). Here are the details
>
>    Device      Major    Minor       Device      Major    Minor
>    ------      -----    -----       ------      -----    -----
>    /dev/hda1     3        1         /dev/hdb1     3        65
>    /dev/hda2     3        2         /dev/hdb2     3        66
>    /dev/hda3     3        3         /dev/hdb3     3        67
>    /dev/hda4     3        4         /dev/hdb4     3        68
>    /dev/hda5     3        5         /dev/hdb5     3        69
>    /dev/hda6     3        6         /dev/hdb6     3        70
>    /dev/hda7     3        7         /dev/hdb7     3        71
>    /dev/hda8     3        8         /dev/hdb8     3        72
>
>>>>>
>
>       In the second set of device numbers, the drive major number should be
>4 with the minor numbers as 1 through 8. This is for a second disk drive
>on a system, using single or multiple partitions. 

Um, sorry, but you are completely and utterly dead wrong - major
number 4 is for the tty devices, unless something drastic has changed
between 0.95a and 0.95c (patches only).  This is how Linux handles it
- Minix may be different, but that's irrelevant.

*Please* be careful with this.  There were problems with an old
version of the FAQ reporting the incorrect numbers, and people will
turn up with some rather major problems with this sort of confusion.
-- 
Jim Winstead Jr. (CSci '95)    | "Catch a fish!"
Harvey Mudd College            |  -Geddy Lee,
[email-masked] |   San Diego Sports Arena
Disclaimer: Mine, not theirs!  |   January 20, 1992

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

** 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: [email-masked]

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

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    tupac-amaru.informatik.rwth-aachen.de	pub/msdos/replace

The current version of Linux is 0.95a released on March 17, 1992

End of Linux-Activists Digest
******************************