[Wed Dec 31 10:35:23 CST 2003]

The SCO legal mess is getting more and more surreal by the week. The latest round appears to center on SCO's argument that the numbering sequence of errno in Linux is the same as in Unix System V. I mean, how much more ridiculous could this story get! Not only are those numbers standardized by now, but one could accomplish the very same thing without even reading the original source code. It is pretty clear by now that SCO is just trying to get bought (and therefore saved) by IBM or any other of the big companies that are betting on Linux. {link to this story}

[Wed Dec 31 10:22:11 CST 2003]

It has just been announced that the XFree86 core team is disbanding, and there are people over at Slashdot already worrying about the future of X in Linux. Needless to say, the fact that the XFree86 core team is disbanding should not affect opensource X development much. For starters, the so called core team had not contributed much lately, and most of the new code and bug fixes were actually coming from other developers. But, perhaps even more important, there are other projects out there such as Xouvert that can take over. {link to this story}

[Tue Dec 16 11:56:04 CST 2003]

Joel Spolsky, of Joel On Software fame, publishes an interesting review of Eric Raymond's Art of Unix Programming book. The complete book is also available online for free. Joel has pretty good things to say about the book, which is something I agree with. Eric Raymond's book will not teach you how to program, but it is the best synthesis of the Unix programming paradigm I have read so far. Nevertheless, what makes Joel's review so good is his objective and open minded approach to what too often becomes the war of the OSes. His simplified description of the key difference between the Unix and Windows worls is right on the money, I think:

What are the cultural differences between Unix and Windows programmers? There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers.

This is, of course, a major simplification, but really, that's the big difference: are we programming for programmers or end users? Everything else is commentary.

(...)

Suppose you take a Unix programmer and a Windows programmer and give them each the task of creating the same end-user application. The Unix programmer will create a command-line or text-driven core and occasionally, as an afterthought, build a GUI which drives that core. This way the main operations of the application will be available to other programmers who can invoke the program on the command line and read the results as text. The Windows programmer will tend to start with a GUI, and occasionally, as an afterthought, add a scripting language which can automate the operation of the GUI interface. This is appropriate for a culture in which 99.999% of the users are not programmers in any way, shape, or form, and have no interest in being one.

(...)

So you get these religious arguments. Unix is better because you can debug into libraries. Windows is better because Aunt Madge gets some confirmation that her email was actually sent. Actually, one is not better than another, they simply have different values: in Unix making things better for other programmers is a core value and in Windows making things better for Aunt Madge is a core value.

Amen, Joel. However, this raises a question: what if we are not developing for Aunt Madge or other programmers? What if we are developing for a server or a business workstation? Which paradigm better suits my needs then? I believe that is precisely where Linux may still have a nice chance of spreading to the desktop. The stability and flexibility of the Unix approach may win out to the "user-friendliness" of the Windows approach in a world where users can be trained and, most importantly, there is a good chance they are using the computer for a given and well specified task.   {link to this story}

[Mon Dec 15 10:50:00 CST 2003]

Brian Proffitt, Managing Editor of Linux Today, writes an article about the end of "Linux" as a branding term. Referring to the release of products such as Lindows or Sun's Java Desktop System, Proffitt argues that there appears to be a trend among the Linux distributions to move away from the term "Linux", perhaps as a way to sidestep Microsoft's negative PR against the product. It seems to me he is taking things out of proportion. First of all, most products out there are still associating the term "Linux" with their products because it comes with some name recognition, and while several products have been released as of lately that do not include it in their official names (Proffitt includes Fedora in the list, which I think is an overstretch), the fact remains that the vast majority of companies are still basing their marketing campaigns on the popularity of the Linux kernel. Of course, this includes Red Hat, whose main product is still called Red Hat Enterprise Linux. In summary, I think Proffitt is exaggerating things quite a bit, although it makes absolute sense for companies to emphasize what differentiates their products from other vendors' and in this sense stressing the kernel itself is of little help.   {link to this story}

[Thu Dec 4 13:07:26 CST 2003]

Tons and tons of words have been written about Red Hat's decision to discontinue its low-end Red Hat Linux distribution and open up its development to the community. Kurt Seifried wrote a piece in his own website on Fedora and the choices facing the system administrators now that they cannot enjoy a free Red Hat distribution anymore. It was precisely his comments about the policy that Fedora seems most likely to adopt for security updates that made me see the problem from a different perspective. Up until now, I had thought that Fedora should be the most natural replacement for those servers that are running an older version of Red Hat Linux that is about to be declared defunct. Problem is that Fedora's well stated plan is to walk on the edge, which quite often means updating a package rather than backporting a fix to a security problem. This makes complete sense for a distribution aimed at the desktop, but it poses some questions when one considers to deploy it in production servers. Let's be clear. A system administrator does not want to deal with constant upgrades of packages that could be vital just so that a security hole is closed. When it takes so much effort to test and deploy a working combination of software that does the job, one is skeptical of introducing any major changes until there is little choice and the whole system is then upgraded to a new release of the operating system. In this context, what is needed is a distribution that seriously commits itself to maintaining a stable branch of their product over a long period of time, and this involves backporting security fixes to older versions of the packages. Now, this pretty much rules out Fedora Core as a real alternative in the server land, although it still may make sense to deploy it on the desktop. What are we left with? It seems to me that all those system administrators out there who want to keep running their servers on open source software and cannot afford the price tag associated with Red Hat Enterprise Linux or other similar products only have two sensible choices: any of the free flavors of BSD or Debian.   {link to this story}

[Wed Dec 3 21:45:19 CST 2003]

Red Hat's latest move has certainly stirred a lot of debate in the Linux community. Let's be real though. Red Hat is a publicly traded company, and it needs to make money. It doesn't owe anything to the Linux fans out there, but rather to its investors. However, there is some self-criticism to make here. Remember how the community reacted to Caldera's idea of making money by enforcing per-seat licenses? Well, it truly seems as if they were right after all. Even Red Hat seems convinced now that this is the only way they can make money with Linux. As a matter of fact, the Terms and Conditions document for Red Hat Enterprise Linux (RHEL) clearly states:

If Customer wishes to increase the number of Installed System, then Customer will purchase from Red Hat additional Services for each additional Installed System. During the term of this Agreement and for one (1) year thereafter, Customer expressly grants to Red Hat the right to audit Customer's facilities and records from time to time in order to verify Customer's compliance with the terms and conditions of this Agreement.

In other words, terms that are not so different from the ones contained in the licenses of the much derided Caldera of the past. It may be time to rectify those snotty comments against them and acknowledge that perhaps they were right after all. It could very well be that, in the end, Caldera's problem was simply being a little bit ahead of the curve when it comes to the commercialization of Linux. When it was still a sin to use non-free applications, they were signing agreements with Netscape to port FastTrack and other products to the platform, just to find later on that Red Hat and others who had badmouthed them were all of a sudden willing to enter agreements with the likes of Oracle and Sybase. Then, when they suggested that business needs called for per-seat licenses, the world fell apart and everyone attacked such heretic proposal... just to see how Red Hat, the darling of open source, is enforcing them now. No, I don't think Red Hat is the devil now. I do think, however, that we should at least recognize the unfair way we treated Caldera in the recent past.   {link to this story}