4 Beginner Tips for Doing Architecture Photography

4 Beginner Tips for Doing Architecture Photography http://digital-photography-school.com/4-beginner-tips-for-doing-architecture-photography/

A great article from Digital Photography School. I especially like the picture of the temple at dusk, wonder where that is.

Another look at IFTTT

In March 2012 (that’s a while ago) I wrote this article about a new service I’d discovered called IF-This-Then-That.

Now, almost five years on, IFTTT has come a long way. Just looking at the channels (they now call them services) it is amazing how far they’ve come. Quite amazing.

Time to go revisit IFTTT. It still amazes me that they are a free service.

Facebook at a Crossroads

Interesting article in MIT Technology review at https://www.technologyreview.com/s/603198/facebook-at-a-crossroads/.

More than half of the 3.4 billion people with Internet access log on to Facebook each month. Revenue in the first nine months of 2016 jumped 36 percent to $19 billion; profit nearly tripled, to $6 billion. Yet the company’s founder has spent the year talking up his plans to become something much larger and more meaningful.

With the election now over, the coming crackdown on fake news, and getting mired in the censorship controversy after blocking the video stream of Philando Castile after he was shot in Minnesota surely didn’t help.

I wonder how much all these things will affect Facebook, and how much that is driving the urge to do unnatural things.

Drones, Virtual Reality, get a grip …

The case(s) for and against PGP

When I read I’m throwing in the towel on PGP, and I work in security, which appeared as an Op-ed in ArsTechnica, I felt that it certainly deserved a response. While Filippo Valsorda makes some valid points about PGP/GPG, I felt that they were less about shortcomings in the scheme and rather usability issues that have been unfortunately ignored.

Then I read “Why I’m not giving up on PGP“,  an excellent article, also in ArsTechnica, and it does a much better job of refuting the article than I could ever have done.

Both are well worth the read.

May I please get whatever Windows version powers the Dreamliner?

It is being widely reported that the FAA has issued an Airworthiness Directive (AD) requiring that Boeing 787 Dreamliners must be rebooted every 21 or so days.dreamliner

This is not a hoax.

This is the AD issued by the FAA 0n 2016-09-24, I obtained a copy of this AD from here.

The AD states:

This AD requires repetitive cycling of either the airplane electrical power or the power to the three flight control modules (FCMs). This AD was prompted by a report indicating that all three FCMs might simultaneously reset if continuously powered on for 22 days. We are issuing this AD to address the unsafe condition on these products.
A little investigation indicates that this isn’t the first time the FAA has had to do this. The last time they had to do something like this was in 2015-09 when they issued this AD which I obtained from here. That AD was more specific about the reason for the problem, stating
This condition is caused by a software counter internal to the GCUs that will overflow after 248 days of continuous power.
It has been widely rumored that the present AD about the 21 day action is similarly motivated, and the logic is that a timer with millisecond precision which will overflow at about 24 days.
This is all very droll, and I hope to hell that they power cycle their planes on the ground regularly and all that. My only question is this, since they are in fact running Windows under the covers, how on earth are they able to keep the thing going for 21 days?
With Windows 7 that was a piece of cake but this new Windows 10 that I have wants to reboot every night and I don’t have any say in the matter.
So whatever Boeing did to keep the damn thing going 21 days, it would be great if they shared that with the world.

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.