6 ms·

I doubt widespread adoption was slowed down with mainstream news about BitTorrent, or what are you talking about more specifically ? Others peer to peer sharin

by ttoinou 23d ago

I doubt widespread adoption was slowed down with mainstream news about BitTorrent, or what are you talking about more specifically ? Others peer to peer sharing platforms got much more popular despite mainstream news about them like LimeWire and eMule

bmacho 23d ago
Maybe they want to torrent Linux ISOs but can't because their ISP/VPN blocks the torrent protocol. Http for server->client downloading is inferior but we are stuck with it.
- ttoinou 22d ago
  Which ISP is blocking bittorrent ?
grumbel 23d ago
Lack of BitTorrent support in browsers is big thing that is missing. Brave and Opera have it, but all the mainstream browsers don't. Thus torrent downloads never got out of its specific niche. That said, I don't think piracy is to blame here, but more the murky nature of copyright in general, with BitTorrent you automatically become redistributor of everything you download and that's just a huge liability and privacy risk that I can easily see browser developers wanting to avoid. Also browser developers have gotten lazy, they couldn't even find the resources to keep FTP alive, so I doubt BitTorrent would have survived for long even if they tried adding it.
- inigyou 22d ago
  Why should they keep FTP or Gopher alive, or support Gemini, when they're just worse HTTP? I think they should make it possible to write a new protocol handler though.
  - __MatrixMan__ 22d ago
    Is FTP really worse HTTP? If you try to enumerate directories over HTTP alarms start going off because you look like an attacker.
    - duskwuff 22d ago
      > Is FTP really worse HTTP? I don't think I'd even call it that. FTP had one purpose: it was an early protocol for remotely managing files. It never had any intent to support dynamically generated or otherwise "virtual" content (as supported by e.g. CGI scripts and mod_rewrite in Apache), and I don't think anyone has ever made a serious attempt to implement that. There's no practical use case for it. Even as a file management protocol, though, FTP sucks. Its connection management is primitive in the extreme - one TCP connection per transfer - and that ruins performance for transfers involving many files, and is difficult to pass through firewalls and load balancers. FTPS encryption is an afterthought, and makes small-file performance even worse (as each connection requires separate TLS negotiation). There's no standard format for directory listings, just ad-hoc parsing of "ls -l" output. Support for modern filesystem features like extended attributes is largely nonexistent. Need I continue? :)
      - chuckadams 22d ago
        The strange way FTP manages connections goes back to FTP being older than TCP/IP itself, and thus using older circuit-switched networks. It wouldn't have been unusual for a server to dial up the receiving machine on-demand, which didn't have to be the machine running the command session. Before SMTP came around, email was commonly implemented on top of FTP.
        inigyou 22d ago
        FTP was written for an early version of TCP/IP (which wasn't called that). Maybe you're thinking of UUCP, which did often run over dial-up circuits and was used for email, but didn't require two connections.
        21d ago
__MatrixMan__ 22d ago
I took a bioinformatics class, students were emailing large files around via the university's email portal. The files were frequently corrupted somewhere along the way. I had to show them how to check hashes and then they would just repeatedly download the file until they got one without errors. But then the sysadmin showed up and asked us to stop downloading multi-gig files repeatedly from his server. I proposed bittorrent as the solution and the sysadmin lost his mind. Without the piracy stigma, I think we'd just have integrtated it into email clients. The user doesn't need to know that the "attachment" is actually a torrent file, they should just "download" it and end up with a reliable copy of what was sent.

by ttoinou 23d ago

bmacho 23d ago

Maybe they want to torrent Linux ISOs but can't because their ISP/VPN blocks the torrent protocol. Http for server->client downloading is inferior but we are stuck with it.

ttoinou 22d ago
Which ISP is blocking bittorrent ?

grumbel 23d ago

Lack of BitTorrent support in browsers is big thing that is missing. Brave and Opera have it, but all the mainstream browsers don't. Thus torrent downloads never got out of its specific niche. That said, I don't think piracy is to blame here, but more the murky nature of copyright in general, with BitTorrent you automatically become redistributor of everything you download and that's just a huge liability and privacy risk that I can easily see browser developers wanting to avoid. Also browser developers have gotten lazy, they couldn't even find the resources to keep FTP alive, so I doubt BitTorrent would have survived for long even if they tried adding it.

inigyou 22d ago
Why should they keep FTP or Gopher alive, or support Gemini, when they're just worse HTTP? I think they should make it possible to write a new protocol handler though.
- __MatrixMan__ 22d ago
  Is FTP really worse HTTP? If you try to enumerate directories over HTTP alarms start going off because you look like an attacker.
  - duskwuff 22d ago
    > Is FTP really worse HTTP? I don't think I'd even call it that. FTP had one purpose: it was an early protocol for remotely managing files. It never had any intent to support dynamically generated or otherwise "virtual" content (as supported by e.g. CGI scripts and mod_rewrite in Apache), and I don't think anyone has ever made a serious attempt to implement that. There's no practical use case for it. Even as a file management protocol, though, FTP sucks. Its connection management is primitive in the extreme - one TCP connection per transfer - and that ruins performance for transfers involving many files, and is difficult to pass through firewalls and load balancers. FTPS encryption is an afterthought, and makes small-file performance even worse (as each connection requires separate TLS negotiation). There's no standard format for directory listings, just ad-hoc parsing of "ls -l" output. Support for modern filesystem features like extended attributes is largely nonexistent. Need I continue? :)
    - chuckadams 22d ago
      The strange way FTP manages connections goes back to FTP being older than TCP/IP itself, and thus using older circuit-switched networks. It wouldn't have been unusual for a server to dial up the receiving machine on-demand, which didn't have to be the machine running the command session. Before SMTP came around, email was commonly implemented on top of FTP.
      - inigyou 22d ago
        FTP was written for an early version of TCP/IP (which wasn't called that). Maybe you're thinking of UUCP, which did often run over dial-up circuits and was used for email, but didn't require two connections.
        21d ago

__MatrixMan__ 22d ago

I took a bioinformatics class, students were emailing large files around via the university's email portal. The files were frequently corrupted somewhere along the way. I had to show them how to check hashes and then they would just repeatedly download the file until they got one without errors. But then the sysadmin showed up and asked us to stop downloading multi-gig files repeatedly from his server. I proposed bittorrent as the solution and the sysadmin lost his mind. Without the piracy stigma, I think we'd just have integrtated it into email clients. The user doesn't need to know that the "attachment" is actually a torrent file, they should just "download" it and end up with a reliable copy of what was sent.