upvote

points

by monsieurbanana5 hours ago |
comments
upvoteby zenoprax5 hours ago|
next
[-]
Every change to the source is effectively a new torrent. This creates a ton of fragmentation as data is reorganized, remixed, reencoded, and so on.

You can see this with many Linux distros: there is no single Debian torrent that people seed for years because there's always a refreshed version.

Distros are a bad use case for P2P anyway since you depend on upstream as soon as you start upgrading and installing packages.

reply
upvoteby vova_hn23 hours ago|
parent|
next
[-]
IPFS has a solution [0] to this problem

[0] https://specs.ipfs.tech/ipns/ipns-record/

reply
upvoteby mitxela3 hours ago|
parent|
[-]
Most of IPFS doesn't actually work very well, if you've ever tried to use it
reply
upvoteby vova_hn23 hours ago|
parent|
[-]
> if you've ever tried to use it

Heh, you got me :) IPFS is one of those things that I love reading and about and thinking about using someday, but somehow never get around to it.

reply
upvoteby mitxela3 hours ago|
parent|
[-]
The problems begin with taking 5-10 minutes to locate a file on the network. That's right, when you ask for a file it takes 5-10 minutes. Also if the file isn't in the network at all then it never terminates.

Nobody noticed because everyone just used the central web gateway that cached every file anyone ever accessed.

reply
upvoteby chmod7755 hours ago|
parent|
prev|
next
[-]
You can trivially have storage deduplication for the files served via torrent, transparent to the protocol. The most trivial version of this that you can do today with pretty much any client is having a single directory containing files serving multiple overlapping torrents.
reply
upvoteby skeledrew5 hours ago|
parent|
[-]
> files serving multiple overlapping torrents

This sounds wildly complex, especially from a discovery perspective.

reply
upvoteby chmod7755 hours ago|
parent|
[-]
I don't see why it would be. It's transparent to other clients just like it is to the protocol. It cannot be more complex than alternatives by construction.
reply
upvoteby righthand5 hours ago|
parent|
prev|
next
[-]
> Distros are a bad use case for P2P anyway since you depend on upstream as soon as you start upgrading and installing packages.

This is true for any distribution method not just p2p. You can even download a nightly through torrents so what does it matter how the data is transferred if it’s always going to require `apt update`?

reply
upvoteby zenoprax2 hours ago|
parent|
[-]
Yeah, I just use the "netinstaller" ISOs since it's much smaller and never needs to be updated. If I had a need for air-gapped/offline installs I'd either download a larger ISO or just manually install packages from .deb as needed.
reply
upvoteby NooneAtAll35 hours ago|
parent|
prev|
[-]
but model releases are already non-changeable?
reply
upvoteby zenoprax2 hours ago|
parent|
[-]
Yes, models are a good use for P2P especially if everyone agrees to share the same torrent and someone (or a cohort) commit to seeding for the long haul.
reply
upvoteby cube005 hours ago|
prev|
next
[-]
If they're no longer using that model they may not be willing to continue using their storage for it.
reply
upvoteby vlyan4 hours ago|
parent|
next
[-]
yes, but a few dedicated hoarders could keep many models alive, and I'm fairly certain the local LLM community has plenty of people who would.
reply
upvoteby mitxela3 hours ago|
parent|
[-]
They don't. That's the conversation topic.

Nor do they need to. 99% of everything is crap, and not worth prescribing except for a random sample so future historians can study our crap.

reply
upvoteby csomar5 hours ago|
parent|
prev|
[-]
How does this address the previous point? If they are not providing storage, then centralized or decentralized doesn’t make a difference.

Torrent/P2P can only add redundancy, so it’s impossible to have worse availability than a download link?

reply
upvoteby _blk5 hours ago|
parent|
[-]
[flagged]
reply
upvoteby Wowfunhappy4 hours ago|
parent|
next
[-]
Well, for a torrent to stay healthy, users have to seed after download, so it can't possibly have the same UX as a standard browser file download unless you want to either kill the ecosystem or hide from the user what is consuming upload bandwidth.

That said, for large files, I much prefer the UX of a well-designed torrent client like Transmission to my web browser. If nothing else, the downloads are reliably resumable.

reply
upvoteby QuantumNomad_1 hours ago|
parent|
[-]
> I much prefer the UX of a well-designed torrent client like Transmission to my web browser. If nothing else, the downloads are reliably resumable.

Brave browser had BitTorrent client built in for a while. I tried it a couple of times as I already use Brave for web browsing on my laptop. It was a very confusing BitTorrent client. I struggled to use it, and wasted time waiting for a download to complete only to not be able to find where the files were and then they disappeared. Using a decent BitTorrent client like you say is much preferable to the one that they had in Brave browser.

reply
upvoteby pell5 hours ago|
parent|
prev|
[-]
> Is there a fully in-browser torrent option that has the same UX as a regular file download in Firefox?

Opera did back in the day.

reply
upvoteby 3 hours ago|
prev|
next
[-]
deleted
reply
upvoteby debugnik4 hours ago|
prev|
[-]
You can add an existing HTTP download as a "web seed" to a torrent, so they don't actually need to do anything for people to share it as a torrent.
reply