April 29, 2011 at 6:06 am
I agree with the last comment. However, a new release every three years? That is a little too often if you ask me. I have 42 servers running over 300 databases here. Some of these apps the vendors go out of business or the app is retired but we are required by law to have this data for 7 years plus and in some cases forever.
Now, when you get into Microsoft Office. Where is the bang for the buck to go from Office 7 to the latest release of Office?
May 8, 2011 at 4:09 am
We have run into the exact problem. Some of our virtualized servers (OS 2003 and SQL 2000) refuse to run on the X series server processors in our VM hosts, even after it's being masked. They are now stuck running on 4 of our older VM hosts untill they're upgraded and ready to move to OS 2008 and SQL 2008.
May 8, 2011 at 12:12 pm
Daniel Bowlin (4/27/2011)
Do you think mainframe software folks in the 1970's were worried about the Y2K issue when they worked-NO-they didn't believe their applications would be around that long. Big mistake.
Some didn't. Some did.
Starting in 1969 ICL designed its 2900 series mainframes (based on earlier designs from the two companies that merged to form ICL). They had a hardware time datatype that was a 64 bit unsigned integer counting in microseconds, with base time 1900-01-01. That wasn't going to have a year 2000 problem, nor a year 20000 problem nor even a year 200000 problem; but Cobol app-writers soldiered on with character coded dates using 2 characters for the year even on that hardware (of course some people had even worse formats - now what was it that Oracle used in the late 70s or early 80s?).
It's the same today; I've come across people writing in C# and using an 8 bit year number based on 1900-01-01, I've no idea why they can't just use their machines internal hardware clock format which certainly doesn't have that problem.
Tom
May 8, 2011 at 12:27 pm
duplicate post - sorry
Tom
May 8, 2011 at 2:15 pm
MHilsher (4/28/2011)
If we want to talk about building a smarter market and making software investments last longer then, I think, we need to be willing to look at the whole model and take a realistic look at the costs. If we are willing to buy software as if it were an ongoing relationship instead of a single purchase commodity then manufacturers will be willing to sell it that way.
I can understand the argument, but I'm quite prepared to put up a counter-argument. I have (over the years) acquired quite a lot of odd bit sof softeare that just work and continue to work. I have written stuff that still runs today, unchanged, quarter of a century after I wrote it. So the cost of support for those things has been NIL.
But now if I go out and buy some software it almost certainly will not work - maybe I can make it work, or maybe I need some technical support to make it work and have to pay for that technical support, but in either case the software supplier hasn't delivered what he has been paid for. Many companies, particularly those selling in consumer retail markets, invent incredibly complex anti-consumer licensing terms and EULAs (and not surprisingly, in decent jurisdictions these things are thrown out in court now and again). On large commercial contracts, and even worse on government contracts, we see very large companies overcharging by a substantial factor, failing completely to deliver what was in the contract, and then suing the customer when the customer says "enough, I'm not paying you any more for screwing up".
So maybe what we should be looking at is some statement like "when software suppliers start delivering reasonably stable bug-free scomponents that are not riddled with security holes that the average teenager would have more sense than to incorporate in any software he wrote we will start to see a willingness on customers' parts to enter into a long term relationship which involves ongoing payments".
I am unhappy with market where a supplier can say "you bought it and it clearly won't do the job we told you it would? Hard luck, you can't have your quarter of a million back and nor can we offer you any support other than recommending which 'this is a table and this is a key' Janet and John training courses you should send your extremely experienced DB people on and pay us through the nose for" (I've actually had that, we eventually got the money back but it was a nightmare).
Currently the market is altogether unreasonable, but to form a reasonable market it is not just the buyers of software that have to change, it is the sellers too. It's all a bit chicken and egg, but corporate customers who have been thoroughly done over by "reputable" suppliers are probably not going to change first.
Tom
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply