Contributed by mk/reverse on from the distribution bottleneck dept.
Bob Beck writes to misc@ and tech@:
I just committed a change to ftp.html to identify second level mirror sites. This is deliberate. We are going to be moving with this release towards a two level mirror distribution from the fanout site in canada.
This sounds like a very good idea since ftp.openbsd.org is quite unusable every six months and thus delays the distribution to the other mirrors. It's time for you to poke your favourite mirror operators and have them update their source.
(Comments are closed)
By RC (4.16.255.217) on
It would be a good idea to put all the lowest-level mirrors in their own group, and give the higher-up servers (that are not supposed to be users directly) a different DNS naming scheme, so they won't show-up when I pick a number and try it out.
And even after going through the list, and finding the best mirror for yourself, it's easier to remeber "6", rather than "anonopenbsd.cs.colorado.edu".
Comments
By Anonymous Coward (69.156.206.199) on
Comments
By tedu (66.93.171.98) on
Comments
By Anonymous Coward (69.156.206.199) on
By Semi-Anonymous Coward (216.238.113.174) on
By Matt Van Mater (65.205.28.104) on
Also, I disagree with some people's suggestions to obfuscate the mirror names. Personally I really appreciate the fact that they list the organization and location where the mirror is at. Why would I want to sync with a mirror in colorado or california if I can get one 10 miles away in here in virginia? If you want to have alaises for neatness sake, thats cool, but I don't think the aliases alone will solve the bandwidth problems, and might even make them worse.
Comments
By James Carter (66.218.244.40) on http://www.opentorrent.org
By Chas (147.154.235.53) on
The ctorrent binary is only 55k under OpenBSD 3.5. Here is the source.
ctorrent is not perfect. It is not firewall friendly, but it has the potential of vastly reducing the bandwidth consumed at release time.
Comments
By Anthony (68.145.111.152) on
Also... firewall friendliness can be improved with a little care.
First, create a user and group called torrent, and don't give him permissions to anything else. All your downloads go to torrent's home directory.
Second, tweak PF to allow torrent to listen for connections (in the same way that the FTP proxy is set up).
Third, tweak PF to give the torrent user the lowest priority you can. You want torrents to run only when you're not using the bandwidth, otherwise your connection will become unusable.
Fourth, install "screen" from ports. Run torrents (btdownloadheadless or btdownloadcurses) from within screen so you can log out.
Comments
By Chas (147.154.235.53) on
...and integrate it into pkg_add.
While static linking against the C++ library may increase its size (from 50k), setting ctorrent as the default remote install method would take most of the load off ftp.openbsd.org.
The python version would not be appropriate (binaries too large).
Really, ftp is an ugly old protocol. Yes, ctorrent may not be the answer, but why not try something rather than just complain about bandwidth problems at release time?
Yes, a code review would obviously be required for ctorrent integration into the base distribution.
Comments
By Anonymous Coward (69.156.206.199) on
An even better idea... Buy a CD!
I'm finally doing it again, and I've even managed to expense another copy to my Company (cheap a** company) but still, buying 1 CD through them and one from me is better than not helping to support OpenBSD by just ftp installaing and not giving back. Don't forget, OpenBSD isn't commercially funded (at least not like RH, SuSe or such...) so every little bit helps, IMHO.
Sincerily,
A proud supporter of OpenBSD...
By Anonymous Coward (131.130.1.143) on
Comments
By Chas (147.154.235.53) on
Let's just say that the i386 boot floppy and the .tgz files were all on torrents.
For the duration of the installer download, yes, clients would share data with one another, which might be of negligable benefit.
However, the clients would automatically seek out the best download sites, which would spread the load.
Even without the client upload, distributed bandwidth consumption solves a lot of problems. However, at this stage, it may also create some significant problems.
By Anonymous Coward (69.197.92.181) on
Comments
By mirabile (212.185.103.56) tg@66h.42h.de on http://mirbsd.de/
Even with the former, I already managed to get 6-8 torrents
running simultaneously on a Pentium 120 with 128 MiB RAM,
running OpenBSD 3.5-current based MirBSD.
With the latter, it's even less ressource intensive because
the python core is loaded only once.
Hint: if you're on PPPoE ADSL, try pppoe(8) from -current,
it fixes a severe problem.
As for FTP: it deserves to die anyway, but since httpd(8) comes
with the base system, why not install via http? There are even
some public OpenBSD http mirrors available.
You could of course tape them up, or use NFS, or whatever, but
CDs or HTTP seem quite appropriate for me.
//mirabile
Comments
By Anonymous Coward (67.71.76.239) on
Comments
By sthen (81.168.66.229) on
By RC (4.16.254.193) on
> What's wrong with the original Python client?
Maybe because you have to have python installed? Maybe because it's very limited? Maybe because it's very slow? Maybe because people don't want to learn python?
> The probability of a security problem is higher with a C program,
Not true.
> and computers that are slow enough to care about the speed are rare.
Also not true.
> Second, tweak PF to allow torrent to listen for connections
> (in the same way that the FTP proxy is set up).
What? bittorrent isn't a proxy. You don't set up rules for it in any way remotely similar.
> Run torrents (btdownloadheadless or btdownloadcurses) from
> within screen so you can log out.
Lowsy advice. There are a number of ways you could keep either program running after you've logged-out. 'nohup' would work well, and it comes with every Unix system I've come across yet.
By Michael Knudsen (217.157.199.114) on
Still, a secure way of distributing .torrents would be needed.
Comments
By Anonymous Coward (68.123.254.186) on
Comments
By jose nazario (204.181.64.2) on http://monkey.org/~jose/
Comments
By Michael Knudsen (217.157.199.114) on
The best way is of course to buy the CDs.