The ongoing drama at Hewlett-Packard has me rapt with attention. Beyond its involvement with Mercury (which HP is in the process of buying), the corporate-spying scandal doesn’t have much immediately relevance to my own world of software development. However, it is a fascinating tale, and it’s interesting to watch it unfold.

Certainly friends who work at HP are equally focused. Morale at the company is bad, like when Carly Fiorina was laying off people left and right in the wake of the Compaq acquisition. Not good, not good at all.

Within this broad story, there’s room to enjoy what (to me) is a perennial issue: What do you call the company?

Legally, the firm keeps changing its name. It used to be the Hewlett-Packard Co. But nowadays, it’s the Hewlett-Packard Development Company, L.P.

What about shortening the name? There we have lots of options. I use HP, as you can see. That’s also the company’s preferred usage. However, others also use H-P, H.P. or my personal favorite, simply Hewlett.

Nobody, but nobody, in the tech industry calls Hewlett-Packard, “Hewlett.” That’s reserved for out-of-touch mainstream journalism, such as the New York Times headline for today’s story about the hunt for the leaker. The Times also uses the abbreviation H.P.

The Wall Street Journal likes the abbreviation H-P, even in headlines, but calls the company Hewlett-Packard Co. on first reference within the story.

Our style at SD Times and other BZ Media publications is to follow a company’s own preferred usage, whenever possible; we only make occasional exceptions, such as when companies have gratutious punctuation as part of their name. We drop the exclamation point (which in journalism is called a “bang”) from names like Yahoo!, for example, because it’s disruptive when you’re trying to read.

But I still get a kick out of seeing the first ref to HP written as simply “Hewlett.” It always takes a moment to figure out who the NY Times is talking about. C’mon, guys. You can do better than that.

My first exposure to microprocessors came through the use of the Zilog Z80 chip. It was hard to do any work with small computers in the late 1970s and NOT use the eight-bit Z80; they were relative cheap, easy to build circuits with, and simple to program. Many hardware and software engineers, including myself, cut our teeth on Z80 assembly. Early microcomputers, like the Radio Shack TRS/80 and numerous CP/M boxes, used the Z80 before the IBM PC came out and redefined the landscape around Intel’s x86 family.

But Zilog, what have you done for us lately? Not much, given the company’s recent financial woes — millions of dollars of losses every quarter. While the company still sells variations on its newer eight-bit Z8 microprocessor, it also offers other stuff like infrared controllers. Even so, the breadwinner is the Z8, which includes onboard flash memory, perfect for embedded microcontroller applications.

Zilog has lived in an eight-bit world for 30 years. Yes, the company has attempted to break out of the eight-bit box before, such as with the short-lived 16-bit Z280 and 32-bit Z380 processors from the early 90s. But they just didn’t go anywhere.

Flash forward (so to speak) to 2006. One month ago, the company dumped its chairman/CEO, Jim Thorburn, who had been in place for five years, appointing an interium CEO while beginning a search for a permanent replacement. And now it has released a new 16-bit platform, called ZNEO.

ZNEO looks like an interesting chip, and a possible upward migration path from the Z8 microcontroller. It has fast zero-wait-state internal flash memory, in a variety of sizes ranging from 32KB up to 128KB: that’s a lot of space in the embedded market. Plus, it has a math engine that can do 8, 18, and 32-bit operations.

Clearly, the ZNEO project is going to be critical for Zilog, as the firm struggles to survive. It’s a chicken-and-egg situation: Zilog needs new customers and design wins in order to get its finances in order. But will embedded developers, who perhaps rely upon the company as a provider of tried-and-tested commonity chips, want to base their future products on an unproven platform from an trouble supplier? Time alone will tell, but I have my doubts.

My 9/21/06 “Zeichick’s Take” about automotive security brought several letters-to-the-editor, one of which made an excellent point that applies well in the physical security world, but which in my opinion falls down in cybersecurity.

Steve Brewin wrote,

“Apparently the vast majority of crime is committed by amateurs chancing on an easy opportunity. The simple lock removes the easy opportunity, amateurs will look elsewhere. Professionals play for much higher stakes and while they can easily bypass such simple security mechanisms, the probability of an attack from them is massively less. Most targets are not worth their time. For most, the cost of installing systems capable of thwarting their attacks is disproportionate to the risk.

The insurance assessor explained that while most viewed their offer as a marketing exercise, their statistics told them that the discount they were offering was small compared to what they expected to save in the cost of claims alone.“

That’s very true. Professionals can unlock cars, remove The Club, jimmy house doors open, even break a laptop security cable with a small bolt cutter. So can a determined amateur, who can pick up the right tools, or practice simple techniques. But what about the casual amateur? The kid walking through the parking lot who sees an brand-new iPod sitting in a car? For that kid, a locked door may sufficient to make him move on.

In other words, if someone is bound a determined to steal YOUR things, locks probably won’t help. But if they’re just looking to steal SOMETHING, they’ll pick the lowest-hanging fruit. Your security system simply ensures that your fruit isn’t the lowest-hanging target.

But that falls down when it comes to cybersecurity — because of the shotgun approach. Even the most casual script kiddies use sophisticated ports scans, SQL injection, worms and other automated techniques. Those are the equivalent of trying to break into every car in the parking lot simultaneously. I’m not sure that hoping that someone else’s computer is a lower-hanging target is enough. It’s unfortunate, but our neworks, servers, desktop AND applications have to become fortresses. At every layer of the stack, we’re being targeted.

One of the challenges for any software development project — whether enterprise or for-sale, open source or not — is what to do about all those pesky defects that nobody’s going to fix. Why aren’t they going to be fixed? It might be that they’re not a show-stopper, or that there are other priorities, or there’s no easy fix, or simply that nobody wants to do it.

Every non-trivial software project has bugs that won’t be fixed. Sometimes you know that it’s not going to be fixed, and at other times, everyone has the best of intentions, but it just never gets done.

One of the benefits of most open source projects is transparency. Take Eclipse, which uses a public bugzilla feed to let users and contributors report defects. When defects are reported, often they’re resolved, but sometimes they’re marked RESOLVE LATER. Does that mean that the issue truly will be resolved later, or as some people suppose, is that a polite euphemism for RESOLVE NEVER?

Let’s face reality: Not every bug is going to be fixed. Yes, it would be nice to have less ambiguity, and to know, for certain, that a specific bug is going to be (or not going to be) addressed. But at least with a system like the RESOLVE LATER system, you can see if action is being taken or not. With non-open-source projects, or OSS projects that take place with less transparency than Eclipse, bug reports go into a black hole.

By contrast, with commercial software, a bug will only be fixed if the software owner sees the business value of fixing it. While I agree that RESOLVE LATER is suboptimal, it’s easy enough to see that a bug that’s been ignored for months or years isn’t going to be addressed. And that’s valuable information.