Not true. I use new programs all the time with GUIs and I have no idea where things are going to be. But I figure it out very quickly because there is a GUI. I don't need to read the manual and I don't need to look on the web for answers. If it were all CLI then I'd likely have to find a wiki, faq, or forum. I'm doing that constantly for other CLI only programs. For GUI programs I almost never need to consult outside authorities unless it's a very complicated program such as Excel, photoshop, or some arcane system setting that is less a command line problem then it the impossibility of just knowing where to find the setting. Windows Registry is an example of a GUI gone wrong. But the registry should not be used as a counter example. It's badly designed. A well designed system would be contextual. The problem with the registry is that its only contextual from the computer's perspective. From the user's perspective it's just a giant list with horrific sorting.
Give the user a full GUI experience or you can continue to deal with a lack of adoption.
The answer is yes or the answer is no. It's a binary solution set. I don't mean to be harsh here but it's non-negotiable.
The windows version of regedit is GUI. The dos version does not. There is a lot of typing to make regedit work properly. All the keys have commands in them.
That's okay. Remember, excel has that as well where the various fields can have code in them. But the interface is largely GUI. Provide something along those lines and you'll be fine.
And there are lots of very complex programs that are excursively GUI. Pretending that you can only do these things in command line is nonsense.
Developing a proper GUI is more complicated then just creating a CLI. We know this... we appreciate that it's a pain in the ass. But you need a GUI. Provide one or there are going to be adoption problems.
First, I've been pretty clear about not including scripting in my comments about GUI versus command line.
So we're not talking about scripting. You can absolutely make scripting work with a GUI and drag and drop operations. But forget that for now.
The "regular expressions" language used by Grep is very nice and I have a lot of respect for it. But there is a GUI way to do it.
An actual search function like Grep is very easy to work with a GUI. Again, drag and drop operators. You have a list of plain text operations on the left hand side that are categorized. An operation could say "First character of line" or something like that. And then you have a window that the operations are dropped into. Ideally if it were done correctly the full set of operations will form into a plain text sentence that would describe what it was doing.
You could even put the regular expressions version/syntax immediately below this window which would facilitate people learning regular expressions more quickly.
I agree. Though, I would say that you underestimate how complex and rich a GUI can be if it's done correctly.
it's all about contextual options... and even scripting should be something you can do in a GUI with drop down menus and drag and drop operators.
Several companies have created development tools that work this way. They're rarely as rich as the raw versions but that's just a question of how much effort is put into the GUI.
You can express anything in the GUI that is in the CLI in full and complete detail. It just requires a bit more work.
In many ways the CLI is quick and dirty. I can appreciate it for what it is and what it can do. I wouldn't remove it. I think ti should be there. But we can do better.
If you had no internet access, you'd rather go hunting for a program in the command line you didn't know the name of rather then find it in a context menu automatically referenced to the task you using?
Get real. You've memorized the commands. Good for you. stripped of that you'd be fumbling in the dark. And a GUI would help assuming the GUI actually sorted information properly. It has to be contextual. If I right click on something I should get contextually relevant options that wouldn't come up if I right clicked on a different type of program or file.
None at all so long as the GUI has all the features the CLI has... and right now that isn't the case in linux. The CLI almost always has more options or the program has no GUI at all and must be used with the CLI.
Give me a full featured GUI alternative and that's fine. As it stands there is no such thing.
Look, I'm not against the command line. It's fine. And I actually would say that every program should have a command line. That said, every program should also have a GUI interface.
A serious problem in linux is that frequently you have to go to the command line to do a lot of things. You should NEVER have to go to command line.
The command line is great for people that have memorized all the commands, know exactly what they want to do, and can run the operations in their sleep. But for everyone else it's a hinderence. They have to do queries and check forums to figure out what the program is called. Then they need to look up the syntax.
It's the opposite of user friendly.
Command line is great for certain things. I Scripting especially is much easier if everything can take a command line. I wish more programs in windows for example could take a command line.
But linux especially needs to offer the GUI as the primary interface for EVERYTHING.
I know the old linux hands disagree. This is why you have adoption problems. And because you have adoption problems many companies don't write software for your OS requiring the open source community to write everything themselves. And of course hardware venders frequently don't release drivers for your OS. Fix the GUI issue and all that will change.
Quid pro quo. We're not asking for the universe here. Just the GUI as the primary interface. Keep the command line for those that prefer it. But you'll never get the adoption up so long as its the secondary interface.
See, the issue here is that you don't need to localize payments at all.
You put up a portal where people can pay. If the money clears the transaction goes forward. Why is it my responsibility to tell the host nation what people bought and sold on my site?
No doubt countries pass laws to this effect all the time. But then they've past laws to declare pi equal to 3.
Laws that are inherently unenforceable are stupid. If physical goods are coming into the country maybe you can track that. But digital downloads? Hopeless.
Maybe MS would have a hard time ignoring these laws being such a large target. But the internet is full of hundreds of thousands of companies selling software.
How many of them do you think care where you're from or apply a sales tax on the purchase? Just about none of them.
All you're doing is making an argument against a unified payment portal. Maybe that's the solution. Keep the little companies with their separate merchant portals.
This is the 21st century and the consumer has globalized. If they want to treat us like crap then we can return the favor.
As to taxes... do those apply to online purchases of software? Never paid sales tax in my life for that. And I've run sales through the US, europe, and Japan. I'm well traveled and have lived in different countries. Never paid a tax for a digital download.
Why would you localize an internet sales portal? You want it to work the whole world over.
Accept all payment systems that are in the 21st century from VISA to paypal to whatever. Translate the whole thing into as many languages as you can find.
It's unforgivable for a company to have a problem accepting a customer's money. This is a darwin award level error.
This way the power user such as yourself could have access to dozens of operating systems at once.
The best tools for some things are only made for windows. It's just a fact. If you want to do these things you need to run windows.
The best tools for many other things are only made for linux. There's just nothing comparable on windows or MacOS.
And then there are things MacOS does better. Garage Band or or whatever.
Then you have operating systems that don't normally run on desktops at all such as the android or iOS operating system. All these things and more can run at once on the same system.
I have a few tools that were written in DOS. There is nothing like them anywhere else. Windows XP can emulate DOS well enough that they can be run on XP. But they stopped working in VISTA and Windows 7. I have an XP VM that I keep around specifically to run those and similar tools.
I'm looking into the future and seeing that we might have a day when certain tools only run on Windows 7 or a specific version of the MacOS operating system. If I want those tools I must use that operating system. It isn't practical to keep all those machines around for those purposes. So instead we create a VM.
1. You're only sending the information through one extra process. I've run 3d games in VMs before and not had a problem. There is a performance hit but it's not a big deal.
What is important is that the VM have a comprehensive emulation of the environment. Some VM emulators half ass it. That causes problems.
2. As to overhead, this is a question of optimization. If you've done it properly this shouldn't be a huge deal.
3. The hypervisor OS by definition should be emulating specific environmental conditions. That is, you pick a machine and you set out to create an emulation of that specific machine.
If you want to update the hypervisor that's fine. But the updates will apply to NEW emulations and not old ones.
For example when I load up virtual box for VMware workstation it asks me what OS I wish to emulate. Why does it ask that? Because certain environments are more or less compatible with those operating systems.
Updates would add new environments but the old ones should just be configuration files that establish the pentameters.
I do see what you're saying and it would be a problem. however if the VM OS is primarily there to facilitate the loading of as many varied subordinate OSs as possible then why would they drop compatibility?
I just think it would be less of a problem.
4. Again a ten percent bump in power usage assuming the optimization hasn't been a complete farce is reasonable.
As to your argument that everyone should just switch to linux. The programs aren't written for linux. So if we used linux we'd be running a VM in linux anyway. Exactly how does that solve any problem?
The tired of argument of "you should have used linux"... is tedious.
I'm not claiming to have invented anything. I'm merely saying if we do this then we can have OS neutral computers that can run lots of operating systems concurrently.
Want to bring up an old file from 1980? Open it in the 1980 VM... everything just as it was. No need to maintain the hardware.
As to processing power, machines already have more power then workstations need. The five or ten percent loss of performance isn't a big deal especially if you consider that you can bring your old OS along with you from one machine to the next without having to dump it unless you want to... and you get to use the latest hardware. Imagine how simple full system back ups would be as well. You just copy the VM to another drive. Drag and drop.
What about viruses? No problem. You can restore to an older version of the VM. Or always restore the state of the "internet VM" to a clean copy on every use. The system can get infected all the time. It won't matter. Every time you reload that VM the viruses are wiped.
I actually think conventional OSs are a bad idea in general.
Imagine performance isn't an issue. Lets just assume you have more then enough processing power that emulation just isn't relevant.
Okay, imagine how much easier it is to manage drivers if the drivers only have to be compatible with a master VM OS. All venders just have to test their hardware with that one OS. No need for mac drivers. No need for Windows drivers. No need for linux drivers. Just port everything to a standardized VM OS.
And then there is security. The VM OS shouldn't connect to the internet. That isn't what it does. It handles hardware abstraction and loads VMs. You can load a VM and then open a web browser within it. But you can't just load a web browser from master system itself. With the exception of a few white listed diagnostic applications it shouldn't run anything.
I really think that's the future of computer operating systems. Ideally, the VM OS should be something tiny that can fit on a on a tiny solid state storage chip on the motherboard itself. Similar to the BIOS. It should load indifferent to what hardware is plugged into it. And it should have enough free storage space to handle any conceivable combination of drivers that the system might need.
I agree on the X bit... on the importing old deals into the new system.
You have to do that. It's non-negotiable. And that's the problem. It's a HUGE pain in the ass. And what you're saying is that your company can't offer that feature at a competitive rate. I know that. I've asked around repeatedly.
The only solution is to keep the old system going or reprogram the whole thing from scratch.
It's just what "is."
The only reasonable solution for most of these companies is to VM the old systems so they can maintain them on new hardware. And then to build new UI tie ins so that you can interact with a 20 year old database through an ipad... AND make it look sexy.
I've done that a few times. The whole system is horrifying when you understand how much processing power is being wasted on abstraction. But the cost of the processing power is meaningless compared to the cost reprogramming it.
Again, this is an issue big international banks have given up on. Somewhere in their infrastructure you'll find literally dozens if not thousands of interlinked databases that all use different formats, technologies, scripting languages, OS's, etc. They were all built at different times by different groups for different purposes. And THEN everything was linked together using custom scripts and programs that often only exist in their computers and no where else.
And you could say "oh just rewrite it" but the thing is many of these systems were badly programmed in the first place. They work. But the documentation is often horrific or non-existent. You can talk to the old hands and ask them how it works but they often have no clue. They know how to ADD a feature or change a feature in their systems. But they've been doing that for so many years without a full rebuild that no one actually knows how everything is wired together anymore.
You can pull out one tiny system out of the network that everyone swears is irrelevant it can can completely crash the system and make it totally impossible for it to function until it's replaced. Why? Because everything was designed assuming everything was just "so." And if anything changes nothing works.
Again, I'm not advocating this as a good idea. I'm not the one that designed this or came up with this idea. It just "is." No one really planned it this way. Its something that grows in a company like fungus. And by the time it gets to this stage you can't really do anything to fix it. You just have to survive it.
And the CEOs frequently ask what it would cost to upgrade these systems. They say 'wow, those are old, get back to me with an upgrade proposal.'
They're proprietary backbone systems. They're frequently the soul of the company's electronic infrastructure. Old legacy databases processing some critical but arcane transactions that can't be done by any system that hasn't been specifically programmed from the ground up to do it.
Trust me. They want to upgrade. The cost is just a significant percentage of their profit margin for that quarter. And IT has learned that you don't tell management that it has to do something expensive. That just means management needs to find someone smarter then you that can come up with a clever way to eat the cake and have it too.
And that's what we in IT have been doing in many of these companies for years. We find a way to solve the problem so management doesn't have the problem and doesn't have to pay for the full system upgrade.
And for this amongst other things we keep our jobs. We solve the problem.
Would it be better to simply rewrite the whole thing from scratch? Yes. But it would require years of reprogramming it from scratch with internal developers or we'd have to outsource at a huge cost to another group. And then we'd have to sync all our sub offices to the new system.
Our only hope is VMing the whole thing into some sort of abstraction at some point. Then we can dump it on any new system, hide the text based interface with scripts and everyone can get what they need.
MS is letting us down by not maintaining backward compatibility. But the VMs seem to be stepping up.
corporate america is full of old legacy programs that most of the company has forgotten but are essential to the operation of the organization. Somewhere in the sub basement there are a few machines only a few members of the IT department are aware of... they are often the reason it takes "two days to process" certain requests... you could argue they whole thing should be reprogrammed from scratch but you're dealing with proprietary programs that could be very complicated and were built bit by bit in spaghetti code fashion over decades.
It's something of a mess. But the companies work and if everyone does their jobs the system runs.
You see this sort of thing in big international banks. Large retail chain head quarters. Or even medium sized businesses that have been operating a few franchises since the 80s.
Requiring them to upgrade isn't going to work. They're already trying to move these system to VMs. But compatibility for these old programs even in VMs is spotty. It's a serious problem.
Slashdot Mirror
Not true. I use new programs all the time with GUIs and I have no idea where things are going to be. But I figure it out very quickly because there is a GUI. I don't need to read the manual and I don't need to look on the web for answers. If it were all CLI then I'd likely have to find a wiki, faq, or forum. I'm doing that constantly for other CLI only programs. For GUI programs I almost never need to consult outside authorities unless it's a very complicated program such as Excel, photoshop, or some arcane system setting that is less a command line problem then it the impossibility of just knowing where to find the setting. Windows Registry is an example of a GUI gone wrong. But the registry should not be used as a counter example. It's badly designed. A well designed system would be contextual. The problem with the registry is that its only contextual from the computer's perspective. From the user's perspective it's just a giant list with horrific sorting.
Give the user a full GUI experience or you can continue to deal with a lack of adoption.
The answer is yes or the answer is no. It's a binary solution set. I don't mean to be harsh here but it's non-negotiable.
The windows version of regedit is GUI. The dos version does not. There is a lot of typing to make regedit work properly. All the keys have commands in them.
That's okay. Remember, excel has that as well where the various fields can have code in them. But the interface is largely GUI. Provide something along those lines and you'll be fine.
And there are lots of very complex programs that are excursively GUI. Pretending that you can only do these things in command line is nonsense.
Developing a proper GUI is more complicated then just creating a CLI. We know this... we appreciate that it's a pain in the ass. But you need a GUI. Provide one or there are going to be adoption problems.
First, I've been pretty clear about not including scripting in my comments about GUI versus command line.
So we're not talking about scripting. You can absolutely make scripting work with a GUI and drag and drop operations. But forget that for now.
The "regular expressions" language used by Grep is very nice and I have a lot of respect for it. But there is a GUI way to do it.
An actual search function like Grep is very easy to work with a GUI. Again, drag and drop operators. You have a list of plain text operations on the left hand side that are categorized. An operation could say "First character of line" or something like that. And then you have a window that the operations are dropped into. Ideally if it were done correctly the full set of operations will form into a plain text sentence that would describe what it was doing.
You could even put the regular expressions version/syntax immediately below this window which would facilitate people learning regular expressions more quickly.
You started out well and then admitted that you were wrong in your second sentence.
"every day usage"... *BUZZER SOUND* Wrong.
All usage. I can understand scripting requiring a command line and that is fine. But for ALL TASKS a GUI should be viable.
MS admins don't want to lose that feature and the cost to performance is irrelevant.
Ask the MS admins if they want to eliminate the GUI.
They don't.
hyperbole isn't going to make your argument stronger.
I agree. Though, I would say that you underestimate how complex and rich a GUI can be if it's done correctly.
it's all about contextual options... and even scripting should be something you can do in a GUI with drop down menus and drag and drop operators.
Several companies have created development tools that work this way. They're rarely as rich as the raw versions but that's just a question of how much effort is put into the GUI.
You can express anything in the GUI that is in the CLI in full and complete detail. It just requires a bit more work.
In many ways the CLI is quick and dirty. I can appreciate it for what it is and what it can do. I wouldn't remove it. I think ti should be there. But we can do better.
I'm not saying get rid of the terminal. I'm saying make the GUI a viable option for ALL functions.
And yes, the fact that you can do that in excel with a GUI is the reason excel UTTERLY DOMINATES the spread sheet market.
Provide a viable GUI alternative. Excuses just mean you're saying no.
It's a binary solution set. Either you have it or you don't.
If you had no internet access, you'd rather go hunting for a program in the command line you didn't know the name of rather then find it in a context menu automatically referenced to the task you using?
Get real. You've memorized the commands. Good for you. stripped of that you'd be fumbling in the dark. And a GUI would help assuming the GUI actually sorted information properly. It has to be contextual. If I right click on something I should get contextually relevant options that wouldn't come up if I right clicked on a different type of program or file.
None at all so long as the GUI has all the features the CLI has... and right now that isn't the case in linux. The CLI almost always has more options or the program has no GUI at all and must be used with the CLI.
Give me a full featured GUI alternative and that's fine. As it stands there is no such thing.
You can have hundreds or even thousand of options in the GUI fairly easily. Just have nested and contextual settings.
Everything isn't shown at once. You have preferences or options windows. Within each of those you can have all sorts of tabs and sub menus.
*gets ready for mindless hate replies*
Look, I'm not against the command line. It's fine. And I actually would say that every program should have a command line. That said, every program should also have a GUI interface.
A serious problem in linux is that frequently you have to go to the command line to do a lot of things. You should NEVER have to go to command line.
The command line is great for people that have memorized all the commands, know exactly what they want to do, and can run the operations in their sleep. But for everyone else it's a hinderence. They have to do queries and check forums to figure out what the program is called. Then they need to look up the syntax.
It's the opposite of user friendly.
Command line is great for certain things. I Scripting especially is much easier if everything can take a command line. I wish more programs in windows for example could take a command line.
But linux especially needs to offer the GUI as the primary interface for EVERYTHING.
I know the old linux hands disagree. This is why you have adoption problems. And because you have adoption problems many companies don't write software for your OS requiring the open source community to write everything themselves. And of course hardware venders frequently don't release drivers for your OS. Fix the GUI issue and all that will change.
Quid pro quo. We're not asking for the universe here. Just the GUI as the primary interface. Keep the command line for those that prefer it. But you'll never get the adoption up so long as its the secondary interface.
is it within the eu?...
See, the issue here is that you don't need to localize payments at all.
You put up a portal where people can pay. If the money clears the transaction goes forward. Why is it my responsibility to tell the host nation what people bought and sold on my site?
No doubt countries pass laws to this effect all the time. But then they've past laws to declare pi equal to 3.
Laws that are inherently unenforceable are stupid. If physical goods are coming into the country maybe you can track that. But digital downloads? Hopeless.
Maybe MS would have a hard time ignoring these laws being such a large target. But the internet is full of hundreds of thousands of companies selling software.
How many of them do you think care where you're from or apply a sales tax on the purchase? Just about none of them.
All you're doing is making an argument against a unified payment portal. Maybe that's the solution. Keep the little companies with their separate merchant portals.
Put paper chains around my wrists and watch how they hold me.
You can adapt to the 21st century or go the way of that which fails to adapt.
Then we'll pirate.
This is the 21st century and the consumer has globalized. If they want to treat us like crap then we can return the favor.
As to taxes... do those apply to online purchases of software? Never paid sales tax in my life for that. And I've run sales through the US, europe, and Japan. I'm well traveled and have lived in different countries. Never paid a tax for a digital download.
Why would you localize an internet sales portal? You want it to work the whole world over.
Accept all payment systems that are in the 21st century from VISA to paypal to whatever. Translate the whole thing into as many languages as you can find.
It's unforgivable for a company to have a problem accepting a customer's money. This is a darwin award level error.
Then you're a slave to one OS.
This way the power user such as yourself could have access to dozens of operating systems at once.
The best tools for some things are only made for windows. It's just a fact. If you want to do these things you need to run windows.
The best tools for many other things are only made for linux. There's just nothing comparable on windows or MacOS.
And then there are things MacOS does better. Garage Band or or whatever.
Then you have operating systems that don't normally run on desktops at all such as the android or iOS operating system. All these things and more can run at once on the same system.
I have a few tools that were written in DOS. There is nothing like them anywhere else. Windows XP can emulate DOS well enough that they can be run on XP. But they stopped working in VISTA and Windows 7. I have an XP VM that I keep around specifically to run those and similar tools.
I'm looking into the future and seeing that we might have a day when certain tools only run on Windows 7 or a specific version of the MacOS operating system. If I want those tools I must use that operating system. It isn't practical to keep all those machines around for those purposes. So instead we create a VM.
1. You're only sending the information through one extra process. I've run 3d games in VMs before and not had a problem. There is a performance hit but it's not a big deal.
What is important is that the VM have a comprehensive emulation of the environment. Some VM emulators half ass it. That causes problems.
2. As to overhead, this is a question of optimization. If you've done it properly this shouldn't be a huge deal.
3. The hypervisor OS by definition should be emulating specific environmental conditions. That is, you pick a machine and you set out to create an emulation of that specific machine.
If you want to update the hypervisor that's fine. But the updates will apply to NEW emulations and not old ones.
For example when I load up virtual box for VMware workstation it asks me what OS I wish to emulate. Why does it ask that? Because certain environments are more or less compatible with those operating systems.
Updates would add new environments but the old ones should just be configuration files that establish the pentameters.
I do see what you're saying and it would be a problem. however if the VM OS is primarily there to facilitate the loading of as many varied subordinate OSs as possible then why would they drop compatibility?
I just think it would be less of a problem.
4. Again a ten percent bump in power usage assuming the optimization hasn't been a complete farce is reasonable.
As to your argument that everyone should just switch to linux. The programs aren't written for linux. So if we used linux we'd be running a VM in linux anyway. Exactly how does that solve any problem?
The tired of argument of "you should have used linux"... is tedious.
I'm not claiming to have invented anything. I'm merely saying if we do this then we can have OS neutral computers that can run lots of operating systems concurrently.
Want to bring up an old file from 1980? Open it in the 1980 VM... everything just as it was. No need to maintain the hardware.
As to processing power, machines already have more power then workstations need. The five or ten percent loss of performance isn't a big deal especially if you consider that you can bring your old OS along with you from one machine to the next without having to dump it unless you want to... and you get to use the latest hardware. Imagine how simple full system back ups would be as well. You just copy the VM to another drive. Drag and drop.
What about viruses? No problem. You can restore to an older version of the VM. Or always restore the state of the "internet VM" to a clean copy on every use. The system can get infected all the time. It won't matter. Every time you reload that VM the viruses are wiped.
I agree but I actually see it as a good thing.
I actually think conventional OSs are a bad idea in general.
Imagine performance isn't an issue. Lets just assume you have more then enough processing power that emulation just isn't relevant.
Okay, imagine how much easier it is to manage drivers if the drivers only have to be compatible with a master VM OS. All venders just have to test their hardware with that one OS. No need for mac drivers. No need for Windows drivers. No need for linux drivers. Just port everything to a standardized VM OS.
And then there is security. The VM OS shouldn't connect to the internet. That isn't what it does. It handles hardware abstraction and loads VMs. You can load a VM and then open a web browser within it. But you can't just load a web browser from master system itself. With the exception of a few white listed diagnostic applications it shouldn't run anything.
I really think that's the future of computer operating systems. Ideally, the VM OS should be something tiny that can fit on a on a tiny solid state storage chip on the motherboard itself. Similar to the BIOS. It should load indifferent to what hardware is plugged into it. And it should have enough free storage space to handle any conceivable combination of drivers that the system might need.
Everything else should be in the VMs.
I agree on the X bit... on the importing old deals into the new system.
You have to do that. It's non-negotiable. And that's the problem. It's a HUGE pain in the ass. And what you're saying is that your company can't offer that feature at a competitive rate. I know that. I've asked around repeatedly.
The only solution is to keep the old system going or reprogram the whole thing from scratch.
It's just what "is."
The only reasonable solution for most of these companies is to VM the old systems so they can maintain them on new hardware. And then to build new UI tie ins so that you can interact with a 20 year old database through an ipad... AND make it look sexy.
I've done that a few times. The whole system is horrifying when you understand how much processing power is being wasted on abstraction. But the cost of the processing power is meaningless compared to the cost reprogramming it.
Again, this is an issue big international banks have given up on. Somewhere in their infrastructure you'll find literally dozens if not thousands of interlinked databases that all use different formats, technologies, scripting languages, OS's, etc. They were all built at different times by different groups for different purposes. And THEN everything was linked together using custom scripts and programs that often only exist in their computers and no where else.
And you could say "oh just rewrite it" but the thing is many of these systems were badly programmed in the first place. They work. But the documentation is often horrific or non-existent. You can talk to the old hands and ask them how it works but they often have no clue. They know how to ADD a feature or change a feature in their systems. But they've been doing that for so many years without a full rebuild that no one actually knows how everything is wired together anymore.
You can pull out one tiny system out of the network that everyone swears is irrelevant it can can completely crash the system and make it totally impossible for it to function until it's replaced. Why? Because everything was designed assuming everything was just "so." And if anything changes nothing works.
Again, I'm not advocating this as a good idea. I'm not the one that designed this or came up with this idea. It just "is." No one really planned it this way. Its something that grows in a company like fungus. And by the time it gets to this stage you can't really do anything to fix it. You just have to survive it.
Your software isn't customized to their business. This is just the sort of problem that kills upgrade deals.
The software MUST be dynamic.
I'm not talking about that.
And the CEOs frequently ask what it would cost to upgrade these systems. They say 'wow, those are old, get back to me with an upgrade proposal.'
They're proprietary backbone systems. They're frequently the soul of the company's electronic infrastructure. Old legacy databases processing some critical but arcane transactions that can't be done by any system that hasn't been specifically programmed from the ground up to do it.
Trust me. They want to upgrade. The cost is just a significant percentage of their profit margin for that quarter. And IT has learned that you don't tell management that it has to do something expensive. That just means management needs to find someone smarter then you that can come up with a clever way to eat the cake and have it too.
And that's what we in IT have been doing in many of these companies for years. We find a way to solve the problem so management doesn't have the problem and doesn't have to pay for the full system upgrade.
And for this amongst other things we keep our jobs. We solve the problem.
Would it be better to simply rewrite the whole thing from scratch? Yes. But it would require years of reprogramming it from scratch with internal developers or we'd have to outsource at a huge cost to another group. And then we'd have to sync all our sub offices to the new system.
Our only hope is VMing the whole thing into some sort of abstraction at some point. Then we can dump it on any new system, hide the text based interface with scripts and everyone can get what they need.
MS is letting us down by not maintaining backward compatibility. But the VMs seem to be stepping up.
corporate america is full of old legacy programs that most of the company has forgotten but are essential to the operation of the organization. Somewhere in the sub basement there are a few machines only a few members of the IT department are aware of... they are often the reason it takes "two days to process" certain requests... you could argue they whole thing should be reprogrammed from scratch but you're dealing with proprietary programs that could be very complicated and were built bit by bit in spaghetti code fashion over decades.
It's something of a mess. But the companies work and if everyone does their jobs the system runs.
You see this sort of thing in big international banks. Large retail chain head quarters. Or even medium sized businesses that have been operating a few franchises since the 80s.
Requiring them to upgrade isn't going to work. They're already trying to move these system to VMs. But compatibility for these old programs even in VMs is spotty. It's a serious problem.