I noticed that ngolf at <a href="http://zonnet.nl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">zonnet.nl</a> was thankful that he was able to &quot;download&quot; instead of &quot;torrent&quot;, however I am not.
<br>(<a href="http://lists.ourproject.org/pipermail/musix-users/2006-December/000432.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.ourproject.org/pipermail/musix-users/2006-December/000432.html</a>)<br><br><a href="mailto:musix-users-owner@lists.ourproject.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"></a><a href="mailto:musix-users-owner@lists.ourproject.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

</a>&quot;Downloading&quot; (http/ftp) relies on the underlying TCP layer for error control, which uses a weak checksum by modern standards.<br><br>In addition to distributing transmission bandwidth, modern peer-to-peer protocols provide an additional layer of error control.
<br><br>Long story short - I have a corrupt ISO file, which would Not have happened with Bit Torrent, (or Gnutella, or eDonkey)<br><br>Maybe one of you could send me the output from this command:<br><br>for a in `seq 0 697`; do (dd if=MusixGNU+Linux-
0.79b19.iso bs=1M count=1 skip=$a 2&gt;/dev/null | md5sum &gt;&gt; MusixGNU+Linux-0.79b19.md5sum.1M); done<br><br>And I can manually recover the file; maybe downloading only 1 meg to repair the file.<br><br>Otherwise, I&#39;ll have to begin downloading the entire 697 Megs all over again.
<br><br>