Things on my mind. George Drapeau's Weblog

This is an entry I've been meaning to write for a while, on the topic of how bad most of us are at estimating within a given range, even when that range is generous.  Let me explain:

In the book "The Psychology of Judgment and Decision Making" by Scott Plous, he provides a quick self-test that shows that we are often over-confident about our ability to estimate, even when we're given every opportunity to define the margin of error ourselves.  In software engineering, this comes up all the time: a developer is asked to estimate how long it will take to implement a particular feature.  You know what happens: the developer says "Oh, 2 weeks," and the feature ends up taking 6 weeks to finish.  Why did the developer say "2 weeks"?  Maybe it's because s/he was afraid to say a date that sounded too long, but often it's just a matter of being overconfident about our own estimates.

Don't believe me?  Try this test yourself.  Here are the rules:


For each of the following ten items, provide a low and high guess such that you are 90 percent sure the correct answer falls between the two.  Your challenge is to be neither too narrow (i.e., overconfident) nor too wide (i.e., underconfident).  If you successfully meet this challenge you should have 10 percent misses -- that is, exactly one miss.

(for each of the following items, list both a LOW and a HIGH number; you're 90% confident that the real answer lies between your LOW and HIGH number for that item)

1. Martin Luther King's age at death
2. Length of the Nile River
3. Number of countries that are members of OPEC
4. Number of books in the Old Testament
5. Diameter of the moon in miles
6. Weight of an empty Boeing 747 in pounds
7. Year in which Wolfgang Amadeus Mozart was born
8. Gestation period (in days) of an Asian elephant
9. Air distance from London to Tokyo
10. Deepest (known) point in the ocean (in feet)

Okay, have you done it?  You can find the answers here, along with a little wrap-up of what this all means.

A funny coincidence happened to me this week: I was talking with one of my colleagues about Linux and Solaris, and why somebody would pick one over the other.  Personally, I use several operating systems on a regular basis: Solaris at work, Mac OS X when I'm mobile, Ubuntu Linux at home, and Windows XP (Service Pack 3) to track my spending with Quicken.  (I currently run that inside VMware Workstation on the Linux box, which I started using years before virtualization became the "it" term it is today).

(okay, I can't resist this side note: the first time I used Quicken virtualized, it was over ten years ago on my Sun system using WABI at first, and later the x86-based SunPC card.  Sun's been doing some kind of virtualization stuff for a long, long time.)

Anyway, the topic of "Why Solaris?" was on my mind...and then I saw this blog posting, entitled "Why I like Solaris".  It's written by a former Sun employee who tells of his experience learning Solaris after having been a Linux user for a few years.

The blog post makes some interesting points from a developer's point of view about what was missing from Solaris that put obstacles in his way, but were later fixed (the release of Solaris 10 a few years ago fixed a lot of inconveniences, for example).  But what I got out of the blog entry was the general feeling that if you develop for the platform, things are going to work for a long time to come.  Oh, also that ZFS as a development tool is pretty cool, because it takes the risk out of trying an experimental change: you just create an instant snapshot, make your changes and test them, and if you don't like the result, go back to the previous snapshot.  That's a nice debugging tool.

You can see more context by reading this blog entry on ZDNet, which addresses yet another article attacking the viability of Solaris.  It's interesting writing, worth taking a look.

Powered by ScribeFire.

A buddy of mine used to work for Yahoo! on some pretty high-traffic properties that they run.  But last year he left the company to pursue an idea he had.  His company, G-Snap!, is the result, and tomorrow afternoon at 12:30PM Pacific time, I will be using his company's technology to "snapcast" the USC vs. Arizona State college football game.

So first things first: if you wanna keep up with the game and won't be around a TV but you will have a mobile phone with a web browser, go here:

http://gsnap.com/236.

I've tried it on my Treo's browser, and it's been tested on tons of other mobile browsers as well as the major desktop browsers like Firefox, IE, and Safari.

It's hard for me to describe how fun it is to follow a snapcast; it helps if you're interested in the event itself.  You can simple go and watch the commentary, or you can login (for free) and make your own comments.  Often, I find the comments are more entertaining and engaging than the snapcaster's commentary, but you be the judge.

When you join a snapcast, you are in a live community of fans who are interested in not just the game scores but also some of the play-by-play and live commentary of what's going on.

Also, you can create your own snapcasts of anything you want.  Recently, a new user decided to snapcast the NASCAR Talledega 500 (it went really well, according to my friend).  Another recent snapcast was two people snapcasting the recent U.S. Vice Presidential Debate, with lots of viewers commenting.

You can get a better description of what G-Snap! does by reading about them here.  Or, take your browser (mobile or desktop) to the URL above and watch my 'cast and enjoy the game.

Fight On!  Beat the Sun Devils!

Powered by ScribeFire.

(this blog entry is a note-to-self kind of a thing.)

I've been using a cool Firefox browser extension called ScribeFire to write my blog entries; I like it because it's easy to write the blog entry without having to worry about writing HTML markup, and it makes it easy for you to post the blog entry to just about any kind of blogging software you want.  I usually write to my blogs.sun.com blog, which runs the Roller blogging software.

That's all good, but recently I couldn't post new blog entries with ScribeFire and I couldn't figure out why.  I'd go back into the Account Wizard, where you tell ScribeFire about your blog, including username and password.  But it kept failing on my username and password, and I was absolutely sure I had those correct.

Well, I finally figured out what I was doing wrong.  This will certainly apply to Sun employees but it may apply to others out there using Roller blogging servers.  Here's what I needed to do:

• Log into blogs.sun.com (my blogging site); recently, we switched our authentication mechanism to something all Sun employees know.
• under the "Actions" section there is a choice labeled "Edit user profile"; click on that.
• Choose a "Weblog Client API Password", which is different from the password you used to log into blogs.sun.com.  This password is what ScribeFire will use when it tries to post a blog entry for you, so you need to tell blogs.sun.com what to expect for a password.  Confirm the password and save.

There you go.  Now you can go into ScribeFire and update your settings.  Here's how I set mine:

• Open ScribeFire and click on the "Add" button under the Blogs tab; this launches the ScribeFire Account Wizard;
  
• my blog's url is "http://blogs.sun.com/drapeau"; enter yours and Continue;
• Click the Configure Manually button that appears next;
• Select "MetaWeblog API" as the blog system type (I don't know why not "Roller"; just trust me here);
• for the API URL, type "http://blogs.sun.com/roller-services/xmlrpc";
• for the Username and Password, use your username and the password you entered as the Weblog Client API Password above;

That should do it.  Now you can blog with Scribefire, which should make blogging easier and more fun overall.

Powered by ScribeFire.

I had the pleasure of meeting with an ISV yesterday who is interested in simplifying how they deploy their solution to customers.  To make a long story short, simplification for them will result in more stable deployments for their customers, who can really stress the solution of software + hardware system.  So they came to Sun to talk about our systems.

A couple of questions came out of the meeting and I agreed to follow up; I figured I'd post the answers here, because the questions are not proprietary and the answers aren't, either.

Question #1: how many power supplies on an M4000 server?
Answer: 2.  The Sun SPARC Enterprise M4000 Server has two power cords coming into the box, in what we call a 1 + 1 redundant power supply configuration.  The M4000 needs only one power cord coming into the system to power it, but we have a second power supply just in case the 1st one fails.

(by the way, the M5000 server has four power cords.  Why?  It uses two power supplies active to power the server, and each of those has a redundant power supply.)

Here are the specs for the M4000 server, which comes from the Sun System Handbook.


Question #2: what kind of monitoring interface does the M-series server have?

Answer: I hope I'm answering the question that was asked here.  I recall that one question had to do with what the console looks like when you log into it: ALOM or ILOM-style interface?  (these have two different styles of giving commands to the server when you log into the console)  According to the technical lead in our ISV Engineering Labs datacenter, the M4000's console interface looks kind of like the SunFire 6800's style, which is (and I quote) "ALOM-ish".

And here is the documentation for the M-series's console, called the XSCF (eXtended System Control Facility).

If this isn't answering the question you asked, let me know what you need to know and I'll happily track it down.

Powered by ScribeFire.