The scuff worked out just as intended and is now in front of us, perfectly positioned for us to IDD it. But Rick Welch suggests abandoning this opportunity. We have a new FSW load coming up, and he thinks it might be a good idea to get the rover into a good attitude for that. We wouldn't leave the scuff altogether, but we'd try to drive to a different location, one from which we could still reach the scuff while being better positioned for the FSW load.
But the science team nixes the idea. "We've got this," one of them says, "let's use it."
Well, they won't have Rick to kick around any more. Not for long, anyhow. He's moving on to MSL after this week, and Julie Townsend is doing the same. "The last remnants of the original team are floating away," she muses.
Speaking of MSL, Jeff heard a disturbing rumor. The flight software architecture for MSL, he heard, is going to be based on a system called VML. Nothing wrong with that -- if you have an orbiter, or even a lander. But for a rover, VML doesn't make sense. This is because VML requires every command to be time-tagged; it doesn't seem (says Jeff) to have an event-driven mode. (That's what we call a mode that says, "do each command as soon as the previous command finishes.") That's the mode in which we always command the rovers. Time-tagging all commands makes sense when you have an orbiter, whose environment can be perfectly predicted months in advance, or even a lander, whose environment is more or less fixed. But for a vehicle that has to dynamically respond to an unpredictable environment, this would be absurd.
And maybe it's not true -- we don't know enough about VML to know. "One good thing if it is true," I point out. "It'll sure help me decide if I want to work on that project."
[Next post: sol 399 (Opportunity sol 379), February 15.]
 I don't know whether VML was ever seriously in contention as the basis for MSL's flight software or if this was simply a baseless rumor, but in any case VML is not being used on MSL.