I listen to a number of podcasts in the TWiT network.  Actually, I’m normally playing catchup as I’m subscribed to a number of their podcasts. One of the podcasts I’ve been catching up on recently is TWiL - This Week in Law - hosted by Denise Howell. It’s definitely a bit on the dry side, not as funny or lively as the TWiT or MacBreak Weekly podcasts that I tend to keep up with. If you’re dealing with technology or doing business in a technology-related field, though, it’s definitely worth checking out.

The episode I’ve been listening to lately is Episode 16, Cloud Computing and EULA Law.  One of the topics that they delve fairly deeply into in this episode is the topic of ediscovery, or the laws surrounding the legal discovery process relating to electronic assets.  They approach the issue more from a corporate perspective, discussing, for instance, the proper policies for archiving email communications and such.  They do, however, mention the employee use of personal resources and how that use could open up those personal resources to the legal discovery process.  It’s this last bit that caught my attention, both as something that is more common of a practice than anyone probably cares to admit and as something that could have more serious privacy ramifications for any employee engaging in this practice than that employee likely realizes.

To understand how broad this could be, lets look at a couple of examples of use of personal resources for transacting company business:

1. Sending company-related email from a personal email account (using your Gmail account from your iPhone was an example given in the podcast)
2. Using a personal laptop to do your work instead of a company-provided machine
3. Keeping company-related files and information in a personal Google Docs account or other personal cloud storage account

Are you guilty of any of these?  If you are, and the company you work for is ever involved in litigation where the information you handle is pertinent to the litigation, you could be exposing your personal account, and all that is in it, to the legal discovery process.  What does this mean in real terms?  Simply, it means that attorneys, paralegals, and clerks could end up combing through everything in your account or computer looking for whatever evidence they need for their case.  While only pertinent evidence would be presented in that litigation, most people would shudder at the idea of an outsider having full access to their personal information.  Now, I am certainly no attorney, but I would imagine that there would need to be clear evidence that someone was using personal resources on a regular ongoing basis in order for a judge to grant a litigant access to his or her personal resources like this, but, if there is clear evidence that pertinent information could be stored on non-corporate resources, the judge would likely be obliged to grant such access.

So what can be done to keep this from happening?  The way I see it, protecting personal privacy in a corporate environment requires a two-fold approach.  As in many instances, the first approach is education.  Employees must be made to understand the risks they are taking with regards to their privacy when they use personal resources for company business.  The second approach is one the companies themselves must undertake.  Companies need to understand that employees are likely turning to various personally-owned resources because they are more convenient.  To make sure that employees are complying with applicable laws and company policies and aren’t opening themselves up to personal exposure, corporate IT departments must make sure that corporate electronic resources are readily available and easy to use.  If, for instance, you, as a company, expect your employees to be answering email while out of the office, but your email server is only available through a hard-to-use VPN, you’re setting your employees up for failure, because they’ll turn to services they have easy access to in order to fulfill the requirements of their jobs.

So, if you’re an employee reading this, think about the ways you may be unintentionally exposing yourself.  If you’re a corporate executive or IT person reading this, think about the ways in which your employees access company data and how they jive with the requirements of their jobs.  If you don’t, you may be putting your or your employees’ personal privacy at risk.

Yes, another politically-slanted post.  I’ll try to keep them to a minimum, I promise.

There has been much discussion lately on the subject of broadband deployment in the United States.  I fall on the side of the fence that says that our broadband deployment yardstick is long out of date.  I am happy to see the new administration seeking to update our broadband standards.  Regardless of this, though, I had some thoughts on broadband in general that I wanted to share.

First of all, I have been quite frustrated with ISPs for some time in the area of what was considered quality broadband connectivity.  This frustration stems from unimpressive download speeds, absolutely laughable upload speeds, quality of service issues, and even anti-competitive practices that have sparked the debate on Net Neutrality.  One of my largest frustrations, though, is that the American people, for the most part, don’t seem to mind.  Why is this?  My personal opinion is that they don’t know any better.  Call it patriotism, call it pride, call it whatever you want, but most people in this country tend to think that, because we’re America, what we have must be the best.  Is this the best I can get in the way of Internet connectivity?  Well, we’re America, what we have must be the best right?  WRONG.  While most households in the US contend with sub-5Mbps connections, many of the so-called broadband connections still being sub-1.5Mbps connections, users in places like Japan are enjoying 100Mbps to their residences.

It is my opinion that, since most users in America have not experienced what real, true, high-speed broadband connectivity feels like, they are content to enjoy their current sub-par speeds, naively believing that this is as good as it gets.  Were these users to experience what true fast broadband felt like, even for a short time, they would begin to clammer for that level of service from American broadband providers.  As it is now, those providers are perfectly content to sit on their laurels, not having any driving force for real innovation.  Some ISPs have begun to come around recently.  Verizon, for the most part, started by rolling out its FiOS fiber optice service, the service that I use and love.  This service began offering not only higher speeds, but higher quality.  Connections that didn’t cut out at all times of the day and the capability to actually sustain a download at or near the full speed of the connection were a welcome change for these users.  One other feature of the service that was unheard of at the time, but extremely welcome by people like me, were much higher upload speeds.  Even now, it’s not uncommon to find the uplink speed of a broadband connection set at 512Kbps or worse.  FiOS offered an uplink speed of 2Mbps or better.

Other ISPs are starting to come around, but the going is slow.  Comcast, for instance, is rolling out speed increases to many of its users.  Prior thinking on speed must be rethought.  Previously, uplink speeds were kept low.  Some of this dates back to the A in ADSL, or asynchronous, meaning the uplink speed was lower than the downlink speed by design.  For newer broadband technologies, though, the speeds really need to become more synchronous.  We as a society are changing how we use our connections.  More and more of our lives and our businesses are online.  More importantly, more of our data is living in the cloud.  Cloud services are great for end users since they provide for more efficient use of available resources.  For cloud services to work, though, users must be able to upload their data to the cloud in a fast and efficient manner.  The success of cloud services really does depend on better broadband deployment.  As more of our communcations depend on broadband connectivity, that connectivity simply must become better, faster, and more stable, and ISPs’ feet must be held to the fire to provide users with the level of service expected of a utility service.

Next Saturday, March 22, a mere 11 days from now, the Intel Pentium processor will turn a grand 15 years of age. The Pentium marked a pretty dramatic increase in x86-based processor optimization capabilities, namely the introduction of multiple instruction pipelines. The optimization gains were so much so, that many software packages don’t usually enable CPU code optimization beyond the standard 386-level 32 bit code until you get to the Pentium/i586 architecture.

The age of the Pentium CPU was quite astonishing for me to realize. I remember our family purchasing our first Intel-based PC in 1993 with a 486 CPU. At the time, the Pentium was brand new. Those who were involved in the computer industry during this transition to brave new CPU-worlds will remember that the original Pentium chips, running at a blazing 60 and 66 MHz, had numerous heat issues. The 486 and earlier CPUs of the time did not have the heat dissipation issues that the Pentium chips had, so the older CPUs could usually get by with merely a heat sink attached to the chip. The Pentium was the first real introduction to computer enthusiasts of the requirement for not only a heat sink for the CPU, but a fan for active cooling of that heat sink as well.

Continuing in our early-to-mid-nineties throwbacks, the Pentium Pro will turn 13 in November of this year, reaching CPU adolescence. The Pentium Pro itself may not have seen wide adoption among computer enthusiasts, who instead opted to upgrade to the more consumer-friendly Pentium IIs, but the Pentium Pro left us quite a legacy of its own. The Pentium Pro ushered in the i686 instruction set, the prevailing 32 bit x86 instruction set to this day. The x86 instruction set would not see another serious upgrade until the release of the first x86_64 instruction set-based CPU, the AMD Opteron, in 2003. It would be approximately a year later before the first Intel CPUs sporting the new 64 bit architecture began shipping. It’s still amazing to me that the i686 instruction set, still the most widely used instruction set for x86 machines, is almost 13 years old. Around the time that Pentium Pro arrived on the scene, RISC architecture was becoming more and more prevalent, and the industry buzz was that RISC would become the architecture of choice, even for desktop CPUs. With the increasing optimization of the x86 architecture, including the inclusion of several RISC principles in the CPU, the i686 instruction set has lived on, and pure RISC has all but become a thing of the past, relegated to niche sectors of the computing world. Of course, the most recent, and high profile, casualty of this is the switch Apple, Inc. made during the 2006 year from its previous PowerPC based machines to its current Intel-based machines.

The first real usage of a brand for CPUs by Intel, the Pentium name is still with us to this day. With the introduction of the newer Core branding from Intel, the Pentium name has taken its place as the new moniker for lower-end processors from the silicon giant. Still, its been a great 15 years. Here’s lookin’ at you, kid.

I had reason recently to purchase a copy of Steve Gibson’s SpinRite utility to try to recover some data on a backup drive that went kaput. Since all of our workstations in the house are Macs, and I wanted to be able to let SpinRite perform its sometimes lengthy drive analysis without tying up any currently-running machines in the house, I decided to use a spare x86 server that had been sitting idle in our rack for some time. The machine itself was basically nothing more than the case, power supply, and motherboard (with on-board video and LAN). I didn’t have a spare CD drive at the time, and I didn’t really want to go buy one for this application, so I set out to run SpinRite the same way I install my server operating systems - via PXE. The one thing I did install in the system was a removable IDE drive tray, which allows me to easily install drives that I want to run through SpinRite (the “SpinCycle”? :)). I actually started calling this setup my SpinStation, since it turned out to be a very easy way to just pop a drive in and let it run. But I digress. It dawned on my while I was setting this up that organizations, including the ones Nearband Networks supports, may have good use for being able to boot SpinRite via the network. Imagine desktop support technicians responding to the call of a non-booting workstation due to a hard drive failure. Instead of having to carry a CD with SpinRite on it, they can simply set the machine to boot off the network, and let SpinRite run its course. Imagine the case of a server in amongst a rack of servers who’s hard drive has failed. Instead of having to remove that drive for testing, simply boot up SpinRite on the server from the network and let it do its magic. Finally, imagine performing maintenance (yes, as Steve Gibson is fond of pointing out, SpinRite is a drive maintenance tool just as much as it is a recovery tool) on a lab of machines. You could burn a CD for each system, run each system sequentially, or you could boot all of the systems from the network into SpinRite simultaneously and let them perform their maintenance overnight. These are some of the useful examples I was able to dream up while thinking about using SpinRite in this fashion. So, without further ado, on to how I set up SpinRite to boot via PXE.

PXE, or the Pre-boot eXecution Environment is an Intel standard on how to boot x86-based machines via the network. Many different system architectures through the years have had ways to boot from the network (Sun, Apple, etc). PXE is basically network booting for Intel-and-like-based machines. As I mentioned before, I use PXE to perform my server installs, usually Linux. If you’re familiar with the Windows way of doing things, then you may have used Remote Installation Services to install Windows over a network, a technology based on PXE. Most x86 systems built within the last 5+ years come with client-side PXE capabilities built in, especially if they have on-board ethernet, so chances are the systems you’re using now already support it.

Since my home network is Linux-server based, I already have the capability to boot via PXE. The basic requirements are DHCP and TFTP. I use the standard ISC DHCP server that is freely available and comes with most Linux distributions and the TFTP server that is included as well. In order to boot a PXE image off of the network, you’ll need to update your DHCP configuration to tell the client where your TFTP server is and what PXE image file to retrieve and boot from. Most DHCP servers are capable of sending clients the appropriate DHCP options to perform PXE booting with the appropriate configuration, but the specifics that follow will focus on the ISC DHCP server. For ISC DHCP to pass clients the necessary options, you’ll need to add two options to your configuration:

• next-server
• filename

The next-server option is followed by the IP address of your TFTP server, and the filename option is followed by the path to the file on the TFTP server. I use pxelinux to PXE boot my clients, and my TFTP server IP address is 172.16.24.1, so my lines look like this:

# For network OS installs
next-server 172.16.24.1;
filename "pxelinux.0";

Once you have DHCP set up to pass the appropriate bootstrap information, you need to configure pxelinux. Here’s where things get interesting. SpinRite comes with two image options: It can write out an ISO image or a floppy image for you. Normally, you’d use the images to create the necessary disks to run SpinRite from. With pxelinux, however, comes a very handy feature called memdisk, which allows you to boot a floppy image from the network, allowing you to take the floppy image written out by SpinRite, and use it directly with your PXE clients with no doctoring necessary. You’ll need to take the memdisk image and SpinRite images, and place them in the root of your TFTP directory alongside pxelinux.0. Next, edit the pxelinux.cfg/default file in your TFTP directory. If you have other network booting options, be sure to set prompt to 1 so that a prompt is displayed where you can type your booting option. You can also set up a boot message, which can display a menu of choices. Once you have that configured, add the following lines to the file:

label spinrite
kernel memdisk
append initrd=spinrite.img

When the spinrite option is invoked from the pxelinux boot command line, the client will retrieve the memdisk image and use it to then boot the spinrite.img file, which is the floppy image containing SpinRite’s FreeDOS and the SpinRite application.

That’s pretty much it. There may be some details left out, but most of those can be found from other PXE booting tutorials or the pxelinux documentation. If you’re feeling adventurous, you can even open up the SpinRite floppy image, using your image tool of choice, and make changes to the image, such as setting the auto option when invoking SpinRite from the autoexec.bat. This will basically make SpinRite a mostly hands-off operation (other than choosing to boot from the network and, optionally, choosing the spinrite boot option), as the machine will boot from the network and immediately begin checking all available drives in the system. Using this setup, I actually ended up testing every old and unused hard drive I had around the house, so that I could begin using them in my new Icy Dock external USB enclosure.

Finally, one last note. If you’re thinking about using this in a large organization, be sure that you pay attention to Steve’s modest site and enterprise licensing requirements.