Please tell me if I'm missing something, but isn't the real vulnerability that the BIOS can be modified with unsigned code? A BIOS that allows this can be infected with a rootkit regardless of whether the LoJack code was there.
The real problem is that the BIOS can be modified. (At any time, without any sort of security controls.)
Full stop.
A better way to mitigate it is to require either:
- Some sort of hardware lock (jumper pin that has to be removed, a switch on the motherboard)
- Require the user to enter the BIOS at startup and set it to "writeable" until the next power cycle
Signed vs unsigned code isn't all that useful over the long run as signing keys can be compromised or stolen.
If you chose a free linux for your company's servers, and this happens, then your company only has YOU to blame.
That depends on:
- Which distro you chose to base production servers on. Sam's Closet Linux is not as good of a choice as Ubuntu LTS, CentOS, or some flavor of Novell's SUSE.
- Whether management was in agreement with the reasoning behind the choice of said distro and the decision not to purchase annual support.
CentOS is a very solid choice for cases where you're not ready to pony up the annual fees to Red Hat, but you want to leave that door open for the future. For small / medium businesses, it's a smart play because the worst case is that you migrate everything over to RHEL down the road.
It also so closely follows the RHEL platform that you can easily purchase RHEL books and apply the knowledge to CentOS (and vice-versa). Which also makes it easy to contract with a local Linux shop for support.
(Our internal servers will continue to run CentOS. Our public servers are going to be RHEL. If the public boxes are down, we don't make money. If the internal boxes are down, life is hard but the work continues. If my boss gets nervous, we go buy a commercial support contract for the internal boxes or upgrade them to RHEL.)
I haven't seen any problems with our yum updates. But we also use RPMForge for more up-to-date packages along with yum-priorities.
Overall, it's been an extremely stable distro compared to some others that we've tried. But, really, the biggest selling point is that when we need commercial support, we can move to RHEL without requiring tons of retraining. Or purchase commercial support from a local company because it is so similar to RHEL.
So even if CentOS goes belly-up, we're not in a bad position. We would probably move upstream to RHEL.
However, I've been worried about how out-of-date CentOS currently is, basically a snapshot of FC6.
That's because RHEL 5 is also based off of FC6 (Linux kernel 2.6.18).
The whole point of CentOS 5 is to track RHEL 5 closely (and in a binary compatible way). Which is great for people who want to learn RHEL, but not fork out the support cost for the real thing until they're ready and/or need Red Hat support. In fact, Red Hat loves this, because they get mindshare (people get used to working on a Red Hat style system) without the support costs. When those people are ready for commercial support, they're naturally going to turn upstream and talk to Red Hat.
Now, Red Hat does backport a lot of security fixes into their version of the 2.6.18 kernel. I'm not sure if they also backport drivers for more modern hardware (they probably do for server hardware). And you can always compile a custom kernel straight from the kernel sources and use that instead.
If you want more modern versions of packages and don't care about being binary compatible with Red Hat, go install RPMForge as an additional repository. I'd also recommend installing "yum-priorities" and setting it up as directed so that RPMForge packages have a higher number (thus lower priority) then the Base & Updates repositories.
For example, in order for use to use Subversion 1.6 instead of 1.4, we added two lines to our CentOS-Base.repo file under the "[base]" section.
[base] ...
priority=1
exclude=subversion-*
Then we installed Subversion 1.6.3 from the RPMForge repositories. No muss, no fuss, no need to deal with constantly compiling from source. We've done the same for other packages like Samba, Postfix, PostgreSQL, etc.
From what I've read in the past week or two, RHEL 6 is expected sometime in early 2010. (And by past history, that means CentOS 6 will come out about 1-2 months after that.)
The bigger thing was that you gave clear expectations and times. So your volunteers knew that they needed to show up at X, what to expect, and that they could leave at Y. People like predictability and knowing that things aren't going to change on a whim (most of the time). It makes them feel like a situation is under their control and allows them to make other plans with certainty.
(Interestingly, you'll see the same thing if you try to lead / schedule raids or events in a game like WoW. Both situations involve herding cats to achieve a common goal in an environment where your members can easily walk away or not show up. There's a good bit of overlap in the people skills required to succeed.)
Public chat channels are inherently problematic. Drama / attention whores love to flock to those channels where they can be the king/queen of the channel. Especially if there is no objective moderation going on to slap down offenders. Those people will drive away the more reasonable and level-headed people.
You'll see this in all types of communities. It has nothing to do with those folks being technically oriented or not, but has everything to do with base human nature.
But let's be realistic, who would normally visit that site, throughout their usual daily routine? I've had Javascript and cookies enabled always, for my entire time of browsing the web (15+ years?), and never had a web-based attack of any kind. And I surf a lot.
Pure luck? Or when was the last time that you checked?
Ever hear of the Antivirus 2009 infections? That is usually (often?) spread via JavaScript exploits where they break into a website and insert a bit of JavaScript onto every static HTML page in the site. You visit that site with JavaScript enabled and you will end up infected (assuming that you're using a browser / OS that is vulnerable).
(We had a user get hit with the AV2009 malware / scareware. I was able to trace it straight back via the web proxy logs to a bit of Javascript added to a completely innocuous site's pages. This was a site that normal users would visit in the course of their web browsing. In this case it was hobby related; either cooking or crafting. Definitely not a "dark" corner of the net by any stretch of the imagination.)
Um, I dunno why your tin foil hat is so large, but seriously, you're living in the 90's. There is - and never was - anything wrong at all with Javascript or cookies. Flash can be annoying, but the benefits far outweigh the "risk". Java is the only thing I don't particularly trust, since it's pretty much an open gateway to malware today.
Wow, just... wow.
Javascript is one of the most common ways to inject code into a machine to install a rootkit / trojan / worm / botnet. There are thousands (if not hundreds of thousands) of hacked websites out there with bits of Javascript inserted into their pages that will infect your machine if you visit those sites.
The JavaScript fragments are generally inserted by breaking in via an insecure FTP login (common username coupled with poor password choice). So in order to be safe, you have to trust that *every* web page you visit is administered by someone competent enough to prevent a break-in. And hope that your browser doesn't preload pages from an infected website in order to speed up your browsing experience.
Then there's the whole "insert malicious JavaScript / Flash ad" scheme into an ad network that allows you to do drive-by infections on anyone who is served your ad.
Java has absolutely nothing to do with this, is fairly well sandboxed, and one of the least common methods of delivering malware.
(I've personally seen dozens of infected sites in the wild. Small sites as mundane as Aunt Ruth's Recipe or Aunt Betty's Crafting page are especially likely to be infected. Which is why I only browse for the past few years with NoScript and FlashBlock enabled with a very small whitelist.)
It's probably due to how your company's mail filtering is setup.
In an ideal world, you do your filtering during the SMTP session and give either a 4xx or 5xx code to the originating server if you are blocking the message due to filters. This puts the burden of notifying the original sender on the originating server and does not put your SMTP server at the mercy of relying on a (usually) forged return sender address to notify the original sender.
However, a lot of shops do their filtering after accepting a message for local delivery. This causes problems because there's no way of reliably informing the originator of the message that their message was blocked or bounced. Sender addresses are almost always forged in spam runs, and relying on that to notify the sender causes "backscatter" spam. A lot of email anti-virus tools cause this backscatter because they make the naive assumption that the sender address is not forged.
Some systems do a quarantine style setup, where the message is placed in a queue, and the recipient is informed of the sender / subject and allowed to retrieve it.
Unfortunately, filtering during the SMTP transaction (a.k.a. "pre-queue filtering") has its downsides (performance, CPU usage, lack of integration with 3rd party tools). But it's still best to reject as much mail as possible during the SMTP transaction.
With Wal Mart prices are LOWER. Maybe not for companies, but as a consumer Wal Mart's monopoly is a good thing for me.
Over the short-term, yes.
The long-term results? Look at the history of the past 15 years since Wal-Mart came on the scene back in the early 90s.
The specific problem with Wal-Mart is that they are too large and have too much clout over suppliers. The problem back in the mid-90s was that a supplier would get approached by Wal-Mart. Wal-Mart, by offering to carry their product, would result in 2x or 3x more annual revenue due to increased volume.
Everything is rosy for the first year or two. The supplier takes on debt in order to ramp up their production capacity to meet the volume that Wal-Mart sells. They might even be encouraged to stop selling through other stores.
Now Wal-Mart starts to apply the screws. They begin to demand that the supplier lower their costs every year. So after a few seasons of cuts, you're faced with a choice. Sell to Wal-Mart at a loss or lose 1/2 to 2/3 of your annual revenues by not selling to Wal-Mart. Either way leads to the destruction of the supplier unless they start making cheap crap in the cheapest country that they can find.
In what way is that healthy for the economy or the consumer over the long term?
Personally, I never sell used games. (I'm a publisher's dream consumer.)
The reason I choose Steam is that I value convenience over the ability to resell down the road. If I wanted the ability to resell games, I'd play on consoles.
I was initially leery of Steam (didn't sign up until this year), but they've developed a good stable reputation and their distribution model fits with what I want.
Mmm, until the "next" improvement comes along for rotational magnetic based storage, the upper end for drives was predicted to be around 2TB for 2.5" and about 4-5TB for 3.5".
The brick wall is there. Which is one of the reasons that drive capacity growth has been slowing the past few years.
Four 2.5" drives will fit in a 5.25" bay (in a 2x2 format). Those bays already exist. Hopefully, we'll see double-high 5.25" bays that fit (8) 2.5" drives across.
The reason I'd want a double-high 5.25" bay instead of a single 5.25" bay is that the double-high allows them to use a quieter 60-70mm fan instead of the tiny 35-40mm fans.
I can understand having this much space at home, for movies, TV series, pictures and the like, but on the go ?
Smaller backups, less space used for offsite storage (such as bank boxes or media safes).
On my primary laptop, I have about 250GB of files at the moment. None of that is movies or music. More storage means that I can keep more things around in case I need to reference things. There's already things that I don't carry on my laptop that I wish I could.
Unfortunately, for my laptop, I would find even a 300GB drive to be too small (I run a 500GB 2.5" drive). So, a few more years until the drives get big enough and inexpensive enough (I'd pay $400-$500 for something of a decent size).
But for server-side, an array of these units in a RAID-6 setup could be very sweet. The question is whether you can find a server case that lets you hot-swap 2.5" drives.
Re:I hate when TFA is written by a half-tech
on
Gaming On Windows 7
·
· Score: 1
Ugh, fact checking? 32-bit has a 4GB memory limit, not 2GB. With your video ram, it sometimes came out to be 3GB or a little more.
Individual processes are limited to 2GB of RAM.
Then there's the whole issue where Microsoft has limited their client OSs in the amount of RAM that can be accessed. (See Physical Memory Limits.)
Windows 2008 server is limited to 4GB in 32bit mode (or 16GB in 64bit mode). Unless you buy the more expensive versions.
All Vista 32bit is limited to 4GB of RAM. The 64bit editions go up to 128GB (but the home versions are only 8/16GB).
XP was limited to 4GB of RAM, 64bit could access up to 64GB of RAM.
And 2GB per process is a bit of a dream figment in the real 32bit world. Most programs start running into trouble up around the 1.5-1.8GB point, even if they're not yet swapping.
Probably. Especially if they have message size restrictions on the inbound/outbound server.
A 2Mbps link can transmit about 650MB/hr (same for inbound). It takes an awful lot of 10k e-mail messages to fill up 650MB (65,000 per hour in each direction) and there are 24 hours in a day. Even with a 90-95% spam ratio, it's probably doing fine. It's the emails with large attachments that will kill your bandwidth.
(Most messages in my personal mailbox are in the 5k-15k range, with HTML emails being up to a few dozen KB in size.)
Memtest / Memtest86 / Memtest86+ is not a thorough enough check for memory that may be only somewhat bad. To properly diagnose bad memory or timing issues, you have to put the machine under heavy CPU/RAM load for at least a few hours. Memtest86 does not put a CPU load on the machine.
Ideally, you want to even be exercising the disks at the same time. You know, doing a proper burn-in test like PC makers used to offer.
Prime95 does an excellent job of putting the CPU/RAM under heavy load. And it does extensive double-checks of its calculations, so it's quite good at spotting timing errors or flaky memory. If you can run the Prime95 torture test for 4+ hours, your memory / CPU / timings are probably okay. Extend that to 24-48 hours without an error, and you can be pretty confident that those components aren't causing errors.
For home use, Velcro cable ties are a far better solution. The ones we use are about 6" long and 1/2" wide. Which is the perfect size for wrapping bundles up to about 1" in diameter to neaten up things.
They're also a lot easier to deal with for stuff that changes frequently.
Hot copy, nightly duplication etc. may protect against catastrophic system failure, theft etc. but they are poison if you want to protect against lurking data corruption.
rdiff-backup on Linux or Second Copy 7 on Windows.
Both allow you to keep previous versions of changed files.
You can also do something similar with rsync or rsnapshot, but I prefer the way rdiff-backup works.
Slashdot Mirror
Please tell me if I'm missing something, but isn't the real vulnerability that the BIOS can be modified with unsigned code? A BIOS that allows this can be infected with a rootkit regardless of whether the LoJack code was there.
The real problem is that the BIOS can be modified. (At any time, without any sort of security controls.)
Full stop.
A better way to mitigate it is to require either:
- Some sort of hardware lock (jumper pin that has to be removed, a switch on the motherboard)
- Require the user to enter the BIOS at startup and set it to "writeable" until the next power cycle
Signed vs unsigned code isn't all that useful over the long run as signing keys can be compromised or stolen.
If you chose a free linux for your company's servers, and this happens, then your company only has YOU to blame.
That depends on:
- Which distro you chose to base production servers on. Sam's Closet Linux is not as good of a choice as Ubuntu LTS, CentOS, or some flavor of Novell's SUSE.
- Whether management was in agreement with the reasoning behind the choice of said distro and the decision not to purchase annual support.
CentOS is a very solid choice for cases where you're not ready to pony up the annual fees to Red Hat, but you want to leave that door open for the future. For small / medium businesses, it's a smart play because the worst case is that you migrate everything over to RHEL down the road.
It also so closely follows the RHEL platform that you can easily purchase RHEL books and apply the knowledge to CentOS (and vice-versa). Which also makes it easy to contract with a local Linux shop for support.
(Our internal servers will continue to run CentOS. Our public servers are going to be RHEL. If the public boxes are down, we don't make money. If the internal boxes are down, life is hard but the work continues. If my boss gets nervous, we go buy a commercial support contract for the internal boxes or upgrade them to RHEL.)
Yah, the "you must buy issue XYZ of an entirely different series" in order to grasp what is going on is a very big turnoff for me.
Mangas also tend to focus on story / character development over flash/glitz.
I haven't seen any problems with our yum updates. But we also use RPMForge for more up-to-date packages along with yum-priorities.
Overall, it's been an extremely stable distro compared to some others that we've tried. But, really, the biggest selling point is that when we need commercial support, we can move to RHEL without requiring tons of retraining. Or purchase commercial support from a local company because it is so similar to RHEL.
So even if CentOS goes belly-up, we're not in a bad position. We would probably move upstream to RHEL.
However, I've been worried about how out-of-date CentOS currently is, basically a snapshot of FC6.
...
That's because RHEL 5 is also based off of FC6 (Linux kernel 2.6.18).
The whole point of CentOS 5 is to track RHEL 5 closely (and in a binary compatible way). Which is great for people who want to learn RHEL, but not fork out the support cost for the real thing until they're ready and/or need Red Hat support. In fact, Red Hat loves this, because they get mindshare (people get used to working on a Red Hat style system) without the support costs. When those people are ready for commercial support, they're naturally going to turn upstream and talk to Red Hat.
Now, Red Hat does backport a lot of security fixes into their version of the 2.6.18 kernel. I'm not sure if they also backport drivers for more modern hardware (they probably do for server hardware). And you can always compile a custom kernel straight from the kernel sources and use that instead.
If you want more modern versions of packages and don't care about being binary compatible with Red Hat, go install RPMForge as an additional repository. I'd also recommend installing "yum-priorities" and setting it up as directed so that RPMForge packages have a higher number (thus lower priority) then the Base & Updates repositories.
For example, in order for use to use Subversion 1.6 instead of 1.4, we added two lines to our CentOS-Base.repo file under the "[base]" section.
[base]
priority=1
exclude=subversion-*
Then we installed Subversion 1.6.3 from the RPMForge repositories. No muss, no fuss, no need to deal with constantly compiling from source. We've done the same for other packages like Samba, Postfix, PostgreSQL, etc.
From what I've read in the past week or two, RHEL 6 is expected sometime in early 2010. (And by past history, that means CentOS 6 will come out about 1-2 months after that.)
The bigger thing was that you gave clear expectations and times. So your volunteers knew that they needed to show up at X, what to expect, and that they could leave at Y. People like predictability and knowing that things aren't going to change on a whim (most of the time). It makes them feel like a situation is under their control and allows them to make other plans with certainty.
(Interestingly, you'll see the same thing if you try to lead / schedule raids or events in a game like WoW. Both situations involve herding cats to achieve a common goal in an environment where your members can easily walk away or not show up. There's a good bit of overlap in the people skills required to succeed.)
Public chat channels are inherently problematic. Drama / attention whores love to flock to those channels where they can be the king/queen of the channel. Especially if there is no objective moderation going on to slap down offenders. Those people will drive away the more reasonable and level-headed people.
You'll see this in all types of communities. It has nothing to do with those folks being technically oriented or not, but has everything to do with base human nature.
But let's be realistic, who would normally visit that site, throughout their usual daily routine? I've had Javascript and cookies enabled always, for my entire time of browsing the web (15+ years?), and never had a web-based attack of any kind. And I surf a lot.
Pure luck? Or when was the last time that you checked?
Ever hear of the Antivirus 2009 infections? That is usually (often?) spread via JavaScript exploits where they break into a website and insert a bit of JavaScript onto every static HTML page in the site. You visit that site with JavaScript enabled and you will end up infected (assuming that you're using a browser / OS that is vulnerable).
(We had a user get hit with the AV2009 malware / scareware. I was able to trace it straight back via the web proxy logs to a bit of Javascript added to a completely innocuous site's pages. This was a site that normal users would visit in the course of their web browsing. In this case it was hobby related; either cooking or crafting. Definitely not a "dark" corner of the net by any stretch of the imagination.)
Um, I dunno why your tin foil hat is so large, but seriously, you're living in the 90's. There is - and never was - anything wrong at all with Javascript or cookies. Flash can be annoying, but the benefits far outweigh the "risk". Java is the only thing I don't particularly trust, since it's pretty much an open gateway to malware today.
Wow, just... wow.
Javascript is one of the most common ways to inject code into a machine to install a rootkit / trojan / worm / botnet. There are thousands (if not hundreds of thousands) of hacked websites out there with bits of Javascript inserted into their pages that will infect your machine if you visit those sites.
The JavaScript fragments are generally inserted by breaking in via an insecure FTP login (common username coupled with poor password choice). So in order to be safe, you have to trust that *every* web page you visit is administered by someone competent enough to prevent a break-in. And hope that your browser doesn't preload pages from an infected website in order to speed up your browsing experience.
Then there's the whole "insert malicious JavaScript / Flash ad" scheme into an ad network that allows you to do drive-by infections on anyone who is served your ad.
Java has absolutely nothing to do with this, is fairly well sandboxed, and one of the least common methods of delivering malware.
(I've personally seen dozens of infected sites in the wild. Small sites as mundane as Aunt Ruth's Recipe or Aunt Betty's Crafting page are especially likely to be infected. Which is why I only browse for the past few years with NoScript and FlashBlock enabled with a very small whitelist.)
It's probably due to how your company's mail filtering is setup.
In an ideal world, you do your filtering during the SMTP session and give either a 4xx or 5xx code to the originating server if you are blocking the message due to filters. This puts the burden of notifying the original sender on the originating server and does not put your SMTP server at the mercy of relying on a (usually) forged return sender address to notify the original sender.
However, a lot of shops do their filtering after accepting a message for local delivery. This causes problems because there's no way of reliably informing the originator of the message that their message was blocked or bounced. Sender addresses are almost always forged in spam runs, and relying on that to notify the sender causes "backscatter" spam. A lot of email anti-virus tools cause this backscatter because they make the naive assumption that the sender address is not forged.
Some systems do a quarantine style setup, where the message is placed in a queue, and the recipient is informed of the sender / subject and allowed to retrieve it.
Unfortunately, filtering during the SMTP transaction (a.k.a. "pre-queue filtering") has its downsides (performance, CPU usage, lack of integration with 3rd party tools). But it's still best to reject as much mail as possible during the SMTP transaction.
With Wal Mart prices are LOWER. Maybe not for companies, but as a consumer Wal Mart's monopoly is a good thing for me.
Over the short-term, yes.
The long-term results? Look at the history of the past 15 years since Wal-Mart came on the scene back in the early 90s.
The specific problem with Wal-Mart is that they are too large and have too much clout over suppliers. The problem back in the mid-90s was that a supplier would get approached by Wal-Mart. Wal-Mart, by offering to carry their product, would result in 2x or 3x more annual revenue due to increased volume.
Everything is rosy for the first year or two. The supplier takes on debt in order to ramp up their production capacity to meet the volume that Wal-Mart sells. They might even be encouraged to stop selling through other stores.
Now Wal-Mart starts to apply the screws. They begin to demand that the supplier lower their costs every year. So after a few seasons of cuts, you're faced with a choice. Sell to Wal-Mart at a loss or lose 1/2 to 2/3 of your annual revenues by not selling to Wal-Mart. Either way leads to the destruction of the supplier unless they start making cheap crap in the cheapest country that they can find.
In what way is that healthy for the economy or the consumer over the long term?
Personally, I never sell used games. (I'm a publisher's dream consumer.)
The reason I choose Steam is that I value convenience over the ability to resell down the road. If I wanted the ability to resell games, I'd play on consoles.
I was initially leery of Steam (didn't sign up until this year), but they've developed a good stable reputation and their distribution model fits with what I want.
Works if you put a + symbol in front of all the terms.
I dunno why it's leaving the 4th term off.
Mmm, until the "next" improvement comes along for rotational magnetic based storage, the upper end for drives was predicted to be around 2TB for 2.5" and about 4-5TB for 3.5".
The brick wall is there. Which is one of the reasons that drive capacity growth has been slowing the past few years.
When you get into that size drive in that form factor, having generational backups is a lot easier (and smarter).
So at least 3 drives, with 2 of them stored offsite as a start.
Four 2.5" drives will fit in a 5.25" bay (in a 2x2 format). Those bays already exist. Hopefully, we'll see double-high 5.25" bays that fit (8) 2.5" drives across.
The reason I'd want a double-high 5.25" bay instead of a single 5.25" bay is that the double-high allows them to use a quieter 60-70mm fan instead of the tiny 35-40mm fans.
I can understand having this much space at home, for movies, TV series, pictures and the like, but on the go ?
Smaller backups, less space used for offsite storage (such as bank boxes or media safes).
On my primary laptop, I have about 250GB of files at the moment. None of that is movies or music. More storage means that I can keep more things around in case I need to reference things. There's already things that I don't carry on my laptop that I wish I could.
Unfortunately, for my laptop, I would find even a 300GB drive to be too small (I run a 500GB 2.5" drive). So, a few more years until the drives get big enough and inexpensive enough (I'd pay $400-$500 for something of a decent size).
But for server-side, an array of these units in a RAID-6 setup could be very sweet. The question is whether you can find a server case that lets you hot-swap 2.5" drives.
Ugh, fact checking? 32-bit has a 4GB memory limit, not 2GB. With your video ram, it sometimes came out to be 3GB or a little more.
Individual processes are limited to 2GB of RAM.
Then there's the whole issue where Microsoft has limited their client OSs in the amount of RAM that can be accessed. (See Physical Memory Limits.)
Windows 2008 server is limited to 4GB in 32bit mode (or 16GB in 64bit mode). Unless you buy the more expensive versions.
All Vista 32bit is limited to 4GB of RAM. The 64bit editions go up to 128GB (but the home versions are only 8/16GB).
XP was limited to 4GB of RAM, 64bit could access up to 64GB of RAM.
And 2GB per process is a bit of a dream figment in the real 32bit world. Most programs start running into trouble up around the 1.5-1.8GB point, even if they're not yet swapping.
Is that even sufficient for email?
Probably. Especially if they have message size restrictions on the inbound/outbound server.
A 2Mbps link can transmit about 650MB/hr (same for inbound). It takes an awful lot of 10k e-mail messages to fill up 650MB (65,000 per hour in each direction) and there are 24 hours in a day. Even with a 90-95% spam ratio, it's probably doing fine. It's the emails with large attachments that will kill your bandwidth.
(Most messages in my personal mailbox are in the 5k-15k range, with HTML emails being up to a few dozen KB in size.)
Memtest / Memtest86 / Memtest86+ is not a thorough enough check for memory that may be only somewhat bad. To properly diagnose bad memory or timing issues, you have to put the machine under heavy CPU/RAM load for at least a few hours. Memtest86 does not put a CPU load on the machine.
Ideally, you want to even be exercising the disks at the same time. You know, doing a proper burn-in test like PC makers used to offer.
Prime95 does an excellent job of putting the CPU/RAM under heavy load. And it does extensive double-checks of its calculations, so it's quite good at spotting timing errors or flaky memory. If you can run the Prime95 torture test for 4+ hours, your memory / CPU / timings are probably okay. Extend that to 24-48 hours without an error, and you can be pretty confident that those components aren't causing errors.
Except that the SATA connectors are a lot more fragile and easier to break...
The other poster has it right, needlenose pliers or a screwdriver are the way to work with Molex connectors.
For home use, Velcro cable ties are a far better solution. The ones we use are about 6" long and 1/2" wide. Which is the perfect size for wrapping bundles up to about 1" in diameter to neaten up things.
They're also a lot easier to deal with for stuff that changes frequently.
It all depends on the industry that you're in.
Our server/user ratio is up around 1:2.5 right now.
Of course, you can blame some of that on cost-cutting on the employee side, but we've also chopped servers out of the equation in the past 2 years.
And the ratio gets even worse once we start adding in virtualized servers.
(On the upside, we do at least do virtualization now.)
Hot copy, nightly duplication etc. may protect against catastrophic system failure, theft etc. but they are poison if you want to protect against lurking data corruption.
rdiff-backup on Linux or Second Copy 7 on Windows.
Both allow you to keep previous versions of changed files.
You can also do something similar with rsync or rsnapshot, but I prefer the way rdiff-backup works.