Marilyn vos Savant and the Monty Hall Problem - <AUTHOR> http://priceonomics.com/the-time-everyone-corrected-the-worlds-smartest/ <comment><USER2> My crack at it...

1/3 chance prize is behind a given door. Pick a door, you've got a 1/3 chance it's behind it.

But there's a 2/3 chance it's behind one of the other doors.

So you've got two sets of outcomes at this point. Set A has 1/3 probability (the door you chose). Set B has a 2/3 probability (the two doors you didn't choose).

You then get this incredibly valuable information. The door in Set B that doesn't have the prize. So now Set B _still_ has a 2/3 probability of having the prize. But you know that higher probability now applies to only the _one_ door in Set B.

So you end up with: Set A door = 1/3 chance | Set B door = 2/3 chance

Make the switch every time.

<comment><USER3> I've known the answer to the Monty Hall problem for a long time, but this particular explanation just so happens to be the first one that's brought me closer to grokking the answer. I dunno what's different about this one, but it makes sense to me. Congrats.

<comment><USER4> I think that the key sentence in his explanation is "So now Set B still has a 2/3 probability of having the prize." This really nails the whole thing down.

</comment></comment></comment><comment><USER5> An intuition pump for the problem, especially if you know about conservation of expected evidence [1], is that the asymmetry between the door you picked and the other door that wasn't opened is that the other door _passed a test_. The door we choose got a bye; we learned nothing about it's ability to win car-containing contests. The other door was at risk, and survived. We gained information about it.

1: [http://lesswrong.com/lw/ii/conservation_of_expected_evidence...](http://lesswrong.com/lw/ii/conservation_of_expected_evidence/)

<comment><USER6> This was the clearest explanation in my opinion. I'm still a bit confused regarding how much information have we actually got and what mechanism is behind "passing a test" to influence the amount of information when the test result is not definitive (as in this case). We were just given a complete information about one of the options the user didn't choose, but not any direct new information specific of the door the user didn't choose and that remains closed.

Imagine that after opening the door everyone goes home and a new participant who has no knowledge of the previous experiment is called to make a decision between the two remaining doors. Obviously in this case the probably is 1:2, as there is no information regarding the previous test. Actually, if we imagine a similar situation happened before the initial problem with a previous show with 4 doors, we may as well see that the initial probability of 1:3 is also wrong if we had access to the knowledge about the previous experiment.

I still agree with the switch suggestion, but the mechanism behind it is still not entirely clear.

A more intuitive example would also be to invert the problem: leave one of the non picked doors (C) out of the random opening and use the door the contestant picked (A) as a possible case in the random opening experiment. If we start by opening A, then we already know enough to see if the user won or lost, if we open B and there is the car behind it, we already know everything. If we open B and there is a goat behind the door, consider whether you would switch your choice from A to C. I guess you probably wouldn't and it would feel easier to justify your position, as this doesn't involve the "psychological pain" of changing a previous choice by reasons that you don't entirely understand (associated with possible loss-aversion feelings).

</comment></comment><comment><USER7> She went on later to talk about the Tuesday's child problem, which is even more interesting and confounding.

 _I have a friend who has two children, he has a son born on a Tuesday, what is the probability his other child is a girl?_

Compared with this problem

 _I have a friend who has two children, one I know is a boy, what is the probability the other child is a girl?_

And this one

 _I have a friend who has two children, the oldest is a boy, what is the probability the other child is a girl?_

Why do these three probabilities differ (in particular, since the last two may be more obviously different, why is the first one equal to neither of the others)?

I spent the best part of a week in grad school pondering this until I came up with a deeper intuition. But the results are still surprising, I think.

<comment><USER8> My intuition is totally failing me here, because I can't get over the 1/2\. If I have a friend who has one child, and he's about to have another, what's the probability that it will be a girl? Clearly 1/2\. What's the difference between asking any of these questions and the one I just asked? I can't find any difference.

<comment><USER7> Right, that's the last case. The eldest is a boy (or a girl, it doesn't matter), so the younger is equally likely to be either.

The middle case is 2/3 likely to be a girl. Think of the possibilities of the sex of two children (sex given in birth order) M then M, M-F, F-M, F-F. I tell you one is a boy, so we have MM, MF, FM, in two of the three cases, the other is a girl.

In the first case the answer is 14/27 a girl, so almost 1/2, but not quite. To figure this out you can consider all 196 combinations of two children with birth-days-of-the-week, cross out all those that don't match the phrase "he has a son born on a Tuesday", and you're left with 27 possibilities: 14 of them are when the other is a girl (14 because she could be born first or second, and on any day of the week 2x7=14), and 13 when the other is a boy (6 when the other is an older boy born on a non Tuesday, 6 when it is a younger boy born on a non Tuesday, and 1 when both are both on a Tuesday).

So that's not the intuition, as much as the answer.

The intuition is that as you add more specific knowledge about which child you mean, that question contributes less to the probability of sex, and is more an irrelevant detail. Being more specific can be anything. Do it with birthday- of-the-year, (more specific than day of the week) and it is even closer to 1/2\. Do it with something unique, like their phone number (or their birth order, or 'the taller one is a boy') and it is exactly 1/2\. Be less specific, make it so they both toss a coin and it is 'one of the children tossed heads and is a boy' and it is 3/7.

<comment><USER8> Maybe I begin to see the light. First, there is an important difference between considering a random event on it's own and several random events together: in essence, when your friend says they have a boy, he is telling you a little something about _two_ ordered events. That's why you count the BF and FB cases separately (which is the counter-intuitive part).

The actual Tuesday problem requires a little more thought. Somehow that extra information makes you drop a case! I can't help but think that the ordering is the critical factor, and that it's not a coincidence that the "extra information" has to do with time. In other words, the dropped case happens because we drop the distinctive ordering when the two boys are born on a Tuesday.

<comment><USER7> You picked up on a really important issue that is often assumed. Thank you for not letting me just slip it under the radar without question.

To answer your question: we treat the MF and FM differently, just for ease of calculation.

What we're doing is taking a set of possible situations (different 2-child families), each with an attached probability (I'll come back to this), throwing away those that don't match some known information (i.e. those without a boy), taking those that do, grouping them into sets (the set of families with the other being a girl, and the set where the other is a boy), and calculating the probability the actual scenario was in each of those sets.

Now the 'attached probability' probably sounded odd in there, because that's not what we've done, right? We've just been counting situations. True, but that's because we carefully started with situations that are all equally likely. So rather than bugger about with those attached probabilities, we could just use raw counts, knowing that it would work.

So, if we start with four possible sexes of two children: MM, MF, FM, FF, those are all equally likely. I'm using the birth order as a way of breaking the two MF cases apart, so I've got two cases that are equally likely, letting me do the counting trick. I can just count the 2 out of 3 remaining situations that match the information, so 2/3\. Easy.

But I don't have to do it that way.

Let's say we follow your intuition and start with three possible sex combinations: MM, MF, and FF. Now, those aren't equally likely, right? There are twice as many families with MF children as with MM children. So I need to use the attached probabilities.

MM (1/4 of 2-child families), MF (1/2), FF (1/4)

We can remove the FF as inconsistent with the information (as before), then the probability the parent has an MF family (i.e. their other child is a girl) is

1/2 over (1/2 + 1/4) = 2/3

as before.

In fact, for any reasonable calculation based on data, we're almost certainly not going to be able to use the counting trick. In the case where I was using actual birth rate statistics for sex (rather than assuming as many girls as boys are born), I'd have to do it this way. The counting trick is really only useful for toy problems and teaching basic probability: you were right to call me out on it.

\---

The Tuesday's child doesn't drop a case. There are certainly seven cases where, in an MM family, the eldest is a Tue child, and seven where the youngest is, but one of those cases is shared: a case where both are Tue children.

In terms of the intuition you can think of it this way, identifying by birth- day-of-the-week is identifying which child is which, so we're almost at 1/2, but there is one case (both Tue boys) where this information does nothing to distinguish them, so that tiny bit of ambiguity remains, and it can't quite reach the full 1/2, there's still a trace of the 1/3 result that came when the ambiguity was total.

</comment></comment></comment></comment></comment><comment><USER9> None of the explanations in the article really convinced me either. But after looking at the chart of all possible outcomes for a while, it finally clicked. It makes more sense to think of it in reverse from the winning position.

Winning by switching doors requires your first choice to be incorrect.

You have a 2/3 chance of guessing incorrectly when all three doors are closed.

Thus, you have a 2/3 chance of putting yourself in the position from which switching will win.

</comment><comment><USER10> I felt pretty stupid when it took me a long time to convince myself of the correct answer. But I felt better when I read that even "Paul Erdős, one of the most prolific mathematicians in history, remained unconvinced until he was shown a computer simulation confirming the predicted result"!

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

<comment><USER11> The only explanation that convinced me that my original guess was incorrect was this one (which is alluded to in the article):

If there are three doors, the odds that the car is behind any of them is 1 in 3, or 1/3\. Once you select a door, the odds are 1/3 for your door, 1/3 for each of the other, unselected doors. Put more simply, 1/3 for your door, or 2/3 that it is _not_ in your door. Once another door is opened that does not have the car, then the odds of it being your door are 1/3, and the odds of it not being your door are still 2/3, so it makes sense to switch.

<comment><USER12> Thank you. Adding the temporal domain and system states is what makes this easy to understand.

At the time of selection you freeze the probability of the sets (as this is the macroscopic world and the implications of the state in the other rooms must have collapsed due to interactions with all sorts of radiation from the rest of the universe).

Thus what you say is exactly correct.

* T0 - {1/3} {1/3} {1/3} * T1 - {1/3 Your pick} {2/3 = {1/3} + {1/3}} * T2 - {1/3 Your pick} {2/3 = {0/3 Host Pick} {2/3 Remaining door}}

</comment></comment></comment><comment><USER13> So I _believe_ the 2/3 answer to be true. I see the evidence in those tables. But intuitively, I still don't get it, and the explanation in the article isn't helping

> The short answer is that your initial odds of winning with door #1 (⅓) don't > change simply because the host reveals a goat behind door #3; instead, > Hall's action increases the odds to ⅔ that you'll win by switching.

Well, why don't they change simply because the host reveals a goat? If you show me a three sided coin, I'd say there's a 1/3 chance of getting a particular side. If you then magically change gravity such that one of the other sides will never ever be landed on, would the two remaining sides not now have 50/50? I guess the article asserts that the "probability" doesn't get redistributed amongst the remaining options evenly, and I want to know why it doesn't and why it instead all "goes" to the one I didn't pick.

I don't mean to be confrontational in asking, and I don't doubt the answer, I just don't get _why_. Could anyone explain it better, or point me somewhere that does?

<comment><USER14> The way I like to think about it is as follows: You pick door 1. Out of three doors you have a 1/3 chance of having a car behind your door. The chance that the car is behind one of either of the other two doors is 2/3\. Let's pretend that instead of opening a door and revealing a goat, Monty instead says to you "You can switch to both of the remaining doors. If the car is behind either one of them you get to keep it." Your likelyhood of getting the car by switching is now 2/3.

Instead, Monty does the statistical equivalent: He allows you to know for sure which of the other doors definitely has a goat.

<comment><USER15> This is a great answer.

To answer the question about the 3-sided die: the question is flawed for 2 reasons.

First, the way you phrased it, you know the information a priori. It's like me learning that the car isn't behind door #1 before I choose. In that case, I have a 50/50 chance on the other doors.

But what if you didn't tell me before? This introduces our second problem. Let's say I roll the die and you hide it under a cup. I tell you I chose side A and you tell me A is physically impossible and ask me if I want to switch. Well of course I want to switch ... but I didn't learn any more information about sides B and C. It's a 50/50 toss-up. In terms of the game show, you basically just opened the constant's door.

A critical element of the original problem is when the information is learned and knowing that the contestant's door will not be opened. It is what allows the phrasing from zaksoup above.

</comment></comment></comment><comment><USER16> One thing that bothers me about the problem as it's stated in the article is that it isn't explicit about whether the game show host is _required_ to open one of the goat doors regardless of which door the contestant picks, or whether the host is allowed to choose whether to open a door or not. If the host were to only open a goat door if the contestant initially picks the correct door, then the contestant would lose every single time if he/she always switched doors.

<comment><USER17> > whether the host is allowed to choose whether to open a door or not

The problem as stated is: "you select door #1. Then, the host, who is well- aware of what's going on behind the scenes, opens door #3". Why would you think the host has the option of not opening a door? And if you think they could do that, why couldn't the host also do other things, like offer the contestant cash to walk away, or swap what's behind the doors, or add more doors, or open all three doors, or sucker-punch them in the gut?

<comment> T-hawk > Why would you think the host has the option of not opening a door?

Because the actual TV show of Let's Make A Deal worked that way. Here is Monty's own take on it (click to page 2.) [http://www.nytimes.com/1991/07/21/us/behind-monty-hall-s- doo...](http://www.nytimes.com/1991/07/21/us/behind-monty-hall-s-doors-puzzle- debate-and-answer.html)

This is the source of all the confusion from vos Savant's original column. vos Savant got the math right for her version of the problem where the host always opens a door, but that isn't how the show worked. She presented a simplified "spherical frictionless cows" version of the problem.

The actual show did not compel Monty with any rules on opening doors. He had free rein to do whatever he wanted. He could reveal an incorrect guess right away with no opportunity to switch. He could and would offer the contestant cash to switch or not switch. Monty could try anything to trick or bluff or deceive the contestant, all for the sake of producing entertaining television.

Of course, there is no correct mathematical answer at all to a game of bluffing and outwitting. At best you might find a Nash equilibrium in game theory, but even that is hard to pin down. You need to know Monty's tendencies precisely, but even that is hard when his goal isn't to maximize expected value but to produce entertainment.

<comment><USER17> > The actual show did not compel Monty with any rules on opening doors. He had > free rein to do whatever he wanted. He could reveal an incorrect guess right > away with no opportunity to switch. He could and would offer the contestant > cash to switch or not switch. Monty could try anything to trick or bluff or > deceive the contestant, all for the sake of producing entertaining > television.

And really, the thing is, _none of that matters_. Maybe in this version he could reveal an incorrect guess! Maybe in this version he could reveal the door that the contestant picked! That's not what happened in the situation you're asked to analyze. All that matters is that the host picked a door that (a) was not the door the contestant picked, and (b) contains a goat. Nothing beyond that is part of this problem, and nothing beyond that is necessary to solve it. You're given a very specific situation, and asked what the best decision to make is.

</comment></comment></comment></comment><comment><USER18> I'd re-frame it this way:

"The host has zero incentive to reveal what's behind the door you already picked (or the choice of switching would be a no-brainer) so the fact that they left it shut doesn't tell you anything."

"However, the fact that they _didn 't_ (or couldn't) open the remaining shut- door hints that it may contain the prize."

The key is that the host's choice _is not random_.

<comment><USER19> Exactly the way I like to think of it. When he opens the goat door there are now two possibilities: you were right the first time, or the remaining door has the car.

By selecting the other door your are now betting against your initial choice, which _was_ a 1/3 chance. Thus your new odds are 2/3.

</comment></comment><comment><USER20> I just want to start off by saying that I am not, at all, trying to place blame on Marilyn vos Savant for any of this.

When someone gets declared as the smartest/best in the world it first off sets people's expectations so high that they expect perfection, and secondly it places the individual onto a plateau for which others would love to knock them down.

The article doesn't discuss this, but I'm sure that played a part in why her detractors jumped on her so fast and so fiercely. They got told that this person was smarter than them, and they were inferior, and now was their chance at proving that that wasn't the case.

She was of course right, and she likely didn't declare herself the "world's smartest woman" but unfortunately for her, that connotation was still attached to her character, and no matter how modest she was it would have been difficult for other people to take an ego knock by feeling like this person was "better" than them.

Essentially the title of "world's smartest woman" set her up for something like this to happen. Luckily for her her detractors jumped on something she was correct about making themselves sound like morons. However it could have happened when she made her first public mistake (it would have happened eventually).

Fortunately this episode may have helped release the pressure somewhat that was placed on her character. She saved face, but her detractors feel like they took her down a peg so didn't continuously stalk her looking for mistakes.

PS - Just to reiterate I am in no way trying to blame Marilyn vos Savant or deflect any of it onto her. Someone else likely declared her the "world's smartest woman," that is outside of her control, and she dealt with this as well as anyone could hope to.

<comment><USER17> > The article doesn't discuss this, but I'm sure that played a part in why her > detractors jumped on her so fast and so fiercely. They got told that this > person was smarter than them, and they were inferior, and now was their > chance at proving that that wasn't the case.

If only they had stopped to see _if she was even wrong_ first, they wouldn't have proven the claim.

</comment></comment><comment><USER21> I read about this problem and the fact that multiple educated writers falsely called out vos Savant in an old Martin Gardner column, and it shines in my memory as one of the problems that illuminated math for me and made me see recreational math as worthwhile. Of course back when he wrote about it the topic of sexism was mercifully left out, and I honestly hadn't given a moment's thought to the fact that vos Savant was a woman until I read this new take on it, but there you go.

Have standards for what makes something confusing and difficult to understand risen significantly over the decades? When I brought this problem up with my group of (admittedly geeky and mathy) friends no one was left unconvinced by the end of the afternoon, and most even had the intuition as well as the mathematical proof of the answer. Clearly we aren't any smarter than the public figures who couldn't comprehend this puzzle a half a century ago-- so it all in the framing of the problem?

<comment><USER22> Vos Savant originally posed the problem with ambiguous wording.

<comment><USER17> The original problem, from her website:

"Suppose you're on a game show, and you're given the choice of three doors. Behind one door is a car, behind the others, goats. You pick a door, say #1, and the host, who knows what's behind the doors, opens another door, say #3, which has a goat. He says to you, "Do you want to pick door #2?" Is it to your advantage to switch your choice of doors?

Craig F. Whitaker

Columbia, Maryland"

(a) she didn't originally pose the problem, it was a question asked of her, and (b) the wording of the problem is not ambiguous.

<comment><USER23> the ambiguity is that it's presented as something the host does in this particular instance, but the validity of the probability calculations depends on it being a protocol the host always follows (in particular, that the host will always reveal one of the goats _not_ behind the contestant's first choice of doors).

<comment><USER17> There _is no_ "always follows". This is an event which will not be repeated in the history of the world. All there is is 3 doors: you pick one, the host opens another door which contains a goat, and offers you a choice. Why he picked the door that he chose is irrelevant. All that is relevant is that (a) it's not the door you chose, and (b) it contains a goat. You don't need anything beyond that to solve this problem. If you think you need something beyond that to solve the problem, you're not solving it correctly.

<comment><USER24> "Why he picked the door that he chose is irrelevant" I disagree. If he picked the door at random and it just happened to contain a goat it's 50/50\. If he picked the door because he was always going to pick that door if it contained a goat then it's 50/50

</comment></comment></comment></comment></comment></comment><comment><USER25> I don't buy this at all : "Despite its deceptive simplicity, some of the world's brightest minds -- MIT professors, renowned mathematicians, and MacArthur "Genius" Fellows -- have had trouble grasping its answer."

The intuition is simple. Each time you initially pick a door with a goat, you win the car by switching. This clearly happens 2/3 of the time.

<comment><USER26> That's not true, as Wikipedia says:

"Paul Erdős, one of the most prolific mathematicians in history, remained unconvinced until he was shown a computer simulation confirming the predicted result (Vazsonyi 1999)."

<comment><USER25> Lol, Paul Erdos was 82 in 1995, which is when Vazsonyi claims they had this conversation, a year before Erdos died. Beyond his advanced age, it's well known that he did amphetamines his whole life and by that point his brain was pretty fried. I guarantee you if you gave the Monty Hall problem to the great Erdos in his primetime he would've thought it trivial.

</comment></comment></comment><comment><USER27> This was fascinating. I can't believe so many academics got it wrong, and then attacked her gender over it!

<comment><USER28> I'm not surprised. At the time, almost every question every week in Parade magazine was just pulp. Questions of the type "what's the world's smartest woman's favorite color?". You could take anybody off the street and get the same answers. Parade magazine was a gossip magazine.

Furthermore, at the time she wasn't listed in the _current_ Guinness Book so anybody that looked it up would see the column as a fraud unless they checked a specific old edition. Claiming somebody "is listed" when they had been listed, for one year many years ago, is a lie.

So there were a lot of readers who thought of the column as a joke. If you open 99 doors that are full of mindless drivel, what are the odds the 100 is the one that has something interesting? This is why so many people were fooled by it.

<comment><USER17> > If you open 99 doors that are full of mindless drivel, what are the odds the > 100 is the one that has something interesting? This is why so many people > were fooled by it.

So they thought "ha, this is foolishly wrong, I'll write in and tell them that—of course, without doing the 5 minute math check to make sure, first!"

</comment></comment></comment><comment><USER29> I'm a teacher, so I optimize for the result "understanding in my students." I teach it like this:

You _don 't_ bring up Monty Hall first. It bends minds too much.

I give a parallel game, where basics are similar, but you can choose to reveal 3 doors, 2 doors, or just one door each time. Everyone (after making sure they aren't being tricked) chooses to reveal three doors. Winner every time. Then I change the rules: Can't open all three doors. Have to choose between 1 or two. Everyone picks two.

Only _then_ do I give the Monty Hall problem, and show (as @bhc3 put it succinctly) that it's essentially the same game they just learned: your choice is between revealing two doors, or revealing one door.

The most interesting part of this, and why I do it this way, is that I specifically optimize for my students to be able to explain what they know. I can teach someone to win an argument with someone who is convinced it's a 50/50 chance this way. Other ways, people sorta, kinda get it, but can't explain it to others who are confused.

EDIT:

The general principle here IMHO is teach something simple first, and show how it can be applied to something more complicated. When people think something is complicated, "breaking it down" into simpler concepts or making easy analogies doesn't have that great a track record. Their brain seems to have already classified it as "complex" and that has to be overcome —they have to be convinced to drop the tag #complex— in addition to however you teach the right understanding.

</comment><comment><USER30> The way I see the problem is slightly different and I think quite intuitive. If you've chosen a goat, then the host, by eliminating a door, is telling you exactly where the car is. If you have not chosen a goat, then the host not telling you where the car is. What are the chances that the host is telling you the location of the car? It's the same as the chances of you having chosen a goat the first time around.

</comment><comment><USER31> I still think that the problem is wrongly cast as a probability problem, rather than the game-theoretic problem that it is.

<comment><USER18> A fair point, the hosts' choice of door is not random at all. He _could_ open the door you'd already chosen, but that would make your choice to switch-or- not a no-brainer.

</comment></comment><comment><USER32> It's a testament to the brilliance of game show producers that they took something like this that both the contestant and the audience will misunderstand (but looks so simple!) and made a long running show out of it, making millions along the way.

</comment><comment><USER33> Quickest way I've seen to understand this result is referenced on Wikipedia:

 _An intuitive explanation is that if the contestant picks a goat (2 of 3 doors) the contestant will win the car by switching as the other goat can no longer be picked, while if the contestant picks the car (1 of 3 doors) the contestant will not win the car by switching. The fact that the host subsequently reveals a goat in one of the unchosen doors changes nothing about the initial probability._

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

</comment><comment><USER34> There is a flaw in the chart. For the three listed Lose cases, it clumps two distinct choices into one line item and counts them as such, and thus provides an incorrect count of the possibilities.

Moreover the basic argument is flawed. The knowledge of Monty has no barring on the knowledge of the contestant. If Monty simply presented you with three doors that you were to pick from, but opened an incorrect door _before_ you choose your first door, then what would your odds be? The fact that he opens one after you choose does not matter. Monty has total knowledge of the setup and you still have zero.

<comment><USER35> After you choose a door, Monty cannot choose it -- he's stuck choosing one of the two doors that you did not. So, the order of choosing the doors absolutely matters.

<comment><USER34> OK. You are right. I worked through the whole problem meticulously and figured it out. It's actually rather easy to explain once worked through, as follows:

The odds of initially choosing correctly are 1 in 3. In that case if you switch you will loose, but if you stay you will win. The odds of choosing wrong initially are 2 in 3. In which case if you stay you will loose, but if you switch you will win. So it is actually that simple. If you always stay you will win 1/3rd of the time and if you always switch you will win 2/3rds of the time.

It only seems like it should be 50/50 at first blush b/c that is what the odds would be if you choose to stay or switch arbitrarily. That is also why if you write down all the possibilities and simply add them up it will appear to be 50/50 too (which is what I did).

The only thing I still can't quite figure out is exactly how the exposure of one of the renaming two doors increases one's knowledge. I thought I could take the list of possibilities and eliminate those that no longer apply and then add them up, but that doesn't seem to work.

</comment></comment></comment><comment><USER36> One way to intuitively believe the answer is to imagine there were 100 doors, you picked one, then the host opened up 98 of the other doors, revealing goats. Switching would be the obvious answer in that case.

<comment><USER37> That's still not obvious to me

<comment><USER38> I'm a little intoxicated so this may be way over doing it or just not make sense, but...

Let's make the number even bigger, so we don't even need to deal in probabilities -- a sextillion (10^21) doors. That's more doors than there are grains of sand on the planet. Say you're given a sextillion doors, and you pick one lonesome door, call it door A. What are the odds that door A is the right one? Essentially zero, right? I'm going to say straight up zero because now is not the time for you to be a dreamer.

Ok so now that you've made your futile pick, poor Monty has to go and open every other door, all sextillion of them, except for yours and one other (let's call it door B) which he leaves closed. Every door he opens contains a goat.

So now out of this vast universe of doors, there are (10^21-2) doors opened with goats bleating away, and only two doors left unopened: door A, aka yours; and door B, the one that Monty mysteriously left unopened. One of them must contain the car.

(I'm guessing at this point it will be obvious for many people that door B contains the car, but I'll elaborate further in case it isn't clear yet.)

So we're left with your door A and Monty's door B. At this point there are only two scenarios that matter. Either you picked the right door originally, in which case staying put is the winning move. OR, you picked the wrong door originally, in which case switching is the right move. And we already know you picked the wrong door (remember, no dreamers allowed here), so you should for sure switch to this by-now-extremely-conspicuous-looking door B.

Door B isn't just some random door; the fact that it was chosen as the only door to not be opened tells you a tremendous amount of information about it. Think about the game from Monty's perspective. Either you pick the correct door initially and he gets to make door B a random goat door, or you picked the wrong door and he has no choice but to make door B the door with the car behind it. Since we know you picked the wrong door, we know what Monty's gonna have to do.

</comment></comment></comment><comment><USER34> It didn't seem right to me at first, so I worked through it. The trick was to realize that switching always gives the opposite result of the initial choice. So if the initial choice is correct, switching will make it wrong. On the other hand, if the initial choice is wrong, switching will make it right. (Recall that Monty eliminated one wrong choice, so there is only one other choice from which to choose.) Since you have 1/3 chance of being right and 2/3 chance of being wrong on the initial pick, switching will reverse your odds.

</comment><comment><USER39> From Monty Hall's interview:

> He retained the authority to offer the contestant cash NOT to switch. "I > wanted to con [them] into switching there."

So he wanted them to win the car. That seems interesting. I suppose it makes sense as this was an entertainment program. Viewers like a happy ending. Or if the guest accepts the cash and stays with the lower probability door, it's okay that they get the goat because they have cash. So win-win just for appearing. Also prevents unhappy guests from saying bad things about the show.

</comment><comment><USER40> It always amazed me that so many academics got it wrong. Once you understand the way the actual game works, it's pretty obvious that you gain a statistical advantage if you switch.

<comment><USER21> I know right? I don't blame them for getting it wrong at first glance-- I'm pretty sure 999 out of 1000 humans would. But the mathematics of the probabilities can be written down on a napkin they are so simple, so how was no one able to convince these scientists with a clear, concise technical proof? They really needed a computer simulation, as I've seen it claimed?

<comment><USER41> > But the mathematics of the probabilities can be written down on a napkin > they are so simple, so how was no one able to convince these scientists with > a clear, concise technical proof?

I'm even more appalled that no one tried, you know, actually running the game. Have someone take a quarter and two pennies, mix them up under cups, let you choose one, show you a penny, then switch or not. Repeat several times. Switch places. When you're playing the role of Monty, the truth will reveal itself...

<comment><USER42> I have a close friend that was incensed about my explanation about how he was misunderstand. He even ran a broken simulation that showed he was right. When I corrected his source code with detailed comments, he further accused me of trying to fool him and make fun of him. Didn't speak to me for a month.

Bizarre. But I suppose this kind of thing that goes against instincts can really upset people.

</comment></comment></comment></comment><comment><USER43> What many descriptions of the problem leave out is that it is critical that Monty knowingly picks a door with a goat. If Monty chooses at random, then the winning odds do indeed increase to 50% if he happens to open a door with a goat behind it.

The randomized variant, by the way, tends to garner roughly the same degree of "you're completely wrong" responses when given to people who know just enough about the normal Monty-hall problem not to be fooled by it.

</comment><comment><USER44> One interesting variant, is the case where the Host opens a door without knowing if that door had a goat. Expressing relief that he opened a goat door, he asks you to consider switching doors.

IIRC, you get less information in this case, since there was a 1/3 chance that the host would accidentally pick the "car" door, but you still have a 1/2 chance of winning by switching.

<comment><USER45> > still have a 1/2 chance of winning by switching

It seems that you are referring to the other variant, in which case this is false, because that one has a 2/3 chance of winning by switching.

<comment><USER46> No, you have a 1/2 chance of winning _after a door has been opened._ However, you also have a chance of losing on that reveal. Something you don't have in the normal variants. (That is, in normal variants, you only lose at the end of the game. This one, you could effectively lose when the host opens the actual winning door.)

So, your overall odds aren't as different as it seems. Just you have a much better odds of winning by switching, if you are still in the game.

</comment></comment></comment><comment><USER47> "You made a mistake, but look at the positive side. If all those Ph.D.'s were wrong, the country would be in some very serious trouble."

Best quote in the entire article.

And if I had to explain the problem in one sentence: Opening the first door obviously gives you a 1/3 chance, which remains unaffected by the host opening another door.

<comment><USER48> > Opening the first door obviously gives you a 1/3 chance, which remains > unaffected by the host opening another door.

You had a 1/3 chance if you opened the second door too. Why does the second door's chance change, but the first door's chance is somehow locked by you having chosen it?

<comment><USER35> The chance is locked in because, by the rules of the game, the host can't open _that one_ and show you anything -- regardless of what it contains. You know that there's at least one door that the host can open (of the two remaining doors), so them opening a door changes nothing about the door you've chosen.

</comment></comment></comment><comment><USER49> The problem is not well-posed. The debate should be about its formulation, not about the math...

The key here is to understand that no matter what you do, the game organizer will ALWAYS open one of the two others doors.

Now, what if the organizer was to open a door only in some cases? He could open the door only when you choose the correct door. In that case, you have 0 chance of winning when you switch doors when the organizer opens another one.

What makes the 1/2-1/2 probability - that so may math PhDs defended - acceptable is this: the organizer is selecting a door at random and opening it. Then if I choose a door and the organizer opens another one, I know that I have a 50% chance of having selected the correct one. Of course, he could also have opened my door in which case the game ends.

This is a good example of how an ill-posed problem have different solutions depending on its implicit interpretation.

<comment><USER17> In the problem as stated, the organizer _did_ open a door, which _did_ contain a goat.

<comment><USER49> That's not enough. You need the knowledge of "the organizer will ALWAYS open a door that contains a goat" to draw the conclusion of the article. That knowledge is implicitly assumed. I have shown that by assuming a different knowledge - in this case, the organizer only opens the door that contains a goat when you choose the door that contains the car - you can end up with different probabilities.

I don't have an IQ of 200+ nor do I have a PhD in math, but I'm pretty certain that the probabilities in this problem are unknown unless you know the behavior of the organizer in EVERY situation, not in one particular case.

<comment><USER17> > That's not enough. You need the knowledge of "the organizer will ALWAYS open > a door that contains a goat" to draw the conclusion of the article. That > knowledge is implicitly assumed.

It's not implicitly assumed, it's stated in the original question: "You pick a door, say #1, and the host, who knows what's behind the doors, opens another door, say #3, which has a goat." You pick a door, the hosts opens another door which contains a goat. He can't open the door you chose, he can't open a door with the prize, he can't not open a door. Introducing a possibility which is not a part of the specified problem turns it into a different problem.

> I have shown that by assuming a different knowledge - in this case, the > organizer only opens the door that contains a goat when you choose the door > that contains the car - you can end up with different probabilities.

For every "the organizer only the opens a door that contains a goat when you choose the door that contains a car", there's an "the organizer only opens a door that contains a goat when you open a door that doesn't contain a car". Not knowing the host's behavior means that it isn't part of your analysis. If you don't know why he does what he does, all you can use are the facts in front of you: there are three doors, you pick one, you are shown a second door which doesn't contain the prize, and are offered a chance to choose.

> I'm pretty certain that the probabilities in this problem are unknown unless > you know the behavior of the organizer in EVERY situation, not in one > particular case

Not so. If you knew the host's behavior (which the original problem does specify precisely), you can use it in your analysis. But not knowing it, means the best decision has to be independent of it. And if you knew the door that contained the prize, you could use that in your analysis. But not knowing it, means the best decision has to be made independent of it.

<comment><USER49> You are making an assumption on the host behavior, the assumption being that if you repeat the experiment the host will open a door containing a goat. If you think you're not and that the 1/3 - 2/3 probabilities are correct based on the single observation you made, consider this:

you have 1 black ball and a 2 white balls in 3 different urns each containing a ball. You select one urn A. Some external agent randomly overturns an urn. That ball it contains is white. What's the probability that the ball in urn A is black? The answer is 1/2\. Not 1/3\. It's 1/2 because you the assumption you make on the external agent's behavior is that it's random. If you don't make an assumption on its behavior, you can't calculate probabilities. If you make the assumption that the external agent picked up the white ball on purpose and will repeat that behavior when faced with similar circumstances, the probability is 2/3.

My point is that if you don't make an assumption on the host's behavior, you can't calculate probabilities.

</comment></comment></comment></comment></comment><comment><USER50> There's an important rule that isn't always communicated correctly: the participant must know ahead of time that the host is always going to open a door.

</comment><comment><USER51> Impossible to graduate from Berkeley with a CS degree without hearing this problem :)</comment>


BeatMyPrice: Login Haters Become Price Beaters - <AUTHOR> http://mashable.com/2008/11/10/beatmyprice/ <comment><USER2> <http://bountii.com/pricehunts.php></comment>


Ask HN: How does slow internet impact your work? - <AUTHOR> For those who don't have access to high-speed internet (<5mbps up/down) - how has this impacted your work?
With  modern package managers (npm, pip, etc), docker images, etc - it can take significant time to download dependencies. I currently have a fiber internet connection (>300mbps), but there's a chance I'll move to a rural area with slow internet (<5-7mbps).
For reference, i use docker/ruby/go/js professionally so that requires frequent downloads, updates to packages. Everything is of course collaborated on via git.
TLDR;
- How do you manage the constant upload/download of software development with slow internet?
- Do you have any tips/tricks for managing dependencies with slow internet?
- Do you ever manage days at a time without internet access?
Thanks all! <comment><USER2> I currently live in Colombia and every once in a while, around 40-60% of packages drop. I noticed it was a peer connection in Miami, and almost all traffic went through there. Even if I went to an Argentinian IP, it would still go up north to Miami and then south (my guess is cheap residential peering connections). Anyways I basically got a server from a provider that bypasses this peer connection, and setup a VPN. When my internet starts misbihaving, I simply connect thru that VPN and it fixes the package loss. You adapt.

</comment><comment><USER3> Surelly it will be pain once you have been "spoiled" with by fiberoptic.

Keep in mind that for asymetric 5-7mbps downlink you may have 0.5-1mbps uplink. Also if you plan to work remotely in a team then video-conference and screen-sharing quality may be very poor.

For heavy stuff (rebuilding Docker images etc) it is convenient to have some remote ssh dev machine with the top connectivity (AWS, etc).

Other than that invest in some redundant links - research locally available 4G, WiMax or directed WiFi, cable TV operators.

</comment><comment><USER4> As long as it's a reliable connection it's not all that bad. Annoying, but you adapt.

But having an unreliable line is a whole different story. When things stop working and you can't do anything, can't plan for it - you loose your flow. It might sound funny or even wrong given what's going on there, but this was hands down the biggest boon to my life quality when living in China.

</comment><comment><USER5> The major impact goes to the productivity, which directly affects business & project management</comment>


Number go down: the single trade that crashed Bitcoin - <AUTHOR> https://davidgerard.co.uk/blockchain/2019/05/18/number-go-down-the-single-trade-that-crashed-bitcoin/ <comment><USER3> Actually I'm kinda impressed someone put a market order to sell $30 million Bitcoin and the book filled it then and there.

Yeah it moved the price. That's a pretty big trade for BTC. Would BTC have cleared $30 million in actual trading volume a few years ago?

Now the fun part, good luck getting the cash out of the exchange!

<comment><USER4> Luck has nothing to do with it. Someone who is able to either buy or sell such amount in short period of time is not a first timer; they definitely have access to get that dough converted/moved out of computer systems into their banking account as flawlessly as they sold that $30MM in the first place.

Otherwise they would not have done such move at all.

<comment><USER5> I suspect they _are_ a first timer. There are lots of very rich amateurs in the bitcoin world.

A pro would at a bare minimum split it into a few thousand timed orders.

</comment></comment></comment><comment><USER6> These fluctuations have been a part of Bitcoin for a few years now. And while most people think it's no big deal I think it's absolutely fatal.

It's fatal because bitcoin isn't supposed to be some kind of stock that you buy, sell and speculate on. It's supposed to be a currency and that's where it's supposed to get its value from. Unfortunately that's not how it's being used because unfortunately it's not a very good currency.

Nobody wants to use a means of exchange that fluctuates widely from day to day. No one wants to accept $ 1 in bitcoin for a loaf of bread if that $ 1 could be worth ten cents tomorrow. Currencies need to be stable for them to be usable as a means of exchange.

Unfortunately this sort of instability seems to be a feature of bitcoin rather than a bug. Unlimited anonymous transactions means the system will be easy to manipulate.

That said the dream of bitcoin could be one that saves humanity from the financial tyranny imposed by governments. This is particularly true for people who live in third world countries where governments play fast and loose with their currencies and their money can quickly become devalued.

It is also to an extent true for richer nations where government control of the currency led to things like the great depression the great stagflation of the 70s and heaven knows what ill effects it's causing today that economists of tomorrow will learn about.

It is clear to me that having independent currencies will result in a freer more prosperous world. I think what's needed is an alternative to bitcoin that is set up to actually work like a currency rather than a share or forex market with people buying currency that they don't plan to use.

I think the solution is to learn from paypal which also set out to create it's own currency and almost succeeded. Create an alt coin and brand it as a currency and have it be used that way. Maybe go to ebay top sellers or etsy top sellers and convince them to accept your alt coin. Have rules and tracking mechanisms in place to prevent manipulation of the money supply. And most importantly a widespread currency can't have anonymity. I'm not saying anonymity shouldn't be allowed in a currency. But widespread use of a currency requires being able to manually undo transactions that were done through fraud, the way banks and credit card companies can. This is why people tend to avoid making large payments in cash, they want a paper trail so it can be undone if necessary.

<comment><USER7> > _Have rules and tracking mechanisms in place to prevent manipulation of the > money supply. And most importantly a widespread currency can 't have > anonymity. I'm not saying anonymity shouldn't be allowed in a currency. But > widespread use of a currency requires being able to manually undo > transactions that were done through fraud, the way banks and credit card > companies can. This is why people tend to avoid making large payments in > cash, they want a paper trail so it can be undone if necessary._

Regular money has basically all these features, plus the advantage of enormous institutional support (laws, systems, finance sectors, central banks, markets...)

</comment></comment><comment><USER8> "The crypto blogs put forward all sorts of bad reasons — it's capital flight from China! It's Bakkt offering Bitcoin futures! It's Flexa offering retail payments in crypto! It's Microsoft experimenting with the blockchain! — even though this was really obviously a manipulated push like so many before."

All reasons for the price to rise or drop are obvious in hindsight. I like to see pundits make these predictions _before_ the price event. Better yet, buy or short sell BTC, make a screenshot and put your money where your mouth is.

<comment><USER9> So figure out when market manipulators are going to act? You'd have to be colluding along side them to know this.

<comment><USER10> I think you missed the point. All the poster is saying is that these crypto analysis people should actually attempt to predict price moves based on market forces instead of explaining movement in hindsight.

</comment></comment></comment><comment><USER11> On BitCoin this type of behaviour seems quite easy to spot but it happens elsewhere too - eg the S&P E-Mini futures and probably the Nasdaq futures.

It takes remarkably few contracts to actually move the market - <USER2> during the Globex session.

<comment><AUTHOR> oh yeah - this sort of thing is rife on thinly-traded commodity and forex markets, especially if you think the regulators aren't paying much attention - you'll see Barts all over the place.

It's a symptom of just how thin trading is in crypto, even for the "biggest" one.

<comment><USER12> I'm not sure "thin" is the right word here. It took something like 20 minutes for someone to dump nearly $40 million worth of Bitcoin, and after the dust had settled, the price had dropped less than 12%.

There are many other factors that lead to this sort of thing happening with Bitcoin, including the lack of regulatory oversight you mention.

<comment> village-idiot The nominal market cap of BTC right now is about $129 billion. A $40m trade represents about 0.03% of the reported market cap. That a trade that small would cause the market to crash by double digit percentage points is absolutely a sign of a thin market.

Also, the slow speed of price propagation isn't a sign that the market is thick, it's a sign that the market is inefficient.

<comment><USER13> >That a trade that small would cause the market to crash by double digit percentage points is absolutely a sign of a thin market.

It was only the market on a single exchange, Bitstamp, which is extremelly illiquid compared to the largest exchanges. The problem was that Bitmex, a much more liquid exchange, bases the settlement price of its popular perpetual Bitcoin swap on an index of just two exchanges, Bitstamp and one other, so manipulating the price on illiquid Bitstamp also screws with the price on liquid Bitmex.

<comment> village-idiot I agree that Bitmex basing its settlement price on two less liquid exchanges is a bad thing. Personally given the number of margin traders being force liquidated, I suspect that BitMEX likes the lack of liquidity.

However, if the issue was only a thin market on Bitstamp, the price fluctuations would have remained localized to Bitstamp and the futures market on Bitmex. But instead the price for bitcoin dropped by about $1k across the board, which to me signals thin markets everywhere.

</comment></comment></comment></comment></comment></comment><comment><USER14> This is called pulling the stops, most trader has stops set by their borrowers. In this case is easy to pull the stops as a lot of people seem to use this thing to gamble

</comment><comment><USER15> Ah so BitMex uses Bitstamp price (and Coinbase) - that's the link I was missing understanding price manipulation in Bitstamp and longs liquidated in BitMex.

</comment><comment><AUTHOR> Well, that was quick. The next round of "Bitcoin: Moon or Toilet?" started this morning at 02:00 UTC, with a $1000 price pump. Why? Well, it coincidentally wiped out this short:

[https://twitter.com/whalecalls/status/1129931343838814208](https://twitter.com/whalecalls/status/1129931343838814208)

</comment><comment><USER16> When I read 'crashed' I didn't expect a 100% increase in two months [http://bitcointicker.co/stamp/btc/usd/24hr/](http://bitcointicker.co/stamp/btc/usd/24hr/)

I guess they orchestrate one more (last) pump&dump hype cycle.

</comment><comment><USER17> Someone should chart all the dates and amounts that journalists have claimed BTC has crashed in percent or points, add it up, and then show how they're reporting on trend that does not exist and is in fact the opposite of reality.</comment>


How Many Programming Technologies Can You Really Master? - <AUTHOR> http://thecodist.com/article/how-many-programming-technologies-can-you-really-master <comment><USER2> You conflate the tools, methodologies, and detailed interfaces of particular environments (that is, coding) with programming. Master programming and the warts and failings of programming languages and operating systems become less significant.

</comment><comment><USER3> I think you first have to define mastery. Is it perfect code on every imaginable measure? I don't think so. I've been learning Windows, Linux, Networking, UI/UX, HTML, CSS, JavaScript, VB6, VB.NET, C#, ASP, PHP, MySQL, Informix, PostgreSQL, MS SQL, SSIS, SSRS, SSAS/OLAP, Photoshop, AWS, Angular, Node.js... The list goes on. The point is, someone can prove my weaknesses in all of these areas. Jack of all trades master of none doesn't mean you can't be a play maker. Failing starts by calling yourself a master.

</comment><comment><USER4> Really? A lot of the technologies in the opening paragraph are in relation. If you are building API-centric apps, you will have to have a well rounded understanding of how the technologies _relate_ not just the mastery of each on their own. Maybe that is the intended message?

The main issue is the overuse of the word master, which may imply the 10,000 hour rule. I suppose they do this to ward of amateurs.</comment>


Show your support for Snowden with these shirts, bumper stickers, and hats - <AUTHOR> http://www.wishplz.com/product-collections/bDRzO6c7Stw0vSVh2ITOwz8YqWQbHNGC

<comment><USER2> This collection is awesome! Definitely gonna buy my t-shirt and donate.</comment>


Would you ask a girl to consent to sex with an app? - <AUTHOR> http://www.thememo.com/2015/07/20/we-consent-sexual-consent-sex-app-rape-michael-lissack-dangerous/

<comment><USER2> Both the article and the thread so far seem to miss a crucial point: consent can be withdrawn.

"I changed my mind" effectively renders this "contract" null and void. The only (near) 100% sure-fire way to avoid a false rape allegation is to videotape the whole thing. Good luck with that, gentlemen.

</comment><comment><USER3> Maybe when you go to a fraternity party you should sign a contract that forgoes your right to sue if you get injured in a fall, get raped, or otherwise get hurt.

I told my son that it isn't even safe to go in a frat house to deliver a pizza and it should say "abandon all hope all ye who enter here" over the door.

</comment><comment><USER4> I sure would. Can prevent some problems (think about Julian Assange for example).

<comment><AUTHOR> What if something changes mid-way through? Is it a free-for-all once you've signed on the dotted line?

<comment><USER4> Perhaps the app should have a list of options, e.g.:

      I consent with:
      [X] Fellatio
      [X] Intercourse
      [ ] Anal
      [ ] SM
      [ ] …

So it's clear what is agreed upon and what not.

<comment><USER2> This completely misses the point, which is that consent can be withdrawn at any time.

</comment></comment></comment></comment><comment><USER5> I hope they have good security and nobody steal the database.</comment>


Knative = Kubernetes Networking++ - <AUTHOR> https://ahmet.im/blog/knative-better-kubernetes-networking/ <comment><USER2> > Knative is about to hit v1.0 and become «stable», has a solid community.

I'm sorry for the negativity but I'm skeptical about the reliability.

AFAIK it still doesn't really address instabilities. Software crashes, hardware fails, power goes out. It is trivial to lose data, and it is trivial to be blissfully unaware that there is a possibility of data loss because when everything's green, things work perfectly fine.

My anecdote is, I was at a conference, listening to the "Introduction to Knative" talk. Knew just the name and that serverless is a hot new thing. There was a simple app that has sourced earthquakes and displayed a map, or something like that. Things looked neat and simple, so I wanted to jump on that bandwagon, but... My first (and quite obvious) question was, "what happens if during the event processing a hardware node that runs a service instance suddenly goes dark?".

I was surprised that there wasn't a meaningful answer, so I've tried to research it myself and found that - in my understanding - the event is just lost. Unless someone had taken extra care to implement such guarantees by adding more and more statefulness. As I get it, it's still K8s, and I can deploy my own message bus/queue, but this devalues Knative for me.

[https://github.com/knative/eventing- contrib/issues/656](https://github.com/knative/eventing-contrib/issues/656) is the issue that tracks it, and it was shoved away to the eventing-contrib repo...

It could be that I don't understand something, or that I've made the wrong conclusions.

\---

Update: Found [https://github.com/knative/eventing/pull/1949](https://github.com/knative/eventing/pull/1949) \- seems that they've merged in something just _yesterday_. Seems that things are improving. That's good.

<comment><USER3> I am not sure if an event queue is the primary focus of Knative, or at least this particular blog post. This is focusing on the problem of Kubernetes networking, which is honestly pretty useless.

By default, a Kubernetes "service" exists to create a single IP address for a group of replicas. You see that your "foo service" is at 10.2.3.4, you open a TCP connection to it, your connection is created to one of the available replicas. You open another connection, it goes to another replica. This accomplishes some load balancing and lets new TCP connections avoid unhealthy replicas.

The problem is, a TCP connection per request is relatively uncommon these days. You open up one connection to MySQL and send it multiple queries. gRPC sends multiple requests and responses with one TCP connection. HTTP/2 sends multiple requests with one TCP connection. The days of one request = one TCP connection are over.

So there is a lot of work being done to try to make load balancing transparent at a level above the TCP connection. Your app asks to connect to foo-service, and each request is routed to another healthy replica. Replicas come and go, but your app never has to handle reconnects. You want to send 10% of requests to a canary instance without having to tell your application that; you want the networking layer to handle that for you.

There are several approaches to handling this problem.

The first is having smart clients; if your gRPC library knows how to ask the Kubernetes API for a list of replicas, it can do its own load balancing and health checks. It gets a list of valid endpoints, opens up a connection, subscribes to the streaming health service that each backend provides, decides on a load-balancing algorithm, and goes! This works quite well, but it is difficult to setup and difficult to maintain. The C++ gRPC client has to do this, the C++ HTTP/2 client has to do this, the Go gRPC client has to do this, the Go HTTP/2 client has to do this, the Python gRPC client has to do this, the Python HTTP/2 client has to do this, the node.js gRPC client has to do this... you get the picture.

I am most familiar with this approach from my days at Google, where load balancing typically consisted of a smart client for every language that connected to a coordinator, asked for backends and a rule for splitting traffic among them, and stayed connected to receive updates. It worked extremely well. You could drain a cluster very quickly, and obviously traffic kept flowing if the load balancer died. (Not sure I ever saw the load balancer die, though.) The disadvantage is that a malfunctioning smart client can break everything; every piece of code you deploy to production in every language has to work perfectly. (From reading job ads, I feel like few companies are as disciplined as Google at saying "you have to use one of these 3 supported programming languages". So in the real world, the "smart client" approach will never work. You can check out the existing gRPC client libraries to see this in action; best case, there is round-robin load balancing based on DNS records, with some metadata that can also be retrieved from DNS. C++ supports it best, Go is next, the rest of the language bindings... questionable. Raw HTTP/2? Good luck.)

The second approach is to have a smart proxy that your apps use to get to the outside world. You run this smart proxy as a "sidecar", receive all traffic through it, and send all outgoing traffic through it. It knows where all the backends are and how to load balance, so the app doesn't have to. Personally, I think this is the most practical approach right now. Run Envoy next to your apps, make your services "headless" (so Kubernetes just returns all endpoints over DNS, rather than trying to do TCP-level load balancing), and go! Even your outdated PHP app will now have detailed metrics and participate in distributed tracing. The disadvantage is that you have to manually add an Envoy container and minimal config to everything you run, which people apparently hate.

I like this approach, it's what I personally do. Envoy has its quirks, but it does provide a lot of observability with very little effort. You can code whatever custom tooling you want with an xDS control plane, and even with a static config file and some DNS records, it does a great job of ensuring that every request you make hits a working backend. (And alerting you when there are none.)

The last approach is to redesign Kubernetes networking so that it transparently provides the same thing that a sidecar would. That is where things like Istio, linkerd, and knative's networking stuff fit in. They take your deployment specification, inject a sidecar, and adjust iptables rules to force your application to talk through the sidecar. Some of them, I believe, come with a control plane so that you can perform management operations cleanly (canarys, draining a region or node, etc.).

My personal opinion is that they do too much; if you name your syslog port "grpc" by accident, goodbye traffic! What was supposed to be documentation is now just an undocumented part of the Kubernetes API. And since it's all non- standard, what works with your Istio cluster may not work with your Linkerd cluster. You can actually write well-formed config files that will work on one cluster but not on another. So I don't think this is the approach that will eventually win.

Approach 1, a smart client, is the most likely to be reliable and understandable. It's also the least likely to work in a world where people's Excel spreadsheets run in production and need to load-balance their HTTP/2 requests. Approach 2 is probably the most difficult to set up right now, but it's a good compromise for the real world. You type in the config that you want, and then that is executed in an observable and maintainable way. You have to type stuff though, so it's unpopular. Approach 3 is the most popular and most likely to cause problems. But I'm sure that if we keep bludgeoning it with enough hammers and hire enough Kubernetes Certified Operators at $300,000 a year, we can make it work!

Sorry for the rant but it just blows my mind at how much time people will spend to make something transparent that is actually fine to see. All we need from Kubernetes is to tell me where the replicas are. Then we can write our own load-balancing that works for our application.

<comment><USER4> >The disadvantage is that you have to manually add an Envoy container and minimal config to everything you run, which people apparently hate.

Correct me if I'm wrong, but I think envoy (or istio, at least), uses a mutable admission webhook to inject the sidecar into your pod. This means you never have to enter anything into your pod spec.

Edit: I noticed you pointed this out with istio.

<comment><USER3> Yeah, Istio is the Kubernetes glue for Envoy. Envoy is just a proxy; it can exist without Kubernetes and as far as I know, knows nothing about it.

</comment></comment></comment></comment><comment><USER5> As a developer started his career during the cloud/everything-as-a-service boom, thinking about Kubernates networking gives me anxiety

</comment><comment><USER6> Still waiting for it to support basic, but crucial functionality like tolerations and node affinities. And no, using admission plugins like PodNodeSelector is not viable on managed clusters like GKE.

</comment><comment><USER7> Its not governed under the CNCF, so really, what Knative equals is Google lock-in.

<comment><USER8> That seem premature and unfair. KNative has representation from Google, IBM and Redhat, and the steering committee is working on a more inclusive governance structure. (I have no inside knowledge of this - just what I have gleaned from slack ;-) )

<comment><USER7> What's premature (it has been around for at least a year)?

And why is it unfair to ask for open governance from companies other than Google and IBM (redhat is part of IBM)?

<comment><USER9> Pivotal is also on the steering committee.

Representation is based on contributions to the project, and Google has publicly stated that they look forward to not being a majority on the steering committee (when other companies have exceeded Google's contributions).

There are CNCF projects whose governance is entirely within a single company. I get that there's a great narrative here that "Google doesn't share", but it seems like Google is being held to a higher bar here.</comment></comment></comment></comment>


Stuxnet Source Code Released Online - <AUTHOR> http://www.thehackernews.com/2011/07/stuxnet-source-code-released-online.html

<comment><USER2> Old news - this is just decompiled, not the original source.

</comment><comment><USER3> This just looks like someone decompiled Stuxnet.</comment>


Hiring & Loss Aversion Jujitsu - <AUTHOR> http://www.metamorphblog.com/2010/04/loss-aversion-jujitsu.html

<comment><USER2> _"A good parallel is the romantic realm: First a light kiss. Then harder. A hand wrapped around the low back. Upper back. In the hair. Grabbing. Tugging. Pulling. A brush against the breast. A kiss on neck. The clavicle. Sternum. Clothed breast. Bare breast. Nipple. And pretty soon you're upstairs rollicking on the kitchen table....This, my friends, is how the poor man should hire."_

With this kind of enlightened dialectic, I just can't understand why more women don't go into computers.

<comment><USER3> Ah, you mean because the description reads like a romance novel, women would think they are being typecast? :-)

</comment></comment><comment><USER4> Trust economics to give us a scientific name for flirting, but why "salami tactics"? :)

<comment><USER5>
      And pretty soon you're upstairs rollicking on the kitchen table. Who'd a thunk
      it would've gone so far?

Apparently because salami tactics lead to salami action. I'm a bit surprised that he is using this imagery (and the imagery of border incursions) while he's presumably in the process of hiring people. Does he really want prospective hires to think in these terms?

</comment></comment><comment><USER6> Has anybody here ever done this in the real world? Or had it done to them?

<comment><USER7> Yes on both counts. I'd say it happens all the time in startups, especially with co-founders and early hires.</comment></comment>


How We Spent $500 on Tech to Ship $2.6M of Soylent - <AUTHOR> https://medium.com/@alando46/how-we-spent-500-on-tech-to-ship-2-6m-of-soylent-3abfdcebee78 <comment><USER2> This was really interesting, but it just seems like they chose the wrong fulfilment partner for their warehousing and logistics. I work for a third party warehousing and logistics company in AU, but we specialise in receiving orders from external parties in electronic formats and providing tracking information back to the orderer. People think that warehousing/distribution companies are all the same, but there are a lot of different niches. Some are strong with bulk shipping, some with small and fiddly picking, some with large national campaigns that need simultanous delivery. You need to do your research and look for which suppliers are being used by other companies that have a similar distribution profile to you.

<comment><USER3> Yep. This is 100% right.

I've got warehouses that send me things in EDI. I've got warehouses that have me pull something down over sftp in csv or xml. I've got warehouses with bizarre SOAP apis. I've got warehouses with bloody custom REST APIs [that probably cost them $10,000+] sitting on a mac mini that sits in their office.

Your comment really should be at the top since this blog post is little more than a warning of "Pick the right fulfillment house or it'll eat 6 months of your life"

</comment></comment><comment><USER4> "a $500 system that successfully managed the first four months of Soylent shipments."

Successfully is rather overstating it. The shipment of Soylent was delayed by over a year and went at a snail's pace. My shipment was delayed at a rate of roughly one month per month, with it eventually arriving something like six months after the first shipment had gone out, despite being one of the first backers. I can't think of a single metric on which I would call the Soylent shipping process "successful".

<comment><USER5> Wasn't that an issue with the overwhelming demand (and not having sourced enough ingredients) as opposed to shipping issues? I don't think your shipment of Soylent was in transit for six months.

<comment><USER4> I'm sure it was a combination of a lot of issues. They did have a lot of demand, and with that demand came full advance payments for all of that product, which they got to use interest-free for the entire time from sale to delivery. I'm not trying to say their job was easy, or that the main difficulty was any particular thing. I am saying that the result was a long way from being something that merits this kind of self-congratulatory blog post.

</comment></comment></comment><comment><USER6> Cool story bro, but it give me hives just reading it. "We didn't know anything about physical order fulfilment so we hacked our way into a local optimum, rather than asking anyone who knew".

Or, as we say hereabouts, a month in the lab solves a day in the library.

But it only cost $500! Well, I'm sure that'll come as a lovely surprise come payday when John discovers he's working pro bono.

Also, that product looks disgusting.

<comment><USER7> I love math where $500 in hardware plus 6 months of engineer salary equals $500.

I am a grad student making about $30k/yr and my advisor still says to figure labor as costing $1,000/day.

<comment><USER8> Startup math is a bit different.

For example, without that kludge, they wouldn't have been fulfilling orders. So, even if they "wasted" half a man-year, they still made their sales and avoided the cost of, you know, going out of business.

You can't really apply operational reasoning to startups the same way you can to larger businesses--you've got to factor in other things.

(And yes, that is used frequently as a way of deflecting legitimate operational complaints.)

<comment><USER9> That's not the criticism. They're not cobbling a solution together to prevent bankruptcy, they're cobbling together a solution to an already solved problem. Ecommerce fulfillment companies exist, and they chose a freight company with inadequate technology for their needs. Then they're justifying it by saying they hacked a solution for only $500, when it's really costing $500 + 6 months salary + hurt reputation for an extremely late delivery.

They could've incorporated a company that used EDI (or an API) to tie into their database to process orders much more effectively than hacking together a solution with a store bought laptop.

<comment><USER8> ( [http://en.wikipedia.org/wiki/Soylent_%28drink%29](http://en.wikipedia.org/wiki/Soylent_%28drink%29) )

Look at the timeline. They only started shipping in like May of '14\. This article covers April of '14\. They had only run a crowdfunding campaign like less than a year prior. They raised funding (a lot) a year later.

The problem with "but but but they should've used an API or an order- fulfillment company" ignores that, at that time, they very likely were lacking the upfront capital required to setup and guarantee that relationship. The problem with "but but but they wasted a ~salary~" is that, if you looked at their payroll at that time, I'm willing to bet they were being compensated mostly in equity and not market wages.

Again, there is an entire solution space that is strictly better that is also strictly off-limits _if you don 't have the spare funding_.

EDIT:

More to the point, this thread is full of Monday-morning quarterbacking. The fact is, these guys raised $20M, and we're bitching on the internet.

<comment><USER7> Lots of people make bad business decisions, and I don't want to give them a hard time about the shipping company they chose, especially when they were willing to share the experience in a blog post.

What worries me most is the internal accounting that gets them to $500. I am pretty stingy with the money I spend on my hobby projects, and sometimes it is fun to build things that I could buy for slightly more money. That's ok when the goal is entertainment. If I was at work I would do completely different math, and probably consider a few hours work to save $20 to be a complete failure.

<comment><USER8> I absolutely agree that your logic is correct, for a grad student or full-time engineer.

But again, early-stage startups != normal business calculus.

Look at it this way:

You've got two buckets, one of cash and one of time. You can fulfill business goals by dipping into either or both buckets. The time bucket continually replenishes at a fixed rate but never change capacity, the money bucket may replenish unpredictably in both amount and time and have its capacity expanded (more employees, capital, whatever). If either bucket goes dry, you lose.

At an early stage, your cash bucket is near empty compared to your time bucket. If you've spec'ed your business properly (hah) and are not too unlucky (hah hah), you will never have a demand that exceeds the total available amount in the two buckets.

So, to fulfill demands, you pull from the time bucket, because it has the greater reserves, and because it'll replenish as every second tics by.

As time goes on, though, the demands outstrip what your time bucket can handle. Your time bucket, remember, never gets larger. But, since your business is growing, the cash bucket has been getting larger, and so you start to fulfill demands out of that bucket, using contractors or vendors or whatever.

Eventually, you are fulfilling demands _entirely_ out of the cash bucket, because you simply will never have enough time to do them in the required timeline otherwise.

The same rule ("gotta fulfill my business demands without emptying my buckets") applies at both ends of a company's lifecycle, but results in entirely different behavior-- _and that 's not bad_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> This is a really good example of why you need a 'hacker' in your startup, in the traditional 'one who is good at building ad hoc systems' sense. Having awesome technologists who can write brilliant, well-tested and robust code is certainly useful, but a lot of the time in the early stages of a company you just don't have time. You have a problem and it needs to be solved _fast_. Most things can be fixed later when the initial traction turns in to cash. Until then, hack all the things.

Note: I might be biased because hacking things together is what I'm good at.

<comment><USER11> ... Or just should a fulfillment provider that is halfway competent. Perhaps one that isn't doing you a favor and actually does similar stuff for other people.

<comment><USER10> The point is that you can't really predict what you're going to need. Someone in the business who can pick up a problem and solve it fast, even if the solution is a hack you'll replace later, is useful. Having them around means you don't miss opportunities you'd otherwise have to pass on.

<comment><USER11> Sure, but in this instance you can 100% know what you need--a shipping fulfillment provider for B2C sales. There are hundreds to choose from, they didn't choose one.

They are happy and proud, but their slow shipping and fulfillment disappointed much of their customer base and surely cost them a lot of sales. I'm not even a customer and I knew that they were a clusterfuck. Their $500 hack probably cost them at least 100x that in revenue.

Hackers are great and valuable, but sometimes you don't need a hack you need competence.

</comment></comment></comment></comment><comment><USER12> Summary: "Fulfillment of physical goods is hard, especially when you don't know anything about it."

<comment><USER13> I agree, but it makes for a good story. It is amazing how much detail goes on behind the scenes in shipping product. A story like this where "logistics outsiders" re-create this stuff from scratch and then write about it is quite entertaining. Good for them, they figured out something that works and had a fun time doing it.

</comment></comment><comment><USER14> While I enjoy such war stories and love hacking ad-hoc systems myself, I can't help myself not to think how much time they wasted instead of going to someone familiar with shipping industry. There is a saying in my home country: "Not everyone can sing through the vilage!"

</comment><comment><USER15> Does anyone know how to get around that Excel CSV issue, where Excel will "helpfully" convert a number-like value into a meaningless value in scientific notation, even if the number was quoted like "1234"?

That was a huge pain point in a previous work that I did.

<comment><USER16> Can't you set the number format on the cell?

<comment><USER15> It's possible with .xls or .xlsx files, but csv files can't store number formats.

<comment><USER17> That is why you convert the spread sheet column to a number before you export to csv. The fulfillment center was lazy, when you paste large numbers like that into excel, it auto converts your large number into scientific notation. you simply only have to change the data type of the column and it will change it back to a number. A CSV is dumb, it only exports what Excel displays.

</comment></comment></comment></comment><comment><USER18> So it's not only $500, but $500 + John's salary which I think is far higher than this.

<comment><USER19> Makes a better story like that though. Or even "It cost us 10% of our company to even start shipping out our product, what were we thinking?" (Random guess at equity stake)

</comment></comment><comment><USER20> Does anyone know why an off-the-shelf solution like Magento or Shopify paired with a label printer wouldn't have worked? It's interesting to see the the mechanics of an early-stage startup, but this feels like a largely solved problem? Also, how did the mess of labels get matched with the specific orders, someone was just matching invoices and stickers?

<comment><USER21> Before reading the article, I was thinking 'have these dudes not heard of ShipStation?!?' But yea, to answer your question, yes, shipstation + shopify works brilliantly. One person can process and ship 60 orders in 30 minutes. 60 orders via a 3rd party warehouse with all their fees, would run you ~$150 - $200.

<comment><USER20> Thanks! I'm still a little bit confused about the problem they're solving, but I'm glad to know I'm not crazy :)

<comment><USER11> Probably because it's not a real problem, they created it entirely themselves. At least they solved it!

</comment></comment></comment></comment><comment><USER22> "As ridiculous and janky as that initial experience was, it wasn't like it was a failure on our end or on the other end. I wouldn't really see this as a shortcoming."

He can only say this because they are profitable. In reality I think they were lucky to have a product people wanted so badly. In the first 12-18 months, most of the complaints by actual Soylent customers about Soylent had nothing to do with the product itself, only the fulfillment.

</comment><comment><USER23> "A UPS tracking number is 15 digits or something like that, but a FedEx tracking number is 24 digits. If you opened it in Excel it would truncate it, because it would be like, "That is a 24-digit-number. We should store this in scientific notation.""

I am stunned that this is actually an issue even when dealing with CSV and Excel. It is quite easy to store numbers in Excel and treat them as simple text.

<comment><USER24> Excel really is horrible at handling anything that needs to feed into a software system that isn't also built on Microsoft technology. Just yesterday I was trying to get a coworker to manually order some rows in a database that I had exported to CSV by date, the problem was that some of the dates were just month-year, and some were month-year-day.

Excel insisted on formatting the columns as dates and the month-year rows would turn into month-year-day columns, turning the year into the day and using 2015 as the year.

I told him to just open up the file in a text editor, as I didn't feel like trying to figure out Excel's interface for him or coach him through an LibreOffice install.

If the person I'd needed the info from was not in the organization, as this situation had been, I'd have considered the approach unworkable and figured out a different way to get the info I needed, as they did. Figuring out and teaching people how to use Excel is not how I want to spend my time.

<comment><USER23> Well, a lot of people use Excel to prep data for other systems and it really isn't that hard to handle. Perl has excellent libraries for reading and writing Excel spreadsheets. Excel is really easy with a large amount of training material. Even the Perl libraries are very easy to use.

I would never tell a user to open up a text editor on tabular data. It is too easy to configure Excel to do the right thing each time. Basic spreadsheet formatting takes care of a lot of problems.

<comment><USER24> Let me know when Excel can do real Unicode. Ruby rejects CSVs made with Excel's default Unicode export. I had to sit with my boss last year trying out different ways to get it to work right, and eventually made him use LibreOffice to do the xlsx -> CSV conversion.

<comment><USER23> Let me get this straight. Your boss's preferred tool outputs a CSV that is rejected by your tool's CSV import and your solution is to force your boss to do the conversion in another piece of software? You being a developer and your boss being a business user doing his/her work in his/her tool. That tool being one of the biggest selling programs of all time for business use.

<comment><USER24> Yep. It was much easier than writing a layer to translate Microsoft Unicode into real Unicode. But he wasn't a business user. I wouldn't dream of telling the business users what tools to use to get me the information I need. Not because I can't, I absolutely can, but because if it's a business use case, it's worth engineering a real solution. This was just a temporary hack to get us through a tricky data problem. Installing it on his machine and working out a procedure took 10 minutes. Would have been quicker if his machine didn't have the characteristic slowness and inscrutability that Windows machines operated by non-techies exhibit. That procedure carried us through until I could work out a saner way.

</comment></comment></comment></comment></comment></comment><comment><USER25> Nice article about an awful product. I don't eat to live: I live to eat.

<comment><USER26> To each it's own. I like to enjoy a good meal every now and then, but day-to- day eating is mostly an annoying necessity. I have better things to do with my time.

</comment></comment><comment><USER27> meh. I saved $10 million with a perl script and an army of zebra printers.

</comment><comment><USER17> Don't eat soy.

<comment><USER28> Apparently Soylent doesn't contain much of either soy or lentils. It's a weird way to name a product. Sort of like making a fruit juice called "BeefPork".

(I know the name is a movie reference. Still doesn't make sense to me.)

<comment><USER26> > _I know the name is a movie reference. Still doesn 't make sense to me._

It should, since you recognize the reference, and the name fits perfectly. For me, Soylent Green pretty much the first thing that comes to mind when thinking about this type of product.</comment></comment></comment>


Year in the Life of a Kernel Maintainer (2012): Greg Kroah-Hartman - <AUTHOR> http://www.linuxfoundation.org/news-media/infographics/year-life-kernel-maintainer-2012-greg-kroah-hartman

<comment><AUTHOR> An interview with Greg Kroah Hartman: [https://www.linux.com/news/special- feature/linux-developers/...](https://www.linux.com/news/special- feature/linux-developers/600241-30-linux-kernel-developers-in-30-weeks-greg- kroah-hartman)</comment>


The Essence of Peopling - <AUTHOR> http://www.ribbonfarm.com/2015/04/08/the-essence-of-peopling/ <comment><USER2> One of the most interesting things I've ever read was about this guy who was homeless and living in the forest for a really long time. [1] He talked about how for certain periods of time, he completely forgot that he existed. Without having anybody to perform his identity to, he had no consistent self or identity.

> "I did examine myself," he said. "Solitude did increase my perception. But > here's the tricky thing—when I applied my increased perception to myself, I > lost my identity. With no audience, no one to perform for, I was just there. > There was no need to define myself; I became irrelevant. The moon was the > minute hand, the seasons the hour hand. I didn't even have a name. I never > felt lonely. To put it romantically: I was completely free."

For me personally, this makes me think that the phenomenology of selfhood is very much dependent on perception and others. To be is to be perceived. In the absence of perception, the "I" dissolves.

Perhaps "I think, therefore I am" sorta still makes sense as long as you're aware of the fact that you're thinking. But as the Hermit describes– when you're alone for a long enough period, and you're not thinking about other people, or what other people will think of you when you return, or what letters you want to write for other people, "I" stops showing up. And therefore "I" does not exist. The entity that is the person is still hanging out in the forest, but he/it has no need for a name or any consistent identity.

_____

[1] [http://www.gq.com/news-politics/newsmakers/201409/the- last-t...](http://www.gq.com/news-politics/newsmakers/201409/the-last-true- hermit)

<comment><USER3> "I think therefore I am" is actually about what it is possible to know. Descartes basically argues that the only thing you can be sure of is that you are a thinking thing.

</comment></comment><comment><USER4> Can somebody offer some cliff notes on what they got out of this?

I skimmed because frankly I'm too jaded to fully read something that doesn't start out with an introduction, telling me what's up ahead and why I should care and instead goes on and on for many pages.

The parts that I skimmed felt like the thoughts I tend to have regarding big ideas that haven't come together quite yet. There's definitely something, but it's elusive because something is missing, something big enough that it tends to cut many pages into a paragraph. That's what this feels like to me.

"In conclusion, drink tea, together with your friends; pay attention to the tea, and to your friends, and pay attention to your friends paying attention to the tea. Therein lies the meaning of life."

This is a terribly obnoxious thing to say to somebody after they've supposedly spent 20 minutes reading your article. The meaning of life?

I once read a book when I was 20 that blew my mind so hard that I spent the next year in varying degrees of telling others THEY need to do and think like I do because clearly, this feels so right and it felt so wrong prior. It was like falling in love with a new outlook on life, the infatuation takes a while to fade away.

If you're not careful, you can develop a guru complex where you start thinking you possess knowledge others need to urgently know about. That's where sentences like 'therein lies the meaning of life' come from I find.

That feeling will pass and you'll look back on having written words that imply you have life figured out and shake your head in disbelief :)

<comment><USER5> Welcome to Ribbonfarm.

</comment></comment><comment><USER6> I'm always confused by psychological references to Descartes "I think, therefore I am" statement. Isn't this instead a statement about knowledge? That is, starting from no assumptions, what can be known about the world? It's my understanding that Descartes' answer was that the fact that the questioner is currently thinking means that they must exist, and this can be used as a foundation for more knowledge about the world.

<comment><USER7> I was always taught that Descartes "I think therefor I am" quote is often misunderstood or at least misrepresented. What I was taught might be a better way to understand it is very close to what you stated. If a person can doubt the existence of everything then certainly they could doubt even the existence of themselves. Once one starts down a path of doubting then certainly everything is subject to scrutiny. What one cannot doubt is the fact they are doubting. So perhaps the quote should be better paraphrased as "I doubt therefor I am". Ive always found that helpful and while it seems you understand that point very well I just thought Id mention it because prior to such an explanation the process by which one affirms there existence because they think never made much sense to me.

<comment><USER8> Note also that Descartes expresses a fear, which he doesn't explore very much, that if he were to momentarily stop thinking, he might "cease to exist." He has a formulation along the lines of: "I exist, that's certain—but _how often?_ " The answer: as long as he is thinking, he exists. So the Cartesian affirmation of individual existence has an interesting porosity.

<comment><USER9> I think the problem goes even further. The cogito assumes an "I" that it never really establishes. "I think, therefore some thoughts exist" seems to hard to challenge, but who is to say that these thoughts are continuous or coherent, that they really define a single entity "I?"

<comment><USER10> ding! For a statement that is supposed to be free of assumptions, assuming there's a thinker instead of just thoughts, is a pretty big leap.

<comment><USER11> "When I analyze the process that is expressed in the sentence, 'I think', I find a whole series of daring assertions that would be difficult, perhaps impossible, to prove; for example that it is _I_ who thinks, that there must necessarily be something that thinks, that thinking is an activity or operation on the part of a being who is thought of as a cause, that there is an 'ego', and finally, that it is already determined what is to be designated by thinking - that I _know_ what thinking is. For if I had not already decided within myself what it is, by what standard could I determine whether that which is just happening is perhaps not 'willing' or 'feeling'? ... Whoever ventures to answer these metaphysical questions at once by an appeal to a sort of _intuitive_ perception, like the person who says, 'I think, and know that this, at least, is true, actual and certain' \- will encounter nowadays a smile and two question marks from a philosopher nowadays. 'Sir', the philosopher will perhaps give him to understand, 'it is improbable that you are not mistaken, but why insist on the truth?'"

</comment></comment></comment></comment></comment></comment><comment><USER12> This. Is. Fucking. Amazing.

For years I looked for a succinct and cohesive explanation of why Descartes is fundamentally misguided.

Just ordered my copy of 'Others in mind" ([http://www.amazon.com/Others-Mind- Social-Origins-Self-Consci...](http://www.amazon.com/Others-Mind-Social- Origins-Self-Consciousness/dp/0521729653)) referenced in article.

<comment><USER13> Thank you for your comment. I skipped after the first paragraph. I then came back to comments and was convinced to read further and I am happy I did.

</comment></comment><comment><USER14> I was quite sure this would culminate in a plea for better UX and user testing.

<comment><USER2> To be fair, there's always room for better UX.

<comment><USER14> Not disagreeing.</comment></comment></comment>


Why you should consider Syme over Facebook - <AUTHOR> http://karp.id.au/tech/2013/11/why-you-should-consider-syme-over-facebook/

<comment><USER2> Heh.. telling my peers to choose an alternative to Facebook is hard enough, telling them it also costs money will make them instantly continue using Facebook.

And they will say "If it aint broken, don't fix it" and "I don't have anything to hide, i don't need to switch".

<comment><AUTHOR> It's free!

</comment></comment><comment><USER3> Doesn't posting your public key for all to see on the internet mean any authorities you're trying to avoid giving access to your data can simply use said public key and get it anyway?

<comment><AUTHOR> To decrypt messages, you need a private key, not a public key. On Syme, private keys are only available to you, and public keys are only available to your group members. We don't have access to either one of those.

If you're interested in learning more about how our crypto system works, you can check out our white paper on Github ([https://github.com/symeapp/syme](https://github.com/symeapp/syme)).

</comment></comment><comment><USER4> What is the point of keeping your social network activity secure if using this system will make you a person of interest, which will likely increase surveillance?

<comment><AUTHOR> If you care about your privacy and are uncomfortable with the idea of someone reading your emails or social media activity, encryption is pretty much the only way to protect what you share, whether you're a target or not. I don't think that using an encryption app is enough to make you a serious, individual target.

I think the problem isn't only in surveillance -- it's in giving private companies access and control over heaps of data on our personal lives.</comment></comment>