Re: kernel ftp ?

quoted

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
remember.

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?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/