The RPi is slow, but not that slow. The issue with using the full 100 mbit is the shitty NIC on the shitty USB bus. I've used 100base-T at full speed on far slower machines than an RPi, but they had proper NICs.
The RPi 2 would have a good chance of handling gigabit if it had a proper NIC.
While certain apps like audio/video/photo editors performed really well on the G5, most real world apps were slower than on x86 processors at the time. When the Apple Intel developer test machines came out people raved about how much faster they were than the G5s. Those were only dual P4s, not even core. The 32 bit core machines were a big step up in performance over the G5s in every day use. Remember that back then single core performance was far more important than it is now. A dual core x86 chip of the time would "feel" much faster than a quad G5 outside of specific apps.
When Apple changed from 68K to PowerPC and from PowerPC to x86 there was a large jump in CPU performance each time. This allowed for the overhead of emulation without performance suffering too much. That performance jump doesn't exist now. In the best case ARM keeps up with the lowest end Intel chips, and Apple doesn't use the lowest end. ARM simply does not have the CPU grunt to emulate x86 without a massive performance hit.
You obviously have never compared SQL performance on Azure VS Amazon. To claim that an Azure P1 is even in the same ballpark performance wise as a db.m3.xlarge is laughable. A P3 (at $3461/month) is still an order of magnitude slower than a db.m3.large. There is NOTHING on Azure that can compete with with even a db.m3.medium simply because the I/O performance is so bad. Even if you fired up a D14 with SQL enterprise, any workload short of pure read-only would fall on its face once it tried to do any writes because the storage simply cannot keep up. I have extensively benchmarked using Microsoft's own SQLIO tool and at times found Azure storage giving less than one IOPS. Yes, less that one IO per second. Azure support confirmed that was normal and expected behavior.
You obviously also know nothing about networking to make such a comment about slammer. On Azure, SQL databases can be connected to from anywhere, any IP. There is no firewall at all. The IP filtering is all done in SQL code, which is extremely dangerous. A bug in the SQL code and you are owned. You cannot change this. RDS on AWS by default does not open the MSSQL port (1433 by default) the world. You must very explicitly both put an RDS instance into a public VPC subnet and then allow the world to connect. AWS will even tell you this is stupid and make you confirm. If there is a bug in the SQL code on RDS it is only an issue if you explicitly do something stupid. A stupid thing which is an unchangeable default on Azure.
AWS may not hold your hand as much as Azure, but everything it does is far more polished and performs far better. All of the features you mention for Azure AWS has and has had for far longer, except for direct Visual Studio publishing.
Auto scaling in AWS is far more powerful than Azure. You can scale based on several different metrics, not just CPU load. It is not "just there" like in Azure in that you must explicitly configure it, but it is worth it for the massively increased control. You can easily replace instances in an AWS load balancer with completely unrelated ones, something that is impossible in Azure
Staged publishing also exists in AWS as Elastic Beanstalk, which is more comparable to the standard PAAS Azure offering. You can switch websites instantly between any of your up to 200 environments, not just two (live and stage) like in Azure. Again, it doesn't hold your hand, but it is far more powerful and flexible.
MSSQL is an absolute joke in Azure which is sad given that it is run by MS. The performance is abysmal and it is Azure's cut down version of SQL, not the same as a real server. AWS lets you run your own on EC2, or use their managed RDS service. RDS offers point in time restores up to 35 days at any point even on their cheapest MSSQL express based offerings. Azure requires you to get their "premium" SQL at an inflated price for that level of backup. RDS is also still a full server without any missing functionally like SQL Azure. Security of SQL Azure is also non-existent. It does IP filtering at the DB level, no firewall. The next slammer type worm will infect every Azure DB including yours.
On top of all that performance is not even comparable between the two services. Azure purposefully compares their offerings to deprecated AWS instances because current AWS instances blow them out of the water in both price/performance and raw performance. I/O performance is basically non-existent in Azure, their managed storage system is pathetically slow.
Azure is designed to make it easy for a developer who has zero infrastructure and networking knowledge to get his code out into the world running on a shitty system. This is a very bad thing. A developer with even a tiny bit of infrastructure knowledge can see how bad Azure is.
If AMD performed the same as Intel VMware wouldn't offer a 50% discount for using AMD. See my comment above about MSSQL. Like MS, VMware is not going to offer discounts unless they have to. AMD CPUs perform so poorly that VMware has to offer a discount just to make them even remotely viable.
Oracle also offers a discount for using AMD. If any company loves money it's Oracle and even they realize that performance on AMD sucks without a discount.
Since you are such an MS fanboy, here is the biggest MS example of how you are completely wrong:
Microsoft SQL Server
MSSQL is:
1. Compiled using Microsoft's compiler, not Intel's. No "cheating" there.
2. A fairly integer heavy workload which in theory would benefit AMD's module architecture.
The reality is Intel processors absolutely destroy AMDs in MSSQL performance. By more than 2 to 1. A mere Westmere based 2X Xeon X5690 12 core system beats a 32 core 2X Opteron 6282SE in TPC-E. Intel has 3 generations of newer Xeons since that benchmark was made, AMD has had only one newer Opteron (6300 series) which was a tiny increase at best.
The biggest nail in the AMD coffin is that MS gives you a discount on MSSQL licensing if you use AMD CPUs because the performance is so bad. MS is not known for leaving money on the table, if they could make AMDs perform like Intels they would.
Also Microsoft's Azure service used to be a big user of AMD CPUs. All their older A series VMs run on AMD 4100 series Opterons, which are pre buildozer failure models. All their newer A series and all their recent D and G series run on Intel.
No, there really isn't an equivalent. Which is more important, CPU power or GPU power?
The closest AMD in price with a GPU is the A6-6400K. It would be quite a bit better in the GPU department, but MASSIVELY worse in the CPU department. Not even close in CPU power. To get something that wont cripple you on CPU you would need to go up to the A8-6600K, but that is over $110 at the CAD stores I checked and would still be way worse in single thread CPU.
There are also the new Kabini CPUs and the top end of those, the Athlon 5350, is around $70. It would save you money on the MB (AM1 boards are cheap), but would be even worse than the A6-6400K in CPU and might not even match the G3240 in GPU.
Both the AMD E2 or Celeron 847 will smoke an Atom N450 in performance. Both are just fine for an average email/web surfing box assuming the rest of the system isn't complete crap. Both have way better graphics as well with the edge going to the E2, but the Celeron has much better CPU performance.
Clock speed doesn't mean everything. Remember when the P4 first came out and a P3 of 400-500 lower MHz could keep up with it? Sandy Bridge has very good IPC. I have a laptop with an i5-2467M and I have it configured to lock the speed at a mere 800 MHz when on battery and I don't even notice unless I try to do something CPU intensive. It does have an SSD an 8 GB of RAM though.
As 0123456 said, a Celeron 847 is about twice the speed of a 3.8GHz P4. The Celeron actually has MORE cache than the P4 in total (548K more to be exact). Plus it likely would have faster memory and a much faster interface to the rest of the system components.
You do realize that a Celeron 847 is way faster than the GP's P4 3.8 GHz? Don't let the Celeron name fool you, it is still a dual core sandy bridge chip, just clocked low.
The lowest end AMD E2s might get bested by the P4, but the higher clocked ones would still be a big improvement.
The bigger problem with most cheap laptops is the slow HD and lack of RAM which would cripple any CPU. Give a Celeron 847 an SSD and 4GB+ and it would be fine for most non CPU intensive or gaming tasks. Much better than the P4 for sure.
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.
The Core i7's are consumer-grade processors and are slower than the Xeon's the Mac Pros use
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.
All other operation systems running on similar hardware but having strict security and privileges proof you wrong. Even Linux existed at that time already and ran happily on that hardware.
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.
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.
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.
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.
Slashdot Mirror
The RPi 2 would have a good chance of handling gigabit if it had a proper NIC.
While certain apps like audio/video/photo editors performed really well on the G5, most real world apps were slower than on x86 processors at the time. When the Apple Intel developer test machines came out people raved about how much faster they were than the G5s. Those were only dual P4s, not even core. The 32 bit core machines were a big step up in performance over the G5s in every day use. Remember that back then single core performance was far more important than it is now. A dual core x86 chip of the time would "feel" much faster than a quad G5 outside of specific apps.
When Apple changed from 68K to PowerPC and from PowerPC to x86 there was a large jump in CPU performance each time. This allowed for the overhead of emulation without performance suffering too much. That performance jump doesn't exist now. In the best case ARM keeps up with the lowest end Intel chips, and Apple doesn't use the lowest end. ARM simply does not have the CPU grunt to emulate x86 without a massive performance hit.
You obviously have never compared SQL performance on Azure VS Amazon. To claim that an Azure P1 is even in the same ballpark performance wise as a db.m3.xlarge is laughable. A P3 (at $3461/month) is still an order of magnitude slower than a db.m3.large. There is NOTHING on Azure that can compete with with even a db.m3.medium simply because the I/O performance is so bad. Even if you fired up a D14 with SQL enterprise, any workload short of pure read-only would fall on its face once it tried to do any writes because the storage simply cannot keep up. I have extensively benchmarked using Microsoft's own SQLIO tool and at times found Azure storage giving less than one IOPS. Yes, less that one IO per second. Azure support confirmed that was normal and expected behavior.
You obviously also know nothing about networking to make such a comment about slammer. On Azure, SQL databases can be connected to from anywhere, any IP. There is no firewall at all. The IP filtering is all done in SQL code, which is extremely dangerous. A bug in the SQL code and you are owned. You cannot change this. RDS on AWS by default does not open the MSSQL port (1433 by default) the world. You must very explicitly both put an RDS instance into a public VPC subnet and then allow the world to connect. AWS will even tell you this is stupid and make you confirm. If there is a bug in the SQL code on RDS it is only an issue if you explicitly do something stupid. A stupid thing which is an unchangeable default on Azure.
AWS may not hold your hand as much as Azure, but everything it does is far more polished and performs far better. All of the features you mention for Azure AWS has and has had for far longer, except for direct Visual Studio publishing.
Auto scaling in AWS is far more powerful than Azure. You can scale based on several different metrics, not just CPU load. It is not "just there" like in Azure in that you must explicitly configure it, but it is worth it for the massively increased control. You can easily replace instances in an AWS load balancer with completely unrelated ones, something that is impossible in Azure
Staged publishing also exists in AWS as Elastic Beanstalk, which is more comparable to the standard PAAS Azure offering. You can switch websites instantly between any of your up to 200 environments, not just two (live and stage) like in Azure. Again, it doesn't hold your hand, but it is far more powerful and flexible.
MSSQL is an absolute joke in Azure which is sad given that it is run by MS. The performance is abysmal and it is Azure's cut down version of SQL, not the same as a real server. AWS lets you run your own on EC2, or use their managed RDS service. RDS offers point in time restores up to 35 days at any point even on their cheapest MSSQL express based offerings. Azure requires you to get their "premium" SQL at an inflated price for that level of backup. RDS is also still a full server without any missing functionally like SQL Azure. Security of SQL Azure is also non-existent. It does IP filtering at the DB level, no firewall. The next slammer type worm will infect every Azure DB including yours.
On top of all that performance is not even comparable between the two services. Azure purposefully compares their offerings to deprecated AWS instances because current AWS instances blow them out of the water in both price/performance and raw performance. I/O performance is basically non-existent in Azure, their managed storage system is pathetically slow.
Azure is designed to make it easy for a developer who has zero infrastructure and networking knowledge to get his code out into the world running on a shitty system. This is a very bad thing. A developer with even a tiny bit of infrastructure knowledge can see how bad Azure is.
If AMD performed the same as Intel VMware wouldn't offer a 50% discount for using AMD. See my comment above about MSSQL. Like MS, VMware is not going to offer discounts unless they have to. AMD CPUs perform so poorly that VMware has to offer a discount just to make them even remotely viable. Oracle also offers a discount for using AMD. If any company loves money it's Oracle and even they realize that performance on AMD sucks without a discount.
Since you are such an MS fanboy, here is the biggest MS example of how you are completely wrong:
Microsoft SQL Server
MSSQL is:
1. Compiled using Microsoft's compiler, not Intel's. No "cheating" there.
2. A fairly integer heavy workload which in theory would benefit AMD's module architecture.
The reality is Intel processors absolutely destroy AMDs in MSSQL performance. By more than 2 to 1. A mere Westmere based 2X Xeon X5690 12 core system beats a 32 core 2X Opteron 6282SE in TPC-E. Intel has 3 generations of newer Xeons since that benchmark was made, AMD has had only one newer Opteron (6300 series) which was a tiny increase at best.
The biggest nail in the AMD coffin is that MS gives you a discount on MSSQL licensing if you use AMD CPUs because the performance is so bad. MS is not known for leaving money on the table, if they could make AMDs perform like Intels they would.
Also Microsoft's Azure service used to be a big user of AMD CPUs. All their older A series VMs run on AMD 4100 series Opterons, which are pre buildozer failure models. All their newer A series and all their recent D and G series run on Intel.
Bad RAM could have corrupted the file as it was being written to disk. The file is corrupted all along, but not the disk/filesystem's fault
Or the file could have been corrupted in RAM on read, and would actually be fine if read on a working machine.
Or the disk has been replaced in those 6 years and the file was corrupted during the copy because of bad RAM
There are lots of possibilities for the file to get corrupted that don't involve the disk or filesystem.
No, there really isn't an equivalent. Which is more important, CPU power or GPU power?
The closest AMD in price with a GPU is the A6-6400K. It would be quite a bit better in the GPU department, but MASSIVELY worse in the CPU department. Not even close in CPU power. To get something that wont cripple you on CPU you would need to go up to the A8-6600K, but that is over $110 at the CAD stores I checked and would still be way worse in single thread CPU.
There are also the new Kabini CPUs and the top end of those, the Athlon 5350, is around $70. It would save you money on the MB (AM1 boards are cheap), but would be even worse than the A6-6400K in CPU and might not even match the G3240 in GPU.
Neither VNC or RDP require that the server have any local video capabilities. It is quite possible to run a Windows server headless.
RDP can remote single applications and has been able to for years. No full desktop required.
Both the AMD E2 or Celeron 847 will smoke an Atom N450 in performance. Both are just fine for an average email/web surfing box assuming the rest of the system isn't complete crap. Both have way better graphics as well with the edge going to the E2, but the Celeron has much better CPU performance.
Clock speed doesn't mean everything. Remember when the P4 first came out and a P3 of 400-500 lower MHz could keep up with it? Sandy Bridge has very good IPC. I have a laptop with an i5-2467M and I have it configured to lock the speed at a mere 800 MHz when on battery and I don't even notice unless I try to do something CPU intensive. It does have an SSD an 8 GB of RAM though.
As 0123456 said, a Celeron 847 is about twice the speed of a 3.8GHz P4. The Celeron actually has MORE cache than the P4 in total (548K more to be exact). Plus it likely would have faster memory and a much faster interface to the rest of the system components.
You do realize that a Celeron 847 is way faster than the GP's P4 3.8 GHz? Don't let the Celeron name fool you, it is still a dual core sandy bridge chip, just clocked low.
The lowest end AMD E2s might get bested by the P4, but the higher clocked ones would still be a big improvement.
The bigger problem with most cheap laptops is the slow HD and lack of RAM which would cripple any CPU. Give a Celeron 847 an SSD and 4GB+ and it would be fine for most non CPU intensive or gaming tasks. Much better than the P4 for sure.
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.
The Core i7's are consumer-grade processors and are slower than the Xeon's the Mac Pros use
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.
All other operation systems running on similar hardware but having strict security and privileges proof you wrong. Even Linux existed at that time already and ran happily on that hardware.
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.
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.