Linux-Advocacy Digest #997, Volume #29 Thu, 2 Nov 00 01:13:03 EST
Contents:
Re: Ms employees begging for food (Patrick Farrell)
Re: Ms employees begging for food (T. Max Devlin)
Re: A Microsoft exodus! ("Aaron R. Kulkis")
Re: Ms employees begging for food (T. Max Devlin)
Re: A Microsoft exodus! ("Erik Funkenbusch")
Re: Ms employees begging for food (Patrick Farrell)
Re: A Microsoft exodus! ("Erik Funkenbusch")
Re: A Microsoft exodus! ("Erik Funkenbusch")
Re: 2.4 Kernel Delays. ("Les Mikesell")
----------------------------------------------------------------------------
From: Patrick Farrell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy,comp.arch,comp.os.netware.misc
Subject: Re: Ms employees begging for food
Date: Wed, 01 Nov 2000 23:01:18 -0600
Reply-To: [EMAIL PROTECTED]
Gigabit Token Ring... Solution to the worlds problems ;>
Patrick
"T. Max Devlin" wrote:
>
> Said Peter da Silva in comp.os.linux.advocacy;
> >In article <[EMAIL PROTECTED]>,
> >T. Max Devlin <[EMAIL PROTECTED]> wrote:
> >> Said Peter da Silva in comp.os.linux.advocacy;
> >> >In article <[EMAIL PROTECTED]>,
> >> >T. Max Devlin <[EMAIL PROTECTED]> wrote:
> >> >> No, it is the results of my research and experience, which I'm going to
> >> >> have to point out is not limited to only examining the ethernet itself,
> >> >> but dealing with the "whole network".
> >
> >> >Even the crappy ethernets we built using thicknet segments and Intel's
> >> >crummy 911 repeater boxes between Xenix-286 systems and VAXes got better
> >> >than 1 Mbps throughput on a shared ethernet. I don't care what your
> >> >research and experience says, it's completely out of line with my
> >> >experience.
> >
> >> No, it is just out of scope with your context. The *ethernet* gets more
> >> than 1 Mbps *bandwidth utilization*. That isn't the same thing as
> >> throughput.
> >
> >I'm sorry, you seem to be using normal technical terms in some way that makes
> >no sense at all.
>
> No apology necessary. I'm aware of the problem. They make perfect
> sense, though its no surprise you're not familiar with the way I am
> using them. Please, feel free to ask me for a more explicit definition
> of any word which I'm using in a way you don't recognize clearly. I try
> to be as accurate, consistent, and practical as I can, and considering
> how rarely technical terms are used like that, its not rare at all that
> it becomes an issue.
>
> >With a 10 Mbps network, with two stations, I can get damn near 10 Mbps
> >throughput.
>
> Correct, so long as the entirety of the network which you must get
> things through is only that one Ethernet.
>
> >With many stations, I can get much more than 10% or 30% of
> >the aggregate throughput. Just what exactly is this thing you say that
> >you can only get 10% of out of Ethernet? And why should anyone care about
> >it?
>
> You say you can get much more than 10% or 30% aggregated throughput, but
> the issues is the non-aggregated throughput. It takes a CSMA/CD
> transmission channel (apart from the "point to point"
> thought-experiment) roughly ten times longer to get an arbitrary amount
> of data to the "other end" of the channel when the average utilization
> is at 30% than it does when the utilization is 10%.
>
> Anyone who wants to use the channel should care, and certainly anyone
> responsible for ensuring it can be used should care. I don't think the
> reasons are entirely non-obvious, though I will admit they are not the
> typical way that the technology is explained to people.
>
> >> The "30% rule", often misunderstood, apparently, is relevant to this
> >> idea. What the 30% rule really means is that every time you want to use
> >> the bandwidth of the ethernet (10 megabits, nominal) to support your
> >> demand, there is a 30% chance there might not be enough.
> >
> >That's a really unique interpretation of the 30% rule. First of all, that
> >would leave Ethernet 70% effective. Second, depending on the number
> >of hosts (and, more importantly, their duty cycle) that figure could be
> >anything from 1% to 99%...
>
> No, you misunderstand the whole thing, which is not a "unique", merely a
> correct, interpretation of the 30% rule. You have my sympathies if you
> are only now becoming aware that you didn't understand the 30% rule to
> begin with, but there's nothing I can really do about it, except point
> out that your understanding is, indeed, flawed. You have gotten so far,
> to your credit, to recognize that this atypical definition of the 30%
> rule does "leave Ethernet 70% effective". By this token, an Ethernet
> running at 10% utilization on average is 90% effective, and an Ethernet
> showing 70% utilization is only 30% effective. The relationship between
> demand and load, the logarithmic response curve I've been describing
> (this is all much easier when I have a whiteboard) which identifies how
> performance decreases exponentially as utilization increases linearly,
> which results in these numbers explains:
>
> a) Why I recommend "provisioning" Ethernets for 10% load on average,
> b) The 30% rule, indicating as a rule-of-thumb that Ethernets averaging
> over 30% should be partitioned, and
> c) Why Ethernet was "never intended" to be implemented so as to support
> greater than 50% bandwidth utilization of its 10 megabit transmission
> rate.
>
> Since you're talking about the aggregate utilization, it makes no
> difference whatsoever how many hosts you have or what kind of traffic
> patterns they show, unless you're going to pretend you can "interleave"
> frames efficiently on the channel by second-guessing individual
> transmissions. Yes, the utilization of an ethernet can be any figure
> from 1% to 99%, and as you correctly surmised, the efficiency of the
> ethernet (in supporting an individual stations demands) can be said to
> be the inverse percentage. Ergo, to use a channel which already has
> over 50% utilization is to be satisfied with a channel that has an
> efficiency of less than 50%.
>
> >> The most I'm willing to be comfortable
> >> with is a 10% chance that I won't have the bandwidth I need, because one
> >> or more of the other transceivers sharing the media might also expected
> >> they could use more than a small fraction of the bandwidth available in
> >> supporting their loads.
> >
> >How can you possibly come up with this figure? You could have a network
> >with mostly idle boxes that twice a day pump out 2 seconds of 100%
> >utilization, or you could have two other boxes on the net always using 400
> >megabytes per second between them. In the former case at any given time you
> >have almost 100% chance of getting 10 Mbps. In the latter, almost 0%.
>
> I come up with this figure for precisely these reasons. So that I don't
> have to try to second-guess what individual boxes are doing, and when
> they are doing it. All I have to do is double-check that utilization
> averages 10% (that figure could be for a week, an hour, or a minute,
> depending on your resources and tolerances) or less, and you'll never
> have to worry about the difference between 10 megabits at 2%
> utilization, and 10 megabits at 35% utilization in terms of whether they
> will provide the service required by whatever arbitrary node, host, or
> server which might be utilizing that Ethernet.
>
> >> Unless you've got fewer than 10 devices on a
> >> segment,
> >
> >Where does this "10 devices" come from?
>
> 100/10=10. To have the ability to ensure that each station has
> sufficient throughput, you do the "simple math" thing. Unless you
> understand how Ethernet works. You've gotten so far as to recognize the
> variance of traffic patterns and the impact it can have, but you've
> still not gotten to the point where you can do more than "divvy up the
> bandwidth". That's not the way CSMA/CD works.
>
> >I've had 2 devices on a segment use
> >100% of the bandwidth for their own use, and I've had 100 devices on a segment
> >doing mostly nothing most of the time. You *always* have to worry about
> >utlization... and you still have to do that with switched networks: it doesn't
> >matter if you have 3.2 Gbps aggregate bandwidth if it's all supposed to go
> >to and from one port.
>
> Why would you have to "worry about" utilization? It never goes over
> 100%, and that means you're getting your money's worth, right? You're
> trying to step over into the realm of provisioning, but the simple
> network model doesn't support provisioning on a complex network. You
> waste time trying to convince yourself, for no reason and with no
> results, that more bandwidth is the only way to improve things, but you
> haven't the information which would have provided the answer to the
> question "how much more bandwidth do you need" in a way which will
> convince the people who write the checks.
>
> You have to admit, there is a fundamental conflict in the standard
> industry knowledge about how networks work, when the goal seems to
> simultaneously to have as low a utilization as possible, as a sign of
> success in properly running the network, and as high a utilization as
> possible, which also proves the network is well run. Tell me, which is
> it?
>
> >And yes, you're better off if the average load is 30% than if it's 60%, or if
> >it's 10% than if it's 30%. And, yes, in that sense the 30% rule is a useful
> >guideline, but it doesn't mean what IBM claimed it mant and it doesn't mean
> >that Ethernet is overengineered: any network that uses a shared resource
> >instead of some intelligent packet routing mechanism is going to have the
> >same kind of limitation...
>
> You still don't understand what IBM pointed out (not "claimed"). It
> isn't that you are "worse off" at 60% than at 30%. Its that you are
> substantially more than twice as bad off at 60% than at 30%.
>
> >and it doesn't matter if it's ethernet or token
> >ring, you're not going to have as much point-to-point throughput if there's
> >contention for the bandwidth (yeh, you don't get a collision, but now you
> >have to sit back and twiddle your thumbs waiting for the token). And even
> >on a switched network, there are shared resources to contend with.
>
> Yes, but they don't have non-deterministic behavior as part of their
> very design because their channel arbitration scheme relies on a random
> interval to mitigate contention. It matters quite a bit if its a
> CSMA/CD Ethernet or a token ring or any other type of transmission
> channel technology. This also accounts for the point-to-point
> (including switched) scenarios you've been using. Only shared media
> mulit-station CSMA/CD Ethernet LANs exhibit this behavior.
>
> >And damn, you've taken an awful complex way to say that... and brought up a
> >lot of arguments that have absolutely nothing to do with the point, each of
> >which has lead to more noise and confusion.
>
> No doubt due to the fact that that wasn't what I was saying, and you are
> apparently unaware of the reality of the complex points I am making.
> What you mistake for you noise is simply your own confusion. No, it
> isn't simply a matter of a linear, or deterministic, relationship
> between response time and channel utilization, as you seem to believe.
>
> --
> 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: 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: Thu, 02 Nov 2000 00:15:43 -0500
Reply-To: [EMAIL PROTECTED]
Said Joe Doupnik in comp.os.linux.advocacy;
>>> More like, if you have 30% utilization, and you've got 3 stations
>>> transmitting equally, you will find the throughput of each to be 1 Mbps.
>>> But that would only hold true in this simplistic model you seem to be
>>> hung up on, which entirely ignores the reality of the logarithmic
>>> response curve which Ethernet exhibits. In the real world, if you had 3
>>> stations transmitting 1 megabit per second on average, your utilization
>>> would probably be well over 30%.
>----------
> In a word, no.
> This raving is costing lots of bandwidth. May I humbly suggest running
>those experiments to see first hand the true state of affairs. Try several
>simultaneous FTP streams amongst a collection of stations in the same
>collision domain. The wire is fully occupied, the throughput is rather evenly
>divided amongst transmitters, the aggregrate throughput is about 90% of total
>wire capacity. Borrow a hub and please give it a try; no model is involved.
I don't understand what this has to do with the quoted text. Did I say
an Ethernet could not "go" over 30% utilization?
> While the test runs flip throught the Boggs et al paper on Myths
>and Reality concerning Ethernet, location cited previously and a copy is
>also on netlab2.usu.edu in directory misc as file ethercap.zip, same file
>in pub/mirror/misc on netlab1.usu.edu.
Well, thank you for the link. I'll have to read it to find out where
the confusion is coming from. Consider while I do that, as it will be a
couple days before I will be back, this question:
How much "bandwidth" does each ftp session have when the aggregate
throughput is 90%?
I am not considering the LAN utilization in prescribing 10% bandwidth
guidelines. I'm concerned with how much service each station gets, not
how good the hub is doing.
--
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: "Aaron R. Kulkis" <[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: Thu, 02 Nov 2000 00:13:35 -0500
Ayende Rahien wrote:
>
> "Weevil" <[EMAIL PROTECTED]> wrote in message
> news:VyHL5.1544$[EMAIL PROTECTED]...
> >
> > Ayende Rahien <[EMAIL PROTECTED]> wrote in message
>
> > > How hard would it be to write something like this for unix/linux?
> > > If I understand the way those viruses worked, you open the attach file,
> it
> > > reads the adress book and sent it to the first 50 people there, right?
> > > Can't you do the same in unix? (I'm asking, not insulting. I want to
> know
> > > the answer.)
> >
> > It used to be a truism that you can't get a virus merely by reading your
> > email. Microsoft changed all that (to the shock of most
> security-conscious
> > observers) when they added Visual Basic macro capability to their email
> > program. Any of their apps which use such macros (e.g. Word) are
> obviously
> > vulnerable.
>
> I agrees, but I don't believe that this is the way that ILOVEU & Mellisa
> worked.
> IIRC, (and I may very well not), they needed the user to execute them.
> There *are* ways to make outlook run code just by viewing it (and just by
> selecting it too, I think) but I don't think that there was an actual virus
> that use this.
>
> > How hard would it be to write such a thing for unix/linux? Impossible, as
> > far as I'm aware. I'm no authority on everything that's available out
> there
> > for unix/linux, but I don't know of any email applications that blindly
> > execute attachments.
>
> If I recalled correctly, how hard would it be to create a virus that when a
> user execute it:
> A> Send itself to everyone in the user's adress book.
> B> Erase every file that the user has access too. (Not to hard I think,
> rm -rf /, isn't it?)
>
> Most of the damage from melissa & ILOVEU was that they erased user file, not
> the OS itself.
>
> > > > No, it's far easier to compromise closed source products, and one of
> the
> > > > main reasons is that customers do *not* have access to the source
> code.
> > >
> > > Actually, it's not easier, you can do it with OSS too, because I know
> that
> > a
> > > lot of people read the source, but use the binary unless they make some
> > > changes in the code.
> > >
> >
> > For those people, you're right. It is just as easy. But as I mentioned,
> > most source packages do not include binaries. Many OSS packages offer
> > alternative, binary-only packages, but if that is what you choose to
> > download, then the advantage of OSS is lost. You're in the same boat as
> > closed-source users.
>
> Compiling a source is an unneccecary hassale for most people. Most of them
> aren't programmers, they don't have anything to do with the source.
Let's see...you can settle for applications compiled for base-level
80386 machines OR you can run this EXTREMELY complicated command line...
$ make install
And sit back and watch the computer compile, link, and install a
custom-version tailed for your EXACT hardware.
Only a moron would prefer the former.
--
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: 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: Thu, 02 Nov 2000 00:18:53 -0500
Reply-To: [EMAIL PROTECTED]
Said Patrick Schaaf in comp.os.linux.advocacy;
>T. Max Devlin <[EMAIL PROTECTED]> writes:
>
>>It appears there are a number of people who work with Ethernet, but
>>don't really understand what it is about Ethernet that leads to a
>>"logarithmic response curve",
>
>When did you do your last Ethernet timestamped packet traces - and on
>which switch equipment? Can we see the traces?
A couple years ago, honestly. It was a Cisco switch, IIRC. No.
--
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: "Erik Funkenbusch" <[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: Wed, 1 Nov 2000 23:21:41 -0600
"Weevil" <[EMAIL PROTECTED]> wrote in message
news:r80M5.2717$[EMAIL PROTECTED]...
> Erik Funkenbusch <[EMAIL PROTECTED]> wrote in message
> news:hQTL5.5426$[EMAIL PROTECTED]...
> > <[EMAIL PROTECTED]> wrote in message
> > news:39ff63ae$1$yrgbherq$[EMAIL PROTECTED]...
> > > I don't know which vessel you are talking about, but the USS Yorktown
> was
> > dead
> > > in the water and towed into port -- and YES -- it was NT that crashed.
> >
> > Look, NT was as much at fault in the yorktown as the OS that was used in
> the
> > Arianne 5 was responsible for it's crash.
> >
> > > >Trust me, Linux/Unix applications have errors too.
> > >
> > > They haven't sunk and billion dollar vesselsand killed the crew --
which
> > is
> > > exactly what would have happened to the Yorktown in war time.
> >
> > The Yorktown is a non-combat vessel. But it's irrelevant since the
fault
> > was in the database software. The Database vendor even said that the
> > problem would have never happened if the navy had not been running a
beta
> > version of their software.
>
> I'm not familiar with the details of this case. Did NT crash or not? If
> so, then surely you're not blaming an application for it. If the OS
> crashes, it is the fault of the OS. A buggy application should have no
> effect on the OS, beyond perhaps keeping it busier than it should.
Something you might want to read is this:
http://www.jerrypournelle.com/reports/jerryp/Yorktown.html
No, NT did not crash. The "system" crashed, and specifically the database
was corrupted do to an application failure. This caused a domino effect
throughout the network, where systems that depended on valid data all
crashed because they had no data validation or exception handling.
Furthermore, the Yorktown was expected to fail, since it was an "X" project.
It was taken out to shake it down and find out where the faults were. The
basic idea of an "X" project is that if it doesn't fail, you're not testing
it hard enough.
------------------------------
From: Patrick Farrell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy,comp.arch,comp.os.netware.misc
Subject: Re: Ms employees begging for food
Date: Wed, 01 Nov 2000 23:13:28 -0600
Reply-To: [EMAIL PROTECTED]
Of course the trick question to ask people is which layer does TCP/IP reside in
the OSI model. :)
Patrick
Peter da Silva wrote:
>
> "Layer 3 switching" is simply a performance hack to speed up routing in the
> common case. If it's at layer 3, it's routing. I agree the terminology is
> stupid. That doesn't mean the hack isn't useful or that it doesn't work most
> of the time.
>
> --
> `-_-' In hoc signo hack, Peter da Silva.
> 'U` "Milloin halasit viimeksi suttasi?"
>
> Disclaimer: WWFD?
------------------------------
From: "Erik Funkenbusch" <[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: Wed, 1 Nov 2000 23:25:29 -0600
<[EMAIL PROTECTED]> wrote in message
news:3a00b948$4$yrgbherq$[EMAIL PROTECTED]...
> >> The Yorktown is a non-combat vessel. But it's irrelevant since the
fault
> >> was in the database software. The Database vendor even said that the
> >> problem would have never happened if the navy had not been running a
beta
> >> version of their software.
>
> >I'm not familiar with the details of this case. Did NT crash or not? If
so,
> >then surely you're not blaming an application for it. If the OS crashes,
it
> >is the fault of the OS. A buggy application should have no effect on the
OS,
> >beyond perhaps keeping it busier than it should.
>
>
> NT not only crashed, but Erik M$. Funkenbusch is such a complete
nincompoop
> that he thinks a guided missile cruiser is a "non-combat vessel."
No, the Yorktown was taken out of combat to be an experimental prototype.
While it's indeed a guided missle class (specifically Ticonderoga or Aegis
class) cruiser, it's job is a non-combat one, since it is expected to fail.
------------------------------
From: "Erik Funkenbusch" <[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: Wed, 1 Nov 2000 23:28:26 -0600
<[EMAIL PROTECTED]> wrote in message
news:3a00b5cf$3$yrgbherq$[EMAIL PROTECTED]...
> >Look, NT was as much at fault in the yorktown as the OS that was used in
the
> >Arianne 5 was responsible for it's crash.
>
> REALLY! I'm sure this is going to be good --- And the reason the database
> kept the crew from restarting NT and get underway was?
Can't use your brain can you? Once the tech entered the data into the
database, applications all over the ship started crashing as they performed
illegal calculations. When the applications were restarted, the first thing
they do is read the data out of the database, causing it to crash again.
The only way to fix the problem is to fix the database, and without the
application to enter the data into, it has to be done by hand.
------------------------------
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: Thu, 02 Nov 2000 05:33:42 GMT
"Chad Mulligan" <[EMAIL PROTECTED]> wrote in message
news:Si5M5.17296$[EMAIL PROTECTED]...
> >
> > No new software installed? No IE update? What was the machine
> > doing. The one I posted was a busy webserver. Before sp6a I
> > couldn't keep an NT box running more than a month or so at a time
> > even when I wasn't forced to reboot for some simple change.
> >
>
> This was a server running NTLM, IIS and it sat and span on it's own. Even
> though many software installs request a restart most often they will run
> fine without it. Being a server it didn't need IE updated. IIS Can be
> restarted without stopping the system. As a newbie on NT Server in 1995 I
> restarted often, once I started to understand the system, restarts become
> less and less often.
You were right to reboot at the first hint of trouble back then. Before
service pack 3 NT was so unstable as to be mostly unusable. It has
gotten better to the point that after sp6 even I have to admit that it
isn't likely to crash unexpectedly any more unless triggered by hardware
problems. But how much trouble have people had to deal with to
get to that point? And it is still annoying to have to reboot just to
change a machine's name.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
** 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
******************************
