Subject: Linux-Development Digest #395
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Fri, 21 Jan 94 21:13:13 EST

Linux-Development Digest #395, Volume #1         Fri, 21 Jan 94 21:13:13 EST

Contents:
  ncurses 1.8 problem (Henning Holtschneider)
  Re: Transputer: that difficult? (Michael Haardt)
  Van Jacobson slow start (Re: Linux v1.0: what's in it?) (Harald T. Alvestrand)
  NIS Server NEED (Olivier MANGON)
  Re: nfs performance (Matthias Urlichs)
  Re: term111 (Steve Danz - SST)
  Re: Is there an _official_ directory structure for linux? (Peter Dalgaard SFE)
  Re: mac linux (James Hammett)
  Re: Transputer: that difficult? (Rob Savoye)
  Possible video bug 486VLB+Trident8900 (David Deppner)
  Re: Linux v1.0: what's in it? (Alan Cox)
  Re: Linux v1.0: what's in it? (Rob Janssen)
  Re: nfs performance (Alan Cox)

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

Crossposted-To: comp.os.linux.help
From: hh@hhdo.ping.de (Henning Holtschneider)
Subject: ncurses 1.8 problem
Date: Thu, 20 Jan 1994 17:12:24 GMT

Hi!

I have a serious probelem with ncurses 1.8. My little test program looks
like this:

        #include <ncurses.h>

        main ()
        {       
                initscr();
                mvprintw (0,22,"text1");
                refresh();
                mvprintw (0,23,"text2");
                refresh ();
                endwin ();
        }

When I run the program the output of 'mvprintw (0,22,"text1")' is put in the
right place but then the curser is positioned at the right bottom of the
screen (it is there after refresh () has been called) and when 'text2' is
printed, the screen is scrolled and the string is placed at the beginning of
the following line.

I have tried to move () the cursor before wprintw-ing  but that  didn't
help, either.

When I modify the program like this ...

        #include <ncurses.h>

        main ()
        {       
                initscr();
                mvprintw (0,22,"text1");
                mvprintw (0,23,"text2");
                refresh ();
                endwin ();
        }

... so that refresh () is called after all output is made, it works fine.
So, the problem seems to be in the refresh () routine?! Or could it be a
failure in my /etc/termcap or somewhere at /usr/lib/terminfo (I did never
have such problems before and with the "original" curses it works all fine)?

Is there anyone who can help me or who has the same problem?

Thank's

        <-gninneH<-
-- 
      Henning Holtschneider * Bauernkamp 41 * 44339 Dortmund * Germany
          Member of OASE - European Shareware Authors Organization
  Internet: hh@hhdo.ping.de  Fidonet: 2:2444/1099  Telefax: +49 231 7285296

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

From: Michael Haardt <(michael)u31b3hs@pool.informatik.rwth-aachen.de>
Crossposted-To: comp.sys.transputer
Subject: Re: Transputer: that difficult?
Date: Thu, 20 Jan 94 21:15:15 MET

anton@ulysses.demon.co.uk ("A.F.Hall") writes:
> Yup, I've got one of those CSA kits and the transputer driver (v0.4 I think)
> works perfectly well. You can also get an assembler/ disassembler which runs
> under Linux, though I'm still having problems with it i.e. the examples are
> looking for libraries which don't exist. I just wish there was a freely
> available C/C++/OCCAM compiler/cross compiler which ran under Linux.
> Actually I think some people are working on it - but is it for Linux? 
> Anyone know?

I am working on a new release of the assembler and linker, but I can't 
give a release date yet, because the bootstrapping phase of cross 
compiling will hopefully end soon.  I wrote an entirely new linker, 
which works much more efficient, e.g. a binary with 170k text segment
needs only 10 passes.  Only the documentation needs some more work ...

The library contains Minix code, that's why I can't release it.

Indeed I am working on a backend for lcc, although only for 32 bit
transputers right now, with fp requiring a t800.  But as I said, I can't
give a release date yet.  I will make announces to comp.sys.transputer
and other groups when a beta version is finished.

To come back to the subject: no, it is not that difficult.  :)

Michael
--
Twiggs and root are a wonderful tree (tm) Twiggs & root 1992 :-)

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

From: hta@uninett.no (Harald T. Alvestrand)
Subject: Van Jacobson slow start (Re: Linux v1.0: what's in it?)
Date: 21 Jan 1994 14:01:42 GMT

hedrick@geneva.rutgers.edu (Charles Hedrick) writes:

>Retransmission is now using a fairly simply slow start strategy.
>Jacobson has come up with more clever things, which the Hosts
>Requirements RFC says should be implemented.  However at the moment we
>don't need cleverness -- we need reliability.

Hrmmm....I would want to be careful here.
From what I overheard at one IETF, the interesting thing about the
slow-start that was implemented in the original TCP was that when all
hosts implemented this, and the network was overloaded, the network
would become unstable. With VJCC, the network will sooner or later settle
down to a state where someone gets something done.

Unfortunately, VJCC has the effect of slowing you down a little, so on
a congested link, someone not using VJCC will be able to crowd out someone
using VJCC - which some people may think is a feature.

That's why it is a *MUST*, not a *SHOULD* - and I think it should
be fairly high up on the list of things that Linux networking should adhere to.

Unfortunately, the only reference seems to be:

[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
     August 1988.

I don't know if this is online.
-- 
                   Harald Tveit Alvestrand
                Harald.T.Alvestrand@uninett.no
      G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
                      +47 73 59 70 94
My son's name is Torbjxrn. The letter between "j" and "r" is o with a slash.

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

From: mangon@gla.ecoledoc.ibp.fr (Olivier MANGON)
Crossposted-To: comp.os.linux.help
Subject: NIS Server NEED
Date: 21 Jan 1994 08:12:55 GMT
Reply-To: mangon@gla.ecoledoc.ibp.fr

Hi ,

I need to find a NIS server for linux (yp*), so if anyone can tell me where i can get one Please Email Directly...

Thanks A lot...                         Olivier.
PS:NYS alpha version is only a library i need the full packages.




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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: nfs performance
Date: 21 Jan 1994 11:10:15 +0100

In comp.os.linux.development, article <2gmqcm$53f@trondviggo.nvg.unit.no>,
  venaas@trondviggo.nvg.unit.no (Stig Venaas) writes:
> 
> In Ultrix one has daemons (biod) that help the nfs daemons by doing
> read-ahead and write-behind buffering. One can also run multiple nfs daemons
> at the same time. Is that possible with Linux?
> 
Running multiple daemons should be possible. You can't start more than one, 
but inserting a few fork() calls in nfsd should work.

Linux doesn't have a biod yet. As usual, it's just that nobody with the 
required experience has yet needed the added performance badly enough to 
write the necessary kernel code. ;-)

-- 
Boys will be boys, and so will a lot of middle-aged men.
                                -- Kin Hubbard
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: danz@tidbits (Steve Danz - SST)
Subject: Re: term111
Date: Fri, 21 Jan 1994 08:22:13 GMT

cajho@uno.edu wrote:
: In article <2h7m0v$3bi@mojo.eng.umd.edu>, dskim@eng.umd.edu (Daeshik Kim) writes:
: >
: >     It was rather refreshing shock!
: >
: >filter:~ >tupload -uv ALPHA-pl14p.tar.gz 
: >sending ALPHA-pl14p.tar.gz
: >        sent file removed.
: >        1185209 bytes sent in 543 seconds, cps = 2182.71
: >
: >     Even with 3 other active 'trsh'..
: >
: >     It was big improvement since last release...so I could not stand
: >     to post this..

: That's funny, because I found that I slowed down from 1.0.8 to 1.1.1..using
: a ZyX 14.4 from PC to Sun.  At least that is what term is reporting.  I
: was getting just over 1600 average on tuploads w/1.0.8 and now 1.1.1 reports
: mid 1500's, w/all other things equal.  In fact my estimate for 1.0.8
: tupload speed may have been conservative...Needless to say, I'm back 
: w/1.0.8.  Anyone else notice this?
:   

I have noticed a slowing in 1.11 also, but I thought it may be my config.
When running a 9600baud connection between a Sun and a PC 1.11 is running 
around 1200-1300 while 1.08 was 1500+ with the same termrc.


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

From: pd@kubism.ku.dk (Peter Dalgaard SFE)
Subject: Re: Is there an _official_ directory structure for linux?
Date: Fri, 21 Jan 1994 15:15:08 GMT

In <QUINLAN.94Jan19024352@spectrum.cs.bucknell.edu> quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) writes:

>J. Mark Noworolski <jmn@crown.EECS.Berkeley.EDU> writes:
[snip]
>> Where _should_ all these files be?
>>
>> I recall reading somewhere that there is some sort of recommended
>> standard floating around somewhere.

>Yes, there is.

[snip]
>> thanks,
>> mark
>> PS. I want to know this because I am about to try porting latex to linux
>> (the one distributed with slackware is apparently broken since it doesn't
>> include slitex and also needs a setenv TEXINPUTS command to work).

>I encourage any developer who is interested in knowing more about the
>filesystem structure standard (by no means is it official) that we are
>working on to contact me.  I ask anyone else to wait since we are
>going to release our work soon -- there are probably going to be some
>more changes before we release it.  Thanks.

And regarding the original problem: Unless you really feel
bad about a slight amount of mess in your file system, there's
no need to recompile: just make a symbolic link from whereever
the TeX library actually is to where TeX expects it to be
(probably /usr/TeX/lib or some such). Slitex is a format and
can be made without recompilation. Once you've got hold of
Timothy van Zandts seminar.sty, you won't want it anyway.
--
   O_   ---- Peter Dalgaard
  c/ /'  --- Statistical Research Unit
 ( ) \( ) -- University of Copenhagen
~~~~~~~~~~ - (pd@kubism.ku.dk)

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

From: James Hammett <jamesh@apple.com>
Subject: Re: mac linux
Date: Fri, 21 Jan 1994 16:07:23 GMT

In article <59795@sdcc12.ucsd.edu> CSE 230, cse230c@cs.ucsd.edu writes:
> If you want to run linux, get a PC.  The mac is died because
> it will never be able to run linux as well as the PC can.  Mac
> is losing the battle;  the support for Mac is just next to
> none (in terms of things like linux).  Too bad the PC is
> finally defeating other machines like the amiga, atari and
> mac.

Currently an Alpha Version of NetBSD is out for the macintosh, and they
are working on getting a beta out soon.  

Brad Pickering <sp> has ported MiNT (an Atari type unix) (MiNT I Not TOS).
GCC and some other utilities are currently available for it. 

I beleive that MacBSD actually takes over the computer, while MiNT just
runs as an application.

_______________________________________________________________________
______
  I in no way   |              James Hammett                 | I don't
know
 represent the  |           Apple Computer Inc               | what they
are 
 view of Apple  |>>>>>>>>>>>>>>and vice versa<<<<<<<<<<<<<<<<|
think/planning

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

Crossposted-To: comp.sys.transputer
From: rob@Cygnus.COM (Rob Savoye)
Subject: Re: Transputer: that difficult?
Date: Fri, 21 Jan 1994 15:42:06 GMT

Michael Haardt <(michael)u31b3hs@pool.informatik.rwth-aachen.de> writes:

>anton@ulysses.demon.co.uk ("A.F.Hall") writes:
>> available C/C++/OCCAM compiler/cross compiler which ran under Linux.
>> Actually I think some people are working on it - but is it for Linux? 

 The only semi-free C/OCCAM compiler is part of tannebaum's Amsterdamn
comiler kit. I think UnisPress in New jersey sells it. Personally, as
someone with years of transputer experience, I find OCCAM sucks. At one
time there were several "free" OCCAM like libraries for C that let you
start light-weight threads and stuff. I might have a copy on tape somewhere...

>Indeed I am working on a backend for lcc, although only for 32 bit
>transputers right now, with fp requiring a t800.  But as I said, I can't

  There are two GCC ports for the transputer that I know of, neither one is
any good. They're also based on old vesions of GCC, so updating them would be 
painful. 

  When I was doing transputer development I used a Unix machine as the 
development platform, I see no reason why Linux couldn't be used. 

        - rob -
--
Cygnus Support         << KERNEL: Panic, core dumped >>             Headquarters
PO Box 1548                  Darkstar crashes,               1937 Landings Drive
Nederland, CO 80466     pouring its light into ashes,    Mountain View, CA 94043
+1 (303) 258-0506            reason tatters, ...               +1 (415) 903-1400

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

From: dsd@netcom.com (David Deppner)
Subject: Possible video bug 486VLB+Trident8900
Date: Thu, 20 Jan 1994 08:44:19 GMT

I just got a new 486DX-40 VLB with a Contaq chipset.  When I installed it
in my previously working system I found that when switching between VCs and
when in X, characters (or pixels in X) would get mixed up between the two
VCs I was switching.  Not good.  I took out the Trident card and put in
an Ahead and an Oak card and both worked fine.

Go figure...

I'd imagine that this was caused by some subtlety of the inner workings of
the kernel, perhaps in its interaction with the bus, but I'm not sure.  

--
David Deppner     dsd@netcom.com  Psyborg@MOOs
Linux forever...  PGP forever...  Apple ][ infinitum!
Down with uSoft and all world govs!


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

From: iiitac@swan.pyr (Alan Cox)
Subject: Re: Linux v1.0: what's in it?
Date: Fri, 21 Jan 1994 16:37:34 GMT

In article <1994Jan20.131736.6031@inex.com> carlb@inex.com (Carl Boernecke) writes:
>I must say that I'm glad Linus and folks are doing the freeze on
>the code.  This will give it a chance to settle-down, thus giving
>us a uniform place to base all future development on.  Only big
>thing that holds me back from fully endorsing 1.0 is the network
>code; how is it holding up?  I know my 0.99pl14o stuff with both
>PPP and SLIP runs better than any previous release, but it does
>ocasionally 'hang.'  I'm not sure if it's due to the machines I
>have that run NOS (KA9Q), or my Linux boxes, though I would assume
>that it's the latter.

Pl14t has a collection of major TCP write side fixes contributed by
people. It would have more for closing down too but time runs out
before I can get them all in....

PPP won't be in 1.0 because the developers choose to class it as ALPHA.
It's awfully stable for alpha test software 8-). Bear in mind most of the
distributors add some of the alpha/beta pieces either directly (grrr!) or
as patch kits in /usr/src (which I much prefer). So I'd expect PPP to 
at least be on the CD-ROM distributions even if it has WARNING ALPHA TEST
stamped all over it. 

What I'm looking forward to then is the finished version of SLS everything
as loadable modules....

>So, is the networking code stable, or not?  Will we ('we' being
>the thousands of loyal Linux users) finally be able to compare our
>systems to those that run NetBSD or FreeBSD?  Their only real
It's better than it was. The BSD bods have had 15 years to get their
code stable in various environments, which helps no end. if it annoys
you ask them about DOS emulation, choice of network cards, and things.
It's all a bit pointless this comparing lark. If it does what you want
use it. 

>bragging point has been the networking code.  Will this realase
>effectively remove that point from the 'my system is better than
>your system' discussions?  I don't really care, though, just 
>curious.
Why go down to their level ?

Alan
iiitac@pyr.swan.ac.uk


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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Linux v1.0: what's in it?
Date: Thu, 20 Jan 1994 22:41:12 GMT
Reply-To: pe1chl@rabo.nl

In <1994Jan20.131736.6031@inex.com> carlb@inex.com (Carl Boernecke) writes:

>I must say that I'm glad Linus and folks are doing the freeze on
>the code.  This will give it a chance to settle-down, thus giving
>us a uniform place to base all future development on.  Only big
>thing that holds me back from fully endorsing 1.0 is the network
>code; how is it holding up?  I know my 0.99pl14o stuff with both
>PPP and SLIP runs better than any previous release, but it does
>ocasionally 'hang.'  I'm not sure if it's due to the machines I
>have that run NOS (KA9Q), or my Linux boxes, though I would assume
>that it's the latter.

>So, is the networking code stable, or not?  Will we ('we' being
>the thousands of loyal Linux users) finally be able to compare our
>systems to those that run NetBSD or FreeBSD?  Their only real
>bragging point has been the networking code.  Will this realase
>effectively remove that point from the 'my system is better than
>your system' discussions?  I don't really care, though, just 
>curious.

The networking code still is not 'as good as' that in BSD.  Unfortunately,
there are only a few knowledgable people working on it, and even in
this small group there are differences in opinion on what is the right
way to solve problems (and to treat fellow developers)

I have carefully avoided to get involved in this project, although I
have some experience with this topic.  It must be coincidence that the
inter-person relations and the number of different releases of the KA9Q
code show similarities to what is happening with Linux networking, and
one such experience was enough for me...

>Finally, Linus said the freeze would happen when pl15 was released,
>but I didn't see a date.  Did I just miss it, or was it not mentioned?

Originally the mentioned date was dec 31 for the freeze.  But in reality
there are still patches being made, so 1.0 will probably slip a bit.
Many of the recent patches are to the networking code, so hopefully it
will be a little better when pl15 (1.0) is released...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: iiitac@swan.pyr (Alan Cox)
Subject: Re: nfs performance
Date: Fri, 21 Jan 1994 17:23:49 GMT


Sounds like we need an NFS FAQ

Lets try a first draft - maybe this can be hacked onto a net howto or something

Q1.     Files get corrupted when using NFS over wider area networks or SLIP

Certain vendors (Sun primarily) shipped many machines running NFS without
UDP checksums. Great on ethernet, suicide otherwise. UDP checksums can be
enabled on most file servers. Linux has it enabled by default from pl13
onwards - but both ends need to have it enabled...

Q2.     My NFS files are all read only

The Linux NFS server defaults to read only. RTFM the 'exports' and nfsd
manual pages. With non Linux servers you may also need to alter /etc/exports

Q3.     I mount from a linux nfs server and while ls works I can't read or
write files.

You must mount a Linux filestore with rsize=1024,wsize=1024 (or 2048 if
you really want - 1024 is a better choice).

Q4.     I mount from a linux nfs server with a blocksize of between 3500-4000
and it crashes the Linux box regularly

I know good isn't it [NOT]. Basically don't do it then. (see Q3).

Q5.     Can Linux do NFS over TCP

No. If someone wanted to spend the time and update the rpc code to add rpc
stream record marking it should work then.

Q6.     I get loads of strange errors trying to mount a machine from a Linux
box. 

Make sure your users are in 8 groups or less. Older servers require this.

Q7.     Linux NFS clients are very slow when writing to Sun & BSD systems

NFS writes are normally synchronous (you can disable this if you don't
mind risking losing data). Worse still BSD derived kernels tend to be
unable to work in small blocks. Thus when you write 4K of data from a Linux
box in the 1K packets it uses BSD does this

        read 4K page
        alter 1K
        write 4K back to physical disk
        read 4K page
        alter 1K
        write 4K page back to physical disk
        
        etc..
        
Better systems don't have this problem. The Linux client is however
quite slow anyway.


Q8.     I've heard NFS is not secure is this true

Yes, totally. Running NFS in an uncontrolled environment is rather like
leaving your front door open, painting 'On holiday' on your house and posting
maps to every known criminal...
In a fairly secure environment or when you can recover data from stupid
misuse its pretty much OK. The worst someone can easily do is alter all the
files on an NFS mounted disk and/or crash the machine. So long as you don't
mount your system files writable you should be vaguely safe

Q9.     I occasionally mount from lots of different places do I have to set
the all mounted each boot.

No you can use the automounter to mount disks as you access them.

Q10.    How do I stop things hanging when a server goes down

There are three main NFS behaviours

soft:   Your NFS client will report an error to the process concerned if an
        NFS server doesn't answer after a few retries. Most software handles
        this well - but not all.
        
hard:   Your NFS client will try forever unless killed off. Operations will be
        restarted when the NFS server recovers or reboots.
        
hard,intr:
        As hard but ^C will also stop the NFS retrying. In a few cases - notably
        nfs mounted /usr/spool/mail disks this doesn't help as the shell will
        be ignoring ^C when it checks you have mail...
        


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


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

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

    Internet: Linux-Development@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-Development Digest
******************************
