Advantages of going XP64

On Mon, 24 Jan 2005 23:29:13 -0500, "Carlo Razzeto"
wrote:


"Randy Howard" wrote in message
. ..
In article ,
says...
My copy of Windows XP has been running for months (about 6) with out any
real issues...

There is a big difference between "running" and "being used". I refer
specifically to the difference in having a computer for email, usenet,
web browsing, etc. and using one for production, mission critical work
and it not spending 18 of its 24 hours each day turned off or in the
screen saver.


My parent's actually don't know where the "off" button is... There for it's
up time is VERY similar to the length of time the OS has been installed
(excluding reboots for updates I did). So I'd say it was a very successful
install of Windows.... Beyond that, please describe "mission critical". I
find most servers really arn't all that busy most of the time... The
equivilant of being in screen saver mode... With the possible exception of
Database servers.


Thanks for helping me. :-)

This was more of a "Windows is not all that unstable" thingl.


in some ways it's quite a bit more robust then Linux (see driver
development!!)

You better explain that one. I've found far, far fewer device drivers
of low quality on Linux than I have on Windows. Ubiquitous driver
availability != quality. The fact that you can find a driver for some
rare gizmo that only 14 people ever bought for Windows but not for
Linux bears no relevance to the robustness of drivers. The fact that
some vendors do not devote their limited resources to providing drivers
for any platform other than windows also does not mean that Linux
drivers are not robust. The vendor is at fault for not providing
support for the fastest growing OS platform.

while(true) int a = 1;
Death of of Linux box (code runs in driver).

Because no windows driver code lives in the kernel literally or figertativly
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
it won't be *as* suseptable to such things (though there are other ways to
break the kernel). I'm not saying it's impossible to write a bad windows
driver that will kill the system. I'm just saying it's harder!

Having developed kernel components and device drivers in excess of
twenty years. I can attest that you're smoking something.

Windows NT, W2K, and XP has every kernel vulnerability Linux has,
and then adds a whole lot of extras. A rouge DMA operation is just as
deadly, same goes for rouge pointers, forget to clear an interrupt,
etc. This effect is magnified because windows has large numbers of
poorly documented kernel support routines, many with un-predicatible
behavior and interactions.

Linux has far less subroutine pollution to deal with, and far
fewer black box effects. Each Linux driver developer has full access
to all the surrounding kernel source code. (no such luck in Win
XXX).

Additionally windows suffers from poor divisional structure. Flaws
like dragging the video drivers into the kernel starting with NT 4.0,
etc .

Overall O/S's reliability is a function of all kernel components
and hardware working together to function in a consistent manor The
greater the number of active components, the higher the probability of
failure. Add in sketchy Win XXX documentation and you have a
receipt for BSOD's at the drop of a hat.


As the SCO bites the dust.. Hopefully, IBM can place on tombstone
on that grave sooner rather than later.. One can expect any remaining
Unix device driver writers to shift their full time efforts towards
Linux. Tack on some funding and Mickysoft won't stand a chance.

On Tue, 25 Jan 2005 09:14:39 -0600, M. Bezzel wrote:



Wes, I need some info. What benchmarking/temp monitoring software do
you use in linux? I am a total noob with linux but I need to build some
cheap systems for web browsing, email etc., and I would like to burn them
in. I have a few Biostar m7ncg 400 boards and installed suse 9.1 personal
on one of them last night. It works great and I am very impressed with the
suse package, but I am quite lost when it comes to installing/finding
programs. Also I have a JIUHB 1700+ and would like to OC it and test it in
linux. I see prime95 is available but temp monitoring is what I'm after.
Remember, I'm a noooob. Also If you could point me to a good noob tutorial
that would be great. Thanks man, you're the best.

Don't know anything about suse. Suggest you try the suse newsgroup for
support on it specifically. As far temp monitoring, the basic package is
lm_sensors. That will rpovide the basic text ouput like;
[wes@wes2 wes]$ sensors
it87-isa-0290
Adapter: ISA adapter
VCore 1: +1.28 V (min = +1.12 V, max = +1.79 V)
VCore 2: +1.52 V (min = +1.41 V, max = +1.70 V)
+3.3V: +3.25 V (min = +2.98 V, max = +3.63 V)
+5V: +4.97 V (min = +4.49 V, max = +5.51 V)
+12V: +11.84 V (min = +10.82 V, max = +13.18 V)
-12V: -11.40 V (min = -10.83 V, max = -13.19 V)
-5V: -4.97 V (min = -4.54 V, max = -5.47 V)
Stdby: +5.03 V (min = +4.49 V, max = +5.51 V)
VBat: +3.15 V
fan1: 2343 RPM (min = 0 RPM, div = 8)
fan2: 0 RPM (min = 0 RPM, div = 8)
fan3: 0 RPM (min = 0 RPM, div = 8)
CPU Temp: +32°C (low = +15°C, high = +55°C) sensor = diode
M/B Temp: +28°C (low = +15°C, high = +40°C) sensor = thermistor

For a graphical monitor I use gkrellm. To load the cpu I use burnK7. To
test the system I use memtest. To overclock your 1700+ raise FSB and vcore
as desired/required. Should be a linux tutorial somewhere on your suse
distro.

--
Abit KT7-Raid (KT133) Tbred B core CPU @2400MHz (24x100FSB)
http://wesnewell.no-ip.com/cpu.htm

In article ,
1 says...
On Mon, 24 Jan 2005 23:29:13 -0500, "Carlo Razzeto"
wrote:
Because no windows driver code lives in the kernel literally or figertativly
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
it won't be *as* suseptable to such things (though there are other ways to
break the kernel). I'm not saying it's impossible to write a bad windows
driver that will kill the system. I'm just saying it's harder!

Having developed kernel components and device drivers in excess of
twenty years. I can attest that you're smoking something.

Agreed. As soon as I read that, I decided there was no point in arguing
with him anymore.

Linux has far less subroutine pollution to deal with, and far
fewer black box effects. Each Linux driver developer has full access
to all the surrounding kernel source code. (no such luck in Win
XXX).

bingo.

Overall O/S's reliability is a function of all kernel components
and hardware working together to function in a consistent manor The
greater the number of active components, the higher the probability of
failure. Add in sketchy Win XXX documentation and you have a
receipt for BSOD's at the drop of a hat.

Here's an example. I recently purchased an Iomega external USB/Firewire
250GB hard drive to use for backing up a number of system with smaller
hard drives (all Windows boxes).

It's been running fine for about 2 months, until today, when I got a
blue screen "page fault in non paged pool" in ntfs.sys while backing
up a Windows XP SP2 machine that is normally the most solid Windows
box I have seen. After that happened, I could no longer boot the
computer with the Iomega drive attached. Using either USB or Firewire,
as soon as it tried to mount it up, boom, same ntfs.sys BSOD. Even
safe mode off of the USB cable, same thing. So I tried the drive on
3 other computers, all of which exhibited the same exact error with
either USB or 1394. An Iomega "on-line chat" support tech tried to
help me by trying a few things, but they all got back to the same
BSOD. He was about to have me return the drive because he couldn't
get around the blue screen.

Apparently, when the first crash came during a backup, the NTFS
partition got so hosed up that Windows couldn't even touch it.

So, I got the idea to plug it into a 64-bit Compaq notebook with Suse
Linux 9.1 x86_64 which I had. I plugged the drive in (had never even
tried the Iomega on Linux before) and it immediately came up, saw
the drive, and the NTFS partition, as well as a small FAT32 partition
that was on the drive as well. I could mount it and read a directory
off of it, but Windows couldn't even catch a whiff of it before blue
screening on its own file system type.

So, I deleted the partition with Linux fdisk, then put it back on one
of the windows systems and used disk manager to rebuild the partition.
Of course, all of my backups were lost going this route, but I didn't
trust what was on the partition at that point anyway. So now, while
typing this I'm performing backups again (hopefully it won't blue screen
again) and we'll see what happens.

Moral of the story: Even if you don't like Linux, you may need it
someday to get your Windows computer to work again. :-)

--
Randy Howard (2reply remove FOOBAR)

En , Randy Howard va escriu
On Mon, 24 Jan 2005 23:29:13 -0500, "Carlo Razzeto" wrote:
Because no windows driver code lives in the kernel literally or
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^

Having developed kernel components and device drivers in excess
of twenty years. I can attest that you're smoking something.

Agreed. As soon as I read that, I decided there was no point in
arguing with him anymore.

Agreed. This is the kind of quickly written remark that shot the whole guy.


Here's an example. I recently purchased an Iomega external
USB/Firewire 250GB hard drive to use for backing up a number of
system with smaller hard drives (all Windows boxes).
snip

I agree with you, this is typical use where a foreign OS can help to go out
of a tangle put by a kernel problem (badly written driver or simple deadlock
or even bad hacking).

However, I came to such solutions in the other way, too: I resorted to use
Windows (or DOS) to clear stuff that Linux (or other OS) cannot sort out
itself.
Before any rant, I agree it happened to me more often to resort to Linux to
untangle Win than the contrary (which happens only thrice, and one was with
0.99pl14, so probably should not count). But also I often run Win than
Linux, so I am biased about the cases too.

I prefer remind me that firing just another OS is an effective way to debug
things.


Moral of the story: Even if you don't like Linux, you may need it
someday to get your Windows computer to work again. :-)

Just invert the TMs, it comes much more funny I found. ;-)


Antoine