[Tue Sep 30 20:11:32 CDT 2003]

Things are getting tougher and tougher for Sun Microsystems. Just yesterday, a Sun's spokesperson announced that the company's fourth-quarter loss would amount to US $ 1.04 billion. Now, if that doesn't warn of troubles to come, I don't know what else would. For several years now, I've been convinced that Linux would sooner or later kill all commercial Unices, starting with SCO's Unixware, SGI's Irix, HP-UX and even IBM's AIX, but then moving onto Solaris itself. My assessment may have sound harsh to some in the past (perhaps less so now) but I simply fail to see any large advantage in the commercial flavors of Unix that Linux won't be able to attain eventually. Even more important though, Linux comes to solve Unix's eternal problem: the existence of multiple incompatible flavors that lock in the customers in a given type of hardware without offering other advantages in exchange. In other words, what would ultimately kill commercial Unices is simply a closeness which run against its very own foundations. While most engineers tend to view operating systems in terms of technical merits, the reality is that they operate in a business environment, not in academia. Contrary to what many people believe, the market doesn't pick winners and losers based solely on quality, but rather on a very wide arrange of features that may not come across as logical sometimes. What customers are interested on is open systems that don't lock them in with a given vendor's products (therefore allowing them to migrate their customized software easily in case they see a better opportunity somewhere else or the vendor simply shuts down) and applications, applications and applications. General Motors, Ford, Boeing, Lockheed Martin, Walmart, Coke, the US Army and the small business around the corner couldn't care any less which OS keeps their systems running as long as it is stable enough, secure enough (mind you, in both case the key word is enough, and not perfect), and the software they need runs fine on it. Features? Yes, they do matter. But guess what? If the market demands it, they will be added to any OS sooner or later. Heck, remember DOS?

So, what's Sun to do? Well, most people will readily recognize that the company has been on the edge of innovation for quite some time now and chances are that things will remain that way for quite some time. Sure, Bill Joy recently quit and that was a hard blow to the company's prestige. Still, they have plenty of other bright people working for them. They have recently unveiled a revolutionary new prototype chip technology that has the potential of tilting the balance in their favor... although it remains pure vaporware and nobody even knows if it will even see the light. They are also trying their hand at Linux, with the release of the Java Desktop System, a commodity PC loaded with their own Linux distribution, totally customized for the business desktop, and ready to plug into any network built around web services. Will all this be enough to save the company? Who knows? As Chris Preimesberger argues, one of Sun's weaknesses right now is precisely the fact that they appear to have way too many products. One cannot avoid the feeling that Sun management is so desperate to recover after the dot com fiasco that they are tipping their toes in pretty much every single market out there just to see what works. Understandably, the investors seem to be convinced that the company has lots its compass. What would I recommend? Well, I'd say they should do some of the things they already appear to be pushing for, and then more. In any case, they truly should go for it, avoiding that age old problem of traditional management: a timorous "let's stick to what we know" type of solution. Some interesting ideas I would definitely explore if I were Sun management: release technologies such as Java and even Solaris itself to the open source community, get more involved in the development of the Linux kernel and contribute enterprise technology to it, bet seriously on the Java Desktop System as a way to push Microsoft out of the business desktop market, and continue competing for the high-end server market by making more inroads in scalability to be able to compete against the likes of IBM, Cray and SGI.

[Tue Sep 23 08:27:19 CDT 2003]

Are Java's cross-platform capabilities truly that important? That's precisely what Peter Varhol considers in an article published in JavaPro. True, Java's claim to popularity was its "write once, run anywhere" mantra, and there is a good chance this is precisely what counts for the explosion of Java development we saw back in 1996-1997. Yet, as Varhol points out,

At one point in time, portability meant something to software developers. Today, it seems less important, primarily because something happened in the meantime. The unexpected rise of Web-based applications meant that client components didn't have to be written for different end-user computers. (...) This result made the client largely irrelevant, especially in custom application development. Today, we all use a Web-based application of some type almost every day. This includes applications in use within our company, or on-line e-commerce applications such as those provided by the likes of Amazon.com and LLBean.com.

I know, I know, we should also remember that certain implementations of Java have become incompatible with Sun's Java standards. In order to sell more of their products and differentiate themselves in the market, companies such as BEA came up with implementations that will simply break the "write once, run anywhere" idea. Yet, the reality is that it is still possible for the most part to write code in Java that will remain portable across platforms if one makes an effort to avoid those proprietary solutions. That's not the problem. The problem is that once the Web has become so pervasive, we already have the answer to our problems without a need to fall for any vendor lock-in trick. Windows, UNIX, MacOS and Linux systems all speak HTTP, both on the server and the client side. Just add web services to that and you already have a solution that runs fine on a heterogeneous network, and one is still in charge when choosing a language (or languages) to implement it all: Perl, Python, C#, Java... Add to this that most companies won't be really switching their server platforms every other day. Let's be realistic, once system administrators install and configure an application (perhaps even a Java application) on a given piece of hardware running a given operating system, what are the chances they will be meddling with it and switching to another platform? Well, if that's the case, then Sun would better start stressing other advantages of using Java.

Does this mean that Java is dead? Not really. It is still possible to argue in favor of the language on other grounds. It does allow for a relatively fast development cycle at the same time that the code is quite maintainable, it is well featured, supported and popular enough to find good professionals who are familiar with it. Also, as Varhol points out,

... in practice, few actually intend to run Java code on different systems. The portability they desire is between the developer workstation (typically a Windows or Linux desktop system) and the target hardware, operating system, and application server. Beyond that, there is little need to port to other platforms, especially once the application is up and running. Although it does occasionally happen, it's rare for enterprises to radically change platforms in production, because doing so requires a large capital investment, as well as significant retraining.

[Sun Sep 21 16:52:39 CDT 2003]

I still haven't written a word about the SCO lawsuit, mainly because it's not as if I'm an expert in US law and there are plenty of other people who are already speaking way too much on the issue. As it's the case with many other controversial topics, this has also become an entertainment of sorts, at least among certain technical and geeky circles. The result is that we end up with way too many people who know way too little about the issues being brought up to court writing and speaking way too many words that actually fail to clarify anything at all. In other words, we end up stuck with a lot of politics and farcical posing instead of serious debate. Why do I say this? Well, because it seems obvious to me that most people are getting confused about the true nature of the lawsuit, although we must also acknowledge that SCO is doing little to clear up the smoke with its famous slides disclosing code that was allegedly copied directly from Unix System V. Eric Raymond published a position paper answering those accusations already, and Bruce Perens has done so too. However, the true nature of the lawsuit has absolutely nothing to do with this, although everyone seems to be forgetting this little detail perhaps because one would have to recognize that SCO may have a chance to make an argument after all. It all boils down to an alleged breach of contract by IBM when they supposedly acted against the AT&T license by which they obtained the Unix source code. Now, what does that license stipulate? It states very clearly that

AT&T grants to Licensee a personal, nontransferable and nonexclusive right to use Software Product solely for Licensee's own internal business purposes and solely on or in conjunction with Designated CPUs for such Software Product. Such right to use includes the right to modify such Software Product and to prepare derivative works based on such Software Product, provided the resulting materials are treated hereunder as part of the original Software Product.

And this is precisely where SCO may have a nice shot. IBM is in its right to modify the source code and sell it as such "provided the resulting materials are treated hereunder as part of the original Software Product". This last sentence is vital in this case. Again, I'm no expert in these issues, but it seems to me that lots of other people who know nothing about the topic too are speaking way too loud. If code such as the one in the JFS and XFS file systems written by IBM and SGI is to be considered derived work (and there is a good chance a cogent and logical argument in favor of this interpretation could be made in court), then SCO would be right. In that case, it's not as if the open source community somehow behaved in a dishonest manner and copied code from Unix System V, but companies that wrote derived work from it contributed it to the Linux community and therefore breached the above mentioned AT&T contract. Now, that's the gist of SCO's argument once we take out all the posturing and image, and I'm afraid it is precisely this real argument that won't be defeated so easily.

[Thu Sep 18 12:35:05 CDT 2003]

Jef Riskin, known for his work in the Macintosh GUI, just published an interesting article about IDEs. Among other ideas, he mentions that

Most current IDEs make adding comments difficult, sometimes painful: You often have to wrap comments by hand, discouraging paragraph-length explanations, or at least discouraging their editing.

When it comes to the practice of commenting code, Riskin points out how the problem is not so much to explain how the code works but why one needs to write a certain routine in order to bypass an obscure hardware or software limitation. It is precisely this type of comments that become extremely useful when one needs to maintain an application at a later stage. But how we know then when writing a comment is truly necessary instead of being just one more example of extreme verbosity? Riskin offers an illustration that I found quite intriguing as a methodology:

In the past, APL and Forth were given as exemplars of undocumentable languages, but their extreme compactness meant that a single line of code often required a small dissertation. I managed a large project based on Forth, and the result was very readable and maintainable. To achieve this, we had regular code-reading sessions in which one programmer read and commented on each piece of code written by another programmer. In addition, an expert documenter/writer worked alongside the programmers. If he did not understand a piece of code, he would interview the programmers until he could write a cogent explanation.

But that's not all. He also stresses the limitations of the IDEs and modern languages such as Visual Basic, which sometimes come to put some serious boundaries to human creativity even though they may be useful at another level.

A prime example of this is Visual Basic (VB). A VB program soon becomes a morass of windows and requires a slog of opening and closing windows to create a program or to follow what is happening in a program. The language is largely unstructured, and writing a program is a wrist-numbing experience. Not only is the environment hellish, but also the language is frustrating to use unless your interface restricts itself to the standard Microsoft widgets. Creativity and imagination are rapidly punished; anything outside the interface norm is either inordinately difficult or impossible to do. The problems with the interface to VB and its reluctance to implement new interface widgets are especially surprising, considering that the person credited with designing VB writes books on interface design.

Not only does he also find it arguable that object-oriented languages such as Smalltalk could be the ultimate paradigm due to their "deluge of classes" but he also has something to say about open source development that sounds pretty logical to me, although perhaps a bit controversial:

Open-source development --in many ways a blessing, in that you can dig into the guts of a system if you need to is also cursed by the oft-undisciplined masses that contribute to most open-source projects. There is little quality control and few who choose to document their work carefully and professionally.

All in all, it's a short interesting article full of puzzling suggestions. I do like to program in object-oriented languages, but the object-oriented fanaticism is something I've simply never understood. As Riskin says, the large amount of classes and interfaces is too overwhelming quite often, and one ends up spending more time just checking the documentation than actually coding. The same can be said about the use of IDEs. I'm more of a vi type of guy, but fully acknowledge the importance of using IDEs in some instances. However, I deeply dislike any talk of an IDE as a silver bullet that will come to solve all of the developer's problems. Simply put, there is no such a thing, and it's about time we come to terms with this reality. I cannot explain how many times I took a programming class here or there and the tutor had to spend some nice amount of time just explaining how to use this or that IDE tool instead of how to program in the given language that we paid to learn.

[Tue Sep 16 13:54:56 CDT 2003]

Well, a few days ago I wrote about Bill Joy leaving Sun and how there were rumors going around over whether or not he disagreed with the direction the company is taking lately. Today, I came across an article published by CNet News on Scott McNealy that doesn't paint a nice portrait of Sun's future. As the author, Charles Cooper, puts it,

By the time big tech companies approach middle age, they either wind up reinventing themselves or start sliding into mediocrity. It happened to Microsoft, to mention one of the best recent examples. Say what you like about Bill Gates, but he oversaw an ambitious refashioning that left his company stronger than before. The same can't be said for Sun Microsystems, a one-time high-flying server maker whose strategy --if you can call it that-- has been to throw a lot of stuff against the wall and wait to see what sticks.

Sure, we all know that Sun stands behind their vision that states that "the network is the computer", and there is even a chance that as visions go this might be good enough to keep going, but nobody knows how the company intends to put this into practice. In other words, Sun, unlike other companies in the same sector (Novell, SGI...) does have a vision but it lacks a plan to bring it about. As Cooper says, one gets the impression that McNealy et alii are just obsessed with throwing ideas around to see which one sticks in the imagination of the customers. In other words, their moves smack of despair, and it shows. It shows when they make public statements against Eclipse and then decide that they may join the effort after all, or when they deride Linux over and over again and then put Scott McNealy on a ridiculous display on stage wearing a penguing suit and touting the benefits of open source. Who can blame the analysts for being skeptical about the future of the company?

[Sat Sep 13 11:40:15 CDT 2003]

Bill Joy, Chief Scientist at Sun Microsystems, announced this week that he is leaving the company. As anyone could imagine, even though Joy didn't open his mouth yet to explain why he is leaving the company that he co-founded, rumors are flying already: he is at odds with top management over the direction the company should be taking, he lost faith in the future of Sun... take your pick, there is plenty going around. I couldn't care less about all that though. I think Bill Joy should rather be remembered for his technical contributions to the UNIX world: BSD, NFS, several designs of the UltraSPARC processor, some work on Java, and vi, the simple text editor. Whatever it is that Bill Joy wants to do with his life from now on, let's just hope that it is at least half as productive as it's been so far and we all will be much better off.

[Thu Sep 11 17:20:18 CDT 2003]

Now, I must admit that hearing companies like Microsoft whine about the supposedly anti-competitive practices of foreign governments really pisses me off. In response to a recent deal signed by the Chinese, Japanase and South Korean governments to develop and promote an open source operating system, one of Microsoft's top executives in Asia stated that

We'd like to see the market decide who the winners are in the software industry. Governments should not be in the position to decide who the winners are.

So, in other words, "the market", at least according to Microsoft's view of it, does not and cannot include the governments. Apparently, they are supposed to act in a vacuum and are not allowed to make decisions based on whatever makes business sense for them. What is "the market" then? Only private companies then? Perhaps only those that purchase Microsoft products? Now, that's an interesting economic concept that they are coming up with. Sorry, I cannot see why governments cannot make purchasing decisions based on their interests and those of their own citizens, instead of the interests of an American corporation based in Seattle. After all, isn't that what free market is supposed to be all about? The different economic agents, including the public sector, make decisions based on their own interests and the invisible hand will take care of the rest. What Microsoft is talking about here is not free market at all, but rather pure self-interest disguised in neoliberal clothes.

[Tue Sep 9 11:34:12 CDT 2003]

From time to time, one reads articles about how Linux is quickly getting there but it still has a ways to go when compared to other more mainstream operating systems. Well, I just came across one more such article: We Have Met the Enemy, and He is Us, written by Dave Salvator and posted on Extreme Tech. I must say that while agreeing with the author's proposal of an open source movement more aimed at finishing the products than it currently is the case, I also find some of his criticisms in large part invalid. Let's see. Salvator starts telling us about his problems with Linux:

The community effort to expand and improve the OS is amazing. But based on my experiences, Linux is still a mixed bag -- with plenty of late-night-where's-the-nearest-hammer infuriation over stuff that just won't work. (...) I recently took a second stab at putting together a Linux-based PVR/media jukebox server system. I got further this time, but I'm still staring at a system that just won't work.

Needless to say, the Internet is full of stories from people who tried to implement the very same thing on other platforms, including Windows, and are still staring at a system that just won't work"... and that without even getting down to the price sticker issue. In other words, what Salvator is trying to accomplish is not your regular weekend project. It's something costly and complex. So, he ran into a few bumps along the road. And what? Is he really surprised about it?

In any case, Salvator's complaints become more detailed as on reads on, and to be honest, they sound quite familiar. First of all, he criticizes what most people usually refer to as "dependency hell", although acknowledging that projects

like Debian's apt-get, Gentoo's emerge and Yellow Dog's yum do a very good job of addressing this problem. They do dependency checks up front, gather the needed bits from trusted servers, and surprisingly, they often get your app installed.

Well, I suppose it's not a problem then, right? In any case, this has been debated quite often in the open source community. Sure, Windows usually comes up as an example of how it should be done. However, this obviates that a real solution should not only be "user-friendly" but also technically sound, and I seriously doubt that the way Windows does software installs should truly be hailed as an example. Compiling everything statically and bundling the libraries with every single darn application doesn't sound so attractive, I think. Sure, it solves the dependency problem, but at what cost? To make matters worse, Salvator adds that his favorite installer

... will tell you where it put the damned executables. (...) Windows may be the devil, but at least you can easily figure out where an application installs itself.

Pardon me? As luck has it, I had to install putty just the very same day I read this article. Well, I couldn't tell where the executable went, I couldn't see any entry in the programs menu, and I finally had to struggle with a poorly designed new search functionality in Windows XP to find where the heck the file went. The morale? It's not the installer but the packaging that does the trick. There are ways in Linux to automatically add an entry to the program menu in GNOME or KDE just as in Windows or the MacOS, but a poorly packaged application will not take advantage of these mechanisms on any OS. And don't even get me started about how Windows leaves piles of files lingering around after one chose to uninstall the application that put them there in the first place, or how the filesystem always ends up being a complete mess after one installs more than ten applications, or... and yet, for some obscure reason, we all have to assume that Windows is "user-friendly" and gets installations right.

So, where do I agree with Salvator? Well, as he puts it,

It's time for the Linux world to throw the "project" concept out the window too. Stop thinking of these development efforts as works-in-progress, and start thinking of them as products. Not in the charging money way, but in the "finish and ship" way. Linux applications need to just work. (...) I'm not proposing that we dumb down Linux. I'm not proposing that we bury code behind some curtain that no one can see. I'm just asking that Linux application developers think their projects through from A to Z, with Z representing a polished product that installs successfully with minimal fuss.

The reality is that way too many open source applications out there can hardly be called "products" at all. They are, as Salvator points out, "projects", and unfinished ones at that. Yes, there are exceptions, and Apache, Sendmail or Samba certainly come up to mind as good examples. Yet, even these programs are constantly being worked on and changed from one version to another, and it is perfectly possible to download and install a beta or even alpha release of any of them at any given time. What is the problem then? How come we hear complaints about a myriad other applications and not so much about Apache or Samba in this respect? I'd say it's mainly due to the fact that those projects clearly establish the line between the version that has been released and the one that is under development, just like the Linux kernel itself does. Do you want to run the CVS version of a given application with its latest bag of tricks? You're free to do so, but it may or may not run, and it may or may not even install. You have been warned. As long as the line between one and the other release is clear (and as long as both versions actually exist, at least for larger projects), I don't see anything wrong with this either. After all, it's an intrinsic part of the open source philosophy itself, and without this I seriously doubt we'd also be able to reap the benefits of widely tested software, etc. It's the price one pays for more freedom.

[Fri Sep 5 15:21:51 CDT 2003]

Microsoft appears to be getting ready to enter the mobile phone market after signing a deal with Motorola. With this move, it seems clear that the platforms war is moving to this relatively new but fast growing market. The reason is clear. This is precisely the market where Java and Linux have a fighting chance, and Microsoft doesn't want to be caught by surprise there too, as it happened with the Internet back in the early and mid-1990s. After all, it wasn't so long ago that we read how consumer electronic giants Sony, Samsung, NEC, Matsushita (Panasonic), Philips, Sharp and Toshiba signed up a partnership to standardize Linux for consumer electronic devices. It's no coincidence that Motorola recently dumped most of its shares in Symbian either, since that is precisely a major competitor of Microsoft in mobile phone software. In other words, get ready to witness another mother of all battles in this field in the years to come. Pretty much everybody is convinced that the server and desktop markets are already saturated, and the technology industry needs to look somewhere else for revenue growth. These mobile gadgets look like the perfect candidate right now, especially since they open the door to the as yet untapped consumer market (well, sure some families do have computers at home, but that's absolutely nothing compared to the pervasiveness of consumer electronic devices everywhere... now, that's a market!). Even more important, this will be the battleground where both Java and .Net will meet each other to lay down the basis of tomorrow's consumer services. The stakes are pretty high, and both Sun and Microsoft know that imposing their own technology as the standard in this new market will generate a lot of revenue on the server side.