Installer Sizes

[mattgoff]

OK, I've vented on this before, but I just have to get this out again. We're on 9.5.1. I ran into a replication bug, but for once there's already a fix for it. But, I have to go to 9.5.2 FP2 HF7. To do this I have to download:

• 9.5.2 installer @ 691MB,
• FP2 installer @ 685MB, and
• HF7 loose files @ 21MB.

So nearly 1.4GB to fix my one bug. Oh, and I have seven servers with a mix of 32 and 64 bit, so double that to get my IBM download and multiply by seven for the amount of traffic I have to pass over my WAN. Let's just say that the pipe size between SF and Sydney means this upgrade isn't happening today....

In theory I could log into IBM from every server and use Download Director to get it kinda fast, but a) with very few exceptions we don't run Java on any of our servers (for obvious, Zero Day, reasons) and b) logging into PA for 9.5.2, FixCentral for FP2 and Boulder for HF7 is even more painful than waiting for the internal transfers to complete-- at least they're fire and forget.



Matt

[mattgoff]

Surprise! 9.5.2 FP2 HF7 contains a replication bug that, as usual, didn't show up in test! Spent all day today (Saturday) on it, just gave up and started a rollback to 9.5.1. Getting all seven servers buttoned up (to square 1, that is) should pretty much wrap up my day.... I think I'll save my full writeup for next week-- I'm not sure anything I'd write now would be SFW.

BTW, in desperation I checked out 10.1.1, thinking: in for a penny in for a pound. *Each* Installer is 2.4GB. Each. Installer. <deep breath> And, inexplicably, a .tar.gz instead of .zip.

[Andy Key]

Just wait until you need a 10.x hotfix. Use of the pretty installer (cos copy and paste from zip files is far too hard and way too fast) bloats your 20-30MB of zips to (for 10.1 FP 1 HF2) 300MB for BI Interop, 300MB for TM1 Client and 450MB for TM1 Server. 1GB. For a Hot Fix.

[mattgoff]

I never bothered to look, but here are the (uncompressed) directory sizes for 9.5.1:

• x64 server: 203MB
• x86 client: 199MB
• tm1web: 48MB

Installers:

• x64:545MB
• x86:558MB

Digging into the subdirs on x64:

• API: 6MB
• axajre: 72MB (AFAIK, nothing but LDAP)
• bin: 44MB
• bin32: 9MB
• custom: 17MB (I still haven't figured out how to skip installing files/service)
• doclibrary: 53MB (bring back the PDFs)
• license: 2MB (thank goodness I have access to the terms in Turkish)

I assume the rest of the installer is contributor which we don't use/install. Seems like I only "need" about 10% of the current installer. Who knows what makes it another 5x bigger with v10....

Maybe most people don't care. They suck up the one-time download, upgrade their one server, and move on. I'm probably I'm a special case with my seven servers, but the inefficiency here is just ridiculous and, to me, is another demonstration of the lack of customer focus and usability.

Matt

[George Regateiro]

You are not the only one. Considering across all our environments we have to do the install 14 times for various pieces (not including clients) it is a pain. Then the tar inside of the zip thing is amazing (or what ever order it is). The 2 gig download because 6 when I have to unpack it twice and then clean up after it.

[Alan Kirk]

Maybe most people don't care. They suck up the one-time download, upgrade their one server, and move on.

Depends on whether the frapping download of their non-standard ta.rg.zz.zz.zz archive file times out part way through (after, say, a couple of hours) and they get several hundred megabytes of something that WinZip valiantly tries to unpack (since standard Windows knows not what a t.arr.rrrgg.ggzz.z archive is) but finds it can't because it isn't all there.

Then you get to go back and reselect the download, but of course your session has timed out after 30 minutes.

So you log back in yet-a-frapping-gain, and go through the Maxwell Smart-like collection of pages that you have to go through before you get to the real sodding download page yet-a-frapping-gain, and you get to choose HTML download for the umpteen thousandth time because the lovely Java-based Download Director has never, not once, worked properly for me (and of course when you "update" your selection to HTML download the site never, ever remembers that), and you get to change the radio button to "I agree to the licence agreements" for the umpteen trillionth time because it always defaults to "I do not agree" despite the fact that you had to sodding well agree to the terms on an earlier page anyway.

And so you wait, and you watch, and maybe, just perhaps, this time those gigabytes will actually make it all the way down.

Hmmm...

Mark me down as both a "care", and another except with more steam coming out of the ears right now.

[Alan Kirk]

Maybe most people don't care. They suck up the one-time download, upgrade their one server, and move on.

Mark me down as both a "care", and another except with more steam coming out of the ears right now.

And even more steam, now having found that the last 64 bit server package that I downloaded was an "Invalid compressed data stream". Or, put another way, 2,421,566 kb of bandwidth-wasting, hours-chewing, hard disk-cluttering Byte Ballast. Thank you IBM, thank you very much.

I'll know in an estimated 3 hours and 13 munutes whether the latest attempt to download it succeeds, after yesterday's attempts failed when each attempt to download it was met with a "Page cannot be displayed" error.

If IBM could synergistically leverage the number of "jokes but not of the funny kind" that it produces, it would own Hollywood by now.