Your example reminded me of Python:

for user in users:
    send_message(user, "Happy Birthday")

I was referring to his moral crusades, and how they've apparently turned the public opinion a bit against him (my take on what we're seeing in the comments).

Trust me, I'm more than glad that he keeps sharing his views on technical matters.

Anyway, I know my post was poorly worded, however try looking at it in the GP's context.

Garrett's blog posts are an equal split between insight-sharing and attention-whoring, yet the free software press keeps focusing on the latter.

A modest proposal

Facetime =/= AppleTalk
Other than that, I think your comment is spot on. (Not that I don't enjoy watching Apple taste their own poison).

--
I can haz Unicode, Slashdot?

I'll leave this here.

He said Python, not Javascript.

The CPython folks constantly moan about parser complexity, and even they managed it.

You're probably confusing WiFi (IEEE 802.11) with GSM.

Distance records (using non-standard devices) include 382 km (237 mi) in June 2007, held by Ermanno Pietrosemoli and EsLaRed of Venezuela, transferring about 3 MB of data between the mountain-tops of El Águila and Platillon.[46][47] The Swedish Space Agency transferred data 420 km (260 mi), using 6 watt amplifiers to reach an overhead stratospheric balloon.[48]

Emphasis mine; Source

Indeed, lsof doesn't always catch open files given as arguments, so I often find myself using grep too.

What creates the multi-second delay is that lsof tries to resolve IP address to canonical names (and there will be IP address in the output, as you asked for every open file (descriptor) in the system.) You can solve that by using "lsof -n", just like "netstat -n".

Sigh, still haven't managed to kick this habit...

First of all, I apologise for the tone of my post... lkcl's posts frequently attract trolls and, posting at a late hour again, my hasty judgement got the better of me. :-(

When you give your bittorrent client a magnet link with a "btih" (BitTorrent Info-Hash) component, it starts looking up the DHT (asking other peers it's already made contact with) for peers sharing that infohash's torrent. As soon as it finds at least one, it connects to that peer ("joins the swarm") using the BT protocol and asks for the torrent's metadata (the.torrent file's info section). It is at this point where it will pop up a window asking you where to save the torrent and/or which files to download from it.

Given the above, one way that "gittorrent" could work would be the following:
1. Each Git object (file/file tree/commit) would be a separate "torrent", identified by its hash. Information about which peers have which hashes (i.e. objects) would be stored in the DHT. Nothing new for DHT so far. With this in place, you could checkout any individual git file/tree/commit and its history (each git commit references its parent).
2. Here we introduce a DHT protocol extension (let's call it "get_hash_addenda") using which you could get information stored in the DHT (this is the major difference with .torrent files) about newer commits. With this in place you would also find other users' "forks". This would also be useful for ordinary torrents by the way (get subtitles/new episodes for this torrent).
3. With these in place, you now have a (very slow) "gittorrent" implementation. Additional extensions/local DHT data caching/assumptions/whatever) would be used to speed the whole thing up. Existing BT trackers (fast peer lookup for a given infohash) would work as is. Existing git daemons would also work, and could also be extended to speak DHT and the BT protocol. All these things map well to existing BT concepts.

The protocol(s) used for transferring objects between peers could be the BT protocol (provided we treat each git object as a separate torrent, as lkcl recommended), and/or any protocol already supported by Git (as an analogue of "web seeds").

Example bare bones magnet links:

magnet:?xt=urn:git:<object id>
magnet:?xt=urn:git:<long hex number representing a user>/<repo>[/<branch|tag name>]

or even magnet:?xt=urn:git:<user>/<repo>/<branch|tag name>
if a way of having non-spoofable and globally unique nicknames is found (probably in an FCFS fashion).

A nice research project on extending BT (which already somewhat implements the "get_hash_addenda" functionality) is Tribler.

The earlier "gittorrent" effort that lkcl criticised can be found here. A cursory glance reveals an emphasis on trackers and almost no mention of DHT, probably due to it being written in 2008.

Disclaimer: All this is from a layman's point of view and horribly inaccurate. The DHT protocol extension especially could probably be avoided using some convention. I've been reading up on how BitTorrent and DHT works lately and, honestly, I can't blame you: apart from the BEPs it's basically UTSL.

I see your flamebait already fooled some mods. However, you're supposed to attack the idea, not the man. And you failed spectacularly at that.

The key component in what he's proposing would be the DHT; not even necessarily the same DHT as used by standard BitTorrent clients. The use (or not) of the BitTorrent specification and its intricacies would be just an implementation detail.

You're free to be one of the "can't be done" people; it would be wise not to advertise it too much around here however; as it's not become Reddit yet.

"how do I send out new versions of the .torrent files every time I commit something"

I think I've had enough. Off to BT101 with you.