Don't Shoot Yourself In the Foot!(Protecting 'Nix mount-points)

One of the big differences between Windows and the various 'Nix flavors is in the way it handles mounting logical/physical drive volumes.

Windows uses "Drive Letters", (C:, D:, etc.), to distinguish between mounted drives.  Because of this, it's relatively easy to know where one drive or partition ends and another begins as they are shown as separate, distinct entities.

On the other hand, 'Nix uses "Mount Points", ("/mnt/foo", "/mnt/bar", etc.), to distinguish between mounted devices.  Because of this, devices, data-sources, or whatevers, appear as if they are a part of the local, physical hard drive - yet can be located on a different partition, different hard-drive, a different computer, or it could even be located in an entirely different part of the world.

The way this works is like this:

• You create a physical directory where you want your data-source, (hard drive, partition, etc.), to appear; such as "mkdir /mnt/foo" where "foo" is now an empty directory located within "/mnt" (or wherever you want to put it).
• You then actually put the physical device on top of the mount point by "mounting" it:
  Viz.:  "mount [something on] /mnt/foo"

And Voila!  Whatever data, device, or whatever exists at or within "something" magically appears at "/mnt/foo" replacing whatever was already there.

Are warning bells ringing yet?  They should be. . . . .

What this means is that - if you change directories to "/mnt/foo" - you have no way of knowing if your [something] is, or is not, mounted there by simply looking at the directory.  That is, unless you just happen to know what's supposed to be there. . . .  An assumption I'd really hesitate to make if I were you.  Especially if you are starting out with an empty "something".  Or if the errant user thinks he is starting out with an empty "something". . . . .

What this also means is that shell-scripts, (batch files for all you Windows aficionados), have no way of knowing what's there, or what's supposed to be there, without you telling them somehow.

(OK, OK!  There are special commands that you can run to find out what's there, or what's not there - but they are not always easy or intuitive, and it's really easy for an unknowing user to dump stuff into a mount-point that's not mounted yet.  Go ahead.  I dare you.  Ask me how I know. . . . .)

What Unix should do is make un-mounted mount-points un-writable in the same way that Windows/DOS doesn't allow you to use a drive letter that is not yet mounted.  But it doesn't.  Any Tom, Dick, or Harry can blithely write into an un-mounted mount-point, causing no end of confusion.

Solving the Problem:

Obviously what is needed is some way to show when the directory you are using as a mount-point - isn't mounted.  And the hint on exactly how to solve this problem is given by the problem itself.

If you remember, when you mount something on top of a directory, (which, by the way, is the way it works), whatever was in the directory prior to being mounted disappears, replaced by whatever you mounted there.

The fix is to deliberately put something in the mount-point directory - prior to something being mounted there - warning everybody that whatever is supposed to be there, isn't there yet.

So. . . . this is my fix:

From a root terminal - or sudo root. . . .

• I create the directory where I want to mount something.
• I deliberately "touch" (create, with nothing in them) two bogus files with warning file names:
  Viz.:
  touch 'Do Not Use!'
  (and)
  touch 'Not Mounted Yet!'
• I then "chmod" these two "files" to 644 - making them read only to everyone but root.

(Note that the single quote marks are not a mistake.  You need to use them to include the "!" character in the file's name - as normally the "!" is a "magic character" in 'Nix.)

With this, there is no possibility for mistake.  Anyone who goes to that directory, expecting something to be there, instantly knows that - whatever it's supposed to be - it isn't there yet.  And depending on the system - and their relationship with it - they can either go "Oops!  Forgot to mount my. . . .", or put the Sysadmin wise that something isn't exactly kosher in Denmark.

What say ye?

Jim (JR)

The Cost of Complacency

I spent most of today replacing the front brake pads on my wife's Lexus that we had bought in 2005 or thereabouts.  Not only were the fancy aluminum rims frozen fast to the steel of the disk-brake rotors due to the electrolysis of the dissimilar metals, (nothing being done to prevent it), the calipers and especially the caliper supports that hold the pads in place were unbelievably rusted.  The rotors themselves were so badly rusted that the polished brake surface was actually peeling off the rotors, exposing the rusted and pitted metal below.  These parts had been replaced a year ago by the dealer.  One year later they needed replacing again.

Now we also have a 2002 Camry, and I've done brake work on it before - and yes, I've seen rusty brake parts there too.  But!  They were never as badly rusted as the parts I saw today - even after years and miles of use and abuse.

A friend of mine bought a Yaris for two reasons:  First of all, it was manufactured by Toyota, the Reigning Gods of Automobile Manufacturing,  Secondly, the price was right.  Of course, being manufactured by Toyota, it walks on water and talks to the angels.  Right?

In his case, the car has been one expensive repair after another and he has made a Holy Vow to never darken the door of a Toyota dealership ever again.  Especially since the Toyota people near him have been absolute models of diplomacy and tact.  (/sarcasm!!)

Of course, all three of these cars were manufactured and sold before the Toyota Recall Debacle.  The Camry was, and still is, one heck of a car.  It's within spitting distance of 200,000 miles on the clock with 'nary a burp to sully its pristine reputation.  The Lexus, manufactured two years later, has been a hole in our driveway into which we have been pouring money.  And my friend's Yaris, purchased even later than the other two, is rapidly on its way to being inducted into the "Five Gallons of Kerosene and a Match" Hall of Fame.

Then came the problem of "sudden unexplained acceleration."  And depending on who you talk to, it cost lives - people who died in crashes attributed to that fault.

Toyota was God, so Toyota had become complacent.

So, what happened to Toyota?  Nowadays many people are thinking a second, third, and maybe even a fourth time about trusting Toyota again, and for the first time in it's long history Toyota has been posting sales losses rather than gains.

---

In the same vein, the exact same vein as a matter of fact, General Motors all but literally owned the automobile marketplace years ago.  They became complacent, and they reaped the rewards of their complacency.  General Motors all but vanished off the face of the earth - and would have vanished without a trace - but for the massive Government bail-out they received.

---

Digital Equipment Corporation - in it's time - had virtually the entire mini-computer market in its back-pocket.  Being Gods in their industry, they became complacent.  Look where they are today.  Or rather look where they aren't today, having withered away to nothing long ago.

---

In the '60's, NASA was GOD when it came to technical innovation.  They had the world by the balls, and the sprinkles on top of the cherry, on top of the whipped cream, on top of the icing, on top of the cake was landing a man on the Moon.

When the Apollo 13 mission was rapidly going down the toilet, the three astronauts on that mission were in such deep trouble that, (in all probability), even Lloyd's of London would not have insured their lives.  Thanks to the incredible ingenuity of the people on the ground at NASA they made it home, in record time, with 'nary a scratch to show for their harrowing adventure.

Having gained the high ground, so to speak, they became complacent - embroiled in political turf-battles that sapped the energy and vitality out of that agency.

Where are they now?  On the peripheries of space technology; so far out of the picture that they depend on the Russians, French, and Chinese to get payloads into space.

---

The United States, once the Gold Standard for innovation, has become complacent since we - obviously - had the entire world by the Short Hairs.

So, what happened?  A recent article on the subject of innovation and its relationship to the economy quoted an independent analysis of the inventiveness of various countries - and guess where the Good 'Ole U-S-of-A ended up on that list?  In the highly prestigious position of being number eighty-one.

That's right, kiddies - in 81st place, right behind Dilbert's famous Country of Elbonia.

And it would not surprise me if position number 81 is even lower than Iraq and Afghanistan's position on that list.  Compared to China?  Fuggeddaboutit!  We're not even in the same Solar System they're in.  We have even dropped below our former Arch Rivals, the Russians, and are probably being outpaced by some third-world countries as well.

---

There's a saying:  "If you always do what you've always done, you will always get what you always got."

Unfortunately, that's not true anymore.  If you "always do what you've always done" what you "always get" is to be rapidly left behind by those companies, agencies, and governments who still have the wisdom to encourage, (and fund!), innovation.

Complacency cost Digital it's entire company.

Complacency darn-near sent General Motors to the same fate.

Complacency cost Toyota dearly in that most precious of commodities - customer trust and loyalty.

Complacency has cost the United States not only it's position in the world, but has wrecked more havoc on our economy than ever since the Great Depression, and has placed our National Debt squarely in the fists of the Chinese.  And God Himself help us should the Chinese decide to "call" on even a fraction of the paper they hold.  We'd deflate faster than a pin-pricked balloon. . . .

Complacency costs.  Dearly.  Tragically.  Even Globally.

What say ye?

Jim

Hot Smokin' Weapon! Award for May 2011:EasyBCD by NeoSmart

  . . . . And a Big HELLO to all my friends out there in Television Land!

I have decided that it's time for another one of my famous (sort-of) "Hot Smokin' Weapon!" awards.

And the lucky winner is. . . . . . (Envelope please. . . .rrrrrrip, shuffle, shuffle - pregnant pause)
NeoSmart Technologies and their EasyBCD product!  (Enthusiastic canned applause. . . .)

Seriously now, EasyBCD is one of those cute little utilities that really should have been included with Windows Vista, 7, etc., because it's so darned handy and useful to have.  In a sense it's a lot like sex.  If you've never had it, you don't miss it - but once you've gotten it you wonder how you ever lived without it.  Not only is it so darned useful that, (IMHO), it should be standard equipment on modern computers, it is also absolutely free.  Yea, I know - I can hear the yawns already - however try not to fall asleep before I finish here, you'll be glad you stayed awake - Promise!

To really appreciate the magnitude of EasyBCD's contribution, we need to take yet another Stroll Down Memory Lane. . . .

The earliest versions of both DOS and Windows - up until about the time of Windows '98 - use a hard-coded boot "pointer" in the Master Boot Record, (MBR), of the hard drive to tell it where - on that particular hard drive - the boot and start up files were so that it could get the computer up and running.  The advantage of this system was that the boot process is a trivial exercise:  Follow The Yellow-Brick Road and you eventually get to Oz.

If you've been paying attention, you will see the big, glaring, disadvantage of this boot method.  It assumes that any bootable operating system is on the first hard drive in the logical chain - which, by the way, is the only one that would boot natively.

If you wanted to boot to a different partition on the first, (root), hard drive, you'd have to re-create a new MBR that points to the partition to be booted.  If you want to boot to an entirely different hard drive you'd have to, (somehow or other), change the logical order of the drives to make the new drive the root drive in the logical chain.  (And then muck around with the MBR!)  Both of which, (as many a user will tell you), are among the fastest ways to bork a system into utter oblivion unless you were particularly careful.  And lucky.  And had backups.

In order to make these additional partitions - or disks - bootable without having to hack the MBR, (Yow!), or fuss around with the logical sequence of the drives, (Say WHAT?!), whenever someone wanted to change the boot order; people were forced to purchase specialized applications, (like System Commander), that could show them a menu of bootable operating systems and let them pick the one they want.  It was a hack, but it was a hack that actually worked and people gladly shelled out their hard-earned pesos to buy these utilities.  These utilities, because of what they did, were also fraught with danger.  I can personally testify that if you screw up just THIS MUCH. . . . Well let me just say that it wasn't a pretty sight.

Starting with Windows NT Microsoft worked out a way to fix this problem by providing a "boot.ini" file in the root of the first logical drive that was used to boot the system.  The function of the boot.ini file was to tell the system what operating systems were installed and on which disk and/or partitions they could be found.  Creating a multi-boot environment became as simple as editing the .ini file.  No hack required!

Of course, making things that easy for the end user goes against Microsoft's Corporate Policy, so they fixed that with the release of Vista by scrapping the boot.ini file in favor of a special, hidden, "database" called the Boot Configuration Data (BCD) store.  Supposedly, this was done to support an entirely new boot paradigm called the Extensible Firmware Interface (EFI) - something that may well become significant when 3 terabyte (+) disks become more common.

The end result of this was to make changing the boot process virtually impossible without using a Microsoft Supplied Utility called BCDedit.  BCDedit is a pure command-line tool and is about as obtuse and cryptic as Egyptian Hieroglyphics, thus giving Microsoft the lead in the mad rush to make boot configurations as insanely difficult to maintain as possible.  (Though Grub2 is a close second, with FreeBSD and Solaris right behind them.)

Enter NeoSmart and EasyBCD.  EasyBCD transforms the management of the BCD store from alchemy and fervent prayer to something as easy as a point-and-click interface.  With this you can make a nice little menu for yourself with each bootable O/S listed - without having to jump through flaming hoops or do the high-dive into a cement filled bucket.

You can change the existing boot order around, add or remove operating system boot entries, change which O/S boots by default - along with tweaking all kinds of interesting parameters - like creating an "if all else fails, this should boot" entry in your O/S list.

Probably one of the best features of this utility, (IMHO), is that it allows you to make BACKUPS of your finely tuned boot sequence - just in case!

Even more useful is that the latest versions allow you to make a bootable "recovery" USB stick with EasyBCD on it, to help you in those cases where an operating system install has hijacked your carefully crafted boot process and stubbornly refuses to let you get it back.  Or even provide a workable substitute.

Now, admittedly, there are some things that EasyBCD can not, and will not help you with:
If you decide that you're crazy enough to mess around with, (or actually re-arrange), the logical volume GUID's, (Yikes!), or you're maddeningly insane enough to hand-edit the drive's MBR and partition tables to change the logical order of the partitions on the drive, (Double Yikes!!), EasyBCD can't help you.

For these tasks you need particular and specialized tools, a double-shot of fine Kentucky Sour-Mash Bourbon, And a straight-jacket!

For everything else related to booting, EasyBCD is the obvious winner.  So much so that, (surprise! surprise!), even the folks at Microsoft use it instead of their own tool.  Which should tell you something about both EasyBCD, and Microsoft's BCDedit utility.

P.S.  Just in case you missed the cleverly hidden hyperlink at the beginning of this article, you can go check out EasyBCD right here:  http://neosmart.net/dl.php?id=1   I'd do it if I were you.  You really will be glad you did.

What say ye?

Jim

I've Got a Tiger in my Tank!

No, this is not an Esso/Exxon commercial.  (Of course, you do realize that I am severely dating myself with that reference!)

Neither is this a commercial for Mac's OS-X.

Instead, this article is about a little known - and probably even less often used - SATA drive mode called AHCI which stands for "Advanced Host Controller Interface".  There's even a nice Wikipedia article about it that goes into all the gory details if you're interested.

AHCI supports all kinds of fun features like the ones listed below.
(Taken from the AHCI Spec - Rev 1.3, available on IBM's web site here.)

AHCI specifies the following features:
• Support for 32 ports
• 64-bit addressing
• Elimination of Master / Slave Handling
• Large LBA support
• Hot Plug
• Power Management
• HW Assisted Native Command Queuing
• Staggered Spin-up
• Cold device presence detect
• Serial ATA superset registers
• Activity LED generation
• Port Multiplier

The support for port multipliers is important, especially if you want to get a nice shiny new External SATA RAID box - as most of them require port-multiplier support nowadays.

The large LBA support is especially important because it allows you to connect HUGE drives to the system - and the staggered spin up helps avoid smoking your computer's power supply when you fire up that monster 32 drive array!  Though you would hope that any array that size would have its own dedicated power supply, right?

There are - as always - a couple of flies in the ointment:

• Many self-booting utilities, (like Apricorn's hard drive backup/cloning software), haven't even thought of AHCI, let alone support it.
• If you're running anything older than Vista or a Hot Smokin' Linux Kernel, fuggedaboutit!  Don't even try.
• If you ARE running Vista or better, (trust me, anything you might be running is much better than Vista!), or a Hot Smokin' Linux Kernel - and didn't install with AHCI enabled at initial install time - when you change to AHCI and reboot, your computer is liable to look at you with a puzzled expression and ask "What's a Cubit?"

I have no idea how to mitigate this in Linux as I have neither tried it, nor have I researched it.  On the other hand, Microsoft has already released a Knowledge Base Article describing the registry hack you must do - before making the switch - to clue your computer in on what's about to happen.

All in all, especially as multi-petabyte RAID arrays become common attachments to the average X-BOX game console, AHCI is going to become increasingly important.

What say ye?

Jim