Which effectively means that spinrite is incapable of any recovery in that situation. If it can't relocate data it has no ability to put it somewhere else. You trust it to put the recovered data back in the SAME bad sector? Spinrite can't fix bad sectors, all that magnetic crap it claims to be able to do is just that, crap. Seriously, run it against a USB flash drive sometime and watch all the BS magic magnetic info it gives you.
No, that is not fine. First off, if the disk is damaged, why would you trust a different spot? If the sector spinrite writes to is also bad you have recovered nothing. If the disk is really bad there may not be any sectors that are safe to write to.
Second, if the filesystem is damaged or spinrite doesn't understand it (ie, anything other than FAT), then it has no idea of what sectors contain useful data and which are free. Spinrite can very easily write over other data that you want to recover.
The recovery in Spinrite is destructive. After "successfully" reading a sector, it writes the recovered data to *THE SAME DISK*. That's a big data recovery fail.
I know Wayland doesn't have RDP or apparently any remote capability right now. My point was that RDP demonstrates that a "bolt on after the fact" can not only work really well, but can work better than something like X that was designed for network transparency.
X may have been designed and built from the ground up with network transparency, but that doesn't mean it's actually any good at it.
I don't know if RDP has feature parity with X, but as far as I can tell everything that is actually used in X is possible in RDP. Patents I have no idea, but there are some non MS things that implement it already. Virtualbox for example.
RPD demonstrates just how old and outdated X really is. RDP was bolted on after the fact yet is way better than X remotely. If Wayland adds some way of using applications remotely it should emulate RDP, not X
In what way is X better than RDP? RDP is MUCH faster, handles network issues, can be moved between systems or local displays, handles sound, etc. It really is a much better system in the real world.
Don't know about OSX, but Windows applications can be displayed remotely just like X apps. Even on X with an RDP client. Despite the common way of sending the whole desktop, individual Windows apps can be displayed remotely. It's actually much better than X because RDP is much faster, can move running apps from one display to another and will survive network drops.
I know I'll probably get modded down for this, but anyway...
Microsoft (and/or Citrix) seems to have done a pretty decent job of bolting on remote display to Windows after the fact. In most real-world ways RDP is much nicer than remote X.
Except this specific ARM CPU is not similar to a P4 or low-clocked Core at all in integer or anything. "ARM" is not one CPU anymore than "x86" is. There are some pretty fast ARM chips out there, but not this one. The specific Marvell ARM in the DreamPlug/SheevaPlug/GuruPlug is not fast at all, Benchmarks put it at a mid to low end P3 in integer. Slower than most Atoms by far. A cheap atom netbook would have significantly better performance without much more power draw, plus you get a screen an hard drive as well.
I'd wait for benchmarks on this before auto-bashing it in favor of the Intel SSDs, which are are meeting up with decent competition these days.
There are SSDs that are performance competitive with Intel. They are not made by Toshiba. Unless Toshiba has made massive gains over previous models then this drive will not be competitive with Intel or other good SSDs. Most if not all "Toshiba" SSD controller chips are re-baged JMicron ones.
Well, the interface isn't proprietary so there's no reason 3rd parties can't release higher capacity SSDs in the future.
Not proprietary != widely used.
And I'd like to see where people get the idea that Apple hasn't added TRIM support to OS X?
The only OSes that currently support TRIM are Windows 7, Server 2008 R2, Linux with kernel 2.6.33 or greater and recent OpenSolaris. OSX does not support it and Apple's only comments have been a long the lines of "we'll get to that, eventually, maybe".
I've seen this posted before in other Atom stories and it's 100% BS. The Atom is a full CPU, they did not shift any features into the northbridge as you claim. The 945 chip often used on Atom motherboards has been around for a while, and was used in systems before the Atom even existed. The 945 is just not very power efficient so that's why it needs more cooling than the CPU.
The Atom can be paired with other northbridge chips, notably Nvidia's ION. If part of the CPU was in the 945 chip as you claim this would be impossible.
I've been simplifying by talking just about h.264 decoding, but that's not the whole problem. On OSX, third parties can't even use basic stuff like overlay properly. That's really basic stuff, but still vitally important to low CPU use when playing videos. Overlay has been around since at least the Win 3.1 days and hardware of that era.
Even if your video card doesn't support h.264 decoding, using overlay will still drastically reduce CPU playback of h.264 content. OSX simply doesn't allow it, at least until this new API.
That's not the case at all. Why does VLC use so much less CPU on Windows/Linux than on OSX if everything is perfectly cross platform? Sure, it doesn't use directshow on Windows, but it does use the lower level video acceleration APIs to great benefit. Same deal on Linux, it uses the video acceleration that X11 provides. The equivalent APIs on OSX just don't work.
Your argument also doesn't account for Perian, which is most certainly OSX only and not cross platform. Perian is a Quicktime plug-in and very much tied to Apple's APIs. Feed H.264 out of a MOV file to the Quicktime decoder and it will enable hardware acceleration. Feed that EXACT SAME STREAM, except out of a MKV or AVI through Perian to the EXACT SAME DECODER in Quicktime and hardware acceleration gets disabled because Perian is not "blessed" by Apple.
Now play that same video in VLC on Windows or Linux. Your CPU usage will be way less than in OSX. Just because Flash sucks, but so does Apple's (old) video playback APIs.
VLC, Mplayer, Perrian, etc on OSX can play better than Flash, that is not the same thing as "perfectly fine". VLC and Mplayer a quite optimized so with a fast enough CPU they can grunt through playback without help. That doesn't mean it's working fine. Use VLC or Mplayer on Windows or Linux on the same hardware and the CPU use is drastically reduced because hardware acceleration works.
Just because Flash sucks doesn't absolve Apple of the problems that are their fault.
If everything was "perfectly fine" why did Apple release a new API that actually works and why are all the third party players updating to use it?
I'm not going to speculate on Apple's motives or intentions with this. I don't know if it was intentional or an oversight.
The simple fact of the matter is Apple has more than one API that it documents will do video acceleration. Only the one released very recently actually works.
Perian is a pluggin for Quicktime. It most certainly is using Apple's media framework. All it does is pass the SAME video streams you might find in a MOV file to the Quicktime decoders. It doesn't have a H.264 decoder of it's own like VLC, it just passes the data to Quicktime's H.264 decoder. Yet Quicktime disables hardware decoding because it did not come from a "blessed" source.
Still that misses the point. The so-called acceleration APIs are supposed to work outside of Quicktime too. Yet they don't. VLC has tried to use the official APIs and they just don't work. It's not a simple as calling the Quicktime code paths or not. Even basic things like video overlays don't work with the old APIs on OSX.
If the old APIs worked then why did Apple just release a "new" API that does?
The problem is those previous APIs don't actually work. Read through the VLC forums sometime on the problems they've had implementing acceleration on OSX, it's quite enlightening. Nothing that Apple hasn't blessed can use the old APIs and actually have the hardware acceleration work.
Now, Flash is a horribly programed pile of crap which is why it uses 3X the CPU of VLC to decode the same video on OSX. But neither of them are using hardware acceleration because it's impossible for a third party to do so on OSX, at least prior to this new API. Compare VLC on OSX to Windows or Linux on the same hardware. It still uses a massive amount more CPU on OSX than the others.
Then why didn't VLC, Mplayer, perrian etc use the official APIs? None of them had hardware acceleration on OSX either until this latest API release. Read up on the problem. The old APIs simply do not work.
No, you're not getting it. The APIs like QTKit and CoreAnimation CLAIM to support video acceleration, but they don't. At least they don't to anything except what Apple allows.
For example:
- H.264 video in a Quicktime container played by an Apple player = Hardware acceleration enabled.
- The exact same H.264 stream repackaged in an non-Quicktime container (AVI, MKV etc) = Hardware acceleration disabled.
I'm sure the developers of VLC, Mplayer, Perrian and the like would have loved to use QTKit and CoreAnimation like you suggest. But they can't because those APIs simply do not work.
No, the previous hardware acceleration APIs on OSX do NOT work. Check the problems VLC has had. Nothing except officially blessed Quicktime components could do H.264 acceleration on OSX until now despite Apple's claims. Even other plugins working through the Quicktime framework were denied access.
Flash is a piece of crap, but lack of hardware acceleration on OSX is 100% Apple's fault, not Adobe's. Even if you hate Adobe/Flash this new API access is a good thing because VLC and the like now have working hardware acceleration as well.
There are a multitude of aftermarket CPU coolers which are much quieter than the stock ones from Intel or AMD. Some chips can even be run passive with the right heatsink. Take a look at the reviews on http://www.silentpcreview.com/
The Pinetrail Atoms do NOT use the GMA500. They use the GMA3150, which is a cut down version of the GMA3000/GMA3100 which themselves are based on the GMA950. They are not fast, but work fine with Linux as long as your Intel drivers are up to date.
Only Z series Atoms paired with the US15W chipset have the GMA500.
I've never used them, but Supermicro does make a couple of boards with Atom CPUs and ICH9R southbridges. 6 SATA ports and a PCIe x4 (x16 mechanical) for further expansion.
Even if your "fuzzy" numbers are close enough (all the ARM vs X86 benchmarks I've seen are even more in X86's favor), the AMD X2 is not even close the best performance-per-watt X86 CPU.
A mobile Core 2 or i5 have TDPs or 35W or lower and almost never draw anywhere close to that in actual use. They are also significantly faster than an AMD X2. They would easily beat the A8 in performance per watt if your numbers are correct.
Slashdot Mirror
Which effectively means that spinrite is incapable of any recovery in that situation. If it can't relocate data it has no ability to put it somewhere else. You trust it to put the recovered data back in the SAME bad sector? Spinrite can't fix bad sectors, all that magnetic crap it claims to be able to do is just that, crap. Seriously, run it against a USB flash drive sometime and watch all the BS magic magnetic info it gives you.
No, that is not fine. First off, if the disk is damaged, why would you trust a different spot? If the sector spinrite writes to is also bad you have recovered nothing. If the disk is really bad there may not be any sectors that are safe to write to.
Second, if the filesystem is damaged or spinrite doesn't understand it (ie, anything other than FAT), then it has no idea of what sectors contain useful data and which are free. Spinrite can very easily write over other data that you want to recover.
The recovery in Spinrite is destructive. After "successfully" reading a sector, it writes the recovered data to *THE SAME DISK*. That's a big data recovery fail.
Apple always changed to CPUs that were much faster than the old ones, so emulation was possible. This is the reverse.
I know Wayland doesn't have RDP or apparently any remote capability right now. My point was that RDP demonstrates that a "bolt on after the fact" can not only work really well, but can work better than something like X that was designed for network transparency.
X may have been designed and built from the ground up with network transparency, but that doesn't mean it's actually any good at it.
I don't know if RDP has feature parity with X, but as far as I can tell everything that is actually used in X is possible in RDP. Patents I have no idea, but there are some non MS things that implement it already. Virtualbox for example.
RPD demonstrates just how old and outdated X really is. RDP was bolted on after the fact yet is way better than X remotely. If Wayland adds some way of using applications remotely it should emulate RDP, not X
In what way is X better than RDP? RDP is MUCH faster, handles network issues, can be moved between systems or local displays, handles sound, etc. It really is a much better system in the real world.
Don't know about OSX, but Windows applications can be displayed remotely just like X apps. Even on X with an RDP client. Despite the common way of sending the whole desktop, individual Windows apps can be displayed remotely. It's actually much better than X because RDP is much faster, can move running apps from one display to another and will survive network drops.
I know I'll probably get modded down for this, but anyway... Microsoft (and/or Citrix) seems to have done a pretty decent job of bolting on remote display to Windows after the fact. In most real-world ways RDP is much nicer than remote X.
Except this specific ARM CPU is not similar to a P4 or low-clocked Core at all in integer or anything. "ARM" is not one CPU anymore than "x86" is. There are some pretty fast ARM chips out there, but not this one. The specific Marvell ARM in the DreamPlug/SheevaPlug/GuruPlug is not fast at all, Benchmarks put it at a mid to low end P3 in integer. Slower than most Atoms by far. A cheap atom netbook would have significantly better performance without much more power draw, plus you get a screen an hard drive as well.
I'd wait for benchmarks on this before auto-bashing it in favor of the Intel SSDs, which are are meeting up with decent competition these days.
There are SSDs that are performance competitive with Intel. They are not made by Toshiba. Unless Toshiba has made massive gains over previous models then this drive will not be competitive with Intel or other good SSDs. Most if not all "Toshiba" SSD controller chips are re-baged JMicron ones.
Well, the interface isn't proprietary so there's no reason 3rd parties can't release higher capacity SSDs in the future.
Not proprietary != widely used.
And I'd like to see where people get the idea that Apple hasn't added TRIM support to OS X?
The only OSes that currently support TRIM are Windows 7, Server 2008 R2, Linux with kernel 2.6.33 or greater and recent OpenSolaris. OSX does not support it and Apple's only comments have been a long the lines of "we'll get to that, eventually, maybe".
I've seen this posted before in other Atom stories and it's 100% BS. The Atom is a full CPU, they did not shift any features into the northbridge as you claim. The 945 chip often used on Atom motherboards has been around for a while, and was used in systems before the Atom even existed. The 945 is just not very power efficient so that's why it needs more cooling than the CPU.
The Atom can be paired with other northbridge chips, notably Nvidia's ION. If part of the CPU was in the 945 chip as you claim this would be impossible.
I've been simplifying by talking just about h.264 decoding, but that's not the whole problem. On OSX, third parties can't even use basic stuff like overlay properly. That's really basic stuff, but still vitally important to low CPU use when playing videos. Overlay has been around since at least the Win 3.1 days and hardware of that era.
Even if your video card doesn't support h.264 decoding, using overlay will still drastically reduce CPU playback of h.264 content. OSX simply doesn't allow it, at least until this new API.
That's not the case at all. Why does VLC use so much less CPU on Windows/Linux than on OSX if everything is perfectly cross platform? Sure, it doesn't use directshow on Windows, but it does use the lower level video acceleration APIs to great benefit. Same deal on Linux, it uses the video acceleration that X11 provides. The equivalent APIs on OSX just don't work.
Your argument also doesn't account for Perian, which is most certainly OSX only and not cross platform. Perian is a Quicktime plug-in and very much tied to Apple's APIs. Feed H.264 out of a MOV file to the Quicktime decoder and it will enable hardware acceleration. Feed that EXACT SAME STREAM, except out of a MKV or AVI through Perian to the EXACT SAME DECODER in Quicktime and hardware acceleration gets disabled because Perian is not "blessed" by Apple.
Now play that same video in VLC on Windows or Linux. Your CPU usage will be way less than in OSX. Just because Flash sucks, but so does Apple's (old) video playback APIs.
VLC, Mplayer, Perrian, etc on OSX can play better than Flash, that is not the same thing as "perfectly fine". VLC and Mplayer a quite optimized so with a fast enough CPU they can grunt through playback without help. That doesn't mean it's working fine. Use VLC or Mplayer on Windows or Linux on the same hardware and the CPU use is drastically reduced because hardware acceleration works.
Just because Flash sucks doesn't absolve Apple of the problems that are their fault.
If everything was "perfectly fine" why did Apple release a new API that actually works and why are all the third party players updating to use it?
I'm not going to speculate on Apple's motives or intentions with this. I don't know if it was intentional or an oversight.
The simple fact of the matter is Apple has more than one API that it documents will do video acceleration. Only the one released very recently actually works.
Perian is a pluggin for Quicktime. It most certainly is using Apple's media framework. All it does is pass the SAME video streams you might find in a MOV file to the Quicktime decoders. It doesn't have a H.264 decoder of it's own like VLC, it just passes the data to Quicktime's H.264 decoder. Yet Quicktime disables hardware decoding because it did not come from a "blessed" source.
Still that misses the point. The so-called acceleration APIs are supposed to work outside of Quicktime too. Yet they don't. VLC has tried to use the official APIs and they just don't work. It's not a simple as calling the Quicktime code paths or not. Even basic things like video overlays don't work with the old APIs on OSX.
If the old APIs worked then why did Apple just release a "new" API that does?
The problem is those previous APIs don't actually work. Read through the VLC forums sometime on the problems they've had implementing acceleration on OSX, it's quite enlightening. Nothing that Apple hasn't blessed can use the old APIs and actually have the hardware acceleration work.
Now, Flash is a horribly programed pile of crap which is why it uses 3X the CPU of VLC to decode the same video on OSX. But neither of them are using hardware acceleration because it's impossible for a third party to do so on OSX, at least prior to this new API. Compare VLC on OSX to Windows or Linux on the same hardware. It still uses a massive amount more CPU on OSX than the others.
Then why didn't VLC, Mplayer, perrian etc use the official APIs? None of them had hardware acceleration on OSX either until this latest API release. Read up on the problem. The old APIs simply do not work.
No, you're not getting it. The APIs like QTKit and CoreAnimation CLAIM to support video acceleration, but they don't. At least they don't to anything except what Apple allows.
For example:
- H.264 video in a Quicktime container played by an Apple player = Hardware acceleration enabled.
- The exact same H.264 stream repackaged in an non-Quicktime container (AVI, MKV etc) = Hardware acceleration disabled.
I'm sure the developers of VLC, Mplayer, Perrian and the like would have loved to use QTKit and CoreAnimation like you suggest. But they can't because those APIs simply do not work.
No, the previous hardware acceleration APIs on OSX do NOT work. Check the problems VLC has had. Nothing except officially blessed Quicktime components could do H.264 acceleration on OSX until now despite Apple's claims. Even other plugins working through the Quicktime framework were denied access.
Flash is a piece of crap, but lack of hardware acceleration on OSX is 100% Apple's fault, not Adobe's. Even if you hate Adobe/Flash this new API access is a good thing because VLC and the like now have working hardware acceleration as well.
There are a multitude of aftermarket CPU coolers which are much quieter than the stock ones from Intel or AMD. Some chips can even be run passive with the right heatsink. Take a look at the reviews on http://www.silentpcreview.com/
The Pinetrail Atoms do NOT use the GMA500. They use the GMA3150, which is a cut down version of the GMA3000/GMA3100 which themselves are based on the GMA950. They are not fast, but work fine with Linux as long as your Intel drivers are up to date.
Only Z series Atoms paired with the US15W chipset have the GMA500.
I've never used them, but Supermicro does make a couple of boards with Atom CPUs and ICH9R southbridges. 6 SATA ports and a PCIe x4 (x16 mechanical) for further expansion.
Even if your "fuzzy" numbers are close enough (all the ARM vs X86 benchmarks I've seen are even more in X86's favor), the AMD X2 is not even close the best performance-per-watt X86 CPU.
A mobile Core 2 or i5 have TDPs or 35W or lower and almost never draw anywhere close to that in actual use. They are also significantly faster than an AMD X2. They would easily beat the A8 in performance per watt if your numbers are correct.