How to Not Suck at Scripting, Part 1

I hear this ALL OF THE TIME from IT guys who have somehow not caught the script-writing bug: "I wish I knew how to write scripts". Usually it's followed by a deep breath, a sigh, and staring off either up into the ether, or down at the ground.  I'm here to tell you how you can find that bug, and make it bite you in the ass. This is Part 1 of a 2-part article.  This part will focus on the "why" aspects.  Part 2 will focus on the "what" and "how" aspects.

The Basic Basics

First off, before I get into the enumerated list, I have to explain what is this thing we call "script-writing" or "scripting".  A "program" or "application" generally implies, or denotes, program code that has been compiled into a new binary file that can be executed by the operating system, or by another (aka "host") application.  A "script", on the other hand, is generally *not* compiled into a new (i.e. binary, hex, octal, whatever) file, but left "as-is" in the original "source code".

Source Code is the stuff you type with your own sweaty, trembling Red Bull-infused hands.  If you use something like Windows Notepad to open a program file, and you can actually spot words or phrases in your native language (e.g. English, German, etc.) it's probably either source code or script code.  If you open it in Notepad and it looks like the following crap, it's probably compiled code.

MZ
(*&(#*$)@&)#($*@&#$*&^(000011100-11)!00*!&^0010010101100011100(*&@#][}{}\?<>??::^!@~&^%&^0111011010101001]]]

The simplest giveaway is the file name extension.  I'm not going to back to 101 level stuff here, but you should have a clue that .EXE files are programs or applications, while .BAT, .VBS, .JS, .PS1 and .PY are usually script files.

One important thing to remember is that while there are many scripting languages, they are all basically serving a common purpose:  providing a low-cost, low-complication resource for system admins to automate tedious or repetitive tasks.  Sure, some languages offer more robust features for certain tasks than others, but in the end, it's a matter of matching up the tools for the jobs.

This discussion dovetails a bit with my recent post titled "Why Every SysAdmin Should Learn to Write a Script", however, this one will go in the direction of establishing a few basic technical ground rules.  Stay tuned for more... :)

Read More

Another Book Announcement and More!

I've just published another book!  Yes! I know exactly what you're thinking:  "What the...? Why do they let him keep doing this?!  Have they no mercy upon our eyeballs?!"

Well, in the interests of science, humanity, environment and the ever-pressing need to keep gasoline in the tank of my car, I've decided it was time to pull together as many of the mindless stories I could from my old-as-dirt years working in the world of IT.  That was a very long run-on sentence.  My high school English teachers are probably rolling over in their graves right now.

There's also quite a lot of blabber about how I got into the world of IT and how I swam through the sea of CAD into the ocean of Infrastructure Management and Software Development. It really is fascinating.  Not how I got into IT, but the fact that I could construct a sentence that almost sounded coherent.  Wow!

What's this New Book All About?

The new book is called "You're Only as Good as Your Last Mistake".  Sub-titled "25 Years of Boneheaded Reflection and Stupid IT Stories to Dull your Senses".  It's a blending of a little biographical nonsense, some seriously pretentious pontification, some articles adapted from my blog (this blog), and stories about things going bump in the electronic night. I suppose it could be called a BioTechieHumorFailDisasterFest.  Uhhh.  Yeah.

It's available on the Amazon Kindle store in every country where Amazon can sell books (US, UK, France, Germany, Italy, India, Japan, Spain, Canada and Brazil, as far as I know).

Here's the GOOD NEWS!

• It's only $2.99 (USD) and whatever that translates to in other currency
• Don't have a Kindle?  No problem.  You can download a FREE Kindle Reader app for iPhone, Android, Blackberry, Windows Phone, Windows XP/Vista/7/8, Mac OS, and ...
• You can read Kindle books online in almost any web browser using the Kindle Cloud Reader!
• If you are an Amazon Prime member, you can "borrow" eBooks, including all of my eBooks, for FREE!

What's the Catch?

• I only ask a small favor:  It's a BIG favor for me, and a small effort on your part, but I really would appreciate honest reviews of my books.  If you've purchased, or borrowed, any of my eBooks and actually read them (without pausing in the middle to stab yourself in the eyeballs with a fork), please go to the Amazon web site for the book(s) you've read and submit your opinion on them?
• You can start at my Author Profile page to make it easy.
• Thank you!

Sample: "Where it All Began: From Doritos to Digital Ships"

"Chronologically it's weird, because some of those jobs were in parallel with others.  For example, in that maze of titles I managed to fit in roughly five good years of rock and jazz band, but whatever. I also weaved in about ten years of artwork (painting, drawing, squishing clay stuff around, and so on) which never earned me more than "Hey man, that's cool!"  I remember responding a few times with "Cool enough to buy?", and the response to that being something like "Yeah! By somebody.", but somehow "somebody" could never be found. 

Sometime in early 1984, Mark, one of my brothers stoned friends, walked into our kitchen while I was maniacally inhaling a bowl of Fruit Loops (my favorite cereal at the time).He stopped at the doorway to exclaim "I got a job, dude!" to which we all replied with stunned silence.  I decided to inquire, saying something intelligent like "Oh yeah? What?"  

He explained that he was hired as a "Naval Designer" at a local Naval engineering firm, and went on to indulge us in this magically mysterious thing called "benefits", and something even more interesting, called a "salary". If I hadn't grown up in a Navy town (okay, a Navy "region"), I would have assumed a "Naval Engineer" designed belly-button replacements or something. 

Most of what Mark said was really fascinating, even though I could barely hear his muttering over my own cereal-chewing noise.  The best way to describe him is to think of someone who looks, sounds, and acts a lot like Jeff Spiccolli (Fast Times at Ridgemont High), only not as funny, has a mustache and wears glasses, coming in and telling you he was hired at an engineering firm.  You get the idea. 

Somewhere towards the end of my bowl of cereal Mark said something that perked my ears up.  I think it was something he mentioned about there being more positions needing to be filled, and that they paid pretty well. As it turned out, there were roughly twenty openings for "Drafting Apprentice" jobs, so I ran down and applied.  After a short interview ("Can you hold a pencil, boy? Alrighty! You is hired!"). 

I was finger-printed, scanned, questioned, photographed, probed and stamped with a badge and told to show up at 7:30 AM the following Monday.  That led to five or six years of my work as a Drafter/Designer in the U.S. Naval engineering field." 

Sample above (C)2013 David M. Stein, All Rights Reserved. May not be reproduced or copied, transmitted, in whole or in part, for any purposes or derivative use, without explicit written consent of the author (me). And let's face it: If you're so desperate that you'd consider copying this literary fast food schlock, well, you may need some serious medication already.

Read More

Automation Potential - If Only...

After years (too many to count, or even want to count actually) of working in the IT field, I've come to realize that 99 percent of what holds back businesses, schools, organizations of all kinds from achieving even minor automation benefits from the tools they already have at their disposal is their own lack of leveraging some of their most basic features.  If only...

1. The "Managed By" field for User accounts were populated consistently in Active Directory (AD).  
2. Computers were named consistently with respect to function and disposition using parse-able syntax.
3. The "Location" field were filled out consistently for Computers, and Printers in AD.
4. The "Description" field were not only paid a little attention, but used consistently in AD.
5. A little time were set aside to clean up File shares and storage folders.
6. A basic set of tools were included in the base image of every desktop and laptop computer.

Filling out the 'Managed By' field for user accounts makes it easy to generate automatic organization charts using Visio or other chart tools.  With Visio you can not only automate the org charts, but automate publishing to an intranet location.  The "managed by" association can also be used to automate workflow operations in all sorts of applications, such as System Center Service Manager.

Note: Even if you don't use Exchange or any internal e-mail system, filling out user account fields makes it easy to automatically generate look-up tools for finding employees by name, location, title, department, and more.

When computers are named with a parse-able syntax, it opens the door for all sorts of automation tricks.  From automatic naming processes during MDT and OSD provisioning, to Group Policy targeting (WMI-filtering, etc.), to scripting, to inventorying, to whatever.  A parse-able name is one that is constructed by concatenating codes that represent specific attributes.  

For example "SVDB10012" might represent "Server", "Virtualized", "Database Role", asset number "10012".  Another example might be "DNVA4034" to represent "Desktop computer", "Norfolk, Virginia office", asset number "4034".  The potential code schemes is limitless, as long as you don't violate DNS or WINS naming limitations.

One customer I've worked with uses a scheme similar to the following (modified to protect the innocent, of course):

Device Code: 

D = Desktop
L = Laptop
T = Tablet
M = Mobile device / Smartphone
S = Server

Functional Code:

P = Physical
V = Virtual
C = Cloud hosted

Location Code:

NN = Office location code (numbers or letters)

Asset Code:

nnnnn = 5-digit asset number assigned in inventory and purchase tracking system

Additional "codes" might include organization (division, department, etc.), project or program association, security category (classified, non-classified), regulatory compliance scope (SOX, HIPAA, etc.), shared usage (kiosk, conference room, etc.), infrastructure role (telephony, scanning, CAM operations, etc.), and so on.  You can use these codes to control script behavior, Group Policy filtering applicability, OSD task sequence automation, AD queries, inventory reports, and on and on.

Whether you use Symantec Ghost, MDT, Configuration Manager OSD, or some other tool to prepare, maintain and deploy a "standard" operating environment for your desktops, laptops and tablets, don't forget to include some basic tools to help with troubleshooting and even client-side automation.  Some suggestions might include a few Sysinternals utilities, Trace32 or CMTrace log viewers, Intel or AMD processor diagnostic tools, and so on.  You don't have to do this if it doesn't benefit you, but if you discover that you've been copying certain apps or files to computers each time you troubleshoot problems, you might want to consider making those items part of the standard installation.

I'm not suggesting that you should immediately run out and start doing these things.  I am only suggesting that you stop and think carefully about how you are managing things now, and what you could do to make it possible to automate certain tasks later on as a result of the work you put in up front.  If you make some small changes now, it can open up incredible potential later on for automating tasks that otherwise can be very difficult and time-consuming.

Read More

Why Every SysAdmin Should Learn to Write a Script

I'm a bit overdue for a perceptual conceptual brain-twisting deep-dive article, and caffeine seems to always push me in that direction, so it was time.  And besides, I've been torquing my brain to the limits working a huge article series for 4Sysops on Troubleshooting Configuration Manager clients.  On top of that I'm in the final throws of my next book, and no shortage of "real" work at the office to contend with, and trying to maintain sanity with four kids still at home, and well, it'll be worth the wait, but I may need a stiff drink when it's wrapped up.

So, without further adieu...

Why the Title?

There's no shortage of articles, blogs and whatnot that tout the "benefits of scripting and coding" for anyone who spends time on a computer.  Okay, maybe they're mostly aimed at those who earn a paycheck spending time on a computer, but that's okay too.  Most of the articles I've read however seem to focus on the benefits of automating common tasks, as well as extremely difficult or complex tasks.  That's fine also, but there's more to it than that.  Much more.  To me they're kind of missing the main point:

Writing a script teaches you a particular way of thinking.

Sure, automating tasks pays pretty well, but there's more to be gained by an everyday computer technician from learning to write even the most basic script. One of the main reasons, indeed THE reason, that I chose the title for this article has nothing to do with automating tasks at all. Let us drink the Kool Aid of digression and digress with me for a bit, mmkay?...

A Different Kind of Thinking

Writing software code, whether it's to be compiled or interpreted, involves a process of thought.  Granted, there are some variations of the thought process as it pertains to a particular programming language, as well writing functional, procedural or object-oriented code, but the process itself; the process of telling the computer to perform certain actions, remains.  It's a logic process.

If This is True: Do That  /  Otherwise: Do something else...

Disregarding semantics for a moment, the flow of logic is roughly the same whether you work with C++, JavaScript, LISP, Python, Ruby or whatever.  Picture the following example scenario:

Task: Instruct a Robot to retrieve a box of cereal from a cabinet on the other side of the room.

That sounds easy, right? "Hey, robot.  Get me the box of cereal."

But the robot doesn't move.  It needs to be told:

• where to go
• how to get there
• what exactly to retrieve
• how to actually retreive it
• where exactly to go next
• how to go to the next location
• when to perform each step

The only basic questions it doesn't absolutely need to ask are the who and why aspects. For now, anyway.  Let's ignore the possibility that it's a super-advanced robot that understands these things. Let's instead go with a robot that was just born and has to be taught like a baby human would.  These steps come with a few qualifying pieces as well:

• where to go: relative to current location
• how to get there: walk, roll, crawl / turns, ascentions (climbs),descentions, and distances
• what exactly to retrieve: which object(s), means for identifying or locating
• how to actually retreive it: grasp, slide, push, pull, tip, scoop / carry, store, clutch
• where exactly to go next: relative to current location
• how to go to the next location: walk, roll, crawl / turns, ascentions (climbs),descentions, and distances
• when to perform each step: now/immediate, x minutes/seconds from now/from previous step

It should make you pause for a moment and begin breaking down the sequence of tasks in detail:

1. Turn [n] degrees to your [right/left]
2. Move forward approximately [x] feet and stop
3. Turn [n] degrees to your [right/left]
4. Move forward approximately [x] feet and stop
5. Raise arm upward to [x] degrees from default position
6. Extend arm forward [x] inches
7. Grasp cabinet handle
8. Pull grasped handle, swing arc to [left/right] until door is opened [x] degrees from starting position
9. Release handle
10. ...

You get the idea.  Those of you that have actually programmed machines like this already know that I'm glossing over a lot of detailed steps in between.  This is actually the basis for how a programming language is developed: step by step, nouns and verbs. Then come the adjectives (gently, loud, etc.), until the language is matured enough to accomplish the general class of tasks it was intended to address.

Side Note: When asked "what is the best programming language?" the answer is: "There is no such thing as a 'best programming language'".  Every language is better at some particular tasks than others.  A programming language is a tool.  A tool is a means for accomplishing one or more tasks. Each tool is conceived and built to address a particular set of tasks.   

Contextually, some languages are "better" to master with regards to job opportunities or specific projects.  From a technical point of view, the concept of "better" depends on specific comparisons of individual features as they align with a set of specific tasks which are to be accomplished.  The more general or multi-purpose capability a particular tool becomes, the less specialized it becomes at the same time. 

That was a lot of mumbo-jumbo, sheesh.

You may start letting your mind wander into additional challenges, like navigating stairs, odd angles, and so on.  Hopefully another thought crossed your mind: How much we, as human beings, take for granted this little stuff.  Imagine what someone fighting through physical therapy has to deal with as they learn to walk or speak again following a major injury.

In most respects, this way of thinking forces you to shoehorn your intentions into the mouth of the beast we call a computer. The point is that when you're forced to structure your thinking in someone else's terms, it also forces you to think more clearly about what it is you're trying accomplish.

In many respects, it forces you into a serialized or sequential mode, even if your goal requires solving parallel processes.  You have a Start and a Finish.  A beginning and an end.  Initialization and termination. An Alpha and an Omega (for you religious folks, a little humor, pardon me). Regardless of having to contend with seemingly random or asynchronous sub-tasks, the overall context has (or should have) a defined start and end.  If you're looking to run a program that just goes off and does a bunch of unrelated things; does a lot of unrelated and undefined things, and never ends, that's been done already: It's called politics.

Let's put this into somewhat of a "real world scenario" for a  moment. A

Example: Finding all Files in a Folder that Contain a Particular Text Value or Numeric Pattern

This is a very common task indeed.  Whether it's finding documents that contain a reference to a particular contract number, or data files that contain a numeric pattern, or sales records with a particular date, log files that include a specific name or code, the logic for pursuing the answer is pretty much the same.  What differs is the trivial stuff like formats, locations, and the periphery like environment and concurrency limitations.  I say "trivial" in the sense that those are relatively less important than the primary goal being sought.  I'm fully aware that in many cases those so-called "trivial" extraneous things can become the biggest headache to deal with.  Okay, enough blabbering from me.  Let's dissect this creature...

What are we trying to accomplish here?

1. We need to identify what we are looking for: ____
2. We need to identify where to look for it: ____
3. We need to identify what to do when we find it: ____

There are millions of other things we can do, and may need to do, in addition to these basic questions, but in most cases these are the three most important questions to answer.  You could boil them down into two primary categories: Target and Action.  What is the target and What action do we take on it (or because of it)?

For this example, we'll keep it simple and go with the following parameters:

Find all instances of the text value "CNX-10114025" within all of the documents contained in the Folders located on server FPS0025 under the shared folder root of "Contracts".  The target UNC path then becomes "\\FPS0025\Contracts".  Maybe a quick inspection of the folder structure reveals that there are nested folders which will need to be scanned, as well finding that there are an assortment of file formats to be found:

• Microsoft Word, Excel, of various versions (.doc, .xls, .docx, .xlsx, etc.)
• ASCII Text (.txt)
• XML files
• HTML source files
• PowerShell scripts (.ps1)

You probably stared at that list and immediately began to think through the process for opening, reading, and parsing each file type.  You're already staring at the trees, let's get back to the forest.

Here's what you should have thought:

1. Access the root folder
2. Look for files in the root folder
3. Check each sub-folder
4. Look for files in each sub-folder
5. Check for the next level of sub-folders
6. Look for files in each sub-folder
7. Wash. Rinse. Repeat

An average programmer or scripter (script-writer? script-kiddie? I can never figure out what the proper term is anymore) would get to step 4 and immediately blurt out "Recursion, bitches!" and then quiet down after realizing they just upset everyone else in the library.  I happen to be sitting at a table in our "central" public library actually, so that's why I made that connection.  I haven't blurted out anything yet though.

Forget recursion for the moment; stay focused on the forest.  The trees will come later.  And, yes, I know that the preceding sentence is completely illogical, let's keep moving along...

Are you seeing the process yet?  If you're following along with my mindless rambling, you're probably nodding in confirmation of understanding that you have to think it through in an orderly fashion.  The key here is "orderly" (i.e. sequential.  serialized.  linear).

Side Note: Yes, I know that there are non-linear, amorphous, parallel and even polymorphic/non-linear/parallel problems to be solved, but this is Dave 101 and that course isn't until next semester (if ever).  Context is everything.  The context here is: how does writing a script benefit a systems administrator who's never considered writing a script before now.

Pseudo-Code to the Rescue

Most programmers will have likely put there head into both hands and moaned at reading that line above.  The prevailing view of pseudo-code is that it's for beginners.  Noobs.  Training-wheels.  And in some respects that's true, but it works. No reasonable programmer or scripter can argue that writing pseudo-code is detrimental to anything besides (A) their ego and (B) their time.  I've seen it used by some of the best and brightest programmers when conditions were sufficiently warranted.  What did that mean?  I mean that when faced with an incredibly complex task to accomplish, pseudo-code can help map out the primary steps and it can bring clarity to the major components of the impending code to be written.

What is Pseudo-Code Anyway?

Rather than explain it, I'll just show it:  First, here's a chunk of actual program code...

If Not amx_InstallRegKeyExists ( regKey3 ) Then
   dPrint "info", 0, "AMX is not installed. Proceeding with install sequence."
   If Not amx_PreReqsFound ( arrReqIDs ) Then
      dPrint "info", 0, "Installing AMX prerequisite components..."
      p1 = amx_InstallMissingPrereqs ( arrReqIDs, False, vbMinimized )
   Else
      p1 = True
      If amx_InstallSequence ( arrAppIDs, False, vbMinimized ) = True Then
         p2 = amx_InitRebootSequence()
      Else
         dPrint "error", Err.Number, Err.Description
      End If
   End If
Else
   dPrint "info", 0, "AMX is already installed. No action required."
End If

Now, let's write that in pseudo-code:

1. If application "AMX" is NOT already installed (then...)
1. install prerequisite software items
2. install AMX application
3. check that everything installed properly
4. reboot the computer
2. Otherwise (else...)
1. nothing to do, exit cleanly

That's it.  Pure and simple. Now, the question you may ask is "Hey, dumbass: where do I buy a book on this 'pseudo-code' programming language?".  You don't.  You can't.  There's no such official programming language by that name.  It's a term used to describe the writing of program instructions in human-readable terms. It's like a "faux diamond", "pleather jacket", or an "honest politician". It's "fake". The word "pseudo" means "not actually, but having the appearance of...", or fake, so you get the picture.

Master or Commander?

Am I saying that you need to spend a lot of time mastering the art of writing scripts?  No.  I'm only suggesting that learning how to write even one script successfully will help you in the long run.  It's sort of like walking a mile in the computer's shoes.  I'm not going to trick you and deny that writing scripts isn't both addictive and lucrative.  The more you write the more tasks you'll think of to use them on.

Pointers

Some of the sites I look to for help and inspiration when working on new scripts (if I don't have code laying around from twenty years of tinkering with it):

• Microsoft TechNet Script Center
• PowerShell.com
• Rob van der Woude
• PowerShell Code Repository
• ss64.com 
• Dr. Scripto's Script Shop (Microsoft)
• MSDN VBscript Language Reference
• MSDN ADO Code Examples
• ActiveXperts.com

Read More

What's On Your Desktop?

I got into a brief, but interesting discussion about what applications certain IT folks typically have open at ANY given time of day.  More specifically: if you were to guess as to what you'd find if you were to walk up behind various staff members, and see what apps were opened on their desktop(s), how accurate would your prediction be.

Here's what I almost always have open on my dual monitor setup at work:

• Google Chrome
• Internet Explorer 9
• Microsoft Outlook 2010
• Microsoft System Center Configuration Manager 2007 admin console
• Microsoft SQL Server 2012 Management Studio
• Microsoft RSAT: Active Directory Users and Computers
• VMware Workstation 9
• AdminStudio 11.5 / InstallShield 2012 (depending upon workload)
• TextPad 6
• Paint.NET
• Several CMD consoles

At home, from my laptop (usually on the couch):

• Google Chrome
• Microsoft Word 2010
• Microsoft PowerPoint 2010
• Microsoft Outlook 2010
• VMware Workstation 9
• PowerShell ISE
• Several CMD consoles
• TextPad 9
• Paint.NET
• iTunes 11

Read More

Why I Haven't Bothered with HTML 5 Much Yet

I'll let the pictures do the talking this time...

Read More

How Old is a Computer?

Let's pretend it's exam time, mmmkay?  Goody!  I know you're jumping out of your seat with joy right now, so let's begin.

Scenario:  You're at your office desk on Monday morning, giggling out loud while reading the latest Dilbert strip on the web, when your phone suddenly rings. You normally ignore it, but the LCD (ok, maybe you have Lync alerts enabled) shows "CIO" is calling.  You sip your coffee/RedBull/Monster/hot tea/etc. and swallow before answering.

You: "Systems Engineering.  You stab 'em, we slab 'em.  How can I help you?"

CIO: "I need a report that shows how old each computer in our organization is, sorted by the oldest at top.  How soon can you have that to me?"

You: "Uhhhhhhhhh....."

You pause and realize you have Microsoft System Center Configuration Manager 2012 SP1 installed and everything is working smoothly, including inventory and reporting.  Then you realize that "age" isn't so clear cut of a thing when it comes to computers.  To avoid sounding like an idiot, you respond with your usual clever answer:

"I think I may have what you need, but let me verify anyway and I'll get back to you as soon as possible.  Would that be okay, [sir/ma'am]?"

CIO: "That's fine.  I'll need an answer before the board meeting at noon."

*click*

Question:  What is the most reliable method of determining the "age" of a given physical computer (server, desktop, laptop, tablet, etc.):

1. The install date of the operating system
2. The BIOS firmware date
3. The dateCreated property of the Active Directory account
4. The Purchase Order (PO) date
5. The manufacture's model sticker on the back/underside of the box
6. The CPU version information
7. The motherboard version information

Answer:  __ ?

4. The Purchase Order (PO) date

Unfortunately, options 1, 2, and 3 are easily changed by routine processes in the environment.  Option 5 isn't accessible from a programmatic (e.g. WMI, SNMP, etc.) perspective.  Options 6 and 7 don't necessarily indicate an aggregate "date" on which the computer began "life" (whatever that's defined as being).

That leaves option 4.  If your purchase order and invoicing system is online (rather than paper), and you have the means to tap into its database, you could run some queries and get what the CIO needs.  If the database is linkable to the Configuration Manager site database, you can do some SQL "joins" to leverage the goods on both sides of the aisle.  This makes for an easy CIO-pleasing result.

If your PO system is paper-based, or isn't accessible to running custom reports, well, you may be shit-out-of-luck.  But all is not lost!  If you stop and think about who was responsible for requesting the shitty, inefficient PO system for the organization, and that person is not on your list of friends, it could be an opportunity to play the office politics game and toss out one of those "See! I told ya so!" cards and call for a show of hands.  Then again, you may simply be shit-out-of-luck, in which case, you might want to finish your drink, take a deep, slow, meditative breath, and call the CIO back with the not-so-good news.

It's surprising, to me anyway, how often this situation arises.  A "computer" device isn't as monolithic as a human in some respects, which may sound really strange and ironic. A human has a single "birth date", which can be verified via a birth certificate, passport, military I.D., or driver's license.  A computer starts off with a duality of hardware + software, and even then, some of the hardware isn't so hard-coded (firmware updates).  If only computers had a singular, reliable, consistent "birth certificate".  Imagine what the little inked foot prints might look like. :)

Read More