Subject: Linux-Development Digest #139
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 8 Sep 94 13:13:14 EDT

Linux-Development Digest #139, Volume #2          Thu, 8 Sep 94 13:13:14 EDT

Contents:
  Re: Novell routing between IPX/TCPIP? (Mark Evans)
  Re: News Spool File System - new filesystem type?? (Bill Davidsen)
  Re: News Spool File System - new filesystem type?? (Bill Davidsen)
  Re: Alpha Linux (Anton Ertl)
  Re: Serial port problems (Joerg Wedeck)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Martien Hulsen)
  Re: Multiprocessing Pentium Systems (Alan Cox)
  Re: Alpha Linux (Steven A. Reisman)
  Re: A thought to improve security (Alan Cox)
  Re: Threads for Linux (Rene Angel Sepulveda)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Highlander)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Michel Anders)

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

From: [email-masked] (Mark Evans)
Subject: Re: Novell routing between IPX/TCPIP?
Date: Thu, 8 Sep 1994 09:04:48 GMT

Rob Janssen ([email-masked]) wrote:
: In <[email-masked]> [email-masked] (Bob Kaehms) writes:

: >(the way tin's acting, I may have asked this a while back, but since
: >I didn't hear any replies....)

: >Does anyone have any ideas on how I could turn Linux into a router for
: >both TCPIP and IPX?  what would it take to get IPX routing available on
: >Linux? Buy-in from Novell?  Anyone familar enough with IPX to know whether
: >or not this is doable without Novell?

: IPX routing is fully documented by Novell.  Much of it is already
: in Linux.

One warning do not set an ethernet driver to promiscuious mode unless you have
the following patch applied, when you are using IPX.

--- /usr/src/linux/net/inet/ipx.c.old   Mon Sep  5 11:14:52 1994
+++ /usr/src/linux/net/inet/ipx.c       Mon Sep  5 15:01:08 1994
@@ -856,7 +861,7 @@
                int free_it=0;
                
                /* Rule: Don't forward packets that have exceeded the hop limit. This is fixed at 16 in IPX */
-               if(ipx->ipx_tctrl==16)
+               if((ipx->ipx_tctrl==16)||(dev->flags&IFF_PROMISC))
                {
                        kfree_skb(skb,FREE_READ);
                        return(0);

Otherwise you will flood the network with IPX packets, and most likely have your netware server consoles 
filled with error messages.

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

From: [email-masked] (Bill Davidsen)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 8 Sep 1994 13:19:29 GMT

In article <ianm.778965597@miles>, Ian McCloghrie <[email-masked]> wrote:

:The Right Way to implement this kind of filesystem would be a
:user-space process, reading and writing the raw device -- essentially
:just using /dev/hd<foo> as a database.  Putting it in the kernel gains
:you nothing but more kernel bloat.

I hate to disagree, but doing it through the kernel gains you portability.
If you read the last post about why newsrun doesn't kick off automatically,
you know that authors of news systems have real problems there.

For what it's worth, I did a BBS which kept it's own message base instead
of using one file per message. It worked REALLY well, and I'm rewriting it
as client server now to solve some locking overhead when multiple processes
do certain operations.

I have thought of writing a complete news system using this method, which
would restrict reading to NNTP, since the file structure would be all
diferent. Not a loss, I think. I'm still looking for a fast algorithm to
find N consecutive bits ON in a bitmap...
-- 
Bill Davidsen, [email-masked] on weekends.
        "Speaking *from* but not *for* Prodigy"

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

From: [email-masked] (Bill Davidsen)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 8 Sep 1994 13:25:55 GMT

In article <[email-masked]>,
Rob Robertson <[email-masked]> wrote:

:I don't think this would work, as so many words in usenet postings are
:misspelled that looking them up in a dictionary, probably won't buy
:you anything, cuz they won't be found!

An interesting fact is that people tend to quote other articles in their
own postings. When I was hacking TMNN I set up a feed which threaded the 
articles to be sent on References: headers, and created the compressed
UUCP batches in order rather than the date order in which I received
them.

Now the reason for all of this was that I was feeding out over a 2400
baud modem. By sorting I was able to get up to 30% reduction in the
size of the compressed batch. I have no reason to expect less than 20% for
text articles (but not binaries).

The short answer is "yes, compression works, compression with ordering
works really well."
-- 
Bill Davidsen, [email-masked] on weekends.
        "Speaking *from* but not *for* Prodigy"

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

From: [email-masked] (Anton Ertl)
Subject: Re: Alpha Linux
Date: 8 Sep 1994 13:31:11 GMT

In article <[email-masked]>, [email-masked] (Peter Holzer) writes:
|> [email-masked] (Anton Ertl) writes:
|> 
|> >In article <[email-masked]>, [email-masked] (Douglas Ambrisko) writes:
|> >|> The biggest task with the
|> >|> Alpha is making everything 64 bit clean and this will apply to the EISA
|> >|> drivers.
|> 
|> >Only if Linux on the Alpha will be a 64-bit-OS. 
|> 
|> I sure hope it will be. Who wants a 32 bit OS on an Alpha?

The VMS guys. And I prefer a true 32-bit OS to a half-hearted 64-bit
OS, where one of the main data types of the main language is 32 bits:
Mark my words: As soon as people will be using really more tha 4G in
one app, they will complain about 32-bit ints as they do about 8086
segments now.

|> >If it will be, I hope
|> >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
|> 
|> Then you have to drop either the 16 bit or the 32 bit int type.

No. Just add an int32_t.

|> Both
|> options may make some people unhappy. The 32 bit int is a reasonable
|> compromise. It also breaks all those programs which assume that a
|> pointer and an int are just the same thing, which is a good thing IMHO.

Why is this a good thing? And is it also a good thing that programs
break that assume that an index into an array or the difference
between to pointers fits into an int?

And if you say, that such things can be easily fixed by greping for
"int" and replacing it with "TrueInt", you are wrong. In C int is not
just another type, it affects many things in the language: Normal
integer constants have the int type, int plays a special role in
conversion rules, switch wants an int argument, etc.

I have debugged enough programs (one:-) that worked perfectly well on
decent OSs on an Atari ST to know why I dislike
sizeof(int)!=sizeof(void *). Just writing "3" instead of "3L" cost at
least 5 hours of debugging time of two people (one of them an
experienced Atari user).

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
[email-masked] Most things have to be believed to be seen

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

From: [email-masked] (Joerg Wedeck)
Subject: Re: Serial port problems
Date: 7 Sep 1994 19:42:38 GMT

Rob Janssen ([email-masked]) wrote:
: In <[email-masked]> [email-masked] (Joerg Wedeck) writes:

: >as the subject says i am having problems with the serial port with
: >ALL linux kernels, when switching to speeds higher than 19200 baud.
: >from 38400 baud on onward i have to experience data losses.

: >the manual says there are 2 NS16C552 compatible UARTs which support
: >FIFO. Are these UARTs incompatible to the serial driver provided by
: >linux ?

: I use a card with three of these, and one of my ports runs at 76800 bps
: to my modem.  flowcontrol works perfectly.

ok, I further investigated the problem. running kermit or minicom outside
X really runs fine at rates >= 38400 baud. But running from X windows
results in data loss (linux 1.0.9 and 1.1 until pl 49). any ideas ?

Joerg

--
==================================+======================================
Joerg Wedeck                      | E-Mail: [email-masked]\
Universitaet Tuebingen            |             .uni-tuebingen.de
Lehrstuhl fuer Techn. Informatik  |
Sand 13                           |
72076 Tuebingen                   |
Germany                           |
==================================+======================================
       Deswegen bin ich ja Optio, und Du nur Legionaer :-)
=========================================================================
Public Key for using PGP:

========================================================================+

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

Crossposted-To: comp.lang.fortran
From: [email-masked] (Martien Hulsen)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Thu, 8 Sep 1994 13:34:02 GMT

Michel Anders ([email-masked]) wrote:

> >4. Is there interest in accompanying GUI/non-GUI debuggers and
> >   performance analysis tools?

> again, GDB satisfies my needs quite nicely (programming wise :-))

Not for f2c though :-(. Hope that g77 will resolve this.

Martien

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

From: [email-masked] (Alan Cox)
Subject: Re: Multiprocessing Pentium Systems
Date: Thu, 8 Sep 1994 14:27:49 GMT

In article <[email-masked]> [email-masked] (Rich Deighton) writes:
>It has to be said that Linux is a very good OS, but there is little need to
>flame something just because it comes from Microsoft. Be open minded about
>such things :-)

I think the phrase is 'Bits of NT are pretty neat'. I certainly reckon you
could run Linux as an NT subsystem instead of the psuedo posix bit.

Alan

-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

From: [email-masked] (Steven A. Reisman)
Subject: Re: Alpha Linux
Date: Thu, 8 Sep 1994 00:49:24 GMT

Albert D. Cahalan ([email-masked]) wrote:

: Why drop one? 
: 16 bits = short int
: 32 bits = int
: 64 bits = long

 128 bits = long long   :)

-- 
Steven A. Reisman
12695 4th St. S.                                  [email-masked]      
Afton, MN  55001                                      (612) 436-7125

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

From: [email-masked] (Alan Cox)
Subject: Re: A thought to improve security
Date: Thu, 8 Sep 1994 11:20:23 GMT

In article <[email-masked]> [email-masked] (J.A.vanderMost) writes:
>Some programs in a Unix system have to be SUID root to do the things they do.
>Like /bin/passwd /bin/login /usr/bin/lp /user/bin/at etc.. are all SUID root.

You can implement a non suid lpr set with thought, and a non setuid root one
quite easily.

>But being root is MUCH to powerful for these programs, they don't need all
>the abilities of root, only a very small portion of it. And that's exactly

passwd/login are bad examples. They need to be/can be root because after all
if you can break them you can probably break the whole system anyway.

>Let's say lpr has a security bug in it, it allows a normal user that knows 
>witch options, etc. to use, to modify a file that this user couldn't normally
>modify. This is a very harmful bug, because this user can easily become root!

With some older lpr's you could 8)

>Let's modify the kernel a bit, and redefine the meaning of the UIDs below 256:
>UID 0 is root ( like it always was, many programs depend on this )
>UID >256 are normal users, without a special meaning.
>UID 1-255 are not what they used to be, they have a special meaning :

It now doesn't work anything like proper Unix. The problem isn't one of
kernel facilities its more one of sloppy code. To fix it properly requires
a lot of thought and care whatever system you choose to use. I've run one
Unix machine with no user accessible setuid binaries. Indeed all the user
visible filestore was nosuid. A small true root partition with the user
space chroot()ed under it held the only setuid binaries. All these talked
via named pipes and an encyrption key system to/from the user clients
with agreed minimalist protocol options including the fact that all files
were passed down the pipe and never opened by the priviledged server.

It's a case of discipline and planning not quick hacks.

Alan

-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

From: [email-masked] (Rene Angel Sepulveda)
Subject: Re: Threads for Linux
Date: 7 Sep 1994 18:20:18 -0400

Nicolas Droux ([email-masked]) wrote:
: Hi there,

  Hi
  
: I need to be able to create threads, or lightweight processes, under  
: Linux. Is there a good solution to this problem ? Is this feature  
: integrated in a recent release of the kernel, is it planned, or is it  
: possible to do this by means of a 3rd party package ?

You can use the pthread library.

this library is port to Linux-1.0

it's the FAQ

============= cut here ================

                  Answers to frequently asked questions
                  for my implementation of POSIX threads

Question: What are pthreads?
Answer:   Pthreads stands for POSIX threads. Currently their is NO
          POSIX thread standard, just drafts. The last draft circulated
          was draft 8, in October 1993. I expect that it won't be
          approved and another draft will be circulated soon.

Question: I've read somewhere that the calling arguments for the
          pthread function FOO() was BAR but your implemnentation
          is BAZ. Which is right?
Answer:   If I've implemented the function foo() then my implementation
          is probably correct according to the current draft of pthreads.
          I've tried to keep my implementation as up to date as possible.
          The discrepency you are seeing is probably because you've
          seen the OSF/DCE implementation of threads which was based
          on draft 4 of the POSIX thread standard, and there has been
          significant changes to the interfaces since then.
          There is one discrepency to this see below.

Question: What about pthread_detach()
Answer:   The latest draft has completely removed this function from the
          standard. I've considered this very a rather bad move on their
          part and have kept pthread_detach(). It is based on the last
          draft to contain the pthread_detach() function (draft 7).

Question: Where do I get the latest draft of pthreads? 
Answer:   You can try IEEE which is the organization which POSIX belongs.
          I have found them to be completely unhelpful for my needs and
          have had to go out and beg for my own copy. Usually they
          release the previous draft just in time for the next draft to
          go up for balloting.

Question: Where can I get this implementation?
Answer:   You can try sipb.mit.edu:/pub/pthreads or
          toxicwaste:/pub/archive/pthreads

Question: Where can I get documentation?
Answer:   I haven't written man pages yet, and I only have some of the
          functions available online. You can find them under my home page.
          HTTP://www.mit.edu:8001/people/proven/home_page.html

========================== cut here =====================================

regards,
-- 
 Rene Angel Sepulveda           e-mail: [email-masked]       
Ing. Civil Informatica          http://www.inf.utfsm.cl/~rene/
UTFSM, Valpariso. CHILE    "Que vana es la gracia y falsa la belleza" (hamlet)

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

From: [email-masked] (Highlander)
Crossposted-To: comp.lang.fortran
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: 8 Sep 1994 11:49:43 GMT

In article <[email-masked]>, Larry Meadows <[email-masked]> wrote:
>Hello
>
>Given the interest in Linux, I thought I'd post a short survey:
>
>1. Are people interested in a commercial compiler suite for Linux on
>   Intel Architecture platforms? The suite would include true compilers
>   for extended Fortran 77, ANSI C, Draft-ANSI C++ with extensions, and
>   High Performance Fortran. C, f77, and C++ could support shared memory
>   parallelism (thread-based) if system support is available in Linux.
>   HPF would support socket-based communications on networked systems,
>   and could support custom interconnects.

F77 and HPF would be nice.  ANSI C and draft-ANSI C++ are kind of pointless
unless you really want to try competing with gcc/g++, since in theory anybody
who wanted to could add thread-based parallelism to them.  Yeah, it'd be
a pain in the butt to do

>2. How much would people pay for such a product [ loaded question ]?

Speaking only for myself, I'd pay for a compiler.  Iff the price isn't
ridiculous.  I'm not going to pay thousands of dollars for a FORTRAN
compiler when I can use f2c and gcc for free with source code, but I would
be willing to pay on the order of a couple hundred dollars for a parallelizing
FORTRAN compiler that's (for instance) PVM-aware.  I'd say $500 max, but then
I'm a poor college student and I've been kicking around the idea of writing
my own compiler (although not terribly seriously).

>3. What distribution media would be required?

Probably floppy and/or ftp.  Not too many Linux users I know have tape
drives.  CD-ROM might be doable as well (and would give me an excuse to
finally buy a CD-ROM drive for something other than games).

>4. Is there interest in accompanying GUI/non-GUI debuggers and
>   performance analysis tools?

Definitely, if they actually work.  Trying to figure out gdb is a pain,
especially since it's not FORTRAN-aware yet.  I've taken to using Ups,
but it has its own set of problems.

I guess a larger question is, how many people are doing serious numerical
work with FORTRAN on Linux?  I've done some, but it's difficult for two
reasons: 1.)  no native FORTRAN compiler, and 2.)  i[345]86 floating point
performance sucks big fuzzy Volkswagens through a straw.  Anybody tried
running something really perverse like the NAS Parallel Benchmarks on a
Linux box? (11 seconds on a Cray Y-MP, 22 hours on a VAX 785 :)

Just my $0.02

        --Troy
+--------------------+------------------------------------------------+
|   Troy A. Baer     | "My soul is painted like wings of butterflies, |
| Senior, Aero. Engr.|  Fairy tales of yesterday, grow but never die, |
| DOS?!? Try Linux!! |  I can fly, my friends!"  --Brian May          |
+--------------------+------------------------------------------------+

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

Crossposted-To: comp.lang.fortran
From: [email-masked] (Michel Anders)
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: Thu, 8 Sep 1994 11:28:47 GMT

In <[email-masked]> [email-masked] (Larry Meadows) writes:

>Hello

>Given the interest in Linux, I thought I'd post a short survey:

>1. Are people interested in a commercial compiler suite for Linux on
>   Intel Architecture platforms? The suite would include true compilers
>   for extended Fortran 77, ANSI C, Draft-ANSI C++ with extensions, and
>   High Performance Fortran. C, f77, and C++ could support shared memory
>   parallelism (thread-based) if system support is available in Linux.
>   HPF would support socket-based communications on networked systems,
>   and could support custom interconnects.

GCC/G++ (and f2c) are excellent compilers and free..., and since i'm not
writing any *commercial* software these suffice.

>4. Is there interest in accompanying GUI/non-GUI debuggers and
>   performance analysis tools?

again, GDB satisfies my needs quite nicely (programming wise :-))

For non-commercial programmers like me, i fail to see how a commercial
compiler could surpass the available GNU software. It would be interesting
to see, though, how many commercial developers are interested in the Linux
platform and what kind of products the consider to offer.

Michel.

/*-------------------------------------------------------------------------*/
/* Michel J. Anders         Dept. Experimental Solid State Physics 3       */
/* [email-masked]       University of Nijmegen                         */
/* +31 80 653434            Toernooiveld 1, Nijmegen                       */
/*-------------------------------------------------------------------------*/

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

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