[Sat Mar 27 16:40:18 CST 2004]

Much has been written lately about the relative cost of ownership of Linux when compared to Windows. As it could be expected, Microsoft itself has published documents online to prove that it is cheaper in the long run to administer Windows. This is one of those issues where, just as in the case of performance benchmarks, about anyone can cite a study to back up his preferred OS of choice. Just point your browser to Google and do a quick search. However, when arguing in favor of betting on opensource technology, there is one major factor that I see being downplayed most of the time: that of flexibility or freedom. Could it be a reaction to Richard Stallman's aggressive campaigns to spread the gospel of free software? There are occasions where I am convinced that those supporting the concept of opensource simply go too far in their efforts to make their marketing sound very business-friendly, and completely ignore or set aside perfectly valid political arguments that also make sense when explained to a top manager of any company if we spell out all the implications. I believe the above mentioned benefits of flexibility and freedom from the tyranny of a single vendor are among these that we should emphasize more without fear to be labelled as free software lunatics. Please, let me explain. It was not so long ago that Red Hat decided to discontinue its low-end Linux distribution, choosing to concentrate instead on its more expensive enterprise product. Now, think whatever you want of this decision but there should not be any doubt that Red Hat's managers are in their right to make such move if they consider it furthers the goals and interests of their company. But where does this move leave you if you are the person in charge of making decisions at a small company somewhere? You have been running Red Hat Linux for years now, have invested quite a bit of effort into getting to know the OS, customizing it and developing on top if it, and now you have to switch to something different... or do you? Well, here is the key: because Red Hat builds its own products on top of an opensource platform, you can not only swap their Linux distribution for a different one more easily but you even have the choice to sign up with Progeny's Transition Service in order to obtain the security updates that Red Hat will not be providing anymore. Now is that a business advantage or not? The answer seems obvious to me. As Jonathan Feldman pointed out in a recent article published by Network Computing:

When Red Hat announced it would discontinue its old Linux line late last year, Progeny saw an opportunity. Its Transition Service issues annual software updates for $5 per user. In contrast, after Microsoft's Windows 98 end-of-life announcement, a business with 300 desktops would have had to dole out $60,000 to upgrade; 5,000 seats, $795,000. The fact that Microsoft recanted its decision doesn't put money back in the coffers of the companies that believed Windows 98 was dead and unsupportable. Conscientious managers didn't have a choice at the time — by not upgrading, they'd have left themselves at risk to viruses and other security breaches that could have resulted in even more costly scenarios.

Now, is this a business argument? I sure think so. Could anyone accuse me of being a lunatic free software evangelizer for arguing this point? I seriously doubt it. Let us not be afraid of using one of opensource's most powerful weapons. Mind you, I am all for common sense and pragmatism, but I just cannot see how avoiding the freedom from the tyranny of a sole vendor argument could help us at all. {link to this story}

[Sat Mar 27 16:23:49 CST 2004]

If many companies are finding out that opensource just works no matter what Steve Ballmer may think of it, governments all over the world are getting even more excited about the flexibility and empowerment that comes attached to opensource solutions. The state of Massachussetts has just released a software repository where government agencies can contribute and share their own software. It is something that just makes sense, especially in a world where governments are supposed to make more with less, not to talk about the special needs of foreign authorities that are not very thrilled about the prospects of becoming more and more dependent on an American industry such as Microsoft. Personally, as an EU citizen, I would rather have my governments spend money on opensource software that can be improved by local programmers see huge amounts of money syphoned out of the EU by the Redmond giant. Yes, Ballmer and Gates talk over and over again about how free software threatens to put an end to the software industry altogether (well, to be fair, it is none other than Earl McBride who has championed this position all the way to Congress lately), but that does not worry nearly as much as the idea of an out of control monopolistic (or semi-monopolistic, which in any case amounts to the same) software vendor which can do as it pleases in the ever more central technology field. I simply do not want to see a world where young Spanish developers from poor regions have no choice but to look towards Redmond if they ever want to live off their programming skills. Sure, I fully understand how that image may please the top managers of Microsoft, but my Government should not implement policies seeking to please Mr. Gates. {link to this story}

[Thu Mar 25 11:40:51 CST 2004]

There are a few technical topics out there that are every bit as controversial as political issues: the discussion on whether or not Microsoft is a monopoly, the future of opensource... As it could be expected, one of the main consequences of this contentious nature is the fact that most analysts appear to be incapable of taking an objective approach. So, it is refreshing to read Dan Farber's opinion on the six barriers to wide open source adoption. According to Farber, the barriers are:

• Informal support
• Velocity of change
• No roadmap
• Functional gaps
• Licensing caveats
• ISV endorsements

Some of these items (informal support, functional gaps, licensing caveats) should sound familiar to anyone who has been following the world of opensource for a while now. To be fair, there is a bit of misunderstanding in the first point since it is clearly possible for any company to purchase a decent support contract with vendors such as Red Hat or Novell, among others. We need to acknowledge that licensing issues are something that customers may have to deal with when using opensource, while in the past they did not have to worry about it if they were running commercial applications. I am not sure this is such a big issue or it makes a huge difference (after all, much has also been written and said about the old style end-user licenses and whether or not they were legally enforceable or even constitutional), but I nevertheless have to acknowledge that it is an issue.

So, what to say about the other items on the list? Well, it is certainly not difficult to argue that the functional gaps or the ISV endorsements should show up sooner or later as the popularity of opensource software spreads and it becomes more feasible to make money by selling applications that run on it. There are two other barriers from the list that, it seems to me, are more important and which we have not considered so much in the past. First of all, it is clear to anyone who switches from a commercial UNIX to Linux that the velocity of change in the Linux world is much higher. The dynamism of opensource is like a two-edged sword: on the one hand, end users benefit from new features much sooner than they would on other commercial platforms; but, on the other hand, this also makes guaranteeing the stability of the platform much more difficult. Let us clarify something here. We are not implying that Linux is unstable in the sense that it crashes too often or it needs to be rebooted once a week. We can call this the common acception of the term "stability". What we are referring to here is something far more important for large customers: whether or not the underlying development platform that one is supporting changes very often or not. The reality is that Linux in particular, and opensource software in general, changes quite often, therefore making it difficult to support thousands of workstations in a corporate wide deployment, for example. The same applies to deployments on application servers, which are used as development platforms that should not be changed so often. Yes, there are vendors such as Red Hat who came up with a solution to the problem: sell a more stable release of a disrtibution for a nice fee. The only problem is that this strategy undercuts something that, let us face it, remains opensource's main weapon: it is free as in beer. So, other than the adoption of a more stable Linux distribution, such as Debian, I simply cannot see any other solution to this conundrum. Finally, we must also acknowledge that the lack of a roadmap set on stone could also pose serious problems sometimes. This is a blessing and an omen at the same time. Why? It allows far more flexibility to the developers and, among other things, it also makes it possible for the end users to have a say in the future direction of a product, which is not even a choice in the case of commercial products unless they have enough business leverage. On the other hand, it is more difficult for users to make plans in the long term. However, let us be realistic: the so called roadmaps that we get from commercial vendors most of the time are nothing but guides that fail to guarantee anything at all. Our business world moves way too fast for these roadmaps to represent anything other than an overall intention of the vendor, which is, after all, not so different from what we deal with in the opensource world. {link to this story}

[Mon Mar 22 16:09:44 CST 2004]

Marc Andreessen, of Mosaic and Netscape fame, has published a list of 12 reasons to adopt opensource that makes quite a bit of sense. It goes from the obvious ("It's free" or "The Internet is powered by open source") to the insightful ("There are an increasing number of companies developing software that aren't software companies"), including a semi-humorous point ("Open source benefits from anti-American sentiments") that is nevertheless powerful. Mind you, Andreessen is not saying that opensource is anti-American, but only that it may benefit from an anti-American wave around the world. This is an important distinction. {link to this story}

[Sun Mar 21 16:45:49 CST 2004]

Havoc Pennington has written an article about the need for the opensource movement to adopt a high-level language for its desktop projects. Due to Pennington's affiliation, nobody should be surprised to see that his reasoning revolves around the GNOME desktop environment and completely ignores KDE, just the same way he refers to Linux and ignores FreeBSD, for example.

Adopting a high-level programming language, as opposed to C or C++, will bring about a few sorely needed benefits: coding efficiency, portability, security in the form of sandbox, use of component technology, etc. It was Miguel de Icaza who perhaps wrote about these issues for the first time when he published Let's Make Unix Not Suck several years ago. His commitment to porting Microsoft's .Net technology to Linux would later somehow tarnish his image among the free software evangelists but the fact remains that his insightful comments about UNIX's shortcomings were basically correct. So, why not bet the future on Mono? Pennington offers a few serious reasons not to do so:

Looking at the situation realistically, if GNOME started to require a .NET clone you'd see a fork, and if it started to require a proprietary JDK you'd see a fork. There are too many people who would find these directions unacceptable.

Microsoft has set a clever trap by standardizing the core of the CLI and C# language with ECMA, while keeping proprietary the class libraries such as ASP.NET and XAML. There's the appearance of an open managed runtime, but it's an incomplete platform, and no momentum or standards body exists to drive it to completion in an open manner. Many interesting class libraries are clearly encumbered by Microsoft IP and nobody concerned about legal liability will want to ship them. The core may also be encumbered, though that remains uncertain.

Aside from IP issues, Microsoft controls the .NET platform. They will always be ahead, and it will always be tuned for Windows. This is the wrong direction for free software, if we want to win the war, and not only some battles.

Even if we use some unencumbered ideas or designs from the .NET world, we should never define our open source managed runtime as a .NET clone.

If we built on the ECMA core, it would be critical to launch a large-scale effort to standardize and market a comprehensive alternative API set to replace the Microsoft-encumbered class libraries. This would be a heck of a lot of work.

These are, I believe, some serious non-dogmatic arguments against the idea of using Mono as the main component technology in GNOME. The problem is not so much the technology itself, but the dependency from Microsoft. It sure does not make much sense to compete against a company by adopting one of their technologies and making it a central piece of one's own products, especially when the competitor is still in control of the technology. Some will promptly say that Microsoft chose to standardize the core of the C# language with the international bodies, and that is at least technically correct. However, that is not the whole story. As Pennington points out, the key class libraries that will be needed in order to interoperate with Microsoft's own products in the future (ASP, mainly) are not public and standardized. Even worse, the Mono developers are bound to always follow Microsoft's lead and, to top it all off, there are way too many doubts about the possible legal issues one may step into by reverse-engineering these libraries. Let us be honest. Mono and the .Net framework are not the solution. What then? Well, Pennington makes what I consider a very sound argument in favor of betting on Java:

Java has broad industry acceptance, historically driven by Sun and IBM; it's by far the most-used platform in embedded and on the UNIX/Linux enterprise server. At the moment, it's more widely used on the web than .NET. It's the obvious default given the UNIX tradition of the open source community —have a look at the strength and volume of Java technology at Apache.org.

One virtue of Java is that it's at least somewhat an open standard; the Java Community Process isn't ideal, but it does cover all the important APIs. The barest core of .NET is an ECMA standard, but the class libraries of note are Microsoft-specific. It's unclear that anyone but Microsoft could have significant influence over the ECMA spec in any case.

(...)

Combining Java and Linux is interesting from another standpoint: it merges the two major Microsoft-alternative platforms into a united front.

Of course, there will be those who will argue in favor of Perl, Python or any other favorite high-level language. However, the reality is that those languages are still not up to the level where Java or C# are. Scripting is fine for short-term solutions, system administration scripts and even web applications, but not for large desktop applications or, even less, a wide framework. In this sense, Java offers both the power of languages such as C or C++, together with the ease of development offered by many scripting languages. It is, therefore, a good compromise, and one that certainly makes a heck of a lot more sense than Mono. {link to this story}

[Sat Mar 20 20:14:11 CST 2004]

Eric Raymond's plea to opensource Java has been the talk of the town for the last couple of weeks. It is something that makes a lot of sense, especially now that Microsoft is launching a full fledged assault against the language with its own .Net framework. It also fits nicely with Sun's latest moves towards Linux and opensource in general. About the only problem I can see is McNealy's doubts about the possibility of making money from something that is essentially free or, perhaps even more frightening, losing control of the technology altogether. However, as Eric Raymond puts it somewhere else:

One of the things I'm continuing to discuss with them is a strategy whereby they open control of the source [code]. That is, they issue the Java reference implementation under an open-source license, but they keep control of the brand. They keep control of the testing, they keep control of the verification, they keep control of the certification, they retain the right to say, "This and only this is Java" once it's passed our compliance tests and it's guaranteed interoperable with everything else.

As I say, it just makes sense, especially in the run-up to what most likely will be major conflict between proprietary and open technologies. Besides, if Scott McNealy needs any proof that it is possible to make money out of opensource he only needs to look at IBM. Java is still an excellent programming language, and over the past few years it has generated a large industry and made lots of money, but unless Sun lets it go now it will succumb to Microsoft's offensive. This is not a war that Sun will be able to fight on his one, in spite of all the bravado McNealy is good known for. {link to this story}

[Sat Mar 20 17:35:40 CST 2004]

It sure would not surprise to anyone if I repeat here the assertion that Microsoft, in spite of all its efforts to sell an image of itself that stresses their supposed "innovations", has actually innovated very little. Nevertheless, we all have to acknowledge Microsoft's enormous capacity to adopt somebody else's ideas, build on top of it and make a business out of it. They certainly do not innovate in the technology, but do innovate in the business side of things. Peter Coffee writes in eWeek about Microsoft's next generation command line for Longhorn. It sounds as if they will finally beef up Windows' always lacking command line interface, allowing direct access to .Net objects from the shell prompt. The idea definitely sounds exciting, but let us see how they implement it. I can also see a lot of potential for security breaches here. {link to this story}

[Sat Mar 20 17:18:59 CST 2004]

Just yesterday I was writing about the latest virus to be unleashed against Microsoft Outlook, and I decried the bad programming practices the company from Redmond has been practicing for decades now. Today, I came across a short piece on the improvements to be introduced by Windows XP Service Pack 2. There are a few things that indeed sound exciting: an upgraded firewall, changes to the way Outlook treats attachments and, above all, a new memory protection feature quite similar to Pro-Police. Let us just hope that Microsoft continues building on this work and finally departs from a tradition of messy, sloppy and insecure development. {link to this story}

[Sat Mar 20 16:58:41 CST 2004]

Who would have said just a couple of years ago? In spite of all its struggles, Cray is making money again and it even appears to have a future. It was not so long ago that I started working for SGI and came across a few old Cray engineers who gave me an interesting glimpse into what had been the history of computing in the good old days (i.e., before the arrival of the PC and the Internet). They were all extremely knowledgeable people, but somehow anchored in a time when dinosaur-like supercomputers were the latest novelty everyone cared about. They always looked back to those days with an understandable nostalgia, but it was obvious to me that real life had just passed them and they simply could not grasp a lot of new concepts. Of course, needless to say, I was just behaving to a great extent with the cheeky self-confidence that only a young inexperienced person can have. In any case, I was convinced that while supercomputers would still be needed by certain industries, it would be virtually impossible for large companies to survive on that market alone. The way I saw it, the likes of IBM, HP and Sun would end up crushing an independent Cray whose sole line of revenue came from the very high-end world of supercomputing. Why did I think so? Well, mainly due to their inability to spread administrative and other costs the same way those other companies might. To add insult to injury, there were quite a few startups seeking the nirvana of clustering technologies that would also compete against Cray from the low-end. Well, perhaps I was wrong in making all those assumptions, but something tells me Cray's current financial health should not be taken as an guaranteed indicator of what is to come in the near future. Would the company have been able to show the same results without 9/11 and the concurrent explosion of Government spending in national defense? And how about the Government's barely masked intervention to favor Cray and the national supercomputing industry in order to stop a massive triumph of NEC and other Japanese giants? {link to this story}

[Sat Mar 20 11:04:32 CST 2004]

One has to admire the developers involved in the OpenBSD Project for their relentless pursuit of a highly secure UNIX based operating system. Both commercial Unices and their opensource competitors have benefitted enormously from their work. O'Reilly published an interview with Marc Espie, one of the OpenBSD developers, and he does not seem to miss a chance to publicize his dislike for the way the Linux community is approaching security issues:

If we remove unsafe string functions and other projects add them back, it's like Sisyphus' story. We have to rewrite the same patches again and again when we import some external software. (...) Evolve the OS, not Revolutionize it. This is in violent contrast to Linux. (...) Weirdly enough, the Linux people are about the only major group of people that has constantly stayed deaf to these arguments. The chief opponent to strlcpy in glibc is most certainly Ulrich Drepper, who argues that good programmers don't need strlcpy, since they don't make mistakes while copying strings. This is a very mystifying point of view, since bugtraq daily proves that a lot of Linux and free software programmers are not that bright, and need all the help they can get.

There is little doubt that, in spite of them both being opensource projects, the BSD and the Linux families of operating systems do differ very deeply in their philosophies, and the fault line is perhaps the one Espie is pointing to here: while the Linux world loves the idea of revolution and offers a constantly changing landscape to our eyes, the BSDs prefer evolution by regular and constant improvements to the code base. Each has its strengths and weaknesses. Thus, while the BSDs truly tend to be more stable and rock solid, it is usually Linux that jumps ahead and experiments with new ideas, drivers and features that sooner or later make it to the BSD code base. It is the user's pick, and that is precisely what I love about opensource. They both, Linux and BSD, offer you a choice without locking you up in proprietary solutions. In the end, you and I win.

Espie also talks in the interview about a few security features recently added to OpenBSD, such as the static bounds checker, ProPolice, random loading libraries and W^X. Espie somehow manages to explain them all in very easy to understand terms. The interview is worth reading, whether you care about OpenBSD or not. {link to this story}

[Fri Mar 19 20:36:29 CST 2004]

Much has been written in the last few months about the SCO lawsuit against IBM over the alledged infringment of copyrights. Most people seem convinced that SCO is just resorting to some form of legal bribery in lieu of a real business plan. In any case, I found interesting and somehow refreshing Bob Evans' take on the whole SCO fiasco. He does not seem to care much who is right and who is wrong in the legal battle, but rather worries about the negative consequences that staying away from a disruptive technology like Linux could have to all those businesses that are too afraid of touching the penguin for a fear of SCO. Talking about Randy Mott, Dell's CIO and former CIO of Wal-Mart, Evans explains:

Leaders, he said, have to lead —they have to act in the very clear self-interest of their companies and their customers. Sure, he added, it's a good idea to be aware of such entanglements and to give some thought to how they might play out, but don't let that awareness spread to fixation. Because if we allow ourselves to drift into paralysis over something like what might happen in lawsuits over Linux, we'll miss market opportunities, slow the pace of innovation and transformation, and give competitors a break that they surely haven't earned. Somebody in some courtroom somewhere will sort out the Linux stuff, Mott said, and after that, some minor adjustments might have to be made, but those won't be nearly significant enough to affect the business at hand: pushing forward with innovative business ideas and the underlying IT systems that support them.

It is something to keep in mind now that SCO is threatening to sue all commercial users of Linux. It may sound strange, but worrying about SCO's legal threats in a world clearly dominated by constant change is the last thing any business should do. {link to this story}

[Fri Mar 19 20:11:58 CST 2004]

I understand Microsoft is the target of many viruses, at least in part, because it is the most widely spread operating system. Still, perhaps precisely due to this fact they should have taken extra care to release software that is much better designed and written. Today, we read that the latest virus (a handful of variants of the Bagle worm) is triggered without even the need of opening any attachments. It exploits a serious flaw in Microsoft Outlook that allows the hacker to download an a trojan written in Visual Basic Script. Sure, the flaw was discovered in October of 2003 and Microsoft already released a security patch some time ago. Still, what I find amazing is that a company that pretty much enjoys a monopoly of the desktop market has been releasing this sort of poorly written and designed software. It sure is not a problem of budget constraints, taking into account how much money they have in cash. {link to this story}

[Fri Mar 19 10:56:39 CST 2004]

According to CNet News, Novell has decided to opensource Yast, SuSE's software management tool. Their Linux distribution is not that popular here in the USA, so I suppose not many users are familiar with the tool. However, I must say that SuSE's Yast is quite impressive, both in its curses-based and its GUI versions. Not only does it allow you to install software from media quite easily, but it is also to update the system with new patches and updates from SuSE's servers and administer the different components of the system (printing, X, Apache, user accounts, etc.). On top of that, Yast has something that seems to be Red Hat's Achilles' heel: consistency. Things are where one thinks they should be, it feels natural, and the GUI version is 100% consistent with the curses-based version. So, why release it with a GPL license now? My guess is that Novell realized they will not be able to monetize it, but it can definitely hurt their main competitor's reputation, since up2date is still light-years behind Yast. {link to this story}

[Thu Mar 18 13:09:25 CST 2004]

O'Reilly publishes an article about the enormous growth of Gentoo in the world of Linux distributions. I am not so sure there are many people out there using it, but there is little doubt that it has grown a lot in the past couple of years and it has become more and more influential among the cognoscenti. The article contains a couple of things that should make us reflect. First of all, there is the issue of how to better organize a community-based software project. This is something the people at Debian have been struggling with for a few years now. When there is no central structure or hierarchy such as the one provided by a company, things can get out of hand easily. If the project is small enough, this could have no major consequences, but as it the group grows so do the problems, internal conflicts, difficulties to coordinate things... and there is a certain propensity to reach a stalemate. Second, and perhaps more important taking into account the nature of the Gentoo project, the very fact that end-users are allowed to customize and optimize their software appears to be causing some interesting problems. In this sense, it appears as if many users are sending bugs upstream that are just due to what we could call the zealotry of the over-optimization. For some time now, the idea that by compiling with certain optimizations we will end up with a super-fast system has been thriving. Well, it sure should not surprise many people that an excessive zealotry in the use of these optimization techniques could also result in buggy binaries. {link to this story}

[Mon Mar 15 16:01:55 CST 2004]

Things change fast in this field, but for whatever reason the idea that KDE is far superior to GNOME is still there in the air. I still come across people who have not used GNOME since version 1.4 (mind you, things have changed a lot in GNOME world since those days), tried KDE back in the days of version 1.0 and has stuck with them ever since. I suppose we humans are animals of habit, and there is no reason why software should be any different than any other field of human experience. However, GNOME 2.2 has definitely improved quite a bit on previous versions. I am not just talking performance, reliability or consistency here, but also what is more generically known as user experience. It seems obvious to me that GNOME has benefitted from the corporate support paid by Sun and other big names, and that cooperation has resulted in an attractive desktop environment whose main selling point could be precisely its simplicity, especially when compared to KDE's excess of options and customizations. I fully understand this is one of those topics too prone to burst into flame wars and personal crusades, but Ronny Klein has written a concise article with what I consider a few good points to support the view that GNOME could be preferable to KDE. It is nice to have a choice, unlike with certain other operating systems, but I believe GNOME 2.x deserves to be given another chance by all those who did not bother to try it since the 1.4 days. {link to this story}

[Sun Mar 14 20:19:16 CST 2004]

Life is not always fair, and business life is even worse. I have to mention this after reading that Microsoft and Intel plan to promote a new technical specification called WS-Discovery that sounds suspiciously similar to Sun's Jini. Say what you will about McNealy's guys, but you have to admit that innovate they do, especially when compared to their competitors in Washington state: Java, the network is the computer concept, thin clients, browser-centered approach to computing, open standards, mobile devices as the next frontier of the information revolution... Yet, for the most part they have been unable to reap the benefits. While Sun's researchers were always on the forefront of the next wave of technical inventions, other vendors managed to jump on the bandwagon a little bit late, make it look as if the whole thing was their own idea, and profit from it. So, what is this new technology?

... software that uses WS-Discovery could help a portable music player find a stereo receiver, or a cell phone tap into a local restaurant guide.

In other words, Jini. Of course, this other "innovative technology" is sponsored by the Wintel giants and expands the idea to the world of web services, beyond Java. As I explained, take somebody else's idea, and run. As usual, in a matter of 5 years or so the lay people will believe it was Microsoft and Intel who came up with the idea in the first place. {link to this story}

[Wed Mar 10 11:45:59 CST 2004]

Linux Journal published a short article about the process of building an enterprise Linux distribution that provides us with an interesting insight into what it takes to put together one of these box sets. The article itself is quite limited in that it does not enter into the details of the process, but it nevertheless offers us a nice overall view of the Red Hat Enterprise Linux development flow. For what we can read, Red Hat has exactly the same problem any other software vendor has: dealing with customer's expectations and demands without introducing unnecessary instabilities into the product.

When it comes to the objectives of the maintenance stream, it seems that all partners and high-profile customers speak out of both sides of their mouth. "Don't change anything! I'm using this release in production. Don't upset the apple cart", is followed by "I really need this feature immediately. Hurry up and give it to me, but don't put anything else in."

Needless to say, it can get quite messy when you have several hundred requests like that. As I say, there is nothing groundbreaking in the article, but it is sort of interesting to read about the real-life experiences of a Linux distributor. {link to this story}

[Wed Mar 10 10:54:59 CST 2004]

It has been a while since I developed something in PHP, but apparently the upcoming PHP version 5 promises a very exciting array of new features and improvements. For whatever reason, I have ended up using Perl more than PHP for my own web projects. There is something I really do not like in the very way the source code of PHP applications look. Granted this is just a matter of personal preference, but after all so are many of our decisions when we choose a language to develop in. I am not even sure I know how to explain it, but there is something that turns me off when I check the source code and see the chaotic combination of HTML and PHP code seamlessly meshed together. Yes, I understand a lot of Perl code out there is also hopelessly chaotic, but I have never been a big proponent of the "you too" type of arguments. I mean, sure, Perl code can be difficult to follow, but if PHP code can be the same too then... why change in the first place? Now, Python is a different proposition, I think, in the sense that it does offer a more clear alternative. In any case, I will not deny that PHP comes in handy to write quick and dirty projects in just a few days. On top of that, it offers pretty decent performance and, according to what I read, platform portability. So, why do I use Perl? I found a few reasons to use Perl: first of all, if it does the job, I do not see why I should switch to another language that does not offer me any clear and specific advantage; second, due to the fact that Perl has been around far longer, there is much more documentation, online tutorials, modules, etc.; and third, I also happen to administer my own server at home and simply do not want to handle security fixes every other month, and it appears to me as if PHP has vulnerabilities way too often. However, PHP version 5 appears to include a few interesting features: full object-oriented design, better XML support, and even built-in SQL database capabilities. It is planned to be released somewhere in May 2004, so it just makes sense to wait at least until the end of the year before using it in a production environment just to make sure the wrinkles have been ironed out. However, it may be worth considering PHP again. {link to this story}