kernel ftp ?
schmitz at zirkon.biophys.uni-duesseldorf.de
Tue Jul 17 04:38:17 EST 2001
> > Yep, but does the bitmover sire offer rsync access? That's what most of us
> > still use ...
> No, we do not and will not offer rsync or FTP access. Those are very
> bandwidth intensive services, BK uses a tiny fraction of what they use,
> and you can accomplish the same thing with a
> rm -rf /tmp/exported_tree
> bk pull
> bk export -tplain /tmp/exported_tree
> That's way, way, way less bytes moved to get you a perfect mirror.
Thanks. I wasn't pushing for bitmover to set up rsync, I honestly didn't
> I can easily understand you not wanting to learn a new tool, or having
> some other reason, valid or otherwise, not to use BK. That's fine.
Thanks for your understanding - in my case it's just inertia at work. Plus
there doesn't seem to be a Debian or RPM package I could find. I don't
follow kernel development closely, I don't need to commit patches, even a
source tarball snapshot posted to some big FTP archive would suit me fine.
> Our way around this problem is to get you to do one "bk clone" and only
> "bk pulls" after that. That will transfer _only_ the data which has to
> be transferred, nothing else. Even that is a substantial amount when
> you multiply it all out by the number of people. We'll deal with that,
> we won't deal with full copies.
Color me naive but wouldn't a second tier of bk or other sites alleviate
that? Provided they won't allow commits so syncing the repositories won't
get to be a headache? Mvista runs a bk mirror, incidentially. Other sites
willing to set one up might be found if necessary (what's the average disk
space requirement? You covered the bandwith aspect nicely...). Together
with a note on penguinppc.org and other pages advertising the kernel
source, to please use mirrors where possible?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev