« August 2006 | Main | October 2006 »
September 28, 2006
Vishy's Indian English Dictionary: rakhee sister
rakhee sister./rah·KHEE sis·tuh/. Not a blood sibling but one in spirit. A rakhee is a wristband that a woman ties on any man she considers her brother, in exchange for his protection (on a day called Raksha Bandhan, lit. bond of protection). After the rakhee is tied, the pair are bound as spiritual siblings who will look out for each other. It is fairly common to see men walking around on Raksha Bandhan day with their forearms covered in rakhees. Blood siblings also engage in this custom, but just as many rakhee brother-sister pairs, if not more, are unrelated by blood.
Needless to say, the ability to designate anybody as your sibling can easily be subverted—not all rakhees need be mutually consensual. Tying a rakhee on somebody's wrist is entirely the woman's prerogative, and a way to brush off unwelcome advances from a man. Sometimes, snubs can happen inadvertently. Suppose you're a man in American society and you're really attracted to a girl until she says to you one day, "I can tell you anything. You're like a brother to me." That's exactly how an Indian guy can feel if a girl surprises him with a rakhee. Of course, in both the American and Indian versions of the situation, the guy is supposed to react in the same way, with a smile that hides more than it shows, because he has just become a rakhee brother.
Posted by Vishy at 11:16 PM | Comments (0)
September 27, 2006
Vishy's Indian English Dictionary: kitty party
kitty party./ki·tee·PAH·tee/. A party where guests contribute money to a common pool, which is all given away to the guest who wins a drawing that happens at the party. Usually held on lazy afternoons and attended by Indian housewives, almost necessarily embellished with the attendant socializing and gossiping opportunities.
In fact, as I was growing up, I always thought of gossip as the primary function of these get-togethers. Stardust magazine at the time had a celebrity gossip column called "Nita's Natter", with a sultry cigarette-smoking cat as its icon. When kitty party mingled with this image in my head, I would imagine a coterie of Indian housewives transformed into gossiping cats at these social events. Sadly, as I later found out, the word kitty in this phrase has nothing to do with cats. It is more closely related to the table's prize in a game of poker, also called kitty by some (Why? The explanations don't seem entirely convincing to me.).
So now you know of one way Desperate Housewives in India amuse themselves.
Posted by Vishy at 10:17 PM | Comments (1)
September 20, 2006
A saner DRM scheme: marrying the media device and the cellphone
Why doesn't anybody like DRM?
Innovations in media distribution are matched at every step by "innovations" in DRM, short for Digital Rights Management or Digital Restrictions Management, depending on whom you ask. These innovations, sometimes implemented using dangerous methods, consist of ever more draconian restrictions on how a piece of media may be consumed and shared. The media industry continues to be wilfully blind towards how broadly unpopular these restrictions are.
In addition to being rooted in a mentality that treats customers as criminals, DRM schemes are unpopular because of how unnatural they feel compared to earlier forms of media. The purchase of a videotape legally confers rights on consumers to do with it as they pleased--make copies, lend it out to friends or resell it. On the other hand, with most DRM schemes today, media distributors set limits on how customers may consume digital media. These restrictions leave customers entirely beholden to media distributors well after the original purchase transaction has concluded. The de facto effect of these encumbrances is that consumers now license digital media from distributors, like commercial software, rather than purchase it outright. This purchase-but-not-quite leaves some customers feeling cheated out of their money.
Media distributors no doubt feel threatened by how the ease of reproduction of digital media directly hits at the foundation of their earlier business models. It is hard to argue from a legal standpoint that DRM should be eliminated entirely. It is not hard to see, however, that the slew of outrageous DRM restrictions from the entertainment industry stems from a sense of denial and disorientation in a world in which new media has changed the rules of the game. Many DRM schemes today are tied to an actual digital media artifact: a digital audio file, DVD or digital video download. An artifact may be played only until a certain date or only a certain number of times. Other DRM schemes tie media to the device that plays them. This kind of scheme makes it hard to share an artifact illicitly, but also gets in the way of customers who legitimately want to play an artifact on multiple devices they own.
It would be logical and consistent with earlier forms of media consumption to tie digital rights to a person rather than to an artifact or device. The rights to play an artifact are conferred on the owner of the artifact, and are fundamentally separate from the artifact itself and its medium of consumption. Any sane DRM scheme that won't end up imposing inordinate restrictions on its consumers must adhere to this principle.
One possible DRM scheme that fits the bill might be based on biometric data. Every media player might have a fingerprint reader to validate someone's identity before they play an artifact. Such a scheme would be terribly complicated because such biometric information would have to be programmed ahead of time into an artifact or a media player. Moreover, not everybody is going to be thrilled about handing fundamental, impossible-to-change biometric information like fingerprints or eyeball scans over to media distributors or media player manufacturers; the risk of a leak and subsequent abuse is simply too high. Ignoring the complications though, from the customer's point of view, this scheme would get a lot more right than Microsoft decreeing that a video may only be played thrice. For inspiration on how a similar, less complicated DRM scheme might work, we need look no further than everyone's humble companion: the cellphone.
A cellphone's SIM card effectively acts as a lightweight proxy for its owner's identity. Media players could be designed to accept a DRIM card, the digital rights equivalent of a SIM card. Much like SIM cards store their owner's contacts, DRIM cards stores rights pertaining to media artifacts. Media artifacts may reside separately on a media player's storage device but won't play unless there is a right for that artifact in the device's DRIM card. Rights on a DRIM would be truly offline. Unlike a SIM, a DRIM should not be required to contact the media distributor in any way before a media artifact is played. Rights stored on the DRIM should be mere tokens, which can be transferred as required.
It is easy to see how this system would be less infuriating than existing DRM schemes. You could play your media artifacts on any device you own by using your DRIM card in them. You could make as many copies of a media artifact as you want for backup purposes because no copying restrictions are 'baked into' the artifact. You could lend the artifact to a friend by copying it over to their device and then beaming its rights from your DRIM to thers, like some phones let you send your contacts to others via SMS. You could limit the term of the loan by specifying that such a rights transfer expire after some time. If you wish to resell a media artifact instead, you could have the new owner copy it from your device; they could then pay you to beam them a non-expiring rights transfer.
With its similarities to cellphones and SIM cards, mobile carriers surely have the know-how to implement a DRIM scheme to share media among mobile phones. With the growing buzz around mobile media, mobile payments and other mobile applications, mobile carriers might want think of how they can enter the value chain in this lucrative market. If mobile and media player manufacturers collaborate on a DRIM standard, we will be closer to a world where the power equation between a media distributor and a customer achieves some more balance. There is already a way; now all that's missing is the will.
Posted by Vishy at 10:55 PM | Comments (0)
September 14, 2006
Sun hires JRuby developers and wakes up to enterprise realities
Sun recently announced that they hired the chief developers of JRuby, a port of the Ruby programming language to the Java virtual machine. If this overture of Sun towards a non-Java language is any indication of future developments, backers of enterprise Java should be mighty pleased.
One of the things that has bothered me for a while about Java's platform philosophy is its dogma about everything being written in Java. Platforms in an enterprise setting tend to be heterogenous for a number of reasons. In a typical enterprise, where a variety of programming and scripting languages glue systems together into a cogent platform, Sun's official insistence on all-Java-or-nothing seems unrealistic at best and unnatural at worst.
Enterprise customers who wish to switch to a fully functional Java platform have two options: wait for Sun and the Java open source community to release Java libraries that do what you you need, or rewrite significant amounts of functionality in Java themselves, possibly mixing in several direct non-Java dependencies along the way to save time. The first option may be subject to Sun's exasperatingly slow Java Community Process. The second option negates the whole point of switching to a Java platform. To Java's credit, a significant amount of functionality available prior to its advent has already been ported to pure Java. But ask any software engineer and they'll tell you that Java isn't the best language for everything. A policy that officially supports only Java on the Java virtual machine ignores the reality of an enterprise—the mind-boggling heterogeneity in the kinds of technical tasks that need to be accomplished.
Microsoft .NET adopts a more pluralistic approach to languages on its platform. So long as someone makes the effort to write a platform-compliant compiler for a programming language, most of the existing libraries in that programming language can be adopted without too much effort. Writing a good compiler is harder than writing just any library, but the effort pays off immensely with regard to code reusability. More importantly, it is still less work than rewriting everything known to the industry in one language. Today, Microsoft .NET counts among its supported languages a systems programming language (C++), an object-oriented language (C#), a scripting language (IronPython), a functional language (F#) and even a dying language (COBOL). By embracing such a myriad of programming styles and languages, Microsoft .NET's approach reflects the reality of an enterprise better than a monolingual one.
If Sun has hired the JRuby developers because it has learned from Microsoft .NET's approach to programming languages, they are undoubtedly taking a step in the right direction. Before someone points out that I am ignoring Jython, a perfectly robust port of Python to the Java virtual machine, let me point out that Jython was never officially blessed by Sun. And we all know where Jim Hugunin, the creator of Jython, went. The Java platform could gain many more converts if it doesn't impose a reinvent-the-wheel-in-Java requirement. For this to happen, Sun could start out by officially bringing Ruby into the Java fold, along with other languages as time goes on. They could also (genuinely) open source Java platform specifications and let the open source community decide which languages get co-opted, as a recognition of its tireless efforts.
Here's to more announcements like this from Sun!
Posted by Vishy at 08:40 PM | Comments (0)
September 13, 2006
While you're shopping for that display, throw in some RAM too
Paul Boutin recently wrote a piece on Slate about how the best computer upgrade these days is a bigger display rather than a faster computer. While I agree with him, I think adding more memory to your computer might be an equally worthy contender for 'best computer upgrade'.
Setting aside the demanding gaming segment, personal computers, fueled by the gigahertz myth, have long been way more powerful than they need to be for basic tasks like Web browsing, checking email and light word processing. Boutin points out that switching around a set of related applications silently soaks up far more time than we realize. He claims noticeable gains in productivity after he switched to a higher display because he can now view the applications he reads with and writes with simultaneously. Boutin's arguments make a lot of sense, but are a little journalist-centric. Most other people use more than two applications at a time: one or more browser windows, an instant messenger, a media player and other applications as needed, such as a video editor or a spreadsheet. For example, a financial services professional may cycle through Microsoft Excel, Microsoft Outlook, a trading application and a Bloomberg news terminal. A software developer may cycle through a browser, Microsoft Outlook, an IDE and the application being developed. These are just two examples, but typical office or home tasks involve more than just two applications at a time.
With limited screen real estate and multiple open applications, a computer with say, Windows XP's supported minimum memory—64MB of RAM, slows to a drag because applications not being used actively get paged out to disk. Switching among a set of applications gets painful as portions of windows take forever to be read back from disk, be redrawn and be usable. Adding more memory to your system can bring about amazing increases in performance. To be sure, there is a limit beyond which adding more memory yields diminishing returns. Continuing to add more RAM is hardly a bad idea because with enough RAM, there may be no need to swap applications out to disk at all. Rather than agonizing over what exactly the sweet spot, if you're in the market for an large display anyway, just drop another $150 on a gigabyte of RAM. It is at least four times as cheap as a 24+" LCD display and offers quite a performance boost, especially if you use more than two applications at a time.
The problem with this advice is that adding RAM to a computer is not always as straightforward as hooking up a computer to a larger display. In the case of many PCs, it involves peeking under the hood and figuring out where to install RAM modules, but only after reading through several ominous warnings to ground yourself before handling them. My most painless memory upgrade experience (see page 79) has been with my MacBook: remove battery, pop out old modules, insert new ones, replace battery. The slightly more involved process of adding RAM to most computers means less people will be willing to try it, which is really a shame. I am sure most people will wise up to the benefits of added RAM once it becomes easier to augment a computer's memory. Windows Vista has a distinctive new feature called ReadyBoost™, which enables users to expand a system's available memory simply by sticking a memory key into its USB port. Once features like these become more commonplace, memory issues are bound to (*cough*) become a distant memory. Anyone who is particular about how much memory they will need could simply carry their own around. Internet cafés may just start putting up 'BYOB, BYOM' signs.
Oh, and don't forget to enjoy that new display also!
Posted by Vishy at 11:38 PM | Comments (0)
September 12, 2006
Vishy's Possibly Useful Factoid: Closing multiple windows together in Windows
To me, the taskbar grouping feature of Windows XP (or as some know it, Windows FP, for "Fisher Price") is a source of great consternation. While it saves me plenty of taskbar real estate, the grouping and ungrouping algorithms are entirely outside user control. Ordinarily, this wouldn't be a problem, but it is one of my pet annoyances that these algorithms are arbitrary and somewhat braindead about when they group and ungroup taskbar buttons (as an aside, I should note here that the Gnome desktop environment lets the user explicitly group and ungroup taskbar buttons).
Some aspects of Windows are plain idiotic, but they may merely hide a savant nature. One of my favorite parts about the taskbar grouping feature is the ability to close all windows in a group at once. I discovered by chance today how one could close multiple windows together as a group even if they aren't all part of the same group on the taskbar. I am about to reveal the secret of window closing on overdrive—the power of multiple selection brought to taskbar buttons.
Hold down the Ctrl and Shift keys and click on the taskbar buttons of all the windows you want to close. They will all depress, just like the button of the currently active window. Release the keys and right click on any of the buttons for the same menu that appears when you right click on an ordinary group. You can now close all of them, or cascade and tile only the ones you chose, if you are into that.
Go forth, grasshopper, and banish all those stray popups and windows that you forgot you even opened.
P.S.: In case you didn't know about this other, less obscure tip, hold down Shift as you click on the Close (X) button of any window to close other windows of the application ("related windows") at the same time.
Posted by Vishy at 08:36 PM | Comments (0)
September 11, 2006
Video on demand: perspectives and opportunities
Video on demand has seen a bit of action lately as broadband penetration continues to increase and old media roll out business models that take new realities into account. There is no dearth of players in the field, be they large companies or small, young companies or old. Sometimes, the players are not even those that one would expect. It is clear that this sector is quite immature and that early movers can do a lot to shape it in their image and grab a big slice of a multi-billion dollar market. This post will provide an overview of recent developments in video on demand (particularly in TV over IP), identify opportunities and speculate on future directions.
Video on demand players such as YouTube and Google Video are reaching stratospheric levels of user activity. When a startup that is little more than Flickr for video is valued at 600 million, it is safe to say that video on demand is hot. If the last presidential elections in the United States were powered by blogs, this one might well be powered by YouTube. At the moment, both these services are clearly in high demand, but they are both driven by a new media approach. Their continued success may well depend on how they integrate with other shades in the consumer media spectrum.
Integration with other types of media is what pre-Web 2.0 technology players in concert with old media can offer. Last week Amazon introduced Unbox, a movie and TV episode download service. The $9.99 movies and $1.99 TV episodes are owned by several traditional media houses. All videos come encoded with a Windows-only digital rights management system. Amazon is the least experienced player in this field and it almost seems they released a movie download service right now just to throw their hat into the ring and to steal some of Apple's thunder in the process. Apple, however, has always pulled off its media plays with remarkable finesse and timing. Their announcement of a movie download service and video-related enhancements to the iPod product line comes at a time when demand for consumer video is at a point of inflexion. The video iPod has enough of an installed base now that having the option of downloading movies from iTunes to them seems like a natural progression from downloading music and TV shows. Another key announcement among Apple's latest product releases is the one about a forthcoming set top box that will act as a media hub. This long awaited wireless device might well mark the convergence of PC and TV, a goal other players have tried to attain and failed.
Now for the more surprising aspects of this space. Netflix pioneered online video rentals and it was widely expected that it would tie up with somebody like TiVo to offer on-demand movie downloads to DVRs. For lack of will or execution, this partnership never materialized, and two companies that might have been uniquely positioned to move ahead of big players like Apple, Google and Microsoft just never capitalized on their advantages. As DVRs and movies on demand continue to be increasingly commoditized by basic cable providers, TiVo has probably lost the optimal window in which it could best reap the benefits of a collaboration with an online movie rental provider. Another surprise entrant in the video-on-demand arena is AT&T, with its Broadband TV service. Subscribers to this service can watch approximately 20 channels within the comfort of their browser. This service may not take off very well though because people want to watch TV content on a television rather than on a PC. Unless there is some way for downloaded content to be streamed to other media devices, AT&T's TV may well be just turn out to be the stunted arm in a triple-play offering. Another product line to watch is Microsoft's beachhead in the personal media space via its Zune media player. Although Microsoft is by no means early to the video on demand game, its existing relationships with content providers, relatively established content verticals and virtually limitless budget might portend a video on demand strategy that cannot be instantly dismissed.
In the context of cross-device integration, video on demand players might do well to evaluate their offerings with respect to the mobile and automotive segments as well. Media devices such as the PSP, mylo and iPods will continue to make steady inroads into the personal electronics segment. More and more cars come equipped with in-cabin video these days; having a plan to capture this portion of the market might yield large payoffs. Having coherent and interoperable Internet, mobile and automotive strategies might well prove to be the triple play of online video. The appointment of Google's Eric Schmidt to Apple's board might open up interesting ways in which the two companies can collaborate over video on demand. Even if Google's nationwide WiFi doesn't take off as expected, Google and Apple might be able to work out what to do with all the dark fiber the former has bought up.
Over all this potential for innovation hangs the specter of old media companies imposing excessively rigid digital rights restrictions on their content. Even after the realignment and introspection that old media is going through in response to challenges posed by new media, it is easy for them to revert to their content-is-king credo once video on demand has taken root sufficiently. One can only hope that their experiences collaborating with new media and technology players over video on demand will teach them that content alone is worthless without a good business model to accompany it.
| Strengths | Weaknesses |
|---|---|
| The increasing penetration of broadband and the coming of age of delivery technologies means video on demand is poised to take off. | Video on demand won't supplant existing delivery methods and become indispensable to consumers until they have the flexibility to stream content from and play content on any device they own. |
| Opportunities | Threats |
| The precise shape of a video on demand offering is still open to definition, and moving fast can still help shape the sector significantly. | Old media can stunt innovation in business models and delivery methods by drawing the old content-is-king canard. They can get away with it too because intellectual property laws currently work in their favor. If they don't adapt to the new ways of consuming content, they risk alienating users and failing to attain critical mass on their new media initiatives. |
Posted by Vishy at 12:24 AM | Comments (0)
September 01, 2006
Is platform heterogeneity in the enterprise inevitable?
Many small to midsize enterprises tend to be pragmatic about their choice of technology platform. Such enterprises would see no harm in operating on a single platform, such as Linux or Windows, so long as all its components work. Such an enterprise is willing to tolerate less than "best of breed" components so long as they all blend into a cohesive technology solution that satisfies its needs.Then there are other enterprises who are determined to use only those components, which, by some measure of goodness, have surpassed all others in their class. These enterprises are willing to stitch a platform together from these components themselves, even if it means that it will be heterogeneous and more complex to manage. Platform heterogeneity is unavoidable given the present enterprise software environment, so long as such enterprises exist. We will identify a few factors, which, when resolved, might enable one platform to claim the entire enterprise market for itself. We will also see why vibrant open-source communities are key to reducing the complexities associated with platform heterogeneity.
The second kind of enterprises identified above (let's call them "best-of-breed-only"--BOBO, for short) seem to accept platform heterogeneity as a fact of life. Unsurprisingly, these enterprises have significant technology investments and large internal development teams to support their internal IT operations. Year after year, major technology stack providers vie for their hearts and minds by commissioning industry analyst firms to conduct ROI/TCO studies that case their own offering in a better light.
Typically, one finds that BOBO enterprises choose Java on the server side and Windows/Microsoft .NET on the client side. Java, having been around twice as long as Microsoft .NET, offers a compelling server platform with a flourishing open source community around it. In many cases, the open source community brings to the table significant design experience and maturity arising from language traditions that predate Java. This development heritage has led to a superior set of administration and management tools that can be combined in new and interesting ways to provide the data administrators need. Moreover, a significant number of infrastructure and middleware players have thrown in their lot with Java, resulting in, for instance, multiple viable implementations of the Java virtual machine standard.
Microsoft .NET may not have as vibrant an open source community around it as Java, but it has a stranglehold on the client that is only cemented by vendors like Infragistics Inc., who produce professional-looking user interface controls around the basic windowing toolkit. The narrowly defined user interface standards of the Windows platform ultimately lead to a more predictable look-and-feel for end-users, thus making Microsoft .NET the best-of-breed client platform. The Windows/Microsoft .NET platform is also preferred by end-users because it can best emulate the look and feel of familiar Microsoft Office applications. Java rich client applications, in contrast, continue to look out of place amid other applications that share the desktop with them. However, because user expectations for Web interfaces are more flexible, Java continues to show considerable promise as a Web-based client platform. A definitive victory for Java Web client frameworks like Seam is not in sight though, because Microsoft .NET's ASP.NET Web development platform also offers a compelling platform on which software developers can be highly productive.
Java has arguably less of an uphill task than Microsoft .NET in taking over the entire enterprise segment. Its major areas of improvement are clearly seen to lie on the client side. Because of early positioning and quality control mistakes from Sun, Java has acquired a reputation of awkwardness on the client that has become hard to shake off. However, open source initiatives like the Apache Foundation have captured the talent, the momentum and the mindshare to produce a compelling, pure-Java client side solution if they only look beyond producing the next application server framework that conforms to some more JSRs. In other words, just because new projects keep satisfying some Java community-defined notion of cool doesn't mean they are always appropriate in an enterprise setting. This sort of "server-is-king" attitude is a holdover from an ancient mentality that treats the client and presentation layer as an afterthought once the core engine has been built. This attitude is outdated today, in an environment where it is necessary to access server-side business logic from disparate kinds of clients, including rich client and mobile profiles. Java's insistence on write-once-run-everywhere to the fullest extent possible might well prove to be its undoing in this regard, because writing versatile client frameworks requires a flexibility server-only engineers can afford not to have.
If Microsoft .NET's aim is to have the enterprise segment in its back pocket, there needs to be a much better sense of community and ownership around the platform. Microsoft is doing nothing to prevent the death of major open-source .NET projects like NDoc. If anything, it releases products that supplant these projects, such as Sandcastle in the case of NDoc. However, the blame for this state of affairs does not lie solely with Microsoft. Once Microsoft releases a competing implementation, community members consider their efforts necessarily nullified, a practice that does not bode well for the health of the platform. Open source projects on the Microsoft .NET platform must have a life of their own, independent of Microsoft's efforts, rather than being stop-gap efforts until an officially sanctioned product that supplants them comes along. Understandably, developers are wary of the Microsoft juggernaut's track record of entering a domain and instantly quenching all its competition. However, if the records of major .NET open source projects like Mono are to be believed, Microsoft's Developer Division, the division behind Microsoft .NET, has been remarkably open about and supportive of Microsoft .NET development originating outside Microsoft. It is, at least to some extent, the responsibility of the .NET open source community to consider accepting this hand of friendship, even if cautiously at first.
Then again, there may be those in the open-source community that won't have anything to do with Microsoft because "strong-arming is in Microsoft's DNA". For those incorrigible developers, there is the flourishing Mono project, which brings Microsoft .NET bindings to Linux. Currently, its focus is to provide a broad set of development stacks centered around the Common Language Runtime standard. As such, it is concentrating more on breadth of functionality rather than aggressive performance optimizations. If an aggressive corporate backer throws in its lot with Mono, as IBM once did with Java, it can work wonders for the entire Microsoft .NET development community. Microsoft would be forced to fine tune its own runtime, which is not aggressively optimized in all cases. The momentum gained from such aggressive optimization could infect the rest of the open-source community, thus spurring it on to developing a compelling administrative and management toolset itself, rather than relying on Microsoft to do so.
Platform heterogeneity may have its benefits, chiefly of not having to put all of one's eggs in one basket. However, it racks up significant technology and human costs and is necessarily more complex to manage. The custom platforms of many BOBO enterprises, for most of whom IT is not a core line of business, prevent them from simply outsourcing their IT function to completely managed hosting providers. The key to reducing platform heterogeneity lies in creating vibrant open-source communities around existing enterprise platforms, each with an objective to fix that platform's shortcomings. These open-source communities would no doubt compete for mindshare, but would also learn from each other and ultimately render platform heterogeneity less inevitable and technology costs more manageable.
[Update: For the sake of completeness, I should mention another category of firms, who, being afflicted with NIH syndrome, conclude that nothing out there is good enough and simply develop their entire technology stack from scratch. This harks back to the days when firms would write their own database systems and have programmers code up queries for each kind of report they wanted. Thankfully, due to the maturity of both commercial and open source software, not too many companies think this way anymore. Today even business analysts with a decent knowledge of SQL can define queries for reports. The firms in this category are mostly ISVs and other technology-heavy outfits that already have a significant investment in technology. It is difficult to call their platforms homogenuous or heterogenous, but it does add complexity simply because very few people know their proprietary systems.]
Posted by Vishy at 07:48 PM | Comments (0)