Community has always played a central role in the Open Source landscape, and the term ‘community’ is bandied around almost as much as ‘Web 2.0′. Unfortunately, as with ‘Web 2.0′, the term ‘community’ has become a vague descriptor for a collection of principles that represent similar things. As more and more disparate groups and organisations make use of any definition, meaning tends to be blurred by the exceptions to the rule.

It is interesting when you look back over the years at how community has played a role in the business and home consumerisation of Linux and Open Source. Once upon a time when we all had beards and a collection of 40 Slackware floppies, community was really all we had. No-one in the ‘real world’ had an appreciation of free software and Open Source, and as such the community stuck together to foster its own culture and identity. A key catalyst behind this development were Linux User Groups - these informal gatherings presented an environment in which people could talk to each other about things that most other people either didn’t know about or didn’t care about. You could meet others with the same priorities, concerns, desires and ambitions as your own, and this was an exciting prospect.

These pockets of community were by no means unique to the Open Source world; music communities have largely been the same. When I first started listening to metal, it was also very much not the mainstream. You couldn’t just walk into a record shop and pick up albums by your favourite bands, there were few magazines, no TV shows and very few organised groups. Like LUGs, pockets of interest sprung up such as metal nights and one-off gigs, and unwritten community meeting grounds sprung up in towns and cities across the country. Just like the Open Source community, the metal world became better organised and community leaders set forth to run local events and help people to meet each other to share this common interest. With these leaders, and support/communication channels such as the Internet, local bands, music shops and band rehearsal studios, the community grew consistently. Like many such communities, the leaders had no formal training - their hunch got them through it.

The commercialisation of community

Around the millennium, a number of large organisations saw something profitable in Linux and Open Source. Although niche technical communities had largely been ignored by big business, the Linux and Open Source train just continued to steam on and on, and board rooms across the world were buzzing with interest about how this exciting technology could bring in good profit margins. As these organisations started to embrace Open Source and rolled out their product campaigns, the community side was either ignored or simply not prioritised. From a traditional business perspective you can understand why - although Open Source, and particularly Linux, provided some incredibly well written, compelling technology with excellent cost and distribution options, the community side could simply not be controlled. In the eyes of a business driven by the traditional software model, it made far better sense to push the community to the side and simply employ a team of people to move the software in the corporate direction, suitably emblazoning it with the word ‘enterprise’ along the way.

Large organisations are fundamentally built on this premise of control. If you don’t have control of your products, your teams and your customers, you cannot invest in the next line of technology to keep you relevant. As such, all large software companies pay great attention to the bottom line. If you can keep your costs down, maximise sales and keep your customers happy, you are onto a winner. Open Source was proving to be a high quality technology with an already established team of (unpaid) developers, and a reputation that was piquing the interest of customers who had heard of the cost and stability benefits. With some suitable branding, Open Source presented an ideal product opportunity, and we started seeing big names such as IBM, Novell, HP, Oracle and Corel rolling onto the bandwagon, many preaching their support of ‘openness’.

The mistake a number of companies, both large and small have made when approaching Open Source is that they lack an understanding of the people who drive the technology. One fundamental concept that I have been teaching as I have taken my On the Front Line: Convincing People the Inconvincible advocacy talk around the UK is that if you don’t understand people, you cannot expect to fully understand Open Source. The problem is that understanding people is really hard, and a skill not typically employed by business. Any kind of strategy and competitive assessment is usually product and financials orientated, normally taking into account development, financing and marketing capabilities. The psychology and social structure of a bunch of disparate programmers who are not on your payroll is a pill just too difficult to swallow, and one that is usually farmed to the bottom of the ‘lets do this’ pile.

All change

A few years ago this all changed when Ubuntu hit the scene. Funded by Mark Shuttleworth, a millionaire philanthropist with an impressive track record of contributing to and supporting charities, a number of notable Debian developers were employed by Shuttleworth for a then-unannounced project. This project was to become the Ubuntu distribution - a distribution founded upon a strong community structure, but with an economic model to make it a viable product for business.

Shuttleworth’s effort was interesting in that it approached the distribution model from the entirely opposite perspective. Instead of taking the Open Source software portfolio and lessening the community side in favour of a corporate product, Ubuntu was heavily pushing the community side with the plan on making it an economic asset later. To the cynical onlookers, Ubuntu was seen as an unsustainable millionaire’s plaything that would ultimately fail when the money run out. The traditional business world, and the Open Source business world kept an eye on this curious project to see how it fared.

Ubuntu has become a remarkably successful project, and one that has netted huge community support and increasing brand recognition. I am convinced that the reason for this success is that Shuttleworth placed an importance in understanding the community fabric behind Linux. He was well aware that the Debian project was a primary source of high quality engineering, policy and packaging, and he will have been aware that the contributors to Debian not only had an understanding of the technology, but a commitment to the ethics of Open Source; ethics that are very much a foundation of Ubuntu. Shuttleworth was also no-doubt aware that by employing the cream of the crop when it comes to Open Source development, he was employing people who would get excited about software, write quality code, blog about it and work insanely long hours.

Let’s get more open

With the explosion on interest around Ubuntu, the other distributors have responded suitably and we are now seeing more and more community-driven distributions. Although I cannot categorically state this for sure, I am positive that the huge success of Ubuntu has inspired the creation of OpenSuSE and Freespire, and the increasingly community-driven nature of Fedora. It is evident that with a strong community behind these distributions, they can indeed become better in terms of engineering and adoption. Fedora is a classic example of this - as it has become more and more community driven, the quality has grown further and further. It is now a very impressive distribution and one that has a comprehensive backbone of developers, documentation writers, translators and users.

From a corporate perspective, interestingly, the Ubuntu project is competing on slightly different terms to many of the others. If you take an organisation such as Novell, I get the impression that they have the brand but now want the community. Novell could sell ice to Eskimos on brand alone, but it seems like they are actively pursuing community adoption and support. Linspire are taking a seemingly similar approach with their recently announced Freespire distribution. The Ubuntu project are approaching it from a different tack however. With such a strong and vibrant community behind Ubuntu, I suspect the quest is now for brand recognition in business.

Which is easier to foster, brand or community? It is difficult to tell, but my bet is that brand is easier. Brand can be made more recognisable with the aid or PR, marketing and strong business and partner relationships. The science of brand is measurable and can be divided into boxes and spread out across your staff. The science of community however is far more difficult. Communities are delicate collections of people with varying opinions, experiences and prejudices (both positive and negative) on technologies and companies. Traditional uses of marketing and PR are entirely inappropriate for community relations, and it instead requires a deep understanding of community, people and a commitment to the principles that the community is ingrained in. If there is an attempt to subvert these principles, the relationship breaks down.

Advocating process

As an Open Source advocate, I am largely an advocate of process, and I advocate the use of software and policy that embodies that process. I am pleased to see the importance of community playing an increased role in the strategy of organisations. Over the years I have advocated to various vendors and distributors what I considered seemingly obvious concepts and methods of encouraging community adoption. What experience has taught me is that these concepts are not obvious, and translating them into processes that work within the constraints of an organisation are the bigger challenge. This becomes even more complex when you take into account the ego, ambitions and measurable outcomes involved in IT.

You know, I say this in a lot of my articles, but the Open Source world gets more and more interesting as time goes on. With companies like Canonical, Novell, Red Hat and Linspire making some wise decisions, this can only benefit the users of our software more and more. This is a good thing for users, and this increased userbase translates into customers when the ecomonic model fits correctly. Open Source is fundamentally social software, and understanding the social fabric behind it is proving to be an economically sound principle as well as an ethically sound principle. Who knows what is next?

So what do you think? Is the community becoming more important? Is this the right direction? Where will we go in the future? Scribe your thoughts below…

If you have a sourceforge account, and are on your way to becoming the best thing to happen to the web since Yahoo or Google, then I beg of you to put a call out for people who understand database design fundamentals.

Designing an interface with PHP is one thing. Designing an “application” is quite another, as it includes designing the architecture of the application, how the various components of the application will interact and communicate, and also how the data used by the application will be managed and stored. This last piece is a decidedly un-sexy part of application design, and is often also (and unfortunately) trivialized by developers.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Today’s task is to finish porting the nodetype and setting tests!

I interviewed Bernard Golden, CEO of Navica, the other day at the 2006 MySQL User’s Conference. Bernard is always worth listening to, and hopefully our audio interview will appear on Distributing the Future sometime soon.

I hope it’s fair to say that Bernard believes that the economic advantage of open source software is so compelling that companies cannot avoid it.

That’s curious, if you think about it. If it’s difficult to argue that not only do people distribute high-quality software for free and with generous redistribution policies, but that that software can be more worth using than proprietary software, there’s an assumption or belief mismatch somewhere.

As people who work in the IT industry, our jobs often require us to evaluate and use a variety of tools and technologies on a regular basis. I would guess that all of us have our favorites that we reach for when we’re given a new task to perform. I use Linux as my desktop OS, vim for nearly all of my text editing needs, Python for my general purpose programming language (scripting and otherwise), and SQLite and MySQL for a database. When I am given a task to accomplish, I reach for the old faithful, well-worn tools in my toolbox. It’s not just that I’m proficient with them and can get the job done fastest with them; I enjoy using them. Often, our choice of tools to use goes beyond reasons of comfort and productivity and can border on fanaticism. That’s an inclination that I try to avoid. I’ll outline some reasons why I avoid this mindset as I’m going along.

As we’re trudging along, doing our normal job, evaluating some new tool or technology, we occasionally stumble across something new and different that catches our attention. It has obvious benefits over anything that we’ve used before. We quickly develop some affinity for this fresh, new piece of tech. Often, we even begin to promote or evangelize this new technology. Then we use it for quite some time, become more familiar with it, learn new features and even some warts, and the affinity remains. At that point, our attachment to it and comfort using it can become the reason we keep using it and we can lose sight of what drew us to it in the first place, which was that it helped us do our job better. When that happens, we can become so technology and tool exclusive in our thinking that we can pass over opportunities to learn and use new technologies.

I’ve probably come pretty close to being that way with the Python language and *NIX operating systems. I’ve passed over job opportunities at least partially because they didn’t involve using Python and the OS wasn’t some UNIX variant. To be fair, the language and the OS weren’t the only considerations in those instances; perceived work environment and current job situation had quite a bit to do with it as well. Interestingly, in the position that I’ve been in for the past 4 or so months, I’m finding my time nearly equally split between FreeBSD and Windows, and Python and C#. And, honestly, I’m not minding the shift as badly as part of me feared.

I had a couple of realizations that keep me positive about this job shift and interested in trying and using other new technologies. My first realization was that doing the job is not about using a tool; it’s about me. Yes, that sounds gratuitously self-centered and arrogant. But it’s true. The tool is just an instrument in my hands. I get paid, not for the tool that I use, but for how I use it and what I can do with it. The first reason that I try to avoid the technology-exclusive mindset I mentioned above is that it can keep me from exploring areas of myself that I might not have discovered otherwise. Note, I said might. You can stay on top of your game using the same tools and techology, but it’s easy to just cruise along and not give new thought to what you are doing or how you are doing it. At that point, you can become reliant on some tool and less so on yourself. My second realization is an extension of the first; with any tool or technology that we use, there are opportunities to come up with creative solutions. The hacker spirit within all of us has a drive to figure things out and creatively solve problems. Even with Windows and C#, I have to exercise that hacker within me every day. The second reason I try to avoid the technology-exclusive mindset mentioned above is that it can keep me from exploring alternative solutions that I might not have explored otherwise. This sounds really similar to the first reason. The difference is that the first deals more with who you are and the second deals more with what you do. Again, note that I said can.

So, what’s the point of this post? First, it’s to encourage diverse use of technology. There is no reason to be afraid to try new technology. So what if you actually like it and it finds its way to becoming a new favorite? Your old tool is just a tool, not a person. Next, I wanted to emphasize that your usage of technology is about you, not the technology. Your choice of which technology to use says more about you than it does the technology. You should feel good about the job you do regardless of the tool you do it with. Your accomplishment is yours. (Granted, the tool creator had something to do with it, but you were the effective means of accomplishing the task). The final point of this post is to encourage acceptance of diverse technologies in others. Yes, those Perl people are freaky (::grin::), but the hacker spirit within them is the same one that is in you. And it’s that which we should be looking to embrace. So, while I have favorites, I don’t want to “pledge allegiance” to any of them. I’ll keep trying new tech, embrace what I like and discard what doesn’t work as well. And I believe that I’ll be better for it.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Today’s task is starting to port a child node to Test::Class. Hooray!

In a post to the Perl 5 Porters mailing list, Nicholas Clark (maintainer of the stable version of Perl 5.8) talks about how he feels as if he is running hard to stand still. There are a lot of good changes going into the development version of Perl (what will be 5.10), but making sure that those changes are suitable for the stable version — as well as keeping new core dual-lived modules up to date.

No one maintains Perl full-time and very few people hack on Perl as paid contributors. Is this the case for other languages?

(It’s unfortunate that there’s so little publicity about the new features and day-to-day development of Perl. LWN.net does a great job of describing Linux kernel development every week. I sometimes wonder if a regular developer-level overview of new features, bugfixes, and such would be valuable. If so, I can probably devote resources to it. The same goes for other languages we cover on ONLamp.com….)

Frozen Bubble is a recreation of an ancient DOS game, played so many times by Guillaume Cottenceau who could use it in his favorite Linux box … so inspired by it he took the challenge and the tools at hand. And guess what : one of these tools is Perl !!!

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Today’s task is finishing the port of the parent node to Test::Class. Hooray!

GoDaddy.com announced they were donating $10K to fund OpenSSH development as they use it as a core part of their infrastructure (more).

All the linux resellers, who sell the features of openssh said no to supporting the project.

Sun, who base SunSSH on OpenSSH, refuse to donate. Why? Because OpenSSH competes with SunSSH! Details

IBM, who sell OpenSSH support as part of multi-million dollar support contracts, tell the customers to email the OpenSSH developer list to get the free support they pay IBM for (details).

The users of OpenSSH are willing to support the project, but not the people making money out of it.

When Sun and IBM say they’re interested in OpenSource, are they interested in anything beyond profits? Maybe their actions will speak louder their silent shame.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Today’s task is still more work porting the node tests to Test::Class. When will it all end?

After years of discussion and legal work, TPF has released drafts of the new proposed Artistic License v 2.0 and the Perl Contributors Agreement.

The reason for the new licence is to clear up potential ambiguities and contradictions in the first version of the Artistic License while retaining Larry’s original goals for the license. (Use the code as you wish, but don’t prevent people from using the official Perl in addition to or instead of modified versions.) It should be easier to use AL2-licensed code with code under other OSI-approved licenses. Additionally, there is language related to the use and enforcement of patents.

The reason for the contributor agreement is legal indemnification for distributing the code and holding a compilation copyright on the entirety of the Perl and Parrot and Perl 6 distributions. It’s important for TPF to know where code comes from and that contributors have the right to give TPF the right to redistribute the code that they write. It’s just good sense.

TPF-president emeritus Allison Randal worked on these projects for three years. Along with the Perl trademark, these documents may be her biggest legacy — and they’re excellent next steps in the continuing reinvention of Perl and the Perl community.

use Perl; has further discussion at Artistic License 2.0 public review. You can review the documents themselves at TPF’s legal section.

The BDFL just posted that Google is looking for students from undergrad through Ph.D levels to work on new open source code and mentors to, well, mentor these students. Obviously, since Guido is posting this, the particular students and mentors he’s trying to draw are Pythonically inclined. This is a great opportunity to get involved in some Python related project. The Python Summer of Code Wiki is here and the Google Summer of Code page is here.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Today’s task is, yet again, continuing to port tests from the procedural form to the Test::Class form.

In the first chapter of the Badger book we used form letters as an example of how (and why) you might use templates. We built a simple mail template containing a few variables and showed how you would process that using tpage to expand the variables and create a letter. It’s an obvious example to choose. I’ve used it in introductory Template Toolkit talks for years. We finished that example by saying

Process the same template a few thousand times with different sets of data and you have the entire basis of the junk-mail industry

Those words have come back to haunt me recently as my spam folder has been overrun with messages containing headers like this:

From: [% from_name %]
To: [% to_name %]
Subject: [% subject %]

The unexpanded tags indicate that even if spammers are using better tools, many of them still aren’t intelligent enough to use them properly.

But I’m very sorry if whoever wrote this TT-based spamming tool got the idea after reading our book.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Today’s task is continuing to port tests from the procedural form to the Test::Class form.

Related link: http://www.tomshardware.com/2006/04/07/going_the_sas_storage_way/index.html

Great article explaining SAS (Serial Attached SCSI) here: http://www.tomshardware.com/2006/04/07/going_the_sas_storage_way/index.html

Don’t do the usual Tom’s Hardware thing where to click straight to the benchmarks and conclusion.

In this article, the first few pages are a great introduction to SAS and included some history about SATA and SCSI that I never knew as well.

Bookmark for when you have some quiet-time to read.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

At O’Reilly, one of our goals is to identify important and interesting new technologies and uses of technology. I like to think we’ve succeeded in some ways (Ruby on Rails, Web 2.0, syndication and feeds). Always looking in new areas while trying to give existing areas the attention they deserve can be difficult, though.

The Perl Journal, started by Jon Orwant, then going through a couple different owners and forms, has stopped publishing. It’s last contribution, and article by me, was in January 2006.

TPJ was a big part of the early Perl community, and I’ll miss it.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Several weeks ago there was a notable bit of controversy over some comments made by James Gosling, father of the Java programming language. He has since addressed the flame war that erupted, but the whole ordeal got me thinking seriously about PHP and its scalability and performance abilities compared to Java. I knew that several hugely popular Web 2.0 applications were written in scripting languages like PHP, so I contacted Owen Byrne - Senior Software Engineer at digg.com to learn how he addressed any problems they encountered during their meteoric growth. This article addresses the all-to-common false assumptions about the cost of scalability and performance in PHP applications.

My on-again-off-again problem with suspend to RAM on my laptop is now on-again. I’ve been getting really tired of shutting down my laptop to transport it between work and home, as well as just keeping it running all the time. I decided today to dig in just a little bit and see if I could figure out what was causing my laptop from properly suspending, or more to the point, resuming properly from suspend.

Here’s a little background for anyone who doesn’t know my story. I purchased a Dell Inspiron 9300 less than a year ago and installed Ubuntu on it. At various times, I’ve had most everything working well. When I recently upgraded to Dapper, suspend to ram broke. It seems to suspend fine, but when it comes out of suspend, I was getting a nasty orange or purple noisy screen. Today, I stumpled across an acpi howto that mentioned trying to turn off optional devices. I decided to try to shut off my wireless cart (Fn-F2) and see if that would help. Surprisingly, it did. I then decided to leave the wireless up and put “rmmod ipw2200″ in my suspend script. That worked, too! So, my wireless card has been the guilty party in keeping suspend from working. Now that I know what the problem was, I can live with this as a solution.

The good news: the transition to online sales of music is going faster than I and many others anticipated. The bad news: musicians are making less money.

CD sales continure to decline year over year: in 2005 retail sales were down another 8 percent, according to the Recording Industry Association of America (RIAA), following an anomalous uptick in ‘04. And the global music market saw an overall decline of 3 percent, according to a report by the International Federation of the Phonographic Industry (IFPI). But legal online sales are rising fast. The IFPI report says record company online revenues tripled last year, and now account for 6 percent of the global take. The IFPI believes legal downloads are now holding their own against free file-sharing. Half of the money comes from the mobile market for ringtones, full track downloads and the like.

I’ll be the first to tell you: AJAX does NOT substantially change the typical web application security audit methodology. However, if you are a developer or a security professional, there are a few issues to consider and watch out for. The following is a list of thoughts I created for my own use, but I’d like to share it with you. Note that it is draft, and a work in progress.

1) Cross Domain XMLHttpRequests: Browser security does not allow you to invoke XMLHttpRequest on a resource outside the current domain. This prevents a rogue web application, or an application vulnerable to XSS/JavaScript injection, from making a user’s browser invoke XMLHttpRequests to an application outside the current domain.

A rogue application, or an application vulnerable to script injection on the same domain (vulnerable.example.com) may cause users visiting that website to invoke XMLHttpRequests to another application on the same domain (www.example.com).

Case study: Myspace worm. However, these attacks are NOT new to AJAX. It has always been possible to request resources outside the current domain via a simple <IMG SRC="http://example.com/cgi-bin/ouch.cgi?a=b">, and JavaScript code for a while now.

2) Developer Mind-set: One of the main advantages of implementing AJAX is to let the browser do as much work as possible, without enforcing a complete round-trip (re-rendering the entire page.) Unfortunately, many developers take this mentality a bit too far and design their applications such that the browser is trusted to perform input validation, output encoding, and access control checks. This gives rise to attacks we have already seen in the past: SQL injection (input validation), Cross-Site Scripting (output encoding), and improper access control. That said, AJAX in itself does not introduce these vulnerabilities – poorly web applications have been susceptible to these problems long before AJAX.

3) JavaScript Obfuscation: Commercial application vendors regard their source code as their intellectual property, and are likely to want to obfuscate client side code to protect it. AJAX implementations introduce a large amount of client side code so we are likely see a lot of commercial applications implement JavaScript obfuscation. This may be an understandable approach from a legal perspective, but it breaks apart when the intention is to obfuscate security controls. I have come across instances where JavaScript code has been obfuscated to protect home-grown crypto algorithms from being deciphered. It is always easy to reverse-engineer such applications – sometimes it is as simple as using a web application proxy such as Burp to monitor GET and POST requests.

4) Denial of Service: Yes, it is possible for a rogue or vulnerable application to force a user to launch multiple XMLHttpRequests to a target application, but this has been possible before AJAX. Infact, browser domain restrictions make XMLHttpRequests useless in launching such attacks on other domains. Simple tricks like using <IMG SRC="http://example.com/cgi-bin/ouch.cgi?a=b"> nested within a JavaScript loop can do the trick more effectively. If anything, I predict poorly thought out infrastructure and application design is likely to cause AJAX applications to inadvertently DOS themselves due to too frequent XMLHttpRequests.

These are my thoughts so far. I welcome your comments.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Apple’s Bootcamp and latest Firmware update allow you to dual-boot intel Macs. This is welcome news for many who must use Windows software for work (or play games.) I haven’t bothered dual-booting my Macbook Pro because I prefer OS-X, and I didn’t pay premium for Apple hardware only to run Windows XP on it. I don’t want to have to close all my OS-X applications and reboot to Windows when I need to test applications for work. I’ve tried Q, but unfortunately, it’s still quite buggy and only does emulation (virtualization is in the works.) This situation has caused me have to travel with 2 laptops which isn’t a whole lot of fun to do.

Yesterday, Parallels released a Beta version of their virtual machine workstation software for the Mac. I just installed Windows XP on it, and it is FAST (it takes advantage of Intel Virtualization Technology found on the dual core processors.) If you own an intel Mac and are looking to run Windows (or any other OS) in a virtual environment, do consider trying Parallel’s Workstation for the Mac. Remember, its still beta, and currently has the following shortcomings:

- Network: Bridged mode only
- No audio support
- No USB support
- Still buggy (crashed OS-X for me. I have since set “Acceleration” to “Normal” and turned off en0 after reading suggestions on their forums, and things have been quite stable for me so far)
- No file sharing support
- Host cannot connect to guest
- Parallels Image Tool has not been ported to OS-X

Note that the above problems are currently being worked on, and Parallels is promising to fix most of them by their next beta release. In spite of the above shortcomings, this is an impressive piece of software. Not having to travel with 2 laptops has certainly made life easier for me.

From the mailbag, fellow PDX.pm hacker Eric Wilhelm has a vision of creating a publicly-readable Subversion repository consisting of all of the modules on the CPAN. Though TPF declined to fund his work, he’s put up his current version at svn4cpan along with some notes on what could happen. If you’re looking for a project, here’s one that could have amazing benefits.

Python 3000 has been a joke for so long now that it’s funny to consider that it will eventually materialize into something real. Guido just posted some thoughts on very real implementation details for Python 3000. The topic at hand was adaptation. Basically, Guido has killed PEPS 245 and 246 which are interfaces and adaptation respectively, and has posited the use of generic functions as an alternative approach.

I’m curious to see how Guido and the other Python big-brains envision everyday use of any kind of protocol-based approach for type management (or whatever you want to term the topic at hand). From one of Alex Martelli’s posts, I can see how protocols could be really cool for library, specifically the standard library, developers. You create a library funtion, state that it can handle this protocol of thing, and it (not-so-)magically just does the right thing with various types that are passed in. For example, you can create a function that really expects a file-like object, create a protocol that adapts a string to a StringIO object, and now it can handle a file or a string. At least that’s how I understand things so far.

As I’ve been watching the discussion around protocols, I’ve assumed that this was going to be Python’s way of gently (and optionally) enforcing type “safety” or requiring function/method call arguments to be of certain types, but it appears to be much more than that. I really like the idea. I’d just like to see more day-to-day use cases rather than just the theoretical discussions that I’ve read thus far. From PEP 246, there is a question “What benefit does this proposal provide?”, to which the answer begins “[t]he typical Python programmer is an integrator” and seems to sound like protocols will just “make stuff work” if a sensible type of object is passed into a function or method. So, maybe that’s the “common, everyday use case” that I was looking for. Maybe it just makes stuff work easier and integrate better. How protocols and adaptation fit into my original “type safety” thoughts is becoming less clear. I was really hoping Python would incorporate optional type checking at some point. Maybe this protocol approach can provide a foundation for type checking. Or maybe that’s an entirely different discussion.

Today at LinuxWorld Boston, the Open Source Technology Group announced the winners of their first ever SourceForge.net® Community Choice Awards. With nearly 1.3 million registered users, and almost 117,000 projects, SourceForge.net is the world’s largest collaboration site enabling IT strategy through Open Source. For SourceForge.net, these awards are consistent with keeping with SourceForge.net’s mission to foster the Open Source movement and community. According to Jay Seirmarco, general manager of SourceForge.net: “offering an annual opportunity to highlight top achievements in Open Source software development is one avenue for us to demonstrate our commitment.” By allowing the worldwide technology community to voice their support and appreciation for projects on the site, they foster the creation of, participation in and evaluation of Open Source software worldwide.

This 30-day project explores the refactoring of a legacy system. The Everything Engine is an aging software project that powers Perl Monks, Everything 2, and a few other websites. It suffers from poor design and maintainiability. Learn what it’s like to look over the shoulder of an experienced developer as he refactors, redesigns, and updates the code.

Nicholas Clark is the pumpking for the stable branch of Perl. In the past few years, he’s released Perl versions 5.8.2 through 5.8.8. He was also the pumpking for Ponie until recently. He recently answered @questions[0 .. 10].