Microsoft Vista Has Gates Saying “Wow”

That’s the headline of a CBS News story about the launch of Windows Vista today. Oooh, the headline writers at The Associated Press must have worked overtime to come up with that one.

No, this isn’t a knock on Microsoft. This is a knock on the AP (this is their picture, too), who have apparently forgotten the difference between reporting and shilling, and on CBS News, which is happy to reprint fluff from the AP without thinking about it.

The second paragraph of the story revealed the depth of this puff piece:

“This ‘wow’ thing is a great way of describing what we’ve got here,” Microsoft’s chairman told The Associated Press on Monday as the software maker began a slate of splashy events in New York. “There are chances for ‘wows’ all over the product.”

Do I smell a Pulitzer? Sheeesh.

>> Update 1/30: CBS News changed the story’s headline to “Vista Makes Its Debut,” and added a lot more detail and commentary. Yesterday, it was purely an AP story, but now CBS News says that the AP “contributed to this report.”

For the past week or so, Microsoft has been dribbling out press releases touting a benefit of Windows Vista: The upgrade will drive IT jobs and spending.

Today’s release brags that Windows Vista will generate US$10 billion in new revenue for the California IT industry in 2007, and will drive 16,000 new jobs in the state. This is based on research from IDC, which was sponsored (read: paid for) by Microsoft. I wrote about one part of that research on Dec. 12.

For someone’s revenue to increase, of course, someone else’s costs have to go up.

Microsoft and IDC have previously released proportionally similar figures for Massachusetts, New York, New Jersey and Florida. It’s fair to expect more states to be “researched,” and their increased IT costs touted as a Windows Vista benefit.

Now, is this increased IT cost a good thing? I would argue that while it’s a huge plus for California’s IT industry, it’s a huge minus for the people of California, who are expected to fork out $10 billion and hire 16,000 people to handle the migration from one version of an operating system to another. (I’m focusing on California here, but my comments apply elsewhere.)

IDC’s figures include the cost not only of migrating the operating system itself, but also of developing and deploying software updates required for Windows Vista, upgrading or replacing hardware, and so-on. Firms providing those services include (to quote from the IDC report):

Microsoft partners and OEMs sell PCs and servers running Windows; software vendors write applications that run on Windows using Microsoft application development tools; retail outlets and resellers employ people to sell and distribute these products; and service firms install and manage Microsoft-based solutions, train consumers and businesses on Microsoft products, and service customers for their own applications.

According to IDC, this is terrific! To quote again,

This is good news for California. Over the next four years, software-related IT employment should grow by almost 150,000 jobs and be the sole reason IT-related jobs increase at all.

IDC says that in California alone, Microsoft will ship nearly 5 million copies of Windows Vista in 2007, and the company will make $500 million in this one state alone. Quoting IDC:

For every dollar of Microsoft revenue from Windows Vista in 2007 in California, the ecosystem beyond Microsoft will reap more than $19 in revenues. In 2007 this ecosystem should sell more than $10 billion in products and services revolving around Windows Vista.

To put it another way, it’s going to cost California’s businesses and consumers $500 million in Microsoft license fees to adopt Windows Vista. And it’s going to cost the state’s consumers $10 billion overall. And that’s good news?

This is good news for the IT industry, of course, and for IT professionals seeking employment. But it’s bad news for the people of California who aren’t in the IT industry, say, a dentist’s office, or a clothing manufacturer, or a school, or a restaurant chain, who will be footing the bill.

It’s hard to celebrate a software update when its creator boasts that it will increase the cost of IT. Isn’t newer technology supposed to save us money?

Bruce Schneier, in a blog posting today, argues (convincingly) that it’s important for researchers and white hats to publicly release details about security vulnerabilities in hardware, software and Web sites. He writes,

Before full disclosure was the norm, researchers would discover vulnerabilities in software and send details to the software companies — who would ignore them, trusting in the security of secrecy. Some would go so far as to threaten the researchers with legal action if they disclosed the vulnerabilities…. It wasn’t until researchers published complete details of the vulnerabilities that the software companies started fixing them.

I agree with Bruce. I think that public scrutiny, which can lead to PR fiascoes, and from there to lost sales and lawsuits, is arguably the only factor driving big companies to fix their products in a timely fashion. Without the pressure of public disclosure, problems — and not just those limited to security vulnerabilities — would be addressed more slowly, or not at all.

Not everyone shares that viewpoint, of course. Big companies abhor the practice, and many believe that security flaws should be kept strictly confidential. There’s also a debate about whether software companies should be given advance notice of vulnerability discoveries, so they can issue patches before the vulnerability is publicly unveiled.

Bruce (pictured) points us to an excellent article just published on CSO Online, “The Chilling Effect,” by Scott Berinato. You should read it, and also its two sidebars by Microsoft’s Mark Miller and Tenable Network Security’s Marcus Ranum.

Now think for a bit. It’s one thing for you to argue for (or against) security vulnerability disclosure for the products you consume, say, from Microsoft or Sun or IBM or Oracle or Novell. Is it another thing for you to argue for (or against) security vulnerability disclosure for the products your development team create? Often, there’s a double standard: disclosure is good for the other guy.

Why should that be?

Separately: If you don’t read Bruce Schneier’s blog, you should. It’s always informative, and sometimes scary.

According to a CBS News report, Sun will soon be using Intel processors in some of its servers. In return, Intel will endorse the Solaris operating system.

If true, this is a good move for both companies, and potentially, for everyone except AMD, which has enjoyed an exclusive deal with Sun since November 2003.

Sun doesn’t win when it’s dogmatic. For years, it fought against Wintel with its SPARC processors. While there were sound technical reasons why the company chose AMD’s Opteron processors instead of Intel’s Xeon processors for its move to x86, there was some classic Sun attitude in there as well. Microsoft, despite its support for AMD’s processors, has long been close to Intel, and Sun’s arch-competitor, Dell, was always an Intel-only shop. Thus, one way for Sun to differentiate itself when selling commodity hardware was to snuggle up to AMD.

Times change. Dell ships a few AMD-based servers now, and Microsoft does a lot with AMD. In fact, in its public communications and technical documentation, Microsoft treats both companies’ processors equally, and it does marking with both. For example, AMD and Microsoft are jointly sponsoring a contest, called Vanishing Point.

AMD makes great processors. So does Intel. Sun, and Sun’s customers, win when the company is pragmatic, not dogmatic. Similarly, Intel gains no benefit from shunning Solaris; it should be an OS-neutral platform provider.

That leaves the obvious holdout, on the computer front, as Apple. Apple uses Intel processors exclusively… something that AMD execs have expressed frustration about. I’d love to see an iMac or Mac Pro running with Opteron processors.

>> Update 8:35am: Just received an invitation to a press conference with Sun ‘s Jonathan Schwartz and Intel’s Paul Otellini, at 10:00am today in San Francisco. Guess the deal’s real.

Larry O’Brien tagged me. Larry, that prankster, is playing Blog Tag, where you dare people to reveal things that most people won’t know. (I traced Larry’s tag back and found this entry on “Storm & Wind” from August 2006. After that, the trail went dark.)

I’m cool. I’m hip. But I also want to stay somewhat on topic; this is a professional blog, not a personal diary. That said, here are things that you may not know about me:

1. One of my first published papers presented a recursive solution to the Tower of Hanoi problem – for the HP-67 programmable calculator. Rather innovative, I still think. Another paper formally presented a “Tiny BASIC” implementation for the HP-41C calculator.

2. The first magazine I worked for, as a staff editor, was called Portable 100, for users of the TRS-80 Model 100 computer (pictured). The first article I wrote for P.100 was a review of a Votrax speech synthesizer. The magazine was so successful that many people referred to the Model 100 computer as a Portable 100.

3. My consulting company, Camden Associates, was launched when I lived in Camden, Maine, more than two decades ago. It was initially a VAR/systems integration/custom programming business called Camden Computer Services.

4. When studying computer science, my favorite course was in compiler design. It was a great class. I also enjoyed taking EE classes, and wished that I could take more.

5. The first personal computer I owned was a TRS-80 Model I, but unfortunately, I couldn’t afford many mods for it. Later I upgraded to a TRS-80 Model III. I never owned a Commodore or an Apple, until acquiring a Fat Mac.

6. I worked my way through college typing term papers and dissertations (I was a wicked good typist) and tutoring. The best money and most gratification was in tutoring non-traditional students who were receiving veteran’s benefits.

7. While Larry is a great puzzle/game solver (see his backgammon comment), I’m not good at it. I’m lousy at backgammon and chess, for example, and can’t solve the Rubik’s Cube – despite Larry’s attempts to teach me the algorithm. My brain just doesn’t work that way.

8. I love doing what I do. But if I had to do something else, I’d become a professional photographer.

Part of the game is that I must tag other people. Okay: Alexa Weber Morales, Bruce Schneier, Esther Schindler, Bernard Golden and Joel Spolsky.

I’ve seen relatively little coverage about yesterday’s approval of the PCI Express 2.0 specification by PCI-SIG, the industry consortium that, well, defines the PCI Express specification.

With the introduction of PCI Express (aka, PCIe) a couple of years ago, server expansion cards got a huge performance boost, with the biggest impact on RAID and other disk controllers, and also on high-speed, low-latency interconnects, like you’d see in high-performance clusters. (PCI Express is found on desktop systems, too, with the biggest payoff in graphics cards. There, PCIe replaced older standards like AGP.)

The beauty of the PCI Express system is that it’s transaction-based. Yes, this makes it considerably more complex than many previous bus designs. In fact, PCIe incorporates a full networking stack. However, that gives it much greater flexibility and scalability.

Each PCI Express interface and peripheral engages in transactions using some number of asynchronous one-bit-wide serial lanes, which are used to aggregate bandwidth. Devices can use links that are between 2 and 32 lanes wide. (That’s in contrast to older buses, which were synchronous and parallel at 16, 32 or 64 bits, and which were therefore hard to sync at faster clock speeds.)

The PCI Express 2.0 spec doubles the data rate from 2.5GT/s (that’s 2.5 billion transactions per second) to 5.0GT/s. Each lane’s performance jumps from 2.5Mb/s to 5.0Mb/s.

That extra bandwidth opens up great possibilities. Think of what it can mean when linking CPUs and GPUs, for example. It also raises the ceiling for low-latency interconnect performance for clusters.

According to PCI-SIG, the PCI Express 2.0 spec adds additional features: device drivers can dynamically control link speed, for example. The bus also supports devices that consume higher power.

As servers and desktops get faster (think about two quad-core processors in a desktop, or four quad-core in a typical server) the bottleneck isn’t the processor or the peripheral. It’s the bus. PCI Express 2.0 is a solid step forward.

Before 2006, only one company – IBM – managed to gain more than 2000 U.S. patents in a single year. But in 2006, five companies broke that barrier: IBM with 3651 patents, Samsung with 2453, Canon with 2378, Matsushita at 2273, and Hewlett-Packard at 2113.

That’s a huge amount of patent activity. In fact, according to IFI Patent Intelligence, my source for all these numbers, there were 173,772 U.S. patents issued in all of 2006, a record amount that was 20.8 percent higher than in 2005.

To quote from IFI’s analysis,

“2006 panned out as a banner year in terms of the number of individual patents granted and leads us to believe that the USPTO is making headway in addressing its backlog of patent applications,” said Darlene Slaughter, general manager of IFI Patent Intelligence.

“Although the number of patents being granted is not the only gauge of technological advancement, the relative increase in number of patents being generated indicates a growing emphasis on the value of intellectual property.”

The USPTO is the U.S. Patent and Trademark Office.

Some other big patent winners in 2006: Intel, at 1962, Microsoft, at 1463, and Sun Microsystems, at 776. You can see the same list I’m looking at the IFI site.

When you factor in the power of patent cross-licensing, patents are an incredibly potent weapon. Patents not only help a company gain market share, but also help them successfully defend that market share against competitors – particularly upstarts. Big competitors share their patents. Smaller competitors don’t have the IP to play that game, so they either have to pay through the nose, or stay out of the game. Novell, in its lopsided IP licensing deal with Microsoft, may be a casualty of the IP wars: it was simply out-gunned.

Threads are breaking out of the server into the desktop and notebook computer – and even in servers, the advent of dual-core and quad-core processors is drastically changing the landscape for applications. To put it bluntly, applications need to be designed, coded and tested to run optimally in a multithreaded environment – not just to get the best possible performance or throughput, but also to ensure that applications will run correctly when there are four, eight or even 16 cores in the machine.

The problem is that most developers, and development teams, don’t think about threading on the desktop. Even when it comes to servers, which have long supported multiprocessing, a lot of the thinking is that “the operating system will handle it,” or “my libraries will handle it,” or “my runtime will handle it.” Well, no. Most of the time, if the architect, coder or tester doesn’t put in the time, you won’t see the results.

When I talk to companies like AMD or Intel, that’s the frustration I hear all the time: Threading is still in the earliest stages of adoption among developers. That’s true on the desktop and the server. That’s true of ISVs and enterprise developers. That’s true for those building libraries and runtimes, and for those building complete applications.

But how to measure how far a company, a development team or a developer is in regard to threading? During lunch this week with James Reinders, director of marketing and business for Intel’s Software Developer Products Group (that is, the compiler folks), I suggested a Threading Maturity Model (ThMM), as analogous to things like the Capability Maturity Model, or the SOA Maturity Model. James liked the idea, and I’m presenting it here for comment. As far as I know, this is an original concept.

Note that companies would likely be at different stages in the Threading Maturity Model for server applications versus for desktop applications.

The Threading Maturity Model (ThMM)

5. Adoption. All developers trained to use threading. Threading is addressed at the design, requirements, and architectural states of development, in addition to coding and testing. Broad incorporation of threading tools into the toolchain. Newly adopted code, such as libraries and components, must demonstrate support for threading. Funded efforts to eliminate all non-threaded libraries and runtimes. All threaded applications are tested against platforms with different cores/processors to identify runtime issues. Formal source-code validation techniques are used to identify potential failures.

4. Utilization. A few developers receive formal training on programming using threads, and how to avoid hazard such as deadlocks and race conditions. Threading considered a programming issue, not a design, requirements or architectural issue. Use of threading encouraged, but not mandated, except in performance-intensive routines. Some libraries and runtimes required to support threading. Specific tools to test threaded code are purchased and used from time to time. Some, but not all, threaded applications are tested against platforms with different cores/processors to identify runtime issues. No formal validation of threaded code for correctness.

3. Hotspots. Developers are largely self-taught about threading. Threading used to address known performance trouble spots within applications by applying simple techniques, such as OpenMP, to optimize loops on a desktop application, or the use of thread pools to manage user connections on a server application. Results measured with code profilers and casual benchmarks. Use of threading is allowed, but not particularly encouraged or required. Minimal testing of applications against platforms with different cores/processors to identify runtime issues.

2. Experimentation. Some developers have studied threading, such as by reading articles, but are not trained. Simple tests of threading conducted with trivial or ad-hoc projects; some tests will appear to indicate failure, because the tests weren’t properly designed or executed. Some allocation of enthusiast team members’ time is channeled into exploring threading, often as a “skunkworks” project. Some understanding of the different threading models. Minimal incorporation of threading into production code. No testing of applications against platforms with different cores/processors to identify runtime issues.

1. Awareness. General awareness of the potential benefits of threading desktop or server applications, but unsure of the specific benefits of different techniques for threading. Threading not incorporated into the development process. Developers trust that compilers, libraries and runtimes are handling threading automatically. No serious consideration of threading as a way to solve performance problems. No testing of applications against platforms with different cores/processors to identify runtime issues.

0. Unawareness. They don’t know and they don’t care: Developers, architects and managers are either unaware of the existence of threading, or don’t believe that it applies to their software development practices. Completely trusts that the operating system handles everything automatically when more cores or processors are added. Nobody is following technical discussions regarding threading.

(My thanks to James Reinders for his enthusiastic response, and to my colleague Andrew Binstock, who reviewed an early version of the model. Andrew offered ways to make it more generally applicable to both desktop and server development, and suggested adding ThMM stage 0.)

This is my 100th blog entry on Z Trek. Profound, ain’t it?

Apple’s decision to change its name from Apple Computer Inc. to Apple Inc. reinforced my nascent feelings about the company, and by extension, IDG’s independent conference for the Macintosh industry. Apple and Macworld Expo aren’t about computers any more. They’re all about consumer electronics.

Sure, in the Macworld North Hall there were a few enterprise exhibitors. Behind the main Apple pavilion in the South Hall (which was mainly showing off the iPhone) there were a handful of software development tools companies. However, they were lost in the maze of iPhones, Apple TVs, and iPod cases. Macworld is a consumer event, and Apple has declared itself a consumer electronics company.

I wouldn’t go to Nokiaworld to see their new phones, so why should I go to a conference to see the Apple iPhone? I’ll wait and see it in my local cell-phone store.

I wouldn’t go to TiVoworld to see their latest digital video recorder, so why should I go to a conference to see the Apple TV device? I’ll wait and see it in Best Buy.

Sure, there was some eye candy for people like me — you know, the ones who care more about computers than music players. Apple did demonstrate some neat features of “Leopard,” the next version of Mac OS X. But those were basically the same bits that Apple’s been showing for the past few months.

Apple’s announcement that two billion songs have been downloaded from its iTunes Store is impressive. But that’s not a reason to attend a conference. Neither is the opportunity to view yet another “I’m a Mac” advertisement.

One can only see so many MacBook carrying cases, iPod skins and people drooling about the iPhone to realize that Macworld has become simply irrelevant. I’m a big Apple customer myself: I’m typing this on an iMac, I carry a PowerBook, both are connected to an Airport WiFi hub, and there’s an iPod hooked into my car stereo. But there’s nothing for me at Macworld.

Jon Bosak informed me this morning that UBL 2.0 has been approved as an OASIS standard. UBL, or Universal Business Language, is designed to provide a consist way for businesses to share common documents using XML; that is, documents like invoices, purchase orders, catalog updates, transportation manifests, things like that. UBL is an alternative to business groups creating ad-hoc schemas for documents that are truly universal to all businesses. Why reinvent the wheel — or the billing form?

While UBL 1.0 made a good start, and laid some fundamental groundwork, the scope of its work was pretty limited to order processing. Version 2.0 adds 23 new document types of the previous version of the XML spec. Those include catalog requests and updates; forwarding instructions, packing lists, bills of ladings and waybills; credit and debit notes, freight invoices, payment reminders; account statements and remittance advice notes.

Sexy? Heck no. But efforts like UBL (you can download the spec here) are essential to helping businesses conduct business online, and can significantly help reduce software development time. There’s also a SOA perspective here: the UBL document and schemas can be used both internally and externally, and can serve as the foundation for a company’s internal workings as well.

Andrew Binstock pointed me to this CNet article, regarding the forthcoming introduction of terabyte hard drives from Hitachi Global Storage Technologies. Too bad they didn’t ship in December. My, that burger tastes good.

Hitachi GST, by the way, is IBM’s old storage division, which Hitachi bought in 2003 and absorbed into their own storage group. I visited the IBM hard-disk plant in San Jose about a decade ago. It had very impressive displays of old washing-machine-sized 5MB hard drives in its museum.