Subject: Linux-Development Digest #301
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 13 Oct 94 11:13:18 EDT

Linux-Development Digest #301, Volume #2         Thu, 13 Oct 94 11:13:18 EDT

Contents:
  Re: Linux For Mac (Hillel Y. Sims)
  Re: FTP slowdown under 1.1.52 with hdparm on (Mark Lord)
  Re: FTP slowdown under 1.1.52 with hdparm on (Mark Lord)
  Re: A badly missed feature in gcc (Jeff Kesselman)
  Re: Kernel 1.1.53 - no BOOM (David Kastrup)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Rob Janssen)
  Re: Xircom PCMCIA ethernet support? (Vir Lagua)
  Re: A badly missed feature in gcc (Bruce Thompson)
  Re: Improving SLIP latency under Linux (Andrew R. Tefft)
  Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE (Bart Kindt)
  Re: Serious Bug In The Networking Code (Bart Kindt)
  Need more than 32 mount's (Holger Kausch US/ESC 60/3/135 #3630)
  Re: insmod drv_hello.o gives "___moddi3 undefined" (Michael Krause)
  Re: A badly missed feature in gcc (Jeff Kesselman)
  Re: Unable to find XF86-3.1-lib.tar.gz with correct sum. (Pierre Belanger)
  Re: A badly missed feature in gcc (Jeff Kesselman)
  Re: A badly missed feature in gcc (Jeff Kesselman)

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

From: [email-masked] (Hillel Y. Sims)
Subject: Re: Linux For Mac
Date: 13 Oct 1994 05:34:35 GMT

Well, just to throw my two cents into this thread...
I just purchased a PowerMac 7100/66 for my brother this last weekend, and boy
was that thing fast, and _that_ was while running at least 3/4 of its software
emulated from 68k code

I would LOVE to have an asskicking os like linux running on this thing, rather
than system 7, especially now that i have to pay for updates to the os (i love
macs look-and-feel of software, but i've grown to loathe the actual os itself
over the last year or so, since my exposure to linux :-)

so here's hoping the guys working on the port can get as much info as needed
and that apple opens up and gives them what they need to know!
-- 
Hillel Sims  -----  [email-masked]  -----  Rensselaer Polytechnic Institute
                             Howard Stern for Pope!
"Is rot13 rotated 13 forward or backward?"
        --Anonymous

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

From: [email-masked] (Mark Lord)
Subject: Re: FTP slowdown under 1.1.52 with hdparm on
Date: 13 Oct 1994 03:30:50 GMT

In article <[email-masked]> [email-masked] writes:
<Hello,
<
<   Not that I am complaining or anything. I just wanted to state that
<I had a drop in transfer rate on my FTP transfers while using hdparm.
<I am using 1.1.52 and running a SLIP line on a 14.4 modem. Normally I
<get about 1.4 K/sec. But while running it with hdparm -m 32 the
<ftp transfer stopped for a few seconds after each disk write. After
<I set the hdparm -m0 then the ftp ran fine again. Any explainations?

Sure.  Your serial port probably does not have a 16550A uart, right?

By default, the linux hard disk driver performs much of it's I/O with
all other interrupts masked.  When you use -m32, it is performing up to
32 times as much I/O per interrupt, with interrupts masked correspondingly
longer.  Odds are good that during this I/O, your serial port is dropping
characters, causing FTP to timeout and retry.

To negate this effect, the -u1 (hdparm) option can be used, though on 
some systems this causes trouble.  Backup first!
-- 
[email-masked]    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: [email-masked] (Mark Lord)
Subject: Re: FTP slowdown under 1.1.52 with hdparm on
Date: 13 Oct 1994 03:35:04 GMT

In article <[email-masked]> [email-masked] writes:
<
<I am not sure that hdparm is as good as it claims to be. 

Hmmm. I don't believe it claims to be good in all cases at all.
Better re-read the man page, paying particular attention to the paragraphs
for the -m setting, which state (among other things):

              On  many  systems,  it also provides increased data
              throughput  of  anywhere  from  5%  to  50%.   Some
              drives,   however (most   noteably  the  WD  Caviar
              series), seem to  run  slower  with  multiple  mode
              enabled.  Your mileage may vary.

<I was fooling around with it, and my results were not encouraging.

See last line above.

<I tried setting my multcount to 16, which is the max value for my disk
<according the the kernel at bootup.  I also tried 2, 4, and 8.  My
<benchmark was the suggested "dd if=/dev/hda of=/dev/null count=32768
<bs=1024".  When the multcount was set to anything but 0, system and
<user time went down, but wall-clock time went up.  This was under
<kernels 1.1.51 and 1.1.52.

Use the built-in -t option for more consistent timings.
As noted in the man page, some drives are slower with multiple-mode
enabled, and many are faster.  Looks like yours are slower.
-- 
[email-masked]    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: A badly missed feature in gcc
Date: Thu, 13 Oct 1994 04:55:54 GMT

In article <[email-masked]>,
H. Peter Anvin <[email-masked]> wrote:
>Followup to:  <[email-masked]>
>By author:    [email-masked] (Dan Pop)
>In newsgroup: comp.os.linux.development
>> 
>> The C compilers on AIX, Solaris, SunOS, IRIX, HPUX and Domain/OS don't
>> support it. If they would, they wouldn't be C compilers anymore.
>> 
>
>Most can be coaxed into doing so (IRIX: -acpp -Wp,-B).  However, I
>notice all the ones above are UNIX... I think this is more common on
>non-UNIX platforms.
>
>>
>> They're valid C code, nevertheless. A C compiler which fails to translate
>> correctly valid C code is broken by definition.
>> 
>
>True, but there is no law against extensions (which may conflict with
>obscure standard constructs) if you can turn them off.
>

Sure. There's no law against a c compielr compiling Modula2 with the 
right flags, as long as it DOESN'T claim its an ANSI c compierl in that mode.
I think (correct me if I'm wrong) that this thread of conversation spun 
off someone claiming that // was being considered for inclusion in an 
ANSI revision-- and my responding such was highly unlikely since it woudl 
break previously legal syntax.

As a flagged option, sure, go ahead and put it in your compiler.  But 
don't expect ANSI portability if you use it.  Myself, when I want to 
write code like that I use c++, where its already legal.

Jeff Kesselman

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

From: [email-masked] (David Kastrup)
Subject: Re: Kernel 1.1.53 - no BOOM
Date: 13 Oct 1994 08:00:35 GMT

[email-masked] (David Luyer) writes:

>Steven M. Doyle ([email-masked]) wrote:
>: In <[email-masked]> [email-masked] (Mark A. Horton KA4YBR) 
>:     writes:
>: >Console: colour EGA+ 132x44, 24 virtual consoles
>: >Serial driver version 4.00 with no serial options enabled
>: >tty00 at 0x03f8 (irq = 4) is a 16550A
>: >tty01 at 0x02f8 (irq = 3) is a 16550A
>: >tty02 at 0x03e8 (irq = 4) is a 16550A
>: >tty03 at 0x02e8 (irq = 3) is a 16550A
...
>The easiest (believe me, it is the simplest modification I've ever done
>to hardware) thing to do is re-wire the serial boards - usually this
>requires the addition of one wire and the removal of one jumper
>connector, sometimes you also have to cut a track.

>After doing this, you have to modify the kernel to use AUTO_IRQ,
>CONFIG_AUTO_IRQ or change the flags on the first four com ports,
>depending on kernel version.

Or, if your kernel is not pre-antique (considerably older than 1.0),
just use the setserial program to set the interrupts.
-- 
 David Kastrup        [email-masked]          
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen
-- 
 David Kastrup        [email-masked]          
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

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

From: [email-masked] (Rob Janssen)
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Reply-To: [email-masked]
Date: Tue, 11 Oct 1994 09:03:50 GMT

In <[email-masked]> [email-masked] (Jeff Kuehn) writes:

>In his last kernel patch announcement, Linus requested information on
>performance of the recent kernels.  I took it upon myself to gather a few
>hard numbers in as much as this is possible.  (Lies, Damned Lies, and
>Benchmarks!) While I consider myself far too skeptical to call Byte
>Magazine's UNIX Benchmark a "good" benchmark, it seemed like a reasonable
>place to start for several reasons.

I have noticed ever since 0.98pl4 that I started with, that performance
has been dropping.  The only exception is the disk performance, which
increased because of the clustering.

In the early days, starting something in X windows was snappy.  Now I
get a noticable delay.  I still have a copy of Byte-3.1 results of
0.98pl4 and indeed it shows a decrease since then.  At that time, my
system yielded 3.0 and on 1.1.33 it had 2.3
(not as much decrease as it seems to be.  however, I should also note
that my fist reaction when running Linux was "boy this is fast", as my
only frame of reference at that time was SCO XENIX and SCO UNIX running
on comparable hardware.  over time, one gets used to the speed and wonders
how it could ever be experienced as "fast" :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Vir Lagua)
Subject: Re: Xircom PCMCIA ethernet support?
Date: 11 Oct 1994 16:17:15 GMT

Russell Nelson ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] (Daniel J Thumim) writes:

:    Is there any chance of getting support for a Xircom CE10 PCMCIA
:    ethernet adapter?  I heard of problems with the parallel port
:    adapters, they don't give out the programming info.  Is this true
:    of the PCMCIA adapter too?

        STUFF DELETED

: Why bother?  They've been unhelpful for years.  I've spoken to the
: President of the company, and he has a specific philosophical problem
: with free software.  That's his right, but it's our right to ignore
: his company's products.

        How about support for the 3COM-3c589 PCMCIA Card?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
||||||||||CUL, vir |||| [email-masked]  |||| [email-masked] ||||||||||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Network and InterNetwork Solutions          +   There is only one Amendment
yet another computer consultant (yacc)      + that ensures all 10. The 2nd.

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

From: [email-masked] (Bruce Thompson)
Subject: Re: A badly missed feature in gcc
Date: 12 Oct 94 09:54:46 GMT

H. Peter Anvin ([email-masked]) wrote:
: Followup to:  <[email-masked]>
: By author:    [email-masked] (Jeff Kesselman)
: In newsgroup: comp.os.linux.development
: >
: > This is doubtful. The problem is that making this a 'feature' of ANSI c 
: > will all of a sudden make previously syntacticly correct code now fail to 
: > compile or, worse, compile with a different symantic meaning.  This woudl 
: > be DISASTEROUS to the attempt to standardize C.
: > 

: It is *already* put into quite a number of compilers (making it a
: portability issue already), and anyone writing code that uses that
: type of constructs should be shot anyway.  It is true there are such
: cases, but they are throuroughly and completely artificial.

Sorry, but simply because other compiler vendors want to break the
ANSI standard is not a sufficient reason IMHO.

The example cited most often,

        i = 4 //* comment */ 2;

is of dubious merit from a _style_ point of view. HOWEVER, it _is_
legal according to the ANSI standard. I would argue then that what
we're discussing is a change to the standard, not a simply a change to
a particular compiler. As such, it's my opinion that the change should
be evaluated in that light.

IMHO it still strikes me as a needless modification to the C standard
since in most cases C++ will look and feel enough like ANSI C that
simply using C++ should suffice.

As a postscript, I find the notion of supporting multiple comment
syntaxes as unusual in the extreme. I know of no other language than
C++ which has multiple comment syntaxes. I have yet to encounter a
compelling reason for it besides backward-compatability which isn't
_that_ compelling for me.

        Cheers,
        Bruce.
-- 
Bruce Thompson, B.Sc.           | "A great many people think they are
Software Engineer               |  thinking when they are merely
MacDonald Dettwiler,            |  rearranging their prejudices."
13800 Commerce Parkway,         |       -- William James
Richmond, BC                    |
(604) 278-3411                  | Usual disclaimers apply
NAPRA #473                      |

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

From: [email-masked] (Andrew R. Tefft)
Subject: Re: Improving SLIP latency under Linux
Reply-To: [email-masked]
Date: Tue, 11 Oct 1994 12:42:12 GMT

In article <[email-masked]>, [email-masked] (John Richardson) writes:
>If your slip server has a queue of ftp packets to send you, it should
>be thowing your interactive packet at the front of the queue.
>Or if you are sending and you have a full buffer of interactive
>packets, your interactive packet should go to the front of your
>queue. 

I just wanted to mention that Morningstar PPP has had a queueing
priority scheme for some time, and from what the documentation says,
it treats ftp as *interactive*, same as a login session. So people
have some different ideas on this.

-- 

Andy Tefft               - new, expanded .sig -     [email-masked]

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

From: [email-masked] (Bart Kindt)
Subject: Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE
Date: Fri, 14 Oct 1994 05:27:54 GMT

In article <[email-masked]> [email-masked] (System Administrator) writes:

>Steve Kneizys ([email-masked]) wrote:
>: Yuri Trifanov ([email-masked]) wrote:

>: : > We are using SLIP!  And the problems we see are not *after* a connection
>: : > is successfully opened, it is one of the system *refusing* connections
>: : > (apparently).  Nearly all functions handled by inetd seem affected: 
>: : > telnet logins, rlogins, ftp attempts, smail connections, attemps to do
>: : > zone transfers from named by our provider's router, you name it.  Things
>: : > work fine *most* of the time, but the login problems are the most
>: : > persistant and visible.  In those cases, the system log *usually* shows
>: : > 'connect from...' but the user never gets a prompt, or never gets a
>: : > password prompt after entering username.  Netd entries in the log are
>: : > 'connection refused' mostly. 

>: :  you could be having problems with the resolver and tcpd, which comes
>: : turned on by default in at least some distributions. if it can't
>: : resolve the inaddr of the connecting host it will refuse the
>: : connection.

>We've done extensive work with the nameserver setup.  I don't think this 
>is the cause.. more a symptom.

>: I see the freeze and I only use Etherlink III 3c579 cards on the same
>: wire as 3 VAXes, including our domain's name resolver.  Telnets from
>: the domain resolver VAX to the Linux freeze, as does FTP, finger,
>: smtp, rlogin.

>I've seen it when accessing the main machine from both the local ethernet 
>connecting about 8 machines, and when accessing by telnet/ftp/etc through 
>the SLIP link from our service provider.  This tends to rule out the SLIP 
>link or external network problems.  Everything *seems* to be pointing to 
>the low level daemons and/or kernel.

>--- George

In line with all this; Where can I read what is actually done with any new 
Kernel version? I just upgraded to 1.1.52, but I don't know what has been done 
to this kernel; was there any TCP / SLIP / PPP development which may solve the 
TCP problems we are having?

====================================================================================
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
====================================================================================

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

Crossposted-To: comp.os.linux.admin,comp.os.linux.help
From: [email-masked] (Bart Kindt)
Subject: Re: Serious Bug In The Networking Code
Date: Fri, 14 Oct 1994 05:39:23 GMT

In article <[email-masked]> [email-masked] (Daniel Tran) writes:
>Xref: otago.ac.nz comp.os.linux.development:12491 comp.os.linux.admin:11970 comp.os.linux.help:43483
>Path: otago.ac.nz!canterbury.ac.nz!waikato!ames!ncar!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!news.mic.ucla.edu!emelnitz.ucla.edu!dtran
>From: [email-masked] (Daniel Tran)
>Newsgroups: comp.os.linux.development,comp.os.linux.admin,comp.os.linux.help
>Subject: Re: Serious Bug In The Networking Code
>Date: Mon, 10 Oct 1994 17:51:46 GMT
>Organization: UCLA Arts - Theater/Film & TV Network Support
>Lines: 17
>Message-ID: <[email-masked]>
>References: <[email-masked]> <[email-masked]>
>NNTP-Posting-Host: 128.97.175.99
>X-Newsreader: Trumpet for Windows [Version 1.0 Rev A]

>In article <[email-masked]> [email-masked] (Jerry Ablan) writes:
>>: There appears to be a serious bug in some of the networking code
>>: supplied with linux/slackware, that causes the computer to get
>>: 'network unreachable' after approximately 3 minutes of perfect
>>: functioning.  I have no idea what the problem might be, and if
>>: somebody tell me where to look, I can try to figure out what versions
>>: my drivers etc. are.  Here are the configurations I ve gotten this
>>: problem with:

>>I've noticed that this occurs when you run routed. Do not run routed and see
>>if it still happens.

>>-- Jerry

>Would running running routed with -q parameter help.

>Daniel Tran - [email-masked]

Routed overwrites the Kernel 1.0.xx memory tables.  Eventually it will crash 
the system, depending how big the routing table becomes. I my case, within a 
few minutes.  Routed does not work properly anyway (the Linux version). The 
only way out is Gated, which I now use all the time... BUT it cannot be used 
with the 1.0.xx kernels!
So, if you MUST use a routed (gated) program, you also *must* use the new 
kernels. I am now using 1.1.52, which works fine as a multi-line SLIP dial-in 
server.

====================================================================================
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
====================================================================================

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

From: [email-masked] (Holger Kausch US/ESC 60/3/135 #3630)
Subject: Need more than 32 mount's
Date: 13 Oct 1994 09:40:01 GMT

Hello,

I am running LINUX (kernel release 1.0) in a 'big' SUN network, using
the automounter 'amd' and YP.

The configuration works very stable, and the integration into the network
you can call 'perfect', except:

        In some cases the limitation of maximal 32 mounts inside
        LINUX is a blocking problem. Because of the use of 'amd'
        the problem is temporary, but shell's hang, if you want
        to move to a directory, which can not be mounted if the
        limitation is reached.

I was searching inside the sources, but was'nt able to redefine the
limit to an higher value (like 128).

I hope, someone out there can help me.

Thank you!

Holger
====================================================================
[email-masked]

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

From: [email-masked] (Michael Krause)
Subject: Re: insmod drv_hello.o gives "___moddi3 undefined"
Date: Thu, 13 Oct 1994 08:35:22 GMT

Erik E. Rantapaa ([email-masked]) wrote:
: I am trying to use the module utilities with the following set up:

:   kernel version: 1.1.51
:       cc version: 2.5.8
:   modules.tar.gz: dated June 27, 1994

: When attempting to load the sample module dvr_hello.o, however,
: I get the following error:

: ___moddi3 undefined

: Is there something special I need to do when compiling module
: object files?

One of the datatypes involved in the modulo operation (%) is of type
long long of you look at the includes. As you only want to test the modules,
you can cast each of the operands to int. Then __moddi3 is no longer needed.

Ciao,
Michael

--
- Michael Krause
- E-Mail: [email-masked]

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: A badly missed feature in gcc
Date: Wed, 12 Oct 1994 17:43:31 GMT

In article <[email-masked]>,
H. Peter Anvin <[email-masked]> wrote:
>Followup to:  <[email-masked]>
>By author:    [email-masked] (Jeff Kesselman)
>In newsgroup: comp.os.linux.development
>>
>> This is doubtful. The problem is that making this a 'feature' of ANSI c 
>> will all of a sudden make previously syntacticly correct code now fail to 
>> compile or, worse, compile with a different symantic meaning.  This woudl 
>> be DISASTEROUS to the attempt to standardize C.
>> 
>
>It is *already* put into quite a number of compilers (making it a
>portability issue already), and anyone writing code that uses that
>type of constructs should be shot anyway.  It is true there are such
>cases, but they are throuroughly and completely artificial.
>

Thsi is a half-truth, it is true but incomplete.  It IS in many compilers 
BUT goes away if you set s 'strict-ANSI' flag.  Thsi is as it shoudl be 
for the reasons I already specified.  Making it a part of ANSI C would 
invalidate previosuly legal syntax-- a very very bad idea.

JK

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

From: [email-masked] (Pierre Belanger)
Subject: Re: Unable to find XF86-3.1-lib.tar.gz with correct sum.
Date: 9 Oct 1994 21:43:15 GMT

Kevin Ruland ([email-masked]) wrote:

: I've searched the world over to find the X11R6 libs and can't find one
: with the correct checksum.  gunzip even pukes on it.  It seems okay
: up to ./lib/libX11.so.6

: I've tried the following sites:

: xfree86.cdrom.com
Either you don't ftp with "bin" option 'enable' or you must do something
wrong.  I HAD NO PROBLEM AT ALL.

: Were's the good one.
They must be all god...

Pierre B,

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: A badly missed feature in gcc
Date: Wed, 12 Oct 1994 17:47:41 GMT

In article <[email-masked]>,
H. Peter Anvin <[email-masked]> wrote:
>Followup to:  <[email-masked]>
>By author:    [email-masked] (Bruce Thompson)
>In newsgroup: comp.os.linux.development
>> 
>> is of dubious merit from a _style_ point of view. HOWEVER, it _is_
>> legal according to the ANSI standard. I would argue then that what
>> we're discussing is a change to the standard, not a simply a change to
>> a particular compiler. As such, it's my opinion that the change should
>> be evaluated in that light.
>> 
>> IMHO it still strikes me as a needless modification to the C standard
>> since in most cases C++ will look and feel enough like ANSI C that
>> simply using C++ should suffice.
>> 
>> As a postscript, I find the notion of supporting multiple comment
>> syntaxes as unusual in the extreme. I know of no other language than
>> C++ which has multiple comment syntaxes. I have yet to encounter a
>> compelling reason for it besides backward-compatability which isn't
>> _that_ compelling for me.
>> 
>
>C++ added another comment convention for the reason that comments
>terminated in newline tend to be a *lot* more convenient to use than
>C-style block comments.  (You may disagree, but I am fairly certain
>you are in minority).  /* ... */ is supported as backward
>compatibility, but you will be hard-pressed to find a C++ programmer
>who uses them more than once in a blue moon.
>

Guys, 
Pardon my intrusion but I think you are both sayign the same thing:)
And as a c++ programmer I agreee with you. /* */ causes alot of
problems (primary in this is its non-nesting nature. Yucko!).  I ALWAYS 
use // in new c++ programs.  I do find the c++ compiler accepting /* */ 
handy in  lazy sort of way, though, when i am porting straight ansi c 
code. (Yes, I could change the comments myself, or write a little 
processor to do it, but as I said, I'm lazy :)  )

JK

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: A badly missed feature in gcc
Date: Wed, 12 Oct 1994 17:49:54 GMT

In article <[email-masked]>,
Alan Braggins <[email-masked]> wrote:
>In article <[email-masked]> [email-masked] (Jeff Kesselman) writes:
>   >This would break perfectly correct C code, like
>   >
>   >    a = b//* Comment here */ c;
>   >--
>
>   And this is the cannonical case of why c++ is NOT a true super-set of 
>   ANSI c.  (Thanks, I'm going to save the exampel for the next time I have 
>   THAT argument.)
>
>That "int function();" declares a function with no arguments in C++
>and an unknown number of arguments in C is far more common.
>So are variables called "class" or other new reserved words.
>--
>Alan Braggins  [email-masked]  [email-masked]
>"Any technology distinguishable from magic is insufficiently advanced"
>

Very true, he said, quickly jotting notes for the next inevitble 
super-set argument.

You'ld be suprised, though, how many people DON'T realize that c++ is not 
just extended ANSI C....

JK

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

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