In <aanlktinehmuubsmlyazux1kakhfaqgudrng0q+azn...@mail.gmail.com>, Luke Kenneth Casson Leighton wrote: >around three years ago i wrote an article recommending that debian >move step-by-step towards distributed peer-to-peer infrastructure, >thus reducing the reliance on server infrastructure, thus potentially >allowing sponsorship funds and resources to be retargetted to other >areas which would improve the debian distribution. > >mostly that was words, not actual code, and, before getting all upset >at how little progress has been made (cameron dale's fantastic apt-p2p >work literally being the only exception ) i decided a few days ago to >do something about that situation, so that i wouldn't come across as >being a complete spongeing whining knob. > >my contribution is to prove that a combination of git and bittorrent >is actually possible: >http://gitorious.org/python-libbittorrent/pybtlib > >(anyone wishing to help / contribute, do contact me: i'll happily give >you access to the repository if you can spot the irony of this >statement) > >it's turned out to be much, much simpler than i thought, by the simple >expedient of turning git commits into a "virtual filesystem" where the >git-pack-objects are stored as files, named by their commit reference. > hooking into the bittornado client's "file close" operation is enough >to fire off a test for whether the pack object is valid (check its >signature at the beginning, and the SHA-1 signature at the end), and >if it is, to run a "git unpack" operation.
Packs are allowed to have information from multiple related commits and are not required to have all the objects referenced by a single commit. So, right there I'm not sure exactly sure how your virtual file system is structured. It seems to me like if packs are the file(s) in your torrent(s) then you may end up transferring much, much data redundantly. I've not sure it is possible to naively combine the bittorrent protocol with Git, since you really want to advertise individual objects, but you need to transfer in the form of a pack/bundle to avoid intra-object redundancies. It's also too "expensive" to track single objects, but also rather "expensive" to switch clients over to a new torrent. >what are the implications, and why is combining git with bittorrent a >big hairy deal? > >* alioth, a single server, could run git torrent trackers, and the >load on the server greatly reduced. and it no longer becomes a >single-point-of-failure > >* joey hess's excellent "ikiwiki", which can be configured to use git, >could be used as the basis for a distributed wiki. > >* again: ikiwiki or something similar could well be used as the basis >for a distributed bugtracker. While wikis and bug trackers have some ground in common, the information stored by a bug tracker needs to be much more structured to enable the types of queries the release team and others do. Does ikiwiki support the features we are used to on the Debian BTS? >* mailing list archives could be stored in a git repository, and, >instead of being mailed to tens of thousands of users, a slow >migration to simply... sharing the email messages via bittorrent can >be performed. this would *significantly* reduce the load on the mail >servers, which i understand to be ... a leeetle bit stressed. Having the archives available via bittorrent sounds fine. However, if subscribing or receiving mails in "real-time" requires special tools, the idea won't work. The mailing list community is so large partly because of the simplicity of the tools required to sent message to the lists and receive messages from the list; SMTP, NNTP, and POP/IMAP are venerated protocols supported on some of the least expensive devices you'll find. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
