Subject: Linux-Misc Digest #594
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:     Thu, 11 Aug 94 21:13:26 EDT

Linux-Misc Digest #594, Volume #2                Thu, 11 Aug 94 21:13:26 EDT

Contents:
  [Q] Cipher ST150-S2 working, anyone ? (Mario Nascimento)
  Mosaic+term compilation and build (Alan Fothergill)
  Re: rpc.nfsd changing UID [Q] (Donald Jeff Dionne)
  Re: ET4000/w32i? How well supported? (Technically Sweet)
  Re: 486DX66 and Linux (Adam DePrince)
  [Q]: Slack - ram mem reqs (J Jeffrey Thomas)
  Re: Australian Linux Users Group List [semi-regular posting] (Herbert Xu ~{PmV>HI~})
  Re: MouseLess Commander + Mouse Server for Linux (Miguel de Icaza)
  Re: starting X automatically on installing linux distribution (Sujat Jamil)
  Cross-compiling DJGPP binaries on Linux (Technically Sweet)

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

From: mario@seas.smu.edu (Mario Nascimento)
Subject: [Q] Cipher ST150-S2 working, anyone ?
Date: Thu, 11 Aug 1994 19:30:30 GMT

Was anybody out there able to put a Cipher ST150S2 to work under Linux ?
What configuration and SCSI card ? I wasn't able to do it w/ a AHA1522.
Thanks for any help.

Mario.

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

From: afotherg@oracle.com (Alan Fothergill)
Subject: Mosaic+term compilation and build
Date: 11 Aug 94 13:00:02

Hi,

I'm actually attempting to build a Mosaic+term on Sun, but any stories
on how this was done on Linux would help.

I'm using term 2.0.3

I've got Mosaic 2.4 sources that I compile with -include termnet.h

I then link with libtermnet.a

Everything links, but when I run the binary, a message flashes about
'Can't open non-blocking connection' or something like that.

BTW, the term connection works - I can connect with trsh


Any ideas? Do I need to make any patches to the Mosaic code? How were
the Linux Mosaic+term binaries built?

Thanks for any help,
Alan

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

From: jeff@ee.ryerson.ca (Donald Jeff Dionne)
Subject: Re: rpc.nfsd changing UID [Q]
Date: 11 Aug 1994 19:47:12 GMT

Karl Keyte (kkeyte@esoc.bitnet) wrote:
: In article 37800004@GLAS, Paul Makeev <mac@glas.apc.org> writes:
: >There is smth strange with rpc.nfsd on my system: the process started
: >from rc.inet2 randomly changes UID. (I tested it with Linux 1.1.33-41,
: >and result is the same). No problems with other daemons. Sorry
: >for posting this topic here, but i get no answer from comp.os.linux.help.

: Yup - does the same here.  I don't think it's random though but more something
: to do with who makes first use of one of the mounted NFS devices.  I admit,
: strange, and I have no idea of why or how...  Anyone?

Yes, so the user that mounts the filesystem only has access to what he/she
should have access to.  Of course, if you want a big security hole, you 
could hack the code to leave rpc.nfsd owned by root......

: Karl

: -------------------------------------------------------------------------
: Vitrociset S.p.A.                             Tel   : +(49) 6151 902041
: European Space Agency                         Fax   : +(49) 6151 904041
Jeff@EE.Ryerson.Ca

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

From: thinman@netcom.com (Technically Sweet)
Subject: Re: ET4000/w32i? How well supported?
Date: Thu, 11 Aug 1994 20:44:21 GMT

sl14@crux3.cit.cornell.edu (S. Lee) writes:

>I'm not sure about the speed, but one thing to keep in mind when
>you're considering an S3 is this: last I checked, SVGALIB doesn't have
>working S3 support yet.  That means you can't get anything above
>640x480 under SVGALIB, but XFree86 works fine (up to 1024x768 on my
>NEC 3D, my S3-805 supports 1280x1024 but the monitor doesn't - I think
>you knew this).

Clearly you should just rip the graphics driver suite out of Xfree86
and make it a separate standalone library.  This would certainly make
it easier to add new cards to Xfree86...


-- 

Lance Norskog
thinman@netcom.com
Artisputtingtogether. Art  s th ow n  aw y.

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

From: axd0822@hertz.njit.edu (Adam DePrince)
Subject: Re: 486DX66 and Linux
Date: Thu, 11 Aug 1994 05:09:39 GMT

In article <321fig$ntj@blackbird.db.erau.edu> andrew@amelia.db.erau.edu (Andrew Anderson) writes:
>Frank Derichsweiler (i31ade@applsrv.rz.unibw-muenchen.de) wrote:
>: mai@vietgate.apana.org.au (Van Dao Mai) writes:
>
>: >Folks,
>: >   I recently upgraded to a 486DX-66 motherboard with 16M RAM (72 pins 
[stuff deleted]
>: I own a Intel 486-66 Overdrive (same as 486 DX 2 - 66) and it takes around
>: 20 minutes to compile the kernel
>
>My Pentium 66 will do it in about 13 minutes.  Very nice, considering
>that my old 386-33 w/ 4Megs RAM would take between 4 and 6 *HOURS*.

My DX2/50 takes about 15 minutes (I'm using an analog clock so don't hold
me for exact timeings).  32Mb Ram and cached IDE card with
4 Mb probally helps this.  It usually runs me a little longer as I like to
compile my kernel with the -fexpensive_optimizations option.

-- 
===============================================================
Tic.                            |       Adam DePrince
                                |       axd0822@hertz.njit.edu

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

From: thomjj@aurxc1.aur.alcatel.com (J Jeffrey Thomas)
Crossposted-To: comp.os.linux.admin,comp.os.linux.development
Subject: [Q]: Slack - ram mem reqs
Date: 11 Aug 1994 20:27:17 GMT

excuse the cross postings, I tried this question in the help group and 
got only one response (maybe everyone there is asking questions?). 
Hopefully a broader audience will help.

I'm trying to install the latest release of Slackware. This is my
first try with Slackware or Linux.
I have a 386DX machine, with 2 meg of RAM, and 270meg of hard disk.

I have made a floppy boot and root disk (bare, and tty12). When I try
and boot, the screen starts displaying boot up information but gets an
error when it tries to access memory location 2097152. Since I only
have 2 Meg of memory (0-2097151), I understand that this could be a
problem ;-)
I had thought that Linux could be run with a basic setup with only
2 meg of Ram. Is this correct, and is it correct for Slackware? From
reading the FAQ's and How-To's (installation), I know that sometimes
the boot floppy will try to load ramdisk code between 2 and 4 meg and
that the user needs to indicate that this should not be done. I do
not believe this is being done in this case because the boot disk does
prompt me for boot up parameters (and lists these by typing a 'tab').
One of the prompts is to use the ramdisk, which I am not doing, so I
don't think that is happening.

Any ideas? Will Slackware run with only 2 meg?

thank you
_______________________________________________________________________
J Jeffrey Thomas                "The sea was angry that day my friends,
Phone:   (919) 850-5249          angry like an old man in a deli 
Fax:     (919) 850-5131          trying to return soup."
Email:   thomjj@aur.alcatel.com

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

From: herbert@greathan.apana.org.au (Herbert Xu ~{PmV>HI~})
Subject: Re: Australian Linux Users Group List [semi-regular posting]
Date: 10 Aug 1994 00:10:59 +1000

Mike Battersby (mibat2@penfold.cc.monash.edu.au) wrote:
: andrew@bing.apana.org.au (Andrew J. Cosgriff) writes:

: >It's time again.
: >Sorry for the somewhat sporadic nature of these posts, I'll try and force
: >myself to post them regularly, honest !

: Ever heard of crond(8)? :)

Isn't it supposed to be cron(8) :()
-- 
A.  B <=> True                  B.  A <=> False
Email:  <herbert@greathan.apana.org.au>
PGP Key:  finger herbert@sleeper.apana.org.au

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

From: miguel@roxanne.nuclecu.unam.mx (Miguel de Icaza)
Subject: Re: MouseLess Commander + Mouse Server for Linux
Date: 11 Aug 1994 17:49:19 -0500

herbert@greathan.apana.org.au (Herbert Xu) wrote:

> Does GPM require the kernel option of selection support?

Yes, you need the selection support in the kernel.

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

From: sujat@shasta.ee.umn.edu (Sujat Jamil)
Subject: Re: starting X automatically on installing linux distribution
Date: Thu, 11 Aug 1994 23:43:31 GMT

In article <32djat$cj9@solaria.cc.gatech.edu>,
Byron A Jeff <byron@gemini.cc.gatech.edu> wrote:

>
>1st impressions are important. The baseline for X will be small and slow on
>many many machines (especially ones that can do much better). I'd rather
>have an informed user using their system to the best of its potential 
>instead of a a bland generic introduction so we can play with Windows and
>OS/2


So, would I.  That's why during the installation, you'd have the
option of choosing the default "bland" configuration, or one that you
have optimized yourself, by again simply pointing and clicking the
right choices.  If you were more savvy than that, you'd install the
default, and then mess with Xconfig manually and set it to your own
liking.  Having a default does not limit the option, but gives a
starting point for the *uninformed*.

>
>1) It assumes that everyone has sufficient equipment to do the job. The last
>   time I checked the average machine has a 14" monitor, a non-accelerated
>   video card and 4MB of RAM. Fine for text - dog slow for X.
>

During installation, you can tell the installer, that for satisfactory
X performance, you require such and such minimum limit of resoureces,
otherwise X installation is impossible or unadvisable.  Many
brain-dead dos/windoze applications have warnings in a similar spirit.


>2) Too much variation between hardware. To solve either the user has to be 
>   asked (difficult) or use a baseline of 640x480x16 ( not very appealing).

I agree.  But, like I said, it's a start.

>
>3) At one point in time XFree86 was released with a sample Xconfig. This
>   practice was stopped when it turned out that folks were damaging their
>   hardware with it because they didn't understand how it worked.
>

Wouldn't happen if they installed the baseline.  Any warnings about
hardware damage can be given during installation just as easily or
completely as they are in a FAQ or howto.  If the users still do not
pay any heed, they deserve all that's coming to them.





>The bottom line is that text should be the default. Setting up X only takes
>a bit of knowhow and about 5 minutes of time (with the caveat that you know
>what you're doing - which much the target audience doesn't).
>
>I'd suggest either having an expert help with the X installation or have
>the user understand what's going on instead of just autoconfiguring.
>

Let's just agree to disagree. :)  I see that you are hooked on text,
and I'm not!  I actually don't see why we are having this argument.
The text would still be the default if the user heeds the warning
about resources etc, and doesn't install X, if there's not enough
resources for it.

>Note that Windows takes option 2 (640x480x16 default).

And much as I dislike windows philosophy, I agree with this option. :)

>
>No you're not. What I meant was that Slackware asks you about other hardware
>(modem, mouse, CDROM) during the configuration. It could possible ask about X.
>However the average user doesn't understand about video chipsets and bandwidth 
Then, the average user should use 640x480 until they do have enough
knowledge.  I think the bottom line is this.  There are ambitious
users and unambitious users.  My point is make it friendly enough not
only to all users (including the unambitous), but give a helping hand
to the ambitious so they get a headstart as they are exploring the
power of the unix and X environment.

>and other information needed to configure X. All I'm saying is that 
>autoconfiguring the X server isn't easy.

Absolutely.  As Patrick Volkerding just remined me in his email (yes I
have managed to annoy him too :>), Sun and Novell etc. spend oodles of
programming hours to make auto X configuration possible on the wide
variety of PC hardware.

>-
>-Yup, but back to Solaris and Unixware for x86 :)
>
>They probably take the 640x480x16 route. Not very appetizing at all.
>

Yes, but as I maintain, it's bettter than starving.

>No it's not because it gives new user the impression that all that's available
>and honestly 640x480x16 isn't real useful for X. Couple that with 4MB of RAM
>(which is still the standard config in most machines) that really slows things
>down you get a unusable interface which would tend to drive novices off.
>

Gosh, have you and Patrick just talked, or is it just great minds
thinking alike? :)  He said the exact the same thing.  My response is
again that it's no more different than the Windows or OS/2 user who's
faced with a similar situation.  The completely lazy unambitious user
will always accept the default option without any adventuring.  But,
that's fine.  If that's what makes them happy so be it.  They
shouldn't get the impression that that's all that's possible because
there'll be plenty of messages during installation (like I suggested
above) that'll inform the user about the minimum resoureces to run X,
and X's maximum capability depending on hardware resources available
(like higher resolution, more colors etc.).  The adventerous user will
avail of the possible optimizations specific to their system. 

>I'm working with an ET3000 right now. The scrolling sucks. You really need
>an acclerated card to efficiently use X.


I know what you mean.  I used to have a Trident.  But, I'd rather use
relatively poor performing X, with the possiblity of multiple xterms
(yes, I do prefer that over multiple virtual consoles), plenty of
menus, and virtual desktops (probably because I *am* a GUI phanatic :>), than a
relatively faster text-based UI.

>Even the current and near future machine won't really be up to the task because
>of memory. For example I was doing an installation on a brand spanking new
>Dell tower with a 486DX2/66 in it. Came with 4 MB of RAM. I had problems
>completing the install due to lack of memory. Even when I finished and ran
>X with a S3 accelerated card it was slow.

Really?  With a S3?  Did you try TinyX?

>
>Things should stay the way they are: No X with the option of installing after-
>ward. Maybe add a Xconfig auto option (which I believe already exist) to
>somewhat simplify the process. Maybe.
>

Again, I guess we need to agree to disagree.  I'd like to see the
exact opposite option, X by default, and no X for those who choose not
to install because they don't the necessary resource.


>That with your suggestion that X would be automatically installed which
>renders my machine useless. And if I'm a novice user expecting great

So, you wouldn't install it.  You wouldn't be forced to install X you know.

>performance from my machine after installing Linux, I'd be sadly disappointed.
>Starting with text and virtual consoles, my machine is quick and usable. So
>when I install X and it runs dog slow I won't attribute it to Linux but to X
>and start upgrading.

So, tell them during installation that "Your system would be dog slow
if you install X unless you have <x> amount of RAM and an accelerated
video card."  Since most ads now explcitly say when the system comes
with an accelearted card, most users probably can be expected to know
at least if their video card is accelerated or not.  Or if you agree
with me that acclerated card are nice but not essential, then just
tell the you should at least have <x> amount of RAM.


>-desires and needs, you get to choose your level of abstraction.  That's
>-what you can do on commercial Unix workstations, so why not on Linux PCs!
>
>That's fine. All I'm saying is to start with the baseline of character based

I vote for baseline X. :) See above.

>UI's which don't stress the machines resources with the option of upgrading
>to the X interface. Or even just checking the memory resources in /proc and
>using SuperProbe to check the video card and advising the user that they
>have marginal resources for running X. The video and memory resources for
>workstations are specifically designed to support X, the video and memory
>resources of PC are not.


Yes!  At last!  Now we are on the same page.  Yes, advise the user on
whether they should install X or not.  But if they can, install the
baseline by all means.  I was suggesting a more primitive "if you have
at least the following" then install X, but if SuperProbe and other
means can be used to further automate this, even better.  (I doubt the
monitor can be detected though :>, so probably the baseline 640x480
has to remain as default.)


>
>Unix is quite unforgiving of novice users. The DOS/Windows/Mac user 
>paradigm is that novices to the OS basically remain novices to the OS forever.
>And since the OS is quite limited anyway very little power is given away.
>However under Unix having an understand of what's going on "under the hood"
>can give of a multi-fold productivity increase. Also with a less complex OS
>mistakes are less damaging than in Unix. 

Like I said, a GUI based abstraction layer can be more forgiving than
the traditional "raw" Unix shells.  The same problem is faced by first
time users/administrators of NeXT machines (which were classified as
personal computers after all) and single user desktop workstations.
After all you have economists and biologists using single-user desktop
workstations that aren't administrated by other people.  I recently
saw some of the fancy administration software on an SGI workstation.
SGI has really made IRIX rather idiot proof (and idiot friendly :>).

>
>Ever done a "rm -rf /usr" as root? I have.
>

I haven't had the good fortune. 

>I have no fear of the paradigm shift. I use X wherever I have sufficient

Good. Glad to hear it.

>resources for it to operate efficiently. I still maintain that the average
>PC (486,4 MB RAM, non accelerated video, 14 in monitor) doesn't provide the

These resource are fast changing.   Pick up one of the recent glossy
PC magazines.  Almost all ads now sport 15" 1025x768 monitors, a lot
show 8MB RAM, and accelerated video.

>necessary tools to run X efficiently and that making a mandate that X
>be the baseline in that environment is a mistake.

Don't agree.

>If you have the hardware to do it justice.
>

Yup, and increasingly more new Linuxers will have the hw.

>Hmm. Alien? The is the setup for the user I described:
>1) login: (ok this is alien to DOS/Windows users)
>2) Type DOS at the prompt (prompt is analogous to C:\>)
>3) Type WP at the A:\> prompt
>
>Now except for 1) what's so alien about this? Even with the explanation that
>switching to another VC one could do mail at the same time (VC switching is
>analogous to ALT-Enter in Windows) this was information overload. That user
>switched back to DOS.
>
>When I said adversion to any change, I really meant any change.


That does sound rather extreme.  Was your user a DOS user or a Windows
user?  Windows USERs are less familiar with command line interfaces.
But, I guess my main argument is that if the GUI could be made roughly
as "easy" to use as Windows/OS2/Mac what-have-you you'd attract more
people who'd appreciate the beauty of a powerful truly multitasking
network-friendly OS that isn't terribly harder than the alternatives
to use.  And give the adventerous users some time, they'll get tired
of pulling down menus, and soon get their hands dirty in shell
programming. :)

>-What exactly do you mean by that?  By allowing abstraction for the
>-average user, by allowing productivity software to run, you'd be
>-crippling the system?  
>
>No what I mean is that by hiding what's going from the user you cripple
>much of the gains between the user and the system. Users could do more
>and be more productive if they are exposed to certain aspects of Unix
>that you're trying to hide. So by transitional you give them the abstraction
>layer and the real goings on underneath the abstraction at the same time with
>the ability to choose/alternate between the two. Much like the file browsers
>that let you pick files: you can use the mouse/menu interface to choose, you
>can type it in, you can alternate between the two, and in all cases the real
>filename is being built/displayed in the dialog box. I'm opposed to the
>mouse/menu only method which many GUI's opt for.

Hey, I'm all for that.  I'm never saying that mouse/menu should be the
only way to go.  I'm sure you've seen the newer HP and SGI desktop
environments.  You can use mouse/menu for doing virtually everything
(even if it's in painfully long winded ways), or you can launch a
terminal window and get back to the familiar text interface.  I also
think your idea of showing the user what's going on when using
mouse/menu is quite interesting.  But, I don't quite agree with your premise
that a command line interface will unconditionally be the most
efficient way of getting the most out of your OS all the time.  Not
necessarily.  Like a writer who's using their computer just to write a
book only need to click on the icon that launches their favorite word
processor.  

The beauty of the unix environemnt is that they can have five
different copies of the word processors running at the same time
editing five different related chapters, and read their mail (by
clicking the appropriate icon) and cruise the "information
superhighway" :) using Mosaic, let's say.  And if Mosaic happens to
crash for some reason, the whole system does not go down.  This user
does not need to know that she can use sed and awk if she uses an
xterm.  But, she does know that her system can comfortably handle
multi-tasking and multiple users.


>It doesn't dimish the system, it dimishes many of the interactions that the
>user can have with the system. It reduces the complexity of the interface at
>the cost of reducing the power of the interface. The system doesn't change but
>the way that the user interfaces to the system does, at the user's detriment.


Well, let the user make that choice.  If they want to be lazy, they
loose some power.  If they want to learn, they can do more.

>
>It's exactly the same with VCR's. Most folks don't care how to program them
>or even set the clock. So VCR+ and others build interfaces that limit the
>interaction between the user and VCR. The cost of the limitation is that
>many features of the VCR are unavilable to the user because of the limited
>interface. Someone who interacts with the VCR interface directly has many
>more options as to how to use the VCR, at the cost of added complexity to
>the interface.

Yes, but you don't have to use VCR+.  Most VCRs with VCR+ also let you
do it manually.  *You* get to choose.  I'm saying let's have the same
choice available.

You have degrees of complexity in even the most commonplace
productivity software.  Take WordPerfect or Word.  You can use it at
its simplest level to type a letter in the default Courier font (and
if that's all you want to do with it you have wasted $300, but that's
your choice).  Or, you can write rather sophisticated Macros that let
you compile multi-file documents, with cross references, automatice
bibliography generation, and so and so on.  All I'm saying is give the
user this choice, and make it easy for the user to go up the
complexity ladder.

>
>I will continue to propose the compromise: Give the limited interface but
>don't hide the details of what's going on from the user. Even the most novice
>user will learn a shortcut, or some new way of interacting with the system
>to said user's benefit if a transisional interface is instituted.

I partially agree since I think no one has conclusively proved however that
a GUI is necessarily more limiting than a command line UI.  Perhaps,
in a multi-layered level, your option could be the intermediate layer
between a full fledged GUI and a full fledged command line UI, with
the user being able to choose what layer they want to be at.

>-Remember, you always have the option to strip away the abstraction if
>-you so wish.
>
>No they won't because they won't understand what's going on behind the
>curtain. The abstraction is a novice user's entire world unless you show
>them "the man behind the curtain".

So, have a multi-layered system, where you can go deeper and deeper
based on your level of expertise.

>
>Also I must press the point that sufficient hardware to support the abstraction
>must be available or that the point that the users hardware is insufficient
>for the task is clearly explained to them.

I agree completely with that.

>
>-
>-
>-I look forward to a powerful *and* friendly Linux based operating envrionment.
>
>I look forward to powerful *and* friendly Linux based users! ;-)

Well, I look forward to both. :)  But, I'd leave it up to the users
as to how powerful they want to get.

>
>Later,

Yeah, back to work (what's that)  ...

>
>BAJ
>-- 
>Another random extraction from the mental bit stream of...
>Byron A. Jeff - PhD student operating in parallel - And Using Linux!
>Georgia Tech, Atlanta GA 30332   Internet: byron@cc.gatech.edu

Sujat
--
*******************************************************************************
Sujat Jamil                                             Electrical Engineering
Graduate Research Assistant                             University of Minnesota
******************************sujat@shasta.ee.umn.edu**************************

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

From: thinman@netcom.com (Technically Sweet)
Subject: Cross-compiling DJGPP binaries on Linux
Date: Thu, 11 Aug 1994 20:49:22 GMT

Under 386bsd 0.1, I set up a system for cross-compiling DJGPP (GNU on DOS)
binaries.  386bsd used exactly the same .o file format as DJGPP.
All I had to do was load up the DJGPP includes and libraries,
and port the DJGPP ld, ar, and ranlib programs to 386BSD.
Et Voila!  A shell script around the whole thing made it pretty painless.

How would I do this here on Linux?  Are the binaries the same format
or different?  Has anyone done this?

-- 

Lance Norskog
thinman@netcom.com
Artisputtingtogether. Art  s th ow n  aw y.

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


** 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
******************************
