Names not mentioned to protect the guilty.
So I am working on a cluster load. Have everything nicely configured. Do some tests, make sure it takes correctly. I have spent many an hour dealing with some sort of broken process, due to minor changes in seemingly unrelated areas. Usually broken due to badly borked installers that, for better or worse (usually worse) are considered “standard.”
This is the N+1th test. We have customers who like installing and re-installing. Over and over again.
We have tried to have them understand that there can be some … how shall I say this … brittleness in any installer. Given that this installer is based upon a very unforgiving (and largely broken) code base, needless to say, you want as little direct interaction with it as possible.
Some of you may know whom/what I am talking about. I won’t elaborate.
Brittleness in an installer is an absolute no-no. It is a non-defensible position. It is something you do if you want to put off customers. Our customers cannot afford brittle installers. One in particular wants to reload his system almost daily as he gets new ideas on what he wants to try.
Unfortunately this installation system is brittle. There are few if any redeeming factors for it.
So after trying a reload, yet again, knowing full well that the customer is going to do this, it breaks. Suddenly things that worked an hour ago ceased working. The brittleness comes through.
I should send a bill for all my wasted hours to the purveyors of this system. Now I have to work around its bugs to provide the needed functionality to my customer. Too bad it is unable to do it.
This is not a Linux issue. This is an issue with a hopelessly broken installer. Linux works great on these units. The installer is a steaming pile of bits.
Viewed 11912 times by 2560 viewers