Sky's Blog

Wow — I was flying down some intermediate (meaning “easy”) alpine ski run at Squaw Valley early this year when I noticed a pair of colorful skis flashing in front of me. At the top of the lift I stopped the guy who was wearing them and inquired because I noticed they were branded Lhasa skis and had a drawing of the Potola Palace on their tail.

Hmm… Tibet, mountains, snow… very cool, and this looked like fun. These are fat (also phat^[1]) skis in two senses — first, they are wide and work well in deep snow and conditions where there’s piles of snow all over the runs — and second, phat in the sense that they’d let you ski with great exhiliration and joy all over the slopes in varying conditions. (continue reading…)

During my lifetime I have gone from viewing stars thorough binoculars, and once through a 40-inch refracting telescope (Yerkes Observatory was just miles from my home – I viewed once as a child) to the amazing deep-space digital views provided by the orbiting Hubble Telescope. I watched Halley’s comet in 1986 from the deck of my home in San Francisco, through 10x binoculars. During my lifetime, scientists dealing with cosmology have advanced our thinking about how the universe (and possible 10^10^10^7 parallel universes — oh, sorry, must not forget I am actually a mathematician and the correct notation is 10¹⁰¹⁰⁷) may have gotten to its current state and where it might be going. {the photo is Phil Plaitt, the “Bad Astronomer” — thanks, Phil, for pointing me to the video which you can play below}

This music video is a trippy artistic rephrasing of how two thinkers talked about the meaning and inspiration of all of this.

Please also continue reading for footnotes and a second video where Sir Arthur C. Clarke, Stephen Hawking and Carl Sagan discuss the universe…

(continue reading…)

Being a user of and a promoter of cloud computing, I am also aware of challenges to the security of cloud computing environments. Cloud computing suppliers come in several flavors. I’ll address two of them here: 1) those who provide virtual hosts; and 2) those who provide automatically-scalable hosting solutions without distinguishable hosts.

A virtual host looks like an actual server. You (or your programmer/sysadmin) can use it as if it were your own dedicated server. In fact, however, it is only a portion of a much larger server. Rackspace/Mosso, and Slicehost are two I’ve discussed and actually use. The focus is on the virtual server.

An automatically-scalable hosting solution is a service or set of services which are hosted on one or more computers, and you can’t actually tell how big the server is or for that matter, whether it’s a whole array of servers. The focus is on the virtual service (not the server itself).

What’s good: Virtual servers are a more secure environment than shared servers because you are only dependent on your own security efforts. (On a shared server, if another user picks a poor password, or doesn’t upgrade their PHP software when security upgrades are released, you can be hacked if their account is compromised.) Automatically-scalable hosts may also be secure in this same way if accounts are adequately protected from each other.

What’s bad: A root compromise of a virtual server may be possible. In fact, it’s probably inevitable that such things will happen. And if you don’t update your underlying software (like WordPress, for instance), they you’re likely to be in trouble anyway. So ultimately any server can be compromised.

I’ve written about “economic denial-of-sustainability” attacks, in which an attacker causes a cloud user to so scale up their server usage that it becomes economically impossible for the defender to survive. These wouldn’t be possible if there were no cloud computing.

When all data for Sidekicks got lost recently [read this article in the Wall Street Journal] was it a cloud failure or was it a single system failure?^[1] [also New York Times article]

In the sense that data was being stored somewhere and the customer didn’t know where it was, then yes it was a cloud failure. But I contend that it was also a failure caused by the existence of a single-point-of-failure. (As system developers, this is our constant nightmare.) The product/service was set up to use a single data service with (apparently) inadequate backup. That created the possibility of this single-point-of-failure. The real failure was that T-Mobile didn’t provide the option to back up your data in a location under your control, so that you could later on restore it if the central service went down. (continue reading…)