What US Software Companies Should Understand About the Rest of the World - <AUTHOR> https://medium.com/@did_78238/what-us-software-companies-should-understand-about-the-rest-of-the-world-783e8dbca758#.b2b3slmak <comment><USER3> This reads like some slightly useful, but obvious, advice mixed with attempts to "stick it" to companies based in the US.

I think it's telling in your example that the friend laughs because their grandma did it, not that the friend themselves did it. Beyond that, by your own admission all the money in tech makes bootstrapping harder, not easier, because it drives up costs. So your example makes even less sense, unless you intend to point out the ignorance of laughing at someone bragging about it.

You're also not the first to recognize that labor is more expensive in the US. Many companies acted on this information in the early 2000's, and it did not exactly result in a complete exodus of software development jobs. Culture, language, and even timezone differences can be a problem. Paying someone in Eastern Europe 30k/year instead of a US developer 100k/year to develop a product does not necessarily result in 70k/year worth of savings.

Interestingly I feel like some of what you say here goes against your recommendations in your internationalization article: the implication is that we should all hire Eastern European developers, but your internationalization article talks about the perils of thinking that all you need to do is slap a new language on your product and think that it's OK for another country.

If you're developing a product to be sold in a given country, and you hire developers from that country, you can empower your developers to act with more discretion.

<comment><USER4> I think you're missing the point here. He's coming at it from a sales perspective. I.e. if you're trying to sell into Romania then there's no point bragging about being bootstrapped because that is a normal way of life for them. You also should recognise that they can produce the same products at a fraction of the cost, and so you may just be too expensive.

On the R&D thing, of course there are issues with going international with development, but if you find the right people, you'll find that many are extremely competent and easy to communicate with.

<comment><USER5> Articles like this completely ignore brain drain. "Extremely competent" becomes more of a rarity when high-quality developers in Eastern Europe move to Germany or the US.

The reality is that nearly all of the time it's not "the same product." When it is, it's great for whoever made it, but when it's not, you're making the very serious decision to release a worse product to cut your costs. Sometimes it's worth it, sometimes it's not.

<comment><USER4> This is true - I've been told that Twitter has actively recruited university students in Romania. However, some people would simply prefer not to move to the US because of personal reasons.

The cheaper clones may also be a lot worse in practice, but hey, it seems to be working for China ...

<comment><USER6> > This is true - I've been told that Twitter has actively recruited university > students in Romania.

This may be because Romanians seem to have a disproportionate interest in natural language processing.

</comment></comment></comment></comment></comment><comment><USER7> > A good developer in Eastern Europe now costs $1000-$1500 a month

I haven't found this to be true, at least when trying to build an international "work from home team".

I've found most estimates for the cost of skilled labor in other countries to be low. Example: For software developers in South America, a good rule of thumb is you need to pay at least half of what you would pay in the US.

I have some people who do marketing for me in the Philippines. They need to be getting about a third of what a US person would be getting.

In both scenarios, you will be able to find people for a lot less, but you will have issues with quality and reliability. This is because even though the job market might suck in their country. You are still dealing with people who are trying to live a comfortable life. In order to get first world productivity, there is a base level of first world comfort that the employer needs to provide (food, air conditioning, health insurance, internet, computer equipment, car, social status, etc...)

Another factor to consider is that as you approach the upper echelons of play, pay rates start to converge at an international level - regardless of where the person actually lives (not a full convergence).

<comment><USER8> >I've found most estimates for the cost of skilled labor in other countries to be low

One thing people forget is that major goods cost the same all over the world. Cars in India cost almost as much as cars in the US, decent models cost more. Electronics in Brazil cost more than what they do in the US. So you just can't pay people such low wages.

<comment><USER7> We recently had to equip someone in Argentina with a Macbook Pro. It cost literally double what it would cost here and it didn't matter if he bought it there or we bought it here and shipped it to him. (we opted for the latter and they hit us with import fees)

</comment></comment></comment><comment><USER9> _3\. You are paying your developers how much?_

Ironically this was how I felt sometimes talking to various EU-based companies I was considering working with last year. Especially given the popularity of the "you're a contractor your first year, then maybe you become an employee" model.

I was looking at a situation where:

1\. The base pay was already less than my prior salary had been, and

2\. Because of the "start as contractor" model I'd get to pay at least an additional 15% in tax for the privilege of working for them, and

3\. Because contractors are responsible for their own insurance, I'd get to pay for that out of my own pocket too, and

4\. Since even the base pre-tax, pre-overhead rate was about 20% less than my prior salary, it'd kill me when time came to negotiate for my next job -- it'd be the same as being set back multiple years' worth of seniority/experience, since salary negotiation always starts with what you made at your last job.

I ran the math on one offer and it came out close to an effective 40% cut plus a likely significant reduction in whatever I'd make at future jobs. And that's just flat-out unacceptable.

<comment><USER10> See, and no tripled salary at 20% tax rate would ever pull me to a country where I pay 3000$ per month for a toilet with bed, every toddler has the right to bear arms, clowns like Trump are even seriously considered for presidency, and my kids don't get free health insurance, daycare and later on great education until college level.

And nope, I don't feel unfairly treated by leaving 50% of my paycheck on the desk in exchange for a society with an overall super low crime rate because everyone here has a minimum amount of money here and the same right to the same chances of starting out in life.

Guess it's simply a different lifestyle. :)

<comment><USER11> I understand and agree with the egalitarian spirit of your post, but...

1) Housing in the vast majority of the US is inexpensive. Paying $3000 for a tiny room is something that pretty much only happens in SF proper and Manhattan.

2) Crime, quality of public schools, etc. are all completely dependent on where you live. As economically unfair as it is, software developer salaries in most of the country are high enough to place you firmly into the middle/upper-middle class, which means that you can afford to live where it's safe and schools are good.

It's morally questionable but American software developers are paid enough that they can for the most part ignore the systemic economic issues that plague the US.

<comment><USER12> > American software developers are paid enough that they can for the most part > ignore the systemic economic issues that plague the US.

We could use a heaping reminder of this every time an argument about social issues comes up on HN.

</comment></comment></comment></comment><comment><USER13> Here is what my fellow Eastern Europeans do not know (and I'm from there so I'm qualified):

> A good developer in Eastern Europe now costs $1000-$1500

> a month. I kid you not.

In Eastern Europe definition of a good developer is "hamburger flipper which knows a little of HTML". I kid you not. Also work ethics are horrendous.

In short it ends up much cheaper to hire somebody in mid-west than from Eastern Europe (even though I tried very very hard).

The really good developer in Eastern Europe is $6000/month - less than US mid- west but you have to adjust for time change, logistic, trust, etc. So you end up at same.

<comment><USER14> Developers are pretty mobile so you should expect that wages will converge on a global basis.

The UK (outside of London) seems to be quite cheap.

<comment><USER13> Exactly - wages for software developers are pretty much the same all over the world. Of course, Bay Area is kinda crazy these days but that is just a temporary flux (I hope).

<comment><USER14> Bay area salaries are just disappearing into housing and transport costs. I don't see salaries coming down, but a continued fleeing of development out of the area.

</comment></comment></comment></comment><comment><USER15> > It really helps to have R&D office in Europe, India or Philippines, you > definitely should consider this if you want to keep your dev costs down.

I'm sorry but my anecdotal experience totally disagrees with this.

The problem really isn't developer quality -- which I believe is quite high in a lot of places, _my problem is that it 's so hard to work across time zones and countries_. Your costs are cheaper but your productivity sucks.

<comment><USER16> Move the whole team to Romania, no need work across timezones.

<comment><USER17> Well, how come the teams that are already fully in Romania not out-competing Silicon Valley?

<comment><USER18> Same answer as for India and all the other cheaper locations; it's easy to get simple development done thanks to all the (chiefly American!) tools for drag and drop development, testing etc available nowadays, but having a team of people with the vision to come up with something new (and therefore difficult; you're not just doing a cheap shitty version of something which somebody else already invented), functional (bug free - yes, the code compiles and passes the tests you knocked together but does it actually work in the real world), scalable and competitive with the systems it attempts to disrupt isn't quite the same thing, is it.

On the positive side, I do get a lot of phone calls from Microsoft in India offering to fix my computer problems if only I'd let them use remote desktop to connect to it.

<comment><USER15> That's true. Also the good engineers make it to the US where they make 10x what they would at home. Isn't that what anyone would do??

</comment></comment></comment></comment></comment><comment><USER19> > You are paying your developers how much?

How come nobody asks how much you are paying your executives? Can't we find cheaper executives in other countries?

<comment> iris-digital Yeah, I cringed when I read that. Just what we need another excuse to keep from sharing profits with the builders of your product.

</comment></comment><comment><USER20> The argument about ad spending and dumb money makes sense and I can relate to it. SV startups have the freedom to build products which are inherently unprofitable (unprofitable by design).

There are many incestuous networks of companies and investors within which startups dogfeed on each other's products in an attempt to generate profit for themselves.

Unfortunately, money can't keep moving in a closed loop. Just like the economy of a country; if money exits the network faster than new money enters it, the network's finances will dry and shrivel up.

The incestuous pattern of dogfeeding which is common in tech centers like SV tends to rely on a few 'alpha dogs' to actually extract money from outside the network. These alpha dogs are the tech giants; Google, Microsoft, Oracle, IBM, Facebook... - To avoid a bubble, these tech giants have to be able to make enough OUTSIDE profit to feed not only themselves but all startups and investors which indirectly depend on them for profit.

With this dynamic, you would hope that the alpha dogs of the industry are highly profitable; but it's simply not the case. It's very rare to find a large tech company with a Stock Price/Earnings ratio below 30 - It seems that even the alpha dogs are struggling to feed themselves so it's hard to imagine that they would leave behind enough scraps for the others who depend on them.

Interestingly enough, the giants like Google and Facebook tend to rely heavily on customers from INSIDE their network for profit (I believe a decent share of their revenue would come from advertising other tech companies) - Which means that even the alpha dogs are dogfeeding.

</comment><comment><USER21> "it will function in all Russia, including Crimea,"

Sorry Dmitry, Crimea is not Russia, no matter what this crazy president of ours thinks of it.

<comment><USER22> You realize of course that the Russian naval base in Sevastopol is older than than the United States, right ?

Not to pass judgement on the current Russian claim to Crimea, but it's a very short-sighted view to pretend that Crimea won't ever be Russian.

<comment><USER16> The Russia that exists today is not the same Russia that existed when the naval base was built. It's a different country with the same name.

<comment><USER23> Well, it's a different _government_. I'm not sure it's a different _country_.

</comment></comment></comment></comment><comment><USER24> Many thanks, Dmitry, for brilliant and acute article. Same problems apply for me: Russian developer doing logistics software in Finland.

Here is my simple theory. There are two types of deals: friendly and unfriendly. Friendly deals happen between friends - people help each other, they have trust and comfort in negotiations, they enjoy making a deal and respect mutual interests. Unfriendly deals normally do not happen. They only happen when there are no friendly alternatives around. During unfriendly negotiations, seller is squeezed for all possible discounts, all terms are treated sceptically, fear and negativity are in the air, and with first chance deal will be off. Product has to be inevitably necessary for deal to happen in unfriendly environment.

It is natural that foreign companies and persons are treated friendly less often than local alternatives. But when product is good, and seller is right, then deals happen anyway. And deals help to make friends, and vice versa =)

<comment><USER25> > During unfriendly negotiations, seller is squeezed for all possible > discounts, all terms are treated sceptically, fear and negativity are in the > air, and with first chance deal will be off.

This reminds me of the adage, "A fair deal is when both parties are equally displeased with the outcome."

<comment><USER26> A great deal is when both parties feel like they've ripped the other off.

<comment><USER27> That often means that at least one side greatly underestimated the real value of the deal.

<comment><USER28> Not necessarily. It only implies that the two sides have largely different values. What is worth but perception, yada yada

</comment></comment></comment></comment></comment><comment><USER29> I think OP is living in a bubble. Sure we aren't #1 in Japan, but what is the size of business in Japan compared to the US? And Putin doesn't want to buy our software.. and you call our society fucked? seriously you're run by a dictator. I could go on and on but I think OP is too invested in his own little world and wants the rest of us to know he exists.

<comment><USER30> > Putin doesn't want to buy our software.. and you call our society fucked?

You completely misunderstood OP's argument, IMHO.

A dispute between Obama and Putin over a peninsula where your company has maybe 1.5 users suddenly results in you being locked out of a market with millions of potential users. And the conclusion is that when selling abroad, you need to be aware that vagaries of international politics can drastically affect your business, and that an American software company will be seen - <USER2> policymakers in _both_ countries - as a tool of American foreign policy.

<comment><USER31> > A dispute between Obama and Putin over a peninsula where your company has > maybe 1.5 users suddenly results in you being locked out of a market with > millions of potential users.

Doesn't this cut both ways? If US based companies are locked out of the Russian market, don't Russian based companies run the risk of being locked out of the larger and more influential US market? If forced to choose, I know which of the two I'd pick.

<comment><USER30> > don't Russian based companies run the risk of being locked out of the larger > and more influential US market?

Of course, and in fact it has happened a few times, e.g. see [1]. But Russian based companies tend to be aware of the possibility and plan accordingly. OP's audience is Silicon Valley startups trying to enter foreign markets for the first time, and for them the idea might be rather unfamiliar.

[1] [http://insidehpc.com/2014/01/us-lifts-trade-ban-russian- supe...](http://insidehpc.com/2014/01/us-lifts-trade-ban-russian- supercomputer-vendor-t-platforms/)

<comment><USER31> > OP's audience is Silicon Valley startups trying to enter foreign markets for > the first time, and for them the idea might be rather unfamiliar.

Why do you assume that to be the case? Just because US companies don't need to rely on foreign markets doesn't mean they're somehow unaware of basic geopolitics.

</comment></comment></comment></comment></comment><comment><USER32> "Heck, even Canada now has a law that makes using Dropbox illegal if you are working with personal data (at least until Dropbox starts storing that data in Canada, or that's what I was told). It's called PEPIDA."

It's actually called PIPEDA, not PEPIDA.

Also, where is the source? I have done a good share of readings in this topic as part of my research in a Canadian university (< 4 months ago) and could not find the "illegal"-ness of such actions.

Currently, the act essentially outlines consent and putting the knowledge and power to update/remove private information with the users, and does not outline what services or actions are illegal.

It is important for people care about privacy, but it is not cool to post un- sourced opinions as facts, as people often mis-cite them as fact and propagate false info.

Here is the act, and a summary of responsibilities: [https://www.priv.gc.ca/resource/fs- fi/02_05_d_16_e.asp](https://www.priv.gc.ca/resource/fs-fi/02_05_d_16_e.asp)

</comment><comment><USER33> I am not a fan of this trend where other lowly paid software developers want to bring down the salaries of highly paid software developers.

To be honest, I can't imagine highly skilled software developers on the wages that the OP considers in his article.

Why are some people obsessed with highly skilled people making a lowly income?

</comment><comment><USER34> "only better and free" \- lol. Good luck with that. Amateurish at best.

</comment><comment><USER35> I guess these might be surprising insights to someone but I'm not sure whom.

<comment><USER36> And hot on the heels of an earlier post decrying Medium authors as largely self-serving knowitalls that are eager to tell you how everything you know is wrong. [1]

[1] [https://news.ycombinator.com/item?id=11478159](https://news.ycombinator.com/item?id=11478159)

<comment><USER35> Too bad it's been deleted; that sounds like it would have been more interesting to read than a guy asking me to be shocked that people make less money in Eastern Europe than in the United States.

<comment><USER37> Thank god for archives: [https://archive.is/5WGiY](https://archive.is/5WGiY)</comment></comment></comment></comment>


Facebook hit git performance issue on large repository - <AUTHOR> http://thread.gmane.org/gmane.comp.version-control.git/189776 <comment><USER2> Facebook engineer here, working on this problem with Joshua.

What this comes down to is that git uses a lot of essentially O(n) data structures, and when n gets big, that can be painful.

A few examples:

* There's no secondary index from file or path name to commit hash. This is what slows down operations like "git blame": they have to search every commit to see if it touched a file.

* Since git uses lstat to see if files have been changed, the sheer number of system calls on a large filesystem becomes an issue. If the dentry and inode caches aren't warm, you spend a ton of time waiting on disk I/O.

An inotify daemon could help, but it's not perfect: it needs a long time to warm up in the case of a reboot or crash. Also, inotify is an incredibly tricky interface to use efficiently and reliably. (I wrote the inotify support in Mercurial, FWIW.)

* The index is also a performance problem. On a big repo, it's 100MB+ in size (hence expensive to read), _and_ the whole thing is rewritten from scratch any time it needs to be touched (e.g. a single file's stat entry goes stale).

None of these problems is insurmountable, but neither is any of them amenable to an easy solution. (And no, "split up the tree" is not an easy solution.)

<comment><USER3> _An inotify daemon could help, but it's not perfect: it needs a long time to warm up in the case of a reboot or crash_

So does, presumably, the cache when you use lstat. (Let's scratch presumably. It does. Bonus points if you can't use Linux and use an OS that seems to chill its caches down as soon as possible. )

I hope I'm wrong, but the proper solution to this seems to be a custom file system - not only will it allow you to more easily obtain a "modified since" list of files, it also allows you to only get local files "on demand". (E.g. [http://google-engtools.blogspot.com/2011/06/build-in- cloud-a...](http://google-engtools.blogspot.com/2011/06/build-in-cloud- accessing-source-code.html))

That _still_ doesn't solve the data structure issues in git, but at least it takes some of the insane amount of I/O off the table.

I'm looking forward to see what you guys cook up :)

<comment><USER4> You might be able to do the "custom file system" as a pass-through FUSE filesystem.

<comment><USER5> Yea, a FUSE filesystem is also being considered as one of the possible solutions.

</comment></comment></comment></comment><comment><USER6> Wow. I was expecting an interesting discussion. I was disappointed. Apparently the consensus on hacker news is that there exists a repository size N above which the benefits of splitting the repo _always_ outweigh the negatives. And, if that wasn't absurd enough, we've decided that git can already handle N and the repository in question is clearly above N. And I guess all along we'll ignore the many massive organizations who cannot and will not use git for precisely the same issue.

So instead of (potentially very enlightening conversation) identifying and talking about limitations and possible solutions in git, we've decided that anyone who can't use git because of its perf issues is "doing it wrong".

<comment><USER7> Your comment was at the top so I continued to read expecting to find a bunch of ignorant group think about how git is awesome and Facebook is dumb, but that's not really what's going on down below.

I don't know what facebook's use case is, so I have no idea if their repositories are optimally structured. However, I've used git on a very large repository and ran into some of the same performance issues that they did (30+ seconds to run git status), so I don't think it's terribly hard to imagine they're in a similar situation.

What we did to solve it is exactly what you're excoriating the people below for suggesting: we split the repos and used other tools to manage multiple git repos, 'Repo' in some situations, git submodules in others.

However, we moved to that workflow mainly because it had a number of other advantages, not just because it made day-to-day git operations faster.

I hope git gets faster, some of the performance problems described are things we saw too, but things are always more complicated and I see nothing below that looks like the knee-jerk ignorant consensus you're describing.

Sometimes the answer to "it hurts when I do this" is "don't do that... because there's other ways to solve the same issue that work better for a number of other reasons and we haven't bothered fixing that particular one because most of the time the other way works better anyway."

<comment><USER8> On a simliar note, I've heard there of people who would hit the limit on fortran files, so they put every variable into a function call to the next file, which itself contained one function and a function call to the next file after that (if necessary).

Making stuff modular is often a good idea.

<comment><USER9> Cellular, modular, and interactive-odular!

</comment></comment></comment></comment><comment><USER10> Yes, it's well known that big companies with big continuously integrated codebases don't manage the entire codebase with Git. It's slow, and splitting repositories means you can't have company-wide atomic commits. It's convenient to have a bunch of separate projects that share no state or code, but also wasteful.

So often, the tool used to manage the central repository, which needs to cleanly handle a large codebase, is different from the tool developers use for day-to-day work, which only needs to handle a small subset. At Google, everything is in Perforce, but since I personally need only four or five projects from Perforce for my work, I mirror that to git and interact with git on a day-to-day basis. This model seems to scale fairly well; Google has a big codebase with a lot of reuse, but all my git operations execute instantaneously.

Many projects can "shard" their code across repositories, but this is usually an unhappy compromise.

People always use the Linux kernel as an example of a big project, but even as open source projects go, it's pretty tiny. Compare the entire CPAN to Linux, for example. It's nice that I can update CPAN modules one at a time, but it would be nicer if I could fix a bug in my module and all modules that depend on it in one commit. But I can't, because CPAN is sharded across many different developers and repositories. This makes working on one module fast but working on a subset of modules impossible.

So really, Facebook is not being ridiculous here. Many companies have the same problem and decide not to handle it at all. Facebook realizes they want great developer tools _and_ continuous integration across all their projects. And Git just doesn't work for that.

<comment><USER11> _At Google, everything is in Perforce, but since I personally need only four or five projects from Perforce for my work, I mirror that to git and interact with git on a day-to-day basis._

At MS we also use Perforce (aka Source Depot), and I've toyed with the idea of doing something similar. Have you found any guides for "gotchas" or care to share what you've learned going this route?

<comment><USER10> I used git-p4 at my last job, and the only thing that ever got weird was p4 branches. At Google we have an internal tool that's similar to git-p4, and it always works perfectly for me. Enough developers are using it such that most of the internal tools understand that a working copy could be a git repository instead of a p4 client.

So if you're planning on doing this at your own company, my advice is to write your own scripts that make whatever conventions you have automatic, and to move everyone over at the same time. That way, you won't be the weird one whose stuff is always broken.

I think most people got burned by cvs2svn and git-svn and think that using two version control systems at once is intrinsically broken. It's not. svn was just too weird to translate to or from. (People that skipped svn and went right from cvs to git had almost no problems, I'm told.)

<comment><USER12> Eric Raymond talks about the problems of converting svn repos to git and is promising a new release of reposurgeon soon that handles svn well. <http://esr.ibiblio.org/?p=4071>

</comment></comment></comment></comment><comment><USER13> This looks like it could be of assistance:

<http://source.android.com/source/version-control.html>

      Repo is a repository management tool that we built on top
      of Git. Repo unifies the many Git repositories when
      necessary, does the uploads to our revision control
      system, and automates parts of the Android development
      workflow. Repo is not meant to replace Git, only to make
      it easier to work with Git in the context of Android. The
      repo command is an executable Python script that you can
      put anywhere in your path. In working with the Android
      source files, you will use Repo for across-network
      operations. For example, with a single Repo command you
      can download files from multiple repositories into your
      local working directory.

[http://google-opensource.blogspot.com/2008/11/gerrit-and- rep...](http://google-opensource.blogspot.com/2008/11/gerrit-and-repo-android- source.html)

      With approximately 8.5 million lines of code (not
      including things like the Linux Kernel!), keeping this all
      in one git tree would've been problematic for a few reasons:

      * We want to delineate access control based on location in the tree.
      * We want to be able to make some components replaceable at a later date.
      * We needed trivial overlays for OEMs and other projects who either aren't ready or aren't able to embrace open source.
      * We don't want our most technical people to spend their time as patch monkeys.

      The repo tool uses an XML-based manifest file describing
      where the upstream repositories are, and how to merge them
      into a single working checkout. repo will recurse across
      all the git subtrees and handle uploads, pulls, and other
      needed items. repo has built-in knowledge of topic
      branches and makes working with them an essential part of
      the workflow.

Looks like it's worth taking a serious look at this repo script, as it's been used in production for Android. Might allow splitting into multiple git repositories for performance while still retaining some of the benefits of a single repository.

<comment><USER14> > Looks like it's worth taking a serious look at this repo script, as it's > been used in production for Android. Might allow splitting into multiple git > repositories for performance while still retaining some of the benefits of a > single repository.

Stay away from Repo and Gerrit. I use them at work, and they make my life miserable.

Repo was written years ago when Git did not have submodules, a feature where you can put repositories inside repositories. Git submodules is far superior to Repo, and allows you to e.g. bisect the history of many repositories.

I'm hoping that Google comes to it's senses and starts phasing out Repo in favor of Git submodules in Android development.

<comment><USER15> What about gerrit?

<comment><USER14> Compared to the code review facilities in GitHub, Gerrit is pretty crappy. Gets the job done, but the UI and the work flow it forces is a bit annoying.

The worst part in repo + gerrit is that their default work flow is based on cherry-picking and they introduce a new concept called Change-Id. The Change- Id basically yet another unique identifier for changes that is stored in the commit message. The intent is that you make a change (a single commit patch), a post-commit hook adds the Change-Id to the commit message and then you upload it for review. When you make additions to your change, the previous change gets overwritten. Gerrit tries to maintain some kind of branching (called dependencies), but they mess things up when there's more than one person working on a few changes at the same time.

In comparison with GitHub-style work flow where you make a branch with multiple commits, submit a pull request, get review, add commits, squash and merge, the repo + gerrit model is awfully constraining.

We might be using an old version of repo and/or gerrit and some of the issues I've encountered may be improved. However, I think that repo+gerrit is a mess beyond repair and trying to "fix" it only makes things worse.

Unless you work on Android and are forced to use repo+gerrit because Google does so, stay out of it.

<comment><USER16> I'm using it, the workflow isn't so bad. In fact it is similar to the way kernel patches are iterated and reviewed, except centralised instead of e-mail based.

</comment></comment></comment></comment></comment><comment><USER17> Huh, fascinating. git was initially created for the Linux kernel development, and I haven't heard of any issues there. Offhand I would have said, as a codebase, the Linux kernel would be larger and more complex than facebook, but I don't have a great sense of everything involved in both cases.

So what's the story here: kernel developers put up with longer git times, the kernel is better organized, the scope of facebook is more massive even than the linux kernel, or there's some inherent design in git that works better for kernel work than web work?

<comment><USER18> It isn't surprising if Facebook has a large, highly coupled code base. Given their reputation for tight timelines and maverick-advocacy, I'm continually surprised the thing works at all.

<comment><USER19> I wouldn't say that a large repository implies that the code is highly- coupled. There are advantages for keeping certain code together in a single repo. Being able to easily discover users of functions of a library, being able to "transactionally" commit an update to a library (or set of libraries) and the code that uses it, being able to do code review over changes of code in various places, being able to discover if someone else has solved this problem before, and so forth. If you only have your project and its libraries checked out, you don't serendipitously discover things in other projects.

As mentioned in this talk on how Facebook worked on visualizing interdependence between modules to drive down coupling at <https://www.facebook.com/note.php?note_id=10150187460703920> , there are at least 10k modules with clear dependency information in a front-end repo, and the situation probably is a lot better now that they have that information- dense representation to work from (I don't work on the PHP/www side of things, I spend most of my time in back-end and operations repos).

<comment><USER20> None of what you mention here precludes breaking up the code into many smaller repositories, and then having them all linked together in one super- repository.

Then tags at the super-repository level can record the exact state of all submodules.

It's not about not checking the other modules out; you can make this the standard behavior, sure. Instead it's about having git manage reasonable sized blocks of the code base.

<comment><USER21> Three big problems with a split up codebase:

1) Instead of doing one large release every week (which facebook does: <http://www.facebook.com/video/video.php?v=10100259101684977>) you now have dozens or hundreds of smaller releases, a lot more heterogeneity to test for.

2) If you have inter-dependencies on modules you have to grapple with the "diamond dependency" problem. Say module A depends on module B and C, and suppose that module B also depends on C. However, module B depends on C v2.0 but A depends on C v1.0. If they're all split across repositories it's not possible to update a core API in an atomic commit.

3) Now you rely on changes being merged "up" to the root and then you have to merge it "down" to your project. This is one of the reasons Vista was such a slow motion train wreck: [http://moishelettvin.blogspot.com/2006/11/windows- shutdown-c...](http://moishelettvin.blogspot.com/2006/11/windows-shutdown- crapfest.html) \-- kernel changes had to be merged up to the root, then down to the UI, requiring months of very slow iterations to get it right.

<comment><USER19> Keep in mind that the talk in question is talking about the web site (and some other stuff) going into production, and as is mentioned in the talk, it is done more than once a week, and the whole shebang can be pushed in some number of minutes (I forget the amount mentioned).

Back-end services have their own release schedules and times, and obviously are made to be highly backward compatible so that they don't need to be done in lock-step with the front-end.

I think you're right about the "diamond dependency" model, but I think the merge-up and merge-down in Vista had more to do with having multiple independent branches in flight at the same time.

</comment></comment></comment></comment></comment></comment><comment><USER22> While I'd be interested in seeing this issue further unfold, just the prospect of a 1.3M-file repo gives me the creeps.

I'm not sure what the exact situation at Facebook is with this repository, but I'm positive that if they had to start with a clean slate, this repo would easily find itself broken up into at least a dozen different repos.

Not to mention the fact that if _git_ has issues dealing with 1.3M files, I wonder what other (D)VCS they're thinking of as an alternative that would be more performant.

<comment><USER23> A lot of big companies have repos 10 or 100 times that size. With tens of millions of files, sometimes up to 100 gigs or more of data under source control.

<comment> brown9-2 True, but don't most places organize one git repo per project, rather than one for the entirety of the company's source code?

<comment><USER24> Most people like that use Perforce (e.g., Google).

And no, they don't split into multiple repos, they might well have the entire company's source code in a _single_ repository (code sharing is way easier this way).

<comment><USER25> That's a pretty terrible way to share code. Simple example: I work on a project, write some code. Turns out that code is useful for someone else, so they reach in and include it, which is easy since it's all the same repo and all delivered to the build system. Now I make a change and break some customer I didn't even know exists. Oops.

This is what package systems are for.

</comment></comment></comment></comment></comment><comment><USER26> [http://thread.gmane.org/gmane.comp.version- control.git/18977...](http://thread.gmane.org/gmane.comp.version- control.git/189776)

They keep every project in a single repo, mystery solved.

Edit:

> We already have some of the easily separable projects in separate > repositories, like HPHP.

Yeah, because it makes no sense, it's C++. They probably use for everything PHP i assume then. Is there no good build management tool for it?

<comment><USER27> > They keep every project in a single repo, mystery solved.

This kind of "Duh, look what you're doing" response isn't really justified.

Sure, splitting up your repository would make things faster, but having to maintain multiple repositories is a major headache for the end-users of git. If it's possible, why not fix its scalability so that you don't have to worry about it?

<comment><USER28> I'm pretty sure that cloning a repository of that size can't be all that fun.

You tend to split repositories based on team responsibilities. I doubt that every developer needs access to update all million+ files.

What this comes down to is that they've made certain architecture decisions that ideally would be changed but it's not possible to do so at this time.

</comment></comment></comment><comment><USER29> Somewhat off-topic, could somebody explain why

      echo 3 | tee /proc/sys/vm/drop_caches

rather than just

      echo 3 > /proc/sys/vm/drop_caches

Is it because the output to stdout lets you be extra sure that the right data was sent to the kernel?

I'm just wondering if this is an idiom with a deeper meaning that I'm not aware of.

EDIT: I'm guessing that when you run it in a script (without set -x), rather than on the command line, you can see in the log what it is you sent?

<comment><USER30> Because you can

        echo 3 | sudo tee /proc/sys/vm/drop_caches

but

        sudo echo 3 > /proc/sys/vm/drop_caches

won't work.

<comment><USER29> Right, that's what I was missing. That makes sense, and come to think about it, is a very useful addition to my toolbox. Thanks pdw and jochu!

</comment></comment></comment><comment><USER31> Others have tried and keep throwing more and more smart people at the problem they just shouldn't have.

MSFT with Windows codebase that runs out of several labs. Crazy branching and merging infrastructure. They use source-depot, originally a clone of perforce.

Google with all their source code in one Perforce repo.

Facebook will be on perforce before we know it.

The solution is an internal Github, not one giant project.

<comment><USER26> Google has everything in one Perforce repo? You mean the search engine, do you?

I agree btw, the Github mindset is the best one. Create for every project a new repo and connect them with build tools. But why not hire 100 SOA- Consultants, they have enough money now.

<comment><USER32> No, literally the entire codebase for all of their products is in one Perforce repo. Ashish Kumar, manager of the Engineering Tools team, mentions it in this presentation: <http://www.infoq.com/presentations/Development-at-Google>

<comment><USER33> The kernel? Android? Some other spooky stuff involving the pest control guy who's holding a big rubber mallet when you fail a unit test?

Are you sure about that?

<comment><USER34> Kernel/Android/Chrome/basically anything open-source is different. If the code is going to be open-sourced, it can't have dependencies on proprietary code anyway.

<comment><USER33> Right, so "literally the entire codebase for all their products" is incorrect. Thanks.

<comment><USER10> The open-source stuff is a rounding error. Think about all the Google products; Search, Google+, Gmail, Groups, Translate, Maps, Docs, Calendar, Checkout, Wallet, Voice, ... those are all in one repository. (Not to mention all the libraries and internal tools; those are all in there too.)

<comment><USER34> To be fair, Android and Chrome are pretty huge projects. I know the numbers (though I don't think I can share them outside of Google), and while they're nowhere close to being a big part of the total, they're also big enough to not be considered a rounding error.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> Large repos bring their own problems, and results in some design decisions accordingly. For example, Visual Studio itself is 5M+ files and this affected some of the the initial design decisions (Server side workspaces, for this example) when developing TFS 2005 (the first version) [1]. That decision suits MS but not the small to medium clients well. So they're now alternating that design with client side workspaces.

It's not wise to offer Facebook to split the repository. Looks like it's time to improve the tool.

[1] [http://blogs.msdn.com/b/bharry/archive/2011/08/02/version- co...](http://blogs.msdn.com/b/bharry/archive/2011/08/02/version-control- model-enhancements-in-tfs-11.aspx)

</comment><comment><USER36> I can believe this working with a former facebook employee. They do not believe in separating or distilling anything into separate repos. Why the fuck would you want to have a 15GB repo?

Ideally they should have many small, manageable repositories that are well tested and owned by a specific group/person/whatever. At least something small enough a single dev or team can get their head around.

Sheesh.

<comment><USER37> And then each of those dev teams can spend 1/2 their time writing code other people in the company have already written _or_ every team can spend 1/2 their time publishing and reading documentation about what has been written.

There is no simple answer. There is only optimization for a particular problem-set you are trying to minimize.

<comment> brown9-2 > And then each of those dev teams can spend 1/2 their time writing code other > people in the company have already written or every team can spend 1/2 their > time publishing and reading documentation about what has been written.

I don't see what this has to do with a discussion of one repo vs multiple repos.

You think that in a multi repo world, the engineers aren't as aware of what code exists and where as they are in a single repo world? You think that code duplication and needing to read docs magically doesn't exist in a single repo world?

The number of repositories is just an organizational construct. Communication still must take place no matter what.

</comment></comment></comment><comment><USER38> the obvious answer, repeatedly mentioned in comments:

> factor into modules, one project per repo

where i work we have a project with clear module boundaries, but all in the same repo. we have an "app" and some dependencies including our platform/web framework. none of these are stable, they're all growing together. Commits on the app require changes in the platform, and in code review it is helpful to see things all together. Porting commits across different branches requires porting both the application change and the dependent platform changes. Often a client-specific branch will require severe one-off changes so the platform may diverge -- it is not practical for us (right now) to continually rebase client branches onto the latest platform.

this is just our experience, not facebook's, but lets face it: real life software isn't black and white, and discussion that doesn't acknowledge this isn't particularly helpful.

<comment><USER39> We've experienced this.

We've got a superproject with our server configs, and sub projects for our background processing, API, and web-frontend respectively.

Often, each project can evolve and be versioned 100% independently. However, often you need to modify multiple projects and (especially with server config changes) coordinate changes via the super project.

It's a little hairy sometimes and often feels like unnecessary overhead, but the mental boundary is extremely valuable on it's own. Being able to add a field to the API and check that commit into the superproject for deployment before the front end features are done is nice. The social impact on implementation modularity is valuable. We write better factored code by letting Git establish a more concrete boundary for us.

</comment></comment><comment><USER40> I hope these guys do take the route of developing a large-scale performant patch.

Git as so many interesting uses at scale as just a tool that navigates and tracks DAGs over time.

</comment><comment><USER41> This was actually pretty fascinating to me. On one hand, I am astonished at how long it takes to perform seemingly trivial git operations on repositories at this scale. On the other hand, I'm utterly mystified that a company like Facebook has such monolithic repositories. Even back when I was using SVN a lot, I relied on externals and such to break up large projects into their smaller service-level components.

I'd be very interested to see some benchmarks on their current VCS solution for repositories of this scale.

<comment><USER42> Given that Facebook is compiled into a single 1 GB executable, a git repo with 1.3 M files doesn't really surprise me.

<comment><USER43> What? Do you have a reference for that?

<comment><USER44> Here you go: <http://www.facebook.com/note.php?note_id=10150121348198920>

"We can build a binary that is more than 1GB (after stripping debug information) in about 15 min, with the help of distcc. Although faster compilation does not directly contribute to run-time efficiency, it helps make the deployment process better."

</comment></comment></comment></comment><comment><USER45> $100B company, maybe they can afford to put some people onto solving this for the open software community (and put the solution into the open), especially since nobody else in the community seems to have this problem.

<comment><USER46> If you proposed a good solution I'm sure they'd be happy to provide time and money and open source the result. But most of the responses aren't even that there is a solution - they say to split the repository into smaller pieces and spend time and money internally having their internal developers deal with that.

A good solution will benefit everyone who uses git. Codebases get larger over time. There is more forking and experimentation. More spoken languages can be supported. More computer languages can be interfaced. The O(n) operations becoming less than that will benefit you in the future as your code grows.

<comment><USER45> > _If you proposed a good solution I'm sure they'd be happy to provide time > and money and open source the result._

If they provided money, I'd provide the time in order to produce a good result. See the problem?

More to the point: FB is all take and no give, as near as I can tell.

<comment><USER47> <https://developers.facebook.com/opensource/>

Looks like a fairly long list to me.

</comment></comment></comment></comment><comment><USER48> This is Joshua (who posted the original email). I'm glad to see so much interest in source control scalability. If there are others who have ever contemplated investing a bit of time to improving git, it'd be great to coordinate and see what makes sense to do - even if it turns out that the right answer is just to make the tools that manage multiple repos so good that it feels as easy as a single repo.

</comment><comment><USER28> There's two issues: the width of the repository (number of files) and the depth (the number of commits).

Since "status" and "commit" perform fairly well after the OS file cache has been warmed up, that probably can be resolved by having background processes that keep it warm. (Also, how long would it take to just simply stat that number of files? )

The issue of "blame" still taking over 10 minutes: We need to know far back in the repository they're searching. What happen if there's one line that hasn't been changed since the initial commit? Are you being forced to go back to through the whole commit history?

How old is the repository? Years? Months? I'm probably guessing in the at least years range based on the number of commits (unless the developers are extremely commit-happy).

At a certain point, you're going to be better off taking the tip revisions off a branch and starting a fresh repository. It doesn't matter what SCM/VCS tool you're using (I've been the architect and admin on the implementation of a number of commercial tools). Keep the old repository live for a while and then archive it.

You'll find that while everyone wants to say that they absolutely need the full revision history of every project, you rarely go back very far (aka the last major release or two). And if you do need that history, you can pull it from the archives.

</comment><comment><USER49> Git was designed for the Linux kernel, and it's simply not big: a couple thousand files, broken up into directories of dozens or hundreds of files.

<http://www.schoenitzer.de/lks/lks_en.html#new_files>

</comment><comment><USER50> This is an interesting social AND a technical problem. The problem for FB is that it is all too easy for them to just fork git, create the necessary interfaces and then hope the git maintainers would accept it (they mightn't) or release it into the wild (and incur bad karma and wrath of OS developers who'd see this has schism or even heresy).

They've reached out to the developers on git, and I guess that's a first step.

</comment><comment><USER51> I don't want to imagine the _actual_ kind of code that requires 1.3M files to run.

<comment><USER19> Keep in mind that your average repository doesn't only contain code that is compiled and executed (or interpreted), there is also documentation, static assets such as images (that may be processed), configuration, computed files (that may make sense to pre-compute once rather than compute on a hundred people's environments every build), and so forth.

Also, it doesn't only include the current file set - they include files that have been deleted, been split into modular files, been merged, been wholesale rewritten, put into a new hierarchy (some VCS systems handle this better than others).

(I work at Facebook, but not on the team looking into this stuff. I'm a happy user of their systems though. Keep in mind that the 1.3 million file repo is a synthetic test, not reality.)

<comment><USER52> _Also, it doesn't only include the current file set - they include files that have been deleted, been split into modular files, been merged, been wholesale rewritten, put into a new hierarchy (some VCS systems handle this better than others)._

The follow-up email still mentions a working directory of 9.5gb. I cannot fathom working on a code repository consisting of 9.5gb of text. There must be something else going on here, even considering any peripheral projects like the iOS and android apps, etc.

(edit: if there are huge generated files intermingled with code, shouldn't those be hosted on a "pre-generated cache" web server instead of git, for example?)

<comment><USER53> Our codebase at my employer currently hovers around 5GB in SVN. Binaries and other generated code are intermixed for historical reasons. Removing them is a non-starter due to the amount of time it'd take to do so; the best solution I've been able to come up with so far is to break out into multiple SVN repos (one for images, one for generated language files, etc.) and then, hopefully, get code into Github while externally using the SVN repos for stuff that shouldn't be versioned in a distributed manner (versioning that stuff is useful as a convenience - avoiding conflicts, etc.).

</comment></comment></comment></comment><comment><USER54> I'm surprised Facebook and all its peripheral development has that much source. I would expect something like 5-10 million lines of code, not ~100 million lines implied by the example.

<comment><USER19> The example is synthetic, so don't worry too much about the implications.

It is useful to keep in mind that Facebook isn't just the front-end (and isn't just code, also images, configuration, and so forth).

Just talking about open source stuff, Facebook also generates code like Cassandra, Hive (data warehousing application), Phabricator (a code review and lifecycle tool), HipHop for PHP (the translator/compiler, the interpreter, and the virtual machine), FlashCache (a kernel driver), Thrift, Scribe, and so forth.

We also have had to build applications to support our operations, so think about what sort of effort goes into building scalable monitoring, configuration management, automatic remediation, logging infrastructure, and so forth.

I don't know the actual lines of code across it all, and wouldn't mention it if I did, but people often underestimate the scale here.

<comment><USER55> And all of that must live in a single repository... because?

<comment><USER19> It doesn't live in a single repository. The commenter I was replying to mentioned "Facebook and all its peripheral development" and a number of lines of code. I wanted to give him a little insight into what sort of things all the peripheral development might include, since it isn't obvious.

</comment></comment></comment></comment><comment><USER56> I don't think Git was designed to perform well with such a large repo. In this case, the best-practice is probably compartmentalizing the code and using Git submodules. The Git submodule interface is a little un-friendly, but I think it does work well for such large repos. I've been using submodules successfully for our development that tracks source files as well as binary assets.

</comment><comment><USER57> I think it's a bad practice to keep a giant code base in one repo. Split the code base into purpose-specific modules, just as you would split any project into purpose-specific modules. In fact, those two things might well line up 1:1.

If a project depends on other projects, have it reference the other projects. Where appropriate, include exact version numbers and/or commit hashes. Gemfiles are good examples of this good practice at work.

Yes, git has submodules for this sort of thing, but after investigating that route, I decided against using git submodules. Use something independent of the VCS instead. Then git won't do weird or unexpected things when you switch branches. Also, you might want to mix in projects that use other version control systems. And really, why unnecessarily couple a project to its version control system?

If (when?), even after splitting a megaproject into manageable subprojects, these performance issues creep in, I'd certainly be interested in whatever improvements people are coming up with...

</comment><comment><USER58> I'm curious what their performance numbers look like if they host the .git repo on tmpfs -- 15GB isn't unreasonable on a beefy (24-32GB of ram) machine.

<comment><USER42> Probably the same as the warm cache results, since that's basically what tmpfs is. I wonder if git does all that stat()ing serially or in parallel, though...

<comment><USER59> I don't have the link handy, but IIRC we did some experiments with that for Mercurial and found that stat() in parallel didn't really help much until you were using NFS or similarly slow network-type latency filesystems.

</comment></comment></comment><comment><USER60> Hey do you know a lot of sites with such needs? Facebook is the first, and probably all sites with such needs I can count with fingers on my one hand. I don't think it's git issue - everyone use this system and all are happy using it. This is like a new feature, but not issue.

</comment><comment> alok-g Is anything known for scalability to such sizes for Subversion, Mercurial, Bazaar, and others?

</comment><comment><USER61> If this was the crazy size of your git repo, why wouldn't you make a tool that took your git repo and versioned it? Keep it in repos that can all be performant, since most of the time you are working with "time local" information?

</comment><comment><USER62> My first thought, as suggested by some on the list, was modularization. Redstone's response (that the 1.3 million files are essentially all interdependent) terrifies me.

</comment><comment><USER63> These times are for spinning-platter hard drives. I wonder what the numbers look like on a modern SSD?

</comment><comment><USER64> That's projected growth for two of their projects. Sounds like they have something brewing...

Still amazed that breaking it up would do more harm than good when the code isn't even written yet...

<comment><USER65> I read it as them being unable to break up a project, and the repo being a projection of future commits to a project that can't be split up.

</comment></comment><comment><USER66> Multiple people in this conversation section have asserted that code sharing is _way_ easier when all the code is in a single _repo_ , but from my understanding of sub-modules, it would be a fairly simple matter of setting up your pre/post-commit hooks to update submodules to a branch automatically and get useful company wide change atomicity (after all, changes should only propagate between teams/projects once they have some stability).

Putting aside the question of whether or not an enormous singular repo can be broken up intelligently into modular projects, is there something about the submodule approach that makes it a uniquely unsuitable way for sharing changes amongst projects?

<comment><USER3> If you limit change propagation, your changes won't propagate as fast. That goes for bugs _and_ bug fixes.

I can certainly see why you would have the latter propagated instantaneously, or close to it.

There's also the point that if you _don't_ propagate change to everybody at the same time, you'll have dozens of slightly different versions of those projects across your company. The question of submodules vs. large repo is not as easily decided as you think - there are large upsides (and downsides) to both approaches.

<comment><USER66> No, you're misunderstanding what I'm saying with regards to publishing stable changes.

Say you have two branches: master and next. Stable work goes in master, unstable work goes in next. When the code is ready for consumption, you merge it into master.

Anyone who is using a project has it setup as a submodule. They add post/pre- commit hooks to update all project submodules. These submodules pull from master.

This way, everyone will get all stable changes on all submodule projects at the time of the next change to their own project.

<comment><USER3> I do understand what you mean just fine. Except it doesn't work that way. If I have a critical bug fix in libA, I need it rolled out _now_. What's more, I need it rolled out across all other projects that use libA, immediately. And no, I don't want to work until all projects committed a change of their own.

Even more, I (or my team) are not the only ones working on libA. Others are too. So keeping changes in 'next' and pushing to master only on occasion doesn't help much. Yes, it keeps non-working patches out - but that's what _local_ branches on your machine are for.

(I'm not even going to mention the issue of merge conflicts. If you work on a massive scale, the longer you stay in a branch, the more likely you are to get a merge conflict. There's easily the chance to go into a several weeks long merge hell. Pull from master, resolve conflicts, run local tests - oh wait, master is already updated by somebody else)

</comment></comment></comment></comment><comment><USER67> git is not memory efficient by design, i used to push about 1G commit to the server and it hangs forever, i had to abort it and push in as small chunks instead

</comment><comment><USER68> Does Facebook really believe that because they have the most users, they should also have the biggest git repo?

Amazon and Google have already solved this problem, and the solution is to reorganize things into smaller manageable packages.

<comment><USER68> What I mean is, even if they manage to solve this problem with some tweaks, they will again hit the bottleneck in an year or two, so they should rethink their source code management</comment></comment>


Facebook launches home video chat–and promises it won't spy on you - <AUTHOR> https://www.marketwatch.com/story/facebook-launches-home-video-chatand-promises-it-wont-spy-on-you-2018-10-08 <comment><USER2> Using a centralized service for communications means spying will eventually happen. It doesn't matter if it's Facebook or some brand new company. The incentives are there.</comment>


Ask HN:What tool for Windows desktop development? - <AUTHOR>

I want to make a small Windows desktop tool that needs to access the local filesystem (so a webapp won't work).
I used to use MS VC++ at the daytime job between 1997 and 2004-ish and also used Delphi (up until Delphi 3) for after-hours projects in the late 90's. I played around with Adobe AIR.
At the moment I'm considering Delphi XE2 Starter, VC++ 2010 Express and Adobe AIR. Delphi used to have a vibrant community, but it seems to have disappeared.
Pricing is also a concern: the cheaper the better, because I'll have to pay for it myself and might only use it for this small project.
Any suggestions? Or any free alternatives?
Thanks in advance! <comment><USER2> Visual Studio C# Express is free, and is probably more than you need for a one-man-band small-ish project.

<comment><USER3> And just to be clear, all the Visual Studio Express components (C++,VB,SQLServer etc.) are free, not just C#. I use Visual Studio C++ Express at work and it's great.

There is also Qt and Qt Creator (both free) if you want to stick to C++, but don't want to tie yourself to Microsoft. And if you don't want to use C++, there's always python bindings for Qt. And if you don't want to use Qt, there's always wxWidgets....</comment></comment>


Does location really matter for your startup? - <AUTHOR> http://joel.is/post/8013047305/does-location-really-matter-for-your-startup <comment><USER2> Do you mean location for ease of getting funded or solving user problems?

At the end of the day all that matters is giving the users of your website/app what they want that helps them solve their problems. The last I've heard users really don't care where your located.</comment>


Beautiful Terminal Diffs, Everywhere - <AUTHOR> http://blog.robertelder.org/terminal-diff-tool/ <comment><USER2> If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

</comment><comment><USER3> Looks good. I'll have to try it out. That you struggled with some of the stranger Unicode glyphs shows this probably has more thought put into it than diff tools that are much older...</comment>


Why Do People Call Ms. Maya Angelou "Dr. Maya Angelou"? - <AUTHOR> http://www.newrepublic.com/article/117947/maya-angelou-was-ms-not-dr-against-title-inflation-america

<comment> anti-racism-dog bark, bark!</comment>


Get your Heartbleed t-shirt and donate to OpenSSL - <AUTHOR> http://teespring.com/hbts

<comment><USER2> I saw a similar tee elsewhere, but I like that in this case the proceeds go to OpenSSL.

Also, the fact that a t-shirt can be made out of this supports Patrick McKenzie's article [1] yesterday, commenting on how this bug (or rather, its announcement) has been a case of successful marketing.

[1] [http://www.kalzumeus.com/2014/04/09/what-heartbleed-can- teac...](http://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the- oss-community-about-marketing/)

</comment><comment><AUTHOR> OP here. Mandatory disclaimer: we're not affiliated with the OpenSSL Software Foundation but we thought it was a good idea to launch a commemorative Heartbleed t-shirt and donate all proceeds to the foundation.

The Teespring base cost for the t-shirt is around $11, the remaining $4 will be donated to the OpenSSL Software foundation once the campaign ends.</comment>


Linux Online Backups | Don't Hurt Your Head - <AUTHOR> http://crackednoodle.com/2011/09/linux-online-backups/ <comment><USER2> I wish the relevant services would use a term rather than "online". Online and offline have specific meaning regarding backups - you can have online backups locally.

I'm not sure what other word would work though... Internet-based is too long. Remote might not be understood by Joe Sixpack.

Heck, I'd even let them get away with using "cloud" here (normally mention of "the cloud" makes the hand-of-doom twitchy).</comment>


Introducing search-string: an advanced search string parser - <AUTHOR> https://mixmax.com/blog/search-string-advanced-search-parser <comment><AUTHOR> This minimal (no-dependency) npm package is used throughout Mixmax in browser and server-side code. Check it out, welcome any comments! [https://github.com/mixmaxhq/search- string](https://github.com/mixmaxhq/search-string)</comment>


Unlocking Xiaomi MI5 bootloader takes 72 hours - <AUTHOR> https://forum.xda-developers.com/mi-5/how-to/unlocking-xiaomi-mi-5-bootloader-t3336243/page22 <comment><AUTHOR> Xiaomi requires registration with SIM card and binds account phone to specific user.

Request is placed on Xiaomi web site where the user needs to explain why he wants to unlock the phone. Upon receiving permit from Xiaomi, one can download a specific application for Windows that won't work until 72 hours passes from the initial request.

I'm blown away here.</comment>


The Earth-Twin Planet That Nobody Talks About - <AUTHOR> http://blogs.discovermagazine.com/outthere/2015/09/30/twinplanet/#.ViAmMPmqpBc <comment><USER2> NASA's latest vision for a Venus visit involves giant dirigibles – and perhaps someday a 'cloud city' like that of Bespin in Star Wars:

[http://www.space.com/29140-venus-airship-cloud-cities- incred...](http://www.space.com/29140-venus-airship-cloud-cities-incredible- technology.html)

<comment><USER3> Or if that depicted in Asimov's "The Sultan of the Clouds". Venus' atmosphere at a specific altitude is actually very similar in composition to that of Earth's at sea level (21% oxygen, 78% nitrogen).

</comment></comment><comment><USER4> What is the deal with Venus's atmosphere? How can it be so much higher pressure than Earth's when the gravity at the surface is 0.9 g? Is it just that CO2 is heavier than N2 (44 vs 28 g/mol?)? If we could magically convert the CO2 to O2, would the pressure be lower? Where is all Venus's nitrogen?

Where does all this sulphuric acid come from? Does Earth have the same amount of sulphur, just locked up in rocks? If so, why doesn't it react and precipitate out on Venus?

Okay, time to read the Wikipedia article [1].

So, Venus's atmosphere actually has _four times as much_ nitrogen as Earth's. But that's overwhelmed by having about a hojillion times more carbon dioxide. There's more than enough nitrogen for an Earth-like atmosphere, crushed down into a tiny space.

Plus, the lack of a magnetic field means the solar wind hits the atmosphere harder than it does at Earth; hard enough to blow water vapour off the planet, although i don't know if that's in significant quantities.

Apparently at the surface, the CO2 has enough density and pressure that it's supercritical. So it's not so much an atmosphere, as an ocean. Kind of. We don't have a word for what it is, but it's atrocious.

As for sulphur, it came from wherever (volcanic eruptions, let's say), but the reason it stays in the atmosphere is that sulphuric acid never reaches the ground: if it falls as rain, the heat of the deep atmosphere evaporates it before it lands. I assume there's still a lot of gas-phase sulphuric acid at the surface, but perhaps that doesn't allow a fast enough reaction to take it out of the atmosphere.

And finally, Earth had an atmosphere like Venus's during the Hadean era, from its formation to four billion years ago [2]. Despite being ludicrously hot, liquid water oceans were stable due to the high pressure. Those oceans apparently allow some chemistry that takes most of the CO2 out of the atmosphere. For some reason, that didn't happen (or stopped happening) on Venus. Maybe because the water was whipped away by the solar wind? Or because Venus was just a bit too hot for liquid water? Or because you need not only oceans but plate tectonics to bury the carbon deep in the crust, and Venus doesn't have plate tectonics?

Don't ask me why Venus doesn't have plate tectonics. Probably the same reason it doesn't have a magnetic field, which on Earth is generated by stuff convecting around in the core.

So, total basket case really.

[1] [https://en.wikipedia.org/wiki/Atmosphere_of_Venus](https://en.wikipedia.org/wiki/Atmosphere_of_Venus)

[2] [https://en.wikipedia.org/wiki/Hadean](https://en.wikipedia.org/wiki/Hadean)

<comment><USER5> Could it be that rather than being stuck "four billion years ago", Venus is actually ahead of Earth in its timeline? Perhaps what we are seeing on Venus is the eventual result of climate change on Venus, not unlike what we are experiencing now?

<comment><USER6> This could make for an incredible movie plot. Humans spend all this time studying climate change and debating about it, only to find out that we were staring the result of it right in the face the whole time: Venus. We discover that the origin of man is not Earth. Rather, we were colonized here by our great ancestors, forgotten in time. Ancestors that came from Venus. They left after destroying the planet. And now, here we are on Earth, repeating history.

<comment><USER7> That's actually one of the real reasons we study Venus - because it's an existing case of runaway global warming, and we want to learn something about our future from it.

</comment></comment></comment></comment><comment><USER8> Lack of effort to explore space always makes me sad - especially that last picture of Venus surface comes from 1982.

<comment><USER9> Yeah. I've been watching a lot of Apollo footage recently. Our concerns seem so mundane, by comparison.

That said, I think the next 50 years will be a new golden age for space exploration...

<comment><USER8> I've been watching Apollo footage recently too ;)

I am not sure about next 50 years, so far It looks like people would spend more on some selfie sticks than space exploration.

<comment><USER10> Mercury, Gemini and Apollo were standins for open war with the Soviet Union, so they got more war-like funding and focus. 'Terrorists' aren't going to be shown up by space travel and no one believes we're really at war with the Chinese so no one is willing to throw money at it.

The US has never really funded anything that isn't related directly or indirectly to war, that includes Space Exploration.

</comment></comment></comment></comment><comment><USER11> I wonder wether earth first looked similar to venus today and was made habitable by (what we today consider) extremophiles. If most of venus' atmosphere was captured in solids or fluids it would look way more habitable.

<comment><USER4> Close! Earth's atmosphere was much the same as Venus's up to four billion years ago. But it seems that what made the difference was the carbonate cycle:

[https://en.wikipedia.org/wiki/Carbonate%E2%80%93silicate_cyc...](https://en.wikipedia.org/wiki/Carbonate%E2%80%93silicate_cycle)

That article blames the difference on the temperature. Elsewhere, i've seen the presence of water oceans being implicated. Either way, i don't think life was the mechanism at that point. Life didn't really have much of an impact for another billion years or two:

[https://en.wikipedia.org/wiki/Great_Oxygenation_Event](https://en.wikipedia.org/wiki/Great_Oxygenation_Event)

<comment><USER12> Partially in response to your other post as well, I've also seen it hypothesized that the collision that produced Earth's moon stripped away most of Earth's atmosphere, the idea being that Venus' atmosphere may actually be the "normal" atmosphere for an Earth-sized planet.

As usual, the core problem is just that our data set is too darned small. Is our Solar System mostly normal? Is our Solar System a bizarre, billions-to-one odds freak case? We don't really _know_.

</comment></comment></comment><comment><USER13> Total Clickbait title (could be rephrased as):

Near Clone of Planet Earth Responds to Charges of Plagiarism in Best Way Possible.

<comment><USER14> seeing that it's discovermagazine.com, i thought that the clickbait statement went without saying.

<comment><USER15> I wouldn't oppose HN editorializing click-baity titles.</comment></comment></comment>


A Powerful Russian Weapon: The Spread of False Stories - <AUTHOR> http://www.nytimes.com/2016/08/29/world/europe/russia-sweden-disinformation.html <comment><USER2> The gist of it below. I know that's a lot of excerpts, but it's too important to overlook.

\</comment><comment></comment><comment>----

 _Now, though, disinformation is regarded as an important aspect of Russian military doctrine, and it is being directed at political debates in target countries with far greater sophistication and volume than in the past._

...

 _The fundamental purpose of dezinformatsiya, or Russian disinformation, experts said, is to undermine the official version of events — even the very idea that there is a true version of events — and foster a kind of policy paralysis._

...

 _Russia exploits both approaches in a comprehensive assault, Wilhelm Urme, a spokesman for the Swedish Security Service, said this year when presenting the agency's annual report. "We mean everything from internet trolls to propaganda and misinformation spread by media companies like RT and Sputnik," he said._

...

 _Tracing individual strands of disinformation is difficult, but in Sweden and elsewhere, experts have detected a characteristic pattern that they tie to Kremlin-generated disinformation campaigns. Continue reading the main story

"The dynamic is always the same: It originates somewhere in Russia, on Russia state media sites, or different websites or somewhere in that kind of context," said Anders Lindberg, a Swedish journalist and lawyer.

"Then the fake document becomes the source of a news story distributed on far- left or far-right-wing websites," he said. "Those who rely on those sites for news link to the story, and it spreads. Nobody can say where they come from, but they end up as key issues in a security policy decision."

Although the topics may vary, the goal is the same, Mr. Lindberg and others suggested. "What the Russians are doing is building narratives; they are not building facts," he said. "The underlying narrative is, 'Don't trust anyone.'"_

...

 _Last year, the European Parliament accused Russia of "financing radical and extremist parties" in its member states, and in 2014 the Kremlin extended an $11.7 million loan to the National Front, the extreme-right party in France.

"The Russians are very good at courting everyone who has a grudge with liberal democracy, and that goes from extreme right to extreme left," said Patrik Oksanen, an editorial writer for the Swedish newspaper group MittMedia. The central idea, he said, is that "liberal democracy is corrupt, inefficient, chaotic and, ultimately, not democratic."

Another message, largely unstated, is that European governments lack the competence to deal with the crises they face_

...

 _Moscow's targeting of the West with disinformation dates to a Cold War program the Soviets called "active measures." The effort involved leaking or even writing stories for sympathetic newspapers in India and hoping that they would be picked up in the West, said Professor Mark N. Kramer, a Cold War expert at Harvard._</comment>


Judges question challenge to voting machines, but case could change state law - <AUTHOR> http://www.kansas.com/news/politics-government/article174144281.html <comment><USER3> This seems to augment Tim Snyder's argument for a return to paper ballots (not paper tapes which have a software layer between them and the machines).

</comment><comment><USER4> This is literally a non-story, in that no evidence is provided one way or the other, and it appears to be turning extremely traditional political posturing - forcing allegations of misdeeds to go through lawsuits and exhibit things like standing, harm, etc. -

Anyway, that being said, the stock picture they used for the header is pure unadulterated gold. It's straight out of The Colbert Report.

<comment><USER5> Give the entire case is about access to evidence (which Kansas denied previous request for), I'm not sure how the story could have been written any other way.

If election tampering were occurring, how would one discover that? How would one confirm it?

If the answer to the above questions is "Trust us, vote tampering isn't happening," then election laws in that state probably need to be changed.

<comment><USER6> At least it could describe some evidence in why there is a reasonable suspicion exists that something is wrong. Saying "well, some woman thinks something's wrong and because she happens to be a statistician she must be onto a government conspiracy" is not very informative. The only thing the article gives is:

> Clarkson has said her statistical analyses of elections over several years > have shown discrepancies indicating vote tampering.

What kind of discrepancies? Indicating how? What kind of tampering? No idea.

<comment><USER7> > _At least it could describe some evidence in why there is a reasonable > suspicion exists that something is wrong._

The burden should be on the state to demonstrate that voting is secure and accurate, especially given that they control the data and the processes, thereby making it more difficult for someone to present evidence. As it is, the state's position is circular: "we won't give you access to the information you need to prove something was amiss until you prove that something was amiss".

But, even in the absence of someone questioning, the state should be able to show why there is no cause for concern in ways that allow the public and outside experts to verify for themselves.

However, on the contrary, many precincts refuse to allow a paper trail/receipts and they continue to use machines that have demonstrated vulnerabilities, further obscuring the issue.

It looks like this case may be prompting legislation that is moving in exactly this direction. That would be a positive outcome.

<comment><USER6> > The burden should be on the state to demonstrate that voting is secure and > accurate

It doesn't work this way. It can't. It's like I am saying "you are a reptiloid alien from planet Nibiru planning the conquest of Earth" and now the burden is on you to prove that you are human and not an alien wearing human skin as a costume. Normal people do not behave this way, and if you claim the election has been tampered with, you need to present at least some evidence why you think so. Otherwise you're just running your mouth (or keyboard) and blowing hot air.

> As it is, the state's position is circular: "we won't give you access to the > information you need to prove something

Not true. She does claim there's evidence that something is wrong and she can prove it statistically - we just don't know what it is because there's no reporting on it. So we can not verify whether she is onto something or her statistics is junk and she's just trolling, in which case the state is right to refuse to spend time on her.

> the state should be able to show why there is no cause for concern in ways > that allow the public and outside experts to verify for themselves

How would that look like? The vote is secret, for a reason, and if you do not trust the state mechanisms that collect that vote, how would you become convinced that the vote is accurate without some trust in the process? How that mechanism would look like?

> they continue to use machines that have demonstrated vulnerabilities

It is true that the machines have vulnerabilities, as do about 100% of computer equipment. Given that, I am not sure what your proposal it - <USER2> using computers at all and count everything by hand? What is the counters are dishonest too? How paper trail would help - personalized vote log is highly private information, and non-personalized one can easily be faked - how do you know if the system didn't report your vote for D as R and vice versa if you are just looking at the stream of Ds and Rs on the tape and don't know which is which? How do you make the system that demonstrably can not be tampered with while you have zero trust in hardware, software or people dealing with it? I don't think it is possible.

Of course, there are mechanisms to prevent election fraud, and they are being used, but each of them involves a degree of trust and can be questioned, and I don't think any of them can be scientifically verified without destroying the privacy of the vote in the process.

<comment><USER7> > _It 's like I am saying "you are a reptiloid alien from planet Nibiru > planning the conquest of Earth" and now the burden is on you_

Your line of reasoning is valid--that a claimant cannot simply make an assertion and declare it true, simply because it cannot be disproven. But, what you're missing is that it's the _state_ that is making the initial assertion: that voting is secure and accurate. So, they are the ones claiming the voters to be reptiloids.

Pretty much the whole of your comment is undermined by this single misapplication of reasoning. But, I'll continue on a couple of other points...

> _Not true. She does claim there 's evidence that something is wrong_

She's asserting statistical anomalies that can be clarified with additional information (i.e. a recount) that the state refuses to provide. But, that's not the point. Again, she's in this position based on a fallacious premise that you've accepted: the state's assertion of security without sufficient proof.

> _How would that look like?_

There are probably n technical solutions to this. A simple one would be paper- receipts with anonymous identifiers that tie votes to tallies published on- line. Anyone can look up their votes/results and/or download them to run analysis. Add a cryptographic hash to avoid forgeries. Speaking of hashes, there's also block-chain.

> _It is true that the machines have vulnerabilities, as do about 100% of > computer equipment. Given that, I am not sure what your proposal is_

Your premise leads you to exactly the opposite of the conclusion that one would expect. That is, you acknowledge the problems, but conclude that it's acceptable for the approach to be trust in the system versus introducing corroborating processes or systems.

I'm not sure if you know the degree to which vulns are a problem, but start by at least closing _known_ vulnerabilities. Then, provide other validating factors that mitigate the shortcomings you acknowledge, whether via paper or otherwise.

In any case, throwing our hands up and saying "it's hard, so let's stick with what we've got and declare it secure even in the face of challenges" is _not_ the solution.

<comment><USER6> > that voting is secure and accurate. So, they are the ones claiming the > voters to be reptiloids.

No, they are not. They are claiming the normal state of affairs - that the vote is what it appears to be, and the voters that appear humans are indeed humans. The challenger makes extraordinary claim - that some of them are instead not what they appear, but reptiloids wearing human skin as a costume. Extraordinary claims require extraordinary proof. Claim that humans are humans do not require proof. Claiming that voting process is not fraudulent is not extraordinary, since this is indeed a common case in vast majority of the situations.

> She's asserting statistical anomalies that can be clarified with additional > information

Which anomalities? So far nobody named even one.

> the state's assertion of security without sufficient proof.

It's not a proof, just as I have no proof you are not a reptioloid from Nibiru trying to undermine human race by casting doubt on electoral processes. I just accept the normal case that you are human wanting honest elections, even with slightly misguided logic - because this is the common case. That's what you have to do to be sane - in fact, there's specific form of insanity where person suspects all surrounding him is an elaborated setup to trick them and demands extensive proofs of most mundane things like that drinking tap water won't instantly kill them and that their relatives are not secretly plotting to murder them - and it is almost always an extremely severe and debilitating condition.

> A simple one would be paper-receipts with anonymous identifiers that tie > votes to tallies published on-line.

What prevents one from faking 10000 anonymous IDs voting for $ones_favorite_candidate? All anonymous IDs look alike, how do you verify they are true? In fact, sine you have no idea which of the IDs is yours, how you even know your vote has been recorded properly? How do you know the hardware just doesn't print one vote for $favorite_candidate after each vote against, with fake (or just unused - e.g. dead person's) ID?

> Speaking of hashes, there's also block-chain.

Oh of course. How could I forget, every problem in the world has one simple solution - use blockchain.

> but start by at least closing known vulnerabilities

Sure, that is sensible. But for that they should be _known_ \- and so far, the statistician in question didn't make them _known_ , but only _implied_ and _hinted at_. That's exactly my complain. When I say "there's RCE vulnerability in current version of Linux", you say "ok, show me the exploit", not "well, now it's on Linus Torvalds to prove there's no RCE in current version on Linux, and he must spend as much time as that guy wants to prove it to him". I would like to see the same approach in this case, that's all.

<comment><USER7> Looks like we've wandered into the ridiculous.

> _They are claiming the normal state of affairs - that the vote is what it > appears to be_

Except that the "normal state of affairs" is not a "normal state" any more than PCs are inherently secure. Of course they're making a claim. It's asinine to suggest otherwise.

BTW, the whole reptiloid/nibiru analogy doesn't work here. Never did.

> _Which anomalities? So far nobody named even one._

She claimed statistical anomalies, as well as others. They're not in the linked article, but it's easy enough to Google her name.

> _What prevents one from faking 10000 anonymous IDs_

Wait. Is there a threat or isn't there one? First you're asserting that the normal state is safe. Now you're concerned about 10000 fake anonymous IDs that could arise from taking _extra_ measures to secure the election.

> _use blockchain._

I know, it's easy to bash blockchain. It happens to be a potential solution to your fake anonymous IDs, but never-mind that.

Really, it sounds like you're just arguing for the sake of arguing. Enjoy yourself.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Can someone explain why the machines themselves would be subject to inaccuracy? Can her discrepancies be explained by voter turnout or varying degrees of candidate charisma/competency?

<comment><USER9> When people vote, the machines they use record votes electronically and on tape. However, when summing up the votes, only the electronic portion is tallied up by removing a physical memory device and plugging them in to another special machine that does the summation.

This woman wants access to the actual physical tapes which have been stored, in order to do a statistical sampling of them in order to say how statistically likely the electronic tally was. (Physically counting the tapes by hand is not practical)

The courts are considering barring her again from access to the tapes.

If the electronic portion was highly statistically unlikely, then there are a lot of places the vote could have been tampered: tallying machines, individual voting machines, memory cartridges, physical transport of memory cartridges, even the paper tapes themselves, etc.

For a documentary I recommend watching Hacking Democracy.

<comment><USER8> Thank you very much for explaining it. In my jurisdiction, we fill in our choices on paper ballots and insert them to a machine. I thought this single machine did its thing on its own and without additional machines. Thank you for explaining the process and the various points of suspicion in the process

</comment></comment></comment><comment><USER10> From an actual source: [http://www.kansas.com/news/politics- government/article174144...](http://www.kansas.com/news/politics- government/article174144281.html)

<comment><USER11> Thanks, we've updated the link from [http://bloomsmag.com/a-mathematician-may- have-uncovered-wide...](http://bloomsmag.com/a-mathematician-may-have- uncovered-widespread-election-fraud-and-kansas-is-trying-to-silence-her/).</comment></comment>


Startups Try to Spread Outside of Silicon Valley - <AUTHOR> http://www.wsj.com/articles/startups-try-to-spread-outside-of-silicon-valley-1468209662 <comment><USER2> > technical talent who are burned out on the rising cost of living and > declining quality of life in the Bay Area.

Yup.</comment>


5 Reasons why the Kindle Fire stands out. - <AUTHOR> http://ajibz.tumblr.com/post/10993396552/5-reasons-why-the-kindle-fire-stands-out

<comment><USER2> I'm convinced they are going to just kill it. $199 and access to all of amazons stuff, really gonna being interesting.</comment>


Is there a helpdesk for CSS/HTML problems? - <AUTHOR>

Yesterday I got caught up in Internet Explorer 6 CSS hell. I am not an CSS expert, so I was thinking for once it would be nice to have a place to consult. Ie what if I could post my problem to some web page with a price tag, and if somebody else can solve it for me, they get the money? Is that a common way helpdesks work? Are there even public helpdesks, or only internal ones?
<comment><USER2> Freelance Comunities:

<http://www.rentacoder.com>

<http://www.odesk.com>

Forums:

<http://www.webmasterworld.com/category21.htm>

<http://www.thescripts.com/forum/forum143.html>

</comment><comment><USER3> Usenet is not dead.

[http://groups.google.com/group/comp.infosystems.www.authorin...](http://groups.google.com/group/comp.infosystems.www.authoring.stylesheets/topics)

</comment><comment><USER4> I have had a lot of CSS problems with IE6 (and solved it all), maybe if you tell me what the problem is I can help you.

;)

</comment><comment><USER5> you can ask a question here for free. <http://www.htmlforums.com/>

</comment><comment><USER6> Have you tried experts-exchange.com?

</comment><comment><USER7> You didn't have any luck on IRC?

<comment><AUTHOR> I don't really know my way around IRC, but thanks for the idea!

<comment><USER7> There is a #css channel on irc.freenode.net with lots of people in it. Basically, you want to be polite, don't repeat yourself, don't dump code to the channel, and don't get pushy if no one answers. IRC is a great way of finding people to talk with on all kinds of technical subjects.

I'll take the opportunity to repeat that there is also a #news.yc on freenode, although very few people use it.

</comment></comment></comment><comment><USER4> I always recommend Head First HTML with CSS & XHTML Is the best way to learn CSS!</comment>


Profit from frontpaging HN and Reddit - what now? - <AUTHOR> http://yieldthought.com/post/1477902830/37-91-from-frontpaging-hn-and-reddit-what-now/

<comment><USER2> The author of this post submitted it 45 days ago: <http://news.ycombinator.com/item?id=1869264>

Interesting how the luck of getting noticed on the new page is so important to getting engagement. I wonder if in this case it's the difference in titles.

<comment><USER3> DupDetector dropped the ball on this one. ;)

<comment><USER4> ironic, since this was actually submitted by RiderOfGiraffes - the user behind DupDetector!

<comment><USER3> Hence the ;)

<comment><USER4> ah - I wasn't sure.

;)

</comment></comment></comment></comment></comment><comment><USER5> No referrer has typically corresponded to Twitter clients in my experience. Given the volume of discussion of the post on Twitter, this seems like the most likely explanation.

There is the occasional Twitter client that does set a referrer value, like Twitterific, but most seem to skip this.

<comment><USER6> Do they set the user agent?

</comment></comment><comment><USER7> Does anyone know what the stats app used is? Thanks.

<comment><USER8> I was wondering the same thing. Turns out that he's using Analytk, a project that he created himself.

Here's what it appears to do:

1\. A referrer information is gathered on each page hit via javascript and submitted to his server

2\. The Analytics page uses Ajax to grab the aggregated data, then charts it using the Google Charts API

That's it. At first I was really interested in it because its beautiful, but on a second look it doesn't do anything that Google Analytics doesn't already do except easily show you referrals from a set of sites that you care about.

<comment><USER9> I wrote it because it gives me real time tracking for posts that have just been published. Initially it updates every minute, which is really fascinating to see. The rate of hits once the site is picked up by HN or Reddit is a _very_ strong predictor of it's final page view count.

The graphs get a bit pointless after a day or two, though. If people are interested in playing around with analytk then maybe I'll open it up to URLs from elsewhere and work down some of my 'to do' features, like 'show me just the day/week'.

Thanks for the beauty vote, I wrote it to look great on my iPhone :-)

</comment></comment></comment><comment><USER10> No matter what, you are my ideal weekend project success story, for making something useful, relatively easy to write and very fun.

</comment><comment><USER11> I would advice to look at seo and landing page strategies. also try optimizely for a/b testing.

<comment><USER9> Thanks, I'm struggling to justify adding a/b testing vs all the other things I could do with the same amount of time (e.g. add social proof etc.)

Also it took me a long time to realize I can a/b test amazon conversions by using multiple affiliate ids... ;)

</comment></comment><comment><USER12> The traffic itself is temporary, but the random backlinks the site got from the brief awareness should be good for seo. When I submitted my now-defunct expired domain name related site and got a similar treatment, it pushed me nearly to the top for the term "expired domain names" on Google.

</comment><comment><USER13> >Strangely, most of the traffic to the game site is 'direct', which can mean almost anything in analytics. Privacy-aware browsers, links sent thorough offline email programs, who knows? Not Google, that's for sure:

Direct means 4chan, just fyi</comment>


Django Advent, Day 7: Natural Keys (Russell Keith-Magee) - <AUTHOR> http://djangoadvent.com/1.2/natural-keys/

<comment><USER2> Sounds cool. I'd like to see django start to support composite primary keys in the future.</comment>