Mark W. Shead

After reading a some comments in a blog post about how DMOZ really needs more good editors, I thought I’d give it a try. I noticed that the Personal Organization category didn’t have an editor so I pushed the button to apply to be an editor. I filled out the form carefully and spent a good amount of time trying to find the sample sites that I would add to that category.

After spending a good amount of time filling everything out, I submitted the application. Later on in the day I received this response:

Dear Mark Shead,

Thank you for your interest in becoming an Open Directory Project editor!
Although we would like you to join us as a volunteer editor, you have
chosen a category that is already well represented, or is broader than
we typically assign to a new editor. We would encourage you to re-apply
for a category that has fewer editors or is smaller in scope, in order
to increase your chances of being accepted.

Feel free to reapply by submitting an application in another area.
If you wish to re-apply, you must fill out another application.
Please do not reply to this email.

Regards,
The Open Directory Project

Additional reviewer comments:

Now I understand if they only want you to be an editor of a small category at first. When I signed up, I tried to use a sub category, but the only subcategory was for consultants, and I wasn’t really interested in doing that.

If they really don’t want people to apply for these categories, they shouldn’t put links to sign up as an editor at the bottom. If they had of had a suggestion of a different category to try that would at least show that there was some level of thought on their side of things. Just saying “keep applying and maybe we’ll eventually let you in” seems like it has a good chance of just wasting my time.

If you want good editors, you need to make sure you aren’t wasting their time. Good editors are more likely to be busy individuals who want to contribute to the community. Bad editors are more likely to be people who will just keep applying over and over again until someone eventually lets them in as an editor.

Maybe I’ll try signing up as an editor again someday if I find a category that I’m interested in, but at this point I think DMOZ may be shooting themselves in the foot by asking for people to sign up as editors for a category and then telling them “no you can’t edit this category”.

If you are trying to use Rome and Rome Feed Fetcher, the following will not change the default user agent:

FeedFetcher feedFetcher = new HttpURLFeedFetcher();
feedFetcher.setUserAgent(\"User Agent 007\");
SyndFeed feed = null;
feedURL = new URL(rssUrl);
feed = feedFetcher.retrieveFeed(feedURL);
List entries = feed.getEntries();

To change the user agent you must use the InfoCache as shown:

FeedFetcherCache feedInfoCache = HashMapFeedInfoCache.getInstance();
FeedFetcher feedFetcher = new HttpURLFeedFetcher(feedInfoCache);
feedFetcher.setUserAgent(\"User Agent 007\");
SyndFeed feed = null;
feedURL = new URL(rssUrl);
feed = feedFetcher.retrieveFeed(feedURL);
List entries = feed.getEntries();

Otherwise the User agent is set to “Java/1.5.0_04″. This is odd because the default client for Rome is “Rome Client (http://tinyurl.com/64t5n) Ver: 0.7″. It seems like an attempt to change the user agent without having a HashMapFeedInfoCache will result in changing the user agent, but somehow it reverts to “Java/1.5.0_04″ instead of whatever you set it to.

To invent, you need a good imagination and a pile of junk.

— Thomas Edison

This is what is so facinating about programming. Your “pile of junk” consists of digital assest instead of physical matterial, so the raw materials are not limited by the normal laws of supply and demand. In software, you are limited only by your imagination.

Yahoo and Google are trying to one up each other on whose database contains more pages. Does it really matter? Isn’t relevancy more important? It depends on who your user is.

If most of your queries on search engines return hundreds or thousands of results, then it probably doesn’t matter who has the biggest index. As long as Google and Yahoo get the popular pages, you’ll most likely find what you are looking for. If you get a bunch of results from your search you are probably aren’t looking for a specific document on the web, so it doesn’t matter which page you get as long as it has the information you are after.

Most internet users fall in the above category. I tend to find that many of my searches return less than 20 results and sometimes only 2 or 3 or even 0. For people like me the number of pages searched is much more important. In fact for those types of searches the method used to order the results (determine the relevancy) isn’t really important. With a small number of pages, it is easy to scan through the list and find the most relevant entry.

Today I was working on a piece of equipment and it started giving me a less than helpful error message. I typed the manufacturer (in quotes) and the error message (also in quotes) into Google hoping to find out how to fix my problem. There were zero results. I tried it on Yahoo and got the same thing. After poking around in some forums I was able to find a post that described the problem on a page that was missing from both Yahoo and Google’s databases. The post contained all the phrases that I had searched for it just wasn’t in either of the search engine’s indexes.

Five years ago I taught a community college class about the internet. I used Geocities to put up the tests, class outline, etc. Today I tried search for:
site:geocities "juco internet class"
In Google I get zero results. With Yahoo I get a single result that links to the page I was searching for.

I’m sure that there are other items that I could find with Google that won’t show up in Yahoo. I’m not trying to say one engine is better than the other. The point is that the index size does matter if you are looking for a specific document. If Yahoo decides that they are going to maintain a larger index than Google, then there are going to be pages that can be found in the Yahoo index, but not in Google’s. If you are looking for one of these pages then size is very important.

Subversion is great, but like any data repository, it must be backed up regularly. Many people have tried to implement version control without really understanding how it works, only to later discover that their backup strategy wasn’t working.

The backup script I use is run every night as part of a cron job. Each morning I get an email telling me if everything went ok or not. Here is a list of what I want to happen with each backup:

1. Dump all the data out of the repository
2. Name the file with a timedate stamp in the filename. Something like YYYYMMDD-HHMM will work.
3. gzip the file to save space
4. Move a copy of the file to another server using scp

Seems pretty basic, but when I’m doing a backup by hand, I like to go a step further and verify the backup by creating a new repository, filling it with the backed up data and then checking it out. This lets me verify that my backup works and that I can get my code back if necessary. So for this verification stage I want to do the following:

1. Pull the zipped file back down from the remote server
2. Unzip it.
3. Create a new repository
4. Load all of my content into the new repository
5. Checkout a copy of trunk into a directory
6. Cleanup

The following perl script accomplishes everything I need. When it is run with cron, I get a short email everyday telling me that it completed. The output is intentionally terse. If I get a long email I know something went wrong, but I don’t have to wade through a bunch of logging information if everything went as planned. If you want more output, take the -q off of the Subversion commands. The emails that cron sends me look like this if nothing went wrong:

Dumping Subversion repo /var/svn to my_backup-20050921-0100...
Backing up through revision 340...
	
Compressing dump file...
	
Created /home/admin/backups/my_backup-20050921-0100.gz
	
my_backup-20050921-0100.gz transfered to my.server.com
	
---------------------------------------
Testing Backup
---------------------------------------
Downloading my_backup-20050921-0100.gz from my.server.com
Unzipping my_backup-20050921-0100.gz
Creating test repository
Loading repository
Checking out repository
Cleaning up

If you want to use this on Windows, you’ll need to make a few changes. First the way we generate the time and datestamp for the file name will need changed. You’ll probably want to use something other than scp and gzip as well.

Here is the script. I hope some people find it useful.


my $svn_repo = “/var/svn”;
my $bkup_dir = “/home/backup_user/backups”;
my $bkup_file = “my_backup-”;
my $tmp_dir = “/home/backup_user/tmp”;
my $bkup_svr = “my.backup.com”;
my $bkup_svr_login = “backup”;

$bkup_file = $bkup_file . `date +%Y%m%d-%H%M`;
chomp $bkup_file;
my $youngest = `svnlook youngest $svn_repo`;
chomp $youngest;

my $dump_command = “svnadmin -q dump $svn_repo > $bkup_dir/$bkup_file “;
print “\nDumping Subversion repo $svn_repo to $bkup_file…\n”;
print `$dump_command`;
print “Backing up through revision $youngest… \n”;
print “\nCompressing dump file…\n”;
print `gzip -9 $bkup_dir/$bkup_file\n`;
chomp $bkup_file;
my $zipped_file = $bkup_dir . “/” . $bkup_file . “.gz”;
print “\nCreated $zipped_file\n”;
print `scp $zipped_file $bkup_svr_login\@$bkup_svr:/home/backup/`;
print “\n$bkup_file.gz transfered to $bkup_svr\n”;

#Test Backup
print “\n—————————————\n”;
print “Testing Backup”;
print “\n—————————————\n”;
print “Downloading $bkup_file.gz from $bkup_svr\n”;
print `scp $bkup_svr_login\@$bkup_svr:/home/backup/$bkup_file.gz $tmp_dir/`;
print “Unzipping $bkup_file.gz\n”;
print `gunzip $tmp_dir/$bkup_file.gz`;
print “Creating test repository\n”;
print `svnadmin create $tmp_dir/test_repo`;
print “Loading repository\n”;
print `svnadmin -q load $tmp_dir/test_repo < $tmp_dir/$bkup_file`;
print “Checking out repository\n”;
print `svn -q co file://$tmp_dir/test_repo $tmp_dir/test_checkout`;
print “Cleaning up\n”;
print `rm -f $tmp_dir/$bkup_file`;
print `rm -rf $tmp_dir/test_checkout`;
print `rm -rf $tmp_dir/test_repo`;


Brett Porter has hacked together a tool that will let you use a CVS or Subversion repository as your maven repository.

Brett Porter - Storing your Maven Repository in CVS/Subversion
It’s pretty rough, but is a working prototype that makes Maven 1.1/2.0 downloads a checkout/update, and deploy is an add/commit. I see this would be useful for snapshot repositories, where you could use one filename instead of transforming the version, so getting the latest would literally be an svn update.

If you are using Subversion with Apache, it is pretty easy to achieve most of this. The problem that I’m faced with is the fact that Maven can’t handle repositories that use SSL and a login.

Currently, I’m using a separate server to host our Maven repository because the Subversion server is using SSL. I hope that Maven will eventually come up with a way to work around this, but right now it looks like most of their efforts are being spent on Maven 2.

I ran across this blog post that is probably typical of many people who are managing software projects.

Musings of a Software Development Manager » Blog Archive » CruiseControl Warnings
I get about 48 email messages from Cruisecontrol each day for one of our projects. This is not something I’m proud of since this situation has existed for at least 4 weeks now, we’ve had a broken build. The problem stems from some nasty functional tests that no one wants to investigate and we’ve sort of let our process slip.

There is a simple solution to this. Turn off the tests that are failing. People’s first reaction to this is “Oh no, we can’t turn off the tests! They indicate that something is wrong. Eventually we’ll have time to fix it.”

If you are actually going to fix it go ahead, but if something has been broken for more than a week, chances are no one is going to fix it any time soon. You should turn it off so it starts building without errors again.

Why is this better? If your team gets 10 emails each day saying that something is broken, they are going to ignore it. No one is really responsible for all of the problems, so no individual really works on fixing it. However, if the build is working correctly and someone checks in code that breaks a unit test and everyone gets and email, that person is probably going to try to fix it because it shows that he is responsible for the problem.

Think of it another way. Lets say I have 3 smoke alarms, 1 gas alarm, 1 CO2 alarm, and a flooded basement alarm in my house and they all sound pretty much the same. Now lets say that the flooded basement alarm goes off and I decide that it isn’t important enough to fix the cause…. So I just let the alarm go off. How likely do you think I am to notice if another alarm goes off once I get used to ignoring the first alarm.

If I’m not going to fix the problem, the best thing I can do is disable the flooded basement alarm until I have a chance to fix it. After a week of ignoring the alarm and nothing bad happening, I’m not suddenly notice it and decide I should do something about it.

One of the first things I did when I started at my current job, is go through and renamed every test that failed our automatic build process as “pending”. By the time the test would run, I had disabled about 2/3 of the tests. Since they were failing we ignored them anyway, so marking them as pending didn’t change anything. Before they were turned off, it would have been impossible to notice if one of the tests that were previously working broke because of a change.

Over time we’ve turned most of the pending tests back on one at a time as we’ve had more time to fix the code or fix the test.

When your tests fail, it should be unusual. I setup our builds to break if any test fails. I’ve got a lava lamp above my cubicle and everyone in the company know what it means. If something breaks people start asking the developers about it until it gets fixed.

Kathy Sierra has an interesting post on her blog about college. Toward the end she talks about how her teenager has decided not to go to college. Kathy reasons that since her personal career has very little to do with her original degree, her daughter is just as well off to spend her time at a vegetarian cooking school instead of pursuing a 4 year degree.

While Kathy makes some excellent points, I don’t think that the cooking school is going to prepare her daughter as well as attending a university. It doesn’t matter what she studies. That is the whole point of a liberal arts education–you don’t just study your field of interest. Places like that are known as vocational schools.

Go to college and pick something you enjoy studying. You are going to spend 4 years developing yourself as a person. If you think the facts you learn in an accounting class to make you attractive to an employer in 10 to 15 years, you’re going to be very disappointed.

OS X has an environmental variable called CLICOLOR. If it is set, it turns on color for command line commands. So…

export CLICOLOR=true

will turn on color. If you want to enable this for everyone, you could do that by putting it in /etc/profile.

This guy says that using Subversion and Cruisecontrol cut their costs by 92%. It would be interesting to see how he calculated this. Regardless, it is amazing how many quality tools are available for free now.

Why Subversion Rocks
In a recent study I performed on my development groups process improvement over the past 5 years, we found that we had cut the cost of managing our build and release process by approximately 92% by incorporating Subversion and related tools like CruiseControl, ViewCVS, and other custom software (and major process changes that accompany them) to integrate and automate our release management processes.

Here is an interesting discussion about the dangers of design patterns. Design patterns can be a great way to solve problems, but many times they become an excuse to over-architect solutions. Design patterns should reduce complexity. If they introduce more complexity, you are doing something wrong.

The myth of design patterns is that they will make it easy to solve problems that you haven’t through of yet. This sounds great in theory, but it is easy to end up “gold plating” the software by building in flexibility that will never be used.

The real power of design patterns is in solving existing problems. A lot of the times this means they will be introduced when you are re-factoring code. When the code starts becoming complex and a design pattern makes things simpler, then it might be a good time to use one.

I’ve inherited a project that makes extensive use of design patterns. In some places the patterns make the code simpler. For example the chain of command pattern is used in several places, so once you understand how the authentication piece works, you understand the principle behind several other key components.

Another pattern that shows up a lot is the factory pattern. While this is a great way to decouple code, it is only beneficial if you gain some type of benefit by having the code loosely coupled. I ran into an piece of code the other day where a factory created an object and I needed to know what it was. I had to look through 5 other java classes and two configuration files to figure it out. In this case, using a pattern made things much more complicated and there weren’t any significant benefits.

Patterns need to be used to solve real problems. If you try to use them to solve every potential future problem, they become a liability.

Technorati Tags: programming, software

• Practice. Expect to practice with your version control system before you go live. This means you need to have a copy of your data. If you are exporting data from CVS to Subversion, it is probably a good idea to keep the import files around for a while in case you have to go back. Version control systems are generally forgiving (that is the whole point over having version control right?), but you can mess things up. For example if you accidentally import several GB of binary files and then delete them, it might cause problems with your backups because that data will still be there.
• Training. Make sure everyone gets at least some training on how to use the system. A short list of how to accomplish common tasks can make everyones life a lot easier and may head off problems down the road.
• Backups. Your data must be backed up automatically. Just copying a directory doesn’t mean you’ve backed up anything useful. You don’t really know if you’ve got a backup until you test it. When you are setting up your backup you should do a test restore to another machine and then checkout your data to make sure it works. You should probably repeat this every few months depending on how important your data is.
• Decide what to keep. You need a clear policy as to what goes into version control and what doesn’t. Some people recommend putting everything under version control. However, I can’t think of a whole lot of reasons to keep a binary iso under version control. Generally you want to put stuff in the repository that might have other versions. Personally, I don’t like keeping binary libraries in Subversion. I have a separate repository for those types of files. I do think it is a good idea to keep your configuration files in the system. It is a real lifesaver to be able to go back to a previous version of a backup script to see why it is failing now, or to see what has changed in httpd.conf that is making Apache act funny.
• Remote access. If you want to make your repository accessible over the internet, you should plan for it when you set it up. With Subversion this is easy because you can plug it into Apache 2. Keep in mind that you want to use the same url from inside the network as outside. This is usually just a matter of putting a DNS entry on your internal network that points to your private ip address while the public DNS entry points to your public address.

Here is a scary scenario for a programmer. Unfortunately it is probably not too uncommon. Imagine you are starting a new job. Before accepting the position you ask all the right questions, but on your first day you discover the following:

1. The lead programer left two months ago. (You already knew this.) The only form of documentation is a few comments and javadocs. (You didn’t know this.)
2. While the project has it’s own CVS server, the backups were done without shutting down CVS and they had never been tested. The server crashed and all the backups were corrupt. There is a copy of the source code that someone had on their local hard drive, but no history information and there isn’t code of the last stable release.
3. The 30% of the unit tests fail. Another 30% have errors. Some of the tests are just wrong, others rely on having resources configured in a specific way. There are also some tests that aren’t actually testing code, but instead do things that populate the databases, etc.
4. The core framework used in the project is based on a 6 year old proprietary binary library that doesn’t have any documentation.
5. The bug tracking data was lost in the server crash. Since you don’t have the source code from a stable release, there are a bunch of little bugs, but none of them are documented.

Sound like a nightmare? Definitely. But it is also an opportunity. Here are the steps I would take under the above circumstances. I’d enjoy hearing what others have to say as well.

1. Implement Version Control. Personally I prefer Subversion, but regardless of what you use, getting it up and running should be your first priority. And just having it functional isn’t adequate. It needs to be running, automatically backing up, and you must test doing a restore from the backup data. If you haven’t tested your backup you are begging disaster to strike. (more on version control)
2. Setup an Issue Tracker. You need a place to keep track of the problems you find. You don’t want to remember a nasty bug when a customer calls to tell you about it. The issue tracker should be used for more than just bugs. It should be your central repository for everything the developers are working on. That means it should hold features, tasks, ideas for improvements, etc. Set milestones and assign issues to those milestones. If you are tracking estimated time for each issue, you’ll be able to set realistic schedules.
3. Document your setup. You need to know how to setup the build and run environment from scratch. I would suggest starting with a clean machine and setting everything up. If your project builds fine on the old developer’s machine, but not on any new machines you setup, you have a problem. You may find yourself spending several days hunting down all the dependencies and configuration settings.
4. Fix the Unit Tests. If tests are failing the developers will ignore them. All of your active tests have to pass every time you run them. If this means you go from 400 tests down to 50 that is fine. Tests that don’t pass can be prefixed with “pending” so they won’t run and you can re-implement them over time. If a test fails you need to consider the build to be broken.
5. Setup Automatic Builds. This doesn’t need to be anything fancy, but if code compiles and tests fine on your machine, but fails on others, you need to know about it right away. Ideally the code should recompile whenever there are changes in the version control system. Also you should make the build fail if the tests fail. When a build fails, you can have it send email, flash the lights, or turn on the overhead sprinklers, but you should not ignore it.
6. Document the code. Digging through someone else’s code and trying to make sense of it can be extremely painful. But you really can’t start writing your own code until you understand how the old code works. Even if you want to replace parts of the old code, you will need to understand what the code you plan to replace is actually doing. Make sure you record your findings, so they can benefit others. You may get called away to rescue another troubled project and you want to make sure you successors don’t have to start over.

Technorati Tags: programming, software, version control

Cobertura is a fork of jCoverage. It runs reports to let you see how much of your code is being tested by unit tests. This is incredibly useful to find areas of your code where a bug would go undetected.

It looks like there is a plugin for Maven already, so I’m going to have to give it a try sometime. link

One of the things I need to do at my new job is get an issue tracking system in place. At Reslife, we put in Cerberus for tracking help desk request. Coming into a place that doesn’t have any type of system to track issues made me realize how much I took Cerberus for granted. Cerberus (www.cerberusweb.com) is a nice simple ticket tracking program. It worked very well for the church’s needs, but for software development we need something more powerful and specialized. Specifically here are some of the things I’m looking for:

1. Integration with version control. If someone commits a change to version control and the comments reference a particular issue, I want a notice to show up in the tracking system that links to the change. This needs to happen automatically.
2. Tracking estimated and actual time spent on each issue. For some reason most tracking systems don’t have this feature, but I think it is very important in order for a team to learn to estimate well. By being able to look at several months worth of estimates and compare them with actual time spent, developers should be able to become better at creating realistic schedules.
3. Email notification. Obviously the system should email you if something changes on an issue that you are “watching”. It would be nice if you could respond to an email and have it posted back to the ticket. (This is what Cerberus did a good job of.)
4. Dependency tracking. If item A can’t be completed until item B is done, the system should keep track of this.

Some of the System I’m looking at:

• Scarab
• Trac
• JIRA
• Bugzilla

So far JIRA looks like the best option. But since it isn’t free, I’ll probably need to use something else for awhile. I installed Trac, but it doesn’t seem to do a very good job of keeping track of users. Also it is fairly complicated to get running on Windows.

We’ll probably end up using Scarab. It seems stable and has a decent user interface. There are some scripts that will allow it to interface with Subversion and it handles email notifications and dependencies. It doesn’t do time tracking out of the box, but there may be a way to configure this.

Scarab was created as a general tracking platform. Almost everything is configurable. You can specify a multi step process for entering a new item and include things the checking for duplicate entries. It isn’t as feature rich JIRA, but it looks like several people have started developing on it again, so hopefully it will continue to grow.

When using maven to generate a multi project I’ve run into an error where it says that it reached the “entity expansion limit” of 64,000. This appears to be coming from the SAX parser which is validating all the HTML pages. I’ve looked for a way to turn this parsing off, but so far I’ve been unable to find a way to do it. Launching Maven like:

maven multiproject:site -DentityExpansion=10000000
Seems to solve the issue.

Maven 1.0 has some problems with memory leaks. Most of the time these aren’t issues, but if you are trying to compile a multiproject you might run into problems. By default Maven tells java to let it have up to 256MB of ram. If you need to increase this you’ll need to open the maven.bat (windows) or maven.sh (unix) file and change the way that java is called. Somewhere around line 118 (on the .bat file)you should see the following:

if "%MAVEN_OPTS%"=="" SET MAVEN_OPTS="-Xmx256m"

Change the line so it reads:

if "%MAVEN_OPTS%"=="" SET MAVEN_OPTS="-Xmx1000m"

This will give Maven 1GB of memory to work with. While this doesn’t really solve the problem of the memory leak, it may give you enough space to keep the problem from crashing Maven.

You can also set MAVEN_OPTS by setting it up as a variable in your environment. If you do this the environment will override anything you set in the .bat or .sh file.

One of the major purposes of software design is to avoid making mistakes. You design your software so you don’t get halfway into the project and say “Oh yeah I didn’t think about that” and have to start over again or continue with a weak foundation. Unfortunatley don’t know exatly what type of mistakes you are likely to make until after you start coding. Since you don’t really know what the real problems are until after you encounter them, you are left with two options. First you can create your design to eliminate problems that you’ve experienced in other project. Second you can build a prototype to get an idea of what will be a problem then design and code the final system.

Trying to plan ahead and eliminate problems before they occur sounds like a great idea, but it often increases the complexity of the project. This isn’t a bad thing if the increased complexity solves real problems, but since you are trying to solve “imagined” problems before they actually occur, some won’t turn out to be problems at all. This means that that software is more complex than necessary.

I have been hosting this site at www.redwoodvirtual.com. The offer some inexpensive virtual private servers and most of the time everything runs well. Unfortunately their server decided that I had gone over my 40 GB of monthly bandwidth and throttled everything down to a very low level. Pages were taking 30 to 120 seconds to load. Redwood’s support is only through email and they seem to check it every 48 hours. The biggest problem is the fact that if they ask you for information in resolving the problem, you’ll have to wait another 48 hours for them to read your reply, so conversations look something like this:

Me: Something is wrong with the bandwidth. Can you please fix it? If you need info from me to fix it, please call me so we don’t have to wait several days for each exchange.
[Wait 48 hours]
Redwood (via email): Hmm… it looks like your bandwidth is being throttled. Do you think you went over 40 Gigs?
Me: No. According to my logs I’ve used only about 12 GB this month. I’m willing to pay more to get things up and running immediately because I can’t afford to have my site down. Can you turn it back on right away?
[Still Waiting for a response]

I went ahead and signed up for an account with www.hostforweb.com. I’m on a shared server, but I figure there is safety in numbers. If their server goes down and I’m not around to tell them, someone else will say something. The also offer ssh access which makes it a lot easier to test scripts, move files around, etc. I’m looking at their virtual private server plans, but I think the shared server may meet all of my needs.

I think my ideal setup would be to use a company like Redwood Virtual to run nightly jobs that upload their results to a shared server site. That way I’d get the flexibility of having root access, but with better reliability for my public pages.

It is probably too early to tell if it is true, but there are some rumors going around that there is a bit torrent of a version of OS X that runs on regular intel hardware. There is even an image of a Compaq running the operating system. Some people have the opinion that this is a clever ploy by Apple to create a lot of publicity. Personally I doubt if that’s the case. It seems unlikely that they would be trying to get publicity for something that you won’t be able to buy for another 12 months or so. There is quite a bit of discussion going on about whether or not the download is real. Most of the Slashdot crowd is calling it a fake, but several posters to www.thePirateBay.org claim that the file called Mac.OS.X.Tiger.X86.READNFO-XISO is the real thing.

PirateBay is showing only one download of the operating system so far and one user is claiming to have it installed. I must admit that when I saw the rumors originally, the thought of posting an iso of Linux labeled as Tiger for Intel did cross my mind. The file being shared may be the result of someone else having the same idea.

The best comment on Slashdot was this:

I think the question all mac users are asking is, will this run on Virtual PC???