Re: CoCo torrent?
RETRO Innovations via Coco <[email protected]> Wed, 3 Jun 2026 10:11:49 -0500
| Newsgroups | gmane.comp.hardware.tandy.coco |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============1886157512077254941== Content-Type: multipart/alternative; boundary="------------YznqKtE4ke6qbOUohsgqMK51" Content-Language: en-US This is a multi-part message in MIME format. --------------YznqKtE4ke6qbOUohsgqMK51 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 6/3/2026 8:35 AM, Allen Huffman via Coco wrote: >> On Jun 3, 2026, at 1:01=E2=80=AFAM, RETRO Innovations via Coco=20 >> <[email protected]> wrote: >> >> As someone else noted, I think it's best to let some large site host=20 >> the repo.=C2=A0 That way, bandwidth is not an issue. >> >> But, for your concern, yes, if 100 people want the entire thing and=20 >> they have none of it, it's a drain.=C2=A0 But, once the people get the= =20 >> first dload, updating a repo is a "diff" type operation, so only=20 >> changes get sent. Such is a much smaller issue concerning bandwidth. >> > Our main goal should be data replication and availability. A central=20 > service is fine, but I think of all the Google services I have used=20 > over the years that they just shut down. Likewise, when I visit my old= =20 > websites and the Links pages on them, almost all those sites=20 > (guestbooks, web rings, hit counters) are gone. The nice thing about git is that the protocol will survive, even if the=20 services do not.=C2=A0 If a service is used, and the service is removed, t= o=20 owner of the repo need only push to a new service.=C2=A0 I have not checke= d,=20 but it's possible one can use URL forwarders as the URL, so repo pulls=20 will not be affected (the URL they use would be a forwarding one, and=20 someone just updates it) > > Having a simple web interface like CoCo Archive is a must, but how=20 > those files exist behind it is less important. For example, I have a=20 > torrent to the GIMI chip de-cap scans that is on a dropbox, and my=20 > torrent points to those files. So it is available to anyone with=20 > Dropbox (if they have enough room to sync the files), or via the=20 > Dropbox web interface, or via Torrent (if we can ever get that working= =20 > again). DropBox and such are fine as well, if someone wants to buy enough=20 storage, but GIT offers options with UIs similar to uTorrent and such=20 (https://git-scm.com/tools/guis). Just like torrents, there are a number= =20 of UI options depending on how the end user wants to interact with the rep= o. > > 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 instal= ls=20 > just to download a copy of January 1983 Rainbow, I might not. I posit that the work to get a torrent file is no more or less than what= =20 is required to get a git repo stored locally. Updating the git repo=20 would be manual without a bit more work, but that's no worse than=20 torrent (since the user would need to go out and grab the latest torrent= =20 link to get the latest torrent) and the potentially automation with git=20 creates a win that torrents can't touch (finding the latest torrent link= =20 would require some code to go to a site that lists all of them, parse=20 the list, find the one with the newest date, dload it, and then start=20 the torrent client with that link.)=C2=A0 And, since there is no diff=20 functionality on a torrent, you'd need to dload to a new dir, and then=20 delete the old dir once done, meaning twice the local storage needed=20 (or, delete first, then dload, but you risk losing access to files while= =20 the torrent replenishes the files with new copies) Jim =2D-=20 RETRO Innovations, Contemporary Gear for Classic Systems www.go4retro.com store.go4retro.com --------------YznqKtE4ke6qbOUohsgqMK51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-= 8"> </head> <body> <div class=3D"moz-cite-prefix">On 6/3/2026 8:35 AM, Allen Huffman via Coco wrote:<br> </div> <blockquote type=3D"cite" cite=3D"mid:DB21601C-5150-426E-BA78-29447D931647-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org"> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUT= F-8"> <div> <blockquote type=3D"cite"> <div>On Jun 3, 2026, at 1:01=E2=80=AFAM, RETRO Innovations via C= oco <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:coco@listser= v.adelphi.edu"><[email protected]></a> 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: 12p= x; font-style: normal; font-variant-caps: normal; font-weight: 400; letter= -spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-tr= ansform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-= text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickn= ess: auto; text-decoration-style: solid;">As someone else noted, I think it's best to let some large site host the repo.=C2=A0 That way, bandwidth is not an issu= e.</p> <p style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12p= x; font-style: normal; font-variant-caps: normal; font-weight: 400; letter= -spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-tr= ansform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-= text-stroke-width: 0px; text-decoration-line: none; text-decoration-thickn= ess: 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.=C2=A0 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.</d= iv> </blockquote> The nice thing about git is that the protocol will survive, even if the services do not.=C2=A0 If a service is used, and the service is removed, to owner of the repo need only push to a new service.=C2=A0 I have not checked, but it's possible one can use URL forwarders as the URL, so repo pulls will not be affected (the URL they use would be a forwarding one, and someone just updates it) <blockquote type=3D"cite" cite=3D"mid:DB21601C-5150-426E-BA78-29447D931647-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org"> <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> </blockquote> <p>DropBox and such are fine as well, if someone wants to buy enough storage, but GIT offers options with UIs similar to uTorrent and such (<a class=3D"moz-txt-link-freetext" href=3D"https://git-scm.com= /tools/guis">https://git-scm.com/tools/guis</a>). Just like torrents, ther= e are a number of UI options depending on how the end user wants to interact with the repo.</p> <blockquote type=3D"cite" cite=3D"mid:DB21601C-5150-426E-BA78-29447D931647-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org"><br> <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=99t want to mess with a bunch = of installs just to download a copy of January 1983 Rainbow, I might not.</div> </blockquote> <p>I posit that the work to get a torrent file is no more or less than what is required to get a git repo stored locally. Updating the git repo would be manual without a bit more work, but that's no worse than torrent (since the user would need to go out and grab the latest torrent link to get the latest torrent) and the potentially automation with git creates a win that torrents can't touch (finding the latest torrent link would require some code to go to a site that lists all of them, parse the list, find the one with the newest date, dload it, and then start the torrent client with that link.)=C2=A0 And, since there is no diff functionality on = a torrent, you'd need to dload to a new dir, and then delete the old dir once done, meaning twice the local storage needed (or, delete first, then dload, but you risk losing access to files while the torrent replenishes the files with new copies)</p> Jim <p><br> </p> <pre class=3D"moz-signature" cols=3D"72">--=20 RETRO Innovations, Contemporary Gear for Classic Systems <a class=3D"moz-txt-link-abbreviated" href=3D"http://www.go4retro.com">www= .go4retro.com</a> store.go4retro.com</pre> </body> </html> --------------YznqKtE4ke6qbOUohsgqMK51-- --===============1886157512077254941== 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 --===============1886157512077254941==--