This is John Kozubik's Typepad Profile.
Join Typepad and start following John Kozubik's activity
Join Now!
Already a member? Sign In
John Kozubik
San Francisco, California
Recent Activity
I have been an EFF supporter for a very long time and am excited about the work that they do. To a lesser degree, I am interested in, and support sister organizations of the EFF, such as Electronic Frontier Finland.... Continue reading
In light of current events, I think it is time to begin discussing "Peak Internet" in the same way that we discuss "Peak Oil" or "Peak Credit". The last two weeks have included Comcast potentially de-peering due to end user... Continue reading
And so, in Q1 of 2011, rsync.net will provide a wireless private network at each of its physical locations (San Diego California, Denver Colorado, Zurich Switzerland, and Hong Kong) which will allow customers to physically approach the datacenter and access their stored data without traversing The Internet. This will ensure that bad policy will have to enter the stone age to keep you from accessing your data. Continue reading
We have been publishing our Warrant Canary weekly at rsync.net for almost five years now. We are happy to report that in this time, no warrants of any kind have been served to us. Continue reading
Image
I've been running an HTPC of some kind or another for almost ten years now, and my user interface has finally come (almost) full circle. Continue reading
John Kozubik is now following The Typepad Team
Mar 15, 2010
@Wodin : You are correct regarding the 'true' command. The explanation is, we need 'echo' in the chroot jail for other rsync.net functions, and do not need 'true', so it's a very small optimization towards keeping the chroot jail as small and simple as possible. In this case, probably superfluous, since 'true' is so simple. @ gpenguin : Your points are well taken. There is one other issue, though ... if we can implement mercurial in a manner that is similar to how we implemented svn and git, using only components written in C, then we can consider it. But we cannot put a python interpreter, etc., into the chroot jail. How much / what portions of hg are in python ?
@uou : No plans for mercurial, or any other DVCS support in the future. Please see the paragraph above: That being said, we will not be adding any further such systems. There will not be cvs or Mercurial support in the future (although I am aware of some ways to run Mercurial over a git, or subversion "transport" and users are free to do so). Once we add mercurial there is going to be another DVCS de jour, and so on. I feel like things have solidified a bit with svn and git as the "standard" offerings and we don't want to add any more binaries and libraries to these systems. I'd appreciate hearing any comments on our interpretation of the landscape ... is hg supplanting svn and git en masse ?
Well, you're talking about two different things there. The FreeBSD/X/Ion combination was indeed much more usable than OSX. That's why I needed to add these third party software packages to OSX to get things like focus-follows-mouse and so on. So I think we're in agreement there. I do still, in fact, miss that desktop environment. But the convenience factor has OSX winning hands down. To use the specific example above, the acroread package on FreeBSD typically requires ALL of linux-base (we're talking gigabytes of installed files here), a kernel module that is required from that point forward, and additional configuration in Opera. At the end of the day you have a clumsy viewer that launches separately and crashes often. Certainly there are all manner of interesting things I could do with the ports dependencies to install "merely" some smaller subset of linux base, etc., but we're still talking about a terrifically cluttered, overinstalled system just to look at a PDF.
I don't think the privacy policy in any way precludes Google from using DNS trails to provide "better" search results to the public at large. If some random web browser shows up and searches for "widgets" and Google has noticed that people who nslookup this widget site tend to also nslookup sites X, Y and Z in some connected fashion afterwords, then Google can adjunct PageRank with that information. That's not disallowed by the privacy policy. They wouldn't be combining the data with "other data that Google might have about your use of other services" - they would be combining it with PageRank to generate new search results for the public at large. (never mind how much trust we should place in their privacy policy - let's assume for the sake of discussion that it is never diluted and always enforced)
Well, the point of the above post was not to focus on whether Google Public DNS is a good or a bad thing ... I think it's bad, from the point of view of Internet monoculture, but that's really just an aside ... or a personal comment. The point here is that I have yet to hear a plausible rationale for the existence of this service, other than a very hazy "google aggregates a lot of data and somehow makes money off of that". So, the point of the post was what I believe to be a plausible rationale. I think they are going to start to adjunct PageRank with "out of band" data to improve search relevance. If you want to delve into the infrastructure ramifications of the service, the NANOG link I posted contains a thoughtful discussion.
Review of the performance documentation, located here: http://code.google.com/speed/public-dns/docs/performance.html neither bolsters nor negates my contention that Google will use their DNS as an adjunct to PageRank, and thus "discourage" caching. On the one hand, they (rightly) point to "(t)he trend towards lower DNS TTL values" and "cache isolation", but their solution to this is simply to accept these trends and throw more hardware and geographic redundancy at the problem - which is easy, if you're Google. On the other hand, Google is going to be prefetching name resolution. Their explanation is a bit hazy, but it does not stand to reason that search results will be more relevant based on prefetched name lookups... So, in addition to examining the default cache settings for name resolution in things like Chrome and Android, I'd also like to see how a "normal" name lookup is formed vs. a prefetched lookup. My contention would imply the ability for Google to distinguish between the two...
I believe that Google will begin delivering search results based not only on PageRank but an amalgam of PageRank and other, increasingly "out of band" information. Continue reading
An interesting article on Freenet and meta networks on the Internet can be found here: http://www.guardian.co.uk/technology/2009/nov/26/dark-side-internet-freenet/ I was particularly interested in this portion: According to the police, for criminal users of services such as Freenet, the end is coming anyway. The PCeU spokesman says, "The anonymity things, there are ways to get round them, and we do get round them. When you use the internet, something's always recorded somewhere. It's a question of identifying who is holding that information." This is most certainly true - but note the key assumption "When you use the Internet...". This is the part that is so badly misunderstood and an assumption that is misleading and dangerous to free speech. The core of FSOSA is that "the mere existence of portable computers, open wireless networking standards and encryption guarantee the populace access to free speech - even without the Internet."
In September, the Tor anonymity network was blocked in China "in anticipation of the CCP October 1, 2009 60th anniversary." As can be seen in a post on the Tor blog: https://blog.torproject.org/blog/picturing-tor-censorship-in-china Providers of Tor "bridges" almost immediately stepped in to fill the void of Tor connectivity in China. This matches a previous increase in Iranian users earlier in the year: https://blog.torproject.org/blog/measuring-tor-and-iran-part-two Although providing a Tor bridge is technically just as easy (perhaps a bit easier, actually, since it is neither an exit nor a published relay) as providing a normal Tor relay, it is slightly more difficult for the end user (in China, perhaps) to acquire and use. So it would be wrong to suggest that the Chinese government has had no effect on Chinese users of Tor. However, it is very clear that we are witnessing just one of many arms races between state actors and individuals. In a contest like this, it is easy to respond to the overwhelming resources of a state actor and conclude that they can win this arms race. There are weaknesses in the Tor bridge protocol (mostly related to bridge distribution) and it doesn't take a states resources to exploit them. But improvements will be made and new protocols deployed. FSOSA does not stipulate that this arms race can be avoided, nor does it stipulate that it is impossible for a state to "win". What FSOSA stipulates is that the only way that China can "win" is not by blocking Tor, but by blocking modern commerce.
First, please note the appeal in the original post to be more specific about your clips. Don't tell us "it's 1080p" - tell us the bitrate as well. BD and HD DVD rips are all over the place in terms of bitrate, as can be seen from this chart: http://forum.blu-ray.com/showthread.php?t=3338 When you do your tests with osx86, please monitor your core usage. Release versions of VLC may still be single-core, which will lead (of course) to very poor performanc e. OSXBMC is multi core aware, and I suggest you test with the latest version of that. I have no comments on a CoreAVC conspiracy. If it could be made to work with OSXBMC, I would happily pay $8 for it. I will ask Elan if that is possible. Let us know how your tests go, with specific bitrates and specific core usage measurements.