Please create an account to participate in the Slashdot moderation system


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Poor Mattthew Garrett (Score 1) 88

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.

Submission + - NSA Firing 90% of it's Sysadmins (

sl4shd0rk writes: Director of the NSA, Keith Alexander, has decided that the best way to
prevent illegal activity, or rather be witness to it, is to reduce the number of ears and eyes involved. During a monolog at a cybersecurity conference in New York this week, Alexander revealed his plans to cut 90% of the System Administration workforce at the NSA. "What we're in the process of doing — not fast enough — is reducing our system administrators by about 90 percent," he said. Alluding to an issue of mistrust, Alexander further clarified: "At the end of the day it's about people and trust...if they misuse that trust they can cause huge damage.". Apparently, breaking the law and lying about it leaves one without a sense of irony when speaking in public.

Submission + - Ask Slashdot: Viable Alternative to Lavabit 1

rizole writes: As we learnt earlier today, Lavabit, an encrypted email provider, was shut down by it's owner. Pointing a finger that the US Government he writes:

I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States.

What alternative email provider would you recommend Edward Snowden now gets an account with?

Comment Re:stratosphere? (Score 1) 115

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

Comment Re:lsof is your friend (Score 1) 252

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

Comment Re:gittorrent (Score 1) 302

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.

Comment Re:gittorrent (Score 2) 302

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.

Slashdot Top Deals

Possessions increase to fill the space available for their storage. -- Ryan