October 2010 Archives

Bring on the Twins Redux

Joe Girardi

Image via Wikipedia

Now that the Bx Bombers have stumbled into post season, I have to share a few thoughts on their matchup with Minnesota. Before we get there, it is worth noting that the Yankees had a lousy September.  It is clear that the core 4 had various nagging injuries this year. The Bx Bombers are the oldest and most experienced ballclub in the post season. So, I was not surprised that manager Joe Girardi took great lengths to make sure key players were rested coming down the stretch. However, I'm not so sure that sacrificing the AL East Division crown was a wise choice. The Yankees have the second best road record in the AL, but they truly excel at home. Their murderous row lineup takes advantage of the short porch in left field.
I suppose that I should take solace in the fact that they will be facing the hapless Twins. At first glance, Yankee fans should be downright giddy. Somehow, I am not convinced that it will be a cakewalk. If there is one team that should be motivated to get a post season series victory, that would be the Twins.  The Bx Bombers have owned the Twins in both regular and post season match ups. One difference about the 2010 Divisional Playoff, Twins have home field advantage and they are not playing in the homerun friendly MetroDome.  I understand that  their new Target Field is quite cavernous. To succeed in that ballpark you must either be able to pitch well or dominant a week division. The Twins did both, thus they have one 6 of the last 9 AL Central Division crowns.  If the Twins are ever going to beat the Yankees, this would be the year.  The Twins have homefield advantage, and they are meeting a ballclub that has played horrendous down the stretch.  The Twins should be seething and really motivated to upend the champions. Especially since the Minnesota ballclub has been absolutely inept against the Yankees.

Perhaps the Yankees biggest issue is the starting pitching has been awful down the stretch. Outside of CC Sabathia, there  really has not been any consistency. The loss of Pettitte hurt the stability of their rotation. Before Pettitte suffered a groin injury he was 11-3 and probably well on his way to winning at least 15 decisions for the ballclub.  In his absence, the team used some journeymen (ie Mitre, Gaudin, Mosely) none of them did more than mediocre. It was difficult to watch their starts. Cashmen finally decided to promote from within, and gave young rooking Ivan Nova a chance. He looks to have a bright future, but might not be ready for the pressures of post season.  For the Bombers to succeed they must simply pitch well.
Timely hitting would also help their cause as well, take exactly what the pitcher gives you. The team has speed in Granderson and Gardner. If they both hit well in this series, you could really see them playing havoc on the basepaths.  I'm not certain that the Twins have a great defense, forcing them to make plays could prove disastrous.  At this writing, I have not seen Girardi's published pitching rotation. It would be safe to assume that AJ Burnett will be skipped in the short Divisional round. 

My pitching starting rotation is as follows -
Game 1 - CC Sabathia
Game 2 - Phil Hughes 
Game 3 - Andy Pettitte
Game 4 - CC Sabathia
Game 5 - TBA        

I have no idea who I would throw in a Game 5. Actually, I do not believe the series will go that far. If I did need a Game 5 starter I would like someone with experience in the postseason, obviously the pitcher with most post season innings is Andy Pettitte but you can't bring him back on two days rest!  This is why Girardi gets paid millions.  I chose Hughes as the number 2 starter because he has the knack for giving up home runs. Target Field is a huge stadium and it will help him. I don't think Girardi will start Hughes in Game 2.  I believe if the series goes 5 we'll see CC and Pettitte twice.

Regarding our hitting..  Robinson Cano has been carrying the club for most of the year. He basically has replaced Matsui in that 5 slot behind Rodriguez. He hasn't hit well in the post season for his career, but I think that will change. Hell if A-Rod could finally get the monkey off his back, why not Cano?  If Texieria, Cano, and Rodriguez drive in runs. The Yankees will be tough to beat. Pitching must hold the opponents to 2-3 runs, and let the offense grind. If their lineup truly becomes circular with Nick Swisher actually hitting in the 8th spot, the team will really flourish. Let's go Bombers !!  First pitch 8.37p EST





Death of a Brand

Mercury Logo

Image via Wikipedia

Ok.. The ubiquitous disclaimer - The following are my words only and not at all affiliated or endorsed by my employer.

Some have asked about the scuttling of the Mercury brand. If you care about the North American auto industry, you probably know that a few years ago, GM ended production of its Oldsmobile line. Earlier this year Ford Motor decided to do the same and officially end its longstanding Mercury product lineup.


I say officially, because it could be said that the Mercury brand was dead for several years prior to the official announcement. Why did Mercury die a slow death?


  • Product Differentiation
  • Complexity
  • Poor Demand

Perhaps the most obvious was the lack of differentiation between blue oval products. Arguably, this differentiation problem was a marketing decision and not an engineering one.

Complexity is always problematic when you are running a lean shop. The product development factory has drastically shrunk in size since downturn in the economy. The number of vehicles sold in North America has reduced considerably. Vehicle sales in North America have dropped to roughly 9 - 11 million over the past three years.  Since the demand for products have drastically decreased it only makes sense that brands that are not profitable be dropped.

Now lets look at some engineering challenges. Commonization is a term that is tossed around a great deal in PD factory. In layman's terms it means eliminate redundant parts. Utilize a common architecture whenever feasible. That is a common sense way of mandating that product development and manufacturing work from a common platform. Additionally, re-use the same fasteners, Powertrain components, stuff the customer will not see.  Though it sounds logical, execution of this concept is not quite that simple.  When you are trying to support the vision of three distinct brands, ie Ford, Lincoln, Mercury, people assume that there really must be a tremendous different between the brands.  Marketing sells this vision daily in its advertising campaigns, as a result engineering must deliver on that promise.  So you end up with unnecessary replicates of parts which serve the same functions, ie mirrors, visors, seat trim, etc.  Basically it really becomes waste when the customer is not getting additional value.  If customer are not willing to pay more for this differentiation, then you're wasting money. Who can afford waste in an ultra competitive landscape?  Besides the cost of managing multiple part numbers, you also have to store and sequence these parts. 

Because assembly plants have a finite amount of space on its manufacturing floor, OEMs typically outsource the handling of the parts to a third party.  This off-line handling is called sequencing. Once this third party handles the parts they are sent into the assembly plant for installation. All of this adds cost to the parts used to assemble a vehicle.

Now that "organic" demand for vehicles are down due to a very soft economy. We cannot consider "cash for clunker" sales because that generally distorts the real picture for demand. Consumers generally want a compelling value proposition when making a huge expenditure. If the perception is that Mercury looks and feels very much like the blue oval product you cannot expect incremental sales. Particularly in a down economy.

Lastly, there is the Lincoln brand that frankly needed attention.  Mercury essentially diverted resources that were sorely needed in the revitalization of the Lincoln brand. There are probably other reasons, but these appear to be the most obvious.  As the OEM attempts to absorb market share it cannot afford waste in any capacity.  Thus far, it seems to be making the more prudent moves when compared to its closest competitors. Time will tell..


The Slackware logo.

Image via Wikipedia

Roughly 3.5 yrs ago I purchased an Acer Aspire 5100. Initially, it was running Vista Home. I promptly wiped the hard disk and installed Debian/Stable. For whatever reason, I ran into some very weird kernel regression problems related to clocksource (TSC unstable due to cpufreq).  Finally got fed up and installed slamd64 (64bit slackware port). At that point official slackware did not exist on 64bit AMD or Intel. I believe the official Slackware64 port was released 5/19/09. Eric Hamleers and crew did an outstanding job.

So, earlier this year I began scouring the interwebs looking for clues on how to upgrade directly from slamd64 to slackware64. Typically, the "upgradepkg pkgtool" and glibc along with a host of base slackware packages "a - through - l" will do the trick. However, since I had already backed up the notebook there was no reason to play around with a live update. I wiped the disk clean and installed slackware64-13.0.  When I was running  Debian on that notebook, I ran LUKS (Linux Unified Key Setup) encryption on the /home and root files systems.  *Quick Aside* encrypted file systems are useful on your notebook computers.. It keeps people from getting at your confidential data..
Somehow, the Debian installer presents LUKS as an option during the install process. Though, some may see this as an advantage, I really never understood what was happening behind the scenes. I didn't realize that the /boot partition was not actually being encrypted (and for good reason).  LVM is fairly trivial to setup, in fact my notebook sports a modest 80GB disk so it is questionable whether I really need LVM.  Nonetheless, I figured that I could then be able to grow and shrink partition sizes with LVM installed. That could never be a bad thing :-)

After making the choice of running Slackware on the notebook, I used some very helpful README files. LVM and its LUKS companion. Unfortunately, I munged the install by incorrectly setting up initrd so that the bootloader LILO can boot the root filesystem.
For those unfamiliar with initrd, it is a temporary filesystem which loads specific instructions into ramdisk (ie kernel modules for hard disk, and file system, etc) to aid in booting the  Linux kernel.

Actually, in my earlier days of running  slackware (before the era of exotic hardware and large hard disks) I never needed initrd.  Somewhere around kernel 2.4.x I began using as Volkerding suggested it in the install README files.  Anyway, if you do not setup initrd correctly, you'll be greeted with a nice kernel panic :-)

How does one rescue their installation when this occurs? Here are some steps that should help. Once again, I was grateful for the help I received from alienbob   alienBOB on ##slackware.
Please be advised that these instructions are geared towards my setup.
For my LVM setup, I only had two volume groups.
I had chose not to leave one partition /boot (/dev/sda1) unencrypted and the entire root file system /dev/sda2 utilizes LUKS.  You must also remember to keep your LUKS passphrase in a safe place. Perhaps store it on an encrypted USB keychain or simply in your brain.
If you forget the LUKS passphrase, you will have to wipe the hard disk and re-install your operating system.

Do the following -
Boot your system with the Slackware install CD/DVD (actually any linux distro live CD should work)
Run 'fdisk -l' to view your partition table
cryptsetup luksOpen /dev/myrootfs cryptslack
Respond with your LUKS passphrase
vgscan --mknodes
vgchange -ay
Run 'ls -la /dev/cryptvg'
lrwxrwxrwx  1 root root    24 2010-09-25 08:27 home -> /dev/mapper/cryptvg-home
lrwxrwxrwx  1 root root    24 2010-09-25 08:27 root -> /dev/mapper/cryptvg-root
lrwxrwxrwx  1 root root    24 2010-09-25 08:27 swap -> /dev/mapper/cryptvg-swap
Now we'll mount the LVM partitions and setup our chroot environment
The chroot environment is necessary for us to correct the initrd setup on our native root file system. Remember that the installer has its own rootfs, /etc/fstab , etc.. If you're unclear about chroot. I'd recommend reading up or using the ubiquitous GOOG search.

After running 'ls -la /dev/cryptvg'
mount /dev/cryptvg/root /mnt
mount /dev/cryptvg/home /mnt/home
mount /dev/mybootpart  /mnt/boot

All of your LVM volume groups and boot partitions should now be mounted. Next we must setup our chroot environment..

mount -o bind /proc /mnt/proc
mount -o bind /sys  /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt              --> gets us into chroot

While inside chroot ::
vgscan --mknodes
vgchange -ay

At this point you should be able to see your installed slackware root filesystem. Be sure to check out the /etc/lilo.conf and the filesize of initrd.gz.  My clue was that initrd.gz was a mere 20kb. This told me that initrd was not built correctly.

So to fix initrd do the following:

mkinitrd -c -k 2.6.29.6 -f ext3 -r  /dev/cryptvg/root -C /dev/sda2 -L -o /boot/initrd.gz 
Of course replace with your actual Linux kernel version number and using the explicit path to mkinitrd would be wise too. Take a look at man mkinitrd to decipher the parameters.

After rebuilding mkinitrd check the timestamp and filesize of /boot/initrd.gz.
They should be different from your originial initrd.gz

After you again check of /etc/lilo.conf for errors (pointers to correct boot image and initrd.gz) Run '/sbin/lilo -v'
type exit to leave chroot
reboot..

All should be well again.. If all went well, after your reboot, you should be prompted for your LUKS passphrase. If not rinse and repeat ;-)










Ode to the ARM

If you haven't been living under a rock the past few years, you might have noticed a growth in marketing of smartphones.  If you have not noticed the television marketing of the dominant players which use Android and iOS, various social networks are also buzzing with this marketing. Besides the wrangling of hobbyists and loyalists, we also have financial pundits weighing in on the debate. People seem to praise that Cupertino company for its inroads and its supposed stance on HTML5 standards. Now that the H.264 is being provided royalty free, it changes the game somewhat. You will begin to see more of those one purpose commodity flip video recorders, which only encode H.264. I digress and will expound on this point in a future entry.

What I find most interesting about the ARM architecture (Acorn RISC Machine) is that it challenges the duopoly of Intel and AMD (Much like Linux and BSD has done in the desktop and server markets). For the sake of argument lets assume that there are virtually no other players in the CPU space at the moment. Having said that the dominant players are fixated on the desktop and server markets. 64bit architecture is becoming increasingly popular, despite the fact that most programs that you'll find on the garden variety desktop computer are still 32bit.

Anyway, Intel and AMD abandoned the low power applications for quite awhile since there was not a great deal of profit margin. ARM has been around since the 80's, well before set top boxes or mobile devices became common place for consumers. Low power and extended battery life are some basic tenants of the ARM architecture. Additionally, developers get the added benefit of working with essentially "royalty free" architecture. The latter is the "killer" feature, that makes it very difficult for the incumbents to compete. Simple RISC instruction set coupled with developer friendly licensing schemes. Wait there is more..

Because RISC has been around for quite sometime it is well understood, thus Unix and Unix-like operating systems thrive on this platform. Though ARM has made incremental changes for performance, everything is well documented standards based engineering.

Obviously, ARM isn't perfect because people still complain about battery life. I would suggest that until we discover how to reconstruct matter.. Well basically there is no such thing as a perpetual heat engine, thus we'll likely be complaining about battery life for quite awhile.  ARM still beats Intel and AMD quite easily when you begin battery life and heat dissipation.  Perhaps if I get some time I'll share some of the benchmarks which can be obtained rather easily on your local Interwebs.

Personally, I have three ARM devices. Let's count them.. Linksys NSLU2, Nokia N800, and Nokia N900 (Cortex). How many do you own?


Monthly Archives

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 4.25

About this Archive

This page is an archive of entries from October 2010 listed from newest to oldest.

September 2010 is the previous archive.

November 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.