I've found a surprising number of modern motherboards that boot fine with no video card (and no onboard video). They often give a "no video" error beep, but keep on booting. Try it without any video card.

You didn't have enough RAM. To use deduplication on ZFS without a massive performance hit requires assloads of RAM. 8 GB is nothing to ZFS with dedup on unless your disks are tiny. While Oracle claims less, the FreeBSD guys have found you need at least 5 GB per TB of disk just for dedup, plus more for cache and the rest of the OS. Do the math and any reasonably big storage pool will need tonnes of RAM.

This is completely incorrect. The current Mac Pros use Nehalem based Xeons which are two generations back from the current Ivy Bridge i7s. Xeons may have differences in core count, cache and/or ECC support but their execution units are the same as their desktop equivalents. The base Mac Pro CPU is equivalent to an i7-960 with ECC support. The current Ivy Bridge i7s are a fair bit faster.

No, he is completely correct. Linux of the time did not "run happily" on that hardware with the same level of GUI complexity as Win9x. Either Linux had no GUI at all, or a simple window manager like TWM or FVWM.

This is also doubly wrong in claiming that all other operating systems at the time had proper security. The biggest competitors to MS at the time were even simpler and less secure OSes. For GUIs there was MacOS which didn't have protected memory and could barely multitask, along with having no security model. On the server side the biggest at the time would have been Novell, which did have a security model, but still had no protected memory and much simpler multitasking than even Win9x.

Nope. P67 boards do not support the onboard video of any CPUs, so effectively it's not there. There are also the P versions of some 1155 CPUs that have no onboard video at all.

All Core 2 CPUs have PAE, even the Celeron versions

Some lower end chipsets from the Core 2 era don't support more than 4GB of physical address space, even with 64 bit OSes.

I'm a satisfied CrashPlan customer too, but it most certainly is bloated. For what it does it's memory usage is insane. The service is currently using 900 MB of RAM on my system just idling, plus another 200 MB for the interface. I've had cases where I've had to edit its config files to allow it to use even more memory and Google shows I'm far from the only one.

It's also extremely slow. It will often backup at only 20-40 mbit/sec locally on my gig lan. I know it encrypts files, but my i7 can perform the same encryption in other programs at least an order of magnitude faster. Yes, I have allowed it to use more CPU power.

While there isn't anything that works as well, there are tonnes of programs that do similar things to CrashPlan with a fraction of the resource usage.

Running spinrite against an SSD is one of the clearest ways of showing that it is complete BS. It will report all sorts of things about the drive that are clearly impossible. It won't error or give no data, it clearly makes things up about the drive.

Another good BS test for spinrite is to run it against a non-ATA drive that is still BIOS accessible. A booted USB flash drive is the best, but something like a modern SCSI/SAS controller works as well. It's clearly impossible for spinrite to access such a device directly, yet it still reports all sorts of things it simply could not see. No errors or blank data, it again makes shit up and displays it.

Doesn't cache writes, so it's only barely faster than a normal mechanical drive.

Nope, that's complete BS.

I have 32 GB in my system and the difference between an SSD and the best mechanical drive is still night and day.

No, it's far more likely that an audio CD will lose data. A modern HD, SSD, tape or even data CD has FAR more error correction and detection than audio CDs. Audio CDs have very limited error correction that is meant to smooth out errors in a non-audible way, not to give perfect data. Any "bitrot" is far more likely to have come from the original CD then the media used to store the ripped data.

No you didn't:

The 386 SX and DX have different bus widths. The SX was 16 bit and was usually soldered on. The DX was 32 bit and usually had a socket, but not a ZIF one. They never shared sockets.

Likewise the Pentium 66 used socket 4 and not socket 5 or 7 that the 150 would have used. Not compatible at all.

Most posters are confusing the issue. ECC and registered are two different things, even if commonly found together. If the DIMMs are ONLY ECC then they will probably work in desktops. If they are registered, ECC or not, then they will not work.

You just proved my point. You ran a test with the most ideal case (pure integer code) and it ran slower when on the same module. Run more real world code with two threads and the performance hit gets bigger. Try the same test on an i7. The code will run the same speed no matter which cores it uses, as it doesn't lie to the OS can claim the SMT units are full cores.

This is the whole reason why Windows 7 has problems scheduling on the FX CPUs. AMD LIES to the OS and claims the SMT units are full cores. This causes performance problems when Windows schedules as if it was true. If AMD had been truthful then the FX CPUs would perform to their fullest potential on any OS, and Linux and Win 8 would not have had to be modified to work around the issue.

Call it hyper-threading, SMT or whatever, the second integer unit on FX CPUs are not full cores. AMD did SMT better than Intel, but it's still not a full core.