Last.fm: "Techcrunch are full of shit" - <AUTHOR> http://blog.last.fm/2009/02/23/techcrunch-are-full-of-shit

<comment><USER2> I'm chuffed that a respectable outfit like last.fm publishes a blog post with a title like that. About time.

Techcrunch has been on the inflection point of "mattering" to the wider public, which scares the life out of me!

<comment><USER3> It's not even grammatically correct!

"Techcrunch _is_ full of shit" would be right.

<comment><USER4> The author is British: [http://en.wikipedia.org/wiki/American_and_British_English_di...](http://en.wikipedia.org/wiki/American_and_British_English_differences#Formal_and_notional_agreement)

<comment><USER5> And if you get any news from bbc.co.uk or read British bloggers you'll get accustomed to sports teams and corporations being considered plural. e.g.: "Apple today are releasing..."

<comment><USER6> Well it's accurate, a corporation isn't an individual and when you're dealing with big business it is always controlled by multiple people so any decision is decided by a group.

<comment><USER7> Actually a corporation is, legally, an individual.

<comment><USER8> Unless I'm mistaken, that absurd notion is only entertained in the US.

<comment><USER9> Nope. I am British and used to be a journalist. The first place I worked had a very large sign on the wall:

"Companies are singular".

Which indeed they are, although staffed by multiple individuals.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> It'll be interesting to see if TechCrunch acknowledge this, respond or apologize...

My bet is they completely ignore it.

</comment><comment><USER11> It finally happened. Techcrunch is the new Valleywag.

<comment><USER12> so who is the new techcrunch?

<comment><USER13> We are. Hacker News is the top spot for getting news relevant to startups.

<comment><USER12> well we are more of a news aggregating service, need some original content. Need more stories to break on HN

<comment><USER13> You don't have to have the same form as something in order to replace it. I don't think the number of breaking stories has any effect on the quality of HN.

<comment><USER14> In fact, I think that more 'breaking' stories is going to have a negative effect.

<comment><USER6> Agreed, more emphasis on 'breaking stories' means that there'll be more fake 'breaking stories'. Look at tabloids, the more news they 'break' the better they sell and now everything is outright lies.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> Last.FM FTW, seriously TechCrunch is getting worse and worse every week.

<comment><USER2> I (obviously) agree. You might see some reticence to post here though, as TC is a bit of a cabal and nobody with a public profile wants to shake the cage.

<comment><USER16> I have a public profile, and long ago dismissed TechCrunch as one of the least intelligent blogs on the Internet. The writing is bad, the content is boring, and now we know it's not even correct.

Go away, TechCrunch.

<comment><USER17> Boring it's not.

Frankly, I'm disappointed by this thread. HN's audience is supposedly smarter than your average Internet crowd. But all I'm hearing here is cheap bashing of the target that everyone loves to hate. Can anyone do better and post an intelligent comment that addresses the topic?

Again, TechCrunch is not boring. One of its strengths is not so much the "breaking news" aspect, but the tongue-in-cheek or tell-it-like-it-is.

In many news organizations, politically correct has removed any spark of interesting content. Not at TechCrunch. It's news with an attitude. You may or may not like the attitude, but at least there's one.

[disclaimer: you can accuse me of bias because of my company connections to TC, but it also means that I got to see some of the behind the scenes and I learned a lot doing so]

</comment></comment></comment></comment><comment><USER18> If people didn't like Techcrunch, they wouldn't go to the site. If Techcrunch was irrelevant, they wouldn't generate massive leads for pet projects that people create.

There was an article a week or so ago about how people were complaining every time Techcrunch posted a story about some Twitter application. The author of the article wrote back in protest basically saying, "well if you don't like the articles, don't comment on them."

Techcrunch generates buzz. They're good at it. I may live in a hole, but I didn't really hear about Last.fm until Techcrunch posted that story. Last.fm got a pageview from me off of that story.

And personally, I don't really care about TC's opinion. I'm smart enough to make my own judgment. But until they report it, I have little way discovering new companies.

<comment><USER19> __If people didn't like Techcrunch, they wouldn't go to the site. If Techcrunch was irrelevant, they wouldn't generate massive leads for pet projects that people create. __

these points are both true, but they don't alter the fact that Techcrunch is also full of shit.

<comment><USER18> If they are, why do people post TC articles on here every few hours?

I typically don't advise people to read articles that are full of shit.

I think people who whine about TC articles and think they are full of shit are in the minority. Their fan base seems to be growing rapidly. You can't impress everyone with your writing. And besides, TC is a blog. I think you're entitled to say whatever you want, even if its full of shit.

</comment></comment></comment><comment><USER20> This makes me think about that TechCrunchee getting spit on the face...

I'd now like to get the spitter's side of the story.

<comment><USER21> TechCrunch is awful, but there's no excuse for the spit in the face incident. I don't give a damn what lousy, fabricated article TechCrunch might have published to precipitate that. It's disgusting and totally uncalled for.

<comment><USER12> who knows if that really happened, or if Arrington was just linkbaiting to make money

<comment><USER22> Don't treat Arrington like some soulless mythical creature. He's a real person. He's susceptible to being offended enough to get pissed off at people and to rant even when he's been in the business for a long time.

Can you imagine how low you'd have to be to fake an incident like that just to get a few hits? Arrington has his faults, but he's not a showboater.

(Also remember that this article was posted while he's taking a break from TechCrunch entirely. Don't blame him for this story.)

<comment><USER23> I don't think that anyone is treating him as a "soulless mythical creature", I am interpreting this as people viewing Michael Arrington as a person of low morals/values.

Additionally, I dont actually see anyone blaming Arrington in this thread - <http://news.ycombinator.com/item?id=491784>

<comment><USER22> There's a tendency to assume that people that aren't you are heartless and will do things you never would do yourself. That's very rarely the case. In this case, assuming Arrington would make a huge drama for nothing, claim somebody did something they didn't, and leave the scene just to get some hits is treating him like somebody who's a tad inhuman.

</comment></comment></comment></comment></comment></comment><comment><USER24> That title is nothing new. I'm just glad someone (with a big audience) is saying it publicly.

</comment><comment><USER25> Overall, not a bad deal for TC, I'd say. Checking on the twitter stream shows that there's a lot of RT of this headline - which will only serve to spread TC's name around. It may be bad in the long run, but they may be able to issue some muted apology, patch things up, and restore their standing. More coverage, etc.

Of course, with MA's combative personality, it may go slightly differently, but it's probably a net positive for TC. Sadly enough.

<comment><USER10> Yeah I'm guessing most people on twitter already know about TC actually. Heck most of them probably first read about twitter on TC - they post enough 'twitter' stories there.

</comment></comment><comment><USER26> The most disappointing thing is that the TC writer is clinging to his story. After a complete denial he is still trying to suggest there is some truth in the rumor.

Either produce the hard evidence or apologise.

<comment><USER27> Link?

<comment><USER26> Err the TC article...

"Despite my attempts to corroborate it and the subsequent detail I've been able to gather, I still don't have enough information to determine whether it is absolutely true. But I still don't have enough information to determine that it is absolutely false either."

Is his last word on the matter. Essentially he is saying they have denied it but his "rumor" may even still be true.

That smacks of a lie somewhere along the line to me (and as it is my job to find lies I suspect it is the case). :)

[http://www.techcrunch.com/2009/02/20/did-lastfm-just-hand- ov...](http://www.techcrunch.com/2009/02/20/did-lastfm-just-hand-over-user- listening-data-to-the-riaa/#comment-2632012)

</comment></comment></comment><comment><USER28> Why does this story have such a longer Front Page Life?

</comment><comment><USER29> Did he mean to say "Techcruch are full of shit" instead of "Techcrunch is full of shit?" Is there an inside joke I'm missing?

<comment><USER30> In British English company names act as plural nouns.

<comment><USER31> I usually do this, and editors always want to change it. I never realized it was an English thing.

<comment><USER6> I have the same problem, I just don't approve of 'style' when it comes to writing. There are lots of personal style and it does amazing, but there are company style guides and printing houses all have different ones.

I have a serious problem using '...' in writing unless it's from the person's mouth. I always learnt if someone says something directly to you then use '...' and if it comes indirect you use "..." so all novels should use "..." because it's fiction and was never said. Yet so many printing houses have gone away from using "..." and have switched to using the quotation form '...'.

I'm unsure why I get worked up over this, I guess I just think it's stupid so few people have control over how the masses perceive the English language. This is a prime example, in the US most institutions use 'is' in this situation, to such a degree that 'are' looks bizarre and the opposite happened in the UK.

The same is with 'ise' and 'ize'. Using 'ize' is so prevalent in the US that in many words the letter S is being supplanted with Z in situations it's not supposed to be. The prime example is how analyse is incorrectly spelled (even in spell checkers) as analyze and I'm sorry but it is technically correct to substitute the suffix 'ise' for 'ize', however analyse is a complete word without suffix, it's not discussing anal.

<comment><USER32> Style is not a matter of control, it's a matter of consistency. There are many, many areas in English where there is no clear rule as to what's "right", so to ensure consistency style guides make explicit what a given publication will do in that instance. Numerals for example, are often written out one through nine, but digits after that. Others will always use digits. Neither is "right", but consistency matters.

As for the quotes, I suspect you'll need to unlearn that rule. I'm not even sure how you got there, except perhaps by misunderstanding the rules for nested quotations, Eg:

"She was absolutely furious, she shouted, 'I hate you' and then ran off," said John

(If it helps any US readers to understand the British usage of plurals, think about the police. You wouldn't write "Police says it has arrested two suspects, but it is still hunting for two more", right? That dissonance is exactly the same as how US usage of the singular, particularly when it comes to music groups -- "U2 says it will tour in the fall" -- sounds to Brits. )

<comment><USER33> The diff seems to be that Americans take a group's name as a synecdoche while Brits apparently think of it as a plural noun.

Would the British rendition be "U2 say it will" or "U2 say they will"?

</comment></comment></comment></comment></comment></comment><comment><USER34> I really want to see what Techcrunch says.

While this is terribly unprofessional, Techcruch had it coming to them.

<comment><USER19> like most people who post here you need to read Paul Graham's early work. professionalism is harmful to quality of work and especially so in startups. professionalism is an artifact of the industrial revolution and is not relevant in all fields. computer programming is to some degree post-industrial and professionalism is irrelevant and archaic for many programmers. criticizing a programmer for being unprofessional is like criticizing him or her for not being well acquainted with the phases of the moon and the effect those phases have on that programmer's crops.

<comment><USER26> rubbish. it is easily possible to be professional and produce excellent work. it doesnt have to be stuffy and haughty that's all :)

(and yeh I read his early stuff: not a fan. At every stage in a startup you have to get to a stage where you need to show some professional gloss to prove your not just another backroom programmer - IMO it is the core reason why a lot fail, they cling slavishly to that "fun guy" image and lose corporate custom because of it ;))

@the previous poster: I wouldnt call it unprofessional per se. Empassioned perhaps :D

sorry for the OT :)

</comment></comment></comment><comment><USER35> And just like that, there's a whole new audience for TechCrunch that never existed.

"Thanks Last.fm for all the free PR" Sincerely, M.A.

<comment><USER36> Except that this Last.FM post is currently the number 3 result in Google for "TechCrunch", with its title prominently displayed.

Oops.

<comment><USER37> That's just Google giving prominent placement to something they see as breaking news. It'll disappear in a week or so, then reappear somewhere much lower in a few more weeks as it's normally indexed by their crawler picking up links and rebuilding its graph.

</comment></comment></comment><comment><USER38> Techcrunch tried but couldn't become the Red Herring of web 2.0. Nowhere near.

</comment><comment><USER19> there you have it in a nutshell</comment>


The Real Difference Between Git and Mercurial - <AUTHOR> http://xentac.net/2012/01/19/the-real-difference-between-git-and-mercurial.html <comment><USER2> In a way, the Git vs. Mercurial debate feels like vi vs. emacs all over again. Hardcore emacs users never quite understood the appeal of a modal editor; hardcore vi users couldn't quite understand how people lived with an input model that constantly moved their fingers off home row.

Usability preferences can differ greatly by person. Another example is information retrieval in a personal database or help system. Some people prefer going through a search engine; others find a directory-based approach more intuitive (and forcing one approach on the other group does not improve productivity).

Similarly, having a unified set of tools for all kinds of version control problems is not necessarily an unalloyed good for everyone. Dealing with persistent history does not necessarily warrant the same approach as dealing with work-in-progress changes. For some users, it may be easier and better to consolidate both problems, for others, it can be more productive to keep them separate.

The Mercurial designers, for better or worse, have decided to separate persistent history changes from local work-in-progress changes, the latter being done via Mercurial Queues. That has the disadvantage that you need to learn a separate set of tools; it has the advantage that unfinished stuff does not pollute your repository's history and that you can tailor both sets of tools to their respective needs (whether they are in fact properly tailored is a different debate).

I suspect that, similarly, Bzr's one-directory-per-branch approach (inherited from Arch) is an easier mental model for some users to deal with than either git's or Mercurial's DAG-based approach, despite many git and Mercurial users not understanding the appeal.

Incidentally, both examples that you list (git stash and git commit --amend) are easily handled by Mercurial Queues. You don't need several separate extensions. (Obviously, some people do prefer special extensions because they reflect their mental models better or optimize common workflows.)

<comment><USER3> _Incidentally, both examples that you list (git stash and git commit --amend) are easily handled by Mercurial Queues._

No, no, no. Let's get this myth out of the way that Mercurial Queues can somehow be part of a _modern_ revision control system. Mercurial Queues are a simple stack of _DUMB_ patches. The only reason why they are used is that often that is all you really need.

But the moment you need any kind of advanced functionality, such as say, something unimaginable like rebasing a Mercurial Queue against an upstream change that conflicts, you are suddenly dealing with tools that are no more advanced than diff and patch, and most certainly don't support any advanced operation on the patches that they juggle. I heard some modern tools like CVS support an advanced operation they call "merge". I'm still waiting until someone implements a usable version for Mercurial Queues.

So please, the moment you use Mercurial Queues in an argument, you've lost. Mercurial Queues are diff and patch in a fancy packaging, but with all the limitations of those. If your revision control system needs them to have the same functionality as another, you've lost.

The dirty secret is this: Mercurial users use Mercurial Queues because Mercurial got branching wrong. It's as simple as that.

 _In a way, the Git vs. Mercurial debate feels like vi vs. emacs all over again. Hardcore emacs users never quite understood the appeal of a modal editor; hardcore vi users couldn't quite understand how people lived with an input model that constantly moved their fingers off home row._

Emacs and vi both have their strengths and weaknesses. I've used both over the years sometimes trending to one or the other depending on the circumstances. As I've gotten to know both better, I understand the relative strengths better and know when it makes sense to use either. They're both good tools, and will both keep big user-bases for the foreseeable future.

Can I say the same about Mercurial and Git? That's a resounding NO.

I can accept that some holy wars can't have winners. But we should also be willing to accept that some tools can be just _better_ than others.

<comment><USER4> I disagree (and we have already had this argument I think ;). Mercurial Queues are different from git branches, not just "worse".

With MQ, and especially with a versioned MQ directory, you have a great workflow for review-ready patches. And review-ready patches are what you are creating, after all, in most large projects: You do some work, you refactor that work N times, then you submit it for review, then you repeat that M times until it passes review and you push it to trunk.

With MQ, you can see the entire history of your set of patches. If you have a queue and you refactor two patches into one, you can go back in history in the versioned MQ dir to see what things were like before that. That is useful, because again, the "product" you are creating is a set of review-ready patches. So versioning the patches makes sense.

I understand that you can use git branches very effectively - I use git myself, not mercurial. However, if you use git to rewrite the history of your branch as part of your development process, AFAIK there is no way to go back in time and instantly see what your branch looked like at time K in the past, because history has been rewritten.

Rewriting history is great - you don't want to submit for review a huge list of patches that include bugfixes as you were working. You want to submit the final patches. But what if you do need to look at the state your work was in the past, before you rewrote history?

<comment><USER3> _Mercurial Queues are different from git branches, not just "worse"._

Mercurial Queues are bolted onto Mercurial and you can often see the cracks. Merging is my pet peeve which I've already mentioned. I think it's not controversial to say that it's a pain? I think that, in true Mercurial tradition, there's an extension in development for it now...

So why do we need to deal with this bolt-on and the resulting pain? Because Mercurial branches aren't good enough, or at least can't adequately support the workflow people need. Compare the amount of Mercurial users using mq to the amount of git users using quilt or equivalents.

I don't disagree with the abstract principle of operation of Mercurial Queues. I disagree with Mercurial as it is.

 _However, if you use git to rewrite the history of your branch as part of your development process, AFAIK there is no way to go back in time and instantly see what your branch looked like at time K in the past, because history has been rewritten._

1) It may be possible to do this with reflog. I don't know for sure because I haven't needed to do this yet. (I think the main problem is that by default reflog purges old history at some point)

2) You can simply create more branches as you go. i.e. replace qcommit by git checkout -b etc. Then push the final ones.

<comment><USER4> I agree that MQ has some pain points. Merging, as you say.

But git branches also have pain points. The only way to save history from before you rewrite history is to save branches, as you mentioned - but doing that manually every time you rewrite history is a pain.

<comment><USER5> Actually the history is kept by reflog for 90 days by default I believe (and you can change this). This covers the large majority of cases where you have completely screwed up your history rewriting and need to go back to a state you remembered you were in.

<comment><USER4> 90 days, or any other finite amount, isn't a solution for what I want. I don't need a quick undo if I erred, I want to see the development process that went into creating some code that later was committed into trunk (and perhaps much much later turned out to have a bug).

<comment><USER5> This probably comes down to discipline, meaning that when you rewrite history in git you may want to take care that you're keeping the useful bits of it and not just squashing everything down to get fat feature-rich commits. Do you think that the history-rewriting tools in git are too often abused by the average git user such that the use of git in general has the problems you've described?

<comment><USER4> Not sure if I agree as to what is normal and what is abuse here. If you write some feature in a branch, and have various commits for bugfixes as you go, you might want to merge those little commits away for review as well as for bisection purposes. This seems both normal and desirable to me - no one wants to review a set of 100 patches for a feature if they contain a lot of redundancy. It's useful to do small commits as you work to get a feature stable, but it isn't useful to ask someone to review all those commits, especially if they fix a previous bug introduced by another such small commit.

However, that history can still be very useful: You might hit a variation on those bugs later, and seeing the original unrewritten history can help a lot in refreshing your memory on what you did there (and it can be even more helpful for someone else getting up to speed on the code trying to fix that bug). Losing the history after history rewriting isn't a good thing.

<comment><USER5> In my experience what is being reviewed by your peers are the feature diffs, not the individual commit diffs. What the actual history looks like is entirely up to you as the coder.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I wrote an article with the exact same title but very different content almost exactly one year ago: [http://stevelosh.com/blog/2010/01/the-real-difference- betwee...](http://stevelosh.com/blog/2010/01/the-real-difference-between- mercurial-and-git/)

</comment><comment><USER7> This article seemed to start off well, but at the end turned into a 'Git is better because tools can edit the DAG storing state. QED'.

It is possible that that is true, but I'd want a stronger backup. Making no negative comments about git at all sets off very strong alarm bells for me.

<comment><USER8> I think the author does say something negative about git, just doesn't say it in a negative way. "When a git user runs into a problem, they look at the tools they have on hand and ask, "how can I combine these ideas to solve my problem?""

The negative here is that A) git user has to know about all the tools, which takes a long time, and then solving the issue requires quite a bit of thought.

That's one of the problems about git is that as a result of the massive flexibility there doesn't seem to a "standard" way to do things, even basic things. Each org has to develop their own processes which is annoying and difficult for new people in the org.

<comment><USER3> I wouldn't mind some of the big users of git summarizing the "best practices" they arrived at in a nice presentation.

<comment><USER9> For large projects, there is git-flow: <https://www.google.com/search?q=git- flow>

I remember someone posting a recommended workflow for smaller projects, but I don't remember what it was called.

<comment><USER10> github uses a different flow. This article mentions the issues with git-flow and describes the flow used at github:

<http://scottchacon.com/2011/08/31/github-flow.html>

</comment></comment></comment></comment></comment><comment><USER11> A small nit about git stashes: they aren't stored in a special linear branch. Each stash is a little branch off of wherever you were when you created the stash. The only trick is that the stash commits are named something weird so that "git stash list" can find them and list them.

You can check this yourself:

        git show stash@{0}

Look where it says "WIP on {branch-name}: {hash}". That {hash} will be one of the hashes in the "Merge" header near the top of the commit.

You can also see this visually with "gitk --all".

<comment><AUTHOR> You are correct. They aren't a linear history. In fact, the key is the @{#} syntax (man git-rev-parse). Each stash commit is a single commit pointed to by a ref/stash reference. Because of the reflog, we can see what ref/stash used to point at, that is @{1}, @{2}, etc.

<comment><USER11> It's actually (potentially) more than a single commit. If you have a dirty index when you stash then that will also be committed along with your working directory changes. If you use the new(ish) --include-untracked option to stash, a 3rd commit will be added that has the untracked files in it. The main stash commit (that holds your working directory changes) is a fake merge of all the commits, just so there are pointers back to the other 2 commits.

</comment></comment></comment><comment><USER12> I sometimes wonder that BitKeeper had allowed kernel developers to use it freely, none of git would have happened. Conversely, does anyone know what's going on with BitKeeper these days? Assumedly they can sell their commercial product to some markets but practically I haven't heard of BK once since git was announced. Potentially a big blunder on their part.

</comment><comment><USER13> imho, as biased as a huge fan of hg can be, and someone who lives in git on a day to day basis, is that git has an actively hostile UI, mercurial has a great one.

all the other technical gizwangs can be debated by propellerheads till the cows come home, but the user experience is quite plainly better in hg.

flamewar goes here ->

<comment><USER3> I think the point that the UI of the default tools is better in Mercurial is entirely uncontroversial.

However, equating that to the user experience is short-sighted. The user experience is also how well the tool works and fills the needs of the user. It think it's very controversial to state hg is better there (this is a polite way to say you're completely wrong).

</comment></comment><comment><USER14> Wait, Mercurial users start _coding_ when they run into a problem with the tool?

I always start googling and hoping there's a stackoverflow question about it that has an answer that I don't get.

<comment><USER3> That certainly reflects my experience: I have a problem...

Mercurial: there's an extension for that!

Git: you can fix that just by adding --foo bar:buzz --derp herp to the commandline lol RTFM

<comment><USER15> Maybe somebody can add a extension to Mercurial that let's you use empty folders.....

<comment><AUTHOR> Git and Mercurial both suffer from this "problem". Because manifests/trees must have contents (file hashes) to exist, you can't track an empty folder.

I suppose git's tree objects could point to the empty tree to record an empty folder, but most of the git code is comparing file blobs not trees.

<comment><USER16> In git, we solve this problem by sticking a .gitignore file in any directories we want to be part of the repo, but without the contents (cache folders, user- generated data destinations, etc.)

How do you get around this in mercurial?

<comment><USER17> It's usually .gitkeep from what I've seen. .gitignore usually lives in the repo root.

</comment></comment></comment></comment></comment></comment><comment><USER18> (I know Mercurial very well. I evaluated 5 or 6 distributed VCS tools and decided to migrate my employer's repository from CVS to Mercurial in 2008: 2GB of history, 150k files, 20k changesets, dozens of developers.)

I don't understand the poster's insistence about wanting to perform an operation similar to git stash in Mercurial "without creating a commit". Creating an ephemeral commit _is precisely the perfect solution_ in Mercurial! Do it, then all regular Mercurial commands (log, diff, etc) will work to manage it. To get rid of the temporary commit later, simply "hg strip" it. It will remove the changeset (and all its children, if any) from the history (a backup will be made in .hg/strip-backup). hg strip is part of the built-in mq extension.

Also, a simple solution to the poster's last complain (re-doing a commit while keeping history of the original commit) is as follow: let's say you are at revision A. You commit B. You realize you screwed up. So you go back to A: _hg update A_. Then you revert your working directory to the state of B: _hg revert --all --no-backup -r B_. Then you make the changes you forgot, and commit again: _hg commit_.

<comment><USER3> _I don't understand the poster's insistence about wanting to perform an operation similar to git stash in Mercurial "without creating a commit"._

Having it as a real commit is an issue when you want to pull upstream for example. My solution would be hg qnew stashname, but I already ranted about the limitations of MQ in another thread here.

<comment><USER18> Why is it an issue when you want to pull upstream? If you do it, the temp commit will live aside from all the csets pulled from upstream. If you want to resume work on it later, then just update to it. If you want to resume work on it while effectively "merging" its changes with recent upstream changes, then simply rebase the temp commit: hg rebase -s tempcommit -d new-head-pulled- from-upstream. (rebase is a built-in extension.) That's the workflow policy I implemented and it works well. It is also easy to keep track of temp commits: running hg incoming/outgoing will show which changesets are present/absent in one repo compared to whatever other repo you use as a reference.

</comment></comment></comment><comment><USER19> Mercurial was my first DVCS so I'm perhaps biased but its API has always fit my brain better. We use Git at my current job but after a few days of trying to get used to it, adding shortcuts to avoid remembering the cryptic switches required to do simple tasks and finally screwing up in some merge conflict, I said the hell with it, installed hg-git and work happily ever after.

</comment><comment><USER20> The biggest advantage of Git's storage model is imo the reflog- I have irretrievably lost work to Mercurial Queues, and that's virtually impossible in Git.

<comment><USER4> If you version your MQ, you can never lose data in it.

In git, if you rewrite history, you lose information - you can no longer see what things looked like before you rewrote it.

Disclaimer: I use git myself and prefer it. But the hg and MQ bashing in the comments here is unfair.

<comment><USER20> When I used MQ, it was to modify history in a way equivalent to some of git's features. Versioning that defeats the purpose.

<comment><USER3> The MQ versioning repo is separate from the main versioning repo. So I don't see how one follows from the other here. You can perfectly modify history in the main repo and version that editing in the MQ repo. The main repo will look clean because the history editing is versioned in the MQ repo.

<comment><USER20> Ah, that's good to know. I was not aware of that.

</comment></comment></comment></comment></comment><comment><USER21> Even GitHub dude Scott Chacon (who does training on Git for GitHub and who wrote the book Pro Git) says in this podcast some aspects of Mercurial are better thought-out than Git: [http://thechangelog.com/post/3445186374/episode-0-4-9-git- sh...](http://thechangelog.com/post/3445186374/episode-0-4-9-git-showoff-and- xbox-kinect-with-scott-cha)

I agree with Scott's assessment: it's really not that huge a deal if your using Git or Mercurial; they're very similar--it's using a distributed version control system that's a huge deal. Many many places are still locked into old school, centralized systems that make collaboration much harder than it is using Mercurial or Git.

</comment><comment><USER22> I think that the real difference between git and mercurial is allowing multiple heads in the same branch. Everything else is just an API difference, but from high level point of view -- they're just trees if commits, that's all.

<comment><USER23> The real difference is the terminology: mercurial named branches mean something other than git branches (git branches are similar to mercurial bookmarks). Steve Losh's article explains that very well.

<comment><USER22> No, I know about bookmarks, but still, it's all about multiple heads. In mercurial branches, if you merge someone's work on the same bookmark as you did, you get new anonymous head. That head gets it's bookmark lost, since bookmark can only point to one changeset, that's why this bookmarks mechanism fits mercurial not too good.

While in mercurial native branching, you are allowed to get multiple heads in one branch, which from one point of view is frustrating, but from another is natural (since you really were both working on the same branch at the same time).

In Git they tried to solve this problem by origins system, but now, when I worked with both, I find mercurial branches to be the simplest concept that is easier to explain than git's origins.

The only big problem with mercurial branches is their speed, but I think that it can be solved (algorithms are not so complex to make it fast).</comment></comment></comment>


Alex Osterwalder and friends launch business model canvas game dev bootcamp - <AUTHOR> http://startupjuncture.com/2013/05/30/alex-osterwalder-and-friends-launch-business-model-canvas-game-dev-bootcamp/ Startup Juncture will cover the event and host an exclusive interview with Alex Osterwalder. Because ultimately the blog is all about our readers we have decided to crowdsource the questions for this interview. So if you have always wanted to ask Alex Osterwalder a question, this is your opportunity! Please post your question in the comments section. <comment><USER2> Suggested question: Business Model canvas (etc.) are about validating, learning, improving. Is he planning any improvements to the BMC, based on learnings in the past years?

<comment><USER3> Ha! That's a very good question. I like Ash Maurya's Lean Canvas better because he actually improved the BMC and has also made a few subtle changes to it since his book's first edition.

</comment></comment><comment><USER4> Top 3 things startups have to pay attention to when using the business model canvas in their daily operations?</comment>


HealthCare.gov Periodic Table of FEPS IT Bureaucracy  - <AUTHOR> http://photos.washingtonexaminer.biz/cache/r960-648499f36a67595d26f67cf181fe1345.jpg

<comment><AUTHOR> Slightly clearer version:

[http://i.imgur.com/fIbcj3K.jpg](http://i.imgur.com/fIbcj3K.jpg)

Does anyone have the original? Google cannot find it.</comment>


Ask HN: What would it take to move the Earth out of its orbit? - <AUTHOR> According to wikipedia, the Earth orbits the sun at an average distance of 149.60 million km.
Say we wanted to move the Earth slightly outside its current orbit so that its average distance from the sun was a full 150 million km.
What would that take?
In particular: would a collision with something really big, like the moon, or a dwarf planet, do it? How big would "big" have to be (say, in Earth masses)? Would the moon do it?
How about if a huge mass magically materialised on the surface of the Earth? Would that somehow knock the Earth out of orbit? If so, how big would that mass have to be?
I'm sorry but I can't reveal the real motivation behind my question. I am definitely not planning to build a doomsday device so that I can rule the world.
(Seriously, I'm just wondering and I'm not a physics geek so I don't know how to start thinking about this). <comment><USER2> Here is a relevant paper which may answer some of your questions: [https://arxiv.org/abs/astro-ph/0102126](https://arxiv.org/abs/astro- ph/0102126)

I've been slowly writing a paper about how to move planets by using repeated gravitational assists from masses moving in orbits which repeatedly cycle between inner and outer planets, conveying momentum from one planet to another. Unfortunately, I just don't have time to finish it right now. Feel free to email me if you want to discuss this stuff in more depth.

<comment><AUTHOR> Very intersting, thanks. This could make a great sci-fi story, btw.

<comment><USER3> There is a Chinese science fiction movie that is about this (although instead of slightly shifting the earth's orbit, they make earth a spaceship itself) called The Wandering Earth. I believe it is on Netflix. The subtitles for the theatrical release were not the best I've ever seen but it was a fun movie.

</comment></comment></comment><comment><USER4> You'd need an injection of delta-vee to move to an elliptical orbit where perihelion is the current distance, and aphelion is the desired distance. So you need to accelerate the Earth by some amount. When it gets to aphelion it's not moving fast enough to stay there, so you need another injection of delta- vee to increase the speed to maintain the new orbit. Note that the new speed in orbit is less than the old speed, despite adding speed twice, because the Earth will lost speed as it climbs up the gravity well.

Then you remember that Kepler's law is R^3 is proportional to P^2, where R is the distance and P is the period. So you can compute the new P based on the old P, and start doing sums from there.

Could probably be done on the back of an envelope with a little more work, but I'm not in a position to do so now. If you're serious, get no better answer, and can wait a day or two, email me.

<comment><AUTHOR> "If I'm serious"? You mean, serious about planetary anhiliation, right? :)

<comment><USER4> No, by "if you're serious" I mean about having an answer. Sometimes people ask questions on a whim and, after an hour or two, don't really care. But sometimes people really want an answer, so they are serious about finding out.

Equally: "... would a collision with something really big, like the moon, or a dwarf planet, do it?"

As always, it depends on the speed and direction, as much as the mass. But if it happened, I suspect we'd have bigger problems to worry about than what out new orbit would be.

Or no problems at all.

<comment><AUTHOR> Thanks for taking the time to answer. I think my curiosity has been satisfied. I did a bit of reading after posting the question here and it seems to me that the simplest way to move the planet out of its orbit would be to pull it by having something really large pass by it, rather than hit it directly with something very large. If I understand correctly, that seems to be the way that scientists think that rogue planets leave their solar systems and wander around. Collisions with large bodies seem to either result in moons being formed or planets breaking up completely?, so it seems that a collision is not a "safe" method to move the planet.

I'm not sure about mantaining the new orbit, rather than falling back towards the sun, as per your comment, but I'm guessing that if the Earth was pulled away from the sun by something as large as another star then it would just start falling towards that other star.

Anyway to be honest I didn't need an exact calculation, more a general intuition. But thanks for the offer :)

<comment><USER4> > _" I'm not sure about maintaining the new orbit ..."_

OK, so you give it a boost. Assuming you've boosting along the orbital path, it's now travelling exactly in the same direction as it was, but faster. Its new path is an ellipse that rises to a higher peak (aphelion), slowing as it goes, but when it gets there it has lost a lot of speed.

And in fact, it now doesn't have enough speed for that new, higher orbit (even though the speed for that orbit is less than the original), and because it's an ellipse that passes through that original position, it will not stay at this higher altitude, but will trace the second half of the ellipse back to the original position.

The magic term is "Hohmann Transfer":

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

Again, let me know if you want more, but I see others have made similar offers so I won't be offended if you don't ask.

</comment></comment></comment></comment></comment><comment><USER5> You have to add velocity to the earth along it's orbit to raise it.

Would the moon do it: Size does not matter (despite what my ex may tell you). You can accelerate a bowling ball by throwing a tennis ball at it hard enough. You can do the same with the earth and moon if you throw it hard enough.

Lets give it a whack to increase perihelios by 0.89M km so that we average 150M km and a more circular orbit. We'll need a velocity increase of about 0.33 km/s. If we assume that it's an inelastic collision we'd need to throw the moon at the earth at about 27km/s.

It's popular to measure energy in comparison to nuclear weapons. That is about 10E14 times the energy of the most powerful nuclear bomb ever designed.

You should dobule check my calculations before sending out RFQ for your doomsday device. If you just send this out to a contractor you will run the risk of looking silly to people who know what they're doing.

<comment><AUTHOR> Isn't there a danger that the Earth will just break up instead of accelerating it if you hit it with a very large mass moving at a very great speed?

<comment><USER5> Yes. The good news is that most of the mass will probably not reach escape velocity and eventually gravity will do the job of pulling it together.

</comment></comment></comment><comment><USER6> As someone who is building a doomsday device I am curious about this too.

</comment><comment><USER7> I'm pretty sure there's an XKCD what-if on this. Or ought to be.</comment>


Ask HN: Looking for prior art to prevent obvious patent - <AUTHOR> https://patents.google.com/patent/US20190034982A1/en?inventor=Chris+Bacon&oq=Chris+Bacon
I ran across this patent and it boggles my mind that it hasn't been rejected for failing the non-obvious test.  I would think it not novel either, as I would expect there to be a lot of prior art.  I wanted to submit something to help demonstrate prior art, but have had no luck finding something published, even though this to me, as a practitioner in the art, is drop dead obvious.
Essentially, the patent covers a browser requesting a list of events from a server, the server getting the events from a database, along with templates for displaying those events, then interpolating the templates with event values, and sending the result back to the browser. They are attempting to patent returning template value replacement on the server in response to a request for information from a client.
Anyone know of prior art that could be used to help prevent yet one more obvious software patent from getting issued?
FULL DISCLOSURE: I ran across this because I was working on something similar for a side business, and it blew my mind when I saw a company listing their patent pending "technology" of showing notifications based on templates. <comment><USER2> I wouldn't worry too much. This was filed on 7/24/18 and is still awaiting a first response from the PTO, which will almost certainly be a rejection.

You can check the status by searching the publication number US20190034982A1 on [https://portal.uspto.gov/pair/PublicPair](https://portal.uspto.gov/pair/PublicPair). Check the image file wrapper tab for updates. You'll see the rejection there as soon as the Examiner gets around to it.

</comment><comment><USER3> Might want to try here too [https://patents.stackexchange.com/](https://patents.stackexchange.com/)

<comment><AUTHOR> Thanks</comment></comment>


Apps Shouldn't be Free  - <AUTHOR> http://bobbyonboard.com/apps-shouldn-t-be-free

<comment><USER2> Totally agree, we should all start charging. As a user, I've become ridiculously cheap. And it's not the price, it's how the ecosystem has evolved. I'm used to free apps now. We need to get people to be used to paying for apps. Not easy though, will only work if everyone starts doing it...

</comment><comment><USER3> I find lack of a demo makes me avoid paying for things.

If there's a demo/lite version, I always buy the app if it's something I use even occasionally.

</comment><comment><USER4> I've been thinking the same thing for a while. The simplest argument in favour would be that people would immediately be much more careful in their selection. If I have to fork out money, I'm definitely not going to pick the buggy / low quality / app with dodgy permissions to the system, uses my location andor other data for ads revenue /etc. It means those apps wont have an audience and die off, because there's no incentive. And we'll all be better off...Not?

I'm so sick of all the crap that is out there, I wish I can just pay a fair amount and get an app that gets close to what I need, is of quality and without hidden agendas and issues.

Free is a funny thing, people's behaviour and expectations go out of whack. Even $0.99 is better than free. It's often better than $9.99 also. Free makes that people expect everything to be free, even quality software.

Quality software is hard to create. You cannot hold it to a developer if he gave it to you for free; he has no reason to really make it good...If you haven't actually put out software at a price, then you don't have first-hand experience of the responsibility it puts on you. The responsibility we need to create a better (app) world.

And if you want to throw the open-source argument, just remember free and open-source is not the same thing. If you're confused go read The Free Software Definition: <http://www.gnu.org/philosophy/free-sw.html>

I agree with previous comments, there should be atleast a trial period, I need to be able to figure out if this app will meet my needs.

</comment><comment><USER5> I think its fine the way it is. I've paid for some truly awful apps and regretted it. If I can download an app, get a feel for it, like it, then upgrade the basic features in it then I'm a happy customer. rather than having spent $7 on something I'll never use again and be bitter about paying for. (I can't really be bitter about wasting 69p but that does add up to quite a large amount after a while!)

</comment><comment><USER6> There's a crappy trend of releasing free games on the basis that you need to pay for gold/coins/credits to progress. This totally ruins the game for me. I would rather pay for a full game then the pay-for-progress model. In this case it isn't even about the money. It just ruins the experience for me because the game has a built-in cheat. You give money, the game becomes easy and you complete it.

</comment><comment><USER7> As a consumer i prefer buying apps. It gives the developer a better financial incentive to improve the product, plus i feel great since not only have i helped someone, i'm also going to get something which USUALLY works better than something just given away.

</comment><comment><USER8> Direct payment is not the only way to let customers pay for apps.

I pay for Google search with my permission to show me advertising. That is also payment, just a different kind.

I do not pay money for my desktop or my mobile operating system. Those are apps too, and the companies that invest in these systems do so mostly for commercial reasons. Great apps, but no direct payment.

"How much would you pay for a great news app?"

Depends on demand and supply.

</comment><comment><USER9> Apps market is completely full. There is much more offer than demand/need. Once "supports" are broken, in this case, when people get used not to pay, to make them pay again, something must change (offer, demand, rules). I'm an architect (real architect , not IT) and in this market it happens the same, people are not paying anymore for ideas, they only pay for project drawings. The competition (offer) is too high, if you don't do it somebody will.

</comment><comment><USER10> This would be great, but would never work. Unless you are working on some incredibly small niche OR your app is miles and miles ahead of the competition, people will gladly (read: stupidly) download a worse app for free rather than pay a small amount.

Also, this would be collusion at some level, woudn't it? :)</comment>


Algorithm No One Knows About (2016) - <AUTHOR> https://getkerf.wordpress.com/2016/03/30/the-best-algorithm-no-one-knows-about/ <comment><USER2> A bunch of comments here are missing the main point: Unless you have an Exabyte of memory, you can't use any kind of data structure to remember which cards you've already picked among 2^64 of them. The goal here is an algorithm that generates the selected cards, one by one, in order, as if from a coroutine that only uses a tiny, constant amount of memory. So, no arrays, lists, sets, hash tables, bitmaps, etc., even if they're hidden in some cute construct built into your favorite language.

<comment><USER3> Is there an easy way to adapt the algorithm to get the cards drawn in a random order? The article says "it's easy to randomize the order after the fact" but if we can't store them in memory then that's a no-go.

<comment><USER4> You select N from M, in order, where M is "too big" and N fits in memory / swap / disk. You then shuffle your N selections to get random ordering.

<comment><USER5> I understand "you can't use any kind of data structure to remember which cards you've already picked among 2^64 of them" as "N cards don't fit in memory". Or is the relevant distinction memory vs disk, as it's feasible to randomize on- disk data?

<comment><USER6> The problem asks to find k cards (integers) out of n, in time O(k) and O(1) additional space — this means additional to the k required to store the output. So while holding n items wouldn't fit in memory, it is implicit that k would. But we still want to avoid Ω(k log k) time, or more than a constant amount of additional space.

</comment></comment></comment></comment></comment><comment><USER7> The last time I wanted an unpredictable, non-repeating sampling of 64-bit numbers, I used a symmetric cipher in CTR mode. Essentially, start with a random key and a random value, return the encrypted version of it, then the encrypted version of its increment, and so on. Returns every number in the range, with no predictability.

<comment><USER8> This works, but only if you're sampling the exact same space as the block size. For example, if your cipher outputs 64-bit blocks, but you want to sample in 2^32, you're back to the drawing board, because there's no way to truncate the cipher output without risking duplicates.

<comment><USER9> You can use the "hasty pudding trick" to truncate the cipher output without risking duplicates. It is inefficient if the block space of the cipher is much larger than the sampling space, though.

However, you can also use a Feistel network to create a block cipher for an arbitrary bit length. So, you can always bound the block space to be no more than twice the sampling space, which is okay.

<comment><USER10> What's the hasty pudding trick? Is it related to the Hasty Pudding cipher?

<comment><USER9> It is. Perhaps it's not officially called that, but that's how it was described to me:

[https://groups.google.com/d/msg/sci.crypt/gjYclOVJDrc/tiv4ic...](https://groups.google.com/d/msg/sci.crypt/gjYclOVJDrc/tiv4icJyJZMJ)

</comment></comment></comment></comment></comment><comment><USER3> >The misleading part in using the language of cards is that you don't often consider a deck of size 2^64. What's nice about the card formulation though is that it conveys how simple the problem statement really is. This is a fundamental problem that was open for a long time. Nobody knew how to deal cards.

>The first obstacle that makes the "dealing" (without replacement) hard is that the "draw" method doesn't work. If you draw (with replacement) over and over again, ignoring cards you've already picked, you can simulate a deal, but you run into problems. The main one is that eventually you're ignoring too many cards and the algorithm doesn't finish on time (this is the coupon collector's problem).

How is this true? If you're drawing from a deck of 2^64 cards then unless you're drawing almost all of them there's not going to be any problem with rejection. Even if you're drawing 2^63 cards you're going to be rejecting only half of your draws, so the average slowdown is just a factor of 2.

If you really want to draw more than half the deck then just randomly pick the cards that you _don 't_ want.

<comment><USER11> > How is this true? If you're drawing from a deck of 2^64 cards then unless > you're drawing almost all of them there's not going to be any problem with > rejection. Even if you're drawing 2^63 card you're going to be rejecting > only half of your draws, so the average slowdown is going a factor of 2.

It it though? I'm a but shoddy on my mathematics, but I'd wager from the birthday problem that you'd probably have to reject much more than half of the 'cards', and as you get to the end, you'd have to redraw several times for each card.

<comment><USER12> Birthday problem says that once you've gone through ~2^8 cards you've got a ~50% of having had to reject at least once. It takes 2^63 until you have a 50% chance of rejecting on _each_ draw.

<comment><USER13> You're right, but it's not 2^8. It is √2^64 = 2^32.

<comment><USER12> Yes, thanks. Took the root of the wrong number.

</comment></comment></comment></comment></comment><comment><USER14> Some of the variable names used:

i, j, t, qu1, S, n, N, U, X, y1, y2, V

I know others have already commented on this but I think it's worth laying out all of the cryptic variables and asking: are some of these shorthand for well known math concepts that make it unnecessary to have a more descriptive name? I understand the use of temporary value holders like `i`, but have no clue what some of the others might be used for or what the single letter names indicate.

Another way to ask the question: if the author had just used instead a, b, c, d, e, f, g, h, etc. what information would be lost, that is gained by the particular letter choices that were used? This isn't rhetorical, although there is a point to be made for sure about clarity in naming... I'm really wondering if anyone can explain what these letters might mean if you are more versed in the math than I am.

BTW here's another Vitter paper I found in case anyone's interested:

[https://www.cs.umd.edu/~samir/498/vitter.pdf](https://www.cs.umd.edu/~samir/498/vitter.pdf)

<comment><USER15> The reason for naming the variables as they are seems to be to keep consistency with Vitter's paper [[http://www.ittc.ku.edu/~jsv/Papers/Vit87.RandomSampling.pdf](http://www.ittc.ku.edu/~jsv/Papers/Vit87.RandomSampling.pdf)] Since the paper is really the primary documentation of the algorithm this makes perfect sense. Renaming the variables to be more meaningful to you would make it harder to compare to the paper, reducing the effectiveness of the paper as documentation and making it hard to compare the code to its specification.

<comment><USER16> There's no reason to preserve bad notation from a 30year old paper.

<comment><USER17> Are you saying that single-letter variable names in maths is "bad notation"?

</comment></comment></comment></comment><comment><USER18> It's called Reservoir Sampling [https://en.wikipedia.org/wiki/Reservoir_sampling](https://en.wikipedia.org/wiki/Reservoir_sampling)

I was just re-reading this yesterday! I think a lot of the Monte Carlo rendering people know about this family of algorithms, and the idea is pretty simple. I'm not sure why it's described from the start as picking k samples though, I find it a lot easier to understand and see how it works when you start with k=1.

Btw, it's fun to work out the probabilities of picking a sample to prove how this algorithm works, and that it's uniform. Big piles of factorials that all cancel out.

Pps the other super rad algorithms that aren't well knows are the alias method for simulating a discrete distribution [https://en.wikipedia.org/wiki/Alias_method](https://en.wikipedia.org/wiki/Alias_method)

...and the suffix array, which is crazy surprisingly useful [https://en.wikipedia.org/wiki/Suffix_array](https://en.wikipedia.org/wiki/Suffix_array)

<comment><USER19> Reservoir sampling requires you to maintain a reservoir of n items that will be your sample. This can be prohibitive if the sample size itself is huge. The algorithm described here decides (commits) whether an item is to be sampled as it sees it (i.e., online), while consuming a constant amount of memory. It differs from the usual reservoir sampling approach in that it cannot go back and "unsample" an item it already selected (whereas the crux of a reservoir sampling approach is evicting current candidate items and replacing them with new items).

</comment></comment><comment><USER20> While reading, I was thinking about LFSR [0] with suitable properties and period. Not strictly random, although LFSRs are commonly used for generating "random" numbers.

[0]: [https://en.wikipedia.org/wiki/Linear- feedback_shift_register](https://en.wikipedia.org/wiki/Linear- feedback_shift_register)

<comment><USER21> Exactly my thoughts - its wolfenstein fizzlefade or LSFR that you learn in crypto 101 that can pick all the numbers in the range randomly.

"Algorithm No One Knows About" is such a condescending title...

<comment><USER22> Especially if you don't actually explain the algorithm and seemingly fail to understand its single most important requirement is that the output is _in order_. Not something to shuffle later, because the only advantage of this algorithm is that the output remains in order.

Otherwise you use a permutation function, such as an LSFR or preferably a family of functions.

</comment></comment></comment><comment><USER23> Getting this wrong can tank your product - see what happened to Draw Something [http://epeus.blogspot.com/2012/04/draw-something-ceo- grace-a...](http://epeus.blogspot.com/2012/04/draw-something-ceo-grace-and- high.html)

<comment><USER24> Summary without the drama: by not using a "discard pile" but picking randomly from the same set of words every time, you get repeat words paradoxically often (birthday paradox), which is what pictionary did and people complained about.

</comment></comment><comment><USER25> Here is how I would do it. Pick a prime p bigger than N. Pick a random permutation of Z/pZ. Pick an initial state. Advance to the next state, to cycle through all the values exactly once.

You use rejection sampling if the state is greater than N, so as long as you pick p close to N this should happen very rarely and be amortized O(1).

If N is big this advance to the next state can be encoded easily as a multiplication by an element of Z/pZ (multiplication followed by modulo p), and you will cycle through all the values because Maths. If N is not so big you pick a few (m) elements of Z/pZ to represent your permutation, and you use the first number as a multiplier mod p the first time, then the second number as a multiplier mod p the second time, and so on..., and you will also cycle through all the value, because Maths as long as you don't get a 1 while multiplying sequentially your m elements.

Don't forget to stamp it good enough(TM), if not use Dual-ECC.

</comment><comment><USER26> Okay, so this is a way to generate a sampling in order, so you don't have to keep a sorted list and your run time can be k instead of klogk. Mostly.

The body of the post, with its talk of strict timing and sample bias, had me thinking it had some clever way to pick a random number from 1 to n in finite time. But that's not actually possible to do with a random bit source and a non-power-of-two n. If this algorithm hits certain rare values it will re- sample the RNG.

<comment><USER27> This appears to be the state of the art in minimising the resampling cost:

[https://arxiv.org/pdf/1805.10941.pdf](https://arxiv.org/pdf/1805.10941.pdf)

</comment></comment><comment><USER28> I may be misinterpreting the question here but can't the author just use a large prime to to pull from the array like you would when hashing? Its how you would in place shuffle a music playlist.

</comment><comment><USER29> Oh dear, I find those single-letter variable names are quite counter- productive in making the code easy for someone unfamiliar to the project to understand...

<comment><USER30> Yeah, I'm way out of my comfort zone here but I found the choice of n and N pretty off-putting

<comment><USER29> A typo is only a (sticky) shift away, and not even obvious!

EDIT: ...and compiles, too!

</comment></comment></comment><comment><USER31> Can't you use [https://en.wikipedia.org/wiki/Lehmer_random_number_generator](https://en.wikipedia.org/wiki/Lehmer_random_number_generator) for this? I thought that was a common method of generating a random sequence without repetition. True, the result is not very random, but in most applications it doesn't make much of a difference.

<comment><USER32> Not if you want it to be actually random.

But you might be correct if you simply want the appearance of randomness.

</comment></comment><comment><USER22> > When I came across a need for the algorithm in my work, it took a lot of > detective work to even find it. There was no source code online. The > algorithm is not referenced often, and when it is, it is in a highly obscure > fashion.

Well, the author certainly isn't helping that problem with a clickbait title like that, and being all mysterious for the first few paragraphs, teasing "you almost certainly don't know this".

"Dealing cards from an extremely large deck: Vitter's Algorithm"

Except he doesn't even explain the algorithm, just some source code (which is super unclear, no comments, short variables). And the unhelpful comment that it was hard to figure out from the paper. All the reason to put a more descriptive title.

How does he expect to help people find this, figure this out, or was this entire post just to brag that "his" solution is better than anyone else's because he found the right algorithm almost nobody else knows about?

</comment><comment><USER33> Ok I'll take a shot at it.

Pick a number between 0 and N. Let's call it p for pivot. Each draw after this initial draw is either less than p with probability p/(N-1) or greater than p with probability 1-p/(N-1). You need to make k-1 additional draws. The probability of m of those draws being less than p is given by the binomial distribution. Choose m from the binomial distribution. Then run the algorithm recursively on the space 0 to p-1 and p+1 to N. Some pseudo-code.

        def deckpicker(N,k,offset=0):
            if k == 0:
                return
            p = uniform_dist(0,N)
            m = binomial_dist(k-1, p/(N-1))
            deckpicker(p-1,m,offset)
            print(p+offset)
            deckpicker(N-(p+1),(k-1)-m,offset+p+1)

<comment><USER34> What's the time complexity of sampling from the binomial distribution?

<comment><USER33> well...shit.

</comment></comment></comment><comment><USER35> [https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle](https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle)

<comment><USER18> It's related to Fisher-Yates shuffle, [https://en.wikipedia.org/wiki/Reservoir_sampling#Relation_to...](https://en.wikipedia.org/wiki/Reservoir_sampling#Relation_to_Fisher- Yates_shuffle)

But it's not the same thing. The difference is whether you can keep all samples in memory at the same time. With Vitter / reservoir sampling, you only need to have your reservoir in memory plus enough space for 1 new sample at a time, so you can stream through a large number of samples with a tiny amount of memory.

</comment></comment><comment><USER36> Why is hashmap not good enough for unique ID generation?

        const tweetIDs = {};

        while(TWEET_COUNT){
            const rnd = Math.random() * MAX_TWEET_ID;
            if(!tweetIDs[rnd]){
                tweetIDs[rnd] = true;
                TWEET_COUNT--;
            }
        }

<comment><USER37> The algorithm described in the article has other desirable properties:

* IDs are returned in sorted order

* IDs are generated one after another, ie could be implemented as a generator or coroutine

* No additional space required during the computation

Resulting in a single pass.

<comment><USER29> Nicely said.

I was thinking of ways to solve the problem by eliminating the overhead of checking whether a random number was already drawn, when Vitter's solution was to make the random number generator produce random numbers in a sorted manner, thus eliminating that overhead entirely.

EDIT: Then again... if the algorithm is to be used to shuffle a list, wouldn't returning the selection in a sorted manner defeat the entire purpose? If k = n, output would be input...

<comment><USER36> It would. The original problem is to draw a subset of tweets.

If there's a chance to randomize the entire tweet archive, then it's a shuffling algorithm now.

</comment></comment></comment></comment><comment><USER38> "Here's a program roughly 0% of programmers know how to write: generate a list of random tweets, without duplication.

[…]

Stated more formally: given non-negative integers _k_ and _n_ with _k <= n_, generate a list of _k_ distinct random numbers, each less than _n_."

I think that knowing _k_ beforehand makes it a different, easier problem. I don't see how, if you don't know _k_ beforehand, you can do without enough memory to store a number of magnitude _n!_ , and even that would be extremely slow, the more items you have to produce (uniformly pick a permutation of _n_ items, and produce as many of them as requested)

<comment><USER39> I don't see why you'd need to generate a permutation?

<comment><USER38> If you don't know _k_ beforehand, you have to (eventually) handle the case where _k_ is large, possibly even equal to _n_.

If it turns out to be equal to _n_ , you have to generate a permutation.

If it isn't, you don't need to, but you need to keep enough information around, in case it turns out that you need.

For example, by the time you've generated 2⁶³ integers in the range 1…2⁶⁴, you need to know which 2⁶³ integers still are 'available'.

I think you can't do that more compactly than by just picking the permutation to generate at start (whether you can efficiently determine the k-th number in that permutation is a separate problem)

</comment></comment></comment><comment><USER40> So let me get this straight...

This algorithm creates an initially empty array of size K with the DB internal ids of what would randomly be selected. Then it goes in order from 0 to the number of rows - 1, and for each one it goes e.g. "What are the chances that number 0 would get randomly picked out of N items if K items need to be picked?" Then, if the #0 passes the "random check", it gets added. Then it would go to 1 and go "What are the chances #1 would be picked out of N-1 items if K-1 items need to be picked?" ...and repeated so on until all K random items have been picked?

<comment><USER41> No, what you described is O(n).

</comment></comment><comment><USER42> "(Stated more formally: given non-negative integers k and n with k <= n, generate a list of k distinct random numbers, each less than n. We reasonably ask that this be done in O(k) time and O(1) additional space. Finally, the distribution must be uniform.)"

"...it's also possible to use the language of cards: deal k cards from a deck of size n, without replacement. So a poker hand like A2345 of clubs is valid for k=5 and n=52, but a hand containing AAAAA of clubs is not."

These seem to be fairly straight forward problems to solve- can anybody ELI5 why the Vitter algorithm is necessary?

<comment><USER43> Trivial algorithms (like one implemented in Python) slow down when k is close to n. Or when n is large, then it is not possible to use bitmap to mark dealt cards.

<comment><USER44> The python algo does not get slow when n is large. The k~n case obviously calls for inverse selection.

[https://github.com/python/cpython/blob/master/Lib/random.py#...](https://github.com/python/cpython/blob/master/Lib/random.py#L386)

<comment><USER45> NOTE: This comment I wrote is totally wrong. I haven't had my morning coffee yet. H_n - H_(cn) ≈ constant, not diverging (for 0 < c ≤ 1). :)

Yeah, but the k ~ n/2 case (in which inverse selection and normal selection have the same runtime) is still Ω(n log n) (equiv Ω(k log k)), which is still "slower" than the presented algorithm.

<comment><USER34> Actually, this comment is correct despite making a similar argument to your incorrect one elsewhere. Using a set to accumulate intermediate results requires k inserts at O(log k) each.

<comment><USER45> I'm still not sure about this—the amortized time of insertion should be O(1) on any one of the usual hash table-type-structures. We're not inserting a single item to an already-built hash-table, but rather k of them into an empty hash-table, with elements being uniformly drawn and bucketed using a good hash function. All of this should give O(1) average time for insertions.

</comment></comment></comment></comment></comment></comment><comment><USER46> And I still don't know about it, because the article just has a code dump and some vaguely relevant historical commentary. Posting the actual paper would have been better.

</comment><comment><USER47> > given non-negative integers k and n with k <= n, generate a list of k > distinct random numbers, each less than n.

> We reasonably ask that this be done in O(k) time and O(1) additional space. > Finally, the distribution must be uniform.)

Sounds like the Knuth multiplicative hash.

The Art of Computer Programming vol. 3, section 6.4, page 516.

</comment><comment><USER48> Tldr of the algorithm from the paper:

Instead of choosing random numbers to include in the list, they're choosing the gap between numbers. They derive the distribution of this gap then approximate it so it can be calculated quickly.

</comment><comment><USER49> If this really was such an obscure but useful algorithm, someone should change the title of this post to help people find it in the future so it doesn't remain obscure (add "card drawing"?)

<comment><USER45> It's... not that useful, as far as I can tell (unless I'm still under- caffeinated!)

@avip mentions the following comment [https://news.ycombinator.com/item?id=20961320](https://news.ycombinator.com/item?id=20961320) , which means that we only have to consider k ~ cn for 0 ≤ c ≤ 1/2\. Drawing in this fashion, we have an expected runtime of k * (H_n - H_{(1-c)n}) ≤ k * (H_n - H_{n/2}) ~ O(k).[1]

The latter is true since H_n ~ log n + C + O(1/n) for some[2] constant C.

Of course, depending on what the author's constraints are, there would be an additional O(k) space requirement for keeping track of indices that have already been picked. Vitter's algorithm is particularly nice, since it can report the items without this additional space requirement.

\---

[1] [https://en.wikipedia.org/wiki/Coupon_collector's_problem](https://en.wikipedia.org/wiki/Coupon_collector's_problem)

[2] [https://en.wikipedia.org/wiki/Euler–Mascheroni_constant](https://en.wikipedia.org/wiki/Euler–Mascheroni_constant)

</comment></comment><comment><USER50> I haven't read the algorithm code, but I think you can do the following? For n items, pick a random k <= log(n!), then enumerate the k'th permutation of n items. It's not trivial, but there are already algorithms for it, e.g.: [https://code.activestate.com/recipes/126037-getting-nth- perm...](https://code.activestate.com/recipes/126037-getting-nth-permutation- of-a-sequence/)

<comment><USER45> Ooh, this feels like it gets close to the solution!

It's not quite there as stated, though, since this algorithm requires O(k^2) time (where k is the number of elements to be randomly drawn) as you have to insert items into specific indices in the array.

<comment><USER50> Yeah, but I think you can be more clever than just doing naive array insertions, by trying to batch them up. At least, we know decreasing sequences of indices can be done in one pass with no changes, and increasing sequences can be done in one pass by accumulating shifts. That leaves alternations to worry about. Now I haven't fully thought this through, but I think something along these lines might work (there may be errors in some of the details here): treat the list of indices you're inserting into as the leaves of a binary tree, and create the intermediate nodes of that tree, initializing them to zero. The intermediate nodes represent offsets (initialized to 0) that will be logically added to all earlier nodes. Then sort the nodes, breaking ties so that the later ones are first. Now perform every insertion at {the given index plus its ancestors}, and then increment the counters for all ancestors of that index so that you account for shifts of later elements. This should get you to O(k log k) or so.

In fact, this makes me wonder why there isn't a multi-insert function in every language's vector implementation...

</comment></comment></comment><comment><USER51> I remember an article about the space complexity of drawing all colors randomly.. this seems related, isn't it ?

</comment><comment><USER52> Does anyone have a mirror for this? No matter what I do, all I'm getting is an empty page with a sidebar.

<comment><USER53> In Firefox: View -> Page Style -> No Style

(For whatever reason the page has a CSS rule #content { display: none; }, which presumably gets removed via JS.)

</comment></comment><comment><USER54> Anyone feel like doing a human readable breakdown of what the algorithm is going?

That would make me happy

<comment><USER55> Yeah, really. A lot of filler paragraphs building up to unreadable code. Bad article.</comment></comment>


Ask HN: Are companies open to a 4-day work week? - <AUTHOR>

I've been experimenting with a 4-day work week at my current employment.  I'm curious if any other employers are open to that kind of arrangement. <comment><USER2> In practice, _every_ company is open to a 4-day work week, if you're valuable to them and the alternative is losing you. Some companies are just more likely to extend the same benefit to everybody.

Definitely do it, by the way. I dropped down to 4 x 8h when my second son was born, and simply never switched back. My quality of life is a lot better now, I don't seem to ever get sick anymore, and I get 3-day weekends every single week.

Way better than having an extra few grand on a paycheck.

</comment><comment><USER3> Many are, but unfortunately not all.

I've worked 32 hour weeks (with occasional overtime) for most of my working life, I think. I've never had a 5 day work week since 2009, and I don't quite recall my work weeks from my first few jobs (2001 - 2008), but I think those may have been 4 day weeks too. My brother had also always worked 4 day weeks, since the early '90s, I think.

But I have also worked a 5 day week for at least a year, and I've turned down a job at a company that totally understood my desire for a 4 day week, but still only wanted to hire me for 5 days.

All my freelance gigs (since 2012) have also been 4 days or less, though my current client cannot accept less than 32 hours per week for some odd reason.

But this is in Netherland. I'm sure it's different in other countries.

</comment><comment><USER4> My former employer offered us 4 x 10h which reduces the commute to work, vehicle wear and tear, mileage and offers 3 day weekends. On the other hand, the 10h days can put a toll on your health when sitting at a desk for that long.

4 x 8h is a good idea as long as you can maintain the level of productivity. Given the competitiveness of the marketplace 4 x 8h might not work unless you have extra employees to fill in the 20% void.

Another factor to consider is your location. If you're getting paid 80% of the full time income and you live in an expensive city, you might find it difficult to adjust your lifestyle. Usually when you're not working (earning), you're spending.

In the end it's all about balance.

</comment><comment><USER5> In the EU, they all must be open to it. [http://europa.eu/legislation_summaries/employment_and_social...](http://europa.eu/legislation_summaries/employment_and_social_policy/employment_rights_and_work_organisation/c10416_en.htm) (from 1997):

 _" In respect of employment conditions, part-time workers may not be treated in a less favourable manner than comparable full-time workers solely because they work part-time, unless different treatment is justified on objective grounds. [...] social partners and/or Member States after consulting the social partners should identify and review obstacles which may limit the opportunities for part-time work and, where appropriate, eliminate them."_

Such directives get translated into law in different ways in different countries, but the overall message is clear.

</comment><comment><USER6> Several people at my workplace have gone down to a 90% work week, taking every other Friday off. The 10% pay cut is small enough to not really notice, but the positive effect of the extra day off every other week is huge. Once my current backlog of work has been cleared I'm considering trying it myself.

<comment><USER7> We do that at the company where I work, for creatives and developers (but not project/client admins, who need to be to clients during regular business hours).

We call it a 9/80 schedule (9 days, 80 hours), and it doesn't require a pay cut, or a reduction in the number of hours worked.

We work 9 hour days, 4 days per week and then we alternate between having the remaining day off and 8 hour work days. We also stagger the our days off, so that any department is never down a significant number of people.

It works really well. We arrive 1 hour before anyone else, so that hour of uninterrupted work is very valuable. There is some pushback from a particularly unorganized Account Leader, but I think everyone understands why that pushback exists.

</comment></comment><comment><USER8> Obviously some are, some aren't.

It depends heavily on how those four days are managed, the nature of what you specifically need to be doing while "on duty", etc.

Reasonable companies will recognize that an efficient 32 hours can be as productive (or more so) than an inefficient 40 hours. The trick is to show that this is the _reality_ of what happens.

If you can generate empirical evidence supporting the same, it should be an easy sell. Good defect and task tracking can help with this.

</comment><comment><USER9> My previous employer was. Getting Wednesday in addition to the weekend off was the best schedule I've had in my life.

</comment><comment><USER10> Ryan Carson blogged about the 4-day work week at Treehouse: [http://ryancarson.com/post/21708810513/4-day- week](http://ryancarson.com/post/21708810513/4-day-week)

</comment><comment><USER11> The standard 5 day week in Australia is 37.5 hours. Our organisation has many people that work only 4 days at 30 hours.

</comment><comment><USER12> Do you mean a 40 hour 4 day work week or a 32 hour 4 day work week? I'm all for the latter.

<comment><AUTHOR> Either

<comment><USER13> they're quite different though. One is just squeezing a 5 day week in to 4 days. The other is only working 4 days worth of hours.

<comment><USER8> I don't think anybody is questioning the math, I think the OP just doesn't care which. Some employers want people to be "on duty" five days a week.

</comment></comment></comment></comment><comment><USER14> I think,it is not possible for the companies in consulting or services business.

</comment><comment><USER15> I would be in, but not if my paycheck was reduced.</comment>