Subject: Linux-Development Digest #160
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Mon, 12 Sep 94 04:13:09 EDT

Linux-Development Digest #160, Volume #2         Mon, 12 Sep 94 04:13:09 EDT

Contents:
  Re: WARNING about shadow-mk package (John F. Haugh II)
  Re: Doom Music + PAS-16 (Tracy S. Schuhwerk)
  Re: Linux console to SCO comp. prob (Stephen Harris)
  Linux hangs on low speeds. :-( (Eugene Tyurin)
  RARP problem in 1.1.50 build ("Stephen Davies")
  Re: DEC EtherWorks 3 (Stephen Thompson)
  Re: Multiprocessing Pentium Systems (Scott Lawrence Lynn)
  Re: Don't use Linux?! (Kay Hamacher)
  Re: File locking--gurus please read. :) (Ben Eng)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Harri Pasanen)
  Re: Doom Music + PAS-16 (Hannu Savolainen)
  Re: Developing Distributed Filesystems for Linux? ("Derrick J. Brashear")
  Re: DOOM for Linux problem - help. (Patrick Reijnen)

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

Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,comp.os.linux.help
From: jfh@rpp386 (John F. Haugh II)
Subject: Re: WARNING about shadow-mk package
Reply-To: [email-masked] (John F. Haugh II)
Date: Sun, 11 Sep 1994 23:07:45 GMT

In article <im14u2c.778889543@cegt201> [email-masked] (Joe Zbiciak) writes:
>The original /bin/login will deny any logged in user from using
>the -f (username) option if they lack sufficient privledge.  Period.
>Indeed, the only reason -froot was a problem was that /bin/login
>determined that the "active user" calling /bin/login was indeed root
>and therefore had permission to use the -f switch.  Any user, once
>logged in, cannot use the -f option unless that user is indeed root.
>
>For those persons interested in verifying this statement, log in
>as a regular user and type "/bin/login -f root" or "/bin/login -froot"
>and see what happens.  You'll not become root.  The problem was in
>rlogin and console logins, where /bin/login was being invoked by
>root itself, rather than being invoked as suid-root.  Apparently, the 
>old /bin/login uses getuid() instead of geteuid() to determine the 
>real user id of the user executing the program.

The easiest solution is to use the patch I posted several months
ago and apply that to lmain.c.  It closes the hole correctly and
doesn't require any extra wrapper commands.

Just to echo my disdain for binary-only distributions, I had a friend
who recently was forced to buy a Linux CD pretty much because the
spare CD I have was binary-only.  So far the only people making money
off of Linux are the CD shops.
-- 
John F. Haugh II  [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ]   @'s: [email-masked]
 There are three documents that run my life: The King James Bible, the United
 States Constitution, and the UNIX System V Release 4 Programmer's Reference.

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

From: [email-masked] (Tracy S. Schuhwerk)
Subject: Re: Doom Music + PAS-16
Date: 11 Sep 1994 23:26:38 GMT
Reply-To: [email-masked]

In article <[email-masked]>, [email-masked] (Christopher M. May) writes:
|> Hi, Has anyone gotten the music to work in DOOM?
|> I've seen 1 person post with a SB16 who said it worked.
|> I thought doom was working perfectly, until I remembered there's
|> music too :)
|> 
|> My card passes the "fmtest" included in the sndkit.
|> (After I load the general midi patches... is this necessary?)
|> 
|> Also, do I have to compile in the MPU-401 support?
|> The PAS-16 emulates an MPU-401.
|> Is the DOOM code sensitive to Soundblaster IRQ?
|> 
|> Does the Music go out /dev/sequencer or /dev/midi, or /dev/dsp?
|> 
|> Finally, does anyone with a PAS-16 have music working?

   If it is anything like the SGI version (which it is supposed to be),
   there is no music...

   -- Tracy Schuhwerk
      [email-masked]

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

From: [email-masked] (Stephen Harris)
Subject: Re: Linux console to SCO comp. prob
Date: Sun, 11 Sep 1994 21:11:08 GMT

Keith Smith ([email-masked]) wrote:
: In article <[email-masked]>,
: I wrote:

: >If you don't like them, then build your own keymap file and termcap entry.

: Bad idea in most cases.  Ususally breaks bunches of stuff.  Of course

Such as?  I'd like to know, so that if/when I need to remap my keys then I'll
know what programs will cause problems.  Thanks.

: >The point is that programs can't make assumptions about keyboard maps.

: Ahh, but they do, they do.

I haven't seen many - infact I don't think I've seen any!  The "problem" with
a unix system is that the terminal at the end of the wire can be of any type.
The only way a program can know is to use the $TERM variable.  I have yet to
see ANY program which has hard coded key combinations, although I've seen
plenty with their own variation on termcap - generally complete with a VT
keyboard entry.

: >: 'Splain where F22 is on a VT100 will ya?

: Hmmm,  you need a 122 key IBM keyboard with an extra row of function keys
: (f13...f24) above f1...f12.  "common" (hahahahahaha) practice uses
: shift-f1 thru shift-f12 for f13 to f24 respective.

Great, so a common PC keyboard doesn't have F22, so you complain that a VT
doesn't have the same?  Huh?

: end-all of keyboard layouts.  Just that the Fkeys sent SANE logical
: sequences of keys.

I'd rather be able to distringuish between all the keys.  'sane' is matter of
opinion.

: compatable market.  Man those ADM-3's, wy-50/60/120/150/350/325/etc
: televideo 9xx, altos, link, etc are EVERYWHERE.

Almost everywhere :-)  I dont' have any in my London office (but I do in my
Greek office, which is why I hate them).

: >2) Software with keyboard sequence limits is severly broken.

: There are _ALWAYS_ limits.  Using the entire RAM resource of a machine
: to map keycode sequences would seem to me to be rather wasteful yes?

Come on, make sense.  Dynamically allocating space required for the keys
based on the definitions in the terminfo/cap databases would mean that
the entire RAM resources of a machine wouldn't be used.  (Unless the
termcap string was so long that you couldn't feasibly access it anyway!)

: Additionally long keyboard sequences are increasingly time consuming to
: decode, and require longer detect timeout intervals ESPECIALLY when used

5 keys at 9600 baud take 5ms approx to send.  3 keys take 3ms.  Gee, really
gonna notice the 2ms difference!  Modem quality is sufficiently variable anyway
to make this point moot.  A quick line glitch and you could wait a second
anyway!

: resource, but to save going nuts I avoided sorting the sequences into a
: tree and simply implemented a linear in-stream compare with shift
: holding chars in a queue of the same size as the longest key sequence
: you are decodeing.  Real pain in the ass, and it'll really beat the
: machine if you define a few hundred 10 character Fkey sequences.

Whereas if you had programmed it more efficiently then you would have had
a longer startup time, but quicker key decoding.  Lazy programming 'to save
going nuts' is just more bad programming.

: The main problem with longer sequences is TIME.  With the VT Fkey layout
: the lead-in key is also a commonly used key used to back up one step in

Yes, this is one fault of the VT keyboard.  Does make decoding harder, but
still at least each key is uniquely decodeable!  Proper programming, and the
simple fact that users generally type ahead mean that this is not such a
great problem as it appears.

Wonder how this turned into a slagging keyboard conversation?  I still maintain
my conclusion of my last message in this thread.

-- 

rgds
Stephen

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

From: [email-masked] (Eugene Tyurin)
Subject: Linux hangs on low speeds. :-(
Date: 12 Sep 1994 01:02:24 GMT
Reply-To: [email-masked] (Eugene Tyurin)

        Hi netters,

When I login into a Linux system (1.0.9 or 1.1.18) from my home
2400 baud modem via phone->Ethernet gateway at school, my session
gets frozen if I try to dump a large amount of text onto screen
(e.g. try to read man pages), unless I set stty 2400 (the default
for ttyp is 9600). I'd consider this a bug, because SGI machines
never do this to me although they also have 9600 baud default.
-- 
  Eugene Tyurin ( ITP, Stony Brook Univ. )
  E-mail: [email-masked] ( MIME mail is welcome! )
     WWW: http://www.physics.sunysb.edu:80/~gene/plan.html

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

From: "Stephen Davies" <[email-masked]>
Subject: RARP problem in 1.1.50 build
Date: Sun, 11 Sep 94 19:07:21 PDT

The 1.1.50 patch adds the definition of the arphdr structure to if_arp.h
but leaves it in rarp.c so that a redefinition error occurs during make.

========================================================================
Stephen Davies Consulting                              [email-masked]
Adelaide, South Australia.                           Voice: 61-8-2728863
Computing & Network solutions.                       Fax  : 61-8-2741015

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

From: [email-masked] (Stephen Thompson)
Subject: Re: DEC EtherWorks 3
Date: 12 Sep 1994 02:10:15 GMT

In article <[email-masked]>
[email-masked] (Alan Cox) wrote:

> >Actually, someone from dec has a driver for freebsd for this card.  (I've
> >included the post at the end of this message.)  Perhaps someone in the linux 
> >community could use it to develop a linux driver... 
> Whats wrong with the current depca driver, this seems to cover the same
> cards (DEPCA, DE100, DE200 Turbo, DE201 Turbo, DE202 Turbo, DE210, DE422).
> The DE203,4,5 are apparently a different custom ASIC.

There is now a etherworks 3 driver for linux, it works very well as I have been using it for about 2 weeks now without
fail

--
Stephen Thompson - South Pacific Technical Support
Digital Equipment Corporation (Australia) Pty. Limited A.C.N. 000 446 800
DTN: 730-5566
+61-2-561-5566
([email-masked]) 

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

From: [email-masked] (Scott Lawrence Lynn)
Subject: Re: Multiprocessing Pentium Systems
Date: 11 Sep 1994 03:08:57 -0700

In article <[email-masked]>,
Hugh Emberson <[email-masked]> wrote:
>>>>>> "David" == David Williams <[email-masked]> writes:
>[chomp]
Ditto...
>
>The easy way is the way that SunOS 4.1.3 does it, or is rumoured to do
>it.  Allegedly 4.1.3 has a single spin lock around the entire kernel, so
>that only one processor can be executing inside the kernel at any time.

I've never looked at the SunOS 4.x.x kernel, but I can't imagine that it was
done this way.  Spinlocks have timeouts on them, and you could easily have
a CPU wait for much too long due to the inherent possibility of starvation 
that comes with a spinlock.  

One way to handle SMP simply is to put spinlocks around all the kernel
data structures, or major subsystems.  This will still probably take a 
great deal of work to get it right, and it'll have problems.  
It's a good start though.

>
>Would it be possible to do this with Linux? 
>
>4.1.3 with its big spin lock seems to perform better than multithreaded
>Solaris 2.x on multiprocessor machines, though this is probably due to
>other problems with Slowaris.
This probably has more to do with Solaris 2.x being based on SVR4.  For
starters SVR4 uses STREAMS instead of sockets!  Also, SVR4 typically
eats more memory than BSD.

Scott Lynn

      -m-------   Scott L. Lynn                    [email-masked]
    ---mmm-----   Pyramid Technology Corporation   Voice: (408) 428-7305
  -----mmmmm---   3860 N. First Street             Fax:   (408) 428-8845
=======mmmmmmm=   San Jose, CA 95134=1702

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

From: [email-masked] (Kay Hamacher)
Subject: Re: Don't use Linux?!
Date: 11 Sep 1994 12:46:59 GMT

In article <[email-masked]>, [email-masked] (Michael Schumacher) writes:
|> Okay. Before you start sending me endless flames, I want to make sure
|> that you know that I *love* Linux. It's probably the best PC Un*x you
|> can find between here and the sun. 
Yeah. So I think, too.
 
|> 2. Linux's libc tends to change its version number almost every week
|>    (sometimes even more often). Even though changes of the minor
|>    version number should not affect previous applications, they will
|>    sometimes break them. This means for a company that they have to
|>    debug the library in order to find a work-around (see 3.).
|> 3. The kernel versions change faster than the speed of light. If you
|>    ask for a "stable" version, you'll be teached that there are two
|>    versions: 1.0 (production) and 1.1 (hacker's paradise). Wanna have a
|>    stable one? Get 1.0! Okay, but if I want to offer a commercial
|>    product, it doesn't matter what kernel version *I* am using, but
|>    what version is used by my potential *customers*! There's a reason
|>    for 1.1: it is a bit faster, it supports more hardware, it provides
|>    more features. As a result, most Linuxers traditionally pick up the
|>    the newest kernel releases all the time - and usually end up in this
|>    newsgroup, saying "this is broken", "that doesn't work anymore",
|>    "can't compile", etc. (if you don't believe me, just exit this thread
|>    for a moment and take a look at the other subjects). Besides other
|>    disadvantages, this will definitely not convince companies of the
|>    stability and usefulness of Linux!
So your conclusion must be : companies prevent techincal progress by developing
only stuff for accepted and wide spread hardware as they must orientate their
work to high numbers of users. Free software must not do such silly things.

|> 5. On the other hand, I can tell you how to make lots of money with Linux: 
|>    simply download the archives of tsx-11, sunsite, nic.funet.fi,
|>    prep.ai.mit.edu and ftp.x.org, put them on a CDROM, call it "Dream Linux"
|>    or similar, and sell if for US$35 per copy. It's that easy. Let's say,
|>    an average user is looking for "the better OS" and wants to try out
|>    Linux. He buys a "Dream Linux" CD - and is lost. Nothing works "out of
|>    the box", no reasonable documentation is available, nor hotline support. 
|>    What will happen? I'm quite sure that most of these desperated people
|>    will close the Linux chapter - forever.
That is the problem : much money without any work. Companies must say "Dream..."
or "best OS" as they compete against ecah other. That needs resources to 
compete and so these resources can not do work on the product. 

|>    Quo vadis, Linux? Do we continue to like Linux "as is", or should we
|> change something in order to encourage companies to develop commercial, but
|> sophisticated end-user software for this beautiful OS? Do we continue to
|> keep Linux a powerful tool for wizards only, or do we want to see Linux 
|> being used in offices and other commercial environments? If we *really*
|> want Linux to succeed, we *need* the companies and their commercial products!

But do we need business men using Linux ? I do not need them. I am happy
in using Linux for my personal needs and work (e.g. Mails,News,graphical stuff).
Linux has developed to this high standard without any commercial leading-strings.
So Linux is any argument *against* commercial software and not for symbiose with
it, IMHO. The power Linux gives me to do my work let my laught about any
Windows-user, as he is wasting the power of his PC.
How long has it take to develope Solaris or UnixWare ? Very long. Are they 
better ? You gave the answer in your posting. So the true progress was done
by private people and not by companies. Linux as the best *NIX has a developing
time not as long as other PC-Unix had, but it is better. So, do we need commercial
software ? And even if Linus had not this great idea called Linux :
There is also Free-BSD.

The real problem is in the mind of most people : Everything which is good must 
be very expensive! So Solaris with high prices must be better than UnixWare
which seems to be better than Linux, as Solaris is more expensive and more
packed as UnixWare which is indeed more expensive than Linux. Or see Windows :
It is not good, it is bad. But : 1) the companies see only the stupid customer
buying his first computer. So they say : "hey, let's get Windows. You can simply
move the mouse-pointer round and do everything" And why ? Because they want
to get their percentage of the Windows-price. No computer-dealer would say to
the normal customer : "Use Linux, it is better", as he earns no extra money with
this kind of software. and 2) that is the point of view : everything must be
orientated on the big sell-numbers and not on the performance.
It is similar to cars :  profis know where to buy good stuff to tune their
car or to cause the car not to need such high volumes of gasoline. The 
average user of the car does not exactly know what does this machine (as I do not
know this), but it works : Fine ! I have not the time to intensive my knowlege
about cars and it makes me no fun. But there are people having fun on doing
this. So why should there be no people having fun in compiling every week
a new kernel for the system they use ? It is not car-tuning it is simply
computer-tuning. What is wrong on this ?

Kay

-- 
==========================================================================
Kay Hamacher                                 Phone   : ++ 49 2332 80650
Milskotter Str. 19                           Fax     : ++ 49 2332 83518 
58285 Gevelsberg                             InterNet: [email-masked]  
Federal Republic of Germany - European Union                  

      Viele Menschen sind zu gut erzogen, um mit vollem Mund zu sprechen,
      aber sie haben keine Bedenken, es mit leerem Kopf zu tun. (Oscar Wilde)   

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

From: [email-masked] (Ben Eng)
Subject: Re: File locking--gurus please read. :)
Date: 12 Sep 1994 02:41:17 GMT

Willis Boyce ([email-masked]) wrote:
: I've been working recently on a DBMS project under Linux.  My ultimate 
: goal is to create a DBMS which compares favorably with commercial systems 
: and which provides a very simple interface into C.

: After looking into various methods (I'm pretty new to Unix), I decided to 
: use advisory file locks as my concurrency mechanism.  These have two big 
: advantages:

: 1.  They allow me to use a decentralized approach to concurrency.
: 2.  They have built-in deadlock detection.

: Unfortunately, the Linux 1.1.8 that I am running apparently doesn't 
: support deadlock detection.

Have you considered sticking with non-blocking advisory file locks?
Often it is not necessary for a process to block on grabbing a lock,
if the process is able to deal with it properly.  Additionally, your
processes can always avoid deadlocks by agreeing on an ordering
convention when applying locks to multiple files.   (Say your
relations are identified by an internal numbering scheme, then you
would always apply non-blocking locks in ascending or decending
relation number order.)

I have found that relying on deadlock detection in the underlying
filesystem implementation has not been a pleasant experience.  In
particular AFS does not implement deadlock detection at all (among
other file locking features that are also not implemented, or are
broken; ie., non-blocking locks).

But if you do decide upon implementing deadlock detection in the Linux
kernel, it would definitely be appreciated here.

Ben
--
e-mail: [email-masked] or [email-masked] (Ben Eng)
UofT EngSci 9T2            ``We are all masochists here.''
Home: (613)-567-9983       Work: (613)-567-4740

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

From: [email-masked] (Harri Pasanen)
Crossposted-To: comp.lang.fortran
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: 12 Sep 1994 06:19:16 GMT

   From: [email-masked] (Mike Castle)

   In article <[email-masked]>, Dan Pop <[email-masked]> wrote:
   >Could you post some examples where a commercial native compiler for x86
   >produces _significantly_ faster codes than the free gcc?

   IBM's C compilers under OS/2.
   Watcom compilers under OS/2 and DOS (do they have unix versions?)
   Zortech C compiler (I presume under OS/2 and DOS as well).
   Most likely the Mark Williams C compiler (they produce better
     compilers than operating systems (coherent)).

   GCC is designed to be PORTABLE first, optimal last.  In almost
   all cases, a DECENT architecture specific compiler will be as
   good as or beat GCC.  

I'd like to see some actual data to verify this.  In my own experience
GCC optimizes very well across most architectures.  I have yet to see
a DOS compiler that would consistently beat GCC generated code. For
instance, DJGCC on msdos produces a PovRay raytracer that is very
similar in performace to Watcom compiled version. 

On MIPS-based decstation, gcc nowadays beats MIPS native compiler, and
the MIPS-people have written a lot of papers about optimization.

If you post/mail some sample program, I can test gcc against native
compilers on various unix boxes, (Sparc, Alpha, HP-PA, MIPS).

Harri
--
======================================================
Harri Pasanen           [email-masked]

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

From: [email-masked] (Hannu Savolainen)
Subject: Re: Doom Music + PAS-16
Date: Mon, 12 Sep 1994 05:52:08 GMT

[email-masked] (Christopher M. May) writes:

>Hi, Has anyone gotten the music to work in DOOM?

>I've seen 1 person post with a SB16 who said it worked.

>I thought doom was working perfectly, until I remembered there's
>music too :)

>My card passes the "fmtest" included in the sndkit.
>(After I load the general midi patches... is this necessary?)

>Also, do I have to compile in the MPU-401 support?
There is nothing wrong in your configuration. XDOOM just doesn't
play music.

Hannu
-- 
=============================
Hannu Savolainen
[email-masked]
"Don't use Windows since there is a door!"

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

From: "Derrick J. Brashear" <[email-masked]>
Crossposted-To: alt.filesystems.afs
Subject: Re: Developing Distributed Filesystems for Linux?
Date: Sun, 11 Sep 1994 23:34:34 -0400

Excerpts from netnews.alt.filesystems.afs: 11-Sep-94 Re: Developing
Distributed .. by John F [email-masked] 
> So ask, what is the target customer for your filesystem software?  Are you
> trying to link Linux users together, or trying to make Linux work better in
> an AFS environment?  If you are looking for a distributed filesystem without
> concern for compatibility, do you care about non-Linux systems?
I don't even have a Linux box. My machine is a SPARC 1; I was hoping for
some sort of free, and more importantly, general, client software.
However, I have access to Linux machines, and I'm not unwilling to work
on this sort of thing.

-D

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

Crossposted-To: alt.games.doom,comp.os.linux.help
From: [email-masked] (Patrick Reijnen)
Subject: Re: DOOM for Linux problem - help.
Date: Mon, 12 Sep 1994 06:33:10 GMT

In <[email-masked]> [email-masked] (Dane Jasper) writes:

>I am having a problem getting DOOM for Linux to run on one of my machines. 
>On the 486/66 machines at school, things work just fine.  It's very
>depressing not to be able to play DOOM at home!

>Here's what I get (system info follows):

># linuxxdoom 
>linuxxdoom: using incompatible library '/usr/X386/lib/libXt.so.3.0.1'
>        Desire minor version >= 1 and found 0
>linuxxdoom: using incompatible library '/usr/X386/lib/libX11.so.3.0.1'
>        Desire minor version >= 1 and found 0
>                          DOOM System Startup v1.666                          

Looks like you need to upgrade you X environment to 2.2.1. Your libs are to old for linuxxdoom.

[..stuff deleted ..]

>The system is a 486/66 with 28 megs of ram and linux 1.0.9.  X is version
>2.1, with the XF_SVGA server.  

>Does anyone have any ideas?  Is it the libs??

>Replies via email are appreciated - post as well if you think it would be of
>general interest.

>Dane

Patrick Reijnen

--
************************* Patrick Reijnen *************************
* Department of Computer Science, Catholic University of Nijmegen * 
* Email:  patrickr@{sci,cs}.kun.nl                                *
* WWW:    http://{atlas,zeus}.cs.kun.nl:4080/homepage.html        *

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

** 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.development) 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
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************