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]

Backing up Snow Leopard Server with mlbackups

Apple‘s Snow Leopard Server product is one lovely implementation of UNIX.  I’ve thoroughly enjoyed using it for the power and simplicity that it offers.  I’ve loved using Apple’s operating systems thanks to the combination of UNIX power and elegant design.  Snow Leopard server is no exception to this rule.

The barrier to entry with Snow Leopard server was lowered when Apple reduced the price of the product to $499 USD and offered an unlimited client version only.  It was even more palatable when the Mac Mini server version was introduced at $999.  Previously, you could build your own Mac Mini server for about $1300 USD, but this new model allows small developers and workshops to get into the product at a very low price point.

With that in mind, I’m anticipating that there’s a number of people that are checking out Snow Leopard server for the first time.  You might be enthralled with all of its features and niceties.  One of those niceties includes Time Machine.  However, when you look at what Time Machine really backs up, you’ll discover that it doesn’t back up any elements of your server data.

That’s right.  Snow Leopard server is not backing up your mail data, Open Directory data or anything else of that nature.  It’s backing up enough to restore the server to an operational state, but you’ll find yourself rebuilding the Open Directory and mail data from scratch.  The Apple documentation states that they offer a number of other command-line utilities for backing up server data.  These utilities are a number of powerful little guys like “ditto” and “rsync.”  For the uninitiated, this means you’re now plunging into the world of search to discover a backup script that will save your hindquarters.

When I was researching this, I came across SuperDuper! and Carbon Copy Cloner most often.  While these serve the purpose of making a bootable clone of your server drive, the developers recommend that you do not use their products against Snow Leopard server while the services are running.  So, guess what?  Now you’re back to looking into a script to stop all of your services, back up the data, then start them back up again.

One side note here: it’s dreadfully easy to stop services with a terminal command or bash script, but I’m not going to go over that here.  If interested in this information, let me know and I’ll post it in another article.

After more searching, I came upon a little resource at http://maclemon.at – a site where a fellow has created the backup script “mlbackup.”  The site is mainly in German, so it’s not entirely clear what to do with the program.  However, it seemed to fit the bill for what I wanted so I decided to check it out.

mlbackup is provided as an installation package.  After downloading it, double-click on the pkg to install it.  Installation is pretty straightforward but implementation is a different story.

After installing mlbackup, it’s important to know what was placed on your system:

/usr/local/maclemon/* – the binaries for mlbackup and man pages
/etc/maclemon/backup/* – sample configuration file and globalexclusions

Start by copying the sample configuration file to a new file for modification.  In my case, I created a backup configuration file that is named after the volume that contains the data for my server.  My server’s name is “Ramona” and the server data is stored on a volume named “RA Server Data.”  Therefore, I did:

sudo cp demo.mlbackupconf.sample ramona_serverdata.mlbackupconf

This creates a copy of demo.mlbackupconf.sample and names it “ramona_serverdata.mlbackupconf.”  Next, you’ll want to edit that new file and make the necessary changes for your server.

I use “vim” to edit, so I type next:

sudo vim ramona_serverdata.mlbackupconf

Using “vim” is an article in and of itself, so I’m certainly not going to cover its usage here.  If you’re an innocent  newcomer to vim, it can quickly turn you into an innocent bystander of a violent gunfight.  Be careful.

Once you’re in vim, hit “i” for insert mode and make the necessary changes to the file.  Notably, you’ll want to change some of the items listed below.  I’m pasting in the contents of my file and the changes that I made.

# What is the name of this backup set?
MLbackupName=”Ramona_Server_Data”
# What is the name of this backup set?
MLbackupName="Ramona_Server_Data"
...

# What file or directory to Backup. (No trailing Slash for directories)
# Default: $HOME
MLsourcePath="/Volumes/RA Server Data"

...

# Where shall the Backups be stored (local path on the destination machine)
# Default: /Volumes/Backup
MLdestPath="/Volumes/Ramona Backup/mlbackups"

...

# Where to send the eMail notification about the backup to?
# Default: $USER
MLadminEmail="<my email address>"

Hit “esc” to get out of insert mode.  Then hit “:” and type “wq” and enter.  This will save the file.

In case you haven’t deduced it from examining the file, I have two external drives hooked up to this Mac Mini server.  One is a firewire800 drive called “RA Server Data.”  The other is a larger drive on USB called “Ramona Backup.”  My intention is for mlbackup to execute against RA Server Data and back it all up to Ramona Backup.  I intend for it to keep 5 sets of backups.  mlbackup is pretty nice in that it will automatically clean up the prior backup sets so it only keeps the amount of sets you want.  If you’re running this every day, you’ll have 5 days of backups.

One other note here.  There’s a bug in the mlbackup script that if the “MLbackupname” parameter contains a space in the name, mlbackup won’t clean up the old backup sets automatically.  Found this one out the hard way.  If you intend to have a backup set name that contained spaces, replace the spaces with an underscore character to prevent this issue from biting you.

The first half of your mlbackup configuration is complete.  You’ve told mlbackup what to do, but now you need to tell it when to do it.  The old way of setting up scheduled tasks in OS X was to use a cron job, just like a regular UNIX or Linux implementation.  However, Apple has replaced cron with launchd.  Now you need to configure launchd.

Launchd is a complex beast.  I’ll summarize what I learned about it.  Launchd will fire up any tasks on your behalf at any time you define, much like cron used to do.  It uses an XML file to define the job and depending on the parameters in the XML file and where you put it, launchd will do different things.

Since it’s so complex, I’m only going to talk about what I did for this launchd task.  Your ideas and mileage may vary.  I’m interested in hearing what others do with this, so be sure to let me know what you put together.

In my case, I created a new file in /Library/LaunchDaemons.  I put it there because I want mlbackup to be executed as root (spare me the speeches, I’m trying to back up server data here) and I want it to have access to the system.

Here’s the contents of the file I created there in /Library/LaunchDaemons.  The name of the file is at.maclemon.mlbackup.radata.daily.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<dict>
  <key>Label</key>
        <string>at.maclemon.mlbackup.radata.daily</string>
  <key>ServiceDescription</key>
        <string>Back up the disk RA Server Data every day.</string>
  <key>LowPriorityIO</key>
  	<true/>
  <key>ProgramArguments</key>
  <array>
	<string>/usr/local/bin/mlbackup</string>  
	<string>/private/etc/maclemon/backup/ramona_serverdata.mlbackupconf</string>
  </array>
  <key>Debug</key>
  	<true/>
  <key>StartCalendarInterval</key>
  <array>
  	<dict>
    		<key>Hour</key>
    		<integer>4</integer>
    		<key>Minute</key>
    		<integer>0</integer>
  	</dict>
  </array>
  <key>AbandonProcessGroup</key>
	<true/>
</dict>
</plist>

Again I’m not going to go into a whole lot of detail here about what I did, but I will point out a few items of interest.

Note the “ProgramArguments” directive.  There, you see that I’m calling mlbackup and giving it the full path of the config file I created earlier.  This is vitally important, otherwise mlbackup won’t do a thing.

The “StartCalendarInterval” element tells launchd when to start the task.

The “AbandonProcessGroup” item is required if you intend mlbackup to send you email at the completion of the job.  Without this element, mlbackup won’t send an email and may not clean up the backup sets in a way that you intend.

Finally, tell launchd that you created the file and you want the system to load it up and pay attention:

sudo launchctl load -w at.maclemon.mlbackup.radata.daily.plist

Launchctl is the terminal command to force launchd to load up the file.  For some odd reason, without the -w, it won’t load.  Why you have to do this is unclear in the Apple documentation for Snow Leopard.  In the past, -w controlled whether the job was enabled or disabled.  In Snow Leopard it seems, without using -w, launchctl just looks at you funny.

That should do it.  You should receive an email from the root user at the end of the backup task if all goes well.  If you didn’t receive an email, be sure to check your backup volume and verify that something was written there by mlbackup.

One other note that I forgot to include.  mlbackup is mainly just a bash script, but it does contain a newer version of rsync.  mlbackup uses this version of rsync over the one that Apple supplied with OS X because it has some vital optimizations for the backup to take place.

That should do it.  Hope this helps get your server backups running well.

Reblog this post [with Zemanta]

Industy buzzword that needs to die: the “experience”

RENTON, WA - MAY 4: (FILES)  Microsoft product...
Image by Getty Images via Daylife

One of the industry buzzwords that needs to go to the grave is the user “experience.”

Don’t quote me here, but I recall this buzzword being developed by Microsoft as part of the marketing campaign behind Windows XP.  XP was supposed to be “experience” or “expert” or “Xtra stuPid marketing,” I’m not sure.  Don’t get me wrong, I’m not an XP hater.  But I’m definitely a hater of the term “experience.”

The user interface is just that, an interface.  The term “experience” has its roots in the passive voice.  Somewhere in there you’ll find that the user “experience” for computing generally sucks.  It’s just a nicer way of saying “our user interface sucks, but it provides an experience.”

Whatever.  Drop it.  Look, other computing companies are just as guilty on this one (I’m looking at you RIM and Apple), but the fact is – everything great on the Internet is ruined by salespeople and marketers, period.

This is just one example of many.

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]

Wallpaper Outrage

Image representing Microsoft as depicted in Cr...
Image via CrunchBase

Paul Thurrott posted a nice attaboy to the MSN folks today for releasing a wallpaper product that will check Microsoft for updates to your operating system.

Get ready folks, I’m about to show my ass again.

Are you KIDDING ME?  Paul Thurrott has obviously never had to manage a network beyond his own house.  Microsoft commonly releases updates through Windows Update and if you’re a Windows admin worth your salt, you’ll know that it’s wise to wait on many of these updates until you’re sure they’re not going to fry your systems.  Indeed, many enterprises flat out block Windows Update and only deploy them when they’re ready to support any mishaps.

Any of you who think Microsoft cannot commit mishaps in an operating system update is just a fracking idiot.  Period.  Don’t even bother talking to me.

So now these MSN goons have released software that lets you bypass your enterprise security measures on Windows Update?  THANKS ASSHOLES.  If you’re running an enterprise network, please take a look at this software package that your users are RUSHING OUT THERE TO DOWNLOAD before they gank up your network.

This is basically WALLPAPER that can update your OS?  Great.  Another background app.  Another systray app.  Another useless waste of time and resources from a company that should be spending its time fixing Exchange 2007 instead of releasing useless garbage that grants enterprise users free license to bypass their IT department.

THANKS AGAIN, MICROSOFT!

You have so jumped the shark.

Reblog this post [with Zemanta]