[i didn't RTFA]. Packet loss/retransmits doesn't matter much, IMHO. In GP example, host B could use some explicit out-of-band signaling to tell A and C what packets are used as xor context. Like, via IP options / IP ID field or something.
I have several gentoo coloboxes in production, the oldest of them is 2.5 years old. Switched profiles 2 times, upgraded gcc from 3.3 to 3.4, kernel from 2.4 to 2.6. I had to visit the colocation building two times: to install the box and to add an HDD to it. Yet the system is up-to-date and reasonably patched against the recent vulnerabilities. I don't have to deal with all that "end-of-support for release XX.YY" crap. I almost never have to resort to building my own packages manually these days, because I can just tweak USE flags (which also means I don't have to maintain my own apache build or my own perl build or whatever else I need). When some new security vulnerability is disclosed and I have to check my systems for it, I usually find them patched against it during the last emerge -u.
Good luck getting any of the above with a binary distro.
I have no idea how the author of TFA managed to ruin his system multiple times during one year. Looks like someone is seriously out of clue.
reality check, hmm. so, where exactly is `reality' there? the article doesn't say a single word about the Cell processor architecture. author's just being nitpicky about Blachford's analysis.
well, let's be nitpicky too, then.
1st paragraph summary: "Blachford sucks at understanding of basic computer architecture". ok, let's see.
2nd p. summary: "estimated benchmarks are all speculative (and, thus, it's hogwash)". oh great, mr. Hannibal probably knows how to get real (non-speculative) benchmarks for Cell. and nevermind Blachford says: "This is something of a "calculated guess", again based on the theoretical maximum computing power being achieved (in 4 Cells). It makes a lot of assumptions which may be in error so I will not be the least bit surprised if this figure is miles out...".
3rd p. summary: "Blachford talks about `no cache' and `local memory', but actually `local memory' == `cache'". someone obviously missed the detailed explaination in Blachford's article about exactly how local memory in Cell is different from cache (with terminology issues explicitly covered).
4th p. summary: "Blachford also declares that the longstanding problems inherent in code parallelism and multithreaded programming are now solved, because the Cell will just miraculously do all this stuff for you via fancy compiler and process scheduling tricks.".
from what i can see, Blachford mentions the word `compiler' in his article exactly once: "Cells will have compilers just like everything else".
and Blachford also writes:
The Cell Compiler Will Magically Make The Code Parallel
This is not true and I didn't say this. You still have to break up problems into software Cells. I still cannot figure out why people think I said this.
oh well. Anyway, I could go on, but I'll stop here. You get the idea.
Slashdot Mirror
[i didn't RTFA].
Packet loss/retransmits doesn't matter much, IMHO. In GP example, host B could use some explicit out-of-band signaling to tell A and C what packets are used as xor context. Like, via IP options / IP ID field or something.
I have several gentoo coloboxes in production, the oldest of them is 2.5 years old. Switched profiles 2 times, upgraded gcc from 3.3 to 3.4, kernel from 2.4 to 2.6. I had to visit the colocation building two times: to install the box and to add an HDD to it. Yet the system is up-to-date and reasonably patched against the recent vulnerabilities. I don't have to deal with all that "end-of-support for release XX.YY" crap. I almost never have to resort to building my own packages manually these days, because I can just tweak USE flags (which also means I don't have to maintain my own apache build or my own perl build or whatever else I need). When some new security vulnerability is disclosed and I have to check my systems for it, I usually find them patched against it during the last emerge -u.
Good luck getting any of the above with a binary distro.
I have no idea how the author of TFA managed to ruin his system multiple times during one year. Looks like someone is seriously out of clue.
well, let's be nitpicky too, then.
oh well. Anyway, I could go on, but I'll stop here. You get the idea.