Google Should Not Be Making Mac and Linux Users Wait for Chrome!

Google should not be making Mac and Linux users wait for Chrome.

I know:

  • There’s a significant guerrilla-marketing campaign in action – the officially unstated competition with Microsoft for ‘world domination’. First Apple (with Safari), and now Google (with Chrome), is besting Microsoft Internet Explorer on Windows platforms. In revisiting the browser wars of the late nineties, it’s crucial for Google Chrome to go toe-to-toe with the competition. And whether we like to admit it or not, that competition is Microsoft Internet Explorer on the Microsoft Windows platform.
  • The Mac and Linux ports will come from the Open Source’ing of Chrome … and we need to wait for this … Optimistically, that’s short-term pain, long-term gain.

BUT:

  • Google is risking alienating its Mac and Linux faithful … and this is philosophically at odds with all-things Google.
  • It’s 2008, not 1998. In the past, as an acknowledged fringe community, Mac users were accustomed to the 6-18 month lag in software availability. Linux users, on the other hand, were often satiated by me-too feature/functionality made available by the Open Source community. In 2008, however, we have come to expect support to appear simultaneously on Mac, Linux and Windows platforms. For example, Open Source Mozilla releases their flagship Firefox browser (as well as their Thunderbird email application) simultaneously on Mac and Linux as well as Windows platforms. Why not Chrome?

So, what should Google do in the interim:

  • Provide progress updates on a regular basis. Google requested email addresses from those Mac and Linux users interested in Chrome … Now they need to use them!
  • Continue to engage Mac/Linux users. The Chromium Blog, Chromium-Announce, Chromium-discuss, Chromium – Google Code, etc., comprise an excellent start. Alpha and beta programs, along the lines of Mozilla’s, might also be a good idea …
  • Commence work on ‘Browser War’ commercials. Apple’s purposefully understated commercials exploit weaknesses inherent in Microsoft-based PCs to promote their Macs. Microsoft’s fired back with (The Real) Bill Gates and comedian Jerry Seinfeld to … well … confuse us??? Shift to browsers. Enter Google. Enter Mozilla. Just think how much fun we’d all have! Surely Google can afford a few million to air an ad during Super Bowl XLII! Excessive? Fine. I’ll take the YouTube viral version at a fraction of the cost then … Just do it!

For now, the Pareto (80-20) principle remains in play. And although this drives a laser-sharp focus on Microsoft Internet Explorer on the Microsoft Windows platform at the outset, Google has to shift swiftly to Mac and Linux to really close on the disruptiveness of Chrome’s competitive volley.

And I, for one, can’t wait!

Notes 8.5 Public Beta 1 Client for Mac OS X and Linux

I stumbled across this announcement earlier today:

On 30 May, 2008 a newer version of the Notes 8.5 Mac OS X client was posted as part of the FULL Notes/Domino 8.5 Beta 1 release. 

Based on comments on a post I made March 2008, I decided to download the 355 MB tarball for Mac OS X.
On my first pass, I attempted to install over top of the private-beta client I described in that earlier post. Unfortunately, the provisioning step was partially successful. When I launched the Notes client, Eclipse started up … and shut down … 
I used the uninstall app that came with this latest tarball to remove the private-beta client. I then reinstalled the public-beta client, got acknowledgement that provisioning was successful, and ran the Notes client. 
In the words of Borat: “Great success!” 
The 500-MB-plus public beta client looks similar to the private-beta client, but it feels snappier. Your mileage may vary. 
Regardless, it’s encouraging to witness this progress. 
In addition to installing IBM Lotus Notes 8.5 Public Beta 1 on Mac OS X (Leopard), I also installed it on a Dell laptop running Ubuntu Hardy Heron – IBM offers a build of the Notes client packaged as a number of .deb files. This was my first experience with a native Notes client for Linux. So far, so good. 
Thanks IBM!
P.S. I expect the Release Notes cover off some of the sillyness I’ve shared here …

Book Review: Building Telephony Systems with Asterisk

Asterisk is a Open Source framework for building feature/functionality-rich telephony solutions. And although it’s able to compete solidly with offerings from commercial providers, the establishment of an Asterisk deployment is involved. Thus D. Gomillion and B. Dempster’s book Building Telephony Systems with Asterisk will be useful to anyone intending to delve into Asterisk. The book is comprised of nine chapters whose content can be summarized as follows:
  • In providing an introduction, Chapter 1 enumerates what Asterisk is and isn’t. Asterisk is a PBX plus IVR, voicemail and VoIP system. Asterisk is not an off-the-shelf phone system, SIP proxy or multi-platform solution. This enumeration leads to a welcome discussion on Asterisk’s fit for your needs. The authors quantify this fit in terms of flexibility vs. ease-of use, configuration-management UI, TCO and ROI. Although the latter to topics are covered briefly, the authors’ coverage will certainly serve to stimulate the right kinds of discussions.
  • Chapter 2 begins by enumerating the ways in which the Asterisk solution might connect to the PSTN. Next, in discussing the four types of terminal equipment (hard phones, soft phone, communications devices and PBXs), the major protocols supported by Asterisk are revealed – namely H.323, SIP and IAX. Whereas H.323 is well known to many of those who’ve delved in videoconferencing, and SIP to anyone who’s done any reading on VoIP, IAX is an interesting addition specific to Asterisk. The Inter-Asterisk eXchange (IAX) protocol attempts to address limitations inherent in H.323 and SIP relating to, e.g., NAT support, configurability, call trunking, sharing information amongst Asterisk servers plus codec support. IAX is not a standard and device support is somewhat limited but on the rise. As of this book’s writing, September 2005, IAX2 had deprecated IAX – and that still appears to be the case. Guidelines for device choice, compatibility with Asterisk, sound quality analysis and usability all receive attention in this chapter. The chapter closes with a useful discussion on the choice of extension length. Highly noteworthy, and already provided as a link above, is the voip-info.org wiki.
  • The installation of Asterisk is the focus of Chapter 3. After reviewing the required prerequisites, none of which are especially obscure, attention shifts to the Asterisk-specific components. In turn Zaptel (device drivers), libpri (PRI libraries) and Asterisk are installed from source. (I expect packaged versions of these components are now available for various Linux distributions.) Asterisk includes a plethora of configuration files, and these are given an overview in this chapter. And although it’s not mentioned, disciplined use of a revision control system like RCS is strongly advised. The chapter concludes with sections on running Asterisk interacting with its CLI to ensure correct operation, start/stop the service and so on.
  • With Asterisk installed, attention shifts to interface configuration in Chapter 4. In working through line and terminal configurations for Zaptel interfaces, one is humbled by the edifice that is the pre-IP world of voice. Our introduction to the intersection between the pre-IP and VoIP universes is completed by consideration of SIP and IAX configuration. Again humbling, the authors’ treatment affords us an appreciation of the application of acknowledged standards like SIP (which is itself based on RTP) through implementation. The final few sections of the chapter further emphasize the convergence capabilities of VoIP platforms by exposing us to voicemail, music-on-hold, message queues and conference rooms.
  • Through the creation of a dialplan, Asterisk’s functionalities and features can be customized for use. Dialplans are illustrated in Chapter 5 by establishing contexts, incoming/outgoing-call extensions, call queues, call parking, direct inward dialing, voicemail, automated phone directory and conference rooms. Customization is involved, and it is in chapters such as this one that the authors deliver significant value in their ability to move us swiftly towards a dialplan solution. Also evident from this chapter, and to paraphrase the authors, is Asterisk’s power and flexibility as a feature/functionality-rich telephony solution.
  • Under Asterisk, calls are tracked with Call Detail Records (CDRs). Data pertaining to each call can be logged locally to a flat file or to a database running on (preferably) a remote server. The database-oriented approach for managing CDR data is more flexible and powerful, even though it takes more effort to set up, as this solution is based on databases such as PostgreSQL or MySQL. CDR comprises the least-invasive approach for quality assurance. The remainder of the content in Chapter 6 focuses on more-invasive approaches such as monitoring and recording calls.
  • Based only on the context provided by this review, it is likely apparent that an Asterisk deployment requires considerable effort. Thus in Chapter 7, the authors introduce us to the turnkey solution known as Asterisk@Home. Asterisk@Home favors convenience at the expense of flexibility – e.g., the flavor of Linux (CentOS) as well as support components such as the database (MySQL) are predetermined. The Asterisk Management Portal (AMP), a key addition in Asterisk@Home, Webifies access to a number of user and administrator features/functionalities – voicemail, CRM, Flash Operator Panel (FOP, a real-time activity monitor), MeetMe control plus AMP (portal and server Asterisk@Home management) itself. Before completing the chapter with an introduction to the powerful SugarCRM component bundled with Asterisk@Home, the authors detail required steps to complete the deployment of Asterisk@Home for a simple use case. It’s chapters like this, that allow us to all-at-once appreciate the potential for the Asterisk platform. (Packt has recently released a book on AsteriskNOW. AsteriskNOW is the new name for Asterisk@Home.)
  • The SOHO, small business and hosted PBX are the three case studies that collectively comprise Chapter 8. Sequentially, the authors present the case-study scenario, some discussion, Asterisk configuration specifics, and conclusions. In taking this approach, the authors make clear the application of Asterisk to real-world scenarios of increasing complexity. In the SOHO case, the SIP shared object (chan_sip.so) is not loaded as this functionality is not required. This is but one example of how the authors attempt to convey best practices in the deployment of a production solution based on Asterisk.
  • Maintenance and security are considered in the final chapter of the book (Chapter 9). The chapter begins with a useful discussion on automating backups and system maintenance plus time synchronization. Those familiar with systems administration can focus on the Asterisk-specific pieces that will require their attention. This focus naturally leads to a discussion of recovering the Asterisk deployment in the event of a disaster. Security gets well-deserved consideration in this chapter from both the server and network perspective. For example, there is very useful and interesting content on securing the protocols used by Asterisk with a firewall. Before closing the chapter by identifying both the Open Source and commercial support offerings for Asterisk, the scalability of Asterisk is given attention.

This book was first published in September 2005 and is based on version 1.2.1 of Asterisk. As of this writing, Asterisk’s production version is 1.4.x, and the version 1.6 beta release is also available (see http://www.asterisk.org/ for more). Even though the book is somewhat dated, it remains useful in acquainting readers with Asterisk, and I have no reservations in strongly recommending it.
Disclaimer: The author was kindly provided with a copy of this book for review by the publisher.

Platform Acquires Scali Manage

From the joint release:

Platform Computing announced today it has acquired the Scali Manage business from Massachusetts-based Scali Inc. Scali Manage is an integrated and flexible High Performance Computing (HPC) cluster management and monitoring system. This strategic acquisition supports Platform’s vision to be the partner of choice for HPC infrastructure software worldwide. The Scali Manage product complements Platform’s existing HPC offerings and extends Platform’s products’ cluster and grid management capabilities.

As someone who worked for both companies, I can honestly state that this really does sound like a win-win outcome.

Scali has chosen to focus on its industry-leading MPI product.

Platform has broadened its cluster-management offering in a very significant way.

I remain a huge fan of Scali Manage more than a year after my departure from Scali.

Why?

Scali Manage is standards-based.

To appreciate the depth of this statement, please read my blog post from March 2006.

Moreover, Scali Manage is likely still the only software that can make this claim. Yes, there are open source offerings. But none of these are based on open standards like WBEM and Eclipse.

With people and technology transferring from Scali to Platform, I expect a very rosy future for Scali Manage.

Why Get a Mac?

Why get a Mac?

Here’s why:

I am in UK on a wireless network using the Macbook. What a great machine – everything seems to work as expected. While at York with no printer set up on the Macbook, I tried to print a file. It asked me two questions in plain English, do you want a network printer and what is its name. On the next keystroke virga printed my file.

The above is from an email message Keith Aldridge sent me earlier today.

Keith has had his Mac for a few weeks.

He later followed up with:

Machine is a breath of fresh air after a PC, especially for a unix/linux user.

What’s in Your SOAP Toolkit?

Your choice of SOAP toolkit may be the most important decision you make in implementing a Service Oriented Architecture (SOA) based on Web Services.

This wasn’t always the case.

For example, First-Generation Web Services (WS-1G) typically depicted SOAP, WSDL and UDDI as more-or-less equal players.

ws_triangle.png

In reality, however, UDDI was and remains (e.g., Erl, Chapter 3) a bit of a non-starter.

WSDL remains key, and continues to evolve with version 2 well on its way to becoming a bona fide standard.

So, what about SOAP?

In learning more about Second-Generation Web Services (WS-2G), I continue to be struck by how much value is being driven through SOAP. In turn then, WS-2G are being driven through XML, as SOAP makes use of XML. It is for reasons like this that SOA-guru Thomas Erl states that SOAs are ultimately all about XML and not Web Services (Erl, Chapter 3, Section 3.5.4).

And this returns us to the point made at the outset.

Because so much value is being driven through SOAP, you must choose your SOAP toolkit wisely. More specifically, toolkit choice will determine, for exanple, which WS-2G specifications are supported via implementations. Even more specifically, as a third-generation SOAP toolkit, Apache Axis2 includes core (e.g., WS-Addressing) and extended (e.g., WS-Coordination, WS-ReliableMessaging, WS-Security, etc.) implementations of a number of WS-2G standards.

SOAP toolkits may also reflect vendor bias. For example, IBM has championed WS-Notification, whereas Microsoft’s emphasis has been on WS-Eventing. These vendor biases at the standards level are quite likely reflected at the SOAP toolkit level. For example, it is reasonable to expect that an IBM SOAP toolkit would include an implementation of WS-Notification, whereas a Microsoft SOAP toolkit would offer one of WS-Eventing instead.

Even though working with SOAP may initially appear a low-level detail at the outset of conceptualizing a SOA, it turns to be a very important consideration that is amplified as SOA adoption proceeds.

Google Apps vs. Microsoft Office: It’s All About Platform Dominance

Remember the browser wars? Netscape vs. Microsoft?

What was ultimately at stake technically?

Platform dominance.

Netscape co-founder Marc Andreessen spoke frequently of browser-as-platform.

And let’s face it, the folks in Redmond have made a healthy business by owning the desktop platform. (In fact, based on the number of anti-trust suits against them, Microsoft may have been a tad too agressive in their quest for platform dominance.)

Why are software companies obsessed with platform dominance?

If you own the platform, you have a controlling influence in owning the software stack.

If you control/own the software stack, you own the customer.

How does this apply to Google Apps For Your Domain (GAFYD) vs. Microsoft Office?

Consider the Microsoft Office stack.

Microsoft

Individual applications like Microsoft Word and Microsoft Excel are ultimately built upon the Microsoft Windows. Common functionalities, tools and utilities, plus the interoperability that exists between applications, is enabled by Microsoft’s Component Object Model (COM). (Object Linking and Embedding, OLE, was superceded by COM.) Although third-party software providers can and do leverage Microsoft Windows and Microsoft COM, in the case of Microsoft Office, this is a wholly proprietary, single-vendor software stack. Own the stack, own the customer. Note also that any Internetworking capabilities are inherited by the applications in Microsoft Office via COM and Windows. Unfortunately, I don’t know to what extent Microsoft Office Live modifies this stack.

Now consider the GAFYD stack.

[Update: I’ve misplaced this figure. Please see the revised stack referenced in the comments.]

GAFYD exist within the context of a Web browser. GAFYD likely leverages various Googlisms made available via a Google API. Analogous to COM in the Microsoft case, this API can be and is being leveraged by third parties. The foundation for Google is based on a number of open standards:

  • XML for expressibility
  • HTTP and SOAP for exchanges
  • URIs for addressing

In addition to these underlying open standards, GAFYD has the potential to leverage emerging Web middleware such as Web Services, the Semantic Web and Grid Computing.

[Update: I’ve misplaced this figure. Please see the revised stack referenced in the comments.]

Along with his co-authors, Web inventor Sir Tim Berners-Lee has recently framed this context more completely elsewhere. The last two schematics are interpolated and extrapolated from the figure provided in the Berners-Lee et al. Science paper. The resulting unbundled, open-standards software stack is Web enabled from the outset. In striking contrast to the Microsoft case, GAFYD will likely result in a software ecosystem completely analogous to that developing around the Linux operating environment. This means that Google will battle Microsoft with only limited control of the software stack. They’ll need to rely on leveraging the rest of the stack, and ensuring that the promise of the Web (e.g., Web Services, the Semantic Web and Grid Computing) can be realized in GAFYD.