Linux-Advocacy Digest #42, Volume #30 Sat, 4 Nov 00 16:13:03 EST
Contents:
Re: Ms employees begging for food (T. Max Devlin)
Re: 2.4 Kernel Delays. ("Les Mikesell")
Re: 2.4 Kernel Delays. ("Bruce Schuck")
Re: so REALLY, what's the matter with Microsoft? ("Bruce Schuck")
Re: Tuff Competition for LINUX! ("Chad Mulligan")
Re: A Microsoft exodus! (gm)
----------------------------------------------------------------------------
From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy,comp.arch,comp.os.netware.misc
Subject: Re: Ms employees begging for food
Date: Sat, 04 Nov 2000 15:54:00 -0500
Reply-To: [EMAIL PROTECTED]
Said Weevil in comp.os.linux.advocacy;
[...continuing from a previous response...]
>I need make no presumptions about the existence of anyone, anywhere, in
>order to open a socket.
Thus the presumption that you are making. ;-)
>I just open the socket. Simple. Whether a
>connection will be made at some later time need not be known. Actually,
>since programs are not psychic, it is impossible to know whether the socket
>will ever be used in a connection.
This is, as I've said before, why you cannot treat sockets like files
when you open them. The socket *may* be used in a connection, and since
programs are not psychic, you presume they will be used (potentially, by
anyone, anywhere) when you open them, or you are merely "pretending" to
open them. Either you are taking the abstraction of sockets in
programming too seriously, or not seriously enough.
I'm interest in figuring out if there might be some "need to know", not
for any specific purpose, but to, instead, avoid problems which might
occur when the programmer starts thinking that whether or not a socket
actually provides any services ("a connection") is somehow not
important, and need not be considered when using (programming) sockets.
>The same is true of a file, as I mentioned above. Neither I nor my program
>necessarily "knows" whether a file that I create/open will actually be used,
>but that doesn't prevent me from opening it, and it doesn't prevent the file
>from existing.
The file is local, and therefore under the complete control, ostensibly,
of the local system. A socket is, supposedly, a connection to something
outside the scope, control, and authority of the local system, or the
local system programmer.
>> But since you have to establish a reference for a
>> non-local resource (the other end, and data coming from or going to
>> there) in order to "open" a socket, once that's done, it doesn't matter
>> if there is another end, let alone whether somebody is there.
>
>You are definitely confused, here. You can, and very often do, "open" a
>socket without having any reference at all about the "other end". This is
>how servers work. A socket is opened, and the protocol driver is told that
>this socket wants to listen for incoming connections on a particular port.
>That's it. There is no guarantee that there will ever be a connection, and
>if there is one, there is no requirement that it be "non-local."
No, I am not confused, though I can understand why you would think so.
The question is not whether there is any guarantee there will be data
passed through the socket or requirement that it be foreign. The
question is whether it might be used, and whether there is a requirement
that it be local.
In the context and terminology I have been using, considering the
example you have used, the server listening at a port *is* a connection.
On the "other side" is, as I mentioned before, "anyone and everyone".
At least in some regards. More accurately, however, if not more
practically, the confusion arises from your presumption, because you
only control one "side" of the socket, that it only has one side.
Similarly, you are making a presumption that, I say with some
trepidation, you are falling into a common trap which often confuses
programmers, whether they recognize it or not. That "conceptual glitch"
is the assumption that programming abstractions are somehow transcendent
and superior to all other abstractions.
In this regard, it might be helpful for us to know whether programming
sockets were named for networking sockets, or whether networking sockets
got their name from programming sockets. Unfortunately, I have no
information in this regard. But I would suspect that since network
sockets work very consistently, in terms of other networking concepts,
but programming sockets have the seemingly incongruous behavior, since
you can't open them like files, but once they're opened you can treat
them like files, that the skew is on the programming side. What you
think of as "a socket" is just the function or abstraction you use to
work with sockets. A socket is the connection between two network
entities, identified by the designation of the IP and port number on
*both* ends, though only one end might be mentioned in a particular
context.
But, of course, none of this could possibly make sense unless we are
clear on the abstract nature of the terms "end" and "connection".
[...]
>All this abstraction and philosophical pondering is really not necessary.
It might not seem necessary to you, but all you have to do is write the
software. The failure of that software to function robustly, reliably,
and scalably is often blamed on "the network", and so this pondering
might not be necessary, but is certainly helpful. Or so I would
presume, based on the number of network problems I'm able to resolve
using this type of approach.
>When a web server and a browser are "connected," all that really happens is
>that the web server has a bit of memory dedicated to that particular client
>(includes his IP address, communication port, and depending on how the
>server is configured, perhaps lots of other identifying stuff, as well as
>the local socket that is handling the connection).
Which is to say that web servers and browsers are never "connected";
they are just currently engaged in swapping data. How the server is
configured, by the way, whatever that means, has no impact on these
things; there is no "other identifying stuff".
>On the browser's end,
>pretty much the same thing takes place. When the connection is ended (by
>any of a number of mechanisms), this bit of memory is "returned" to the
>system to be used for something else (possibly another connection).
But there never was a connection, so how can it be ended? Does a
"connection" between client and server actually exist, or is it merely
an abstraction?
>I don't think the concept of a connection is meaningful below the
>application level, and I'm sure nothing below the transport layer cares
>about it.
Each level, properly understood, has its own way of not having a
connection. I can't be sure what you mean by "the application level",
since "application" is a layer, not a level, and it is grossly
misunderstood by almost everyone who uses the concept, to be honest. In
my method, I define the application layer as "how you identify data for
transfer", which is much more accurate, consistent, and practical in
modern networks than the archaic, telecom-oriented classical OSI
definition, "the user interface". The "user interface" they were
talking about at the time translates to "service" in computing terms,
and ultimately the only service that a network system can provide is
transfer of data.
Nevertheless, presuming you meant "the level of the application
software", you are correct; the concept of a connection isn't
"meaningful" to the logical or software network in the same way it is
thought to be meaningful at the "upper layers". Specifically, what you
regard as "a connection" is "a persistent connection", the somewhat
redundant phrase being used to indicate that there aren't really even
any connections at this level. As I pointed out, the browser doesn't
really have a "connection" to the web server. If, in fact, a server had
to "keep track" of all the countless browsers that are "connected" to it
(currently showing a page retrieved from that server, essentially), the
World Wide Web simply wouldn't work. It is the connectionless nature of
the network (including the software level of connectivity, client and
server, which are no less part of the network than some intermediate
transmission channel is) which allows the scalability and flexibility
which makes the Internet possible as a practical solution.
So this "persistent connection" is most commonly identified as a login,
of some type. This might, depending on how you look at it, extend to
the use of cookies and other tricks to support the illusion of a
connection to a web server. As a programmer, I'm sure you envision FTP
as having a "real" connection, but that's only because you are overly
concerned about "bits of memory", use of local resources to keep track
of the mirage-like "connection". But how can you have a connection
between two computers when the network interconnecting them is
connectionless? The connection of an FTP client to an FTP server is
almost as illusory as the web browser's, or DNS', or any other modern
software system. It is an abstraction; there are no network resources
"set aside" for the communications, regardless of whether the software
on the server can produce a list of all the "currently logged in"
clients.
The "persistent connection" is provided by the Session layer of the OSI
model, and the Presentation layer (another abstraction which I know
programmers have a radically different perspective of than everyone
else) identifies the organized datagrams which are sent back and forth
between the software systems. These datagrams, which define the login
process, if any, the logout process, if any, as well as any "protocol
exchange" routines which allow the request for services and deliver the
fulfillment by transferring data. The application layer doesn't really
deal with "connections" at all.
>The TCP/IP stack adds "to" and "from" type headers to every
>outgoing packet. It wouldn't need to do this if a "connection" were
>something real.
This is why they're called "virtual connections", when the need for
accuracy is large. Not to be confused with "virtual circuits" (though
similar in the abstract), the virtual connections are provided
exclusively by the Transport layer. The TCP/IP stack adds several
levels of "to" and "from" addresses. On the transport layer, these are
known as "sockets"; the concatenation of the source IP and source port,
and destination IP and destination port. Pairing them together allows
for the abstraction of a "connection", in the same way that identifying
the transmitter and receiver on an Ethernet does.
To get back to your server example, just as on Ethernet, it isn't so
much a question of not being connected to anything, but rather of being
connected to anything. I think you might be confusing the idea of
something being on the other side, with knowing what it is that is on
the other side. The "connection", entirely virtual and even abstract as
it is, exists when the server listens on the port. Whether any
*transactions* (logins, what you think of as "a connection" because data
is traveling back and forth) occur is an entirely different matter. But
as soon as you "open a socket", you are theoretically, at least,
establishing a connection, or at least making one available, should
someone choose to use it to send a request to the server.
>> >TCP/IP is not necessary for sockets to exist. They may use other
>protocols
>> >as well. (Not sure about Windows sockets -- they used to only use TCP/IP
>> >and UDP/IP. This may have changed.)
>>
>> TCP/IP may not be necessary for the *concept* of sockets to exist. But
>> the ones we're (or at least I am) referring to are TCP/IP sockets. They
>> *could* use other protocols, but I'm not interested in thought
>> experiments. Not practical enough to be worth examining for accuracy or
>> consistency, as neither is a hallmark of thought experiments.
>
>Do you use RealPlayer? It doesn't use TCP. Streaming video and audio use a
>connectionless protocol -- UDP. And they all use sockets.
Was there something I said that seemed to contradict this? Yes, all IP
communications use sockets. A socket is the transport-layer
identification of the *lack* of a connection. And in the end, TCP is
every bit as "connectionless" as UDP. It just supports fragmentation
and reassembly, and windowing and acknowledgements. These don't make it
a connection; these are part of TCP specifically because, in fact, there
is not a connection. These mechanisms are necessary to get along
without one.
>To a UDP socket, there is no such thing as a connection. When you send
>something using UDP, you just sort of blast it out there with no guarantee
>that the recipient will ever see it.
It isn't the guarantee of whether the recipient will ever see it (you
don't have that with TCP, either, and a smart programmer should never
take it for granted, even when using the "connection-oriented"
alternative for IP's transport layer) that makes the difference; it is
whether you get an acknowledgement it was received by the
transport-layer software on the other side. This doesn't indicate that
it got anywhere past the session layer, by itself. With UDP, the
verification that the transfer of data was successful is dealt with by
the session layer software, is all, instead of the transport layer
"network".
Again, there is no such thing as a connection with TCP, any more than
there is with UDP. TCP does, however, support virtual connections much
more completely by providing these reliability features. To the
network, however, there is no difference between a UDP socket and a TCP
socket. As a programmer, you decide to use one or the other based on
your desires, requirements, and limitations (most prevalent of which is
whether the other side supports your desired service using a particular
transport protocol), and program your software to behave accordingly.
Sometimes you want the "network software", the TCP/IP stack, to handle
acks and resends. Sometimes, it makes more sense to handle that
directly. Notable examples are Real Player (as you mentioned), DNS, and
SNMP. With Real, the demands of streaming require more optimized
handling than TCP can provide. With DNS, the trivial nature of the
exchange and the scalability required make TCP needless overhead. With
SNMP, relying on the network to be either efficient or effective makes
no sense at all, since you are using SNMP to manage that network, and
assuming that the network is working well enough to transfer your data
is somewhat self-defeating.
>Also, you can get incoming data from
>anyone at any time, and since there are no connections, all the data packets
>will be treated as equally valid and important by the protocol stack (this
>is what makes it possible to "hijack" cu-seeme connections, for example).
Which is to say, taking the abstraction from a different perspective,
that, since you can get incoming data from anyone at any time, you are
connected to everyone all the time. I can't help but suspect that
software written with this perspective in mind might be slightly more
reliable and stable than software which pretends that a complex network
is nothing more than a single huge transmission system. I find the
abstraction of the "levels of connectivity" immensely useful in dealing
with these issues. The term 'data packet' is ambiguous, a relic of the
old, simplex model of networking. In the new paradigm, you have frames,
packets, and datagrams, and although each becomes encapsulated in the
previous, nothing ever deals with more than one of them at a time. To
the "protocol stack", you have datagrams from the software connection
being fragmented and encapsulated in packets. To the stack, the packets
don't contain datagrams, or even fragments, conceptually. Packets
contain a _data field_ which contains an arbitrary series of ones and
zeros. The meaning and importance of this binary data is, you are
correct, irrelevant to the TCP/IP protocols. In precisely the same way,
the packet becomes a string of bits making up the content of the data
field in the frame or cell which handles the actual transmission.
[...]
>I think we're speaking from very different perspectives, here.
Undoubtedly. Isn't it fun?
>I'm speaking
>from a programmer's perspective, and I presume that you're speaking from a
>more abstract, network guy perspective.
It is, I'm afraid to say, quite revealing that you think of the "network
guy" perspective as somehow more abstract. In the end, it is simply a
different abstraction than what you are used to. Its certainly not
surprising that you would consider what you are used to as less abstract
and more meaningful, because it is, indeed, less abstract and more
meaningful to you.
>I'm familiar with the software nuts
>and bolts. You're apparently familiar with areas in networking I have no
>experience with.
I have a great deal of expertise in networking; I am merely familiar
with software nuts and bolts. To me, they're all abstractions, equally
useful and equally problematic. Also, equally and easily explainable,
so that one can understand the mechanism and concepts without having to
be an expert in every detail of everything, when you use the right
explanatory model.
>We don't seem to be using the same words to mean the same thing.
Quite true. You are using the words to mean precisely what you are used
to having them mean within your particularly specialty. Unfortunately,
I do not have the luxury of restricting my use of these words to a
single specialty, so I have had to develop a method for determining the
most precise, common, useful meaning, regardless of who is using the
word, or in what context it is being used. It ain't easy, let me tell
you. Trying to maintain a single, universal vocabulary of accurate,
consistent, and practical networking terms is something I'm used to
getting a lot of flack for. It often earns me the designation
"pedantic", "arrogant", and even "clueless". The more specialized the
person, the more readily they discount my efforts, because the less
concern they have for whether anyone else is confused, and the more
supercilious their attitude concerning how important their specialty is,
in contrast to everything else.
I don't mean to sound like I'm knocking you or your statements, Weevil.
I know you're a reasonable person, and I hope you realize that I'm not
trying to insult you. I'm just being honest about my observations and
understanding. The word "socket" obviously isn't used precisely the
same by everyone. But in this regard, it is no different than:
Connection
Interface
Server
Domain
Network
or any number of other networking terms. These words do, however, have
common meaning. By recognizing that it is the common meaning which is
the important one, and the specialized usage should not be considered
exclusive by any means (making phrases like "that's not a [x],
because..." counter-productive.)
So, now that I've finished babbling, for the moment at least, tell me:
if a socket isn't a connection between two transport-layer entities used
to identify support for zero or more persistent sessions (but distinct
from the session, just as it is independent of the routing path along
which the packets are non-deterministically forwarded), what is it?
Some sockets might not "go through" routers, or might not support
sessions, but these exceptions are not what should guide your
characterization of these abstract things called sockets. It seems it
would be far more effective to understand their true nature, rather than
get caught up in the abstractions used to describe that nature. And the
true nature of a socket is a transport-layer virtual connection (or lack
of one; it makes no difference since it is from/to, not an abstract
connection identifier, which defines a socket). Not the function used
to cause the program to listen on or use a particular port; that just
happens to use the same word. With the proper conceptual understanding,
we can see that the use of the term socket in your context is not simply
a coincidence, certainly. But the fact that you learned the term as a
programming command does not mean that this context has some prevailing
claim to the concept itself. At least not anywhere outside your "local
system". It might take months, even years, for your brain to "hear" the
term socket and not think of telling a server to listen on a port. But
the reason the term socket is used for that is because, by listening on
the port, the server is essentially, if abstractly, establishing a
connection, or at least utilizing non-local resources. When and if you
come to that point, perhaps your perspective will be general enough to
recognize my claim that the reason you can't open a socket like you open
a file is because network resources, including abstract things that
don't, by themselves, even take up "bandwidth" or require processing by
routers, are outside the control of the local software. You think of it
as "opening a socket", but the more practical perspective is that you
are "requesting a socket be established." This has ramifications
outside your particular application, so it should not be done in the
same cavalier fashion that you would open a local file.
--
T. Max Devlin
*** The best way to convince another is
to state your case moderately and
accurately. - Benjamin Franklin ***
======USENET VIRUS=======COPY THE URL BELOW TO YOUR SIG==============
Sign the petition and keep Deja's archive alive!
http://www2.PetitionOnline.com/dejanews/petition.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Les Mikesell" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy,comp.os.ms-windows.advocacy
Subject: Re: 2.4 Kernel Delays.
Date: Sat, 04 Nov 2000 20:51:53 GMT
"Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
news:8u1u5s$a81$[EMAIL PROTECTED]...
>
> "Les Mikesell" <[EMAIL PROTECTED]> wrote in message
> news:6qZM5.13022$[EMAIL PROTECTED]...
> >
> > "Bruce Schuck" <[EMAIL PROTECTED]> wrote in message
> > news:lCXM5.122690$[EMAIL PROTECTED]...
> > >
> > > > Of course you can. The question is how it performs compared to
> > > > apache/mod_perl
> > >
> > > I'm more than willing to look at some benchmarks. Do you have any?
> >
> > I'll be happy to do some timing if someone can show me how
> > to make IIS run my perl code. Is perl included in win2k or
> > do you have to use third party code? Does it run in-process
> > or separately. Does it all have to be thread-safe?
>
> www.activeperl.com should be able to answer your questions.
> MS ship it as part of Win2k resource kit, btw.
I assume you mean www.activestate.com? It is extremely
unusual for Microsoft to allow anything that can be used
portably to be associated with their products in any way.
I hope this is a refreshing change in policy but I'll refrain
from believing it until I see some code working.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: "Bruce Schuck" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy,comp.os.ms-windows.advocacy
Subject: Re: 2.4 Kernel Delays.
Date: Sat, 4 Nov 2000 12:56:33 -0800
"Perry Pip" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 4 Nov 2000 09:25:15 -0800,
> Bruce Schuck <[EMAIL PROTECTED]> wrote:
> >
> >"Les Mikesell" <[EMAIL PROTECTED]> wrote in message
> >news:%SNM5.12955$[EMAIL PROTECTED]...
> >>
> >> "Bruce Schuck" <[EMAIL PROTECTED]> wrote in message
> >> news:dFNM5.121778$[EMAIL PROTECTED]...
> >> >
> >> > > > They tested the best capabilities of all systems.
> >> > >
> >> > > Did I miss the php and mod_perl timings?
> >> > >
> >> > > > It's well known fact that IIS 5 on Win2K kicks ass on dynamic
> >content.
> >> > > >
> >> > > > If you have alternative benchmarks post them.
> >> > >
> >> > > Why would I have any IIS timings? I would be interested if
anyone
> >> > > has equivalent perl code running under IIS and apache/mod_perl,
> >though.
> >> >
> >> > That is the beauty of IIS. You can write you ISAPI filters in many
> >> > languages, including Perl.
> >>
> >> Of course you can. The question is how it performs compared to
> >> apache/mod_perl
> >
> >I'm more than willing to look at some benchmarks. Do you have any?
> >
> >> and whether you have to write thread-safe
> >> code in a thread-safe language (which in my experience takes
> >> about 15 years longer than when you don't) to make it work.
> >
> >IIS works just fine. And fast too. Kicks Linux and Solaris ass
> >
>
> And it's not nearly as stable. When you use threads to handle network
> requests, one bad thread crashes all of them, and all your clients are
> cut off.
IIS 5.0 offers improved protection and increased reliability for Web
applications. By default, IIS runs all applications in a common or pooled
process that is separate from core IIS processes. In addition,
administrators can still isolate mission-critical applications that should
be run outside of both core IIS and pooled processes.
> When you use multiple process, then you only lose the one
> request.
And it is slooowwww.
>
> Furthemore, in an environment like NT, you have to reboot in order to
> be sure the OS recovered all the resouces from the crashed apps.
Not with IIS 5.0
------------------------------
From: "Bruce Schuck" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: so REALLY, what's the matter with Microsoft?
Date: Sat, 4 Nov 2000 12:57:16 -0800
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 04 Nov 2000 08:09:36 -0500, mlw <[EMAIL PROTECTED]> wrote:
> >Bruce Schuck wrote:
> >
> [deletia]
> >> > >
> >> > > When Linux starts supplying drivers for even 1/100th of the
hardware
> >> windows
> >> > > supports I'll be amazed.
>
> In what area exactly does Linux support only one device out of
> 100 when compared to WinDOS. Please provide actual details.
You are right. I may have overestimated.
------------------------------
Reply-To: "Chad Mulligan" <[EMAIL PROTECTED]>
From: "Chad Mulligan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy,comp.os.ms-windows.advocacy
Subject: Re: Tuff Competition for LINUX!
Date: Sat, 04 Nov 2000 21:06:35 GMT
Aaron R. Kulkis <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Bruce Schuck wrote:
> >
> > "Aaron R. Kulkis" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Ayende Rahien wrote:
> > > >
> > > > Well, for a start, they are going to have unaffected copies of the
> > source
> > > > code, remember?
> > > > They've change logs.
> > > > They can simply run a doc compar of the code and check only the
portions
> > of
> > > > it that changed.
> > > > Please, this "we can never trust MS s/w now" is total bull!
> > >
> > > In absence of any information ...
> >
> > You are the Crown Prince of "Absence of Information".
>
> I bow down before the, oh KING of "Absence of Information"
>
> >
> > And death threats.
>
> Hey...at least *I* can carry them out.
>
> Care to duel at 500 yards?
>
What are you going to hit him with? Your Sig perchance?
>
> >
> > And sleeping on the job.
>
> My shit works....therefore, it's not an issue.
>
>
>
>
> >
> > And fabricated Ford/GM/Chrysler Dealerships in Detroit.
>
>
> --
> Aaron R. Kulkis
> Unix Systems Engineer
> ICQ # 3056642
>
> http://directedfire.com/greatgungiveaway/directedfire.referrer.fcgi?2632
>
>
> H: "Having found not one single carbon monoxide leak on the entire
> premises, it is my belief, and Willard concurs, that the reason
> you folks feel listless and disoriented is simply because
> you are lazy, stupid people"
>
> I: Loren Petrich's 2-week stubborn refusal to respond to the
> challenge to describe even one philosophical difference
> between himself and the communists demonstrates that, in fact,
> Loren Petrich is a COMMUNIST ***hole
>
> J: Other knee_jerk reactionaries: billh, david casey, redc1c4,
> The retarded sisters: Raunchy (rauni) and Anencephielle (Enielle),
> also known as old hags who've hit the wall....
>
> A: The wise man is mocked by fools.
>
> B: Jet Silverman plays the fool and spews out nonsense as a
> method of sidetracking discussions which are headed in a
> direction that she doesn't like.
>
> C: Jet Silverman claims to have killfiled me.
>
> D: Jet Silverman now follows me from newgroup to newsgroup
> ...despite (C) above.
>
> E: Jet is not worthy of the time to compose a response until
> her behavior improves.
>
> F: Unit_4's "Kook hunt" reminds me of "Jimmy Baker's" harangues against
> adultery while concurrently committing adultery with Tammy Hahn.
>
> G: Knackos...you're a retard.
------------------------------
From: gm <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.ms-windows.advocacy,comp.sys.mac.advocacy,comp.os.os2.advocacy,comp.unix.advocacy
Subject: Re: A Microsoft exodus!
Date: Sat, 04 Nov 2000 21:07:37 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
<snip>
> >> Potenitally, yes. But provided you run an up to date system, those are
> >> most likely plugged.
> >
> >Ditto for Win2K.
>
> ...assuming you aren't accepting email attachements from anyone.
Gee, I've been accepting email attachments for a LONG time on my
NT system and I've had no problems because:
1) I do NOT run as Administrator unless absolutely necessary.
2) My email program doesn't automatically run or open attachments
3) I run an updated AV program
------------------------------
** 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.advocacy) 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-Advocacy Digest
******************************
