Last week I was in Copenhagen for YAPC::Europe. One of the announcements at the conference was the location of next year’s conference which will be in Lisbon. The theme of next year’s conference will be “Corporate Perl”. And that (along with a couple of conversations last night) got me thinking about a talk that I’ll submit to next year’s conference which might well be entitled “Why Corporates Hate Perl”.

It’s not true, of course. There are a still large number of large companies who love Perl. I could probably work through to my retirement enhancing and extending systems that are written in Perl at many of the big banks in the City of London. There are, however, also many companies who are moving away from Perl for a number of reasons. Here’s one of the reasons that will be included in my talk.

I was talking to people from one such company last night. The Powers That Be at this company have announced that Perl is no longer their language of choice for web systems and that over time (probably a lot of time) systems will be rewritten in a combination of Java and PHP. Management have started to refer to Perl-based systems as “legacy” and to generally disparage it. This attitude has seeped through to non-technical business users who have started to worry if developers mention a system that is written in Perl. Business users, of course, don’t want nasty old, broken Perl code. They want the shiny new technologies.

And so, in a matter of months, the technical managers at this company have created a business environment where Perl is seen as the cause of most of the problems with the current systems. It’s an impressive piece of social engineering.

It’s also, of course, completely unfair. I don’t deny at all that this company (like many others) has a large amount of badly written and hard to maintain Perl code. But I maintain that this isn’t directly due to the code being written in Perl. It’s because the Perl code has developed piecemeal over the last ten or so years in an environment where there was no design authority which encouraged developers to think beyond getting their immediate task done. Many of these systems date back to this company’s first steps onto the internet and were made by separate departments who had no interaction with each other. It’s not really a surprise that the systems don’t interact well and a lot of the code is hard to maintain.

There are, on the other hand, a number of newer systems which are also written in Perl which follow current best practices in Perl development and are far easier to to maintain and enhance - as easy, I would contend, as anything written in the new approved languages.

It’s certainly true that this company has a large number of systems that need to be rewritten over the next few years. But throwing away all of the company’s accumulated Perl expertise and moving to new languages seems to be a step too far. Management are blaming Perl for the problems when really they should be blaming the management and design procedures that were in place (or, more likely, weren’t in place) when the code was originally written.

Many organisations are in the same situation, with large amounts of unwieldy Perl code. Ten or twelve years ago everyone was writing web systems in Perl and we were all making mistakes. We all have to deal with those mistakes but we’ve, hopefully, learned from them and can rewrite our systems to take account of everything that we’ve learned in the last ten years.

It’s too late for the company I’ve been talking about in this article. The anti-Perl social engineering has probably insinuated itself too deeply into the culture. It’s unlikely that Perl’s reputation can be rescued.

But if you have similar problems in your own company, then please try to ensure that blame is apportioned correctly and that you don’t use Perl as a scapegoat.

A while ago, I published a teaser on this blog about using the Web as a whole as a data storage object. At that time I said that “the Web right now is cut down into a million pieces that don’t talk to each other properly”. Almost two years have gone by since that article and it looks like not much has changed.

One of the early questions was how interoperable are Web services when they’re not envisioned and created by them same company. This problem lead to a number of initiatives that are trying to push forward Web services creation standards. DataPortability, for example, is evangelizing a number of different standards that will create a better interoperable Web:

• end user authentication through OpenID;
• inter-application authorization through OAuth;
• information syndication and distribution through RSS, RDF and OPML;
• information meaning and automatic extraction through microformats;
• user attention profiling through APML;
• messaging and information brokerage through XMPP.

This collection of standards and best practices is great when a large number of companies start following them. For us, developers, it means that by following these standards our Web services will be interoperable with all other Web services that use the same standards. It means that creating a Web service now is much easier than it would have been two years ago.

What about the end users? How can they take advantage of this interoperability? I’m not just talking about Web services that let you consume data, because that problem was solved a long time ago by aggregators. Aggregators are a good example of a class of Web application that survives because there’s a de facto standard in place: RSS.

So, my point is, how can end users take advantage of Web services that let you publish, transform and assemble information? We’re moving to a point where a number of emerging services give you a one-to-many publishing approach:

• Ping.fm and HelloTxt publish your status across multiple services, like twitter, jaiku and Pownce;
• Typepad’s Blog It publishes blog articles across different platforms and also announces them on different status services;
• twitxr publishes your pictures across different services like flickr and Picasa.

Is it just me or there’s a pattern emerging here? Users see value in these services because they save you precious time by automating repeatable actions, like publishing a picture across different services. One thing to notice, though, is that these services only provide half of all that’s possible with the existing Web.

All these services let you choose among a number of services and then broadcast your information to all of them. Forgetting minor format and content adaptations, they won’t give you the possibility of programming the flow of your information. One thing is to shoot a picture and send it to different services, another thing is letting users tell how that picture flows through different services.

One service that’s offering you the capability of configuring this flow of information is switchAbit. It evolved from an original idea by Dave Winer that you could grab your pictures from flickr and post a tweet for each one of them. Quoting Dave’s original post:

The SwitchABit platform was developed because we noticed that an ever more complex flow of ideas and information is being facilitated by editorial systems and aggregators such as Flickr, Facebook, Twitter, FriendFeed, Seesmic, Qik, Ustream, YouTube, BlogTalkRadio, Disqus, Wordpress, Tumblr, TypePad, Blogger, etc.

switchAbit is basically an RSS to publish mechanism. It’s built around the pub-sub paradigm which means that it will get your information from a number of services, filter it according to your instructions and publish part of it into other services.

With this approach you’d still have to publish your information on at least one supported service, so that switchAbit grabs it and routes it somewhere else. Another approach is acting like a reverse aggregator, extending the functionalities of Ping.fm and others by adding the possibility of configuring information flow.

You could, for instance, add a watermark or a copyright notice to the picture, extract EXIF geo-location information and send it to Fire Eagle, publish the transformed picture on a number of services, and announce it to your contacts on some social networks. And this is just an example of what can be done in the near future.

I’ve been working since January on such an application. It has an interface similar to Yahoo! Pipes, but it lets you compose the flow of information from a starting point through a set of Web services that exist on the cloud. Because of the obvious similarities of this concept with the familiar UNIX pipe, it’s called tarpipe. Quoting tarpipe’s blog original post:

tarpipe will also create an ecosystem where Web applications and services will be able to receive and transform media content. Users will take advantage of this ecosystem by defining delivery and transformation workflows for their documents.

With tarpipe you can direct the output of one Web service into the input of another one. This makes different services virtually interoperable, even if they’re not able to talk to each other individually. It also gives end users the ability to compose flows of actions (or workflows) for their information. It currently accepts information sent through email and a REST endpoint, meaning you can extend your application by connecting it to tarpipe.

So, my initial thought that “the Web right now is cut down into a million pieces that don’t talk to each other properly” is not so true anymore. There are ways of making the Web more interoperable, like following de facto standards and creating programmable service adapters.

At last Thursday’s Ignite Boston, which I wrote up in a previous blog, provided an unexpected mirror in which two opposing views shined on each other, each view provided by one of the two keynotes by John Viega and Jonathan Zdziarski.

Both Viega and Zdziarski.are security experts and authors of books by O’Reilly and other publishers. Viega used the bully pulpit for an entreaty against the “full disclosure” philosophy, a fundamental article in the open source catechism. Zdziarski, who had not consulted with Viega beforehand, endorsed full disclosure whole-heartedly and with a doggedly pragmatic intent. The context for Zdziarski’s approach is the Apple iPhone, which has security vulnerabilities that, in his experience, Apple doesn’t fix until they’re made embarrassingly public.

Today Zdziarski sent me a long and frightening article from the National Journal about the threat of cyberwar. Although the basic premises in the article have been circulating for years, many of the details were new to me. And despite the focus of the title on China, the article makes it clear that governments as well as individuals (the “cyber-militia”) are engaging in disruptive behavior around the world. In fact, the article cites worries about what may be happening in the NSA.

It seems to me that the National Journal article provides more fodder for Viega than Zdziarski. Veiga insisted that the black hats planning DDOS attacks and identity theft aren’t as smart as they are commonly made out to be. They couldn’t create as much havoc if they had to rely only on the vulnerabilities they found themselves. They are helped immeasurably, he said, by the revelations of vulnerabilities in major software products by people with no malicious intent. The worldwide database of known vulnerabilities is swelled by individuals trying to show off their technical chops, and by companies in the security business trying to demonstrate the indispensibility of their products.

So long as software vendors are slow to fix bugs, full disclosure has to be an option, a kind of last resort, and I think Viega allowed for this. Open source projects have to promote a sense of responsibility among contributors to be discreet in reporting bugs with security implications. Perhaps it doesn’t matter much anyway–because most people keep using unpatched versions of software long after fixes come out.

Giles Bowkett’s Never Hate. Only Destroy. (disclosure: contains language your local third graders probably use and your work filter might block as inappropriate) contains a side point which crystallized something I’ve pondered for several weeks:

The whole point of the Cory Doctorow Problem is that the fundamental assumption with Internet celebrities - that a very smart person will always be interesting - is false…. What irritates me is essentially a search failure; I can seek excellent insight on social software and end up reading pointless trivia about a corporate amusement park filled with plastic birds on plastic trees.

This is my problem with current social networks as well. Your information is either public or it’s not. You’re either connected to someone or you’re not. There’s little to no sense of context.

The ever-creative Wade Olson (of KDE fame) tells an interesting story of immediately losing interest in otherwise-interesting hardware due to “Intellectual Property” protections. He caught himself going from caring to not caring in the time it took to read the phrase “Don’t expect Linux support anytime soon.”. His conclusion is:

Vendors need to beware: Intellectual Property gains, once thought to be a Competitive Advantage, will continually over time become a negative branding attribute.

I’ve noticed this myself. I don’t particularly care what Microsoft does, what NVidia does, or what Adobe does. Their products don’t really matter to me when I can use other products without giving up freedoms I consider essential.

Have you had similar experiences?

A proposal to help editors work better with dynamic languages — by not pretending they are static, and by leveraging their unit tests.

As a Test Driven Developer, using dynamic languages, editors frequently disappoint me. The main thrust of editor research, for the past few decades, targets debugging static languages. This post suggests a very simple fix.

For years, many people have argued that one of PHP’s big successes is deployment. The language has little to recommend it for anything beyond simple database-backed HTML templating, but there’s little easier than dropping a couple of .php files in a directory through FTP.

While there are still millions of wonderful (and ultimately unproductive) flamewars about how mod_php is faster than vanilla CGI Perl and Ruby uses too much memory and FastCGI is unstable and shared-everything on a monster JVM is obviously more scalable, none of that will ever matter to most of the deployed PHP code in the world today.

A Perlbuzz commenter named Yudel made the deployment/colonization point very clearly:

I still think in Perl, but as an only occasional programmer, I seldom find it the best tool for the job. The Perl community failed to successfully colonize the new ecosystems of programmers who don’t have root access. Simply asserting that PHP is linguistically inferior won’t convince anyone who has had to argue with a web hosting company about the load MovableType was placing on their servers.

mod_perl is great for what it does, but it’s clear that mod_perl isn’t what hosting providers most wanted. A slim Perl distribution — including perhaps a new Apache httpd module which only embeds Perl — with a good templating module, the DBI, and perhaps an XML parsing module or two could have put Perl on more $4.95/month hosting plans. The corollary to that of course is an easily installable bundle of Pure Perl for an application.

Sure, that doesn’t cover everything. You probably can’t get RT orPlagger or Angerwhale in such a system, but it’s a start.

Ceding the very low end of a technology to an upstart is just one of the ways to let distruptive innovation eat your lunch.

One flaw in this argument is that approximately zero webhosts supported Ruby before the Rails lovefest. As well, the Rails deployment strategy went through several iterations. Here’s the interesting point which subverts my argument somewhat: Rails hosting suddenly became lucrative enough that several Ruby-friendly hosts appeared.

I haven’t yet figured that out.

Yesterday Google celebrated the opening of a larger Cambridge, Massachusetts office, which takes up a substantial part of a building right next to the Kendall/MIT subway stop in the higher-than-high tech area of East Cambridge. I got a look at their new Friend Connect service (covered in a related Radar blog) and heard some fascinating comments that the staff kindly let me reproduce here.

Google staff certainly know how to say the right things and react in ways I approve to the situations Google finds itself in. More and more people I know (including authors) are Google employees, which is statistically predictable because more and more people in general are Google employees. The Cambridge office has been growing wildly since it began with the purchase of the company that created Android. And this office is one of 45 Google offices around the world.

This raises the question of whether the empire can be supported through continued sales of advertising, and whether Google’s stated openness carries through to employee behavior on the ground. I explored these questions with managers and staff at

I like numbers. They can mean a lot of things.

Rather than continuing silly arguments over obfuscated and flawed measurements of “language popularity”, perhaps a better way of measuring the viability of a language or platform is to measure the freshness of its ecosystem.

LaPerla’s How Fresh is the CPAN? measures the upload dates of one of the world’s largest and most active repositories of free software. Of the 12,000 (or is it 14,000 now?) distributions on the CPAN, 25% have a most recent upload date of February 2008 or newer. Half have an upload date of 2007 or newer.

You don’t get those kinds of statistics by putting “Ruby Programming” into Google and pretending the results are meaningful.

I promised to explore the theme of Free-loading Adoption of F/OSS in more detail. Alan Rimm-Kaufman’s Why Small Businesses Should Support Open Source is a great place to start:

It doesn’t matter if your donation is large or small. It doesn’t matter if you give money or code.

What does matter is this: if you’re benefiting from the Open Source Movement, try to give something back.

It makes good business sense. And it is the right thing to do.

Before I joined O’Reilly, I worked in a small consulting company. As I joined, the company was migrating away from proprietary platforms to open platforms. We saved a tremendous amount of money and gave our customers far better service. Being able to use, modify, and redistribute free software let us finish jobs we’d never have been able to do otherwise.

In return, we submitted bug reports. We occasionally submitted patches, both on and off the clock. We knew that we owed a great deal of our business to a healthy commons of free and open source software… and now I know that keeping that commons free, open, and healthy was vital to the business.

The owner of the company allowed the Portland Perl Mongers to meet in our offices once a month. He rented chairs for the meeting. Maybe it’s not a big thing, but it was a way to pay back part of one of the communities which had produced so much great software integral to our business.

You don’t have to hire a core developer. You don’t have to release your own (non-derivative) source code. You don’t have to donate money to a foundation, or host a conference or a meeting.

You don’t have to contribute back to the communities which produce software you rely on… but if you rely on it now, aren’t you interested in its healthy future as well?

Issue 16 of [IN]Secure Magazine is available. Mirko Zorz interviewed me in this edition (Page 41). If you decide to read it, I’d be delighted to hear your thoughts and feedback. The magazine edition of the interview is much better looking and highly recommended (as are the other articles), but for the sake of convenience, the interview session is below.

Four days ago, the FCC held a widely publicized hearing at Stanford about bandwidth regulation on the Internet. In my summary analysis and background explanation of an earlier hearing at Harvard, I referred to the oft-criticized Brett Glass, whose experience running a rural wireless ISP radiates a different perspective from all other commentators. Glass got to speak at the Standford hearing, and his brief remarks offer a readable explanation of a key technical issue–the effects of file-sharing on bandwidth–as well as an appreciation for the worries on all sides.

Small ISPs such as Glass’s (and yes, they do exist, even today) have none of the incentives that network neutrality advocates attribute to major carriers to discriminate against voice, video, or other content. In fact according to Glass, new applications such as VoIP are great because they provide new business. “This week we hooked up a VoIP company which was dissatisfied with the quality of service it was getting from the incumbent in our area. We deployed a low-latency, high-bandwidth radio link just for them, at a cost (parts and labor) of about $1,000. We can justify the cost because we will be paid for the service. It’s cost-shifting without compensation that’s the big issue for all ISPs–large and small.”

Glass has a stake at least as precarious in the current Internet economy as the media companies using peer-to-peer transmission as part of their business plans. Laws or regulations that fail to take economics into account, in his view, could put small ISPs out of business. He defends his position fiercely, and gets plenty of flak in return. I consider Glass a friend and have even planned to tap him as an author on some projects. So I want his view heard as a balance to the “just throw more bandwidth at it” proposals.

That said, I wonder whether the problem is really peer-to-peer protocols, which Glass focuses on, or high-volume media such as video. What architecture could handle the video experiences Internet users want. Compression can achieve impressive quality at reasonable bandwidth, but the sheer volume of everybody sharing the network stresses current transmission systems.

Matt Asay kicked up a small controversy in MySQL adoption: Deep and wide when he wrote:

Now the only thing missing in that conversation is the enterprise stepping up to pay for some or all of its free-loading adoption of MySQL. This is what is prompting MySQL to consider new licensing models. It would be very easily resolved by enterprises for owning up to and paying for the value they derive from open source, very little of which comes down to a lower price tag.

I’d like to extend that to projects beyond MySQL and to a definition of “contribution” far beyond opening a checkbook. Here’s my thesis: if your organization derives some benefit from a community-driven software project, you have a moral obligation to contribute to the health of that community in some way.

I’ll write more about this tomorrow.

There’s been some recent chatter and speculation on the upcoming enhancement to the PCI standard. Among the discussions, I’d like to publicize my opinion on one argument I’ve heard multiple times during the last few days. The argument goes something like this: The cost of performing security code reviews is too high, but the cost of performing black box reviews and/or implementing web application firewalls is lower. Therefore, the solution is to recommend that organizations rely on penetration assessments and/or web application firewalls.

Remember Andy Lester’s rant about Can’t You Just…?. There aren’t often easy answers in any field.

I really like what Chris Cummer had to say in a comment on “All I Need is a Programmer”:

Every time you use “just” to describe a feature or a process it tells me you’ve made a gross assumption about what I’ll need to do.

(Of particular amusement is when non-contributors tell volunteers what to do in free software projects.)

A conference attendance that tops 2000 suggests that a technology involves a certain number of subtle angles. MySQL became a hit because installing it and manipulating tables were so simple–and yet when you get serious, the simple things start growing hair.

If you look at the CPAN test reports for Parrot, you’ll see that the pernicious and persistent problems relate to odd bits of not-quite-always-cross-platform math, specifically floating point numbers and not-a-numbers.

It’s reasonably easy to find and read the C89 and POSIX specifications. They’re well-published. Even if there are confusing parts and contradictions, you can look for them and find the specifications.

Now try to find current information about how various operating systems and the various compilers and major versions and minor versions and libc versions in all of those combinations interact. In short, if I want to figure out exactly what OpenBSD does in its C library in its standard configuration to return a negative floating point 0.0 (or not, as the case may be), where do I go, what do I read, who do I talk to, and — most importantly — how do I change the software I work on to deal with those platform-specific quirks such that the users of my software don’t even have to know that these quirks exist? Ditto GNU/Linux, Cygwin, FreeBSD, Mac OS X, et cetera.

I know that knowledge exists somewhere. Perl 5’s core encodes it somewhere. I suspect the same is true of Python and Emacs and Guile and Glib and kde-base or related projects. Yet the knowledge in code is only useful in two ways. First, in projects that use the code directly and only need to trust that it does the right thing. Second, if other people read the code.

There ought to be a third option: encapsulating that knowledge outside of code somewhere. Maybe this specific case is documented and I just can’t find it. The same goes for alignment concerns (64-bit Intel/AMD, PA-Risc, Sparc, ARM), pointer sizes, and other information.

Does this information exist in one or two good places, or does everyone have to track it down on his or her own? Worse, does everyone just hope these problems never come up?

Didn’t get one of the 10,000 golden tickets in special Google-brand chocolate bars? Python isn’t your favorite language? Not sure about hosting your code and data with the world’s largest ad broker? Never fear — Google’s not the only supercomputing grid in the world. It may not even be the largest.

Computerworld reports that the top botnets control over a million computers and can deliver over a hundred billion advertisements per day. MapReduce and AdWords have nothing on this.

Yes, the deployment platform is mostly Windows, and you don’t exactly have professional system administrators in charge of every whim and need of the machines, but you do have root access, and there’s little chance the box owners will suddenly yank your code and data if your business model conflicts with theirs. Google’s offering has a ways to go if it wants to compete.

Benjamin Otte’s Open Source will scale brings up an interesting point.

If currently 1% of the world uses GNOME and it suddenly were 100x as many, we’d be at 40 million bugs right now.

The persistent lie that increased usage guarantees hordes of available volunteers descending from heaven to wipe out all signs of resistence (accompanied by the appropriate Wagnerian soundtrack) is one of the most pernicious Myths Open Source Developers Tell Ourselves.

Though Benjamin finds hope in the fact that users tend not to report bugs (and distributions don’t work well enough with upstream), the entire scenario still bothers me. I don’t mind fixing an interesting segfault now and then, and I’m always happy to fix a well-reported bug with a test case and a sensible description which helps me reproduce the problem. Yet I don’t scale, especially for projects where I can devote only a few hours a week.

That’s not a few hours every week, either.

Bug reporting, bug triaging, and bug fixing are all activities present in healthy project communities. In return for the freedom of using great software (often at low or no cost) with no usage restrictions and few (if any) distribution restrictions, users have the responsibility of ensuring the community’s long-term health. That may mean submitting a bug report, testing a development version, posting a bug bounty, producing a patch, or even sponsoring a developer. Otherwise, you’re relying on the goodwill of volunteers who’ve already more than paid their obligations to you — and I’m concerned about the long-term sustainability of that model.

Sometimes I wonder of the dual-licensing model is actually healthier in some ways. At least there the costs are explicit and fungible.

I’m at a unique symposium this week named Codework, which I do not dare to describe because it has barely begun. I can only say that snagging Ted Nelson to deliver the opening talk was not only a great motivation for attendance but an exquisitely appropriate historical marker for the workshop, which bills itself as “Exploring relations between creative writing practices and software engineering.” Nelson, of course, is one of the first people to recognize the benefits literature and computing could offer each other.

Readers have plenty of ways to learn about Nelson’s famous Xanadu and his more recent project Zigzag, one of the best ways being to hear him speak as we did in a full hall last night. Thanks to the World Wide Web that Nelson perennially maligns, he is much more famous than he otherwise would be, and also has much more opportunity to spread his views. But here I’ll just jot down a few observations I haven’t seen others offer about Nelson’s ideas, and that aren’t immediately obvious from his talks, fascinating and well-argued as they are.

Adobe has released a beta of AIR for Linux. Good news, everyone with a 64-bit processor, or PPC, or Sparc, or ARM, or anything more exotic than 32-bit x86. AIR for Linux Release Notes say that all you need is:

Processor - Modern processor (800MHz or faster)

Finally, web applications have freed us from the tyranny of worrying about such difficult issues as endianness, alignment, and struct padding!

(Sorry “by the end of the day” turned into four days. I was in rural Pennsylvania with no Internet!)

In 2006 I was taking a look at the then unreleased XenSource XenServer 3.0. The server was running on a Dell laptop on a filing cabinet next to my desk where the XenServer management interface was open on my desktop. My wife walked into our office, looked over my shoulder, and while pointing to the monitor on my desk asked, “Is that the Xen thing you said you were going to be reviewing?” I responded that the laptop next to me was running Xen, and that she was just looking at the management software.

The fact of the matter is that to most people, the software that manages virtualization *is* virtualization — a fact that may save companies like VMware. See, the virtualization management interface is the most public facing component of the virtualization ecosystem, and two crucial parts of this ecosystem are quickly becoming commoditized: the hypervisor and the virtual machine (VM). The entire virtualization ecosystem is being redefined, and in a few years the companies that wish thrive in this market will need to focus on an entirely different set of technologies than they like to tout now.

This blog briefly discusses the commoditization of the different parts of the virtualization ecosystem and what areas companies like VMware will need to pay attention to in order to survive software giants like Microsoft and open source alternatives such as Xen and KVM.

I chuckled at a couple of quotes in Java performance improvements touted, specifically one from Cliff Click:

As your program grows in size, the lack of strong typing basically kills your ability to handle a very large program and so you don’t find the million-line Perl program.

I’ve met Cliff, and he’s very smart, but I have to disagree on two points. First, no one who’s used anything with a better static type system than Java consider’s Java type system “strong”. (If you can still get a NullPointerException from a generic-enhanced collection, Java has a ways to go.)

Second, the reason that there aren’t many million-line Perl programs is that the people who are capable of writing and managing million-line Perl programs have better ways to organize their projects than glomming a million lines of Java into a single shared-everything instance. That’s setting aside the qualities of encapsulation and abstraction that Java-the-language doesn’t have, preferring instead to push that problem to tool vendors and AbstractFactoryFactoryInjectors which consume vast swaths of XML to get around Java’s static code fetish. I can only imagine how much larger the Java code would be without all of those XML files.

I also recommend James Robertson’s take on things, from Earth to Sun.

I’m curious to hear how many million-line Java applications exist in the world and what they do. I suspect that they’re primarily web applications that speak SOAP or REST over strict SOA or HTTP boundaries — just the sort of boundaries beyond which it doesn’t matter if your code is Java, Perl, C++, or the Korn shell. You know, because they’re completely network bound.

Hello. My name is Andrew Kutz, and I am honored to be blogging for ONLamp on the topic of virtualization. Please watch this space for news on VMware, Xen, KVM, and other virtualization technologies. I’ll be creating my first real post later today. If you have any ideas with regards to what type of content you would like to see, please let me know by shooting me an email at akutz at lostcreations dot com.

Thought for the day: If the preferred scaling strategy of Java web applications is shared-everything in a beefy JVM with plenty of threads in myriad pools (and it seems to be) and the preferred scaling strategy of LAMP applications is a shared-nothing architecture across plenty of boxes with memcached in front of a replicated database, what changes will be necessary to run popular apps written with shared-nothing in mind in a shared-everything environment?

Bonus question: besides web applications and language research, are dynamic languages on the JVM interesting? (The clever reader will see where this line of thought leads.)

In my (painfully) long career as a software engineer, I’ve often run across the attitude that code has intrinsic value. You see this frequently in the industry when ‘code reuse’ is used as a metric of efficiency. At several companies I’ve worked at, old and badly bit-rotted products have not been rewritten because “we’ve invested umpty-umph million dollars in that code, we’re not just going to throw it away.” This whole attitude is bull-doodoo, and here’s why.

In amusing synchronicity, I was reviewing Bernard Golden’s Open Source Maturity Model earlier today. Then I read My Visit to Sun, where he describes a conversation he had with Simon Phipps before giving a talk at Sun.

In particular:

Many enterprises seeem to operate in a vendor-centric model: they select a vendor and from then on rely on the vendor to define when new technologies should be adopted, when new releases should be rolled out, even what complementary technologies should be implemented. It’s obvious that this causes middle-of-the-pack performance, lock-in, and lack of pricing power. Without rehashing all of those arguments, consider the other implication of this approach: it fosters dependence — an inability to self-direct in technology direction, custom architecture, and unique business offerings. If all you can offer is off the standard menu, you will never serve up differentiation.

When you give away software and trade license fees and pre-sales for support contracts and free downloads, you break the passive-adversarial model between vendor and customer that has served IT so poorly for the past two and a half decades.

That’s not a safe thing, nor an easy thing. That’s still a good thing.

Companies are constantly opening new veins of ore as they attempt to mine the Internet for useful information. Developers and open source system users will be particularly interested in a SourceLabs announcement of a service called Self-Support Suites that has been in beta since December. This tool combines enormous amounts of information indexed by SourceLabs from bug trackers, technical mailing lists, and other sites to help open source users diagnose problems. They’ve just put up a free download.

The proof of concept I heard from Byron Sebastian, CEO of SourceLabs, concerned a site that spent two weeks trying to track down the failure of an Apache Project module. SourceLabs’s system found a bug report with the fix in a few minutes by finding a match between a stack trace provided by the user and a stack trace provided by a question in a public forum message. This search was more difficult than it might sound, because stack traces don’t match precisely and their contents are not unique strings that are easy to search for. Sebastian says that stack traces and log files tend to have the most useful information–but if other information was organized better, it might rise in value.

Oh, joy. Adobe is at it again.

AIR applications are deployed as a single AIR file that works identically cross-platform. The api’s within AIR are identical across different operating systems so any application behavior will work the same regardless of where it is running. Regardless if you use HTML/AJAX or Flash/Flex to build your application the API’s are identical and run on MAC/WIN/LIN without issue.

Ted Patrick, Why Adobe AIR?

Given that Adobe’s evangelists have a very difficult time telling the truth about which platforms Adobe actually supports (particularly pernicious with regard to Flash; see Uh, Thanks for the “Linux” Support for one example), does anyone really think that AIR will run on anything more exotic than 32-bit x86 GNU/Linux? Set aside the fact that, as much as Ted’s quote may make you think that AIR runs on “Linux” right now, it sounds like no one outside of Adobe will see that binary blob until later this year.

When I think about cross-platform support, I think about the first time I sent e-mail on the Internet via a FidoNet gateway accessed through a PC bulletin board from my Commodore 128 over modem-to-modem dialup in the very early ’90s.

Again (I always have to disclaim this), Adobe has every right to support only the platforms and processors it wants to support. I have no problem with that.

As usual, I offer any Adobe evangelist, manager, or developer the chance to prove me wrong, publicly, by successfully installing a publicly released version of Adobe Flash on the GNU/Linux laptop sitting six feet behind me in my office. (Good luck; it has a PPC CPU.)

Just don’t tell me that you offer cross-platform support and then stick me in a ghetto because I’m using the wrong operating system and the wrong processor. I know what cross-platform support means — you can still browse the web on a Commodore 64 — and your walled garden isn’t it. For all its flaws (don’t get me started on the codec licensing nonsense), Moonlight has a better claim to cross-platform compatibility. For starters, it doesn’t lock you out if you happen to be using the wrong type of CPU.

(I thought one of the goals of high-level programming languages and frameworks and virtual machines was so that you don’t have to worry about the details of the lower levels. Of course, I thought one of the goals of web applications was independence of platform at the level of operating system and below. Shows what I know.)

Inkscape developer (and fellow PDXer) Bryce Harrington mused about fixing critical bugs in Inkscape 0.46 to be in The paradox of FOSS projects supporting Windows.

Unlike the philosophical argument described in The Dubious Benefits of Porting FOSS to Windows, Bryce makes a more concrete, more pragmatic argument. In particular, the ratio of potential contributors to users on non-free platforms is measurably smaller than the same ratio on free platforms.

I’ve noticed this problem in some of my own projects. There are plenty of users willing to try a piece of software that may or may not work well on a non-free platform, but when it comes time to debug and fix these problems, their motivation goes away.

I’m sympathetic; it’s not fun to try to build and debug software on Windows. I don’t use it. I don’t understand it. I’m not the person you want telling someone how to install any of the free compilers that somehow don’t come bundled with Windows, just so that someone might be able to produce an interesting backtrace.

I’m not sure there’s a good solution, at least without enfranchising users to become contributors — and that seems to require Free platforms.