Remote X11

I have a main Linux box running Mandriva 2009.1, and I wanted to set up Linux on a second computer in such a way that I could be sitting at the second computer running programs off of the main computer — kind of like remote desktop, only this would be program by program instead of the whole desktop.

I had seen that magic work before (you just ssh to the other computer and run the command, and it shows up in your local display — I think there’s some kind of forwarding going on); but this time I wanted to add a second kind of magic: I wanted the secure shell session to happen without having to drop to a shell and type a password interactively.

I had seen both kinds of magic working before, just not simultaneously.

Magic A

The magic of running a ssh session without having to interactively type a password is explained on the ssh man page.  It involves the following steps:

1. On the second computer, I ran ssh-keygen (with no master password, for now anyway).  This created (among other things) a ~/.ssh/id_rsa.pub file
2. I copied the contents of the id_rsa.pub file to my home folder on the main computer in a new file called ~/.ssh/authorized_keys .
3. I set the file permissions on the authorized_keys file so that only my user had any permissions (otherwise ssh ignored the file and prompted interactively for a password anyway!)

Now I could ssh from the second computer to the main computer without typing a password.  The stage was set for Magic B:

Magic B

Now on the second computer I made shortcuts for Firefox and Thunderbird on the main computer.  The commands in the shortcuts were:

ssh -f maincomputer mozilla-firefox

ssh -f maincomputer mozilla-thunderbird

Now when I click on those shortcuts, the programs run on the main computer but are displayed on the second computer, only slightly slower than on the main computer (maybe I’ll upgrade to a Gigabit internal network sometime).  Nice!

Forked process

I (along with 34 others) was let go from my company last Wednesday:

I really benefited from my time at Ontario.  Here’s a quick list of some things I had the opportunity to experience and be part of during my four years there:

I saw firsthand the positive effect of peer review on code quality (and got to see code walkthroughs as well and draw comparisons);

The discipline of writing up detailed design documents and test plans helped my technical writing skills grow;

I got to participate in an effort that brought an integration testing framework and tests to a codebase that hadn’t had that before;

I got to work on my people skills (trying to learn how to do healthy conflict instead of just “getting mad”);

I began to think about business and not only technical issues;

I got an introduction to mocks and used a code coverage tool for the first time;

I had opportunities to try to help people (QCAs, technical documentation folks, etc.);

There were good working relationships and many good conversations at the whiteboard about design issues.  Those sketches have long since been erased, but the memories remain.  I wish the company the best going forward.  Thanks for a great four years, Ontario!

Sincerely,

-Daniel-

Masters of the simple

Are you a computer person?  It doesn’t matter if you’re a systems administrator, computer programmer, web designer, computer hobbyist… to friends and family you’re one of those “computer people”.

Do your less technically-minded friends and relatives somewhat revere you for your technical knowledge?  Do they sometimes say self-deprecating things about how they’re not as smart to figure out all that computer stuff?  Do you find yourself starting to believe it?

There’s something that should keep us “computer people” humble, though:  we’re masters of a simplified universe.

Simplified?

Yes.  In our world, the lines are sharper, more clearly defined.  Sure, there are discussions over coding style and best practices — but generally either the code is valid syntax or it’s not.  Yes, a well-designed and flexible system is nontrivial to produce — but I contend it’s still much simpler than dealing with the real world in all its complexities.

As examples of how we expect to live in our simplified world, look how we react when:

• The project needs to go a different direction due to new business priorities
• We have to change our approach due to a change in the law
• The sales team makes a sale that requires extra development work to be done

Do we typically say, “Of course, this is how the real world is — we’ll roll with it”?  Or do we say, “Hey, what’s this nonsense?  They shouldn’t do that!! “  …as if the way things are supposed to be is that there are no business realities or legal realities or economics realities, only technical realities.

We don’t like it when the real world intrudes, do we?  These types of issues have no place in the virtual machine we try to live in as “computer people”. But these types of issues are real, and it takes skill and wisdom — a kind of skill and wisdom I, we, tend to lack — to navigate them well.

Humility fodder.  I can always use it!

Linux window-specific behavior

When launching an rdesktop session from my Linux box, I wanted it launch fullscreen.  I’ll tell how I did it at first and then give a simpler solution.  [Note: I wrote most of this in April and May when I was running Mandriva 2009.0, but I didn't write down exactly how I'd gotten to things, and now that I'm running 2009.1 the path to get to things is slightly different.  I've updated the post to speak in terms of the 2009.1/KDE 4.2 ways of getting to these settings.]

How I Did It At First: No Border

Whenever I ran rdesktop I would then need to go to the window’s system menu to some Advanced submenu and choose the No Border setting.

An Improvement: Saving Window-Specific Settings

At some point I finally got tired of doing this every time I ran rdesktop and wished for a way to make my change stick so I didn’t have to do it every time.  Well, in KDE (I’m not sure about other window managers) there are “Window-specific settings” you can save.  So again on the window’s system menu, I chose Configure Window Behavior -> Window Specific and clicked Modify.  That took me to this configuration dialog:

I set No Border to Remember.  Now when I launched rdesktop I could go to the system menu and choose Advanced -> No Border and the next time it remembered this setting and automatically launched borderless.  Nice!

Except… sometimes I wished to de-borderlessify the window, and I couldn’t figure out how (though I did find I could hold down Alt and use the mouse to drag the borderless rdesktop session to a corner of the screen!).  It seems that borders are sometimes difficult to re-erect once you’ve taken them down…

A Simpler Solution: Toggle Fullscreen Mode

There may be some hotkey that lets me get the system menu back after choosing No Border*, but I found a solution that fits my needs better: simply toggling rdesktop fullscreen mode using Ctrl+Alt+Enter.  That way I can usually run in fullscreen mode but quickly have a normal window again when needed.

*(Actually, Alt+F3 normally brings up the system menu even if you have No Border, but rdesktop is different because it intercepts such key sequences.  That’s why I had to go the circuitous route.)

Clearing window-specific behavior

Great, but by now I had set No Border on the rdesktop window as a permanent setting.  I needed to figure out how to clear that setting.  It turns out that the place was:

Configure Your Desktop -> Window Behavior -> Window-Specific -> Modify -> Preferences and deleting the item “Window settings for rdesktop”.

Then I could run rdesktop like normal and simply press Ctrl+Alt+Enter to toggle fullscreen mode.

Book review: Software Estimation

This review covers Software Estimation by Steve McConnell (Microsoft Press, 2006).

Summary

McConnell says:

[T]he typical software organization is not struggling to improve its estimates from ±10% to ±5% accuracy.  They typical software organization is struggling to avoid estimates that are incorrect by 100% or more (p. xv).

And

I wrote this book for developers, leads, testers, and managers who need to create estimates occasionally as one of their many job responsibilities.  I believe that most practitioners want to improve the accuracy of their estimates but don’t have the time to obtain a Ph.D. in software estimation…If you are in this category, this book was written for you (p. xvi).

The first five chapters introduce some basic concepts:

1. Chapter 1, “What is an Estimate?”: You can get into some confusing situations when some of you are talking about an effort estimate and others are talking about a plan to hit a target.  This chapter explains the difference between estimates, targets, and commitments.
2. Chapter 2, “How Good an Estimator Are You?” presents a quiz that helped me see that “90% confident” wasn’t what I thought it was!
3. Chapter 3, “The Value of Accurate Estimates”, goes to some length to demonstrate the value of knowing the size of the project you’re embarking on, and the great cost to an organization that thinks a project will be significantly smaller than it turns out to be.
4. Chapters 4 introduces the four general answers to the question “Where Does Estimation Error Come From?”  In this chapter was a helpful and thought-provoking flow of questions beginning with these:
   

   • When telephone numbers are entered, will the customer want a Telephone Number Checker to check whether the numbers are valid?
   • If the customer wants the Telephone Number Checker, will the customer want the cheap or expensive version of the Telephone Number Checker? (There are typically 2-hour, 2-day, and 2-week versions of any particular feature — for example, U.S.-only versus international phone numbers.) (p.34)

   This chapter also introduces the concept of the Cone of Uncertainty, where the maximum precision of an estimate is impaired by not knowing what the project consists of. To get to a more accurate picture of how big the project is, you have to narrow that uncertainty. McConnell explains, “The Cone of Uncertainty doesn’t narrow itself. You narrow the Cone by making decisions that remove sources of variability from the project” (p. 39).

5. Chapter 5, “Estimate Influences”, introduces the concept of diseconomy of scale and discusses personnel and other factors that influence the amount of effort that will be required to complete a project.

I was going to stop the chapter summaries after the first five, but some of the next chapters have such good meat in them too…

• Chapter 7, “Count, Compute Judge”, introduces the concept that counting yields more accurate results than computing a number and computing yields more accurate results than expert judgment.  This theme comes up again other places later in the book.
• Chapter 8, “Calibration and Historical Data”, introduces the importance of collecting historical data on your projects and  gives details, guidance on what data to collect, and pitfalls to avoid.  Historical data is another theme that comes up many times throughout the rest of the book.
• Chapter 9, “Individual Expert Judgment”, offers a standard formula to use when you perform expert judgment estimation, so that you factor in best case, worst case, and expected case estimates with proper weight

Chapter 10 covers another quick and helpful technique — Decomposition (and its brother, Recomposition); Chapter 15, “Use of Multiple Approaches”, gives an example of using a combination of decomposition and expert judgment (p. 166) — a combination I have found helpful in my own estimating.

Chapters 18 through 20 cover special issues in estimating size, effort, and schedule, respectively.  Chapter 21 (p. 245) introduces a way of dealing with schedule risks (things that could come up and delay the project) by weighting them by the amount of time they would delay the schedule, times their probability of occurring, yielding a “Risk Exposure” (so for example a two-week potential delay that is 25% likely would have a 0.5-week Risk Exposure.  Using this concept you can figure what kind of contingency buffer your project is probably going to need.

Chapter 21, “Estimate Presentation Styles”, has several helpful ideas in it, such as an estimate with risk quantification, for example “+1 month if the graphics-formatting subsystem is delivered later than planned” (p.252), and “Don’t try to express a commitment as a range” (p.257).

Gold

Chapter 23 is gold.  McConnell talks here about people stuff — why negotiations between technical staff and executives tend to be difficult for technical staff to navigate. “Estimate negotiations tend to be between introverted technical staff and seasoned professional negotiators” (p. 259).  McConnell then gives some help on how to engage in win-win negotiation with executives: keeping the best interests of the company in mind, positive assertiveness, taking schedule requirements seriously, and maintaining  the courage to tell the truth.

A couple of quotes:

You hold the key to a vault of technical knowledge, and that puts the responsibility for generating creative solutions more on your shoulders than on anyone else’s.  It’s your role to propose the full range of possibilities and tradeoffs (p. 266).

Avoid saying, “No, I can’t do that”; instead, redirect the discussion toward what you can do.  The more options you generate that support doing what’s best for the organization, the easier it will be to show that you’re on the same side of the table as the person you’re problem solving with (p.268).

Themes

These ideas come up time and again throughout the later chapters

• The value of historical data from your own company’s projects for accurate estimates
• Prefer counting over computing and computing over expert judgment
• Using a range to express uncertainty in an estimate
• Taking care not to mislead by presenting a level of precision in your estimate that does not reflect the true precision.  (For instance, if your estimation techniques produce an estimate of 573.275 hours, you would probably want to present that as 575 or 600 hours)
• The limits of estimation
  Chapter 20 clarifies the purpose and limits of a schedule estimate:

  The purpose of the schedule estimates in this chapter is not to predict your final schedule to the day but to provide a sanity check on your schedule-related plans.  Once you’ve used schedule estimation to ensure that your plans are reasonable, detailed planning considerations (such as who is available when) will take precedence over the initial schedule estimation described  (pp. 230-231).

  And again in Chapter 21:

  Recognize that these allocations of effort to phases are approximate. They represent useful starting points for planning. Once the estimates get you into the right planning ballpark, detailed planning considerations should take precedence over these initial estimates (p. 237).

The book covers both iterative and sequential project styles.

A Peril Averted

As I read in the first few chapters about the dangers of corporate wishful thinking regarding estimation and scheduling and began to dig into the smorgasbord of techniques that are available to get a picture of the size of a project, my pride began to swell and my attitude began to sour.  Chapter 23, “Politics, Negotiation, and Problem Solving”, was like an unexpected bucket of cold water on the head that snapped me out of my arrogant stupor and really helped to put the lessons of the book into proper perspective.  My recommendation: don’t skip this chapter!

Overall

It’s small (270 pages of main text) and a quick read that makes a wealth of study accessible — McConnell pulls from many sources to give  organizations the tools they need to get a lot better at project planning, without having to take a lot of time to get up to speed on what he calls the “science of estimation”.  Well worth the small investment of time and money.

Scanner install bomb

I intended to call this post Installing a scanner on Linux, but I hit a dead end.  The details of my attempt are first, followed by some ponderings.  I wrote the bulk of this article back in February of this year.

---

I just purchased a used HP scanjet 2400 color scanner and brought it home to hook it up to my Mandriva 2009.0 Linux box.

The Installation Attempt

Let’s see how it goes (I have the driver CD from HP, but I’m going to just hack around first and see if that’s quicker):

1. I went to “Configure your Computer” and on the Scanners page it said to configure scanners the SANE (drivers?) needed to be installed.  I consented, and a quick 1.5MB download ensued.
2. I ran XSane in case no setup was needed, but got this message:
3. I tried again (just in case), but got the same message. :)
4. I also notice that the scanner does not show up in the “Devices recently plugged in” window in the corner of my screen…
5. I pressed Help on the XSane No Devices Available message box, and got this message:
6. Back at the Mandriva Configure Your Computer -> Scanners area, I decided to try Add a scanner manually… but the HP 2400c was marked UNSUPPORTED (and said so when I selected it and tried to go on).
7. A web search turned up a post on the Ubuntu forums pointing to a driver and instructions at elcot.in.
8. But, hmm, that download says there’s HP software in it, and I’m not sure if it would be legal.  (Can elcot.in transfer their license to unlimited numbers of others?)

Bigger Questions

I think next time I’d check the SANE project list of supported scanners before I purchased a scanner.

But……this experience has me asking questions.  In some senses, running Linux is about supporting the ability to have choices.  But then in other ways, running Linux limits my choices.   What does it mean?  Hmm.

World-class code

Someone asked me to define world-class code.  Here’s what I say:

World class code to me is code that you’re rightly not afraid of changing.

Longer answer:

There is code that you should be afraid of – I’ve maintained code before where I was not afraid of it but a more seasoned developer was, and the more seasoned guy was right: once I learned the code more and realized the obscure and unexpected effects my changes often had on the system’s functionality, I became afraid of the code too.

Code that is difficult to change without breaking something drains an organization’s energy away from innovation as more stress and struggle and people power is needed to keep the existing system running.  Abandoning the code base is expensive; it’s also risky: will you really do differently with the new system?

The only way I know to make world-class code is with automated unit tests and integration tests (in the enterprise application domain, at least –  maybe you don’t have to write unit tests to have world-class web apps, I don’t know).  These let me make a change and find out what it did to the unit and to the rest of the system, quickly.  The automated testability also drives cleaner designs, in my experience: If your code is not world-class, it will be a pain to write the unit tests for in the first place, so you’ll know earlier that your design is lacking.  So, though not all thoroughly unit tested code is world class, once you have tried to write good unit tests you can tell from your experience doing so whether your code is world class.

(I am indebted to Michael Feathers’ Working Effectively with Legacy Code (Prentice Hall, 2005) for getting me thinking along some of these lines.)

Invisible tooltips

I recently installed Linux (Mandriva 2009.1) on a new PC and moved our home directories over to it so we’d keep our settings, email, etc.  When I did this, everything mainly worked fine, except that the tooltips (if that’s what they’re called) when I hover over an item on the task bar showed up with black text on black background, something like this (simulated ’cause I didn’t take a screenshot at the time):

My wife’s desktop looked fine, so I figured it was some setting of mine rather than a bug in Mandriva or KDE 4.

It turned out all I needed to do was right-click the desktop and pick Appearance Settings:

and then choose Aya (or Oxygen):

Now the tooltip text is visible:

Rabbit trails (for those interested in how the solution was found)

I had fiddled with Configure Your Desktop -> Colors, but nothing seemed to have an effect on the taskbar’s colors.  I had recently read about something called “plasma” in KDE 4, which the taskbar is maybe part of.  I thought maybe the plasma stuff has its own color scheme, separate from generic tooltips.  Browsing through the search results from googling mandriva plasma colour settings, I found this article, which took me to a settings area I’d never been to before: Configure Your Desktop -> Advanced -> Desktop Theme Details.  I couldn’t at first figure out what to do in here, but when I changed a setting and clicked Apply, I got this dialog:

“Open the desktop Appearance Settings”… hmm… that got me exploring around (I went first to Configure Your Desktop but couldn’t find the setting, so I right-clicked on an empty area of the desktop and got the context menu, chose Appearance Settings, and picked a theme (the theme was blank when I first went there).  Fixed!

An incomplete cost graph

Some co-workers and I recently finished Software Estimation by Steve McConnell (Microsoft Press, 2006).

In Chapter 3, “Value of Accurate Estimates”, the book contains a graph of the extra cost of underestimating vs. the cost of overestimating, something like this:

On the left side, the graph pictures a nonlinear increased costs of underestimating (you don’t schedule enough time for the work; more errors introduced, more status meetings, those types of things).  On the right side, the graph pictures a linear increased cost of overestimating: you pay your employees longer before the project is done (Parkinson’s Law).  McConnell says “In software, the penalty for overestimation is linear and bounded…But the penalty for underestimation is nonlinear and unbounded“(p. 24).

My Misunderstanding

As I look at it now, I believe that when I looked at McConnell’s graph I failed to distinguish in my mind between the cost of an incorrect estimate of effort and the cost of a too-aggressive or too-leisurely schedule.  McConnell is contending that there is great value in having accurate estimates, and great cost to an organization that does not realize the true size of a project it undertakes.  What he did not say (but in my mind I extended his statements to say) was that a larger effort estimate translates linearly to a larger project timeline.  In other words, in my mind instead of saying

Don’t underestimate your project’s size

I read it as

Don’t go for aggressive project schedules

Again, McConnell did not say the latter, but I inferred it.  Let me explain why I think I erred in doing so.

Why An Aggressive Schedule?

There are big costs to an organization that doesn’t develop at a fast enough pace.  Here are a couple I can think of:

• The cost of lost business due to your competitors getting ahead of you.  This would take the form of lost sales now (the product isn’t ready so your prospect chooses a different solution) as well as lost future sales (if the prospect had chosen you now and were happy with you over time, they would tend to purchase more licenses, buy ancillary offerings, etc.)
• The cost of losing your market leadership position. How valuable is it to a company to be the clear leader among its competitors?  Once you lose that status, it must take great effort, possibly over a period of years, to gain it back.

These costs are nonlinear and unbounded as well.  Suppose we could estimate the strategic cost to the organization in addition to the technical cost.  We might get a cost graph like this, with the schedule increasingly aggressive toward the left and increasingly leisurely toward the right:

(The red is the increasing strategic cost to the organization of pushing the date out.)

This graph assumes that the project schedule corresponds linearly to effort, which is pretty simplistic (there is a whole project management discipline that deals with how you coordinate effort to meet a target date, and project management can be done with varying degrees of excellence or not, which would affect the mapping of effort to schedule)…

There are many costs associated with trying to get the project done on an aggressive schedule –  but here we see pictured the potential costs to the organization of not getting it done sooner than the estimate.  This helps us see why a more aggressive commitment could be the right choice for an organization.  (When I was thinking of McConnell’s estimation error graph as a scheduling graph, on the other hand, I was wondering why executives would ever push for a more aggressive commitment when the numbers were clearly against it!)

Of course, there is a minefield of issues to navigate when you try to complete more work in less calendar time; for instance:

• How do you keep your quality at acceptable levels in the face of staff fatigue?
• What is the cost of lowered morale if the deadlines seem impossible to meet?
• What costly technical and architectural blunders do you commit because you’re focused on meeting the deadline and so you’re not as thoughtful about what you’re producing?

and many others — I think that we should lift these up as appropriate so our executives do get a picture of what kinds of cost we’re taking on as part of the aggressive schedule — but then I guess it’s our executives’ job to weigh the relative costs and so navigate!

It was the excellent last chapter of Software Estimation (Chapter 23: “Politics, Negotiation, and Problem Solving”) that got me thinking about this issue — in that chapter McConnell helps you see through the eyes of an executive and understand the kinds of issues you grapple with at that level.

Upgrade bomb

I shoulda hadda backup.

The weekend before last I attempted an online upgrade from Mandriva 2009.0 to 2009.1.  The upgrade from 2008.I-forget-what to 2009.0 had gone with barely a hiccup, though I had performed it without backing up my data first.  This time I wanted to be less cavalier, so I backed up the /home partition beforehand.  I still didn’t back up the programs though.

The upgrade takes many hours even if nothing goes wrong (it’s pulling over a gigabyte, I think).  Things seemed to be going along fine for several hours, until the progress bar was over half, when I got a scary looking error:

I chose to continue, but eventually the install gave up.  I restarted it, but after getting the above error again, I started seeing packages downloading that I thought I had seen before, and began to fear that the install was going in circles. I ended up stopping the upgrade.

The next time I rebooted, when I logged in I got an error about kdeinit4 in an odd little unmovable white dialog in the upper left corner of the screen:

Could not start kdeinit4.  Check your installation.

When I pressed the “okay” button,  I got logged back out.  Yipes!  My wife uses this computer too.  Down system!

I wished I had backed up the programs too.

I don’t know how to get back to Mandriva 2009.0.

A Workaround

I did find that I can log in using KDE 3.5, which is still installed.  The desktop is plain looking, but we can do our work until I figure out how to either upgrade or downgrade.

Reason for the Upgrade Issue

Why is there an unsatisfied dependency?  It looks like the Nvidia 71xx proprietary driver has not been upgraded for the version of X that ships with 2009.1.

Hmm.  I wish that I could have known that there was a stopper problem before I got halfway upgraded.

I wonder what I should do now?