From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Newsgroups: comp.os.linux
Subject: (none)
Date: 15 Aug 92 01:11:56 GMT
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Organization: The Internet

|From Linux-Activists Fri Aug 14 20:45:10 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 21:03 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
	 id AA27966; Fri, 14 Aug 92 21:02:27 EDT
Received: by bloom-picayune (5.57/25-eef)
	id AA19767; Fri, 14 Aug 92 20:45:28 -0400
Message-Id: <9208150045.AA19767@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 20:45:10 EDT
Subject:  Linux-Activists Digest #638
Content-Type: text
Content-Length: 29308

Linux-Activists Digest #638, Volume #2           Fri, 14 Aug 92 20:45:10 EDT

Contents:
  Linux Project Registry (Friday, 14 August, 1992) (James P. Callison)
  Re: What the 17" monitor reviews never tell you (Phillip Rzewski)
  Re: shared libs - can everyone be happy with this? (william E Davidsen)
  (none) (Linux-Activists@BLOOM-PICAYUNE.MIT.EDU)

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

From: callison@uokmax.ecn.uoknor.edu (James P. Callison)
Subject: Linux Project Registry (Friday, 14 August, 1992)
Date: 14 Aug 92 23:51:32 GMT

This is the Linux Project Registry. It is divided into several parts, as
follows:
          (I) Short Listing of Projects Underway 
         (II) Abstracts/Descriptions of Projects from (I)
        (III) Short Listing of Continuing Projects
         (IV) Abstracts/Descriptions of Projects from (III)

But first, some Administrivia.
First and foremost: 
        This is a Project Registry. I am not a project coordinator, and
        unless my name is listed on a project, I really can't help you
        with questions on that project. I'd like to, but I really can't.
        Please direct questions on projects to the appropriate person,
        mailing list, or to comp.os.linux.
Next:
        The list is going weekly, at least until it gets 
        established. I've recieved excellent responses to the list,
        and it looks like this thing will actually work! :-)
Also:
        Ari Lemmke (arl) asked me to mention that the mailing list
                linux-activists@niksula.hut.fi
        was available for help with alpha/beta testing of software.For help,
                mail linux-activists-request@niksula.hut.fi </dev/null
        (just type that in on the command line, if that didn't make sense to 
        you UNIX newbies out there. Don't worry, we were all newbies once...)
        Possibly starting next week, a list of all the mailing lists/channels
        will appear in this space (if someone can get me a list of all the
        Linux channels...)
Last:
        When you send me a submission, _please_ put "Linux Project Registry"
        in the Subject line. I get quite a bit of Email at times (which all
        seems to say "MCI Mail rejected a message" recently--and I didn't
        even send the stupid message), and being able to search for that 
        subject line makes it much easier. Thanks.

As always, We Thank You for Your Support! ;-)

And now begins the Linux Project Registry...

================    PART I    ============================================

Project Name                    Status          Email Address
==========================================================================
1) X386 port for VGA            Middle Burner   hzatz@graphics.cornell.edu
2) Keyboard key switching       in fridge       ben@djehuti.champaign.il.us
   (Ctrl -> Caps Lock, etc.)
3) Kernel TCP/IP                Alpha.3 Rel.    bir7@leland.stanford.edu
                                Testers Needed
                                (See PART II)
4) Boottime Root Choice         Init. Code      geek@cmu.edu
                                Eval & Struct   bg11@andrew.cmu.edu
5) ISO9660 file system(CDROM)   beta            eric@tantalus.nrl.navy.mil
6) SCSI CDROM support           beta            rafetmad@cheshire.oxy.edu
7) X386 port for 8514/A         Alpha test      martin@cs.unc.edu
                                Testers needed
8) Common LISP implementation   Alpha test      
                                        haible@ma2s2.mathematik.uni-karlsruhe.de
9) Linux Kernel                 0.96c pl2       torvalds@kruuna.helsinki.fi
10) Linux Root Disk             0.96            jwinstea@jarthur.Claremont.edu
11) Linux man(2) pages          (see PART II)   jwiegand@moe.eng.temple.edu
12) Keyboard Patches                            thoth@uiuc.edu
13) AHA 1732 32-bit SCSI        begin late Aug. mikee@seas.gwu.edu
14) PLP printer spooler         Primary port    dhs@moeng2.minc.umd.edu
                                project
15) X386 for Trident SVGA       alpha test      alanh@logitek.co.uk
16) MS-DOS file system support  alpha test      almesber@nessie.cs.id.ethz.ch
17) LILO--Generic Boot Loader   alpha test      almesber@nessie.cs.id.ethz.ch
18) Port of GRASS 4.0           porting         asmall@mach1.wlu.ca
19) Port of sc (spreadsheet)    beta test       djansa@shorty.cs.wisc.edu
20) Math emulator refinement    on hold         lynch@ccwf.cc.utexas
21) Extended File System        enhancing       card@masi.ibp.fr
                                functionality
22) Linux kernel TCP/IP         pre-alpha       gc@eng.cam.ac.uk
    support(BSD sockets)                        ceh@eng.cam.ac.uk
23) Xenix emulation             alpha test      lfoard@turing.org
24) User Space Block Devs       back burner     lfoard@turing.org
25) port of xtank               executes,       
                                unstable       sinster@scintillal.capitola.ca.us
26 IEEE 754 implementation      reading stds    
                                               sinster@scintillal.capitola.ca.us


================    PART II    ===========================================

I have translated the comments of the programmers/porters as best I could.
Quotes ("") indicate that the programmer/porter's own description is used.
(If I've messed anything up, please feel free to let me know. Nicely. :-)

1) Port of X386 to work with standard VGA
2) Keyboard patches to allow switching of keys (eg--<Ctrl> for <Caps Lock>)
   gone from back burner to fridge.
3) Kernel TCP/IP support, in Alpha.3 Release. Testers are needed; see the 
   NET channel of the mailing list for more information or to volunteer.
4) "boottime root choice. i.e. at boot time, as user for root partition
    (with default and timeout)." 
5) "ISO9660 filesystem (CDROM)" now beta; no known or outstanding bugs.
6) "SCSI support for CDROM" works fine, but has known bugs and difficulty
   with existing SCSI support; now beta
7) Port of X386 server to work with video cards regiter-compatible with 
   IBM 8514/A Display Adapter. Alpha testing begins 27 July, 1992, and
   testers with non-ATI, 8514/A-register-compatible adapters are needed.
   Please contact martin@cs.unc.edu (Kevin E. Martin) to volunteer.
8) Implementation of Common Lisp for Linux 
9) Err, 'nuff said, eh? :-) 0.97, Patch level 1 is the most currentest
   version (as of Noon, CST, 6 August, 1992 :-).
10) 0.96 is the most current version of the root disk.
11) Due for an end-of-August release (maybe). "Hopefully the best damn
    guide you will ever see." ;-)
12) Currently working on keyboard patches to send to Linus.
13) Will begin work on AHA 1732 32-bit SCSI drivers in late August (unless
    someone beats him to it).
14) porting Patrick Powell's PLP lpd software from U of Minnesota.
15) X386 Trident support is in alpha test stage, and has been sent to Orest
    for inclusion in the next release of X386.
16) MS-DOS file system support is currently supported in the kernel, and
    allows MS-LOSS (err-I mean "MS-DOS" :-) floppies and HDs to be mounted.
17) LILO is a fs-independent boot loader which can boot other systems and
    allows interactive selection of the kernel or OS to be booted.
18) GRASS (Geographical Resources Analysis Support System) 4.0 is a PD
    raster/vector GIS (Geographic Info System), image processing system,
    and graphic production system used extensively at government offices,
    universities, and commercial organizations encompassing 250 user
    programs, written in C, containing over 300,000 lines of code. 
        (Description provided by Alastair Small, from "Intro to GRASS 4"
         by Jim Westervelt, 17, July, 1991)
19) sc (spreadsheet calculator) is in beta test, working on arrow key support.
20) Math Emulator Refinement is currently on hold.
21) The extended fs is now included in the kernel,  but Remy is still working on
    enhancing its functionality.
22) Linux kernel TCP/IP support to provide BSD4.3 socket support, as BSD source-
    based FTP and TELNET will form part of alpha release. Hopefully, socket
    routines will allow development of NFS routines.
23) Xenix emulation; now in alpha test, testers needed.
24) User space block devices--requests for read/write ops passed to user
    process instead of device driver. Once network support is added, could be
    easily modified to allow remote (non-shared) mounts of HDs. Currently works
    well enough to have user process ramdisk; wants to make Stacker-like
    program, but needs block compression code. If you want to take it over,
    email him.
25) port of xtank
26) implementation of IEEE 754 standard; still reading standards


================    PART III    ==========================================

On-going Projects

Project Name            Last "Issue"            Email Address
==========================================================================
1) Project Registry     6 August, 1992
                        constellation!biglaw!registry@mailhost.ecn.uoknor.edu
                                or              callison@uokmax.ecn.uoknor.edu
2) FAQ list             11 July, 1992           linux@numero6.greco-prog.fr
3) Meta-FAQ             Last Monday             Lars.Wirzenius@helsinki.fi
4) Bug Reports/Fixes    (none; ongoing)         ml-linux-bugs@dg-rtp.dg.com
5) Mtools FAQ           21 July, 1992           almesber@nessie.cs.id.ethz.ch
6) Linux BBS list       12 August, 1992         healyzh@holonet.net

================    PART IV    ===========================================

1)This list, obviously :-). To get your project on this list (which will be
   posted bi-weekly, or weekly, if there's sufficient demand), send a 
   message with the Subject line: Linux Project Registry, and the
   body containing:
        1) your email address (if you don't include it, I'll use the address
           from the mail-header, which tends to be messy around here)
        2) a short description of your project (see above for examples)
   and  3) a status report (eg, Alpha.3 Release, beta testing, etc.)
   to
        constellation!biglaw!register@mailhost.ecn.uoknor.edu
        (constellation!biglaw!register works from some sites;
         constellation's full address is constellation.ecn.uoknor.edu)

   or, (IF and ONLY IF the above address doesn't work for some reason)

        callison@uokmax.ecn.uoknor.edu

   If you send me something to include in the list, please send me a note
   when the status changes, as well. It's kinda hard to keep up with you
   guys, as fast as you're going on some of these projects. :-)

2) the Frequently Asked Questions List. If you have a question, read it
   first. 'Nuff said.

3) The "Meta-FAQ"; a short list of pointers with accidental answers :-)

4) The "official" Linux Bug-Report site. The proper procedure is:
        1) post to comp.os.linux to determine if your bug is, in fact, a bug, or
           if it is a problem with your system (or your system's admin :-)
        2) get the Bug Report Template, fill it out, and mail it to
                ml-linux-bugs@dg-rtp.dg.com
   If you have a bug fix/workaround, follow the same procedure, but with 
   a different template.

5) Frequently Asked Questions about mtools; primarily addresses installation
   issues. Posted regularly.

6) Linux BBS registry: a world-wide list of Linux-carrying BBSs (for those
   without Internet access).
================================================================================
Any constructive comments can be sent to me,
                callison@uokmax.ecn.uoknor.edu
and any flame can be sent to /dev/null :-)

                                James

James P. Callison       Microcomputer Coordinator        OU Law Library 
Callison@aardvark.ucs.uoknor.edu   /\        Callison@uokmax.ecn.uoknor
        constellation!biglaw!callison@mailhost.ecn.uoknor.edu
DISCLAIMER: I'm not an engineer, but I play one at work...
        Lawyers get you out'n the kind of trouble you'd never get in 
                if there was no lawyers. -- Cowboy logic

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

Crossposted-To: comp.unix.sysv386
From: kutcha@eos.acm.rpi.edu (Phillip Rzewski)
Subject: Re: What the 17" monitor reviews never tell you
Date: Fri, 14 Aug 1992 22:20:44 GMT

In article <yPgiPB1w165w@questor.wimsey.bc.ca> sp@questor.wimsey.bc.ca (Steve Pershing) writes:
|exuptr@exu.ericsson.se (Patrick Taylor) writes:
|
|=> >I have an Eizo (which is the nanao in german) 9080i with the same
|=> >symptoms. I gave it back to get a new monitor, but got a letter from
|=> >Eizo, which said, that these 'moire' (thats the word with 'm' :-) )
|=> >pattern are a characteristic for 17" monitors. My solution is to have
|=> >a 'cornflowerblue' root window...
|
|I wonder if "moire" patterns are also visible on Sony's large (trinitron)
|monitors?  Anybody??

    You can probably count on it. I've seen some very nice monitors (like my
non-interlaced 14" ViewSonic 6 and these really cool monitors RPI has on their
Suns (I have no idea what company makes them, but I know they cost plenty and
are of generally high quality)) all go moire on that default gray that comes
up in X. I solve my problem the same way, by bringing up blue instead.

--
   Phillip Andrew Rzewski                      Internet: kutcha@acm.rpi.edu
   "I was very let down with the budget. I was expecting a one-million quid
      handout. I was very disappointed. It was the government's fault."
                            --- Mark E. Smith

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

From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Subject: Re: shared libs - can everyone be happy with this?
Date: 14 Aug 92 22:23:45 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)

In article <1992Aug14.162250.19760@ods.com>, david@ods.com (David Engel) writes:
| william E Davidsen (davidsen@ariel.crd.GE.COM) wrote:
| :   If you didn't want to use the jump tables, you don't load the module
| : and you get linked to the real routines directly in memory in the slib.
| : The advantage of this is that you get all the benefits of the current
| : slib implementation in terms of performance.
| 
| Actually, we've already done that in the latest test release.

Bravo! Then everyone will be able to make the best compromise for them.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.

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

From: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Subject: (none)
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date: Sat, 15 Aug 1992 00:43:20 GMT

|From Linux-Activists Fri Aug 14 20:00:16 EDT 1992 remote from BLOOM-PICAYUNE.MIT.EDU
Received: from BLOOM-PICAYUNE.MIT.EDU by salem.salem.ge.com; Fri, 14 Aug 1992 20:35 EDT
Received: by crdgw1.ge.com (5.57/GE 1.141)
         id AA25945; Fri, 14 Aug 92 20:09:05 EDT
Received: by bloom-picayune (5.57/25-eef)
        id AA18538; Fri, 14 Aug 92 20:00:40 -0400
Message-Id: <9208150000.AA18538@bloom-picayune>
From: Digestifier <Linux-Activists-Request@BLOOM-PICAYUNE.MIT.EDU>
To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Reply-To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
Date:     Fri, 14 Aug 92 20:00:16 EDT
Subject:  Linux-Activists Digest #634
Content-Type: text
Content-Length: 13222

Linux-Activists Digest #634, Volume #2           Fri, 14 Aug 92 20:00:16 EDT

Contents:
  Re: Problem w/ folppy boot when CD-ROM is attached to scsi controller (Eric Youngdale)
  Re: Stabilizing Linux (Drew Eckhardt)
  Re: Diamond Speed Star SVGA card (Drew Eckhardt)
  Re: X questions: how to run x-program on other machine? (Drew Eckhardt)

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

From: eric@tantalus.dell.com (Eric Youngdale)
Subject: Re: Problem w/ folppy boot when CD-ROM is attached to scsi controller
Date: 14 Aug 92 21:18:13 GMT

In article <1992Aug14.193537.15994@nas.nasa.gov> chiu@wk211.nas.nasa.gov (Ing-Tsau Chiu) writes:
|I got the following message when booting Linux 0.97 from floppy
|
|  aha1542_queuecommand: Two concurrent queuecommand?
|  70 00 02 00 00 00 00 0a 00 00 00 00
|
|I have an Adaptec 1542B scsi controller and a Toshiba XB3201 CD-ROM
|drive.  The computer is a clone 486/33 w/ Maxtor LXT-535 scsi disk.

        There are bugs in the error handling code in the stock scsi drivers
in 0.97.  (I am not sure, but as I recall, the standard CDROM drivers treat
the CDROM like a hard disk).  There are patches to fix this in the
cdrom-0.2.tar.Z distribution, which is available on tsx-11.mit.edu.

        I would be interested in knowing if there are any problems after you
have installed those patches.

-Eric
--
Eric Youngdale
eric@tantalus.nrl.navy.mil

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Stabilizing Linux
Date: 14 Aug 92 23:00:15 GMT

In article <1992Aug14.132232.22899@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
|In article <1992Aug13.195406.23296@colorado.edu>, drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
|| In article <1992Aug13.133313.15221@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
|| >In article <1992Aug12.173012.17552@colorado.edu>, drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes:
|| >
|| >And the person trying to install on a new machine can't rebuild the
|| >kernel, so s/he needs another working system to get going. Bleh.
|| >Relocation at load time might take 1-2 sec of cpu. Big deal. Without
|| >loadable device drivers you must have a working system to generate a new
|| >kernel.
|| 
|| Most Unices distribute the distribution kernel as a generic kernel,
|| ie one with support for all device drivers compiled in.  It gets a little
|| bloated, but if you can boot it, you can run anything.
|
|  Sounds to me like you think the Linux kernel as distributed contains
|all the devices anyone would ever want to use, so there's no need for
|being able to support new devices.

The assumption is that as new devices get added (such as Ross's 
ethernet drivers), that they will eventually make it into the 
distribution kernel, both in the sources and the generic binary.  

You can recompile (now), or relink (when a working config 
program is implemented) the kernel to add anything you need
before then - propriety GPIB driver, intelligent serial
driver, Ross's ethernet drivers, etc.

|  It also sounds like you're trying to say that you think it's too
|hard, and you personally don't need it, so you want to convince
|everyone it's a bad idea.

My opinion is that the percieved benefits (being able to add drivers at run 
time, saving a relink, rather than regenerating the kernel Makefile and 
relinking), are outweighed by the increased complexity 
of the device driver initialization, and memory allocation code.

- You add a new device driver, when one becomes available, or you
        install new hardware.  Neither is a frequent event. 

- Configuring a system, where you recompile ioconf.c or table.c, 
        and simply link in already compiled .o files for 
        everything else will take less than a minute on 
        anything that isn't thrashing - ie, a minimal 
        386 with ~4M of memory.  A reboot without fsck's 
        (ie, after a clean shutdown) about the same.

        So, you save two minutes everytime you add a new
        device driver.  I added a SCSI disk driver when I 
        finished the code, and will add a SLIP or CSLIP driver
        when one becomes stable.

        That's two drivers since last November.  

- Loadable device drivers let you shrink kernel size by leaving 
        out drivers you don't need.  You get the same effect 
        from a config program, only the kernel is even smaller because
        it doesn't need any of the hacks needed to accomodate 
        loadable drivers.  

I don't see any real benefits there.  

You can argue that loadable device drivers would make debugging 
easier for developers.  What's ideal for developers isn't necessarily 
ideal for users - ask any one who used the early, non-interrupt 
driven versions of the SCSI drivers.  They'll tell you about the 
wonderful interactive performance, and that the system would 
never hang for ~30 seconds while the disk(s) synced.  

When I did the SCSI code, I put in support for both interrupt, and 
non-interrupt driven SCSI drivers, thinking that "It would be 
much easier to debug the non-interrupt driven version."  It was
marginally easier, and all of the initial SCSI efforts ended up 
being of the non-interrupt driven variety that were the bane 
of SCSI users. It took us some time to debug the interrupt code (
one line needed moving in scsi.c), modify all of the 
lowlevel drivers, and get it back into the "stock" Linux distribution.

Interrupt driven SCSI drivers didn't make the stock distribution until
.97, and we've had SCSI versions since .12, support in the 
stock distribution since .95.

It's easier to do it right the first time, and avoid things of 
questionable value that may come back to haunt you.

I don't know that loadable device drivers would help that much 
during code development.  Much of the time is spent in design
and coding.  With device drivers, there are good chances of a 
bad device driver (ie wild pointer) corrupting the rest of the 
system.  Even if you can unload the driver, recompile, and load a 
new one, you may not want to, because something may have 
become corrupt in the rest of the system.  If you are booting 
from harddisk, the reboot-test cycle is not that bad.

I wouldn't say that loadable device drivers are "too hard" to implement - 
just that the added mess in the Linux code, and time it would take 
to do so aren't worth the benefits.

Linux is not a completely clean design.  Isolation between the 
various parts is not absolute.  Especially in the cases of 
pseudo-devices, like the lowlevel SCSI drivers, there is an
incestuous relationship between the driver code and the surrounding 
kernel.  The hard disk and SCSI drivers have special consideration 
given to them in ll_rw_block.c so they can get multi-block 
requests as one device driver request.  All of this would 
have to change, and in some cases, you may get nicer (but 
less tight) code.  

Like BSD, Linux uses certain "pseudo-devices."  These have 
a different interface than the normal block/character devices,
and will need special handling code.  Examples would include 
SYSV STREAMS, BSD network drivers, the Linux low level 
SCSI code.

Different parts of Linux are very dependant on eachother - for 
instance, some of the device drivers assume that kernel memory
is identity mapped.  malloc() preserves this assumption, but can 
only allocate 1 page at a time.  The same is true for get_page().

Current Linux devices have no way to "dettach" from the system,
necessary if you use loadable drivers for debugging, the only 
real reason you would want them. You need that, a way to track
what's mounted on block devices, etc.  

Current Linux code initializes all devices before the move to 
user mode, and most of it happens before buffercache, etc, is 
allocated.  (Well, sys_setup() is called from user mode, but that
just handles the partition tables on disk devices).  You'll need
to add all of the code to keep Linux happy when a new device 
is added.

It shouldn't be difficult, but I'd rather see people dedicate their
time to useful projects, like a SLIP driver for the TCP/IP package, 
a new VM using one page table per process to ease VM386 support,
remove the 64 process limit, increase the address space size, and 
support SYSV sghared memory semantics.  

Personally, I'll finish the SCSI driver rewrite (Experiments show that 
we can expect 3X current performance on unbuffered disks with 1K block file 
systems, 2 block read ahead, 12X if we move to 4K block sizes on the 
new file systems.  Buffered devices will see SOME improvement, I don';t
have one and can't say how much.) before playing with something useless.  






-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel. 

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Diamond Speed Star SVGA card
Date: 14 Aug 92 23:18:19 GMT

In article <1992Aug14.171832.23483@usenet.ins.cwru.edu> mal11@po.CWRU.Edu (Matthew A. Lewis) writes:
|
|
|
|
|anyone got this to work with X under Linux????

Yes.

|
|And also, is it true that the Diamond Stealth card won't work 'cuz
|it has that new S3 chip???

Yes.  There is currently no freely available S3 driver for X386.  However,
some of the Linux crew are working on one.  When available, it will probably
be folded into the X386 1.2 sources.  

The folks making the S3 are very friendly, and distribute accurate
doccumentation on their chips, for free.  Consequently, the S3 will be 
supported some time in the forseable future, x386 users will have 
an option for high speed graphics (I've seen X on a '486 running 
with the commercial S3 server.  VERY fast.  Very similiar to a 
fast RISC workstation, like an HP snake), S3 vendors will have 
a new market, and every body will win.

Colorado Memory Systems should take note of this - to the emerging 
free Unix market, and users of BSDI's product, many of their 
products are absolutely worthless, as they refuse to provide 
hardware documentation to anyone.


-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel. 

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: X questions: how to run x-program on other machine?
Date: Fri, 14 Aug 1992 23:23:37 GMT

In article <zhao.713807106@unixg.ubc.ca> zhao@unixg.ubc.ca (Jiansheng Zhao) writes:
|Hi, there,
|I have X running, but still have some questions. 
|1). I couldn't run any x-program (xrn, etc) on our university's mainframe
|unix machine, which has all those wonderful x-program. There supposed to be
|a xhost or something, or setenv DISPLAY xxx.xxx.ca:0, which I cann't figure
|out. University Computing Centre cann't help much, they were suprised to
|know I am running X on a PC under L-I-N-U-X. Is it possible to dial-in and 
|run x-program from my linux-X machine?

Not yet.  To run the stock X server and clients, you need to have 
either a unix domain socket (local machine), or a TCP/IP socket
connection.  This means you need to have IP access to the 
net on which the host computer runs.

IP access may be attained through either a dirrect ethernet connection,
or via SLIP or CSLIP - Serial Line IP, or Compressed SLIP.  

In order to run SLIP, both ends must be support SLIP software.  Generally,
you need th sysadmin of the remote site to add you in so that they will 
route packets to you.

Another possibility is setting up a bogus X server on the remote
machine as some display other than :0, and coming up with a scheme 
for transmitting requests to your local clients through some propriety
scheme.  

Certain vendors do this.

You might look at xmx if you are interested.

|2). In which subdirectory should I unpack those X-program sources to
|compile? 

Normally, it doesn't matter, as long as you have xmkmf installed on 
your system.  Xmkmf will "do the right thing", setting up the 
include directories, etc, as defined in your X config directory.
-- 
Microsoft is responsible for propogating the evils it calls DOS and Windows, 
IBM for AIX (appropriately called Aches by those having to administer it), but neither is as bad as AT&T.  Boycott AT&T, and let them know how you feel. 


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


** 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-Activists-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Activists@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
    tupac-amaru.informatik.rwth-aachen.de       pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

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

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


** 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-Activists-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Activists@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
    tupac-amaru.informatik.rwth-aachen.de	pub/msdos/replace

The current version of Linux is 0.97 released on August 1, 1992

End of Linux-Activists Digest
******************************
Newsgroups: comp.os.linux