[THIN] Re: Rebooting Win2k Terminal servers
- From: DMelczer@xxxxxxxx
- To: thin@xxxxxxxxxxxxx
- Date: Thu, 12 Jun 2003 11:08:28 -0400
Neil-
You say:
"There is nothing new under the sun, here.
Merely botched assertions that it's *all* down to either Microsoft, or their
OS. IMO, it's no more so, than for other countless vendors both before and
after them."
If you read my last comment the way it was intended, I agree with you
100%...both the OS vendor as well as the Application vendor can do better
jobs to provide stability.
MS OS and apps leak -- a valid assertion under certain conditions. Some do,
some don't.
Other OS and Vendor apps leak -- again, a valid assertion only under certain
circumstances. Some do, some don't.
However, combine the two and you've got an administrator's nightmare...and
this is in effect what the Windows OS and it's collection of apps has become
more often than not, in my opinion.
I don't think any of this is a "botched assertion" as you say...yes MS can
do some things better. Their ring structure for the NT4 kernel was
terrible...but look at Windows 2000, XP, or 2003...they've improved the code
as they should have done for their customers. And yes, vendors can also do
things better. When there's a problem, fix it. Again, take a look at HP --
they discovered their code crashed NT4 TS boxes. And, for the most part,
they've now fixed their older drivers to run under NT4, and all of their new
2000 drivers work fine from my experience.
Again, my point was simply that it isn't a Microsoft problem OR a vendor
problem. Rather, that it's BOTH simultaneously. Those who have experienced
more problems tend to become a little more jaded than the rest of us. I
still don't mind using MS products, even with their security risks and
occasional stability issues. They're better than anything else out there
right now (again, in my opinion only). Someone who's vendor won't cooperate
and whose software causes their NT4 Server to crash 5 times a day might
disagree with me. Again, que sera sera. Blame MS for not gracefully
trapping the errant code, or blame the vendor for the errant code. 6 of
one, half-dozen of the other.
And, just for the record, I'd also throw hardware vendors into the mix as
well. Sometimes (and I had this happen just recently with a vendor who will
remain nameless -- check the archives on TheThin.net if you're interested) a
poorly coded SCSI array bios crashes the box as well, even though the vendor
swears there is nothing wrong with their code. Upgrade the BIOS and the
problem goes away...hmmm...again, another stability issue not OS related
that could be avoided.
What it all boils down to is to debug your friggin' code. Regardless of
what you are developing for: hardware vendor, app vendor, or OS vendor. An
ounce of prevention is worth a pound of cure...isn't that the adage?
Okay, now I'm up to $0.04, and I wasn't even going to reply to this
thread...oh well. Glad my servers are stable for now (knock on wood) so I
have time to do this! ;-)
-Dave Melczer
dmelczer@xxxxxxxx
-----Original Message-----
From: Braebaum, Neil [mailto:Neil.Braebaum@xxxxxxxxxxxxxxxxx]
Sent: Thursday, June 12, 2003 10:52 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: Rebooting Win2k Terminal servers
Comments inline...
> -----Original Message-----
> From: DMelczer@xxxxxxxx [mailto:DMelczer@xxxxxxxx]
> Sent: 12 June 2003 15:33
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Rebooting Win2k Terminal servers
>
> Gotta chime in on this one...
>
> Quote:
> "Application issues, in general, shouldn't necessarily
> compromise the stability of the OS, though. That's why there
> is an OS."
>
> In a Utopian world, Neil, you're correct. In a well-coded
> OS, perhaps this is the case that third-party apps and
> drivers don't crash the OS. Windows, however, does not
> compartmentalize the apps and drivers as well as they should,
Rather unfair criticism, that.
As an OS, NT / W2K have the ring support like in any other real OS.
Certain types of things *have* to involve a certain degree of kernel
activity in some drivers.
There's little that can be done about that - but there are steps, as I
mentioned.
> and they do leave the OS vulnerable to poor third-party
> coding. How many times have you seen a poorly written driver
> or application BSOD a Microsoft box?
Therein lies the problem, though - these aren't necessarily OS faults, or OS
vendor issues, per se.
They are what can happen when ISVs write software that runs in rather
privileged areas of the OS.
> I've seen it too many
> times to count. Just take HP printer drivers on TS as a
> prime example of this...
Drivers on a platform they were probably not initially designed for (TS).
What do we recommend, if we think vendor drivers are causing the issue? Use
the OS supplied ones. QED.
And don't get me wrong, I'm not suggesting non of Microsoft's drivers or
code is without flaw - merely attributing blame where it should rightfully
be.
Have you ever encountered other OSs (say UNIX, for example) where stability
has been compromised by virtue of vendor code?
> But again, it's the fault of both parties as far as I'm
> concerned: Microsoft for not providing more of a restricted
> memory and access space for apps/drivers,
That really is a little harsh.
For user-mode drivers, if you truly had an issue where it crashed the OS.
For kernel mode drivers, you put your faith in the vendor - that's why
there's the digital certificate thing.
> and third-party
> developers for not taking time to properly debug their code.
That's hardly the fault of the OS vendor, though.
> And, just as a point of comparison, I have yet to crash my
> Linux box in 4 years of running it...I run a number of apps
> regularly on it, and reboot only when I recompile the kernel.
How many times have you changed the config, though. What sort of application
and user demands are there.
You see my point, I'm sure.
Cutting edge on *any* platform, tends towards the problematic. There's
nothing new under the sun, here, merely the pervasiveness of the OS and
vendor.
> I'm not advocating one OS or vendor over another, I just
> think both of you have valid points when viewed from another
> (albeit slightly skewed) perspective. Yes, some apps leak
> memory,
Some do, some don't.
Quite possibly some of Microsoft's do.
> and no Microsoft's OS's don't clean up after the apps
> properly on all occasions.
Neither would most other OSs - how would it know when and where to do so, if
the app didn't release it?
> That's life. Even the
> programmers are human and susceptible to errors. Sometimes
> the errors are just too deep-rooted to easily fix.
Indeed.
There is nothing new under the sun, here.
Merely botched assertions that it's *all* down to either Microsoft, or their
OS. IMO, it's no more so, than for other countless vendors both before and
after them.
Neil
***********************************************************************
This e-mail and its attachments are confidential and are intended for
the above named recipient only. If this has come to you in error,
please notify the sender immediately and delete this email from your
system. You must take no action based on this, nor must you copy or
disclose it or any part of its contents to any person or organisation.
Statements and opinions contained in this email may not necessarily
represent those of Littlewoods. Please note that email communications
may be monitored.
The registered office of Littlewoods Limited and its subsidiaries
is 100 Old Hall Street, Liverpool, L70 1AB.
Registered number of Littlewoods Limited is 262152
***********************************************************************
********************************************************
This weeks sponsor - Emergent Online 99Point9.com
Designed to facilitate efficient resolution of your technical server-based
questions, issues and incidents, technical support is a few mouse-clicks
away: you submit your incident-specific support requests via our online
support helpdesk, our certified engineers resolve them while you monitor the
progress, and your systems get back to 99.9% up-time in no time.
http://www.99point9.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
**********************************************************************
Please be advised that this transmittal may be a confidential attorney-client
communication or may otherwise be privileged or confidential. If you are not
the intended recipient, please do not read, copy or re-transmit this
communication. If you have received this communication in error, please notify
us by e-mail (postmaster@xxxxxxxx) or by telephone (call us collect at
212-403-4357) and delete this message and any attachments. Thank you in advance
for your cooperation and assistance.
www.wlrk.com
**********************************************************************
********************************************************
This weeks sponsor - Emergent Online 99Point9.com
Designed to facilitate efficient resolution of your technical server-based
questions, issues and incidents, technical support is a few mouse-clicks away:
you submit your incident-specific support requests via our online support
helpdesk, our certified engineers resolve them while you monitor the progress,
and your systems get back to 99.9% up-time in no time.
http://www.99point9.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
Other related posts:
