The Achilles Heals of Technology

We’ve definitely come a long way.  Enormous strides, year over year.  But some pains remain in our way of getting to the ideal operational efficiencies:

Allocation – It’s still hit-or-miss with so many variant species of installers.  Some products throw components on a computer like a blind drunk person with a shotgun having a spastic seizure.  The CoApp project is probably the best idea to come along since the dawn of Windows.  Sadly, it will probably be ignored by Microsoft. (yes, I know it’s derived from Linux and open source, shadddup!)

Permissions – There’s still too many stupid-ass vendors making crappy products that “require” the users to have Administrator rights.  HIRE NEW PROGRAMMERS you idiots!!  It’s not that friggin hard.  Lock yer shit down!

Licensing – I can’t even count how many variations vendors use today for controlling where their products can be installed and used.  License files.  Registry keys.  Services.  Hardware “dongles”.  Static keys.  Derived keys.  Concurrent acknowledgement services (think FlexLM and FlexNet) and on and on.  If only there were a real “standard”.

Isolation – App-V, ThinApp, XenApp, SVS, etc. are all fantastic ideas.  Where the **** are they?  Yes, I know they’re “available”, but so is medication for dying children in the poorest of places.  The problem is (a) it’s too expensive, (b) difficult to deploy, and (c) still too complex to manage for the laymen of the world. Until this technology is bundled into the core OS products, we will have to suffer with DLL conflicts, shared services, side-by-side assembly caching, versioning, re-basing, redirection and bullshit packaging hacks.  Come on.  This is 2010, right?

Layers – It’s still too friggin complicated to use MDT or OSD or SysPrep or imagex or whatever to build and deploy large numbers of computers in an automated fashion.  Drivers are a pain in the ass.  Custom tweaks are still cumbersome.  Task sequences are nice but still quirky.  The whole process needs to be thought through from scratch and simplified.

Software Packaging/Sequencing Sucks

Yes. It's true. Shocking to many of you, but absolutely true.

I said "Packaging/Sequencing" which are slightly different things. For those of you not familiar with application virtualization technologies like Softgrid, "sequencing" is similar to capture-method packaging, where you essentially roll-up a state change from a baseline environment, and make it a package for deploying to other computers. Simple enough.

Unless you have to deal with Adobe products.

Oh my God. No. Let me put that in a more technically credible form: Holy fucking shit, is more like it.

If you work for Adobe, I'm sorry. But you really need to walk over to the developer team and knock on their door. When the door opens, just smile, and then punch them right in the face. Don't forget to say "Merry Christmas" afterwards either.

Why? Why so violent? Why such disdain for such nice, sweet people like Adobe?

Because they refuse to get with the program. Which program? The program titled "Software development and packaging for the 20th century". (keep in mind we're in the 21st century - ponder that for a few seconds, ok?)

If you package software for a living, primarily for the purposes of mass deployment in an enterprise environment, you will already know this and be simply fast-forwarding on to the next blog post. For those of you dealing with "sequencing" for Softgrid, ditto. For the rest of you, maybe you're an Altris, or SMS 2003, or System Center Config Manager, or Tivoli, or whatever administrator, who cares, the point being you're not a day-to-day packager, so you need to know just how badly Adobe sucks at making software easy to deploy. Let's just say that they don't.

In fact, Adobe makes it as f-ing difficult and painful to accomplish as humanly possible. I wonder if they have an entire department or division, dedicated to making mass deployment impractical and problematic.

It boils down to how they ship their software in the first place. While many vendors, from Autodesk, to Symantec, to whoever, provide you a neatly packaged MSI with all sorts of documentation to help you drop that into a Group Policy, or SMS package, or Altiris, or (holding my breath here...) Softgrid, Adobe does not. They give you an MSI alright, but it's not packaged properly to allow for such silly things like saving time and avoiding problems. No time for that stuff. Profit comes first (and only).

For those of you that have suffered with Adobe's crap while trying to sequence for Softgrid deployments, well, I cry with you and gladly hand you the liquor bottle. It turns out they never read the memo on how to base DLL's on Windows clients. They still do it the 1980's way: Push them all to one base address and ask Windows to dole them out on the memory stack, each and every time you launch the application. Goddamnit! F-you Adobe! Stupid. F-ing stupid!

Thankfully, the folks at Softricity (now Microsoft) thought enough of us whipped and beaten packagers (oops, sequencers), to add that nice little checkbox option: "Re-Base DLL's" for just such purposes. If you haven't tried this feature, give it a try. I would suggest that if you have any sequenced applications which make you sit there for 15 minutes while they drollingly iterate a shopping list of DLL's they load before you can start using the application, that you make another sequenced package using the Re-Base option and compare the results on some test clients.

You may often find many applications launch dramatically faster after they have been processed to re-base the DLL's. This is simply because they're asking Windows to do the chore once, and then capture it for future loadings. Do it once. Yes. What a fantastic idea. I suppose Adobe wouldn't consider doing something dumb just once. No, they'd rather do it EVERY SINGLE TIME they launch. Thanks Adobe. Merry Christmas.