I don't know what you mean by local redundancy or separate-system redundancy, so I can't answer it. The Google File System paper says "By default, we store three replicas". Each replica is on a different server, although they are probably all in the same datacenter. This is a higher level of redundancy than RAID 10.
For example, I am not privy to Google's internal workings, but I very much doubt they have guaranteed full redundancy for every single video that has ever been uploaded to YouTube. Admittedly, they don't use RAID, they use a custom FS, but the principle is the same.
You're right... Google actually uses triple redundancy, and that's cheaper than "enterprise-grade" anything.
When you lose a disk ZFS has to rebuild and unless your system was over-engineered to begin with, there will be performance degradation. But now there's a pretty graph showing you how big the degradation is.
the hardware to drive 48 SATA drives and not saturate the bus still isn't cheap.
Actually, SAS HBAs and JBODs (which is what Sun is using) are cheap; that's why it's odd that Sun is charging so much. For example, the 7210 is the same hardware as the X4540 yet it appears to cost much more.
You joke, but I've used dd for all sorts of tasks: backups, disk cloning/expansion (with gparted), disk benchmarking, etc. Just be sure to set bs=1M for good performance.
IIRC, Y was not based on a composited architecture, so by today's standards it sucks. It might have made a nice successor to X back in the BeOS days, though.
You need to enable IPv6 when IPv4 runs out around 2011 so that you can communicate with IPv6-only users. There's no benefit to turning it on early (unless you want to do debugging for vendors). Articles about how some country or another is "ahead" or "behind" in IPv6 are misguided because they're measuring the wrong thing. What is important is not who is running IPv6 today, but who is buying IPv6-capable equipment today so that they can turn it on "for free" in 2011.
Also, the summary propagates the old China IPv4 myth; in reality China will run out of IPv4 at the same time as the rest of the world.
Unless the reason you are using it is to satisfy a checklist from hollywood.
Yeah, and after Hollywood reads a Reuters article about how your system is cracked, you'll probably have to release a new version to convince them that something is being done. And the charade rolls on.
There are two separate issues mentioned in the article.
1. HTTP and RTMP are not encrypted and thus it's trivial to record any video sent over these protocols. This is well-documented and I'd hardly consider it a flaw. Flash 9u3 has DRM (RTMPE+verification), but most Web sites don't bother to use it.
2. Apparently Amazon's movie store server will send the whole video whether the customer has purchased it or not. This is a bug, but it's Amazon's fault not Adobe's and Amazon should be able to fix it easily enough. Also, they're apparently not using all the DRM features available in Flash so their videos aren't as protected as they could be.
AFAIK Flash DRM hasn't been cracked yet because no one uses it. I'm not an advocate of DRM, but as a practical matter I find it works better when you actually turn it on.
It's probably buffering faster than real time (I didn't realize Windows Media had this feature), since Netflix streams are documented as 3 Mbps. In that case it is possible to trigger throttling (unnecessarily), so you have to hope that you have enough buffering to survive any packet loss.
I don't know what you mean by local redundancy or separate-system redundancy, so I can't answer it. The Google File System paper says "By default, we store three replicas". Each replica is on a different server, although they are probably all in the same datacenter. This is a higher level of redundancy than RAID 10.
For example, I am not privy to Google's internal workings, but I very much doubt they have guaranteed full redundancy for every single video that has ever been uploaded to YouTube. Admittedly, they don't use RAID, they use a custom FS, but the principle is the same.
You're right... Google actually uses triple redundancy, and that's cheaper than "enterprise-grade" anything.
When you lose a disk ZFS has to rebuild and unless your system was over-engineered to begin with, there will be performance degradation. But now there's a pretty graph showing you how big the degradation is.
An x86 server motherboard is also cheap.
the hardware to drive 48 SATA drives and not saturate the bus still isn't cheap.
Actually, SAS HBAs and JBODs (which is what Sun is using) are cheap; that's why it's odd that Sun is charging so much. For example, the 7210 is the same hardware as the X4540 yet it appears to cost much more.
Google has been opening up their platform already; App Engine gives developers (some) access to GFS, BigTable, auto-scaling magic, etc.
You joke, but I've used dd for all sorts of tasks: backups, disk cloning/expansion (with gparted), disk benchmarking, etc. Just be sure to set bs=1M for good performance.
IIRC, Y was not based on a composited architecture, so by today's standards it sucks. It might have made a nice successor to X back in the BeOS days, though.
xclock? xeyes?
I'm sure he's already started on an open-source Mono-based Azure clone.
It looks like Azure uses the .NET sandbox and Hyper-V.
I agree that SSDs are inevitable... for primary storage. Once I've switched my laptop over to SSD I'll still use a hard disk for backup, though.
The chance of a double motor failure is much lower than a motor failure + uncorrectable read error, which is what the article is about.
SSDs are going to become a very viable option for the home backup
Yeah, I love paying much more for my backup than for my primary storage.
SCTP can't be that much better than TCP in this case; it's still based on retransmitting dropped frames.
That's called Data Center energy Productivity (DCeP), but you can't compare it between data centers so it's not very useful for marketing purposes.
Those are quite expensive cameras; people who have those also have MBPs. Cameras under $2000 (AVCHD) all use USB.
Emulating 7 3.2 GHz SPEs with 16 1.5 GHz SPEs connected with virtually no bandwidth sounds difficult.
SpursEngine has 1/4th the performance of Cell; you do the math.
SpursEngine is not a partial good Cell; it's a different chip.
You need to enable IPv6 when IPv4 runs out around 2011 so that you can communicate with IPv6-only users. There's no benefit to turning it on early (unless you want to do debugging for vendors). Articles about how some country or another is "ahead" or "behind" in IPv6 are misguided because they're measuring the wrong thing. What is important is not who is running IPv6 today, but who is buying IPv6-capable equipment today so that they can turn it on "for free" in 2011.
Also, the summary propagates the old China IPv4 myth; in reality China will run out of IPv4 at the same time as the rest of the world.
Come on man, give someone else a chance to ride.
Unless the reason you are using it is to satisfy a checklist from hollywood.
Yeah, and after Hollywood reads a Reuters article about how your system is cracked, you'll probably have to release a new version to convince them that something is being done. And the charade rolls on.
There are two separate issues mentioned in the article.
1. HTTP and RTMP are not encrypted and thus it's trivial to record any video sent over these protocols. This is well-documented and I'd hardly consider it a flaw. Flash 9u3 has DRM (RTMPE+verification), but most Web sites don't bother to use it.
2. Apparently Amazon's movie store server will send the whole video whether the customer has purchased it or not. This is a bug, but it's Amazon's fault not Adobe's and Amazon should be able to fix it easily enough. Also, they're apparently not using all the DRM features available in Flash so their videos aren't as protected as they could be.
AFAIK Flash DRM hasn't been cracked yet because no one uses it. I'm not an advocate of DRM, but as a practical matter I find it works better when you actually turn it on.
It's probably buffering faster than real time (I didn't realize Windows Media had this feature), since Netflix streams are documented as 3 Mbps. In that case it is possible to trigger throttling (unnecessarily), so you have to hope that you have enough buffering to survive any packet loss.