The Monty Hall problem

I’ve long wanted a simple explanation of the Monty Hall problem and I’ve never found one that I liked. Some I really detested like one that tried to make some lame analogy to baseball pitchers.

Anyway, here is what I’ve found to be the simplest explanation yet. First, what’s the problem.

In a game show, the contestant is shown into a room with three identical closed doors. He is informed that behind one door is a prize and behind the other two doors, there is nothing.

He is then asked to pick a door. Once he has picked a door, the host proceeds to open one of the other two doors (that he had not picked) and shows the contestant that there is nothing behind that door.

The host then offers the contestant the option of either changing his selection (picking the third remaining door), or sticking with his initial choice.

What should the contestant do?

The simplistic answer is that once the contestant has been shown that there is nothing behind one door, the problem reduces to two doors and therefore the odds are 50-50 and the contestant has no motivation to switch.

In reality, this is not the case, and the contestant would be wise to switch. Here is why.

image1Three doors, behind one of them is the prize, behind the other two, there is nothing.

The contestant now picks a door. For the purposes of this illustration, let’s assume that the contestant picks the door in the middle as shown below.

image2Since the prize is behind one of the three doors, the odds that the prize is behind the door that the contestant has picked is 1/3. By extension therefore the probability that it is behind one of the other two doors is 2/3 (1/3 for each of the doors).

So far, we’re all likely on solid footing, so let’s now bring in the twist. The game show host can always find a door behind which there is nothing. And as shown below, he does.

image3The game show host has picked the third door and there’s nothing there.

However, nothing has changed the fact that the probability that the prize was behind the door that the contestant chose is 1/3 and the probability that it is behind one of the other two doors is 2/3. What has changed is that the host has revealed that it is not behind the door at the far right. If then the probability that it is behind the far left door and the far right door (the two doors that the contestant did not pick) is 2/3, we can say that the probability that it is behind the far left door has to be 2/3.

With this new information therefore, the contestant would be wise to switch his choice.

Defining Success in OpenStack (With Heisenberg in Mind)

This article first appeared at http://www.tesora.com/defining-success-in-openstack/

I recently read Thierry Carrez’s blog post where he references a post by Ed Leafe. Both reminded me that in the midst of all this hand wringing about whether the Big Tent was good or bad, at fault or not at fault, and whether companies were gaming the system (or not), the much bigger issue is being ignored.

We don’t incentivize people and organizations to do the things that will make OpenStack successful, and this shortcoming poses a real and existential threat to OpenStack.

Werner Heisenberg observed that the act of measuring the position of a sub-atomic particle affected its momentum and vice-versa. In exactly the same way(s) that Heisenberg said, the act of measuring an individuals (or organizations) performance in some area impacts that performance itself.

By measuring commits, lines of code, reviews and other such metrics that are not really measures of OpenStack’s success, we are effectively causing individuals and organizations to do the things that make them appear “good” on those metrics. They aren’t “gaming the system”, they are trying to look good on the measures that you have established for “success”.

At Tesora, we have always had a single-minded focus on a single project: Trove. We entered OpenStack as the DBaaS company, and have remained true to that. All the changes we have submitted to OpenStack, and the reviews and participation by Tesora have been focused on the advancement of DBaaS. We have contributed code, documentation, tests, and reviews that have helped improve Trove. To us, this single minded focus is a good thing because it has helped us advance the project, and to make it easier for people to deploy and use it in practice. And to us, that is the only thing that really matters.

The same thing(s) are, true for all of OpenStack. Actual adoption is all that matters. What we need from the Technical Committee and the community at large is a concerted effort to drive adoption, and to make it easier for prospects to deploy and bring into production, a cloud based on OpenStack. And while I am a core-reviewer, and I am the Trove PTL, and I wrote a book about Trove, and our sales and marketing team do mention that in customer engagements, we do that only because they are the “currency” in OpenStack. To us, the only things that really matter are ease-of-use, adoption, a superlative user experience, and a feature rich product. Without that, all this talk about contribution, and the number of cores and PTL’s is as completely meaningless as whether the Big Tent approach resulted in a loss of focus in OpenStack.

But, remember Heisenberg! Knowing that what one measures changes how people act means that it would be wise for the Technical Committee to take the leadership in defining success in terms of things that are surrogates for ease of installation, ease of deployment, the number of actual deployments, and things that would truly indicate the success of OpenStack.

Let’s stop wasting time defending the Big Tent. It was done for good reasons, it had consequences. Realize what these consequences are, perceive the reality, and act accordingly.

10 ways to make Windows computers safer

These days everyone knows someone whose computer was hacked; everyone has heard of others who have been hit by ransomware, and who have suffered significant losses as a result. The losses are sometimes financial, but often they are non-monetary, like losing all family photographs, music, files, and so on.

While it is not possible to entirely prevent these kinds of things, there are some easy steps that we can all take to considerably minimize the likelihood of this kind of thing. It is however equally the case that the majority of these things also make it a little harder to use our computers, and this is by design.

The primary reason why people fall victim to these attacks is complacency, or letting one’s guard down for just a moment. The simple tips below try to prevent that by making it just a little bit harder for you do yourself harm in this way. So here are some tips that I believe we can all take to improve our computers security. I write them from the perspective of a Windows user; if you are a user of a Mac, similar things apply to you but I don’t use a Mac so I don’t know what they are. And, if you are one of those few Linux users, you are likely a nerd anyway and probably can figure this stuff out for yourself.

There used to be a time when the #1 way to make Windows computers safer was to move to a Mac. That is unfortunately not true any longer. Macs are also vulnerable to many of the exploits that we see these days.

  1. Don’t login as an Administrator user; restrict administrator privileges

One of the horrible things that Windows does on initial installation is to ask you for your name, and setup an account for you. And it makes that user an Administrator. In my experience, most home computer users regularly login using that account.

When setting up a computer, always create a user who will be an administrator, and after the computer is setup, create a regular user who is a standard user. It should look something like this when you look at the users settings.

If the account(s) that are commonly used on your computer are Administrators, do this:

  • Create a new user on your machine with a name like “MyComputerAdministratorDingDong” and make that user an Administrator.
  • Login as “MyComputerAdministratorDingDong” and change the accounts that you regularly use to be a Standard User. If this is a shared computer, this means all users become Standard Users.
  • Ensure that the password MyComputerAdministratorDingDong is long and different from your own password; and don’t tell everyone what it is.
  • Update Windows User Account Control (UAC) to be paranoid and prompt you on all changes to the computer.

What have you accomplished here?

By making all common users Standard Users, you have made it harder for exploits which typically require Administrator privilege to, well, exploit.

When someone wants to install software, make changes to your computer, and so on they will need to be the Administrator, and will need the password to the “MyComputerAdministratorDingDong” account. This does make it mildly harder to use the computer, but it is a worthwhile safeguard.

  1. Look at all the software on your machine and uninstall things that you don’t recognize

Over time, computers accumulate cruft. And if your computer wasn’t secured as described above, you are likely to find lots of cruft. Uninstall anything that you don’t recognize, or don’t use now.

What have you accomplished here?

In addition to potentially making your computer quicker, you have also removed all potentially suspicious software from your machine. Should you need one of them later, you can certainly add it back.

  1. Get yourself a good Anti-Virus software package

It is amazing that this is still something one has to list. Most ISP’s offer Anti-Virus free, download and install one. If your ISP doesn’t purchase one and install it.

Windows 8 and 10 come with Defender. In my experience they are not quite as good as commercial Anti-Virus software packages. While Defender is free, it is worth getting something else at this stage; maybe someday soon Defender will be better.

What have you accomplished here?

Anti-virus software is an essential part of your protection plan.  Make sure you have one; and Windows Defender isn’t (today) the answer.

  1. Change your WiFi password and make it something that is hard to guess, preferably obscene

This should be self-explanatory but passwords like “password”, “homewifi”, and “xfinity” are just too easy to guess! Make it something that is hard to pronounce, uses numbers and punctuation.

My preference is to make it something obscene, that way you won’t be yelling it out to people you meet.

That last thing is something I advocate for all passwords, make them words that you will not utter in public; does wonders for password security.

What have you accomplished here?

Getting on a network with other computers is one of the ways in which a bad actor could infect your computers. By making it harder to get on your network, you have added a layer of protection to your network.

  1. Only allow secure computers on your homegroup, and your home WiFi network

Most households with more than one computer likely share a homegroup and share files, music, and pictures on the homegroup.

If you are not able to secure a computer (as described above) kick that computer off your homegroup, move them to a Guest WiFi network.

So, what do I do about my internet connected TV’s, phones, and other devices which I can’t secure in this way. You could do one of two things, either get another cheap WiFi access point for those, or put them on the Guest WiFi network as well.

What have you accomplished here?

Your homegroup should be a safe space. By eliminating all potentially unsafe actors from the homegroup, you have improved the level of safety there.

  1. No matter how you read email, don’t click on links that you don’t recognize

Phishing, link highjacking, and numerous other nasty things that cause harm to your computer are caused by clicking on links. So if you receive email that includes links, buttons, and other calls to action, think before you click. Hovering over a link or a button will typically reveal what the action will be.

There is no easy way to tell someone how to recognize a fake email message; scammers are quite sophisticated these days. So just be safe and don’t click on things unless you are really sure you know what you are doing.

But, you can remember these simple tips:

  • Banks, Financial Institutions, and most legitimate businesses will address emails to you by name; not “Dear Customer”. If the email does not address you by name, it is likely bogus.
  • If you get an email saying your account has been terminated, will be terminated, has been compromised and you need to take immediate action, don’t click on the link provided. Instead find the link to login to whatever account, institution, or website and login directly. If the link is real, that’s fine, you at least know where you are going. And if it is a fake, you will realize it very quickly when you find that your account is fine!
  • If you get email saying “someone in your contact list has shared a document with you” it is a fake; services like Dropbox will tell you who shared the file with you.

What have you accomplished here?

Many exploits require you to take an action that triggers the installation of the bad software. By taking these steps, you have made it harder for this to happen.

  1. Disable automatic downloads, disable automatic showing of images

Web browsers and email clients allow you to set these privacy options. And they are well worth setting.

Search for directions for your specific browser and email client and make these changes.

What have you accomplished here?

Many exploits require you to take an action that triggers the installation of the bad software. Automatic downloads and infection buried in some image file formats are one way in which bad actors get around this. By taking the steps described here, you have made it harder for this to happen.

  1. Enable a screen-saver (with a lock and a timeout)

This is particularly important for laptops and computers in shared areas. Enable a timeout and a lock screen. When you step away from the keyboard, lock the computer (Windows Key-L). Require a password to unlock the computer.

What have you accomplished here?

An unlocked computer is an invitation for someone to meddle. A locked computer (with a good password) is significantly harder for one to damage.

  1. Disable autoplay USB

One of the most common sources of malware, viruses, and other nasty stuff is shared USB drives. Disabling autoplay along with the steps above can significantly improve the security of your machine.

If you are given a USB drive, consider the source carefully. I prefer to just say “No” and ask people to email the document(s) to me, or to put them on a shared drive like Dropbox.

What have you accomplished here?

Recently a new breed of exploits merely require someone to plug in a rogue USB stick into your machine and the malware gets automatically installed because of autoplay. By disabling autoplay, you make this harder (not impossible).

  1. Disable USB ports

And if you want to be truly sure, here’s what I do with my laptop when I travel. Reboot the machine to BIOS and disable the USB ports.

That way, when the friendly gentleman comes along and gives you a document on a USB stick, you can safely say it doesn’t work (then blame your IT department for it). If the person insists that he can fix it, you are still safe because no matter how much he jiggles the USB stick in the port, it won’t work.

On one occasion, a particularly persistent (read: pesky) individual said he knew what was wrong, that the port was disabled in the BIOS. And he went to reboot the computer to BIOS and sure enough “My IT Department” had set a password on that and damn them because I don’t know what it is.

What have you accomplished here?

Similar to the earlier step, you make it much harder for bad actors to infect your computer using the USB port as the attack vector.

As you can likely see, each of these steps will make it just a little bit harder to use, and enjoy your computer. But as the adage goes, “no pain, no gain”.

Enabling hacking extensions: The right way

Of late, I wake up every morning revving to go and work on the next cool thing in Trove and I see that overnight some well-meaning person has contributed a change that looks something like this:

String interpolation should be delayed to be handled by the logging code, rather than being done at the point of the logging call.
Ref:http://docs.openstack.org/developer/oslo.i18n/guidelines.html#log-translation For example:
# WRONG
LOG.info(_LI(‘some message: variable=%s’) % variable)
# RIGHT
LOG.info(_LI(‘some message: variable=%s’), variable)

And the code submitted fixes a small number (lets say 5) places where strings sent to logging are rendered.

As I said at the TC-Board meeting in Barcelona, these well-meaning people are actually submitting what on the face of it appear to be valid corrections to the code. Yet, I submit to you that these changes represent a scourge that we should stamp out.

I know for a fact that in Trove there are (currently) 751 occurrences of this particular style error. This is the hacking extension H904, and when enabled in Trove, I get this:

$ tox -e pep8 | grep H904 | wc -l
751

That’s the catch, Trove does not enable this hacking extension. A quick look indicates that only Neutron does.

Why are these well meaning changes a scourge? Here’s why …

  • They don’t materially improve a project to fix a small fraction of these errors without preventing them from reoccurring
  • Each of these changes takes some considerable CI resources to verify and get approved
  • Each of these changes take time for someone to review, time which could be better spent if we were to fix these problems properly.

So, I submit to you that if you want to submit a patch to fix one of these hacking issues, here is the right way. Of course, I’m opinionated, I’m going to reference one of my own changes as an example!

  1. If your project does not have hacking extensions, this commit shows you what you have to do to enable that. You may have to bump test-requirements.txt and update the version of hacking that you use in order to use the ‘enable-extensions’ option.
  2. Enable the hacking rule or extension for the particular style issue at hand; let’s illustrate with H203. H203 ensures that we use assertNone() and not assertEqual(None, …).
  3. Run the pep8 test against the project and find and correct all places where the failure occurs. Typically this is accomplished by just running ‘tox -e pep8’.
  4. Test that the code does in fact work as expected; correcting style guidelines can introduce functional errors so make sure that the unit tests pass too. Typically this is accomplished by running ‘tox -e py27 -e py34’.
  5. Actually exercise the system; launch a system with devstack and the project enabled, and actually exercise the system. In the case of Trove, actually build a guest and launch a database or two.
  6. Then submit your change including the change to tox.ini that enables the hacking rule for review.

Well, that’s a lot of work! Sure, you really have to work for your Stackalytics credit, right? I’m sure the load on the CI system will show that this is worthwhile.

It is better to do things this way in the long run. With the hacking rule enabled, future commits will also comply with the rule (they will fail pep8 if they don’t). And that will put an end to the cottage industry that has sprung up around finding these kinds of errors and fixing them one at a time.

In conclusion I urge reviewers in all projects to summarily reject style changes that don’t also enable a hacking rule. Approving them is the wrong thing to do. Require the contributor to enable the hacking rule, and fix the problem the right way. That’s what a good code review is about.