URL Update

I’ve been doing a pretty bad job of updating this blog. Part of the reason is that I wanted to update the URL to move the blog to the root. I finally got around to doing that today. It’s not that painful, so I don’t know why I waited so long to do it.

In the meantime, I’ll start off by sharing an interesting WordPress trick that I picked up here. I’ve been trying to figure out a way to stop spambots from registering on this site and my many other WordPress sites. I may have finally figured out a way to do that. I just implemented it. We’ll see how well it works.

The trick is to add the following block of code to your .htaccess file in the root of your WordPress installation.

# BEGIN ANTISPAMBLOG REGISTRATION
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-signup.php*
RewriteCond %{HTTP_REFERER} !.galaxycow.com. [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://die-spammers.com/ [R=301,L]

Of course, you need to change “galaxycow.com” in the above code to reflect what your site is using.

We’ll see how well it works. Thanks to D’Arcy Norman for that neat trick.

Could a Bug be Deliberately Coded into an Open Source Project for Financial Gain?

For some bizarre reason, the thought at the top of my head last night at bedtime was… “I wonder if sometimes… open source developers deliberately code bugs or withhold fixes for financial gain?”

If you don’t follow what I mean, here’s where I was: often times, large corporations or benefactors will offer a code fix bounty or developmental funding for an open source project they have come to rely upon.  What if an open source developer were to deliberately code a bug into an open source project or withhold a fix so they might extract some financial support with this method?

I brought it up in #morphix to Gandalfar, one of my trusted open source advisors.  We debated it shortly and he brought up several good points.  While this may happen, the scheme is likely to fall apart quickly.  The community is the resolver of situations like this.  If the community finds a bug and offers a fix for the problem, then the developer will find themselves in a political combat situation.  They would likely try to stifle the fix with some ridiculous excuses and/or start to censor discussion of the subject over mailing lists or on forums.  Speculation could be raised about the issue and ultimately, people could start to fork the project elsewhere, unless the license of the project disallows that.  In the long run, the community would resolve the situation by simply offering a new solution.

So while it could theoretically be achieved for short-term gain, in the long run the community makes the approach unsustainable.

Why do I bring this up?  Well, I think we all know that closed source entities often engage in this practice.  I could point out several examples that I have absolute knowledge of this happening, but I don’t think I have to.  I’m not completely absolving open source from this either – look at what “official distributions” do in some situations… Red Hat Enterprise Linux or Novell (SUSE) for example.  But in those situations, if you didn’t want to pay to upgrade the operating system and still resolve your situation, we all know that with the right application of effort and skill you could overcome it.

All in all, this whole thought process ends up with a positive note about open source.  If it’s broken, you can fix it yourself or work with others to make it happen.  The community – that incredibly large, global groupthink – keeps it all honest.

Or, you can put all your money and eggs into a closed source basket and find out you’re getting screwed when it’s too late.

It’s all about choice, right?

Reblog this post [with Zemanta]

Quick Safari/Snow Leopard Tip

If you’re having stupid amounts of trouble with your plugins loading in Safari 4 on Snow Leopard, go to your Finder and open /Applications.  Right-click on the Safari app and choose “Get Info.”  On that screen, you’ll see a checkbox to run the app in 32-bit mode.

Check that.

Restart Safari if it’s open.

Now you’ll find that your plugins magically work.  I guess this whole 64-bit thing has caught developers with their pants down.  Not sure how that happened since they’ve only been talking 64-bit on the Mac and Windows side for years.

Reblog this post [with Zemanta]