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.
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]
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".
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"
KTorrent; just try to play a multimedia file in the built-in media player while it is being downloaded. It even pauses gracefully when there's a data gap ahead.
...Oh, and the screenlock refused to work. After having spent over a day trying to get my workstation back into a state where I could actually _work_, I said "stuff it" and installed WindowMaker, grabbed a few dock-apps by source, hacked my xsession to configure my dual-screen setup, set up the ssh-agent, xlock, etc etc. I really haven't missed having to do all of that manually, but by golly, right now there doesn't seem to be an easily usable alternative!
I've installed my last Ubuntu system, that's for sure.
Just a wild ass guess here, but it sounds like you were hacking on a Debian-based system as if it was Slackware. This may be helpful if you decide to give it another chance.
P.S. Switching to a different theme is a good and fast way to wipe all the flashiness off KDE (and especially Plasma) in short order. I must admit though, it's the first time I've heard of Oxygen described as flashy.
The amazing GUI you saw in that video is built on Qt, and can be run on any platform supported by it with some minimal effort.
"theme based icon recoloring" is implemented in the GUI toolkits. "1/4 sizing screens" is a job for the compositor, in either system.
The biggest user-visible difference between Wayland and X11 will be tear-free display in all circumstances, provided the application's developer has half a clue.
The biggest differences for developers will be the sane (for today's requirements) architecture and vastly simplified API (a big deal in itself).
Search for any given infohash on Google and see for yourself how many indexers there are other than TPB (with many more appearing every day). Somehow I feel they won't all disappear, not until we get a World Government, or something.;-)
Now, in case they all disappear before we get the aforementioned government, DHT can still do the job, even if it's a bit slow. It also is kinda searchable by the way, and expect to see supernode-based structures for fast in-client searching in the future (if they don't already exist, I'm not up to date on the subject).
First steps I do after creating a new Firefox profile:
Set Firefox to reject 3rd party cookies and remove all cookies on session end
Disable all Plugins except Flash and your favorite media player's plugin; gecko-mediaplayer for example.The point is them not even appearing in navigator.plugins. (If you're on Windows(/Mac?), you'll have to repeat this check after every Skype/Office/.NET/Adobe Reader/whatever update. My condolences).
Install Ghostery, RefControl, "Click to Play switch", Scriptish - all from addons.mozilla.org.
Set Ghostery (twice - the intial configuration wizard is not enough!) to
Block all 3pes by default
Not display the Alert Bubble
Auto-update the library and block new elements by default
Not use GhostRank (it sends every single URL you visit to their servers, right when you visit it)
Delete Flash cookies on browser exit
Set RefControl to block sending referers to 3rd party sites
After all of this, I can enable referer sending or cookie/other data persistence per site using RefControl or Firefox's Page Info dialog.
Also, I try to restart the browser at least once a day.
It should be obvious from the above that a) I'm only against being tracked across the web, not ads or analytics done on the same site, and b) it's an uphill battle, and ultimately futile as most browsers (and especially Plugins) leak information in any way they can (plugin/font/javascript feature lists and many more) by default.
Browsers other than Firefox are even worse at this, as they don't allow Extensions to interfere with requests as much. And of course, as soon as you run a Plugin it is game over for privacy on that site at best.
Slashdot Mirror
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.
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: .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).
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
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.
I think I've had enough. Off to BT101 with you.
Hope some Googler can answer this:
Why is Google not enabling STARTTLS on S2S XMPP connections?
It baffles me that emails I send to Gmail users are more safe from eavesdropping than IMs.
Good job, you just managed to get a link without rel=nofollow
Slashcode ftw!
Forget the cloud, here comes LEO!
KTorrent; just try to play a multimedia file in the built-in media player while it is being downloaded. It even pauses gracefully when there's a data gap ahead.
Yeah, that can be irritating at first, indeed. :(
Luckily, you can turn it off at System Settings > Workspace appearance > Configure Decoration > Shadows tab.
...Oh, and the screenlock refused to work. After having spent over a day trying to get my workstation back into a state where I could actually _work_, I said "stuff it" and installed WindowMaker, grabbed a few dock-apps by source, hacked my xsession to configure my dual-screen setup, set up the ssh-agent, xlock, etc etc. I really haven't missed having to do all of that manually, but by golly, right now there doesn't seem to be an easily usable alternative!
I've installed my last Ubuntu system, that's for sure.
Just a wild ass guess here, but it sounds like you were hacking on a Debian-based system as if it was Slackware. This may be helpful if you decide to give it another chance.
P.S. Switching to a different theme is a good and fast way to wipe all the flashiness off KDE (and especially Plasma) in short order. I must admit though, it's the first time I've heard of Oxygen described as flashy.
X11 supports touch, as does Wayland of course.
The amazing GUI you saw in that video is built on Qt, and can be run on any platform supported by it with some minimal effort.
"theme based icon recoloring" is implemented in the GUI toolkits.
"1/4 sizing screens" is a job for the compositor, in either system.
The biggest user-visible difference between Wayland and X11 will be tear-free display in all circumstances, provided the application's developer has half a clue.
The biggest differences for developers will be the sane (for today's requirements) architecture and vastly simplified API (a big deal in itself).
Search for any given infohash on Google and see for yourself how many indexers there are other than TPB (with many more appearing every day). Somehow I feel they won't all disappear, not until we get a World Government, or something. ;-)
Now, in case they all disappear before we get the aforementioned government, DHT can still do the job, even if it's a bit slow. It also is kinda searchable by the way, and expect to see supernode-based structures for fast in-client searching in the future (if they don't already exist, I'm not up to date on the subject).
From my experience when I seed a torrent on the sute [sic] (legal ones by the way)...
Good job declaring that, you should be safe from the boogeyman now.
OLE embedding? (ducks)
Rooting for software patents, or the ones asserting them, only keeps the barriers to entry in place for FLOSS projects and small businesses.
Unless you are a shareholder of the patent-asserting company, or in its payroll, it doesn't make any sense to defend them.
First steps I do after creating a new Firefox profile:
After all of this, I can enable referer sending or cookie/other data persistence per site using RefControl or Firefox's Page Info dialog.
Also, I try to restart the browser at least once a day.
It should be obvious from the above that a) I'm only against being tracked across the web, not ads or analytics done on the same site, and b) it's an uphill battle, and ultimately futile as most browsers (and especially Plugins) leak information in any way they can (plugin/font/javascript feature lists and many more) by default.
Browsers other than Firefox are even worse at this, as they don't allow Extensions to interfere with requests as much. And of course, as soon as you run a Plugin it is game over for privacy on that site at best.