Ask HN: Which revision control system? - <AUTHOR>

For the past few years we've been using Perforce at the company I work for.  For a number of reasons, we've been given the OK from management to switch to a free SCM system.  This is supposed to be a big opportunity to improve our process and save us money, but we're having problems finding a good replacement.
Our must-have features include; ability to import our perforce history, easy/trivial branching and merging (preferably the ability to use an external merge tool), large file support, ability to pass changes from one workstation to another without affecting everyone, and ability to work with multiple gigs of binary files (most are roughly 500k, some are 100+megs).  The binary files are mostly build artifacts, but for a large number of very good reasons we can't expect developers to generate them.  Each developer having their own branch would be nice, but isn't critical.
Our products only run and compile on Windows, so decent windows support would be nice.  We aren't exactly an MS house; our product works with the artifacts of programs that only run on Windows so it runs on Windows.  Our products are very-much closed source, so things like Github are of no use to us.
Distributed systems like Git are compelling for the workstation to workstation support.  Unfortunately Git chokes on our binary files (I get an out of memory error), and I'm afraid that the other DSCM projects will stagnate in favor of Git.  Centralized systems like Subversions are in line with the way we've always done business, but they lack the ability to view/review/pull changes on another workstation and branching/merging isn't as easy.
I'm a big fan of Git, but if it can't work with large file it won't work for us.  Subversion seems like a step backwards, but I could be wrong.  Whatever we choose, we'll be with it for a long time and use it every day.
So, HN; what revision control system would you suggest? <comment><USER2> Out of the three leading free DSCMs -- Git, Mercurial, Bazaar -- none seem in danger of going extinct any time soon. Bazaar is the foundation for Launchpad and Ubuntu, almost irrevocably. Mercurial has less buzz than Git for open- source projects, but I suspect it's even more popular in the business world, and its Windows support is solid. Mozilla uses it, anyway. So you might want to give the other distributed systems, particularly Mercurial, another look.

</comment><comment><USER3> Git _isn't_ very good for large files, unfortunately. In my experience large is quite over >100MB, though.

I'd love to convince everyone to switch to git, but I want to note that SVN's branching/merging capabilities are at par with p4's, since at least 1.4 using svnmerge and probably in 1.5 standalone. (My current employer uses p4, and I switched my last workplace over to SVN from CVS.)

It does suck to go back to centralized SCM after using a DVCS though (I clone my work p4 checkout into git for minute-to-minute use). A possible solution: if your build artifacts are most of the large-file problem, consider storing them out of band and having workstations fetch them using Ant/Ivy or something similar?

<comment><AUTHOR> I would love to have the build artifacts stored in a system for managing build artifacts, but I don't really know of any.

We could (theoretically) store the build artifacts in Subversion and the source in Git, but that would be very unpopular. No one in the company is interested in having multiple revision control systems to maintain.

Our main product is built in Visual Studio, but we use ant for the surrounding build tasks. I think of ant as being a 'better make', what does it have to do with grabbing remotely stored build artifacts?

<comment><USER3> Ivy is an addon of sorts for ant that does dependency management (e.g. libraries, etc.) It sort of jacks the Maven dependency resolution bits and leaves the rest. It's definitely not a 'system for managing build artifacts' (and it's pretty java-focused) but you can set up your own repository and have a build target fetch them, put them in the right place, etc.

I wouldn't necessarily advocate this since you'd inevitably end up having to build some system around it, but conceptually it seems like what you'd want. YMMV, I've only used it for pretty straightfoward Java stuff.

</comment></comment></comment><comment><USER4> Branching/merging on Subversion has been absolutely trivial since the version 1.5 release. Prior to that it was a nightmare, but now it's ridiculously easy.

Can we finally put this to rest now?

<comment><USER5> Agreed. Though, one caveat: SVN will slow down as it diffes large binary files. I remember reading a developer works article file about this. ([http://www.ibm.com/developerworks/java/library/j-svnbins.htm...](http://www.ibm.com/developerworks/java/library/j-svnbins.html) thanks Google!)

(PS: if I'm misinformed, or out of date, I apologize. I use SVN, but never upgrade and have PSDs in the ~100-200MB range and its not terribly fast.)

</comment></comment><comment><USER6> I really love Bazaar.

I love that it's distributed and I can version a local folder with a single command. I love the simple integration with Launchpad.net (which is annoyingly mediocre). I love that it's a single command which has all the inline help built in. I love the conflict management.

However, people with a much better understanding of the details wrote comparisons with each of the popular DVCS currently in use. I suggest if you use another VCS you at least read the Bzr side (<http://bazaar- vcs.org/BzrWhy>).

 _Specific comparisons_ :

Subversion: <http://bazaar-vcs.org/BzrVsSvn> Git: <http://bazaar- vcs.org/BzrVsGit> Mercurial: <http://bazaar-vcs.org/BzrVsHg>

<comment><USER7> Their bzr v. Mercurial comparison is a bit disingenuous at points, if not outright misleading.

Firstly, having used bzr 1.8 and 1.9, and Mercurial 1.0 and 1.1, the claim that bzr's speed is close to Mercurial's is downright hilarious. There simply is no comparison. bzr's speed is so atrocious that, when Python was looking at using bzr for its version control system, the only technique that bzr's fanboys could come up with to ensure fast checkout was to have you download a tarball of the pre-checked-out sources. You can see more at <http://www.python.org/dev/bazaar/> . Conversely, I routinely work with Python-sized repositories in Mercurial without incident. If you have one take- away, this should be it.

They also claim that bzr can swap out its backend and hg can't (patently false --the backend has in fact changed for 1.1, due out very soon; see [http://www.selenic.com/mercurial/wiki/index.cgi/fncacheRepoF...](http://www.selenic.com/mercurial/wiki/index.cgi/fncacheRepoFormat)); that Mercurial cannot be served over vanilla HTTP (it can); that Mercurial does not let you change your merge algorithm easily (it does, see [http://www.selenic.com/mercurial/wiki/index.cgi/MergeToolCon...](http://www.selenic.com/mercurial/wiki/index.cgi/MergeToolConfiguration?highlight=%28merge%29)); that Launchpad, which even you admit is mediocre, is Mercurial-only, without noting that Mercurial has <http://bitbucket.org> and similar sites; and so on.

There actually are a few advantages of bzr over hg. That site just happens to make most of them up.

<comment><USER6> That's pretty bad. Is it out of date or just overly fanboy-esque? It would be cool to put some feature list comparisons somewhere.

Right now most of this stuff seems really anecdotal because people that understand one system mostly use that system exclusively.

<comment><USER7> I honestly think most of it's just ignorance. I don't honestly think that anyone who has used Mercurial in anger can seriously be unaware of merge customization, or of the fact that Mercurial has simple revision numbers in addition to hex codes, or that Mercurial can clone from HTTP, but I can definitely see missing those features if you just messed around with it for an hour when you were trying to evaluate the two systems. Likewise, even someone who had used Mercurial fairly heavily could easily be unaware of Launchpad- like sites, or new back-ends in upcoming Mercurial versions and the like. At any rate, I don't think that the bzr team is being malicious; just uninformed.

The one point that I do think they're guilty of intentionally bending the truth are their claims of speed. bzr goes to great lengths to have more thorough history and merge tracking than either Mercurial or git. It pays for that by being slower. That's a perfectly viable trade in some cases, but bzr needs to own up to it. Instead, rather than simply admit that bzr is slower, its supporters generally try to explain ways to get around the fact bzr is slow, and then claim that the slowness doesn't matter. For example, initial clones ("bzr branch") with bzr are simply atrocious. A bzr supporter will tell you that you don't do clones that often, and besides, there are work arounds-- e.g., since bzr works with whole-file hashes like git, it can share file objects and revisions across all of the repositories on your system, making branching repositories you've already brached at least once go more quickly, and for ones you've not yet, you can just download a tarball of an existing clone and use that as the base. These arguments are weak, sidestepping the issue. I'm reminded of git in its early days, when you had to manually run very, very slow gcs every once and awhile, and its supporters shot back with, "Well, yeah, but you can totally just stick that in a cron job." Mercurial's not innocent, either; I remember its dev team trying to argue why it didn't need named branches, when everyone using git (including me!) thought that git's branching was one of its killer features. bzr needs to do what those projects did: quit explaining away the bug, and just fix it.

bzr's merge algorithm is better than either Mercurial or git's, its GUI (QBzr) is best-of-breed, and its online operational mode makes it a drop-in replacement for Subversion for sites that are trying to migrate away from old habits slowly. It also happens to be significantly slower than the competition, to the point that, much as I personally believe that Mercurial has a better power-to-usability ratio than git, I think bzr has a bad power- to-speed ratio compared to either git or Mercurial. Whether you agree with my assessment is up to you. I just wish that their comparison pages were more honest about what the trade-offs are.

</comment></comment></comment></comment><comment><USER8> I use Mercurial, but have been exploring Git a little because of what you noted -- the community momentum seems to be headed that way.

<comment><USER9> Another vote for Mercurial. Whenever a project gets that "KoolAid" feel (Git, Rails, even Haskell at times) I tend to gravitate towards its competitors, so take that with a grain of salt, but I can say that Mercurial's been great for the small teams I've used it with. On larger projects, I've unfortunately only used Subversion, but I can say that it works, at least.

<comment><USER7> I'll third the recommendation for Mercurial. There is no question that git has more community momentum--something which I hope will begin to change--but Mercurial is nevertheless an outstanding distributed version control system.

Mercurial's default mode of operation has the benefit of being extremely Subversion-like--in a good way. Indeed, if you never interact with anyone else, most of the normal Subversion commands--ci, mv, rm, add, log--"just work." There is no git-style index to worry about, no rebasing, and the command set is small and regular. That means that the learning curve is far, far shallower than git. Yet it still provides the same distributed branching and merging as git, and, though it _is_ slightly slower, the difference is truly negligible in my experience--maybe a couple percent difference at most.

What about the incredible power of git, though? What if you actually want to be rebasing and rewriting your history all the time? When you _want_ unfettered power in Mercurial, you've still got it. The `mq` extension, which can be enabled by adding a single line to your configuration file, allows you to do all the crazy patch rewriting, merging, splitting, and rebasing that git does.[1] But you can ignore that functionality if you want, and still have a very powerful and fast distributed change system.

When Fog Creek looked at going to a distributed source control system last year, I advocated Mercurial over the competitors. Though the transition wasn't seamless, I've been extremely happy with the result. The Unix experience is extremely pleasant, and TortoiseHg (<http://tortoisehg.sourceforge.net/>) provides a surprisingly solid Windows experience out-of-the-box.

If you can look past the fanboyism, I'd strongly encourage you to give Mercurial a try. I think it strikes a much better power-vs.-usability balance than git does.

[1] Except microbranching. Mercurial doesn't currently support local named branches. You can achieve similar things by using mq with qguards, if you really need them, but in practice, I find it's usually easier to just clone a second repository. In practice, although I do miss microbranches sometimes, I've found I greatly prefer the streamlined workflow of Mercurial.

<comment><AUTHOR> The momentum here seems to be pretty heavily for Mercurial... maybe I should consider git to support the underdog ;)

All kidding aside, Hg might be what we need. I'm looking into it now. Is it easy to import p4 history into Hg?

<comment><USER9> Don't take our advice like that! Try it first: You may hate the way that one VCS works compared to another. Technical merits have less to do with this choice than your own preferences.

<comment><AUTHOR> Hehe, yeah I'm trying to try it.

Unfortunately it doesn't like any of the large files (anything over 10megs), and the windows shell plugin causes explorer to run like a dog.

I've done some research on it and I want to like Hg. any advice on having it play nice with large files?

<comment><USER10> Maybe this is too far outside of the question, but particularly if you aren't going to be merging the large files, have you considered mirroring them with rsync (<http://www.samba.org/rsync/>) instead? I'm not sure tracking really large binary files is best handled by a VCS. I'm trying to read between the lines in your question, but would e.g. periodically making dated snapshots of the binaries and otherwise automatically mirroring around the newest version suffice?

The Mercurial page on binary files (<http://www.selenic.com/mercurial/wiki/index.cgi/BinaryFiles>) doesn't say anything about especially large ones.

Also, has anybody had good experience importing from p4 to hg on Windows? I've tried using tailor and some scripts from the mercurial wiki, but no success yet. One of these days I might write my own importer script (mostly because I need to import from five or six major branches, about 50k commits), but haven't had the time yet. (I'm working on Windows for similar reasons. Mercurial has been great for typical VC usage.)

<comment><AUTHOR> Our import from p4 doesn't have to work in windows. We're comfortable in Linux, we just can't develop in it.

You are correct, the binary files will not be merged. Some of them are large encrypted databases and can't be merged. The database is built based on source that may be merged, but the merge will happen in the source, and when the source merge is complete we'd rebuild the databases and check in the result. The largest number of binary files are compiled programs and very rarely change.

You're suggesting something a lot of other people in this topic have suggested. I would love to implement some kind of binary file management system; it just isn't going to happen. These binary files don't need to be merged, but they will be changing semi-frequently and are likely to be different between branches. We don't have the time and manpower to implement a system that would work for us. Either the VCS needs to handle these files or we can't use it.

I think I found a config setting deep in the dark heart of git that can make a repository friendly to large binary files. I'll check it out, and if it works we could create a set of repositories for these binary files. I'll try this and see how it goes. ( <http://www.gelato.unsw.edu.au/archives/git/0607/24058.html> )

I'm really trying to find a way to use Hg, but if it can't handle our use-case we can't use it. That doesn't mean it's a bad VCS. I really like some of its features and the fact that it is far simpler than git. I also really like that it has file explorer integration. It just needs to handle projects with an obnoxiously large code base and large binary files.

<comment><USER10> Did you look at rsync? You don't really need to implement anything.

My point, though, was that in some sense you're trying to find a way to bend a VCS into doing something well outside the strengths of VCSs, so it is worth looking into categories of tools better suited to the problem.

<comment><AUTHOR> Yes, I'm familiar with rsync. We've talked with Perforce Support a fair amount regarding large files, and they remind us that we are abusing their system. It's like using Harley Davidsons on a worksite to move around loads of dirt. It may work, but it's not the intended use.

We might be able to get that to work for some of the binary files realativly easily. The problem is that the majority of these files are build artifacts for our test programs and the builds happen in the same directory as the source (yes, this is a stupid way to do things, but we need to do what customers do, and our customers do this). It would be very hard to distinguish between build sources and build artifacts. This leaves the issue of branches. Each branch would have to 'know' which of the binaries to grab in the shared space, and update other branches at integration time.

This could be a valid way of doing things, but it would take a fair amount of effort because our environment is like the real world; dirty and complicated. For the past couple of years it's been on the backlog to clean and simplify our environment, but something more important always comes up.

<comment><USER10> Good analogy.

How do you distinguish between the build source and artifacts now? It's not difficult to specify (via filename regexes) whath should and shouldn't be examined by Mercurial as potential VC files, beyond whether or not you explicitly add them: look at the .hgignore file. (Not sure that's directly helpful, but for the archives.)

<comment><AUTHOR> We don't distinguish between them. The test programs were built and all the resulting files were checked in. Unfortunately some of the build artifacts share extensions and directories with build source, and some of the build artifacts have no extension. The only way we could add the build artifacts to .hgignore (or .gitignore) would be to manually add them one at a time, and that would be a huge task.

<comment><USER10> You can also add * to the ignore file and explicitly specify what to track, either by hand or by "hg add [fname]" in some sort of script.

I track/sync my home directory with mercurial, and did that to keep it from scanning most of my drive for updates. (You can probably do the same with git.)

(For the archives as much as you, though I hope it's useful.)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Personally, I use Git and hg at home and for small work projects.

But, for the main work projects (console games: lots of code, but also many large assets), none of the alternatives to p4 are reasonable. (Yes, I'm well aware Perforce has vast and sundry problems too).

Might be worth doing some testing on hg, if it can handle your data sizes reasonably, it meets all your other requirements I think.

</comment><comment><USER12> _Our products are very-much closed source, so things like Github are of no use to us._

For what it's worth, GitHub offers paid repositories for just this case; open- source repositories are free, but you can pay to make your repositories private. Even the biggest plan is only $200/month; see <http://github.com/plans> for more information.

<comment><AUTHOR> What makes you think we trust GitHub? ;) The only way GitHub could help us is if they were to opensource their site and let us an instance of GitHub in our datacenter.

We have some very strict rules about the code never leaving company computers, and those rules will not be changing.

<comment><USER13> gitorious is like a subset of github and is open source

<comment><AUTHOR> Thanks! That looks like it might be something we can use :)

</comment></comment></comment></comment><comment><USER14> A valuable resource comparing major scm's that I point people to when they ask me is the FreeBSD project's wiki page: <http://wiki.freebsd.org/VersionControl> Hope it helps. Regarding specifically SVN versus GIT, be sure to look at the VCSWhy link at the bottom.

<comment><AUTHOR> Thanks, that was helpful :)

</comment></comment><comment><USER15> Do not go from Perforce to Subversion. Whatever you decide. That is a massive step backwards.

<comment><USER16> I wouldn't call it a step backwards. Perhaps a step to the side.

</comment></comment><comment><USER17> I'm actually a big fan of Perforce. I don't feel that any system I've tried (~dozen) really beats it when it comes to internal software development inside of an organization. For open source, distributed version control makes a lot more sense, but internally, Perforce is pretty hard to beat and modified versions of it are used at places like Google and Microsoft.

What reasons do you dislike Perforce? Maybe we can help you pick by comparing what you're trying to move away from.

If by "given the OK" you mean you need to swap because your company doesn't want to admin/pay for Perforce licenses, then maybe you can clarify that a bit, too.

<comment><AUTHOR> Perforce is not terrible. I'd even go so far as to say; of the centralized systems, it's better than any other I've tried (including Subversion, and cvs). It could be better, but it could be much worse.

      Things we like about perforce:
       - Client side changelists for modified client side code.  This helps organize our local
         changes to make sure when we're working on multiple things they stay separate.
       - The server is solid.
       - Can handle large files, including the ability to 'forget' previous revisions to save space
         on the server.  It's abusing the system, and we've been told as much by Perforce.  It just
         happens to be the way we do business, and changing that is another project.
       - It can do branching/merging
       - The visual diff and merge tools are pretty good (mostly, more below).
       - Everything that's under revision control is in one place.  If you don't want to have the
         files on your workstation you can simply remove that tree from your view.

      Things we dislike about perforce:
       - It costs money.  At the size of our organization it costs about as much as another employee.
         This is the reason we were 'given the OK'; developers don't really care about cost as long as
         we're employed, and management doesn't really care about features as long as we're productive.
       - We've had significant issues when merging.  Conflicts are not properly flagged and "ghost" code
         (code that didn't exist in either branch) sometimes appear in the merge result.
       - The clients are very iffy.  Crashes are frequent, and the merge problems are related to
         client-side bugs.
       - No one in the company is a fan of being required to 'check out' files to get them to be writable.
         This is how perforce knows when files are modified and because there is no equivalent for new
         files people frequently forget to add files and break the build.
       - It can only show you < 1000 files in a given changelist.  Big changes like that are when it's
         most important to see what you're doing.  This is pretty common when doing branch integrations.
         When this happens you have to hit the "auto-merge" and hope for the best.
       - Branching/integrating isn't streamlined enough to really support every developer having their
         own branch.  If it was dead-simple we could support a distributed development model with a
         centralized server.
       - No real way to share code (for reviews, or collaboration) without going through the shared
         depot.  We use p4tar, but it doesn't play nice with cygwin and has it's own problems.
       - No direct way to revert code.  Reverting is a 5 step process that isn't entirely obvious.

I think that's it.

<comment><USER17> Excellent list there. I think all of your issues are all things I also see as drawbacks to Perforce. I think the main breaking point out of your list would be the merging instability you mention, which we haven't had at either of my last two companies.

We do have merging issues in a different way, but it's always because someone used the wrong flag when merging the two or didn't properly create the initial branch. Still, this is significant anyway because merging/branching really needs to be easy to manage (i.e. hard to screw up) for a tool like this.

In the mega integrations, we came up with a few tricks to work around the file size limit-- often involving merging subtrees one by one from the target branch. This is often needed organizationally for us anyway because the teams/experts are often different when it comes to resolving those merges. It results in more changelists, but it tends to work out okay and the integration history is actually in a better state regarding a proper contact for discussing it later.

We wrote our own Perforce tools at our company for sharing code for code reviews, or some teams use user/feature/"pre" branches for that. I'd like to see that improve in Perforce, but it's been pretty bearable.

What I really want is something with the maturity of Perforce in terms of tools/API/integration/monitoring/history/etc but is built on the premise of needing to do lots of merges and branches easily. I know some major organizations have gone with things like Mercurial because it felt to them like it would mature the fastest in terms of corporate needs, but I've yet to see any of the distributed version control systems that has gotten over the curve: <http://en.wikipedia.org/wiki/Image:Gartner_Hype_Cycle.svg>

I can't wait until they do, really, because the perspective that merging is central to version control is something I agree with.

</comment></comment></comment><comment><USER18> I evaluated Mercurial some months ago and found it very easy to migrate to from Subversion.

Here are some benchmarks on the Linux source tree that might be useful:

[http://laserjock.wordpress.com/2008/05/09/bzr-git-and-hg- per...](http://laserjock.wordpress.com/2008/05/09/bzr-git-and-hg-performance- on-the-linux-tree/)

This blog post is pretty good at summarizing git and mercurial: [http://importantshock.wordpress.com/2008/08/07/git-vs- mercur...](http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/)

</comment><comment><USER19> Why does Git choke on large files?

<comment><USER20> Linus Torvalds: "The git architecture simply sucks for big objects": <http://kerneltrap.org/mailarchive/git/2006/2/8/200591/thread>

</comment></comment><comment><USER21> I use darcs for personal use and it is very easy to use.

<comment><USER22> I'm sorry to say but it's starts to get messy when it's used by a team. Darcs suited me fine while worked alone with projects but as others joined we faces serious problems, including loss of data. I gave it up, switched to Mercurial and never ever missed darcs.

<comment><USER23> Even when used by yourself. Branch a project, build a complicated new feature (e.g. 50 patches), then try to merge.

The exponential merge problem really sucks.

<comment><USER7> I gave up on darcs awhile ago, but darcs 2 honestly does greatly reduce the merge issues that used to plague it. If you're still on darcs, get the upgrade. You may find you no longer need to move to a new product.

</comment></comment></comment></comment><comment><USER24> Would it perhaps be practical to pull the binary files out of SCM and build a small tool that figures out denpendencies and downloads the relevant files from the build server?

It sounds like that might ease your constraints.

<comment><AUTHOR> Something like this might be exactly what we need, but we don't make money building distributed build artifact caching systems. If we don't make money doing it, we aren't doing it :(

"Is this good for the company?"

<comment><USER24> It's often said that developers need to understand the business, and bring forward a business-case, not a technical case.

So: how much money will lose by choosing the wrong SCM today because you're unwilling to change a process you even agree is sub-optimal?

Try to count the number of check-ins, branching, merging etc. the entire team does in a year, multiply by five, and then multiply by even a few _seconds_ of lost time, annoyment and agony pr. event.

I would guess that in that perspective you can afford spending a few days seeing if you can change the build-artifact process to allow you a wider selection of SCMs.

<comment><AUTHOR> I fully understand this argument, but during the last quarterly all-hands meeting our CEO made it abundantly clear that we aren't doing anything unless it directly brings in more revenue or directly reduces overhead. One of the major reasons for switching from p4 is to reduce overhead, if we have to build a new system for it's replacement to work for us we aren't doing a very good job of reducing overhead.

</comment></comment></comment></comment><comment><USER22> I should recommend either mercurial or git, but the learning curve of git is steep.

<comment><USER25> If you set up git's bash completions, and run through a git tutorial, you'll know enough git to work on your projects. The more esoteric subcommands are generally useful in specific situations and simply don't have equivalents in most other VCSes.

</comment></comment><comment><USER26> Darcs!

I mean mercurial!

No, git!

(Aww, these computer science problems are so hard!)</comment>


RIM sues Kik for patent infringement - <AUTHOR> http://blog.davidlam.ca/2010/12/rim-sues-kik-for-patent-infringement.html

<comment><USER2> Background:

0) Kik is like cross-platform BBM for Blackberry, Android, and iOS users.

1) RIM had previously removed Kik from the Blackberry "App World" store.

2) Then two weeks later, they revoked Kik's developer keys and crippled existing Kik installs by disabling Push support. This meant Blackberry Kik users (reportedly over a million of them) would start getting Kik messages up to an hour late. Link / discussion: <http://news.ycombinator.com/item?id=1935093>

⁂

A week ago, we discussed the possibility of a lawsuit. Discussion: <http://news.ycombinator.com/item?id=1935182>

⁂

Strikes me as evil and, as some of you are saying, a bad move politically for their platform. Even if only those 1,000,000 Kik on BB users care, and most BB users don't, we developers generally give a shit, because this seems grossly uncalled for and anticompetitive.

<comment><USER3> Suing Waterloo students is also not how to build rapport with the massive number of co-op students they hire every term.

<comment><USER4> What a bitch move RIM, there will be more UofT students filling up RIM now...

</comment></comment></comment><comment><USER5> Wow this is huge. They could have just removed them from the store. Instead they start a patent suit to basically kill the company.

Interesting strategy. RIM can't do much directly about the iOS and Android competition. But they can sue popular cross-platforms apps. Evil evil evil.

<comment><USER6> I don't want to defend RIM, because I don't know anything about the lawsuit (other than it's likely to be a software patent for something relatively obvious).

But I don't see this as significantly more evil than "just removing them from the store". A lawsuit shows that RIM has a serious grievance (whether justified or not) and moves to settle the matter of competition through an official legal framework (whether flawed or not).

Unilaterally removing an application from app markets that are "open to all developers unless we say they're not" for competitive reasons strikes me as more evil in some ways. We are just a lot more used to it because of Apple's app store.

<comment><USER7> There is a significant increase in evil-ness between the two IMHO.

Banning them from the store/crippling their existing installs is basically: "we don't like you competing with our first party offerings, so get the hell off our platform"

Suing them now, given that Kik is still active on other platforms, is basically: "we don't like you competing with our offerings, so we're going to prevent you from operating _anywhere_ , even on platforms we don't own or have any control over"

I don't know about you, but the second seems a bit more evil than the first.

<comment><USER8> But at least Kik has recourse in the lawsuit case. In the former they simply don't have the right to exist because the platform holder says so. It's not good for customers and it's sure as hell not good for developers.

I agree with the parent, simply booting someone from your walled garden is more evil in the sense that they can't do anything about it.

</comment></comment></comment></comment><comment><USER9> Something funny about them being literally a block away from each other.

RIM could have walked over to their office and had been like, "hey, can yous guys stop the messenger app. k thx. bai".

Google Map: <http://bit.ly/ftLWro>

<comment><USER10> Go ahead and post long links on HN. We'd rather see the URL we're going to, and the text for really long URLs will get shortened. Example: [http://www.google.com/#sclient=psy&hl=en&q=search+fo...](http://www.google.com/#sclient=psy&hl=en&q=search+for+a+really+long+string+to+demonstrate+a+point)

</comment></comment><comment><USER11> I can't pretend to be well informed on this kind of business strategy, but wouldn't another option be to BUY Kik? Turn the iPhone and Android app into a RIM-branded, cross-platform BBM, and incorporated it into the BlackBerry client. Maybe risky, but it might help their platform more than a lawsuit... If it was a really solid app maybe iPhone or Android users would think of getting a BB for their next phone, and it might keep current BB users where they are.

I dunno, this whole affair definitely seems poorly thought out. BlackBerry app development is horrible enough as it is, and there are more and more things making it unappealing. (one of the CEOs said mobile apps are a fad a few weeks ago)

<comment><USER12> They don't under any circumstances WANT a cross-platform BBM.

BBM is the one killer-app keeping people using blackberries due to the network effect.

The only reason I still have a blackberry is because friends and family in far off countries also have them, and vice-versa - we cna talk to each other freely and easily on the run. BBM is really good at this. We would _all_ have to switch to something new, and just as reliable, at the same time to make jumping platforms viable.

As soon as there is something that works as well as BBM that's cross platform, lots of people will jump ship as soon as they are able, as long as they can reach their BBM friends (who will eventually jump ship too)

<comment><USER11> I hear this a lot about BBM, although I've never used it. I think you're right, of course, about them not wanting a cross-platform version. I just wondered if there was something other than a lawsuit they could have done, since a lawsuit seems so ill-fated from a PR angle... Android and iOS are going to continue eating their lunch whether Kik exists or not.

</comment></comment></comment><comment><USER13> Nothing says we want developers on our platform like suing the popular app makers. Even if there seemed to be some IP theft here, I think lawsuit is a horrible way to solve the problem. There is just no PR spin you could put here to fix this.

<comment><USER14> How else would you resolve an IP theft situation? Asking nicely?

<comment><USER15> Not approving the app in the first place into their store, wait till they are popular and a threat.

If they are stealing IP then RIM should not have let them onto the store to begin with. RIM should know what their IP is.

I would say that if they RIM already reviewed their app and let it onto the store, that is a tacit implication that they approved the app with RIM's (alleged) IP in it.

<comment><USER14> Perhaps RIM's IP attorney isn't working at the app store? Lucky for RIM though, I'm sure the app store legal agreements don't include anything silly like having an approval be a license for any RIM IP.

</comment></comment></comment></comment><comment><USER16> Perhaps in relation to this patent (and a host of others, I'm sure)...

METHOD FOR CREATING A PEER-TO-PEER IMMEDIATE MESSAGING SOLUTION WITHOUT USING AN INSTANT MESSAGING SERVER

<http://www.google.com/patents/about?id=RRaUAAAAEBAJ>

<comment><USER17> This might be stupid/crazy, but might it make sense to have a DNS for phone numbers? Why not have 6464680751.cell resolve to a public IP address of my phone? If another phone wants to send it a text message or make a phone call, could it just use the variety of protocols on top of IP?

<comment><USER18> I think ENUM (<http://en.wikipedia.org/wiki/Telephone_Number_Mapping>) is meant to do this. It is used by some telecoms.

</comment></comment></comment><comment><USER19> As a founder of a Waterloo startup this pisses me off to no end. If RIM hadn't taken such hostile actions Kik may very well have been a Next Big Thing. I mean, Kik might still achieve that - and I damn hope they do - but it will be in spite of RIM's hostility.

Now for Waterloo region which has been trying to make a name for itself in the tech/startup world, having a Next Big Thing coming out of it would have been huge. It would have benefited the region from a financial standpoint (think PayPal mafia) and it would have benefited the region from a talent attraction standpoint.

RIM's actions are not only an assault on Kik they're an assault on Waterloo's startup community as a whole.

<comment><USER20> I think they still will be the next big thing. This will buy them more publicity than any kind of PR budget.

</comment></comment><comment><USER21> I would love to see the specific patent(s) Kik is infringing upon. It's a pretty standard IM client, if as the article says it is for: "sent, delivered, read, and even when a user is typing a message." then RIM has a lot of apps to go after.

Could be something more than that, as the CEO was a RIM employee at one point.

</comment><comment><USER22> I'm sorry but how is this patentable : "I haven't read the Statement of Claim outlining RIM's allegations against Kik yet, but I suspect that the patent at issue covers a messaging platform that provides sent, delivered, read, and typing indicators."

Having family work at their Waterloo head office leaves me torn and full of questions. Even though I don't own a RIM phone, I handled their Storm and it's rock solid. The feel is much better my 3G test phone or couple of Android phones, but as a developer I choose to support companies based on merit. RIM just came down a notch in my book.

I compared Kik on my Android and the BBM on the Storm. I would be flabbergasted to find out the Canadian courts would allow this claim to play out.

</comment><comment><USER23> I wonder when they will sue skype (which also has these indicators)...

Funny how RIM wrote an open letter (strangely removed from their site now) about how patents were a problem, and needed to be reformed. They got sued for similarly obvious patents not long ago, and had a very different attitude from the defendant's side of the argument.

Article about the now redacted letter: <http://goo.gl/e6e4U>

</comment><comment><USER24> Anyone able to attain a copy of the lawsuit?

This is what the article links to: [http://cas-ncr-nter03.cas- satj.gc.ca/IndexingQueries/infp_RE...](http://cas-ncr-nter03.cas- satj.gc.ca/IndexingQueries/infp_RE_info_e.php?court_no=T-1996-10)

I doubt this lawsuit has any real substance. Other than RIM dragging Kik through the equivalent of a legal hell, there doesn't seem to be much there.

</comment><comment> mike-cardwell I will _never_ buy a product from RIM now.

<comment><USER6> Why not wait until you learn a few more details than a vague "RIM sues Kik for something" post before you decide to boycott a company?

<comment><USER25> Before invalidating kik's keys, they removed kik from the bb market once before, claiming battery drain as the problem. If that was honestly the problem they had with it, there wouldn't be a lawsuit now, or there would've been one earlier. This is most definitely an evil attempt at keeping bbm relevant which began with a pretty sneaky excuse.

</comment></comment></comment><comment><USER26> Not mentioned here, but "RIM said Kik Chief Executive Ted Livingston worked on product strategy for its BlackBerry Messenger."

[http://online.wsj.com/article/SB1000142405274870459480457564...](http://online.wsj.com/article/SB10001424052748704594804575648932379804088.html)

Not a minor point.

</comment><comment><USER27> I guess RIM went to the Oracle school of business. They're going to find out exactly why this is a VERY bad move. They're going to have an awful time trying attract developers for their platform.

</comment><comment><USER28> lol! I guess it's official. RIM has decided they're a has been.

<comment><USER24> Without even reading the lawsuit, this has been declared official?

C'mon now, let's not be quick to judge. What if this lawsuit had to do with Kik violating your privacy? Sharing your contacts' information, etc.

</comment></comment><comment><USER29> Rim is taking a significant risk that its patents will be invalidated now for obviousness, or, just as likely, if prior art surfaces.

</comment><comment><USER30> I wonder what the feasibility would be of developing a web client for BlackBerry, with long-polling or websockets for the notifications.

<http://us.blackberry.com/developers/browserdev/>

The key viral feature was using the addressbook to populate the contact list, and you'd lose that, but still be able to implement a bunch of the other stuff. I can't tell from that browserdev page how much of the "widget API" is stuff that you'd need to get bundled up and signed, and how much is just available in the browser.

Either way, this is a pretty developer-hostile move on RIM's part. That's okay, though; all indications are that RIM is capable of developing a large selection of beautiful, compelling, worthwhile first-party apps for the Playbook. A third-party developer ecosystem would really just weigh the platform down.

</comment><comment><USER31> While I agree with the consensus that this is evil (essentially cutting a start-up off at it's knees), RIM has a legal obligation to enforce that patent if they know someone is infringing or they risk losing it. The Kik founder should have been much more vocal about being booted and having his keys revoked; now he makes himself look like an easy target. He really needs to put PR pressure on RIM at this point if Kik is going to survive.

<comment><USER3> I think you're confusing patent with trademark:

"As a trademark must be used to maintain rights in relation to that mark, a trademark can be 'abandoned' or its registration can be cancelled or revoked if the mark is not continuously used. By comparison, patents and copyrights cannot be 'abandoned' and a patent holder or copyright owner can generally enforce their rights without taking any particular action to maintain the patent or copyright."

[http://en.wikipedia.org/wiki/Trademark#Comparison_with_paten...](http://en.wikipedia.org/wiki/Trademark#Comparison_with_patents.2C_designs_and_copyright)

<comment><USER32> Are you an IP lawyer, 'cause if not ...

I can easily see how choosing not to enforce a patent might make it harder to claim infringement in a later case.

It's not that the patent would expire, but that there would be a precedent of not caring about infringers.

<comment><USER3> IANAL, but does that make what I said wrong? He didn't say anything about setting precedent, he said they risk "losing" the patent if they do not enforce it, which is just not true. If you have a source saying otherwise, I'd love to see it.

<comment><USER32> IANAL, but I have a vague memory from a patent talk. So, I can't disprove you, but I can remain more skeptical of your claim, unless you're an IP lawyer -- in which case I'd assume you know something I don't.

Regarding the semantics of "lose" -- why does it matter in any discussion of real-world actions or motivations?

Even if I don't lose something, if I do things to erode its usefulness, I've essentially lost its functionality. Therefore regardless of whether I legally lose the thing or not, I'm going to resist doing things that (possibly) reduce its effectiveness -- the result (in terms of my actions) is the same.

</comment></comment></comment></comment></comment><comment><USER33> From this, it would seem that Kik violated both Apple and RIM store guidelines: [http://getsatisfaction.com/kik/topics/serious_privacy_flaw_w...](http://getsatisfaction.com/kik/topics/serious_privacy_flaw_within_kik)

My take: RIM saw the violations and the threat to BBM and decided to ban Kik. Apple saw the violations and the threat to BBM and decided to leave them alone. Makes sense in both cases

</comment><comment><USER15> > I haven't read the Statement of Claim outlining RIM's allegations against > Kik yet, but I suspect that the patent at issue covers a messaging platform > that provides sent, delivered, read, and typing indicators.

So the guy admits to not reading the statement outlining the allegation, but he will comment on it anyway.

</comment><comment><USER34> BBM is the key of BB existence for regular/most BB users outside Enterprise. Without BBM, BB is probably crippled.

</comment><comment><USER35> I hope the Barbra Streisand Effect happens here.

I love Kik; it is a brilliantly simple app that I use everyday and I would certainly be happy if more of my friends used it.

</comment><comment><USER36> How else would you expect RIM to react to a product that infringes on one its core features? It's been pushing BBM heavily in its marketing campaigns, and can't afford to have that exclusivity taken away.

Doesn't seem evil to me.

<comment><USER37> By outdoing them in features, performance, installed userbase. You know, competing.

<comment><USER36> So should Apple drop all the lawsuits it has pending against other companies so it can focus more on competing?

What I'm saying is that it doesn't seem unreasonable, as others are making it out to be, for RIM to sue a company for making a product that's nearly identical to its own.</comment></comment></comment>


How we screwed (almost) the whole Apple community - <AUTHOR> http://day4.se/how-we-screwed-almost-the-whole-apple-community <comment><USER2> They might be severely overestimating the stupidity of the masses [1] here by only considering the those who actually responded in comments or twitter.

 _Either they perceived the news as truth, or called it fake, no grey zone in between. The split between the two camps, was quite unequal. An estimate would be that 90% regarded the screw as a fact and based all the further opinion on that, only 10% were critical to accuracy._

This smells like massive response bias. I imagine most skeptical and critical readers get tired of responding with the obvious "hmm, how do we know this is true?" response.

A more interesting statistic would be how many people saw it and didn't find it interesting enough to warrant further investigation. I believe I saw the headline, rolled my eyes, and went back to work.

That's not to say lock-out isn't an important consideration, but it didn't pass the "this can be verified" test, and anyway, it would be obvious enough once the new iPhone came out.

[1] Edit: maybe the masses are stupid (I'm not convinced of this), but the vocal rush to judgement of a few is not necessarily a representative sample.

<comment><USER3> The exact point is that the critics remain silent, while the believers (or those doing it on purpose) carry the false news forward. Then those posts will appear on the search engines. Then those searching about the topic will become convinced based on big number of similar posts.

<comment><USER4> Attempting to correct misinformation, for instance, here on Hacker News, is essentially impossible and pointless. This screw story, like many others ("MBP Retina is unrepairable", etc.) play into an ideology[1].

And no facts, no matter how well sourced, can defeat ideology when the ideologues have the down button and outnumber the critical thinker.

For instance, pointing out that Apple licensed the technology they got from Xerox back in the day, a stone cold and indisputable fact, gets down voted into invisibility and claims that it isn't true and that it was stolen, here on Hacker News. The claim that Apple stole from Xerox has been repeated so often and in so many cases that it has become "fact" in their minds. Another example is the idea that Apple didn't invent any new technology with the iPhone. They need this to be true, so they spread all kinds of nonsense (like 2001, a movie, is "prior art", which shows a significant lack of understanding of what patents are)... and they believe it.

It isn't simply that people are gullible, its that ideology (and apple hating is a prevalent ideology) is stronger than reality for so many people.

[1] Maybe religion is a better word, it feels more accurate, but is more likely to be taken as a pejorative so I'm going with ideology.

<comment><USER5> This sounds a bit like the problem of the proliferation of news on cable TV and on the Internet. With there being so many choices for news, people tend to migrate to the source that aligns with their preconceived notions. So instead of being presented with information that may run counter to what they believe to be the truth, they only get their views confirmed.

With so many sources available, it's difficult to correct misinformation. People tend to believe what they want the truth to be, and now they have sources to confirm it.

</comment></comment></comment></comment><comment><USER6> fwiw, they didn't just submit to reddit and wait. They also submitted it to (at least some) sites directly. Doesn't look like any dedicated rumors sites actually published it. Getting fake rumor submissions is a daily occurrence for rumor sites.

The actual stories were posted on smaller sites which questioned the authenticity. And Wired actually did an article on custom screws and used the image as a jumping off point: [http://www.wired.com/gadgetlab/2012/08/if- theres-a-screw-the...](http://www.wired.com/gadgetlab/2012/08/if-theres-a- screw-theres-a-way-custom-screws-wont-stop-the-diy-community/)

So you can look at as either a success or failure.

(disclaimer: I run MacRumors.com)

<comment><USER7> Actually, this comment here is the one that makes me think. I realised when I ran across it that I and, judging by the comments in this thread, others are taking the article at face value as truth despite that same article having just told us not to do that.

<comment><USER8> That direction of thinking will only drive you crazy. Skepticism is good but don't take it too far.

Also there is at least some proof that it was posted 5 days ago: <http://imgur.com/fkyQS> and [http://www.reddit.com/r/apple/comments/xvnvo/a_friend_took_a...](http://www.reddit.com/r/apple/comments/xvnvo/a_friend_took_a_photo_a_while_ago_at_that_fruit/)

I suppose we can question that day4.se were really the ones who planted it... but, does it matter who planted it? The conclusion is the same.

<comment><USER7> Please, examine the post to which I replied. The point is not a question of whether the facts you laid out are true. You are correct in that they don't matter so much. But consider in the context of the GP post: we have the article appearing to lay things out fairly closely to "look how much everyone believed us" versus the comment saying "well, not everyone". That is to say, the message of the article still holds just fine, but it would still be fair to carry this direction of thinking as far as "is their analysis totally on the level?" Given that _this_ is more or less the message of the article, I was just noting how, even with this very message in front of us, we aren't necessarily heeding it as well as we could.

<comment><USER8> Ah, that wasn't quite clear. I agree, day4.se may not have had the effect they claimed they had.

</comment></comment></comment></comment></comment><comment><USER9> Maybe a more accurate headline would read "How (almost) the whole Apple community is screwed". On one hand, you have the people who believe this. On the other hand, you have the ones who do not. In the middle is those who don't care. We'll disregard them for this argument.

The people who believe the false rumor of a custom Apple screw are, at least to a large extent, the people who wouldn't put it past Apple. There's a point being made there; Apple has done a lot in their short history of mainstream popularity to lock users out of their hardware and software. A custom screw wouldn't be anything out of the ordinary. With this argument, Apple has developed a notorious reputation and when people are believing this without questioning it, it means the Apple community (as opposed to just Apple users) is screwed.

The ones who would not believe it, I feel, are split into two camps. Ones who saw no evidence of this being true, and ones who could not reconcile it in their mind that Apple would be doing something like this. The ones who didn't believe it because of a lack of evidence is the community Apple (and every other company) needs on their side. The ones who didn't believe it because they didn't want to believe it do so out of a blind love for Apple, and denial that Apple could betray them. Even if this is a small number of people (you can't deny they exist, though), it's still evidence that the Apple community is screwed.

The first group is full of people who either hate Apple for similar-but- opposite reasons to the last group or people who are suspicious of Apple's history (especially after the newest Macbook Pro). There is merit in their mindset, and that's not good for the Apple community. The last group is full of done-no-wrong supporters, who will praise anything Apple creates for better or worse. The lack of critical thinking and constructive feedback and criticism is bad for the Apple community. Who knows if a review of a new product is 10/10 because it's a good product or because it's an Apple product?

This is just my analysis, and I am happy to discuss alternative viewpoints. For what it's worth, I'm not upset that these guys made a fake. It gives a great view into the mindset of Apple news publishings and reactions.

<comment><USER10> It's not Apple community. It's just people. The same rumor can be started about anything popular with the same success. We had chain letters about facebook charging for access and all kinds of other baloney long time ago. snopes.com has loads of it. There's always some percent of people with low critical thinking, and always some percent of irresponsible bloggers/press which think spreading the rumor is always more profitable than fact-checking it (and they are probably right - nobody ever got rich on ad dollars earned by not publishing something).

<comment><USER6> The flip side is, is it such a crime for blogs to publish these things that seem obviously fake? Even when they qualify it?

We're not talking the New York Times here. We're talking Apple-fan blogs.

If I forward you a link by email of something interesting but probably fake, do you get offended by me sending you something possibly fake? No, if you are interested in Apple stuff, then you probably find it interesting, even if fake.

Casual blogs are the equivalent of passing along interesting stuff found on the internet, fake or not.

<comment><USER8> ...Says someone in the business of spreading rumors.

You had the disclaimer on your top level comment but not this one: "(disclaimer: I run MacRumors.com)"

<comment><USER6> sure, I guess I didn't bother qualify the post, because I wasn't lumping MacRumors in with the "casual Apple-fan blog" in my mind. That's perhaps why we didn't post it.

</comment></comment></comment></comment></comment><comment><USER11> This whole thing can be reduced to "people who engage in idle gossip are generally speaking not the sharpest pencils in the box".

Most people with half a brain just kept their mouth shut, so there's really no way to draw any conclusion about the Apple community as a whole, unless you can produce an accurate number on the people that ignored the whole thing.

</comment><comment><USER12> The funny thing is Apple does make their own screws. When they replaced my back glass at the Apple Store they also replaced the screws so I would be unable to service it later.

[http://www.ifixit.com/blog/2011/01/20/apples-diabolical- plan...](http://www.ifixit.com/blog/2011/01/20/apples-diabolical-plan-to- screw-your-iphone/)

<comment><USER13> Thanks for the link.

I'm a long-time customer of iFixit, but I've been really disappointed in iFixit's attempts to shill their products with FUD (warranted or not) about Apple. It reminds me of the "Chewie's" chewing gum scene in Clerks, where the gum salesman is ranting about the cigarette industry.

Every critical post they make is a long diatribe followed by a shilling of their products that does nothing to solve the larger problem. It's all about selling their product. And hey, it's their right, but I find it tacky.

What's the point of their $10 "liberation" kit? It includes the pentalobe driver for the screws they're replacing. Why would I _really_ need to replace the screws at this point? I don't.

I thought this was a recent iFixit trend, but I see they've been using these tactics for a while.

<comment><USER14> Kyle from iFixit here. I just wanted to say that we just present our perspective. The way we see things has evolved from taking apart thousands of gizmos and learning from people all around the world what goes wrong with hardware. We're constantly inspired my creative repairs.

Our goal is to help people get things fixed, and encourage designs that are long lasting.

You're certainly welcome to disagree with us. I don't think we're any more opinionated than Apple's designs are. We have a different perspective, and we share it. We back up our opinion with relevant products. People only buy them if they find them useful.

The Liberation kit was a fun way for everyone to get involved in the process. We also sell standalone Pentalobe drivers—so if you want to keep your original screws, you can do that too. Having Phillips screws on your phone is actually quite convenient—most eyeglass kits have the small Phillips drivers, so if you're in much better shape if you ever need to open your phone up to dry it out while you're on a trip. The liberation kit is effectively the same thing Apple techs use when you take it in for service and they swap out your screws for Pentalobe ones.

iFixit isn't about marketing gimmicks. We didn't build the world's largest repair manual and open source it just to sell tools. We're trying to change the world.

Repair is win-win-win. You save some money by making something work again, the manufacturer wins because their product is useful longer, and the environment wins because it didn't end up in a landfill.

I'm convinced that what the world needs now—more than ever—is a free, open source repair manual for every thing. That's what we're building, and it gets better every day.

<comment><USER15> By publicly suggesting that Apple did something wrong, you guarantee yourself a large number of enemies.

<comment><USER16> and even larger amount of followers ;)

</comment></comment></comment></comment></comment><comment><USER17> What's funny is there's no indication from the drawing that the screw would only work in one direction; it just needs a special screwdriver, and you have to spend 10 minutes figuring out its proper orientation. When manufacturers ship non-standard screws, they simply create a market for non-standard screwdrivers. I had to get a three-pronged screwdriver to get into my Wii, and it presented little obstacle. Given the difficulty of actually using this particular design however, a discerning reader, and especially a tech journalist should be able to see that this is completely stupid and impractical. Apple is not in the business of employing technicians to spend half their days orienting screwdrivers.

</comment><comment><USER18> This is the brave new world of SEO in our media. Once reputable news sources are more than willing to throw all their credibility out the door so that they can be the louder wall of an echo chamber for the sake of impressions.

<comment><USER19> Didn't the article point out that most of the "major" news sources covering this pointed out that this was an unconfirmed rumor?

<comment><USER20> That doesn't affect SEO, does it?

</comment></comment></comment><comment><USER21> I wish web designers would stop putting light grey text on white backgrounds.

</comment><comment><USER22> Does anybody else hate those pale, faded out font colors? It does make the page look better when you are glancing at it not trying to read anything but it sure makes reading textual content (the actual point of blogs and most websites) much more difficult.

<comment><USER23> Check out: <http://www.readability.com/bookmarklets/>

Here's how it looks: <http://awesomescreenshot.com/02fd25oe4>

<comment><USER24> Wow, those humongous margins are far worse than the low contrast. Is there a customizable equivalent around?

<comment><USER25> There is readable [1]. It gives you a bookmarklet with your personal preferences.

[1]: <http://readable.tastefulwords.com/>

</comment></comment></comment></comment><comment><USER26> The media is hungry: there is simply not enough news to report to fill the pages, and real news is dull and requires a lot of effort to understand and write about.

So the media have to grasp every rumor, every speculation, everything which can be made into a scandal.

They would never, ever, say "nothing to see here, pass on". That would be loosing sales for them.

</comment><comment><USER27> "A lie can travel halfway around the world while the truth is putting on its shoes." - Mark Twain (attributed)

</comment><comment><USER28> "When someone presents a bit of loose facts on Twitter, I usually respond with something like "64% of the facts on the Internet is 48% incorrect according to 52% of respondents", completely made up numbers out of my head, but it makes people think a little extra."

I really hate that particular brand of quip.

I find it most often employed by people who want to effortlessly dismiss some statistic that they happen to disagree with.

I'm not claiming that's the case here or that Twitter is full of solid, factual information. Rather, that it's a worthless way to respond. At least the original posts in such cases, no matter how loose provide a context for someone inclined to search out of the facts.

</comment><comment><USER29> Even if I doubted the veracity of the news, I would still be unhappy about even the concept of an "unremovable" screw on my Apple hardware and my comments would reflect my dissatisfaction with this idea itself, irrespective of veracity. By assuming that people talking on Google+, facebook, twitter, etc. are buying the idea hook, line and sinker, it ignores the likely possibility that some people may just be reacting to the idea itself and hope that their comments, along with the rest of the masses, would dissuade both Apple (in this hypothetical situation) or any company that would attempt a similar design in the future.

</comment><comment><USER30> of course, the real problem is that Apple will read this rumour and then get the idea of implementing these screws to lock consumers out of their devices and achieve the utopia of "no consumer serviceable parts".

</comment><comment><USER31> This sounds a whole like like the Sokal Affair - take a look at it on wikipedia if not familiar. And all before the Internet.

</comment><comment><USER32> This seems awfully irresponsible.

<comment><USER33> In what way?

<comment><USER32> Spreading false rumors, especially a potentially damaging one.

</comment></comment></comment><comment><USER34> The author could have saved a lot of time and effort in coming to the conclusion that distance from the truth is problematic. Jean Baudrillard wrote about it in "Simulacrum and Simulation" 40 years ago, which was adapted into a movie called "Multiplicity," starring Michael Keaton.

</comment><comment><USER35> First of all, this problem isn't unique to tech journalism or the Internet. Stuff like this has happened in old media several times in the past--where's the outrage for that?

Secondly, the spread of misinformation, when it does happen this quickly, is usually rectified just as quickly. The good thing about most reputable tech blogs is that updates happen quickly and often. Anything you might have accepted as fact one day might be dispelled the next.

Aside from Apple's stock tanking several years ago when Ryan Block published a news story on Engadget about delayed iPhone shipments, when was the last time anyone was hurt by this sort of misinformation, anyway?

</comment><comment><USER36> I think it's fair to say the Apple community got exactly what it wanted here. This sort of "trick" wouldn't be playable on any other community, because its rabid fanboys tend to care about other things than screws.

Apple fanboys however... They care about the margins of product-announcement papers and reads the future from them like gipsy-queens reads tea-leaves. It's an impressive performance, but still oh so pointless.

Because they miss the important thing: A screw is an implementation detail. What you want is open access to the bits which matters: SIM, battery, storage, platform and bootloaders.

Provide me with that and I couldn't care less what screws you use.

</comment><comment><USER37> A more interesting question is the drawbacks of taking time to scrutinize, or making more conditional statements, or waiting for confirmation. Meme direction seems to be set pretty early, and hard to move once set. It's a commonplace of politics that you have to react within the news cycle or the story gets away from you, and everyone agrees this is not a good thing.

So anyone taking the time to actually think through a bit is surrendering time, at an important moment in the discussion, to less careful people.

</comment><comment><USER31> This reminds me of the Sokal Affair: <http://en.wikipedia.org/wiki/Sokal_affair>

Very similar idea - and all before the Internet.

</comment><comment><USER38> What role does truth play?

I think most readers understand that apple news is rumor (unless it comes from apple). So the reader doesn't really care if the news is true. They want are stating their opinions as if it were true. They may not explicitly say "i know this is probably fake, but if not, apple can go screw themselves."

Similarly, the publishers are purely reporting the existence of this conversation to their readers. Like "hey, this is what folks are talking about, you might be interested".

</comment><comment><USER39> My grandfather sends me those political chain emails asking if they have any validity. He's pretty skeptical and deletes the majority of these, but every now and again he wants more information. That's where I come in. Last night I responded to one where the author attacked his opponent's credibility without any cited sources, for or against. I wrote him a long response about the need for sources, as well as the need to check the source's credibility.

What this article points out is how the news media is very hungry for new stories, and their need to publish as soon as possible. This means unverified information passes through the journalistic filter. This also points out, like the emails above, that people will generally fall for confirmation bias in many cases. Even HN has bouts of the echo chamber. It's really hard to counter, even when you are actively guarding against it.

Manual critical thinking and checking sources _all the time_ is very mentally draining. I would bet that most to all of us have some form of automatic first-pass mental filter that immediately questions "facts" contained in email chain letters, or the latest fad technology if it has too many buzzwords, or Facebook posts. That is a shortcut we've developed so we don't have to manually think about every bit of information that comes across our desks. It goes immediately to the mental round file.

Unfortunately, there are people out there that do not have this filter. Maybe they haven't mentally trained to look for these kinds of problems. Maybe they were referred to the story by a trusted source, like a good friend or a prominent publication. Maybe the information fell precisely into their particular confirmation bias that it bypassed their skepticism. Political advertising _thrives_ on this problem. Unscrupulous con men thrive off this problem.

But it happens to us all the time. I fall for it all the time, even though I try to find the "real" facts and am generally skeptical of most things. Thus it doesn't surprise me that people fell for the screw hoax, because Apple is traditionally very secretive and has a history of locking out DIYers. That screw fit Apple's MO to a T, and thus likely slipped through many of the internet bullshit filters and went viral. It happens. It will happen again.

The best we can do is try our best to root out false information, and accept that we will be fooled from time to time.

</comment><comment><USER40> This isn't limited to Apple, this isn't limited to tech. The small fish eat the lies of the smaller fish, and in turn get eaten by the medium fish, and a rumor turns in to a meal down the road for aggregator-type media sites. This happens with tech, but also with gossip, news, politics, everything.

This isn't new, either. This is just a cyclical case of lazy journalism.

</comment><comment><USER41> Just listen to the news tonight and count how many times dramatic reports are immediately followed by "...independent sources say".

</comment><comment><USER42> It's really interesting to look at the ways in which media distribution models have changed--especially the level of perceived authenticity in television 40 years ago vs now. As the internet becomes a greater and greater form of information dissemination, new models are going to need to develop in order to provide truth in media.

</comment><comment><USER31> <http://en.wikipedia.org/wiki/Sokal_affair>

</comment><comment><USER43> For more information on how the media is manipulated in the 21st century, check out Ryan Holiday's book: [http://www.amazon.com/Trust-Me-Lying- Confessions-Manipulator...](http://www.amazon.com/Trust-Me-Lying-Confessions- Manipulator/dp/159184553X)

</comment><comment><USER44> Clearly the game of Telephone has never been able to have a higher impact than it does today with the speed and scale of the social internet.

But I think there is one question left unanswered: Why are we assuming this story itself is in fact true? Because it's written on a blog? :)

</comment><comment><USER45> Reminds me of this book: Trust Me, I'm Lying: Confessions of a Media Manipulator [http://www.amazon.com/Trust-Me-Lying-Confessions- Manipulator...](http://www.amazon.com/Trust-Me-Lying-Confessions- Manipulator/dp/159184553X/)

</comment><comment><USER19> I wonder how often companies pull stunts this against their competitors.

<comment><USER46> Would the Mojave bait-and-switch count? Like this article, it was intended to be publicly revealed. <http://en.wikipedia.org/wiki/Mojave_Experiment>

</comment></comment><comment><USER47> I see what happened. Apple, attempting to mitigate the damage caused when drawings of their new incompatible screw design leaked, has found a couple of patsies to claim it was a hoax.

</comment><comment><USER48> >We must become more critical of what we read and think 'Is this reasonable? '

The problem w/ this prescription is that just b/c something is 'unreasonable' to us doesn't make it untrue.

</comment><comment><USER49> _"Apple is the world's largest company"_. Last time I checked Apple was listed somewhere around 30 (20th for most profitable). Maybe Day4 didn't check there facts...

</comment><comment><USER50> This reminds me of a Dilbert episode: <http://www.youtube.com/watch?v=DEOOFanQms0>

</comment><comment><USER51> Hold on. How do we know this article is even true?!

<comment><USER52> Funny, after reading i thought this too, so did some google'n... how do we know google isn't in on this too? <.<

</comment></comment><comment><USER53> All the more reason why we need to teach kids in elem schools now how to identify real info and research sources. What a mess.

<comment><USER14> (iFixit here.) We told every reporter we talked to that it was a fake. But we didn't get very many calls.

</comment></comment><comment><USER54> Could somebody explain what makes any of this stuff "security"?

Go ahead and make some weird top secret screw. We'll 3D print a drive for it.

</comment><comment><USER55> Does anyone else have a really hard time reading this? Need a little more contrast on the font color, por favor.

</comment><comment><USER56> Make the body font on your blog bigger - its all out of proportion with the rest of the site design.

</comment><comment><USER57> I think it'd be hilariously ironic if a story came out next week claiming this story to be a fake.

</comment><comment><USER58> On the net, everyday is April 1st.

</comment><comment><USER59> Didn't hear about this. Apple user. Guess the "(almost)" is a very large or small almost.

</comment><comment><USER60> Apple is the world's largest company, so they can take a few knocks.

Claims the article, by what measure?

<comment><AUTHOR> It was true for a moment by market cap. That's probably where they got the notion.

[http://en.wikipedia.org/wiki/List_of_corporations_by_market_...](http://en.wikipedia.org/wiki/List_of_corporations_by_market_capitalization)

</comment></comment><comment><USER61> They're called _rumors_ a for reason. People expect most rumors to be bullshit anyway.

</comment><comment><USER62> Please change title to: How we (almost) screwed the whole Apple community

kthxbye

</comment><comment><USER63> Another day, another blog with low-contrast text.

</comment><comment><USER64> So if I post an article about RIM betting the farm in a new phone based on Solaris and the stock tanks because of the domino effect in the news, am I liable?

Yep, the poster should be in jail.

</comment><comment><USER65> This is absolutely hilarious. Come up with some !@#% that doesn't make any sense and watch the hordes make it the most important news since the invention of agriculture!

</comment><comment><USER66> unrelated discussion. did anyone think this site is hard to read? the font size and color...

</comment><comment><USER67> It's funny because it's a pun.</comment>


Find Cities with Similar Climates - <AUTHOR> http://mikemcbrearty.com/climate/ <comment><USER2> I tried to search for my city and got back:

      EAST LONDON, SOUTH AFRICA
      LONDON AIRPORT, CANADA

I would have thought London (UK) might have got a mention.

<comment><USER3> When I type "København" it responds with an empty page. It seems like any non- ascii character makes the page crash.

It doesn't have "Copenhagen", only "Koebenhavn" which nobody uses.

<comment><USER4> One of the cities it gives for Estonia is "Pjarnu", for Pärnu.

But then it also thinks the capital is "Tallin", rather than Tallinn.

</comment></comment></comment><comment><USER5> This city search is the worst one I've ever used. Devs, please test your sites, even the toy projects.

<comment><USER6> I typed in 3 large US cities and got 3 "no results found". Google map API is your friend.

<comment><USER7> I tried London, but it only gave me a place in South Africa or a canadian airport.

</comment></comment></comment><comment><USER8> Nice idea. I like the clean interface and it's very responsive. Nice comparison feature as well. I think you need some kind of canonical name resolution though.

For example, searching for 'Moscow' returns nothing -- but it is found as 'Moskva'. Also, nothing is returned for 'Nairobi', but it's there as 'Jomo Kenyatta International' which is their airport. Not exactly obvious.

Overall very nice work.

</comment><comment><USER9> Can you just list the cities you actually support instead of masquerading with a search box?

</comment><comment><USER10> Is it only showing airports because the dataset uses climate data from aeronautical sources?

</comment><comment><USER11> Do a search for 'South Africa' \- the cities it returns are all small cities which are just big enough to have airports. In the cases of places like new york, only the airport is returned.

I'm just guessing here, but possibly this is a database of geographical locations with a population figure attached. The author has probably swapped 'only show cities with greater than X population' with 'only show cities with less than X population'. Airports would have very low population, and that's why there are so many airports. It also doesn't handle non-ASCII characters.

It's a guess, anyway.

<comment><USER12> [https://en.wikipedia.org/wiki/National_Weather_Service](https://en.wikipedia.org/wiki/National_Weather_Service)

in the US the NWS / NOAA operates weather stations at airports, wouldn't be surprised if other countries have similar programs.

my hometown has a much larger population than the next one over, but the next one over is listed because there's an airport there.

<comment><USER11> You missed my point maybe - the fact that your hometown is bigger and not listed is exactly the problem. There are a number of small cities listed that do not have airports also. The key is that a listed city either lists as 'airport' (population 0), or is a very small city (low population). So my point is that the filtering is probably backwards, and it's filtering out big cities instead of filtering out small ones.

Maybe. ;)

<comment><USER13> Might it not be likely that an application dependent on weather data is actually limited to locations for which weather data is available, regardless of population?

</comment></comment></comment></comment><comment><USER14> Nice hack. The visualization is well done.

Feature idea: It would be cool if you could sketch the min/max temperatures and rainfall you'd like for your ideal city, and it would tell you what's close to that.

</comment><comment><USER15> What I really like about the search, is that it accounts for seasons on different hemispheres. E.g. it returns Lisboa and Cadiz as places similar to Sydney. Even though the months with hot weather are different in the Northern and Southern Hemispheres.

As a side note - clicking the name of a place shows an overlay in the graph. It was not obvious at first; the names are in black.

</comment><comment><AUTHOR> I must confess I didn't expect the number of curt "the search is inadequate" responses; I posted this because it solved a particular problem I've been curious about for some time, and does a great job of displaying the data in a way that's useful to me. I found the graph display quite handy--using the same scaling on all pages allows me to easily compare different locations in different browser tabs, but the data is displayed simply enough that I'm not overwhelmed with sparklines like I am at other climate sites.

That said, I'd love to see more details about the underlying dataset; given the way the search works it appears to be a SQL database, so I assume it's public data from somewhere?

<comment><USER16> I put this site together, glad it's useful for you. The graphs are my take on climatographs.

The data is from the National Oceanic and Atmospheric Administration National Climatic Data Center, see [http://www.ncdc.noaa.gov/](http://www.ncdc.noaa.gov/). The dataset has good coverage of the US, but as people have pointed out, there are gaps in many places, such as the UK. The comparison is based on the monthly average max and min temperatures.

</comment></comment><comment><USER17> Interesting.

As far as I can tell though, it doesn't seem to account for humidity, pollution or wind patterns. The former is especially important for hot climates (or times of the year) since when it comes to comfort, hot dry >> hot humid.

<comment><USER18> Yeah it doesn't account for a lot of stuff. I'm in a Mediterranean climate here and it's suggesting a lot of places that are very far from that. If it's supposed to be used for plant growing related purposes it's not going to be very useful.

</comment></comment><comment><USER19> Results found for: amsterdam

* No results found.

Great product!

<comment><USER20> That doesn't sound very nice...

</comment></comment><comment><USER21> I'm getting a blank page on Safari. [http://mikemcbrearty.com/climate/search?q=Vitória](http://mikemcbrearty.com/climate/search?q=Vitória)

</comment><comment><USER20> Having trouble with "[http://mikemcbrearty.com/climate/search?q=moscow"](http://mikemcbrearty.com/climate/search?q=moscow")

</comment><comment> at-fates-hands Trying to figure out the point of this. It's counter intuitive to how most people think. If I want to move, chances are, I want to move somewhere different than the climate I'm already in. Same thing for vacation. I'm still trying to find a reason I want to go somewhere with the same climate as the one I'm currently in.

Perhaps a better idea would be to show places which are completely opposite of the one you're already in.

<comment><USER22> For me it was the opposite: I choose where I live and I prefer mild climates like southern California in the fall, or Chicago in September. I'd love to see a fully-blossomed climate-view during the year, to city-jump during the most liveable seasons (avoid Chicago Nov-April or July-August for example)

</comment></comment><comment><USER23> I tried searching for my city (Tromsø), and got an absolutely blank page back.

At least tell me "City not found".

<comment><USER24> It looks like it works if you write it 'Tromso'. But you have to write Copenhagen as 'Koebenhavn', so it seems inconsistent in handling the ø.

</comment></comment><comment><USER25> Overall, this is pretty alright, though I'm looking at the climate results for Boston in the summertime right now, and as sweat pours down my face I really really wish that 25°C was the average temperature around here in June-July.

</comment><comment><USER26> Why are the colours so similar?

What about a link to see cities that are the most opposite?

</comment><comment><USER27> It doesn't know about London?

        Results found for: london

        EAST LONDON, SOUTH AFRICA
        LONDON AIRPORT, CANADA

</comment><comment><USER28> Nice Project.

Bug: as soon as you enter mon ASCI Charaters in the search, it will return a blank page, tried: münchen (munich), 東京 (Tokyo).

</comment><comment><USER29> Some sort of filter-by-country, or even just more than 10 results would be a nice addition.

And a 'minimum population' control.

</comment><comment><USER30> Adding in maps would also be interesting - seeing where these different "similar" places on the planet are.

</comment><comment><USER31> Nice idea. Though I think "hours of sunlight" is probably more important than "precipitation.

</comment><comment><USER32> Doesn't find Tampere, Finland.

</comment><comment><USER33> I couldn't find Kathmandu, Nepal on it. Thanks, pretty cool site!

</comment><comment><USER34> Cool, although the recall leaves something to be desired.

</comment><comment><USER35> Seems to only show airpots.

</comment><comment><USER36> something missing from the title "some cities"</comment>


Meta-data surveillance being used to catch perps - <AUTHOR> http://www.theguardian.com/uk-news/2013/oct/04/madeleine-mccann-inquiry-mobile-phone-data

<comment><AUTHOR> Basically meta-data being used to trace people's footsteps - their mobile footprints - to look for potential perps that may have abducted Madeleine.

This is frightening. I'd like an end to this story. But this feels like it's a crossing a line. And can be used for further justification for the surveillance state.</comment>


Show HN: Taurus.io launch - Set up product tours for web apps in 15 min - <AUTHOR> https://taurus.io

<comment><AUTHOR> After being in beta for almost 4 months and a ton of great feedback from HN, we've finally launched Taurus. We're still looking for ways to improve the product so any feedback or comments are of course welcome.</comment>


An Explanation of Cricket (2009) - <AUTHOR> https://www.cs.purdue.edu/homes/hosking/cricket/explanation.htm? <comment><USER3> You have two sides, one out in the field and one in. Each man that's in the side that's in goes out, and when he's out he comes in and the next man goes in until he's out. When they are all out, the side that's out comes in and the side thats been in goes out and tries to get those coming in, out. Sometimes you get men still in and not out.

When a man goes out to go in, the men who are out try to get him out, and when he is out he goes in and the next man in goes out and goes in. There are two men called umpires who stay all out all the time and they decide when the men who are in are out. When both sides have been in and all the men have been out, and both sides have been out twice after all the men have been in, including those who are not out, that is the end of the game!

<comment><USER4> Does anyone know of a good audio recording of this quote?

<comment> cam- It used to be on tea towels that you could buy for a dollar when you were on vacation in Foster-Tuncurry.

</comment></comment></comment><comment><USER5> Test cricket (international matches played over five days) is a truly wonderful experience that I urge everyone to try and watch* at least once.

When you try and explain that the most engaging of matches can end in a draw, after all that time, you rarely succeed on winning over sceptics, but find a friend that is willing to sit and watch for a few days and try it out.

*or listen to, it's equally at home on the radio, where you can keep up in a state of semi-aware engagement. Test cricket doesn't require complete concentration, just a willingness to know what is going on.

<comment><USER6> For those who don't know it: in cricket, a draw is different from a tie. A tie means both teams are equally strong, a draw that no conclusion could be reached because time ran out, either because the weaker team managed to postpone defeat long enough or because of the weather (playing in bad light or in rain makes the game too dangerous, so play can get stopped, even when one team is on the brink of victory. Watching the weather forecast is very important in test cricket)

Draws can be very interestng even if the teams involved have widely different strengths.

Ties in test cricket are extremely rare. There were 2 in over 2000 tests since 1877.([https://en.m.wikipedia.org/wiki/Tied_Test](https://en.m.wikipedia.org/wiki/Tied_Test))

<comment><USER7> Only us Brits would invent a game decided largely by the weather.

Quite apart from rescuing a side in a desperate position by raining for two whole days, even slight changes in atmospheric conditions significantly affect the difficulty of batting for reasonably evenly matched professional sides.

</comment></comment></comment><comment><USER8> So... pretty much this: [https://www.youtube.com/watch?v=dEH4ahCCrJo](https://www.youtube.com/watch?v=dEH4ahCCrJo), right? ;)

</comment><comment><USER9> > "The most infamous event in cricket was the 1932-33 English tour of > Australia "

Many fans of the game would likely disagree; personally, a couple of match fixing scandals and the underarm delivery vs New Zealand were worse. [https://www.youtube.com/watch?v=UkQRERykq5M](https://www.youtube.com/watch?v=UkQRERykq5M)

<comment><USER10> I have always wondered why we have not had a repeat of the underarm delivery [1], but just done by bowling overarm very, very slowly. As far as I know there is no rule in how fast the ball has to be bowled and if you bowled very slowly the ball would reach the batsman rolling along the ground.

1\. For those that don't know the history of the underarm delivery, in a match between Australia and New Zealand the final ball was bowled underarm so the batsman had no chance of hitting the ball over the fence for 6. This was the only way NZ could win. For historical reasons bowling underarm had been allowed, but it had not been used for more than 100 years.

Edit. There have been some changes to the rules so you can't let a ball bounce more than twice now [2]. You should be able to bowl very slowly though.

2\. [https://en.m.wikipedia.org/wiki/No_ball](https://en.m.wikipedia.org/wiki/No_ball)

<comment><USER7> A very slow ball with no spin is very easy to hit for six, especially if you're delivering the ball with an unnatural movement so the batsman knows your intention from your arm movement.

Fast bowlers bowling towards the end of limited overs cricket and facing aggressive attacking shots actually do bowl occasional "slower balls" using their normal delivery stride to try to catch out opponents who tend to mistime shots when the ball arrives slightly later at ~70mph rather than the expected ~85mph. But you're not going to catch them out with a gentle 30mph lob down the pitch, just like a decent tennis player will not have difficulty returning an attempted drop shot serve

<comment><USER11> >just like a decent tennis player will not have difficulty returning an attempted drop shot serve.

County champ tennis player and LTA coach here. You might not see this much from tour players (though Razzano had a crack at it in Paris this year [0]) but I can assure you a well executed 'drop shot' serve will befuddle even the most experienced player. So much so that it is considered unsporting [1]. In fact, 'under hand' serving is allowed in tennis but it is conventional - though not a rule - to inform your opponent that you are doing so for this very reason.

For a quick take on why, your expectation (long serve) will be violated. While you're getting over that you'll need to be running up court (getting on for 12m depending on where you were standing to receive) starting from a stance that was balanced to go left or right. By the time you get there, you're likely going to be hitting the ball on the drop with an over extended racquet which limits your shot selection quite drastically, and the whole back of the court is now open, rendering you vulnerable to a lob or passing shot - <USER2> very things that make drop shots such an effective weapon.

I know a few players who are constantly working on their drop serves, but it is a super hard shot to play well, which is at least one of the reasons you won't see it much at pro tournaments, another being that spectators will literally boo you.

(edit: balance parens)

[0] [http://m.tennis.com/photos-video/2015/05/videos-razzano- late...](http://m.tennis.com/photos-video/2015/05/videos-razzano-latest- unleash-underhand-serve-roland-garros-twice/55013/#.Ve_vh9l4XCR) [1] [http://m.tennis.com/pro-game/2014/07/gentlemans- disagreement...](http://m.tennis.com/pro-game/2014/07/gentlemans- disagreement/52156/#.Ve_tvdl4XCR)

</comment></comment></comment></comment><comment><USER12> I came to the UK aged 10 from (the mighty) USA. Forced to play cricket at school. No f*cker told me the rules. I wish I'd' had this page back then.

<comment><USER9> Did you bat or bowl? For batting: 'See ball, hit ball'. 'The faster it comes, the harder you hit' For bowling: never figured it out :(

</comment></comment><comment><USER13> This is like Cricket 101 - a wonderful introduction to the rules of cricket.

However, this is from 2009 and as such slightly dated. Recent years have seen the explosion of Twenty20 (20 over games - shorter and supposedly more entertaining) as well as other innovations like Batting and Bowling powerplays and so on.

<comment><USER14> The writer is probably one of the games many purists! I love Twenty20 but I have to agree with whoever said "it's not cricket, it's a form of entertainment performed using cricket equipment".

</comment></comment><comment><USER15> Cricket is a great example of where disruption created a larger pie for the incumbent. Kerry Packer popularised the One Day International at a time where the (five day) Tests were on their last legs, which in turn re-ignighted interest in the Tests.

Cricket has experienced no other disruption prior or since.

<comment><USER16> what about the latest craze T20? It's a multibillion dollar industry! Tho I am too much of a purist to watch it often, Its far more monetarily successful than the last disruption. Its tailor made for 2000s generation who dont want to sit thro a whole day to enjoy cricket

<comment><USER15> incremental improvement

<comment><USER7> It pays vastly more than Test and One Day cricket, has radically shifted the balance between batting attack and defence (including in the One Day Cricket played today) by making strike rates matter more than batting averages, has made superstars of players that would have previously been considered severely lacking in defensive technique, encouraged athletic fielding and made Indian franchises an attractive and lucrative destination for overseas players. And probably made generations of kids grow up not wanting to be bowlers! That's a pretty radical set of changes.

<comment><USER15> I agree with all points regarding the impact.

The reason Twenty20 was incremental was because it took an entrepreneur like Packer, with connections and money, to prove that cricket could even be changed in the first place.

</comment></comment></comment></comment></comment><comment><USER17> The MCC is a good resource for the laws of cricket: [https://www.lords.org/mcc/laws-of- cricket/laws/](https://www.lords.org/mcc/laws-of-cricket/laws/)

</comment><comment><USER18> [http://www.youtube.com/watch?v=BBRAzmaq5x0](http://www.youtube.com/watch?v=BBRAzmaq5x0)

Gotta love a game that has fielding positions "Silly Point", "Deep Square Leg", "Cow Corner" and "Short Third Man".

[https://upload.wikimedia.org/wikipedia/commons/b/be/Cricketf...](https://upload.wikimedia.org/wikipedia/commons/b/be/Cricketfieldingpositions.jpg)

Cricket is to me one of those sports that I hated _the idea_ of playing and watching, but I always enjoyed it when I did.

</comment><comment><USER19> [https://www.youtube.com/watch?v=dEH4ahCCrJo](https://www.youtube.com/watch?v=dEH4ahCCrJo) I would leave this here since its most relevant.

I grew up playing cricket.I recently broke my foot playing after not having played for 15 years(collided with an idiot that ran across the pitch close to my crease to backup the wicket in an attempt to run me out).

Go West Indies(we sure aren't what we use to be)!!

<comment><USER20> > I recently broke my foot playing after not having played for 15 > years(collided with an idiot that ran across the pitch close to my crease to > backup the wicket in an attempt to run me out).

I feel like cousin avi from snatch here, that or rick in that it appears like you're just shuffling english words together in a sentence.

</comment></comment><comment><USER21> Just to right the last section: England currently holds the Ashes after this summer's series.

<comment><USER22> shhhhh.

</comment></comment><comment><USER23> Was in London last month and toured Lord's Cricket Ground. That experience got me to watch some test and ODI matches between England and Australia on ESPN3.com. Strange for an American with no Commonwealth ties!

</comment><comment><USER24> Reg Explains Cricket [https://www.youtube.com/watch?v=83oa1S0x9zI](https://www.youtube.com/watch?v=83oa1S0x9zI)

</comment><comment><USER25> [http://www.dangermouse.net/cricket/](http://www.dangermouse.net/cricket/) is good too

</comment><comment><USER26> i almost understood cricket one time ... then a bunch of badgers came out from the floor and i was completely lost again

</comment><comment><USER27> I was hoping to see this when I clicked: [http://cricket.csail.mit.edu/](http://cricket.csail.mit.edu/)</comment>