EBS (Elastic Block Storage) is a way to attach disk volumes to your running EC2 instances. The main difference between EBS volumes and the default ephemeral storage that is attached to EC2 instances by default is that EBS volumes persist beyond reboots and can also be moved between instances without losing the data contained within.

EBS Volumes are billed out in 1GB increments at $.10/GB/month. This is not per usage, this is per allocated GB. For example, if you have a 10GB volume allocated and only 1GB of it is in use, you’re still paying $1/month.

For the purposes of this example, we’ll start with 2 1GB volumes ($.20/month for allocation) which will be mirrored for redundancy at the OS level. This will ensure that a failure of one of the volumes will not affect the operation.

Allocating an EBS Volume

NOTE: For the purposes of this example, the architecture of the running instance is irrelevant. Therefore, to save myself some cost while putting together this part of the demo, I’ll be using a 32-bit ’small’ instance. This will not affect the operation, and will work identically to the 64-bit ‘large’ instance used in the previous examples.

Before you create a volume, you need to determine which availability zone your instance is running within. Think of an availability zone as a server room. To check this, click on the row in your Instances section of the AWS console, and look for the ‘Zone’ entry in the panel below. It should read something like ‘us-east-1d’. Take note of this zone, as it will be required for assigning your EBS volumes (Volumes can only be attached to instances within the same availability zone).

To start the process, click the ‘Volumes’ shortcut under the ‘Elastic Block Store’ header in your AWS console. The default view will show no volumes.

To create a volume, click on the ‘Create Volume’ button in the upper left. You will be presented with a menu asking for the size and availability zone. The size can be anywhere from 1GiB to a theoretical unlimited TiB. In this case, choose 1GiB, and pick the availability zone that matches your running instance. Do this twice, so you end up with 2 1GiB volumes.

NOTE: You may not be familiar with the GiB and TiB nomenclature. For our purposes they are the same as GB and TB, but they do have a significant difference. A TB refers to 1,000 GB, which is 1,000MB, which is 1,000KB, which is 1,000 bytes. A TiB is the binary-counting equivalent, meaning: a TiB is 1,024GiB, which is 1,024MiB, which is 1,024KiB, which is 1,024 bytes. So while a TB is 1,000,000,000,000 bytes, a TiB is 1,099,511,627,776, an eventual difference of 99.5 Billion bytes.

Once the volumes have been created, it’s time to attach them to the system. If you haven’t already, launch an ssh session to your running instance and issue the command ‘tail -f /var/log/messages’. This will allow you to see when and how the system detects that the volumes have been attached.

To perform the attachment, select the checkbox next to one of the volumes and click the ‘Attach Volume’ button that becomes available. You will be provided with the option of which instance to attach the volume. There should be only one. Choose the next available device name (/dev/sd* in the list). If you don’t see your running instance, be sure you created the volumes in the proper availability zone. Do this for both volumes, making sure that you have different device names for each.

Configuring the Volumes

When the EBS volumes are created, they are just like brand new disks out of the box, completely empty, and without any information whatsoever. Since we’re going to be using them as PVs (Physical Volumes) within LVM, this is ok, as they’ll be initialized properly when we start to use them. The first of these steps is to tell LVM that we have 2 new PVs we’d like to use. To do so, issue the following commands (assuming /dev/sdf and /dev/sdg for our new EBS volumes):

• sudo pvcreate /dev/sdf
• sudo pvcreate /dev/sdg

Next, we’ll want to create a VG (Volume Group) out of these new PVs, which will allow us to then start creating usable file space. To create a VG, issue the following command

• sudo vgcreate datavg1 /dev/sdf /dev/sdg

Next, we need to create an LV (Logical Volume) within the VG, which will house our filesystem. In this case, we want to create a roughly 1GB LV that is mirrored (2 copies, one on each physical volume). This will take up both of the EBS volumes we attached to the server earlier. To create this mirrored LV, issue the following command

• sudo lvcreate -L 1000M -n datalv1 -m 1 datavg1 –corelog

This creates a 1000MB volume named ‘datalv1′ with 1 mirrored device (2 total copies) within the datavg1 VG. The ‘–corelog’ option tells LVM to manage logging (the system keeps track of changes made to the LV) internally to the LV, otherwise, a third device would need to be used for logging. We can’t use a size of 1GB (-L 1G), because of the ‘–corelog’ option, which requires some space within the LV. This leaves a little bit of unused space within the VG, but it’s negligible.

Using the Volume

Finally, we need to create a filesystem within the LV that will allow us to actually use the space. To do so, issue the following command:

• sudo mke2fs -j /dev/datavg1/datalv1

This will create an ext3 filesystem (standard within the Linux world, but you may update the command to use whichever filesystem type you desire) that fills up the entire LV called ‘datalv1′. As a test, you can create a mount point, which is simply an empty directory, and mount the file system, this will show you your available space in the volume.

If you’re not planning on utilizing these volumes right away, you can essentially reverse the process to unmount the filesystem, delete the LV, remove the VG, detach the EBS Volumes, and finally remove the EBS volumes. I recommend you do this until you have the process down and can get things running in more-or-less one sitting.

Elastic IPs

Fortunately, this section is rather straightforward, and will just give an overview of how Elastic IPs work, and how to attach them to a running instance. Later, I will show you how to create a nameserver, and then begin running resources through your Elastic IP into your running instance.

To allocate an Elastic IP for your use, click the ‘Elastic IPs’ option under the ‘Networking & Security’ heading in your AWS console.

Since you won’t already have any Elastic IPs allocated, you will be asked to create one right away. Click the button you’re presented with, and you will see an IP appear almost instantly.

NOTE: Elastic IP usage is billed differently than other AWS resources. Since IPs themselves are relatively inexpensive, Amazon doesn’t charge you for using them. But, to keep people from hoarding IPs and not using them, Amazon charges $.01/hour for any Elastic IPs allocated that are not being actively used. While this isn’t much in the short-term, keep aware, as this can add up if you’re not watching.

To attach this IP to your running instance, simply click the checkbox next to the new IP, then click the ‘Associate’ button that becomes available. Again, since you are only running one instance at this time, you should be presented with only one option. Click ‘Associate’ in the menu, and then return to your instances display in your AWS console. After a few seconds of clicking ‘Refresh’ (this could take up to 10 minutes, according to Amazon, but I’ve never seen it take more than 2 minutes), you should see the ‘Public DNS’ item change to match your new IP.

At this point, you should be able to access your instance via SSH to the new IP address, rather than the old one.

That’s it for dealing with Elastic IPs. In the next installment, we’ll work with setting up our hosting control systems, including configuring a domain and DNS.

Starting the base AMI

For managing our server instances, EBS volumes, and Elastic IPs, we will be using the Amazon AWS Management console, which provides a nice web-based front-end to all of the necessary functions.

The default EC2 Console View

The first step is to choose the AMIs menu item on the left of the console window. An AMI is a base image that can be booted into an EC2 instance. Think of it as a backup of a running system that can be restored to another system in the event of a failure. This link will bring up a selection list of available AMIs, which will be used to create our default instance.

The initial list of available AMIs you are shown covers all public AMI images. Any one of these can be booted into an instance. We are going to filter this list so we see only the types of images we want. To do so, click the dropdown arrow next to the ‘All Platforms’ item, and choose ‘Ubuntu’. This will filter the list for only Ubuntu-based AMIs. Then, in the filter box, type ‘intrepid’. This will further filter the list so that we only see the most recent fully-released version of Ubuntu, titled ‘Intrepid Ibex’. Check the box next to the AMI with the ID ‘ami-255bbc4c’.

Choosing the Proper AMI

To start an instance based off of this AMI, check the box and click the ‘Launch’ button at the top of the display window.

NOTE: Using Amazon EC2 is NOT FREE. When you launch an instance, you will start the clock, which will run at $.40/hour in the US (other zones vary) in the case of this configuration. While not initially expensive, if you forget to stop an instance, the cost can add up quickly.

When you launch the instance based off of the chosen AMI, you will be presented with a menu. Since we’re launching an x86_64 instance, your choice is a ‘Large’ or ‘Extra Large’ configuration. In rough terms, the ‘Extra Large’ instance is twice as powerful as the ‘Large’ instance. It also carries twice the cost, so beware. If you feel you’ll be able to utilize the additional horsepower and memory, feel free to use the ‘Extra Large’ instance, as it does not affect the configuration steps.

You will also be asked to choose or create a keypair, which will allow you to do the initial connections via SSH. In the example configuration, we will not be using (and will actually be removing the requirement) a keypair, but we need it initially to access the instance after it has been started. Once you create a keypair, you need to download your personal certificate, which will allow you to access your running instance. If you lose this file, there is no way to retrieve it, and you will need to create a new pair.

You also have the option of creating and using Security Groups, which allow you to segment your EC2 virtual network for security and operational customization. For the purpose of this tutorial, we are only using one server, and therefore do not have a need for custom Security Groups.

Choose the number and type of instances

After launching your instance, you will be presented with your Instance status window. The rotating icon on the left indicates that the status window will update automatically. If you change to a different view, and then come back to the instance status window, that icon will switch to a checkbox, and the status will not update automatically. At this point, you can update manually by clicking the ‘refresh’ button in the upper right of the instances window.

When your instance is started, you will see a status of ‘Running’, and an entry in the ‘Public DNS’ field.

Customizing the instance – Pass 1

To access your newly started instance, use your favorite SSH program (I personally use Putty). You will need to utilize your downloaded key file. Upon login, use the id ‘ubuntu’. You will not be prompted for a password, as the key file acts as the pass.

The first thing we’re going to do is remove the passkey portion from the SSH configuration. Since we’re going to be configuring this server for multiple client use, we want them to use passwords. To change this, edit the file /etc/ssh/sshd_config file using the command ’sudo vi /etc/ssh/sshd_config’. This will open the file in the vi editor with root authority, allowing you to make changes. To enable password authentication, change the line that reads ‘PasswordAuthentication no’ to ‘PasswordAuthentication yes’.

Before restarting the ssh daemon, which implements the change, we want to set a password for the Ubuntu user so we don’t lose our ability to connect. To do so, use the command ’sudo passwd ubuntu’. This will allow you to set a new password for the ‘ubuntu’ user.

Once the password is changed, restart the sshd daemon using the following command ’sudo /etc/init.d/ssh restart’. Before closing the existing connection, be sure to connect via a new session, using your new password for the ‘ubuntu’ user. Once you are confident you can connect reliably, feel free to close the initial window that used the keypair for authentication.

The next thing we want to do is update the system to the latest patch levels. Since the AMI was built when Intrepid Ibex was released, we want to make sure any existing security issues have been repaired. To check for new updates, use the command ’sudo apt-get update’. When the command completes (should only take a few seconds at the most), use the command ’sudo apt-get upgrade’, which will start the upgrade process. The system will check against the updated package list, and build a list of packages to be updated. When it is ready, it will ask you if you wish to update. Type ‘Y’ to confirm.

NOTE: EC2 instances are not static. If you shut down your running instance without following the next steps to save your configuration, you will need to go through the beginning of this article again.

Finally, to prep the system for the LVM (Logical Volume Management) setup we’ll be using for user data, LVM packages must be installed. To install LVM, simply execute the command ’sudo apt-get install lvm2′

Archiving the instance – Pass 1

Once the updates are complete, it is time to do the first ‘backup’ of the running instance into a usable AMI in your personal S3 storage location.

If you do not already have one, you will need to create an x.509 certificate keypair, which will allow you to upload your image to S3 and keep it for storage.

EC2 creates what is referred to as an ‘ephemeral’ storage location which allows you to store temporary data, which is ideal for creating our AMI. The storage is mounted by default at /mnt. We will be using this storage as our default location for the next several steps. To access it, simply type ‘cd /mnt’.

Next, we want to create an image of the running instance in an archive format that is understood by EC2 and can be registered as an AMI that can further be launched as a new instance.

To enable the bundling of an image and registering as an AMI, we need to make sure the appropriate x.509 keypair exists on the system. Upload the two files you should have downloaded when you created your certificate to the /mnt folder on the instance. If you bundle the image with incorrect keypair information, you will be unable to unbundle and register an AMI.

The default location for bundling is in the /tmp directory, which unfortunately exists under / in the default EC2 configuration. This is not a big problem, necessarily, but it necessitates us choosing a different default location as more information is added to the running system. Since the ephemeral storage mounted in /mnt is about 400GB, that’s plenty of space for our needs. To keep things separated during the bundling process, create a folder called ‘bundle’ under the /mnt directory using the command ’sudo mkdir /mnt/bundle’.

To bundle the running image for upload to S3, you will issue the command ’sudo ec2-bundle-vol -k /mnt/pk-<your private key string>.pem -c /mnt/cert-<your cert string>.pem -d /mnt/bundle -s 1000 -u <your account number>’. The account number is your Amazon AWS account number without the dashes. When you hit enter, confirm that you are creating an x86_64 instance, and the program will chug along, creating an image of instance, and placing the files in /mnt/bundle.

With this nice powerful instance, the bundling process takes about two minutes. When it completes, you will see a list of image.part.x files in the /mnt/bundle folder, along with a file called ‘image.manifest.xml’. This is the file you will use for uploading your image to S3 for storage.

To upload the files to an S3 bucket, issue the command ’sudo ec2-upload-bundle -b my-bucket -m image.manifest -a my-aws-access-key-id -s my-secret-key-id’ from the /mnt/bundle folder. The bucket must be an existing bucket within your S3 store. The access key and secret key for your S3 account can be found on your AWS account page.

When complete, you should be able to see the image.part files and your image.manifest.xml in your previously-mentioned S3 bucket.

To register your newly bundled AMI, return to your AWS EC2 console, and click the AMIs entry again in the left. At the top of the AMI display window, you will see a button labeled ‘Register New AMI’. The popup starts the URL for your manifest file. All you need to do is fill in the name of the bucket and the filename. The resulting URL should look like ‘http://s3.amazonaws.com:80/my-bucket/image.manifest.xml’. The registration process should be almost instantaneous. If you receive any errors, go back over the previous steps and make sure your keypairs and other identifying information match appropriately.

Before shutting down the previous instance, we need to boot the new instance and make sure that our configuration and updates have been carried over. In the AMI window of your console, you should already be set to view ‘Owned By Me’, which should show you your new AMI. If not, click the dropdown and select ‘Owned By Me’.

Testing the new custom instance

Launch the AMI into a new instance using no keypair and wait until you see a public DNS entry in your console window.

If you can access your new instance appropriately (using ‘ubuntu’ and the password you created), and you see that the instance has it’s updates (’sudo apt-get update’ shows no available updates), you can safely shut down both instances by checking their boxes and selecting the ‘Terminate Instance’ option in the instance display window.

Next time, we’ll look at configuring EBS volumes and Elastic IPs.

This series of articles will look at the viability of using EC2 as a platform for reselling web hosting services. Listed below are the base items used in the development of the series. Your choice of platforms and options may vary. While I may explore other options, don’t take the examples I give here as the only way to approach things.

Requirements:

These items are required for creating an environment that matches the example given in the series.

1. Amazon Web Services account. Free to obtain, and attaches to your existing Amazon account if you choose. See this link to register.
2. A fully or demo licensed copy of CPanel/WHM control panel software.
3. A fully or demo licensed copy of WHMCS (WHM Complete Solution)
4. An available primary domain name (Optional: one or more secondary domain names for testing client configurations).
5. Potential clientele
6. A willingness to learn and experiment potentially outside your comfort zone.

Our Test Environment:

The environment we’ll be using for these articles will consist of 1 Amazon EC2 Large (x64) instance (Roughly equivalent to a 3GHz Quad Core Xeon processor, with 7.5GB of RAM), Multiple Amazon Elastic Block Store (EBS) volumes of varying sizes, Multiple Amazon Elastic IP addresses to be used for both server and client configuration.

The next article will deal with the initial base setup of the EC2 image and archiving it for use in the next steps.

The Detroit Lions have been the laughing-stock of the NFL for almost as long as I can remember keeping track. For the last 25 years or so, the Lions have managed to lose most of their games, culminating in the embarrassment of the 2008 season, wherein they won the staggering total of 0 games. And the nation was able to watch this embarrassment live as it happened because of one thing: The NFL Blackout Policy.

In it’s simplest terms, the Blackout Policy stops any game that is not sold out at the venue from playing on network TV. For as long as I can remember, the Lions have been on TV on Sunday afternoons, and I can’t think of the last time I couldn’t watch them fail miserably because DETROIT SPORTS FANS CONTINUED TO BUY TICKETS.

This allowed a few things to happen:

1. We could continue to watch the painful experience of a Lions game from the comfort of our own homes
2. Bill Ford Jr. could continue to reap the rewards of selling 30,000+ tickets at exorbitant prices
3. The networks could continue to rake in the profits from advertising
4. The Lions still lost

This season, 2009, seems to be a bit of an exception both in Detroit, and in other markets. Sell-outs are expected to be at a near all-time low, and correspondingly, blackouts are expected to be near an all-time high.

Today was one of those blackout games. The Lions stellar record of losing, coupled with the insanity of the Detroit economy have converged to create a surprisingly rare non-sellout game.

And then they win.

For the first time in almost TWO FULL YEARS, the Lions managed to pull out a regular-season win. And the only ones who could see it are those that bought tickets.

But this is not the thing I’m upset about.

I’m upset about the fact that a sellout for the Lions’ next home appearance is almost a guarantee. That’s how it is with sports. A team does something out of the ordinary (sadly, in this case, that would be winning), and ticket sales for the next appearance get a major boost.

Anyone want to take bets on how they’ll do in the next appearance, when everyone is able to again watch them? With the state of the team such as it is, choosing ‘Win’ is a complete sucker’s bet.

Until Bill Ford Jr. gets his head removed from his rectum and decides to hire a staff that will build a team WITH A DEFENSIVE LINE THAT COULD STOP A DECENT HIGH SCHOOL TEAM, the Lions will continue to have embarrassingly bad seasons.

So, here I am, one of the (probably) very few people that is really unhappy that the Lions won today. I wish I could have it the other way, but I just can’t bring myself to feel excited for a team that has so consistently let us down for so long.

Pull off a .500 season, and I might start to think about getting excited again. Until then, it’s just more of the same. Over and over.

Earlier this summer, I was looking for an all-in-one solution for video-conferencing and broadcasting. There were plenty of tools that allow you to do one or the other, but none that really do both well. Along comes TinyChat with the option to do both. I gave it a test, it worked like a charm, and I was instantly sold. I subscribed, and didn’t look back to my former tools.

Fast-forward to August: I created a recording, went to the download page, and was unable to find it. I e-mailed support, and go no response for a few days. Then, when I did get the response, it was simply “Well, that seems to happen sometimes, sorry about that.” While this might work well for the average regular user, that’s not the response a paying customer should receive. I pressed a little, and was told that sometimes, if there is corruption in the incoming stream (which they believed there was), recordings will fail. This response, while not really fixing my issue, at least let me know that someone had looked into it, and I could do a few checks at my end before starting a recording to help keep the process stable.

Fast-forward again to last week: My subscription payment goes through on 9/2 just like it should. To verify, I go to my TinyChat members page, only to find that my subscription is not active. I immediately contact TinyChat’s support with the details. After a few hours of waiting, I tested the waters and tried to send a Twitter DM. Since TinyChat is not following me back, I’m not able to do that. I give it a day and try again.

On 9/3, I get an @reply asking what the problem is, as the message may have gotten lost. I reiterate what I can in 140 characters, and they ask for the e-mail I have attached to the account. I reply, asking for them to DM me a contact e-mail. They reply with a request to send an e-mail, ATTN: Support, which I send on the morning of 9/4.

That afternoon, I got a response, again asking for the e-mail address the account is registered to, explaining that sometimes the PayPal response can get messed up going into their system. I replied immediately with the details.

That was the last e-mail response I got from them. Over the entire weekend, I sent e-mails and twitter messages attempting to get any kind of response. Finally, on Sunday afternoon, I send in a request for 3 things: Access to my account so I can download previous recordings, cancellation of my subscription, and a refund of the payment that was taken on 9/2. Since it was a holiday weekend, I didn’t hold out much hope for a response.

After zero contact by yesterday, I sent out another Twitter message, hoping to get some type of response. This morning, I receive a response from @harknesslabs: “I am going to take care of it today and hook you up with a free lifetime account. Will email you after its done.”

Finally, a real response. I check out the Twitter account, @harknesslabs belongs to Daniel Blake, the CEO of TinyChat itself. Later today, I also see the following message: Hired someone to handle support for @tinychat today. So it seems that Dan has known for a while that they have needed someone to handle support duties, this looks like a good sign.

As of this writing, my account has been re-activated, and I’ve been able to access my rooms and recordings. I haven’t gotten the e-mail from Dan yet with the notice that everything’s done, but at this point, it doesn’t really matter. I appreciate the gesture, and I will definitely use TinyChat for certain things, but not for anything that has any real critical bearing, at least not for a while. For my broadcast needs, I managed to put together an Adobe Flash Media Server instance that I can fire up and take down at will via Amazon EC2 (I’m going to detail the steps for this at a later time), which I will use when I need something to work just right.

I hope that TinyChat can get these issues resolved and, in the end, turn out a great product that people will line up to pay for. I’ll be keeping an eye on their future development, and will be sure to let anyone know how things are going if they have an interest.

Thanks, Dan. I hope you don’t have to do this type of thing much more/at all.

So, here we are. Only 2 years, and I can’t imagine my life without this little man who’s growing up so fast.

Today I’m taking a half-day off of work and we’re gonna take him to Great Lakes Crossing for some fun, either Jeepers or GameWorks, or both.

Happy Birthday, little boy!

Oh my does he love trains.

Jonah in the Hospital

Today gave us an example of both the speed at which the information travels, and how quickly a rumor can turn to fact.

At approximately 11:15 am EDT today, the @BreakingNews Twitter account sent the following tweet:

Florida-based radio station KissFM reports that Patrick Swayze has reportedly died. BNO News is working to get more information.

At the time of this writing, at least 1,000 (a conservative estimate, I’m sure) tweets were sent pertaining to the subject. What was interesting was the ‘Telephone Game Effect’ that took hold almost instantly. The first tweet, relatively innocuous in the vein of ‘Hey, we heard this, we’re checking it out. Back to you soon’. Within minutes, however, poor Mr. Swayze was 3/4 buried.

Now, the kicker: He’s not dead. About 15 minutes ago, Mr. Swayze’s publicist stated that he is, in fact, alive. More information is coming in that he’s not doing well, and has possibly been hospitalized, but the fact remains: He’s not dead.

So, over the space of an hour, an unconfirmed report turned into absolute fact. Patrick’s Wikipedia entry was updated, corrected, updated again, and re-corrected, CNN had hastily posted and (just as quickly) taken down an article/obituary, and many people were led to believe this to be true.

So, kids, what can we learn from all of this?

News Organizations and outlets: Be very careful about what gets published. Today, people are more in tune to what’s happening in the world than they ever have before. News spreads in an instant, and it’s nearly impossible to put the genie back in the bottle. Once a false story gets out, the only thing that can be done is damage control. However, retractions and corrections can only get one so far. Credibility is a news org’s stock in trade, and any hits to the public’s perception can be deadly. Balancing the need to get out first with information with ensuring that the data is correct is an artform that very few, if any, have mastered.

Public: Be careful about what you read. Don’t always take the first source of reporting as fact. Many times, the first report that gets out either has some piece, or possibly the entire story incorrect. Take the time to verify and validate sources before coming to your conclusions. The ReTweet has become a great tool for helping to spread information. But, if the information being spread is incorrect, the signal-to-noise ratio (which is already pitifully weak) takes a major hit and makes it difficult for everyone else to be properly informed.

The problem appears to be that the use of the product is bad for your liver. Apparently, REALLY bad for your liver. I mean, REALLY REALLY bad. I’ll let the FDA’s statement lay it out for you:

The FDA has received 23 reports of serious health problems ranging from jaundice and elevated liver enzymes, an indicator of potential liver injury, to liver damage requiring liver transplants. One death due to liver failure has been reported to FDA. Other health problems reported include seizures; cardiovascular disorders; and rhabdomyolysis, a type of muscle damage that can lead to other serious health problems such as kidney failure.

That’s right. While only 23 complaints have arisen, it’s very likely that there are many more people who started to notice an adverse effect and just quit using it (the smart people, as I like to refer to them). Some people, who had to have noticed some adverse effects, continued to use the products to the point of permanently damaging their livers, one so much that they died (the not-so-smart people, as I like to refer to them).

Anyway, this is all beside the point I came here to make. What I came here to say was that in only 10 days, I have started recieving SPAM e-mail regarding the recall. I know it’s spam for a few reasons:

1. The ‘from:’ domain is remarkheavensbr.net, which points to just a parking site with no content at all (not even html headers).
2. The ’subject:’ line is grammatically incorrect: “FDA Recall Hydroxycut”. They could have at least said “FDA Recalls Hydroxycut” or “FDA Recall of Hydroxycut (products)”, or any other permutation.
3. The real kicker: The entire content of the e-mail is images, which likely link back to a tracking site somewhere that validates your e-mail address, were your mail client to download the images.

So, I have no idea what this SPAM is advertising, not as if I cared. I just thought it was pretty interesting how quickly these lowlifes jump on new bandwagons.

Someday, I envision a future where the webbernets are SPAM-free, and anyone caught abusing the system in such a way is strung up in a public forum. But that’s just me.

Since it’s now springtime in the rapidly-thawing midwest, I’ll probably be out and about more with my camera. Non-people photography really doesn’t appeal to the wifey, so it’s up to me to capture the really cool stuff.

Since this is more of a tech/personal stuff area, I’m going to be creating a new section just for pictures and stuff.

Stay tuned!

Good. If I had my own way, I’d personally drop support for anything below Vista SP1 for the latest versions of Firefox, and keep the previous version updated within reason for a predetermined amount of time. I’ll get into why I feel that shortly. But for now, back to how I feel about the situation.

As I said, good. Windows 2000 has been available to developers for more than 10 years now. It’s been available to the public for 9 years as of this summer. It’s time to burn out and/or fade away. People will complain that there are still valid reasons to have a Win2k system hanging around due to some compatibility issues with newer software, which I’m personally ok with. The problem I have is when these people insist on also being able to run the most current versions of non-OS software. If you’re one of these people, listen carefully to what I’m about to say next:

YOU DON’T NEED TO RUN THE LATEST FIREFOX IF YOU’RE STILL RUNNING A 9-YEAR-OLD OS. Period.

And I honestly don’t think this would be an issue. Sure, while there are people around like Steve Gibson who are so paranoid that they won’t run an OS that they haven’t personally combed through every single bit of code with their own hands, they are extremely few. And these are the same people who probably aren’t running Firefox at all, anyway, let alone trying to run the absolute latest and greatest version (which would probably run like a dog as it is, since any hardware that’s still running 2k on a desktop is likely at least 5 generations behind today’s market).

So, yes, I think it’s pretty simple. If people can’t even allow themselves to be bothered with keeping their systems updated. SP3 for XP was released to the public 50 weeks ago. Anyone who hasn’t updated to it yet either has a really good reason for running older software (see my previous point), or is just plain lazy, and very likely doesn’t even run Firefox to begin with.

Now, with my point about dumping support for anything prior to Vista SP1. There are multiple facets to my argument here.

1. If you are using a computer less than 2 years old, there is almost absolutely no reason for you to still be running XP in any form. It’s old, it’s outdated, and it can’t exercize the full potential of the system for which you very likely paid pretty good money for. Stop listening to the “Hurrr… Vista is teh suck! It eats all your RAMs!” people and do some of your own research. Vista is a good OS, particularly so post-SP1. I use it personally on my primary system. The 64-bit version, which I run, is excellent, and light-years beyond the capabilities of XP64. Stop listening to Apple commercials as your only source of Vista information and do some real research. You’ll find that most of the things people complained about have either been fixed, or are a part of the system’s function that people just simply didn’t understand at first. If you’d like to know some of these arguments and my rebuttals to them, let me know, and I’ll create a separate post about it.

2. If you’re running Vista, and you haven’t updated to SP1 yet. Stop reading this and do it now. It’s ok. This post isn’t going to go anywhere. Outside of the blatant misunderstanding that was propagated during Vista’s early life, SP1 fixes many (if not all) of the legitimate problems that were in Vista at launch. SP1 is more stable, faster, and more secure than pre-SP1 Vista, and you’re only hurting yourself if you haven’t updated yet.

So here it is. Stop trying to make every software developer bend to your own will. Mozilla has been putting out a quality product that has fundamentally changed the browser market, and they’ve done it all for free. It’s about time you did them a favor and made a bit of their job just a touch less painful. By dropping support for REALLY old OS installs, it frees them to work on developing a package that is the best it truly can be. Stop holding them back. Update your system, do some research, stop purchasing/installing downgrades, and start really using TODAYs software, not the stuff you installed 8 years ago because you fear change and can’t handle something that works better and more efficiently.

Trust me, you’ll be better off.