Re: CoCo torrent?
Allen Huffman via Coco <[email protected]> Wed, 3 Jun 2026 08:35:47 -0500
| Newsgroups | gmane.comp.hardware.tandy.coco |
|---|---|
| Message-ID | <[email protected]> |
--===============8484899316124003083== Content-Type: multipart/alternative; boundary="Apple-Mail=_0311FA1A-3CAC-4577-9FC1-95F65504A862" --Apple-Mail=_0311FA1A-3CAC-4577-9FC1-95F65504A862 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 3, 2026, at 1:01=E2=80=AFAM, RETRO Innovations via Coco = <[email protected]> wrote: >=20 > As someone else noted, I think it's best to let some large site host = the repo. That way, bandwidth is not an issue. >=20 > But, for your concern, yes, if 100 people want the entire thing and = they have none of it, it's a drain. But, once the people get the first = dload, updating a repo is a "diff" type operation, so only changes get = sent. Such is a much smaller issue concerning bandwidth. >=20 Our main goal should be data replication and availability. A central = service is fine, but I think of all the Google services I have used over = the years that they just shut down. Likewise, when I visit my old = websites and the Links pages on them, almost all those sites = (guestbooks, web rings, hit counters) are gone. Having a simple web interface like CoCo Archive is a must, but how those = files exist behind it is less important. For example, I have a torrent = to the GIMI chip de-cap scans that is on a dropbox, and my torrent = points to those files. So it is available to anyone with Dropbox (if = they have enough room to sync the files), or via the Dropbox web = interface, or via Torrent (if we can ever get that working again). There was a tech called BitTorrent Sync that I never looked into. = Something that would let a bunch of us distribute the files, and then = any front end could be on top of it at a larger site, would give us data = redundancy. But if BTSync still has the same issue of =E2=80=9Cadd a = file, now you need a new torrent=E2=80=9D then that doesn=E2=80=99t make = it easy. As one who uses git for my day job, I love that idea. As a normal user who doesn=E2=80=99t want to mess with a bunch of = installs just to download a copy of January 1983 Rainbow, I might not. I like the direction this discussion is heading. =E2=80=94 A --Apple-Mail=_0311FA1A-3CAC-4577-9FC1-95F65504A862 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;"><div><blockquote type=3D"cite"><div>On = Jun 3, 2026, at 1:01=E2=80=AFAM, RETRO Innovations via Coco = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta charset=3D"UTF-8"><p = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;">As = someone else noted, I think it's best to let some large site host the = repo. That way, bandwidth is not an issue.</p><p = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;">But, for = your concern, yes, if 100 people want the entire thing and they have = none of it, it's a drain. But, once the people get the first = dload, updating a repo is a "diff" type operation, so only changes get = sent. Such is a much smaller issue concerning = bandwidth.</p></div></blockquote></div><div>Our main goal should be data = replication and availability. A central service is fine, but I think of = all the Google services I have used over the years that they just shut = down. Likewise, when I visit my old websites and the Links pages on = them, almost all those sites (guestbooks, web rings, hit counters) are = gone.</div><div><br></div><div>Having a simple web interface like CoCo = Archive is a must, but how those files exist behind it is less = important. For example, I have a torrent to the GIMI chip de-cap scans = that is on a dropbox, and my torrent points to those files. So it is = available to anyone with Dropbox (if they have enough room to sync the = files), or via the Dropbox web interface, or via Torrent (if we can ever = get that working again).</div><div><br></div><div>There was a tech = called BitTorrent Sync that I never looked into. Something that would = let a bunch of us distribute the files, and then any front end could be = on top of it at a larger site, would give us data redundancy. But if = BTSync still has the same issue of =E2=80=9Cadd a file, now you need a = new torrent=E2=80=9D then that doesn=E2=80=99t make it = easy.</div><div><br></div><div>As one who uses git for my day job, I = love that idea.</div><div><br></div><div>As a normal user who doesn=E2=80=99= t want to mess with a bunch of installs just to download a copy of = January 1983 Rainbow, I might not.</div><div><br></div><div>I like the = direction this discussion is heading.</div><div><br></div><div><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>=E2=80=94 A</div><div><br></div></body></html>= --Apple-Mail=_0311FA1A-3CAC-4577-9FC1-95F65504A862-- --===============8484899316124003083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Coco mailing list [email protected] http://listserv.adelphi.edu/cgi-bin/mailman/listinfo/coco --===============8484899316124003083==--