cluberti

Well, not entirely true, but in reality yes. Games aren't written to take advantage of multiple GPU processing, and (currently) neither OpenGL or DirectX have the ability to do multithreading of GPU rendering. DirectX 11 will fix that, and games written for DX11 will have the ability to multithread the rendering, but the current crop of hardware probably won't be 100% DX11 compliant so it's of little use now. As it stands currently, the apps/games rely on the drivers and hardware to utilize both efficiently, and you draw conclusions from there as to how successful that has been.

What did you end up going with, and why?

Gotta call you out here just for correctness - Mac OS X is based on the Mach Kernel, which was derived from the Berkeley BSD implementation of NeXTStep (note that the actual name for the kernel is XNU - X is Not Unix). It is *not* a Unix. It's POSIX compliant, yes, but *not* a Unix. While a good post, I don't want noobs thinking that by using OS X, they're using a true Unix - they are not.

About the same. Unless you're needing to modify settings on the fly, neither is necessary. Helpful for some, mostly not for others.

Also, if you're using Broadcom (or rebranded Broadcom, like HP internal NICs for instance) NICs, consider disabling large send offload in the driver config as well. Broadcom drivers are known to work poorly with the Scalable Networking Pack (introduced in KB912222 and SP2 for 2K3). Broadcom isn't the only one, but they're the largest offender. Next, make the following registry changes: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Value: EnableTCPChimney Type: REG_DWORD Data: 0 Value: EnableTCPA Type: REG_DWORD Data: 0 Value: EnableRSS Type: REG_DWORD Data: 0 Lastly, install the hotfix in KB950224. Once done, reboot, and see what happens.

That'd depend on the bulb in the scanner itself. All scanners are not made equal, so contacting the scanner vendor (or seeing if they label this on the specs page of the model on their web site) is your best course of action. I could guess though - enough to do the job? Sorry, had to do it.

I'm a big fan of modular power supplies, so from what you've got listed here a 625W Enermax MODU82+ would fit the bill nicelyand have headroom for the future (and it's a very efficient power supply to boot).

All of the documentation is actually in the help files, which you can look at in the Deployment Workbench.

Take a look around, see if it will work for you: http://www.onlamp.com/pub/a/bsd/2004/04/01...ry_Daemons.html http://frommars.org/linux/hyderabad_techta...full_volume.pdf I would recommend Debian Linux or FreeBSD as a platform for sendmail, in that order (apt-get install sendmail spamass-milter mimedefang clamav clamav-freshclam clamav-milter to install everything on debian).

Spamassassin + Sendmail + MIMEDefang (you could use something other than sendmail as an MTA, I'm just most comfortable with that) will work. Client-side, something like SpamBayes would work.

Take a look at KB 950065.

That is the location where hotfixes are downloaded/extracted before they're installed. It's likely there because you tried to install the hotfix. Unless you can find it elsewhere, it is *not* on your system.

I've not had a problem modifying or replacing files in either, but you can take ownership as admin (even of folders you're locked out ot). Not to mention you do still have full rights over the folder and subfolders, even without ownership. So, again, what don't you have access to as administrator?

EULAs are not legally enforcable. OK, you take that chance, but contract law and precedent (for recent, see Blizzard vs BNetD or Mortensen vs Timberline Software) have, in the US at least, made EULAs enforceable. Canada is usually quick to follow suit, and I know that it's not long before the EU hops on the bandwagon too. Contract law on almost all other contract types end up being upheld in courts, and EULAs have been too. So don't be so sure that EULA isn't legal and enforceable. Not only that, this thinking makes the GPL unenforceable (as it's a license on it's property, just like a EULA on a software package) and all open-source code is now public domain, no better than BSD code, to be assimilated into commercial products without recourse. Because, of course, a license on software is not enforceable and thus means nothing, right?

Really? Ask the autopatcher folks if reselling or distributing (free) Microsoft binaries and IP doesn't get you in the crosshairs of the legal system. How quickly we forget - redistribution of Microsoft software is *not* OK (at least here in the US and Canada, and most EU countries) unless you *are Microsoft*. If you are *not* Microsoft, you *cannot* redistribute the software in *any* form (read the EULA closely - it forbids redistribution).

Well, if you are unable to acquire a piece of hardware not also acting as the core router for the company, you could do any of the above. However, if you could acquire a bit more equipment (like a switch that can create a VLAN, and another AP) you could just put the new WAP on a VLAN, or firewall it from the rest of the network (put it in a DMZ network).

Yes, older than 9.0.0.3359, but I made the assumption you would understand that since it's a 9.x update only, that this only applied to files older than 9.0.0.3359, but newer than (or equal to) 9.0.0.0. This security bulletin does not include any affected WME7 binaries - the hotfix is *specifically* for WME9. It will NOT update a 7.x file (which is why you see the error message you do - WME9 is, in fact, not installed - the error is accurate). Notice in the affected software list for the update, it does not include WME 7.x at all as affected by this.Also, I have to ask - is there any specific reason as to why you would not have upgraded to WME9 as of yet? WME7 was released for Win98, WinME, and W2K. WME9 was released in January of 2003, so unless you have the need to use the encoder to encode files that are compatible with Media Player 6 or older, I can't see a reason not to upgrade (and install this hotfix, of course). As to the Belarc advisor, since Windows Update doesn't show the update, and you do not have a 9.x version of the file on the system, the warning that you need the hotfix is inaccurate. The only thing at fault here is the Belarc advisor.

Well, considering 7.1.0.3055 is Windows Media Encoder 7, not 9, I don't expect a hotfix for WME 9.0 to update a 7.0 file.

Yes it does, you just don't realize it. By installing the SP, you just re-registered all of the .dll files in the product, and re-touched (and potentially repaired) any and all IE registry settings.So yes, it does make sense that this fixes it.

A couple of things to note: 1. If you are testing with anything less than Vista SP1, re-do the tests after upgrading to SP1 2. Vista counts the *whole* time it takes to copy a file and doesn't rely on the cache manager to copy the file to RAM and then write it to the disk later, whereas XP simply starts the copy of the file to disk, but is using the cache manager to "speed up" transfers (it finishes when the file is copied entirely to the cache manager and has started writing to disk). Meaning that if you were to power off your machine during a large file copy that "looked" finished in XP, you could actually end up with a corrupted file, because it wasn't *really* finished copying to disk. Read here. From TFA:

Are the drivers you are having trouble with old, or newer? ATI catalyst drivers have been pretty rock solid since v7.1 released, back in January of 2007 if I am remembering the date correctly. If you're running into people using 6.x (or heaven forbid 5.x or 4.x) versions, then yes, these weren't of the highest quality. Note that the 7.x releases were the first official releases after the AMD purchase of ATI (coincidence? I think not).

What does the local admin account *not* have access to? That's my question.

What you have is people seeing a bugcheck code and guessing (knowing only some experience with some *other* bugcheck they've had, or someone knows of someone with a similar bugcheck, etc). Since we know what the problem is, I'm closing this thread to avoid any further speculation (not necessary) or embarassment for those just guessing at an answer and grasping at straws.

Attaching a null modem cable and a debugger would get them the same data. They should know how to do this. No, once I've got an actual hardware error bugcheck, nothing else matters.

Not a problem. If they weren't able to figure this out themselves from this dump, honestly, I'd not buy a future machine from them. Just my .02¢.