The Pervasive Data Center

NEW YORK--It was a larger and cheerier crowd that attended this year's Red Hat's analyst day at the New York Stock Exchange on Tuesday.

That shouldn't be surprising. At last year's meeting on October 7, Red Hat management had the dubious honor of ringing the closing bell on a day that saw the Dow Jones Industrial Average drop over 500 points.

This meeting took place in a time of what's probably best described as cautious optimism about the state of the economy. And in the context of Red Hat financial results that have continued to show growth at a time when so many companies in IT industry and elsewhere have not.

For the quarter ending August 31, its profit jumped 37 percent relative to the year-ago quarter, besting analyst estimates.

The day included a fair bit of discussion related to financial minutiae, as you'd expect for an event pitched primarily for financial analysts. However, it also included an overview of Red Hat's strategy and its technical direction. Here are a few things that caught my eye.

Jim Whitehurst, Red Hat's CEO, spent a fair bit of time talking about what boils down to fine-tuning of its go-to-market execution such as:

• Value of subscription. This includes what he called "education and compliance," essentially a euphemism for getting people using Red Hat Enterprise Linux (RHEL) without paying for it to purchase a subscription. It also encompasses improving renewal rates for those cases where RHEL has been preloaded by a system builder and bringing a greater focus to articulating the value of RHEL relative to free substitutes such as CentOS.
• Routes to market. This refers to a continued build-out of the channel so that system integrators and others who recommend and install systems for less sophisticated customers will specify Red Hat as part of their solution. This stands in contrast to how, historically, Red Hat was mostly pulled into accounts by technically-savvy users and IT departments.

The message I took away from this is that Whitehurst isn't looking to change Red Hat's direction in any major way but sees a fair number of areas where more focused execution could lead to financial improvements. Later in the day, we also heard that Red Hat is taking a more systematic approach to which products it allocates development dollars for work such as internationalization.

For his part, Paul Cormier, executive vice president of products and technologies, reiterated Red Hat's belief that virtualization (which should be taken as hypervisor in this context) belongs in the operating system. This argument has been in evidence for a while as my fellow analyst Stephen O'Grady discussed after last year's event. 

It stands in stark contrast to VMware's desire to make the operating system irrelevant. Or, to put it another way, VMware's ambition to make the VMware ESX and ESXi hypervisors the model for a new type of operating system. This is too fraught a debate to tackle here; I largely agree with Stephen's take in his post.

However, one of the interesting outcomes of this battle is that Red Hat has been cozying up to Microsoft, the other big gun on the "hypervisors belong in the OS" side. This includes Red Hat's announcement Wednesday "that customers can now deploy fully supported virtualization environments that combine Microsoft Windows Server and Red Hat Enterprise Linux."

This sort of interoperability is certainly a customer desire and both Red Hat and Microsoft can legitimately present it in those terms without anyone smirking. However, the enemy of my enemy is also my friend, at least up to a point.

I also took note that Red Hat finally seems to be making some progress on the management front.

The product in question is RHEV Manager (RHEV-M); it's covered in detail in this video from the Red Hat Summit in September and is currently being tested by customers.

One reason I think it's important is that Red Hat apparently, if belatedly, recognizes that it is. CTO Brian Stevens admitted that RHEV-M "has been a huge missing ingredient."

The one customer speaker at the analyst day was Dave Costakos of Qualcomm and he focused on his company's experiences with testing RHEL-based virtualization and the associated RHEV Manager which he describes as "hits the mark."

I caught up with Dave at a break to get a bit more detail. He told me that they wanted a Web-based interface, which RHEV Manager has. He also liked the integration with Active Directory and other directory systems, and the role-based access controls. He said that it could perform the provisioning operations that Qualcomm requires and otherwise meets their needs.

Management has historically been a relatively weak part of Red Hat's offering that was mostly focused on updating packages. This is really a reflection of the broader Linux and open-source ecosystem in general. Projects like Nagios and, more recently, GroundWork notwithstanding, management doesn't play well to the strengths of open source. It touches too many parts of an IT infrastructure and requires too much cooperative work with the vendors making the things that need to be managed.

It's reasonable to ask whether Red Hat is too late to win big with RHEV Manager and its associated KVM-based virtualization play. But it had to attack management from some angle unless it was prepared to just cede that area of differentiation and potential point of control to system makers and others.

Finally, no technology discussion today would be complete without at least a mention of cloud computing. Brian Stevens jokingly called it a "shiny thing that people are looking at how to monetize."

The cloud discussion covered several angles, not least of which was standardization efforts such as Deltacloud. Like most other standardization efforts, this focuses on what is often called Infrastructure-as-a-Service; Amazon EC2 and S3 are perhaps the best known examples. Stevens admitted that it's going to be much harder to define a standard set of higher-level services (platform as a service in the vein of Microsoft Azure) that are portable.

Red Hat's distinctive play in the infrastructure cloud essentially circles back to its approach to virtualization. In cloud infrastructure as imagined by Red Hat, the operating system matters in important ways.

That's because applications matter; indeed, applications are ultimately what matter most. And in on-premise computing, one of Red Hat's greatest values and differentiators is the vast number of certified applications that it runs. This certification matters to users because, if they encounter a problem, it means that they can call the application vendor to get support. Otherwise, they'd get a "sorry, that's not a supported configuration."

One can argue whether the software layering of which the historical operating system is a part is the most appropriate choice for cloud computing. Fellow CNET blogger James Urquhart dives deeply into this topic in a pair of recent posts.

However, whether it's the way it should be or not, it is for now. And for Red Hat to be able to enable users to carry the certification of applications into a cloud model is a significant differentiation.

[Update: Additional commentary from Stephen Hemminger added.]

Microsoft set off a barrage of commentary earlier this week when it released three drivers under the GPL v2 to be part of Linux. The main purpose for doing so appeared to have been to make Windows Server and Hyper-V more effective as a virtualization foundation for Linux guest operating systems.

I was less shocked by the news than some. It struck me as a smart business move by Microsoft to further dispel both the reality and appearance of not playing well with other operating systems and tools. From a practical perspective, offering technology to Linux that lets it work better with Windows pretty much had to be done in the form of open-source code. At the same time, the Microsoft of today is far more accepting of the fact that like it or not, Linux is going to be a fixture at many of its customers and they're going to have to live with that.

Thus, releasing these drivers seemed to make a lot of sense and, while it was clearly a big step on the part of Microsoft, it certainly wasn't inconsistent with the company's recent posture toward open source, especially since Sam Ramji came onboard to be senior director of platform strategy.

However, it now turns out there's another layer to the story.

On Monday, Stephen Hemminger made a posting to his blog, Network Plumber's Journal. Stephen is a principal engineer with Vyatta, an open-source networking infrastructure vendor. Prior to Vyatta, he was with the Open Source Development Labs (and then the Linux Foundation) and was one of the largest contributors of Linux kernel code (PDF).

This saga started when one of the users on the Vyatta forum inquired about supporting Hyper-V network driver in the Vyatta kernel. A little googling found the necessary drivers, but on closer examination there was a problem. The driver had both open-source components which were under GPL, and statically linked to several binary parts.

The GPL does not permit mixing of closed- and open-source parts, so this was an obvious violation of the license. Rather than creating noise, my goal was to resolve the problem, so I turned to Greg Kroah-Hartman. Since Novell has a (too) close association with Microsoft, my expectation was that Greg could prod the right people to get the issue resolved.

It took longer than expected, but finally Microsoft decided to do the right thing and release the drivers.

By way of brief background, the GPL under which Linux is licensed considers static linking--the combination of software components by a developer--to create a "derivative work" of those components. There are a lot of complexities, nuances, and ambiguities, but for our purposes here, the bottom line is that if you statically link GPL libraries or other GPL'd code into your program, the entire program has to be released under the GPL.

Which Microsoft had not done.

I had a conversation with Stephen Hemminger, who initially reported the potential issue with Microsoft's driver, and he provided me with some additional technical specifics. According to Stephen, the issue revolves around a feature of the Linux kernel called EXPORT_SYMBOL_GPL that allows for interfaces to be marked as only available to modules with a GPL-compatible license. From Stephen's perspective, Microsoft's proprietary code had to use some of these interfaces that "the kernel did not want to offer to non-GPL [code]."

If that all seemed a bit geeky technical, well it is. Very possibly a violation of the GPL but hardly one that is simply flagrantly flouting the law. And, from Hemminger's perspective, "once Microsoft was aware of it, they were eager to resolve." He said that he first discovered this in March, so four months is actually fairly rapid resolution as such things go in large companies.

Greg Kroah-Hartman, who is a fellow at Novell and was very involved in the open-sourcing of the Hyper-V drivers, certainly seems to believe the licensing problem played a role in Microsoft's decision. In an e-mail exchange with ZDNet's Mary-Jo Foley, he writes:

MJF [Mary-Jo Foley]: Hemminger is claiming Microsoft put the LIC code under the GPL because it was in violation of the GPL. Is this true? Did you have to suggest to (Microsoft Platform Strategy Chief Sam) Ramji & Co. that they were in violation in order to get them to agree to release the code under GPLv2?

GKH [Greg Kroah-Hartman]: I didn't have to "suggest" anything, I only had to merely point out the obviousness of the situation  :)

MJF: If this isn't accurate, could you let me know how to interpret (Hemminger's) comments on his blog.

GKH: No, that sounds accurate.

Microsoft itself hasn't commented on the matter.

Based on what we know at this point, I draw a couple of conclusions. The first is that if Microsoft were the Microsoft of five years ago, it would have found some way to mitigate the problem that did not involve releasing code for Linux under the GPL.

At some level, it is now philosophically attuned to working with Linux in a way that it wasn't when one of Sam Ramji's predecessors, Martin Taylor, could be described as "Microsoft's Top Anti-Linux General."

But that said, it seems more than likely that their little license problem provided, at the very least, a forcing function to make their GPL contribution happen.

I had planned to leave the Google Chrome OS discussion to others. It's not that I don't have strong opinions about it but with a commentariat noise level approaching the Michael Jackson ruckus of Tuesday, I figured I'd try to wrap up a client project instead. I did so and I've been getting questions all day, so I thought it would be useful to put down my thoughts in a systematic way rather than answering every query ad hoc.

Let me start out by making what is probably a controversial statement. I don't see this as a big deal. Microsoft is not now radioactive. The Force has not been disrupted. The computer industry does not look different than it did yesterday.

Look. Just about everyone has been assuming that Google was going to bring the Google Android operating system that it developed primarily for smartphones to low-end notebooks. While Chrome OS is different from Android, it's conceptually pretty much the same thing--an open-source operating system built atop a Linux kernel.

So now Google has pre-announced that it's going to do basically what everyone figured it was going to do. Sorry, but that doesn't make me want to run through the streets shouting and hollering.

This is, in many respects, just another Linux distribution. And Linux has (speaking charitably) not had the impact on the general-purpose PC market that its supporters once hoped it would. Sure, enthusiasts load Linux onto PCs and it can work quite well, but even at an open-source developer conference you'll often see far more Macs than PCs running Linux. I can't say that I understand why Chrome OS would succeed where Ubuntu has, if not failed, largely played to a niche.

It's Google we're talking about here to be sure. To which I say that Google has had plenty of failures: Orkut, Google Video, Knol, and Google Base anyone?

Fundamentally, I'm skeptical that anyone is in a position to seriously displace Microsoft and Apple from effective ownership of the general-purpose desktop and notebook space. There's so much ecosystem, most of all software ecosystem, in place that a new entrant would have to offer just overwhelming advantage. Which Linux didn't and doesn't.

There's a story here but it's not about displacing Microsoft.

Rather, I see Chrome OS as reflecting a change in the client and the way we access applications. To the degree that Chrome OS further illuminates and, by doing so, accelerates such change it may indeed be important in its own right. However, this is largely a change that's happening with or without Google--and certainly with or without anything Google does with respect to client operating systems.

And it's this macro-trend that's the real threat to Microsoft, not Chrome OS. Microsoft's franchise is built in no small part on having become the de facto standard API for programs running on another de facto standard that we colloquially call the PC. That franchise may be hard to crack (although Apple has had a degree of success) but that franchise doesn't necessarily carry over to new areas where far less software is locally installed and therefore a "standard API" becomes much less important.

The Linux desktop (whether Chrome OS, Ubuntu, or whatever) won't be your father's PC and it may not even look like a PC at all. That's the far bigger threat to Microsoft. Not that it won't be able to defend its existing franchise but that it will be cut off from extending that franchise into computing that happens over the Net rather than locally.

We most associate hypervisors and virtualization with servers from their beginnings as tools for development and testing, through their widespread adoption as a means to reduce the number of physical servers needed, to their current stage as a foundation for dynamic IT architectures. Virtualization on the client side has been more of a niche  although application virtualization continues to grow in importance and some specific uses, such as running Windows applications on Macs, have proven quite popular.

As for embedded devices, special-purpose computers, virtualization has had essentially no impact.

That's beginning to change. Wind River, one of the major players in embedded operating systems and recently purchased by Intel, today announced the availability of Wind River Hypervisor. From the press release:

Wind River Hypervisor enables virtualization for devices across a broad range of market segments, including aerospace and defense, automotive, consumer devices, industrial, and networking. Within these markets, embedded developers are adopting hypervisors to enable the replacement of multiple boards or CPUs with a single board and/or a single CPU, create innovative new devices that leverage multiple operating systems, and reduce complexity when integrating multicore processors. The benefits of using the Wind River Hypervisor include reduced hardware costs and power consumption, opportunity for innovation, and accelerated time-to-market.

This hypervisor can be employed in a number of different ways on a multicore processor. For example, it can be used to run multiple operating system (OS) and application instances on a single processor as a way of enabling single-threaded applications to access multicore performance.

However, what's probably the most interesting use case is consolidating different operating systems on a single processor--and thereby potentially reducing the otherwise need for separate chips or devices. This hypervisor targets two primary operating systems: Wind River's VxWorks and Wind River Linux. To understand why mixing these two might be interesting and useful, consider the differences between them.

VxWorks is Wind River's proprietary "hard real-time" operating system. It's widely used in places like aerospace and defense (think radar, avionics, and so forth) and the data processing of network gear.

Real-time, in general, refers to operating systems and software that have a very predictable response time to events. Predictability runs in opposition to overall throughput so commercial operating systems have historically not been real-time operating systems. Hard real-time typically refers to the need to have truly guaranteed response with the possibility of failure or damage if a response is not made in time.

Wind River Linux is the company's version of Linux optimized for embedded devices. In 2007, Wind River acquired FSMLabs, a real-time Linux vendor, to augment its Linux efforts. Wind River had earlier had a partnership with Red Hat, now discontinued.

Without going into all the gory details of schedulers and so forth, suffice it to say that the real-time characteristics of Linux have improved considerably over the years. Furthermore, various patches can further optimize Linux for real-time uses. Today, we see Linux in applications (such as this IBM/Raytheon deployment) that would have historically been well outside the realm of even customized general-purpose software.

That said, an operating system like VxWorks retains a specialized focus on real-time and comes in versions that carry stringent certifications. Thus, there are many situations where it may make sense to use VxWorks for those parts of an application that require those certifications or are otherwise better served by the specialized real-time OS. At the same time, Linux may be a better fit for other parts of the application that can leverage the Linux ecosystem for components such as user interfaces.

In addition to having different technical requirements, embedded systems make for a somewhat different virtualization use case than in enterprise IT. In embedded, operating systems remain far more specialized and bespoke and this makes the ability to mix and match them on increasingly powerful and multicore processors very useful. This is another face of increasingly pervasive virtualization.

The enterprises, vendors, developers, analysts, and journalists I speak with regularly are mostly pretty savvy about the basics of open source at this point. Even if they're not licensing geeks or otherwise expert in all the minutiae and subtle implications of open-source development, community, and usage, they generally have the important basics down.

However, as I read Rice University computer science professor Dan Wallach's detailed and thorough critique of an Election Technology Council white paper on open source in voting systems, I'm reminded that there are still a lot of misperceptions about open source among the broader public.

A lot of people are quick to dismiss such confusion as evidence of sinister plots to deliberately undermine open source. No doubt, some is indeed willful misunderstanding, or simply disinformation.

But certainly not all. I've personally heard longtime friends from outside the tech industry voice many of the same beliefs. Many of these fall into one of two buckets: open-source software depends on the support of some nebulous "community," and open-source is less secure because bad guys can use the code to find vulnerabilities.

With respect to the first point, this discussion in the ETC paper is typical:

Due to the volunteer nature of an open source model, the issue of accountability in this environment provides a stark contrast to the accountability within a traditional proprietary offering. In commercial product offering, the individual company is held accountable for delivering a product that meets all applicable standards and for meeting project milestones. Contract requirements are often used to establish performance milestones and clearly delineate the responsibilities of a provider. Within a corporate structure, liability is clearly delineated to the company. In an open source environment, a volunteer group of collaborators will not be so clearly subject to financial liability or have a clear line of accountability. It is possible that a hybrid approach could be undertaken for an open source project which is launched in partnership with a private company, but the issue of intellectual property investment and concerns over the long-term viability of the company's product will likely trigger a need to adopt a more restrictive licensing approach, one more indicative of a traditional proprietary model.

In part, this is a case of conflating open source of circa 1997 or so with open source of 2009. It also reflects that most of the people who are loudest about open source as a social movement emphasize hobbyist communities rather than corporate sponsorship and in-house professional development. Indeed, these people often decry the latter as a betrayal of free-software principles.

The reality for most commercially important projects is much different. The bulk of the development is directly funded by IT vendors for self-interested reasons. In the case of the Linux kernel, the work is shared by a large number of companies. Other software, such as JBoss and MySQL, are primarily worked on by developers at a single company.

Support for major open-source software is similarly commercialized. Although "community support" (that is, forums, blogs, Twitter, etc.) may often in fact be pretty good mechanisms to track down fixes, they're not the only one. A Red Hat Enterprise Linux customer, for example, can get support in exactly the same way that someone with a support contract for Microsoft Windows would.

As for the security question, I look at it largely as a case of analogies gone bad. Typical is this line from a paper on Linux security by a public policy expert that I was asked to review a few years back: "it would seem to stand to reason that if keeping passwords, access numbers, and other aspects of system security secret, keeping code secret might be one way to enhance security."

It all sounds reasonable. After all, even if I think I have a solid security system installed in my office I don't stick its specifications and layout on a piece of paper and nail it to my front door.

However, as Wallach notes:

What we learned from the California Top-to-Bottom Review and the Ohio EVEREST study was that, indeed, these systems are unquestionably and unconscionably insecure. The authors of those reports (including yours truly) read the source code, which certainly made it easier to identify just how bad these systems were, but it's fallacious to assume that a prospective attacker, lacking the source code and even lacking our reports, is somehow any less able to identify and exploit the flaws. The wide diversity of security flaws exploited on a regular basis in Microsoft Windows completely undercuts the ETC paper's argument. The bad guys who build these attacks have no access to Windows's source code, but they don't need it. With common debugging tools (as well as customized attacking tools), they can tease apart the operation of the compiled, executable binary applications and engineer all sorts of malware.

In short, access to software (whether open source or just disclosed source) is not the unlocked door that many non-developers assume it is.

Cryptography provides another example. The mechanisms used by most protocols to encrypt and decrypt data are well-documented. They don't depend on secrecy to work. They depend on an untenable amount of computational power being required to decrypt in the absence of private keys.

And the converse offers further proof. Weak encryption algorithms that depend largely on secrecy are often compromised relatively easily; the Content Scramble System (CSS) used on DVDs is a textbook example.

I take all this as a reminder: don't assume things that "everyone knows" really are.

MOUNTAIN VIEW, Calif.--For me, one of the more interesting discussion threads at the CloudConnect event I'm attending here is that of lock-in.

If you move an application or write a new one targeting a specific cloud provider, are you pretty much committed to that provider, for better or worse, through good service and through bad, until your application becomes obsolete or the provider closes shop?

The answer is not a simple one. And it's made no easier by, on the one hand, vendors blithely throwing around terms like open, standard, and interoperable. And, on the other, by calls for an interoperability nirvana that's hard to see ever existing absent software becoming an undifferentiated commodity.

One of the problems with this discussion is that "interoperability" or "portability" in the "cloud" covers such a wide gamut that it's very difficult to make meaningful general statements. IBM's Bob Sutor noted in a panel on the topic that there are different taxonomies for interoperability. For example, you can migrate content, migrate processes, migrate code, or migrate machines.

And, as you move beyond the automagical movement of running applications from one cloud to another, there's a lot of vendor gloss around interoperability issues. Any application can (more of less) be moved from one platform to another. It's a ";simple matter of programming," as the joke goes--which is to say that there's nothing necessarily trivial or quick about something as simple as moving from one vendor's Linux distribution to another (or even between versions) when real-world factors like testing qualification are factored in.

Thus claims that "all" that's needed to move off one vendor's cloud platform to another is to remap some of the value-added application programming interfaces (such as to a specialized database) or to integrate with a different management framework ring a bit hollow. IT shops stick with legacy platforms today because of far less onerous porting requirements to move to something new.

If there is one sine qua non though, it's the ability to extract the data that you own. On that, there is broad agreement, even if there are practical issues over formats and, sometimes, what data is "yours," exactly.

The discussion is further complicated because cloud computing takes place at several levels.

Roughly, the emerging consensus is that we can throw it into three big buckets: complete applications such as a hosted Microsoft Exchange or SharePoint service; a developer platform such as Google App Engine or Microsoft Azure; or something that's more akin to a bare-bones operating system, storage, or a database such Amazon Web Services.

Common shorthand for these three levels are software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). (Hardware as a service is sometimes used for this last category, but given the role now played by virtualization here, infrastructure seems the more accurate term.)

And, as Alistair Croll of Bitcurrent noted on the panel, the higher you move up the stack--the more abstractions you make use of above the basic infrastructure--the more lock-in you tend to inherit. The fact is that those abstractions (such as mechanisms to handle scaling for you automatically) save you work, but they also tend to be platform-specific.

As Alistair put it: "Developers are lazy in a good way. That's another word for optimization. Any cloud is going to evolve a set of value-add services. And that's the devil's payment. You have to be conscious of the lock-in you inherit."

But this is nothing new. It's not specific to cloud computing. It's not even specific to proprietary software. Want to move from a PostgreSQL to a MySQL database? Want to be renegade, switching from Linux to FreeBSD? Want to switch open-source content management systems? No one is keeping you. It's just a simple matter of programming and a little thing called time.

I just ran across this video from Sun Microsystems that demonstrates a source of disk latency that we usually don't think about. It's short and quite amusing. Take a look.

But being the analyst that I am, I also wanted to highlight some of the pieces that make the demonstration possible.

The technology that's under the covers, measuring the disk latency and so forth, is DTrace, a component of Solaris, originally developed by Bryan Cantrill. By way of background, here's what I wrote upon its introduction in Solaris 10:

DTrace stands for "Dynamic Tracing" and, indeed, it's that dynamism that most distinguishes it from other approaches. A developer, administrator, or performance tuner uses the DTrace scripting language to dynamically establish monitoring points of interest, whether in the OS kernel or user processes.

A probe is a location or activity to which DTrace can bind a request to perform a set of actions, like recording a stack trace, a time stamp, or a function argument. Think of them as programmable software sensors that gather interesting information about the system, and report it.

DTrace in Solaris 10 comes with something like 37,000 predefined probes; users can also define their own. Probes come from a variety of kernel modules that Sun calls providers, each of which creates a unique type of instrumentation.

For example, there's a provider that creates a simple time-based counter (profile) and another to understand lock contention and other sorts of locking behavior (lockstat). But essentially any function entry or exit is a potential probe location; DTrace hot-patches the function entry point in memory to insert the probe.

DTrace is an incredibly powerful tool in that it can do all this monitoring and measuring while minimizing its impact on a running system. (SystemTap is a Linux analog that's considerably less mature.) This allows DTrace to be used in conjunction with production systems--and thereby look for performance bottlenecks under real loads rather than synthetic test cases. The downside of DTrace is that you have to be a bit of a Solaris performance guru to actually make effective use of it.

Enter Fishworks, which Bryan calls DTrace-based appliance analytics.

With analytics, we sought to harness the great power of DTrace: its ability to answer ad hoc questions that are phrased in terms of the system's abstractions instead of its implementation. We saw an acute need for this in network storage, where even market-leading products cannot answer the most basic of questions: "what am I serving and to whom?" The key, of course, was to capture the strength of DTrace visually--and the trick was to give up enough of the arbitrary latitude of DTrace to allow for strictly visual interactions without giving up so much as to unnecessarily limit the power of the facility.

You can also find a more detailed overview of the analytics in this Sun presentation (PDF).

Fishworks is a big part of the secret sauce and value-add of Sun's recently introduced Storage 7000 Unified Storage Systems. It also reflects Sun's new, or at least "tweaked," software strategy. While DTrace is open source (under the CDDL license) along with the rest of OpenSolaris, the GUI dashboard, and other analytics software that makes use of DTrace, is not. This is consistent with a more pragmatic approach to open source on the part of Sun that allows for keeping proprietary modules and components mostly aimed at large-scale production deployments.

Fishworks is one of those--and an impressive one at that. It will know if you shout at your disks!

This post by Michael Dolan at IBM is spot on:

Here's the thing, everyone who hears "Linux desktop" has a knee-jerk reaction and thinks of all the things they do on their own PC, laptop, Mac. The reality is you're probably not the target market for virtual desktops. The market is large desktop environments that have thousands (perhaps tens of thousands) of users and who are not doing consumer-oriented work (or shouldn't be). The cost savings of moving from physical PCs in a 1 user to 1 PC model to a managed model with virtual terminals can be significant. We'll see where the market goes for this model, but I know of a few very large companies that want to make this model very real. The economic situation and the impact on IT budgets may act as an accelerant.

Much of the time when I write about the evolution of Linux or the evolution of the client, I get lots of comments revolving around the lack of popular games for Linux or whether the GIMP can replace Photoshop. And, of course, the partisans for whom it's important whether Linux "wins" or "loses" to Windows or Mac OS X jump in with their various ideological objectives. 

Idealogues and fanboys aside, however, part of the problem is terminology. "Desktop" gets used to refer to at least a couple of different things. One is the traditional, general purpose PC as we've come to know it over the past 20 years or so. The other is a shorthand for any client device with a keyboard and monitor. The former is a "fat client" with all that implies for a broad range of hardware support and available applications. The latter is more specialized. It may run only a limited subset of applications. Or it may run primarily network-based applications through an interface, such as a browser. Whatever the details, it's effectively much thinner--whether or not it's actually a thin client.

I'm not going to argue that Linux can't function as a reasonably general-purpose PC operating system. For example, developers who want a desktop, or more commonly a notebook, that runs Linux have lots of good distributions to choose from that (mostly) install straightforwardly. Ubuntu is a current favorite. But that's not mainstream mass market. And for reasons that I've gone into previously, such as the dynamics of independent software vendor support, I never expect it to be such if we're talking an operating system in today's Windows or OS X mold.

But the way that we access applications is changing. Many clients are predominantly platforms for browsers or they serve a very specific purpose. Virtualization could also change how we run an operating system or systems on our PCs and other devices. In short, there are plenty of roles for Linux on the "desktop," but it's not the desktop as we've historically known it.

About this time last year, I took a look back at some of the macro trends that hit their stride during 2007. I thought it would be interesting to see which of those trends are still noteworthy, which new ones are on the radar, and generally how the landscape has changed.

Server virtualization remains perhaps the hottest trend in IT. It may no longer be pegging the hype meter quite as hard, but that's only because server virtualization has moved into the mainstream. It's ever more clearly one of those fundamental developments that touches and transforms all manner of associated technologies, products, and processes.

To be sure, lots of virtualization customers are still using it for relatively straightforward server consolidation, but more and more are also implementing high availability and other services on top of a virtualization foundation. One notable event during the year was the ouster of Diane Greene from VMware's helm, but so far, neither this nor Microsoft's increasingly aggressive virtualization efforts have had a substantial impact on VMware's position as market leader.

Alternative clients are ways of provisioning applications and delivering software services that differ from the loading up of an operating system and clients on a traditional PC. This includes accessing applications through a browser interface. It also includes a variety of technologies that, collectively, keep desktop applications and/or operating systems in the data center, and push them out to user devices--including, but not limited to, thin clients--in a managed way.

This trend continues to gather pace, albeit in a relatively measured way, with security and compliance often the primary driving force. Most major virtualization players have steadily broadened their portfolios to encompass both client-side and server-side virtualization, taking advantage of one with the other.

Power and cooling, or more broadly, "green," remains at the same relatively nascent level as last year, when I wrote that "power and cooling is increasingly something that IT staffs think about--even if, in most cases, they're not the absolute top-of-mind worry that is sometimes suggested."

Running out of power or space in a facility remains the primary reason that companies take substantive action on major clean-technology projects. Because power bills are usually in someone else's budget, even operational cost savings--never mind generalized environmental concern--don't have a big impact on decisions absent high-level corporate mandates or governmental regulation.

Intel's resurgence continued in 2008, as it ramped its 45-nanometer processors. For its part, Advanced Micro Devices did take steps to repair the damage caused by its delayed "Barcelona" processors. Its 45nm "Shanghai" processor shipped ahead of schedule, lending credence to company claims that its development and manufacturing processes were back on track.

On the financial front, AMD put its Asset Smart plan in motion--essentially spinning off its fabrication plants and people as The Foundry Company, and taking a major investment from Abu Dhabi-based organizations. However, Intel retains a much stronger financial position during an economic period that is likely to be extremely challenging for the semiconductor business.

Open source and open-source licenses certainly didn't go away in 2008. But I don't really view them as a trend at this point any more than programming languages or databases. They're just part of the software landscape--a way to develop and market software.

Open source has, in a sense, won, and one of the consequences is that the license wars are largely over because of an implicit consensus that open source has proven to be a good development model that doesn't need a lot of protection through legalisms.

In particular, very few people are showing much enthusiasm for the Affero GPL, a license whose intent is to extend the GPL's restrictions (enhancements have to be contributed back to the community) to software delivered in the form of a service. Yet that's how an increasing amount of software will be used.

And that's really the trend that emerged in force this year: "cloud computing," a term that I use to refer broadly to using software services or infrastructure over the network.

To be sure, there's more vendor hype (and consumer use in the guise of Web 2.0) than there is enterprise adoption. And I strongly suspect that will remain the case for quite some time. Part of the reason is that deployments will tend to happen with new applications rather than legacy ones.

However, more broadly, enterprises will want to understand and have the tools to manage attributes such as security, compliance, and portability (including the ability to run applications on-premises, off-premises, or a combination of the two).

Is cloud computing a legitimate trend? Yes. And it will be a long-term trend, so just count this as a start.