I think a far more interesting thought experiment would be to determine the longest running machine. I imagine something hooked up to a windmill or waterwheel.
Thoughts?

Did people have the same dilemma with developed photos when they were first becoming widespread? You put it on your mantle beside the family portrait. You give it to a loved one. Give it to a blind friend in wallet size.

When my mother in law first heard about 3D printers and this type of technology, she wanted to run out and buy a 3D printer so she could make a family 'portrait' of statuettes. She still doesn't understand that she also needs a 3D scanner, not just a 3D printer...

I concur. Use the cheapest long term storage media and have multiple copies. In keeping with your current strategy, acquire two portable fire-proof safes that only you know how to open. Keep your original data at home, put each safe at a friend/family member's house. Now you have three copies of your data in three locations. If one copy ever becomes damaged, take immediate action to replicate an existing copy to a new 3rd location.

Perhaps my language did not clearly convey reality. Let me provide an example. Version X is released on Jan 1. Probably will not ever be installed (see below). Version X.1 is released on Mar 1, might get installed, but not before Nov; for this example let's assume that patches keep coming. X.1.2 comes out May 1 - still not installing it, yet. Jul 1 comes around, if the features in X are absolutely required, and we've had it in the lab, and the customer acknowledges that we are not responsible should the product not perform as documented, we'll install it. Again, let's assume it's a no-go. Sep 1: X.1.3 comes out, we'll aim to install it in November, along with any patches and hotfixes listed in the latest release notes. Bottom line, major release X comes out in January, we'll probably not be running it before November.

Prime example, Windows 2012 began rollout on production servers in January 2015 and we'll have >2000 installs by the end of June. My job is to make sure we never have more than 24 hours data loss on any system, can't do that unless I'm sure the product performs as advertised. In my line of work, there's nothing worse than being told every job/transaction completes successfully but it turns out the data is unusable or empty.

For most of the software I use, a major release X is two digits, such as 5.2, 5.3, and 5.4 or 7, 7.1, 7.5 and 7.6 - each is a major release in its own right, so I'm dealing with 7.6.0.4 or 5.4.5. We're finding that, where in the past the product usually went GA as 7.1.0 with a few hotfixes for corner cases, 7.6 didn't go GA until 7.6.0.1, and the vendor is recommending to skip straight to 7.6.1. When it came time to install 7.5, you needed to install the 7.5.0.4 patch before starting the application. Another example, 5.5.0 isn't GA yet and they're up to 5.5.0.9. One of my colleagues in a different business unit installed RA 5.5.0.4 at the vendor's direction for case resolution, and he was hit by a bug that caused a complete filesystem panic and 18 hour service outage.

below:
Now, to put some real world application to your original statement... Can you name any major release of commercial software that needed 0 or 1 patches? Anything from Microsoft, Apple, any Linux or BSD distribution, Solaris, AIX, HP-UX? Anything from NetApp, EMC, Cisco, Brocade, SAP, CA, Google, Symantec, Mozilla, VMWare, CommVault, Oracle, IBM, McAfee, MySQL, Sybase, Apache? These are the major vendors I deal with. The reality is that software products have become so complex that the vendor cannot test every use case before releasing the product, and invariably GA releases are getting buggier and buggier.

My leadership team fully supports my position - and I wasn't even the one to come up with it. I just live(work) by it. Maybe the leadership team of one of the world's top 100 sustainable corporations are all "fucking incompetent", but I think you're the outlier in this case.

About beta....
My hard and fast rule is at work, not at home. Yes I used beta software on a personal device that is not used for any primary function. It's not my only tablet and its far from being my only computing device. There is nothing unique on it, I have good, complete, tested backups both locally and off-device, and I thoroughly studied and understood the roll-back process before starting the install. I had relegated that device to lab/disposable status when I did the install. That said, the beta label from PA isn't the same as beta for other products, i.e. Windows. Once PA makes a stable release, that's it, they're not updating that branch ever again and have moved on to other Android releases. Windows OTOH, once the product goes GA, they keep patching it.

I'm not sure you have your facts straight.

https://source.android.com/sou...
Code name Version API level
Lollipop 5.1 API level 22
Lollipop 5.0 API level 21
KitKat 4.4 - 4.4.4 API level 19
Jelly Bean 4.3.x API level 18

http://en.wikipedia.org/wiki/A...
Latest release 5.1 "Lollipop" / March 10, 2015; 32 days ago

^^ - if the last number is not a 3 or greater -

for all the pedants out there, like me.

I have a hard and fast rule at work: unless it's a real lab device, never ever ever install anything that has been out less than 6 months and is not on its 3rd patch.

It doesn't matter how much a customer wants (read: is willing to pay for) a feature that's out in the next release, if the product version is X.0 or even X.4.0 - if the last number is a not a 3 - I'm not installing it unless I've had it in the lab for 6 months and have thrown everything I can think of at it, including production size load & stress testing. Normally when they find out how much that lab costs they back down. The lab I have cannot provide a production sized load so its basically useless beyond functioning as a classroom for new features.

I have a Nexus 7 (tilapia) and it got Android 4.4.4 loaded in January. It's actually ParanoidAndroid 4.6 beta 6, which I read as 4.6.6. That beta was released on Nov 3rd, it was the 6th patch so I only waited 3 months. Before that I was running their stable release 4.45, which I installed 1 month after its release. Before that I was stock.

Give him one of these books and tell him if he wants to play a game he has to transcribe the code first:
http://www.atariarchives.org/b...
http://www.atariarchives.org/m...

That's how I got started, and around the age of 7 too.

Oh, and wait a year or two before you teach him how to save the code onto audio cassette... Ya know, cause you don't trust him yet not to overwrite a previous save.

According to Google: "define expert"

noun
noun: expert; plural noun: experts

        1.
        a person who has a comprehensive and authoritative knowledge of or skill in a particular area.
        "experts in child development"
        synonyms: specialist, authority, pundit; More
        adept, maestro, virtuoso, master, past master, wizard;
        connoisseur, aficionado;
        informalace, buff, pro, techie, whiz, hotshot, maven, crackerjack
        "she is an art expert"

adjective
adjective: expert

        1.
        having or involving authoritative knowledge.
        "he had received expert academic advice"
        synonyms: skillful, skilled, adept, accomplished, talented, fine; More

This sets the bar pretty low IMO. I am an authority on programming among my peers (application, database, system and storage administrators) - I guess that means I get to vote exspurt.

Although I choose to be a backup administrator, my education was in data communications programming, and my first foray into programming was in the mid 80's. I can still hold my own in C and Java, assembly is a challenge, I can debug C++, I regularly use debuggers to trace closed software and figure out what's going wrong at the application level, and I'm not shy to say I've mastered shell scripting and perl. I remember feeling like I reached a new level when I wrote code that would output code that would build batch scripts. But I still only consider myself advanced because there's whole paradigms that I've not been exposed to; and today programming is only a hobby.

I disagree. The day will come where most consumers will have zero control over the machines they purchase. Meanwhile, I can still roll my own on open hardware or Arduino or Raspberry Pi ....

Most consumers will buy their Chevrolet or BMW with the factory tuning and safety features, or even Volvo without any hood to open. Meanwhile, many hobbyists still build their own kit cars, dragsters and swamp buggies.

Most people are happy to put their money in a national bank in a no interest chequing account, while others invest directly with startups.

  Every option will still exist as long as someone wants it bad enough to do it themselves or pay someone else. Each option will exist in proportion to size of the demographic wanting it.

I too voted other for King Julien.

I voted other because I couldn't decide which type of problem to speak to.

Most occurrences is storage, however god damn ATI cards having such narrow support... Piss me off to no end. First was a dual GPU rage 128. Worked fine in Win98. Odd frames rendered on GPU0 and even on GPU1. When Win2K came out, default VGA crap only, no 3D. Linux was worse. A few years later, got me a shiny TV-Wonder, didn't work after my next OS upgrade and again shitty Linux support. Those are just the main examples.

I've stuck to Nvidia for the last 6 PCs and I'm not switching no matter what specs or benchmarks AMD has.

There are ways to express tone in written communications that are as effective as audible or postural tone, but they take practice. When I was a junior specialist, during a performance review, my manager said that I can come off as gruff or standoffish in my emails. I took the criticism to heart, the issue was resolved within a year. Now (10 years and 4 managers later) my annual performance review regularly includes a comment that my written communication skills are one of the biggest assets to the team.

I:
- stick to facts,
- provide references and explanations,
- clearly identify what is a personal opinion;
      - limit these to technical recommendations,
      - provide justification,
      - acknowledge other possibilities and opinions, with benefits and consequences of each,
- make a draft, leave it for at least an hour, read it aloud before sending,
- review and revise the recipients, To and CC
- include anyone mentioned in the message
- use "and" and "&" to avoid ambiguity in lists [e.g. "two pairs: red & blue, and green & yellow"],
- limit numbers as identifiers or quantities, spell out the number otherwise [e.g. "The five of us found three values: 10, 4 and 7"],
- avoid "not" as it is often missed, speak in the positive [e.g. "Please use the green button" rather than "Please don't use the red button"],
- when it is impractical to speak in the positive, clearly identify the negative word [e.g. "Use any button EXCEPT the red one"],
- avoid "you", "I", "he", "she", etc. This is a rule in documentation, with flexibility in correspondence [rather than "I always do this in documentation, and less in correspondence"].

I like to use numbered lists; it helps further down the line when referencing what was said earlier. I rarely use bullets, usually when there are few, equally weighted points. I normally put each point on its own line but sometimes will offer two or three options in a single sentence [e.g. You can either a) do this; or b) do that].

I once read an article that explained how to reduce or eliminate superfluous words. If done right it can make the message easier to follow, less personal, and avoids different interpretations "I really think you should, at most, do X because Y" -> "Do X because Y". To take one of your sentences as an example: "The other alternative is to hold the short meeting, agree on what you can and summarize it in a short email after the fact" -> "The alternative: 1) hold a short meeting, 2) reach an agreement, and 3) send a summary in email". Appendix 1 of http://www.dtic.mil/whs/direct... provides some great examples:

Military writing guides and styles are a great resource for improving written communications. They must be clear, concise and accurate for orders to be followed correctly.

Other References:
http://www.dailywritingtips.co...
http://en.wikipedia.org/wiki/S...
http://www.armywriter.com/army...
http://www.bizmove.com/skills/...
http://www.mindtools.com/pages...

Others have made similar comments such as "Depends"... I think "right tool for the job" says it best, and normally a complex job requires multiple tools.

My MO is usually:
1. Email to get the subject started, identify objectives.
2. Verbal/in person to give everyone a chance to ask questions and weigh in, followed up with meeting notes/minutes to summarize decision made.
3. Chat/IM for quick questions or coordinating a few people with order dependent tasks.
4. Direct phone call to handle complex questions.
5. Email summary after milestones.
6. And of course, document everything along the way.

In person conversations are rare because my team is spread out nationally. I normally work from home but once every few weeks I go into the local office with a few people from different teams that have the same set of responsibilities but for different business units and customers.