AIX Commands Vol. 1

Seagate announces 750GB hard drive

As I was writing my previous post regarding my defunct 20MB Kyocera hard drive, I received news of a technological breakthrough regarding hard drives. Segate has introduced the Barracuda 7200.10 family, built on perpendicular recording. The first drive will have 750GB capacity and will sell for $559.
Read the news release

IBM PS/2 Problems

I decided to work on my IBM PS/2 Model 30 computer over the weekend, and to my surprise I started having problems with the system's 20MB hard drive. I ran DOS 6.22 Scandisk only to find out lots of bad clusters. The hard drive had reach the end of its life. Here are some details about this drive:

• Brand: Kyocera
• Model: KC-20B
• Capacity: 21.4MB
• Access Time: 65 ms
• Rated Voltage: 12v,5v
• Serial Number: KB2089589
• In Operation since: December 1988
• Interface: MFM (Modified Frequency Modulation, yes way before IDE drives)

This is a memorable little drive from a company that has long since exited the business. These days, Kyocera are a major manufacturer of laser printers, but it's a long, long time since they made a hard drive. Still, at least with this particular model Kyocera were obviously successful as a drive manufacturer: KC-20s were quite common in their day and remained around as valuable trade-ins well into the early Nineties.

Like so many early drives, you could recognise the KC-20 by sound alone — something you almost never get with modern drives. The sweet little high-pitched pinging noise the Kyocera's seek mechanism made was unique. In practical terms, the drives themselves were nothing out of the ordinary: reasonably reliable as MFM drives went, a little on the sluggish side, not very different to a half-dozen others of the same vintage. Good bye friend!

More information on MFM technology http://en.wikipedia.org/wiki/Modified_Frequency_Modulation

Apple Introduces 17-inch MacBook Pro

Apple unveiled its new 17-inch MacBook Pro notebook computer featuring the Intel Core Duo processor and an all new system architecture that delivers up to five times the performance of the PowerBook G4. http://www.apple.com/macbookpro/

Shipping Software by Mark Lucovsky

A few weeks ago I had lunch with the now famous "Mark Jen". I never knew Mark while we were at Microsoft, even though we both worked in the same group. Funny how large groups at Microsoft can get...We had a great Google style lunch at a sunny table in Mountain View. I was too dense to notice that Mark was doing research for his blog. One thing he said got me thinking... Something that many have said over the years, that Microsoft "knows how to ship software". Being a 16 year Microsoft veteran, a Distinguished Engineer, key architect and code writer for windows, architect of the largest source code control and build system ever attempted, I deeply believed that Microsoft knows how to ship software. We know how to build it, test it, localize it, manufacture it, charge lots of $$$ for it, etc.Mark and I talked about this briefly at lunch that day, and I have been thinking about it from time to time since...I am not sure I believe anymore, that Microsoft "knows how to ship software".

When a Microsoft engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? I know the answer and so do you... The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will "ship" meaning that CD's will be pressed and delivered to customers and OEM's. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date.

In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM...Consider the .NET framework for a second. Suppose you wrote something innocent like a screen saver, written in C# based on the .NET framework. How would you as an ISV "ship your software"? You can't. Not unless you sign up to ship Microsoft's software as well. You see, the .NET Framework isn't widely deployed. It is present on a small fraction of machines in the world. Microsoft built the software, tested it, released it to manufacturing. They "shipped it", but it will take years for it to be deployed widely enough for you, the ISV to be able to take advantage of it. If you want to use .NET, you need to ship Microsoft's software for them. Isn't this an odd state of affairs? Microsoft is supposed to be the one that "knows how to ship software", but you are the one doing all the heavy lifting. You are the one that has to ship their software the last mile, install it on end user machines, ensure their machines still work after you perform this platform level surgery.

When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn't have to lift a finger. Now that's what I call shipping software.I would argue that Microsoft used to know how to ship software, but the world has changed... The companies that "know how to ship software" are the ones to watch. They have embraced the network, deeply understand the concept of "software as a service", and know how to deliver incredible value to their customers efficiently and quickly.