<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Tristam29</title><link>http://disqus.com/people/Tristam29/</link><description></description><language>en</language><lastBuildDate>Sat, 08 Nov 2008 08:43:37 -0000</lastBuildDate><item><title>Re: Welcoming Alex Harris to TLF</title><link>http://tlf.disqus.com/welcoming_alex_harris_to_tlf/#comment-3621830</link><description>Great to see you posting at TLF!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Sat, 08 Nov 2008 08:43:37 -0000</pubDate></item><item><title>Re: Abandoned DNA: Private or Property?</title><link>http://tlf.disqus.com/abandoned_dna_private_or_property/#comment-3395426</link><description>The problem with the magazine analogy is that when you leave the magazine behind you are divesting any property right you had to it.  Perhaps this is accidental, perhaps not, but either way it's 'abandoned' property that anyone can claim.&lt;br&gt;&lt;br&gt;If the analogy carries over to DNA, then there is no trespass in picking up a used soda can and then performing a DNA test.  However, if DNA is fundamentally different in that we still have property rights to our abandoned DNA, then why wouldn't there be *both* a trespass and an illegal search under the 4th amendment for picking up the DNA and then performing a test on it?  &lt;br&gt;&lt;br&gt;My confusion is that I'm not buying part (a) of your argument yet, which means that I can't even choose for part (b).  &lt;br&gt;&lt;br&gt;Also, I'm still curious about the twins, siblings, and family members arguments.  Heck, make it even more interesting, if we have property and privacy rights to our DNA, then shouldn't couples be able to choose to sell stem cells to research organizations?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Thu, 30 Oct 2008 14:53:09 -0000</pubDate></item><item><title>Re: Abandoned DNA: Private or Property?</title><link>http://tlf.disqus.com/abandoned_dna_private_or_property/#comment-3392263</link><description>As a legal matter, the abandoned DNA case is not viewed as a search or a seizure, in the same way as I would not be "searching" you if I picked up a magazine you left behind in the airport lounge.&lt;br&gt;&lt;br&gt;It is also true that property rights and privacy overlap. For example, if you think that you have intellectual property over your genetic code (which seems to me incredibly difficult to justify), then you get the DNA protection you want through the IP mechanism. I'm just arguing that:&lt;br&gt;a. In some cases (for example, the abandoned DNA case), a property rights view and a privacy rights view come to different conclusions; and&lt;br&gt;b. The property rights view is more compelling.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">AlexHarris</dc:creator><pubDate>Thu, 30 Oct 2008 12:11:58 -0000</pubDate></item><item><title>Re: Abandoned DNA: Private or Property?</title><link>http://tlf.disqus.com/abandoned_dna_private_or_property/#comment-3386845</link><description>Property rights and privacy rights are inextricably linked.  For example, let's assume that you start from a strict property rights view and assume privacy rights don't exist.  In this case, you can have a house with closed doors and windows into which no one can see.  Rationally, the right to property grants you a defacto right to some level of privacy.&lt;br&gt;&lt;br&gt;Take the other extreme and assume that you start from a strict privacy rights view and assume that property rights don't exist.  Let's even use Jim's definition: "The subjective condition that people experience when they have the power to control information about themselves."  There's a lot of different kinds of information about oneself, but to have any power to control that information then a defacto property right is created to some extent.  If you want to be able to control who can see you naked, then you have to have the power to prevent people from encroaching on some personal space.&lt;br&gt;&lt;br&gt;Personally, I think the privacy argument is a bit more persuasive for abandoned DNA.  If the 4th amendment protects against unreasonable searches and seizures, then doesn't 'unreasonable' simply mean that the government can't do anything a citizen wouldn't normally be able to do? Normal citizens could find my DNA all over the place: hair, skin cells, and saliva from drink cans. However, the government becomes unreasonable when it starts sequencing my genome or whatever is involved in a DNA test.  Normal people don't do that.  &lt;br&gt;&lt;br&gt;I am not a lawyer, so it's difficult for me to say that either property or privacy has the edge in freely given DNA.  I suspect there are rules for evidence of which I'm simply unaware. &lt;br&gt;&lt;br&gt;Anyhow, I think the property and privacy arguments are just linked to some extent, and I'm not sure what the benefit is to picking a side when both of them seem to be relevant.  (I'd love to hear thoughts on this.)&lt;br&gt;&lt;br&gt;Also, neither a property rights view nor a privacy rights view seems to provide much guidance in the hard cases.  If I had an identical twin, who owns my DNA?  Even siblings have genetic information that would be very useful to insurance companies wondering about health risks.  Should I be legally allowed to provide my DNA to an insurance company wondering if they should cover my brother?  How does a property or a privacy rights argument help here?  (Does Joh address this in her article?)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Thu, 30 Oct 2008 03:09:26 -0000</pubDate></item><item><title>Re: Google Policy Fellow Program</title><link>http://tlf.disqus.com/google_policy_fellow_program/#comment-3364458</link><description>As a former Google Policy Fellow at the Cato Institute, I strongly recommend applying if you are currently a student reading this blog regularly.  It's an excellent program.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Wed, 29 Oct 2008 12:13:26 -0000</pubDate></item><item><title>Re: The Patent System is a Hashtable without a Hash Function</title><link>http://tlf.disqus.com/the_patent_system_is_a_hashtable_without_a_hash_function/#comment-1880017</link><description>Seriously?  &lt;a href="http://patft.uspto.gov/" rel="nofollow"&gt;This is supposed to be easier than Google?&lt;/a&gt;  Honestly, I think &lt;a href="http://www.google.com/patents" rel="nofollow"&gt;Google's engine is better&lt;/a&gt; and more accurate.  Of course, if you're talking about the tools that expensive lawyers use, then you're pretty much already in a different garage than the one in which most software engineers tinker.&lt;br&gt;&lt;br&gt;Though, I do wish you were right about the existence of software patents.  (Business method patents should probably also disappear for that matter.)  I kinda like Ben Klemens' proposals, but we're certainly not there yet.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Wed, 27 Aug 2008 19:22:22 -0000</pubDate></item><item><title>Re: The Patent System is a Hashtable without a Hash Function</title><link>http://tlf.disqus.com/the_patent_system_is_a_hashtable_without_a_hash_function/#comment-1877806</link><description>&lt;em&gt;But even setting that point aside, Lindberg’s analogy provides a helpful analogy to explain why patents are a bad fit for the software industry: it’s like implementing memoization using a lookup table without a hash function.&lt;/em&gt;&lt;br&gt;&lt;br&gt;To me the more apt memoization analogy to the patent system focuses on the overlapping subproblems that you hinted at with the Fibonacci sequence example.  Essentially, the patent system attempts to use a &lt;a href="http://en.wikipedia.org/wiki/Dynamic_programming" rel="nofollow"&gt;dynamic programing&lt;/a&gt; technique to speed-up innovation.  The core problem is that the 20 intervening years during which the patent is valid makes whatever subproblem the patent solved worthless.  As you mentioned, there are essentially no valuable software patents from the 1980's.  Thus, no one would have a use for these patents irrespective of their ability to perform a lookup.  I think this gets more to the core of why software patents really hurt innovation in software rather than the lookup concern.&lt;br&gt;&lt;br&gt;Although, the lookup concerns are secondary in my mind, they are certainly important.  For example, consider the situation that would happen if software patents were only valid for three years.  Some of the subproblems those patents solved would still be relevant and important.  This means that being able to find a fast solution to those subproblems would be useful.  However, without being able to perform an easy lookup the software industry wouldn't be able to make use of any valuable solutions to subproblems with which they may be dealing.  Thus, even if the core problem with the patent system didn't exist, the lookup concerns you mentioned would still render current patent system as useless.&lt;br&gt;&lt;br&gt;This also fits with your discussion of the pharmaceutical industry.  They actually benefit from the patent system not simply because they can perform a reasonable lookup, but also because they can potentially still make use of the solutions to subproblems they find to solve larger problems.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Wed, 27 Aug 2008 16:58:31 -0000</pubDate></item><item><title>Re: DMCA takedown notices should take fair use into consideration</title><link>http://tlf.disqus.com/dmca_takedown_notices_should_take_fair_use_into_consideration/#comment-1730733</link><description>Good point, Aaron--I suppose I should have pointed out that our primary means of video promotion is still YouTube. We just have a mirror on our site where we host high-bitrate versions of our videos (higher quality than YouTube's high quality) for media relations purposes.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">ryanradia</dc:creator><pubDate>Fri, 22 Aug 2008 09:39:12 -0000</pubDate></item><item><title>Re: DMCA takedown notices should take fair use into consideration</title><link>http://tlf.disqus.com/dmca_takedown_notices_should_take_fair_use_into_consideration/#comment-1730663</link><description>Great post, but I'm curious.  Even with a separate, self-hosted library, you're missing out on being able to establish a present in the vibrant YouTube community, so how many of the problems caused by the DMCA does a self-hosted library really solve?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Fri, 22 Aug 2008 09:32:02 -0000</pubDate></item><item><title>Re: The Technology Liberation Front  &amp;raquo; Archive   &amp;raquo; FCC Killing BitTorrent? Not Exactly</title><link>http://tlf.disqus.com/the_technology_liberation_front_raquo_archive_raquo_fcc_killing_bittorrent_not_exactly/#comment-1464186</link><description>Maybe this new commenting system will help to prevent such misunderstandings in the future.  :-)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Thu, 14 Aug 2008 23:04:13 -0000</pubDate></item><item><title>Re: The Technology Liberation Front  &amp;raquo; Archive   &amp;raquo; FCC Killing BitTorrent? Not Exactly</title><link>http://tlf.disqus.com/the_technology_liberation_front_raquo_archive_raquo_fcc_killing_bittorrent_not_exactly/#comment-1464047</link><description>Howdy Richard!  (and Brett!)&lt;br&gt;&lt;br&gt;First, I apologize if my previous comment has offended either of you.  That was not at all my intent.&lt;br&gt;&lt;br&gt;Second, let’s take a deep breath!  It is obvious that you’re deeply invested in this emotionally, and at this pace I feel like we’re two or three comments away from invoking Godwin’s law.  Also, there’s a lot of other stuff on the Internet that’s far more “arrogant and uninformed” than my last post, so let’s try and keep some perspective.&lt;br&gt;&lt;br&gt;Third, Brett didn’t exactly attach his résumé to his comment.  I simply assumed he had a business background since he was talking about marketing, bandwidth cost, and business failures.  I think if you’re re-read his comment you’ll see that this is a reasonable assumption if you can ignore your tacit knowledge of Brett’s background.&lt;br&gt;&lt;br&gt;Fourth, and perhaps most importantly, much of this thread is suffering from a miscommunication regarding the word “efficiency.”  The real-world use, and indeed the common business and policy understanding (which is what I was assuming Brett meant), of efficiency means something like a measure of “operating properly and timely.”  Heck, most of the technically oriented people that I talk to (most of whom are software folks and not networking folks) use this colloquial meaning of efficiency.  That is how I intended the word when I first used it in this thread if only because I do not consider myself a network geek.  This is sort of a combination of all the different academic measures of a networking protocol including scalability, transfer speed, stability, and many more.&lt;br&gt;&lt;br&gt;I get the feeling that you’re using it as a descriptor of some overhead to content ratio (and please feel free to provide a definition of it if you have one you prefer).  My networking class (6 years ago) described the sort of overhead-to-content as overhead for a constant amount of content because efficiency is used in so many other ways that is has lost precision.  There is certainly less communications overhead in a direct download than in a peer-to-peer system, so perhaps this is a more direct meaning.  The papers I cited in my previous post don’t even seem to agree on what “efficiency” means.  For example, one describes efficiency as “the probability that two peers can communicate,” and assigns the lowercase Eta to represent this while another uses the same lowercase Eta, but consistently refers to the value as “effectiveness.”  Lastly, they even use the term more generally such that it could simply be interpreted as “better.”&lt;br&gt;&lt;br&gt;I am a security and privacy researcher.  I certainly have a different understanding of authorization and authentication than many technically oriented people who are not as security conscious.  I usually define these words when using their precise meaning in an open policy discussion simply because the common, real-world use of these words mixes both of the more precise academic meanings.  &lt;br&gt;&lt;br&gt;Richard, I urge you to re-read Brett’s post and indeed our conversation to this point to see how a traditional, colloquial understanding of efficiency changes things.  I think you’ll see that my comments were honestly intended to be helpful, but appear tragically inappropriate based on our miscommunication regarding “efficiency.”  Again, I apologize for any slight you (or Brett) found in my comments.&lt;br&gt;&lt;br&gt;Anyhow, getting back to the discussion, one of the reasons that I even cited any papers was that I wanted to provide some avenues of research.  I think these are decent papers describing the overall efficiency / effectiveness / performance / “goodness” of BitTorrent.  I also think they talk about a lot more than just scalability, and I would be interested to see why you think that’s their only contribution.  &lt;br&gt;&lt;br&gt;Also, you suggested that I should do more research, but didn’t provide any concrete recommendations as to where.  I am certainly interested in your thoughts on good places to start.  In particular, you keep mentioning the current infrastructure as something that is important to keep in mind, but much of what I have read recently suggests that there are several changes in the pipeline that would fundamentally alter the last mile infrastructure.  I’d be interested if you had something you felt was a good place to start related to this.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Tristam29</dc:creator><pubDate>Thu, 14 Aug 2008 22:50:05 -0000</pubDate></item><item><title>Re: The Technology Liberation Front  &amp;raquo; Archive   &amp;raquo; FCC Killing BitTorrent? Not Exactly</title><link>http://tlf.disqus.com/the_technology_liberation_front_raquo_archive_raquo_fcc_killing_bittorrent_not_exactly/#comment-1455505</link><description>Howdy Brett!&lt;br&gt;&lt;br&gt;Your statements such as the following indicate to me that you are misunderstanding or simply unaware several basic networking concepts:&lt;br&gt;&lt;br&gt;&lt;em&gt;Claims that P2P is “efficient” are complete nonsense. Nothing is more efficient than a simple, direct file transfer from source to destination. [...] Claims by BitTorrent that its software is “efficient” are, quite simply, lies. Intentional lies used to market its product.&lt;/em&gt;&lt;br&gt;&lt;br&gt;I cannot explain the entirety of computer networking to you in this comment, but I will give you some references peer-reviewed academic work analyzing BitTorrent protocols from different institutions unaffiliated with BitTorrent. &lt;br&gt;&lt;br&gt;D. Qiu and R. Srikant. Modeling and Performance Analysis of BitTorrent-like Peer-to-Peer Networks. &lt;em&gt;In SIGCOMM ’04: Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications&lt;/em&gt;, pages 367–378, New York, NY, USA, 2004. ACM.&lt;br&gt;&lt;br&gt;Here's a quote from the introduction of this paper:&lt;br&gt;&lt;br&gt;&lt;em&gt;The performance of traditional ﬁle sharing applications deteriorates rapidly as the number of clients increases, while in a well-designed P2P ﬁle sharing system, &lt;br&gt;more peers generally means better performance.&lt;/em&gt;&lt;br&gt;&lt;br&gt;D. Arthur and R. Panigrahy. Analyzing BitTorrent and Related Peer-to-Peer Networks. &lt;em&gt;In SODA ’06: Proceedings of the seventeenth annual ACM-SIAM symposium on Discrete algorithm&lt;/em&gt;, pages 961–969, New York, NY, USA, 2006. ACM.&lt;br&gt;&lt;br&gt;Here's a quote from the introduction of this paper:&lt;br&gt;&lt;br&gt;&lt;em&gt;Each ﬁle is distributed on its own network as a number of independent data blocks. A client can share individual data blocks it has fully downloaded even if it has not ﬁnished downloading the entire ﬁle. This allows for a parallelism that is impossible if entire ﬁles are treated as atomic blocks. &lt;/em&gt;&lt;br&gt;&lt;br&gt;L. Guo, S. Chen, Z. Xiao, E. Tan, X. Ding, and X. Zhang. A Performance Study of BitTorrent-like Peer-to-Peer Systems. &lt;em&gt;Selected Areas in Communications, IEEE Journal on&lt;/em&gt;, 25(1):155–169, Jan. 2007.&lt;br&gt;&lt;br&gt;Here's a quote from the introduction of this paper:&lt;br&gt;&lt;br&gt;&lt;em&gt;...the direct “tit-for-tat” mechanism of BitTorrent is simple, effective, and robust. In practice, BitTorrent systems scale fairly well during ﬂash crowd period and have been widely used for various purposes, such as for distributing large software packages...&lt;/em&gt;&lt;br&gt;&lt;br&gt;You can probably find these at any university library if you aren't able to access them online.  You will also find that each of these lists specific benefits of BitTorrent while also analyzing weaknesses in the protocol and suggesting improvements.  This is how scientists approach questions of efficiency.  They do not base their decisions on marketing material and opinion.  &lt;br&gt;&lt;br&gt;Now, you might, as Richard has, debate what network topologies are better or worse for BitTorrent use, but from a protocol standpoint, the general academic consensus is that BitTorrent is efficient.&lt;br&gt;&lt;br&gt;You continue: &lt;br&gt;&lt;br&gt;&lt;em&gt;P2P has two purposes.&lt;/em&gt;&lt;br&gt;&lt;br&gt;This is simply impossible.  P2P is a tool, which has no inherent purpose; only a rational being can have an explicit purpose assigned to its actions.  A hammer is a tool.  It was designed to embed nails into wood, but it could also be re-purposed for beating people to death.  Unfortunately, this has actually happened, but that doesn't mean we should try to "ban" hammers in some fashion.&lt;br&gt;&lt;br&gt;To address your specific concerns:  Yes, BitTorrent makes it easier to transfer intellectual property.  Then again, a car makes it easier to get away from a bank robbery.  Should we ban cars?&lt;br&gt;&lt;br&gt;Yes, BitTorrent reduces costs to content providers and increases costs for ISPs.  Then again, email reduces the cost of individual communication while hurting the profitability of entities like Hallmark and the US Post Office.  Should we ban email?&lt;br&gt;&lt;br&gt;Your last comment may indicate some of the causes of your misunderstandings:&lt;br&gt;&lt;br&gt;&lt;em&gt;The FCC decision prevented ISPs from singling BitTorrent (as opposed to, say, Limewire) out for special treatment, but still allowed them to charge users extra if they hogged bandwidth as a result of using BitTorrent’s inefficient software.&lt;/em&gt;&lt;br&gt;&lt;br&gt;BitTorrent is indeed a company, but it is also the name of a file sharing protocol.  In our discussion of networks we have been talking about the protocol and not the company.  BitTorrent, Inc. is the company that makes money selling advertising on their Torrent Entertainment Network and by helping other engineers develop BitTorrent clients for their products.  &lt;br&gt;&lt;br&gt;LimeWire is a software client that operates on the Gnutella network.  The Gnutella network is a Peer-to-Peer network, but it doesn't split up files in transit.  The Peer-to-Peer part is that it allows you to see which files all your peers are sharing.  Once you select a file, you are downloading it directly from that person's system.  Recently, the LimeWire software client implemented support for BitTorrent protocol, which would then allow LimeWire clients to use both.  Either way, the software client is distinct from LimeWire LLC, which makes money by selling a "PRO" version of their software client.&lt;br&gt;&lt;br&gt;I hope that helps clear up some confusion.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aaron Massey</dc:creator><pubDate>Wed, 13 Aug 2008 16:49:14 -0000</pubDate></item><item><title>Re: The Technology Liberation Front  &amp;raquo; Archive   &amp;raquo; FCC Killing BitTorrent? Not Exactly</title><link>http://tlf.disqus.com/the_technology_liberation_front_raquo_archive_raquo_fcc_killing_bittorrent_not_exactly/#comment-1455502</link><description>I don't really know much about multicast.  My research is in computer security and privacy, but focuses on software engineering rather than networks.  I will have to look into it.&lt;br&gt;&lt;br&gt;I am not saying that BitTorrent is the perfect protocol, but I do think it has some serious advantages.  It is economical, particularly for open source projects that don't have the resources to have a large data server.  It is simply better for popular downloads that will be found locally for most edge nodes.  I also like the fact that it effectively is it's own cache mechanism.  Thus, interrupted downloads can be easily continued through a mechanism built into the protocol.  &lt;br&gt;&lt;br&gt;I'm sure improvements could be made to BitTorrent.  Perhaps something that could adjust based on the number of local peers serving the file would be better.  My only real interest in the technical debate was to correct a somewhat minor point that the fundamental distinction in P2P networks isn't downloading versus uploading; it's "the last mile" versus "in the cloud."&lt;br&gt;&lt;br&gt;In response to your last paragraph, I am opposed to rules because they &lt;em&gt;must&lt;/em&gt; be changed if they're antithetical to progress.  Progress is really hard to identify.  There's something that Paul Graham says about startup companies that fits pretty well here: &lt;br&gt;&lt;br&gt;"A good startup idea has to be not just good but novel. And to be both good and novel, an idea probably has to seem bad to most people, or someone would already be doing it and it wouldn't be novel."  &lt;br&gt;&lt;br&gt;How can we possibly expect any regulator, even network experts such as yourself, to recognize the good ideas and account for them in their regulatory efforts?  Regulation should always be an absolute last resort.  This applies not just to regulation based on the airy principles of unqualified people, but also to well-intentioned regulation created by universally recognized experts.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aaron Massey</dc:creator><pubDate>Tue, 12 Aug 2008 09:04:00 -0000</pubDate></item><item><title>Re: The Technology Liberation Front  &amp;raquo; Archive   &amp;raquo; FCC Killing BitTorrent? Not Exactly</title><link>http://tlf.disqus.com/the_technology_liberation_front_raquo_archive_raquo_fcc_killing_bittorrent_not_exactly/#comment-1455500</link><description>&lt;em&gt;P2P would be fine for an infrastructure in which all links were uniform capacity and fully symmetrical, but that’s not the world we live in.&lt;/em&gt;  &lt;br&gt;&lt;br&gt;Yet.  The market evolved to build networks that are efficient and practical given real world conditions.  These conditions are changing.  Newer technologies such as WiMax are making it much cheaper to improve bandwith in the last mile.  In these new conditions, the market will still evolve to build networks that are efficient and practical.  The only difference is that better protocols such as BT will win.&lt;br&gt;&lt;br&gt;Richard, I get the feeling that we're viewing the network in fundamentally different ways.  You have taken the very practical "what can we do right now with the current network infrastructure" view.  Everything you have said has been 100% dead-on accurate in terms of the present network infrastructure.  I have taken the somewhat impractical "what could we do in the future" view.  I'm an academic so I get to do that sort of thing.  :-P&lt;br&gt;&lt;br&gt;They are certainly both valid views, but the later is really the reason why we don't want the FCC regulating the Internet.  I think you're nodding in this direction with your last sentence in your last comment.  No one knows whether or how quickly new technologies will alter the landscape and upset current accepted wisdom about network infrastructure.  As Tim's original post points out there are always unintended consequences to regulation.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aaron Massey</dc:creator><pubDate>Mon, 11 Aug 2008 22:34:10 -0000</pubDate></item><item><title>Re: The Technology Liberation Front  &amp;raquo; Archive   &amp;raquo; FCC Killing BitTorrent? Not Exactly</title><link>http://tlf.disqus.com/the_technology_liberation_front_raquo_archive_raquo_fcc_killing_bittorrent_not_exactly/#comment-1455498</link><description>&lt;em&gt;I don’t think it’s even possible to make this blanket statement.&lt;/em&gt;&lt;br&gt;&lt;br&gt;Well, it's certainly possible to make a generalization, but is it correct?  :-P  I should have prefaced it with "the vast majority" since I'm sure there's an exception, though I sincerely doubt that Verizon is one of them.&lt;br&gt;&lt;br&gt;At the most basic level ISPs tend towards enabling downloads simply because that's how most people use the Internet.  Home Internet connections spend the vast majority of their time idle.  Of the time they are active, the vast majority of that is downloading something.  ISPs have engineered their systems to respond to this.  &lt;br&gt;&lt;br&gt;Take a step back from the asymmetric vs. symmetric arguments (although Richard is right about this).  If you were an ISP, why would you build out the incredibly expensive infrastructure in a way other than that which was the norm for real world use?  I would be stunned if Verizon didn't have the same kind of traffic congestion that Comcast did if all it's customers decided to download files from local peers on the Verizon network rather than from the Internet at large.&lt;br&gt;&lt;br&gt;&lt;em&gt;It’s also a bit misleading to call BT more efficient because it might require fewer hops if the hops it uses are more congested.&lt;/em&gt;&lt;br&gt;&lt;br&gt;Again, I have to disagree with you, somewhat.  BT is simply a more efficient protocol.  Real world use of BT is crippled by the current architecture of most ISPs.  Again, this is why Comcast was being overrun by BT traffic.  As a result it may sometimes be more efficient to use BT and sometimes less so.  &lt;br&gt;&lt;br&gt;Think about it this way.  When Lake Pontchartrain only had a single two-lane causeway crossing it, there was a serious argument to be made at certain times of the day that it would be more efficient to simply drive around the lake rather than over it.  Does that mean that the concept of using a bridge is less efficient?  No, in theory, a bridge is more efficient than driving around an obstacle.  However, the real world situation may have differed simply because of the current state of the infrastructure.&lt;br&gt;&lt;br&gt;Eventually, the last mile connectivity problems will be resolved (probably with some wireless solution similar to WiMax, only better -- there is a reason why Comcast and TimeWarner are both investors in Clearwire).  At that point, the theoretical efficiency gains to be had with protocols like BT will be even more easy to achieve in the real world.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aaron Massey</dc:creator><pubDate>Mon, 11 Aug 2008 09:45:16 -0000</pubDate></item><item><title>Re: The Technology Liberation Front  &amp;raquo; Archive   &amp;raquo; FCC Killing BitTorrent? Not Exactly</title><link>http://tlf.disqus.com/the_technology_liberation_front_raquo_archive_raquo_fcc_killing_bittorrent_not_exactly/#comment-1455495</link><description>I have to disagree with Richard, somewhat.  The fundamental distinction is not simply the difference between upsteam and downstream.  The fundamental difference is  connectivity "in the last mile" versus "in the cloud."  &lt;br&gt;&lt;br&gt;The last leg of a connection from an ISP to a residential home user is usually low bandwidth.  P2P traffic eats this up because as Peter noted earlier the traffic doubles *in the last mile* since end users are both uploading and downloading.  However, the total number of bits moving on the network are the same.&lt;br&gt;&lt;br&gt;Let's take an (overly simple) example.  If five people download a 100 MB file using traditional services from some server outside of their local network then the ISP has 500 MB of data travel from that server through their local branch and then down to each of their end users.  In other words, 500 MB travels both "in the cloud" and in "the last mile" for a total of 1000 bits traveling on the network.&lt;br&gt;&lt;br&gt;However, if the same five people download the same 100 MB file using BitTorrent, then it could easily be the case that the first one gets it entirely through the cloud (100 MB in the cloud) and the rest get it by downloading it through last mile connections (900 MB in the last mile).  Since the last mile is usually a much lower capacity, this can put a real strain on ISPs.&lt;br&gt;&lt;br&gt;Of course, protocols like BitTorrent have serious advantages too.  Think about the situation where the server is on the other half of the world.  Now that 100 MB file could be traveling across many, many hops.  Let's say it takes 4 hops "in the cloud" before getting to the end user.  In the first case that's 2000 MB in the cloud and 500 MB in the last mile.  In the second (BitTorrent) case, that's only 400 MB in the cloud and 900 in the last mile.  Total bits traveled in the first case is 2500 MB versus 1300 MB in the second (BitTorrent) case.&lt;br&gt;&lt;br&gt;From a single ISP's standpoint though the first case is preferred.  They don't care about the network efficiency for other folks in the cloud.  They only care that their networks are far more crowded.  &lt;br&gt;&lt;br&gt;Richard is absolutely right that ISPs are engineered for downloading.  This is why the last mile bandwidth is thin.  Most of the time there isn't a lot of traffic there as compared to "in the cloud."  &lt;br&gt;&lt;br&gt;However, P2P is simply more efficient from a network standpoint.  Eventually, ISPs that adjust their networks to better support last mile connectivity will be able to produce a better product for their customers.  (It's a lot faster to download something from your neighbor using a P2P client than from some server halfway around the world.)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aaron Massey</dc:creator><pubDate>Sun, 10 Aug 2008 15:12:19 -0000</pubDate></item><item><title>Re: Google&amp;#8217;s Got Plenty of Compute Cycles</title><link>http://tlf.disqus.com/google8217s_got_plenty_of_compute_cycles/#comment-1455276</link><description>Also, your muscle memory is really just another form of cognitive energy required for optimization.  But, I guess that gets back to the HCI debate...</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aaron Massey</dc:creator><pubDate>Mon, 04 Aug 2008 14:40:55 -0000</pubDate></item><item><title>Re: Google&amp;#8217;s Got Plenty of Compute Cycles</title><link>http://tlf.disqus.com/google8217s_got_plenty_of_compute_cycles/#comment-1455275</link><description>"Of course, for really commonly-visited sites, you should probably create a bookmark so you don’t have to type it in at all."&lt;br&gt;&lt;br&gt;I only started using bookmarks when the Awesome Bar came out.  I certainly made them before that, but I didn't used them for my most commonly visited sites because they simply aren't faster than typing.  I used them for those specific pages where I found myself wanting to refer to something and couldn't remember the site URL or any search terms that would bring it up on the first few pages.&lt;br&gt;&lt;br&gt;"The top result is almost always what I’m looking for, and I have my mouse hovering over it by the time the page loads (The top Google search result’s approximate location on the page has long since become a mater of muscle memory). When you consider that I’d be shifting my hand to the mouse anyway in order to use the scroll wheel, the only real difference from using the location bar is the latency to Google’s servers."&lt;br&gt;&lt;br&gt;This is great -- for you.  It's always the "human" in human computer interaction that makes HCI generalizations difficult.  :-)  Personally, I avoid the mouse as much as possible.  Keyboard shortcuts are almost always faster for me.  (I have never used the file menu to open a new tab in Firefox.)  This is why computer interfaces have both.  &lt;br&gt;&lt;br&gt;My goal wasn't to get into a debate about HCI though, so I must have not written very well in my previous comment.  My goal was to address this part of your original post:&lt;br&gt;&lt;br&gt;"This is an example of a general attitudinal problem that’s distressingly common among geeks. Geeks have an tendency to over-value lower-level layers of the technology stacks based on the misguided belief that higher-level technologies are unnecessarily wasteful."&lt;br&gt;&lt;br&gt;Let me give the two-sentence geek side of this argument"&lt;br&gt;&lt;br&gt;There is a general attitudinal problem that's distressingly common among the technically illiterate.  Non-Geeks have a tendency to under-value the use of lower-level layers of technology stacks based on the misguided belief that higher-level technologies are just as fast.&lt;br&gt;&lt;br&gt;The key is striking the balance between investing cognitive energy to optimize the common use of a piece of technology (by learning a URL) and accepting that it may simply be faster to do it the basic "dumb" way (by just googling).</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aaron Massey</dc:creator><pubDate>Mon, 04 Aug 2008 14:20:52 -0000</pubDate></item><item><title>Re: Google&amp;#8217;s Got Plenty of Compute Cycles</title><link>http://tlf.disqus.com/google8217s_got_plenty_of_compute_cycles/#comment-1455273</link><description>While I agree with your overarching point that there are serious practical reasons to searching rather than using the address bar to specify a URL, I personally don't know that it's faster, even cognitively, than remembering the address and typing in the address bar for commonly visited sites.  I think there are two situations:&lt;br&gt;&lt;br&gt;(1)  Worst case: Searching from &lt;a href="http://google.com" rel="nofollow"&gt;google.com&lt;/a&gt; itself.&lt;br&gt;&lt;br&gt;Steps:  &lt;br&gt;  1. wait for &lt;a href="http://google.com" rel="nofollow"&gt;google.com&lt;/a&gt; to load&lt;br&gt;  2. enter search terms &lt;br&gt;  3. click "Search" button&lt;br&gt;  4. wait for results to load&lt;br&gt;  4. scan results and use mouse to click on appropriate link&lt;br&gt;  5. wait for the site to load&lt;br&gt;&lt;br&gt;(2)  Searching from a search bar on the browser.&lt;br&gt;&lt;br&gt;Steps:&lt;br&gt;  1. enter search terms and press enter&lt;br&gt;  2. wait for the results to load&lt;br&gt;  3. scan to find the right link and use mouse to click on the appropriate link&lt;br&gt;  4. wait for the site to load&lt;br&gt;&lt;br&gt;In both cases, you have a cognitive switch from keyboard to mouse mode, which is bad from an HCI standpoint and may be unnecessary if you knew the URL.  Also, in both cases you have at least one additional page load.  From a cognitive standpoint, page loads are really bad because they essentially build in time that allows people to get distracted.  (Ever searched for something and then wondered why you did it when you got the results?)  They are analogous to a "page cache miss" in operating system terms.  &lt;br&gt;&lt;br&gt;Google recognizes this and optimizes fanatically for speed, but even with these optimizations a person still has to watch to make sure the search was entered and the page is actually loading.  Then they have to recognize that the page has completed loading so that they can begin a new page load by finding the appropriate link and clicking on it.&lt;br&gt;&lt;br&gt;Also, advanced searches are hard without memory of the URL.  For example, if I wanted to find an article on copyright that I recently read on the Technology Liberation Front, I could perform a much more accurate Google search by entering search terms AND the URL like this:&lt;br&gt;&lt;br&gt;"copyright site:techliberation.com"&lt;br&gt;&lt;br&gt;If I don't know the URL, then I could get tons of other stuff on copyright that I would have to sift through before I found the specific article I wanted.&lt;br&gt;&lt;br&gt;I agree with the previous posters about the Awesome Bar, and I certainly don't have a problem with people wasting their own time with searches, but I am willing to devote some cognitive power to save time when loading commonly visited sites.  (And I think the market for selling "good" domain names shows that a lot of entrepreneurs see this as a key advantage.)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Aaron Massey</dc:creator><pubDate>Mon, 04 Aug 2008 13:48:29 -0000</pubDate></item></channel></rss>