Linux-Networking Digest #734, Volume #11 Wed, 30 Jun 99 16:13:40 EDT
Contents:
Linux PDC ? ? ("WTS")
Re: sendmail & dns on a linux 2.2 kernel (Suse 6.1) (Andrzej Filip)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Greg Comeau)
Help setting up email on Linux w/DSL connection... ([EMAIL PROTECTED])
Re: DHCP flooded cable network!! (Hal Sadofsky)
Re: nic driver settings (Jim Roberts)
Programmatically reading e-net addresses? ("Jeff Wishnie")
Network Programming (Michael Koops)
Re: Why not C++ (Greg Comeau)
Re: Why not C++ (Chris Double)
Re: Why not C++ (Greg Comeau)
Re: How reset network card setting on the fly? (Tom Wojciaczyk)
Re: Network unreachable on startup only! (Lyndon Hills)
----------------------------------------------------------------------------
From: "WTS" <[EMAIL PROTECTED]>
Subject: Linux PDC ? ?
Date: Wed, 30 Jun 1999 14:37:47 -0400
I have been searching and searching and have not found the information I
need. What I want to do is turn our NT PDC into a Linux PDC. Is this
possible at this stage of Linux/Samaba development? Basically my current PDC
is a file and print server. The problem that I have run up against, is that
user accounts are stored on another NT PDC within the company. Do I have to
re-create our entire companies group/user accounts on the Linux server, or
is there a way to port that information over to the Linux box easily? I hear
there are several places doing this, but I have not been able to find out
how to accomplish this very thing. Please Help!
Thanks!
WTS
------------------------------
From: Andrzej Filip <[EMAIL PROTECTED]>
Subject: Re: sendmail & dns on a linux 2.2 kernel (Suse 6.1)
Date: Wed, 30 Jun 1999 18:12:59 +0200
Vincent De Keersmaeker wrote:
> I've noticed that in the sendmail.cf file the serviceswitch options is
> ignored on my linux system (kernel 2.2 Suse 6.1 ). whatever values i
> put in the defined fiel (/etc/service.switch), sendmail keeps doing
> DNS-lookups at moments i really don't won't him to do. I've solved the
> problem by changing my /etc/nsswitch.conf file ("hosts files" where it
> was " host files,dns". Now sendamil doe not do any DNS lookup, but
> (of course) Squid doesn't either. Is there a way to say that only
> sendmail can't do dns-lookup, but other processes can (like squid)?
>
> Vincent
You may specify service switch file you want sendmail to use.
Use "O `ServiceSwitchFile=" option in sendmail.cf.
If it fails:
http://www.sendmail.org/faq/section3.html#3.22
Q3.22 -- How do I configure sendmail not to use DNS?
--
Andrzej (Andrew) A. Filip fax: +1(801)327-6278
mailto:[EMAIL PROTECTED] http://bigfoot.com/~anfi
Postings: http://deja.com/profile.xp?author=Andrzej%20Filip
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.development.system
Subject: Re: Why not C++
Date: 30 Jun 1999 14:54:39 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Stephan Houben <[EMAIL PROTECTED]>
writes:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>
>> Johan Kullstam <[EMAIL PROTECTED]> wrote:
>> >actually i don't mind the templates in C++. they are rather weak, but ...
>>
>> FUD, again. C++ templates are not weak. They allow construction of
>> libraries that cannot be constructed in any other language.
>
>Templates in C++ solve a problem that simply doesn't exist in most other modern
>programming languages. The fact that it exists in C++ is due to the fact that C++
>is based on C.
>
>Languages like C and Pascal are "strongly typed", which basically means that when I
>have
>a function that squares an int:
> int square(int x)
> {
> return x*x;
> }
>
>,then this function cannot square floats. In order to square floats, I have to define
>a new
>function with almost identical code:
>
> float square(float x)
> {
> return x*x;
> }
>
>
>Now, this problem doesn't exist in dynamically typed programming languages like
>Python,
>since there you would do:
>
> def square(x):
> return x*x
>
>,and the type of x only plays a role at run time (when the correct * operation has to
>be selected).
>
>In other programming languages, e.g. Haskell, you *do* have typing, but there
>types can be more general, i.e. the following definition:
>
> square x = x*x
>
>would be automatically typed by the compiler as being of the type
> square :: (Num a) => a -> a
>, implying that square is a function taking some value of an type a and producing
>a value of the same type, where a may be any type of type class Num, which means that
>a * operation has to be defined on a.
>
>Now both these options are much less cumbersome than the C++ way of doing things;
>moreover, in the Haskell way, you *do* get static typing with all the advantages
>(more efficient code generation, compile-time error checking).
>
>IMHO, C++'s templates are a useful hack to repair a basic flaw in C's type system.
>However, there are certainly much more elegant solutions.
I don't follow. I simply don't follow. First you say stuff like
that templates in C++ solve a problem that doesn't exist in other
languages, and then go on to show generic capabilities of other
languages. That's contradictory.
Then you conclude with a statement that (I assume in other languages)
templates have a more elegant solution. Again, not only does this
contradict that they are not necessarily in other languages, but
your examples DO NOT show how it is more elegant. All you've
shown so far is function-like macros. And C++ templates are not
just that.
It's no secret that I'm very much into C++. However, I ALWAYS
want to learn more about how other langs do stuff. But I keep
seeing posts like above, which attack C++ and then don't clearly
show alteratives. Come on, I'm all psyched up for something hard core.
- 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] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.development.system
Subject: Re: Why not C++
Date: 30 Jun 1999 12:22:57 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Bruce Hoult)
writes:
>In article <7l3en8$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Don Waugaman) wrote:
>
>> Could you describe what you don't like about C++ templates, and how a
>> statically-checked language that intends to minimize runtime cost could
>> do better?
>
>Well, here's what *I* don't like about C++'s templates...
>
>Actually, C++ templates are just fine -- they're probably one of the best
>parts of the language.
>
>The *problem* is that C++ templates are an ad-hoc solution to just one
>problem, and C++ has too *many* ad-hoc solutions. When you write a
>function in C++ you've got to choose between template functions, inline
>functions, overloaded functions, virtual functions ... it's a mess. (Yes,
>I know those choices aren't orthogonal, and can be combined -- that just
>makes it worse.)
>
>Bjarne Stroustrup started with the simple "one name = one function"
>principle in C and added on on virtual functions with runtime dispatch on
>the first argument so that he could emulate Simula.
>
>Then he thought "wouldn't it be nice if you could write new versions of
>'+' and '<' and use the same name for several similar functions of your
>own?". So he created overloaded functions, which are a completly
>different and incompatable thing from virtual functions.
>
>To try to close the gap between overloaded functions and virtual functions
>a bit, he eventually added template functions, which basically let you
>write a number of overloaded functions more economically.
>
>It's a big untidy mess. And sometimes you actually can't do what you want
>to do.
>
>Don't get me wrong -- I greatly admire Bjarne Stroustrup and think he did
>a great job, and C++ was a big improvement on the state-of-the-art in 1980
>when he started to implement it (or 1990, when it started to spread
>widely). But I think it's time to move on now.
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. 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.
>> how a statically-checked language that intends to minimize runtime cost
>> could do better?
>
>Ok, let's look at what happens in Dylan.
>
>Dylan has only *one* kind of function -- the generic method -- but
>depending on the circumstances, the compiler will do any of:
>
>- compile time selection of the right function
> - inlining of the right function
> - outlining of the right function (using it as a template)
>- run time selection of the right function
>
>
>Let's look at an example:
>
>define inline method myAdd(a, b)
> a + b;
>end myAdd;
>
>define method f(x, y)
> myAdd(x, y);
>end f;
>
>define method g(x :: <integer>, y :: <integer>) => (z :: <integer>)
> myAdd(x, y);
>end g;
>
>define method h(x :: <single-float>, y :: <single-float>)
>=> (z :: <single-float>)
> myAdd(x, y);
>end h;
>
>
>Look at "myAdd". Unlike g and h, it doesn't declare the paramter types,
>or the return value type(s). What sort of function is it?
Hmm again. You were trying to say you should move on from C++ because
it has a number of ways to to allow your to compose functions.
Now you're showing Dylan does too. ????? Sounds like a mess too then.
>think of it either as a C++ template function with a and b declared to be
>of some unspecified type...
>
>template<class T> T myAdd(T a, T b){
> return a + b;
>}
>
>... but it's bit more than that. C++ templates require that the actual
>types of a and b be known at compile time. This C++ template requires
>that a and b be of the *same* type, which is also the type of the result.
>But with the Dylan function the arguments could be of different types,
>more like this:
>
>template<class T1, class T2> ???? myAdd(T1 a, T2 b){
> return a + b;
>}
>
>But this is not easy in C++.
It's not (assuming you're talking about the T1 and T2 as compared to
the first template)?? I don't understand this point.
>What is the function return type? T1? Not
>necessarily. T2? Not necessarily. Something else? But *what* else?
>It's impossible to say. Dylan doesn't care.
WhaWhaWhat? Ok, I can see some case where it doesn't matter, but I can also
see some cases where it does. If there is no way to address the latter,
they I would consider this a fundamental flaw.
>You could also think of myAdd as being like a C++ virtual function that is
>not actually part of a class, and that does runtime type dispatch based on
>the types of *both* arguments, not just the first one.
But that doesn't address the return type issue.
>Let's see what "d2c" (see <http://www.gwydiondylan.org>) does with this --
>here is the C code output by d2c (with my comments after //):
Nothing here seems compellingly different (than say C++).
>We can force the issue (and demonstrate the point) by adding the following
>functions:
>
>define method myAdd(a :: <integer>, b :: <integer>, #next super)
>=> (c :: <integer>)
> super();
>end myAdd;
>
>define method myAdd(a :: <single-float>, b :: <single-float>, #next super)
>=> (c :: <single-float>)
> super();
>end myAdd;
>
>This is essentially identical in purpose and effect to C++ explicit
>instantiation of template functions.
Again, you just seem to keep showning similarlties while calling
the C++ way a mess.
>"super()" is essentially the same idea as "super" in Java or SmallTalk or
>"inherited" in Object Pascal (or the unsucessful C++ "inherited::"
>proposal -- see section 13.6 in "The Design and Evolution of C++") --
>except that in Dylan it applies to any overloaded function, not just
>virtual functions.
So Dylan has overloaded function too. That same mess keeps peeking out! :)
>Unlike C++ template functions, these specialised functions are also useful
>when the types of a and b are NOT known in advance, but fortuitously turn
>out to be <integer> or <single-float> at run time. The specialised method
>will automatically be called, rather than the general one, which will
>result in not having to do virtual (generic) calls of arithmetic,
>comparisons etc inside the function, and it may result in more efficient
>calling (or even inlining) of any other functions called from within
>myAdd().
You're starting to loose me, but I think you're essentially saying it
would end up being the equivalent of a runtime instantiation of a
C++ template?
>I hope that I have demonstrated that a single simple mechanism in Dylan
>can sucessfully replace *all* the different kinds of functions in C++,
>with no loss of efficiency over C++.
The problem I'm having is that you attacks some aspects of C++ but
really have not shown how Dylan is not the same mess.
- 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]
Subject: Help setting up email on Linux w/DSL connection...
Date: Wed, 30 Jun 1999 18:52:17 GMT
I just setup my machine to work with DSL. I had
a little problem configuring the box to work
correctly with two ethernet cards, but I finally
got things to work (had to get the latest tulip
driver and recompile). My plan is to eventually
register a domain name with the static IP address
assigned to my machine.
What do I need to receive and buffer inbound
email, and to allow clients on my SOHO network to
send email out through it (a POP server like
qpopper?) I'd prefer to have email go directly
to/from my machine instead of the ISP provider.
I've looked for HOWTO's, tried setting up
sendmail using linuxconf, etc. and am still
confused. Any help would really be appreciated!
Thanks!!!
Jeff
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Hal Sadofsky)
Subject: Re: DHCP flooded cable network!!
Date: 30 Jun 1999 11:26:38 -0700
In article <[EMAIL PROTECTED]>,
Wouter Liefting <[EMAIL PROTECTED]> wrote:
>Whoopiee...
>Ed Davis wrote:
>> Hi,
>> I have had Linux running for almost a year now using ipfwadm to connect 2
>> other home computers running windoze. Today the cable internet provider
>> called me and said they had to shut down my connection because I was
>> flooding the network with requests for an IP address, thousands of requests.
>> They said either I had a wrong DHCP configuration (stock redhat config) or
>If it is indeed your Linux box, kill the dhcpcd daemon and enable static IP
>addressing on all interfaces (this is a good idea anyway).
This is not necessarily a good idea, unless I misunderstand Wouter's
suggestion. You can treat the address supplied to your machine by the
dhcp as static. This will be fine for a while, but eventually the
lease will run out and the server will want to renegotiate (even if it
then resupplies the same address, which is likely). If your machine
is configured for static IP, it won't know about renegotiating with
the server, and then the server, and eventually those who run your
ISP, will become unhappy.
Hal Sadofsky
------------------------------
From: [EMAIL PROTECTED] (Jim Roberts)
Subject: Re: nic driver settings
Date: Wed, 30 Jun 1999 19:16:02 GMT
In article <[EMAIL PROTECTED]>,
Scott Prince <[EMAIL PROTECTED]> writes:
> I have a pro120b ethernet card that linux rh5.2 refuses to recognize. I
> am going to try a newer version of the tulip driver, but I'm wondering
> if the i/o setting may also be wrong. Windoze98 lists the i/o as 6100,
> which doesn't look like any of the examples that I have seen.
>
> How would I go about getting the proper setting?
>
>
> Thanks,
> Scott
>
Scott:
I/O 0x6100 is a valid I/O for a PCI device. If you compile the driver
in the kernel (version 90 or better) the card will be probed.
Otherwise in /etc/config.modules add a alias line as "eth0 tulip"
and options i/o=0x6100 and things should work.
Jim
------------------------------
From: "Jeff Wishnie" <[EMAIL PROTECTED]>
Subject: Programmatically reading e-net addresses?
Date: Wed, 30 Jun 1999 11:42:05 -0700
I need to read the hardware addresses of my network interfaces (all are
Ethernet). I can retrieve IP addresses via gethostbyname() but can't seem to
find a call for accessing the mac-addresses.
Any suggestions?
Also, can anyone point me to a good implementation of a CRC48 or CRC64
hashing algorithm (including recommended poly's)
Thanks!
Jeff
[EMAIL PROTECTED]
------------------------------
From: Michael Koops <[EMAIL PROTECTED]>
Subject: Network Programming
Date: Wed, 30 Jun 1999 18:32:55 +0200
Hi,
does some documentation exist in the net about network programming ? If yes,
where can I get it ?
Thanks,
Mike
=========================
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.development.system
Subject: Re: Why not C++
Date: 30 Jun 1999 15:46:34 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Chris Double <[EMAIL PROTECTED]> writes:
>Personally I'm in agreement with you Greg (I think) - the reason some
>C++ compilers produce bad code is exactly the same reason as why some
>C compilers produce bad code, and some lisp compilers produce bad
>code, and <insert favourite langauage> compilers produce bad
>code. That reason being someone made a mistake in the
>implementation. It is not because the language itself is the problem.
Frankly, I DO believe that the issue goes beyond a bug in the compiler,
or a not too savvy compiler writer, etc and that it DOES include the
languages itself. But it's not _just_ the latter, or _just_ one
of those things. Yet that's more or less the reckless way I've heard
this thread go so far (speaking out loud here, not particularly to you).
Most of the "BLAH is" statements being made are too strong and misleading.
Actually, an executive summary of many of my points in this thread
is that there are too any blanket statements being made and too many
biased comparisons being brought forth. As always, some of this is
because of the limitations of this medium, but others are not.
- 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: Chris Double <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.development.system
Subject: Re: Why not C++
Date: 01 Jul 1999 07:11:18 +1200
[EMAIL PROTECTED] (Greg Comeau) writes:
> This DOES NOT address Bruce's Q. Are you seriously going to
> defend Linus's skewed response to Bruce by showing that MSVC++
> actually has one sole isolated bug some mag reported on (ok that
> in C mode the compiler did not happen to have too)?
I didn't intend it to come across as any form of defence of anyone's
response. It was just an example of a compiler that produced bad code
when compiling C++ but good code in C mode which is what I thought
Bruce was asking about.
Personally I'm in agreement with you Greg (I think) - the reason some
C++ compilers produce bad code is exactly the same reason as why some
C compilers produce bad code, and some lisp compilers produce bad
code, and <insert favourite langauage> compilers produce bad
code. That reason being someone made a mistake in the
implementation. It is not because the language itself is the problem.
> OTOH, since we're just jesting: Do recall that MS products do not
> have bugs.
Of course ;-)
Chris.
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.development.system,comp.lang.c++
Subject: Re: Why not C++
Date: 30 Jun 1999 13:07:02 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (NF Stevens)
writes:
>[EMAIL PROTECTED] (Nathan Myers) wrote:
>
>>NF Stevens <[EMAIL PROTECTED]> wrote:
>>>[EMAIL PROTECTED] (Nathan Myers) wrote:
>>>
>>>>If you don't know C++ templates, you don't know C++ at all. It is
>>>>templates, for example, that make it possible to write a C++ library
>>>>that does matrix operations as efficiently as specially-optimizing
>>>>Fortran on machines specifically designed to run Fortran well. Unlike
>>>>Fortran, though, C++ templates are not tuned specificially for matrix
>>>>math, so can be used to accomplish similar wonders in any area.
>>>
>>>I have to disagree with this. Templates do not in any way improve
>>>the efficiency of generated code. They are no faster (and no
>>>slower) than the equivalent hand written code. Templates only
>>>improve the efficiency of the programmer since only one (templated)
>>>version has to be coded rather than individual versions for each
>>>template class.
>>
>>C++ cannot of course be faster than the equivalent assembly
>>code, but the C++ compiler can optimize code better than you
>>can by hand in C, because it knows more about expressions than
>>you can tell the C compiler.
>
>That was not the point. I was comparing the code generated
>by instanciation of a template with hand written C++ code.
>The fact that templates expand to C++ code means that
>_templates_ cannot improve the efficiency of code.
What you are saying is clearly understandable, so much so
that some would say that it is intuitively obvious.
Well, intuition is often wrong. What you've done is
to present a rather mechanical equivalence and then left
things at that. But templates are more than just that.
Templates create a distinct family of relationships.
This is not just a cognitive conceptual statement, but
one with physical implications too.
- 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: Tom Wojciaczyk <[EMAIL PROTECTED]>
Subject: Re: How reset network card setting on the fly?
Date: Wed, 30 Jun 1999 15:41:31 -0400
ifdown eth0 ; ifup eth0
[EMAIL PROTECTED] wrote:
>
> I am using Red hat 6.0. If I change the network card settings
> in /etc/sysconfig/network-scripts/ifcfg-eth0 and, say, change the IP
> address. Is there anyway to make Linux reset my newly changed settings
> without rebooting?
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
--
=============================================================
:Tom Wojciaczyk, Network Engineer
:Cisco Systems, Inc.
:(804) 762-5535
------------------------------
From: Lyndon Hills <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup,linux.redhat.install
Subject: Re: Network unreachable on startup only!
Date: Wed, 30 Jun 1999 18:19:07 +0100
S P Arif Sahari Wibowo wrote:
>
> Hi!
>
> On startup, several commands involving routing gives this error:
>
> SIOCADDRT: Network is unreachable
>
> However, after the startup process over and I login as root, I can
> manually do all the routing command without error.
Maybe too obvious but these commands are not being executed before the
NIC is initialised are they?
I think I would try sticking some messages in the startup files to help
trace the flow of events, and also, do any of these other commands write
their errors to logs? I would have thought this would be a good place to
look. It would probably be valuable to know what is executed after the
attempt to use these commands, as presumably the commands are dependent
on some other process having completed.
HTH
Lyndon
------------------------------
** 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.networking) 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-Networking Digest
******************************
