Linux-Development-Sys Digest #926, Volume #6 Fri, 2 Jul 99 18:14:58 EDT
Contents:
Re: C++ templates: More than Turing Complete? (Nathan Myers)
Re: Domain Names Limited to two or three Characters? (Tristan Wibberley)
Re: IPCS(1) Command - Source file available (J.H.M. Dassen (Ray))
Re: Why not C++ (Johan Kullstam)
Re: C++ templates: More than Turing Complete? (Johan Kullstam)
Re: C++ templates: More than Turing Complete? (Greg Comeau)
Re: Why not C++ (Nathan Myers)
Re: Remote login problems in custom RedHat env... (Dave Smart x2890)
Re: Why not C++ (Greg Comeau)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 2 Jul 1999 13:49:34 -0700
Davin McCall <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Nathan Myers) wrote:
>
>>The convention in some communities is to ignore performance
>>and engineering rigor. Certainly anything can be achieved in
>>assembly language (or in T-code, if you like) that can be achieved
>>with a C++ _program_, given infinite time and coding effort.
>
>Infinite? Finite, surely!
"Indefinite time and coding effort", then, if you like.
But by quibbling you have missed the point.
>>Given the constraints of a sensible _library_ interface and
>>equivalent-to-machine-code performance, C++ achieves what
>>other languages haven't, yet.
>
>I would say "approaching sensible" and almost completely disagree with
>the performance statement. In most cases a compiled program written in
>a high level language performs very acceptably, but not nearly as well
>as an equivalent program hand coded in assembly language (or machine
>code).
This may have been true at one time. Modern CPUs are so complex
that hand-coding is unlikely to do better than a good compiler
on a significant program.
The point you missed by quibbling is that once you cleave the solution
space along a library boundary, you have left the domain of "computer
science" and are firmly in the domain of "engineering" where your
precious axioms are just obvious facts, and the hard problems
involve tradeoffs and organizational choices.
Language features which help transport these choices back and
forth across that boundary are essential engineering tools that
are often lacking in academic wonder-langauges.
>>Of course some other languages will achieve parity, someday, but
>>only those designed by people who fully understand the strengths of
>>standard C++. Maybe such a language will even succeed in avoiding
>>its weaknesses.
>
>I take it that you mean they must understand the principles, although
>not necessarily how they are applied in C++.
No, absolutely the opposite! Real, useful programs are written
using real language features. To understand principles you must
first understand the specific application. All valid principles
are derived from experience, however they may be dressed up after
the fact.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: Domain Names Limited to two or three Characters?
Date: Thu, 01 Jul 1999 18:39:40 +0100
Reply-To: [EMAIL PROTECTED]
JDJohnson wrote:
>
> Are domain names limited to two (.uk, .de) or three (.com, .org, .edu, .gov)
> characters in length? If not is there a max number of characters?
> Newgroups: comp.os.linux.development.system
Why? Since when did DNS specifications pertain to Linux system related
groups?
Look up the DNS specifications, currently there are lots of two letter
top-level domains (the standard two letter country code), some three
letter ones (com, net, gov, mil, org, etc.), and .arpa
AFAIK the DNS spec allows for any length, and any program should be
prepared for that.
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: IPCS(1) Command - Source file available
Date: 2 Jul 1999 18:59:23 GMT
Philippe Campi <[EMAIL PROTECTED]> wrote:
>Does anyone knows where I can found the source file for ipcs(1) command
>under Linux ?
It's part of util-linux;
http://freshmeat.net/appindex/1998/06/13/897720881.html
HTH,
Ray
--
UNFAIR Term applied to advantages enjoyed by other people which we tried
to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY,
UNDERHAND and JUST LUCKY I GUESS.
- The Hipcrime Vocab by Chad C. Mulligan
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 02 Jul 1999 14:37:55 -0400
o r c @ p e l l . p o r t l a n d . o r . u s (david parsons) writes:
> In article <[EMAIL PROTECTED]>,
> Bruce Hoult <[EMAIL PROTECTED]> wrote:
>
> >Dylan is not several hundred percent slower than C as Java is.
>
> Have you benchmarked Java vs C on the same machine? (No, I don't
> mean benchmarking C on a machine vs Java running on a p-machine
> on that machine); there's certainly nothing in the design of
> Java that would make it much slower than C on the same machine.
>
> Dylan is Yet Another Pascal, isn't it? It looks like the bastard
> child of a shotgun marriage between Ada and Pascal.
afaict dylan is the bastard child of lisp and the algol family (which
includes pascal, ada and sort of includes C and C++). this isn't to
say that dylan is all bad. it is taking some good ideas of both.
--
johan kullstam
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 02 Jul 1999 14:41:07 -0400
[EMAIL PROTECTED] (Davin McCall) writes:
> On 1 Jul 1999 01:57:18 -0700, [EMAIL PROTECTED] (Nathan Myers)
> wrote:
>
> >The convention in some communities is to ignore performance
> >and engineering rigor. Certainly anything can be achieved in
> >assembly language (or in T-code, if you like) that can be achieved
> >with a C++ _program_, given infinite time and coding effort.
>
> Infinite? Finite, surely!
>
> To say that something takes an infinite amount of time to do is to say
> that it can't be done. And yet, you will find that an assembly
> language (or machine code) program of finite size and complexity is
> generated whenever you compile a high level language program, even a
> C++ program.
C++ templates are turing complete (although you'd have to be some kind
of masochist to use them as a programming language -- it can be done).
you have a classic stopping problem. therefore, C++ will not
necessarily compile in finite time to a finite sized program.
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 2 Jul 1999 16:12:22 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Davin
McCall) writes:
>On 1 Jul 1999 01:57:18 -0700, [EMAIL PROTECTED] (Nathan Myers)
>wrote:
>
>>The convention in some communities is to ignore performance
>>and engineering rigor. Certainly anything can be achieved in
>>assembly language (or in T-code, if you like) that can be achieved
>>with a C++ _program_, given infinite time and coding effort.
>
>Infinite? Finite, surely!
>
>To say that something takes an infinite amount of time to do is to say
>that it can't be done. And yet, you will find that an assembly
>language (or machine code) program of finite size and complexity is
>generated whenever you compile a high level language program, even a
>C++ program.
What Nathan meant was clear to me. He just meant no time constaint
to complete it, not literally that the person must take infinite time.
>>Given the constraints of a sensible _library_ interface and
>>equivalent-to-machine-code performance, C++ achieves what
>>other languages haven't, yet.
>
>I would say "approaching sensible" and almost completely disagree with
>the performance statement. In most cases a compiled program written in
>a high level language performs very acceptably, but not nearly as well
>as an equivalent program hand coded in assembly language (or machine
>code).
At least not nearly as well _as some_ equiv progs....
Nobody said it didn't. See Nathan's comment you quote above.
This is CLEARLY a compromise we must all strike.
>>Of course some other languages will achieve parity, someday, but
>>only those designed by people who fully understand the strengths of
>>standard C++. Maybe such a language will even succeed in avoiding
>>its weaknesses.
>
>I take it that you mean they must understand the principles, although
>not necessarily how they are applied in C++.
I took it to mean something like that.
Certainly nobody is denying that C++ has problems.
I hope one day many new somethings will out-do _everything_ out there
or we are in some bad bad bad shape.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 2 Jul 1999 14:27:37 -0700
[EMAIL PROTECTED]> wrote:
>Bruce Hoult <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] wrote:
>:> C++ is still slower and bulkier.
>
>I compiled and compared like this:
>My point was that C++ output is still bigger than C, _for the exact same
>source code_, using the same code generator and optimizer.
Cunning lies are worse than obvious lies.
In the example you posted both compilers produced an identical
sequence of instructions. Only the assembler directives were
different. The honest interpretation of your example is that
the C and C++ compilers appear to produce code of exactly equal
efficiency, for identical input.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Dave Smart x2890)
Crossposted-To: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.security
Subject: Re: Remote login problems in custom RedHat env...
Date: 2 Jul 1999 19:31:56 GMT
Wallace Barnes ([EMAIL PROTECTED]) wrote:
: DNS is disabled on this box. I've even gone as far as to remove the resolv.conf
: file. Besides, tcpdump shows that the box is able to send acks to whatever
: remote machine is involved. Also remember that all established connections can
: reach any host via telnet, ftp, rlogin, etc... (as long as they're in the hosts
: table of course). As for the network card, this problem has been replicated on
: three other identical systems to rule out just that. Network traffic is
: non-existent on this box. I've even prevented misc. services such as sendmail
: from starting to make sure to no avail. Thanks for your responses though.
DNS dissabled or not .. your host still could be waiting for info.
For example, typical installation of TCPD (tcp wrappers) has
the -paranoid setting active which immediatly tries to do a reverse
name lookup. {AFTER the connection, BEFORE the LOGIN just where your hang is!}
If you have TCP wrappers installed with paranoid (default), and no way
to complete the lookup this will indeed hang the connection for some time.
I suspect that once tcpd is blocked by one invocation from someone NOT in
your /etc/hosts file, all other requests through tcpd would queue up too
effectively blocking access to your host.
We use host tables exclusively and disabled DNS too.
I had to get TCP-Wrappers source and recompile without paranoid
option for this reason.
-other thoughts
Also, 'no-route-to-host' and other network timeouts may be
very long, causing a hang that may not clear for 10's of
minutes. Combined with an attempt by your host to access
a server (dns, kerberos), or auth/ident (client) this
could cause a hang .. but trail would show in network log.
Check 'netstat -nr' or 'route' to see the default gateway
is still OK. If it changed (possibly by a RIP default update,
or an ICMP re-route msg) then
you would loose all remote network access at that point.
Also, disruption of network protocols can be caused by firewall,
router config, or disabled services.
Do you have IPFW active and too restrictive?
For example, If you disable or block ICMP, then any network
query may take forever to finish since it may get no response.
As the client telnets to your host, your host (telnetd and/or
tcp wrappers) may use auth/ident back to the client to
validate the userid/port info. If this service is blocked,
the Linux timeout may take a while, particularly if there is no
response at all.
--Dave
: Wally
: [EMAIL PROTECTED]
: Bryan wrote:
: > Jon Skeet wrote:
: > >
: > > [EMAIL PROTECTED] wrote:
: > >
: > > > I have an unusual problem with telnet, rlogin, ftp and any other
: > > > program which requires logging in remotely. The system specs are: 400Mhz
: > > > Pentium Pro, 256MB RAM, onboard Intel etherexpress pro 10/100Mbs network
: > > > card, 2 serial ports, running a custom Red Hat 5.2 kernel. Four kernel
: > > > header files were modified to allow for a 3072 process limit ( fs.h,
: > > > limits.h, posix_types.h, /usr/include/gnu/types.h ). The machine will
: > > > boot and run fine for about 10 minutes then any form of remote log in
: > > > (even rcp and rsh) will hang after it successfully connects to the
: > > > system just before it gives you the opportunity to provide your login
: > > > name and/or password. On telnet you can even see the "Connected to
: > > > <host>" message. Any connection made before this problem occurs is fine
: > > > and has full capabilities. I can get out of the box using any method I
: > > > choose (telnet, ftp, etc). The oddest thing about this problem is that
: > > > all other inetd services are unaffected. They continue to respond to
: > > > request on their respective ports without fail. A tcpdump on the machine
: > > > will show telnet, rlogin, etc ... activity. They send their initial acks
: > > > and replies but don't complete their initialization procedures.
: > >
: > > Is it feasible that the problem is in reverse host lookup? I know telnetd
: > > checks that the host that is telnetting to it is valid before going ahead
: > > with the connection; it's possible that rcp does the same. If so,
: > > possibly your DNS is going wrong...
: > >
: >
: > I agree; it could be reverse DNS or no DNS at all.
: >
: > Another idea: Network card burps...
: >
: > How much activity is there once the system is up? I had a Netgear
: > 10/100 card in my box with one of the original DEC tulip chips (they've
: > since created their own proprietary set due to DEC's discontinuation of
: > the 21something series), and it would come up with some overrun problems
: > at high NFS loads. I finally swapped it with a newer one I had bought
: > for a Windows box, and the old card works fine in the Windows box, and
: > the new one works beautifully in the Linux box (gotta love 100Mbps).
: > (Probably some inconsistencies with the tulip driver and that older
: > chipset..)
: > .
: > Which kernel version are you using? You can use the 2.2.x kernel series
: > on Redhat 5.2. A custom RedHat 5.2 kernel sounds like you used th
: > 2.0.36 kernel that came with it.
: >
: > 2.2.5 runs really stable on three of my 5.2 machines. I'm suggesting a
: > kernel and network card driver upgrade because even if you turn off
: > networking, like you said you're doing, the card may still be on the
: > fritz, and there may be a compatibility issue with the EtherExpress
: > Pro. (Is that intel or 3com? 3com's drivers were semi-broken in
: > 2.0.36...)
: >
: > > --
: > > Jon Skeet - [EMAIL PROTECTED]
: > > http://www.pobox.com/~skeet/
: >
: > -- Bryan Scott
: > -- CTR Online Systems Administration
: > (remove the NOSPAM. for email)
--
+------------------------------------------------------------------+
| Dave Smart E-Mail: [EMAIL PROTECTED] |
| Computer Sciences Corp. |
| 7700 Hubble Drive, Voice: (301)-794-2890 |
| Lanham-Seabrook, MD 20706 FAX (301)-794-9530 |
| #include /std/disclaimer 'My opinions are mine own...' |
+------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.lang.c++
Subject: Re: Why not C++
Date: 2 Jul 1999 15:49:53 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Don Baccus) writes:
>In article <7ldg91$qen$[EMAIL PROTECTED]>,
>Greg Comeau <[EMAIL PROTECTED]> wrote:
>
>>Hmmm. Well, ok, yeah, sure, it does get a messy feeling.
>>But too, you then have to do more of a surmisal of the situation
>>that just that. It seems to me that these various aspects (solutions)
>>are necessary to meet the diversity of problems and needs of
>>applications, and their designs. As such, I don't really feel this
>>is as ad hoc as you say it is.
>
>Oh, it is ad hoc, every bit as ad hoc as the process by which
>the language evolved. Evolution by committee, at that.
This is an inaccurate statement about C++ history and hence
your saying to the contrary clearly demonstrates your lack
of knowledge on the issue and hence loss of credibility in your
perpective on this aspect of things. FYI, the ONLY two major
features added by the committee were RTTI and namespaces.
Yes, they did formally add EH and templates too, but they certained
predated the committee too in terms of what some companies were doing
et al. Sure, the committee was involving in many things, but
to say C++ was designed by committee or was evolution by committee is silly.
>>Indeed it is a solution to one problem
>>(really a class of problems, but ok), but as just mentioned, that's
>>exactly the point. I mean, do you not want the ability to express
>>a solution to a class of problems/designs/etc??? I definitely do.
>
>Wouldn't it be even nicer in a language that was designed to
>allow you to express such things, rather than a kludge like
>C++?
When you meet the perfect language, tell us.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
** 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 PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
