4 ms·
It surely worked, but when it didn’t it took ages to resolve the issue. I remember back in mid nineties, IBM had brought a whole team to troubleshoot an issue a
by elorant 3y ago
It surely worked, but when it didn’t it took ages to resolve the issue. I remember back in mid nineties, IBM had brought a whole team to troubleshoot an issue and they stayed at the company where I worked for almost a week to find out what went wrong.
- deleted 3y ago[deleted]
- Pamar 3y agoWell, exactly the same thing happened in a project I worked on in mid-2000s. Except it was not AS400 or anything hardware... it was a problem with an Oracle product, and took a bit over one week with higher and higher gurus being parachuted in by Oracle Europe. And in the early 90s I had another similar episode, this time with DEC/Vax. Not sure anymore but I think they finally had to patch the OS. My point: nothing made by humans can guarantee 101% uptime. The main difference is how far any vendor will go to solve your problems.
- kragen 3y agoi would say, rather, that the main difference is how dependent you are on the goodwill of the vendor to solve your problems, and how much you can solve yourself (or by hiring people). which is why oracle has been mostly replaced with postgres, mysql, and sqlite; why as/400 has been mostly replaced with web servers running apache and nginx; why vaxen and the like have been mostly replaced with i386 and later amd64 hardware with buses like pci and pcie; and why vax/vms has been replaced by linux when you have business-critical systems problems only your systems vendor can solve, over time, their pricing strategy tends to converge on the following: 1. how much money does your company make? 2. hand it over. you may not know as much about linux as the gurus dec parachuted in to patch your vms installation knew about vms, but i can guarantee that you care more about your own problems than dec did, and that counts for more. you can either learn what you need to know or, if you have more money than time, hire somebody who already knows it—at a market rate, not a monopoly-rents rate. the perverse incentives enjoyed by vendors of closed systems slowly but surely destroyed almost all of them, leaving only a few standing
- Pamar 3y agoI am not sure of what point you are trying to make here. I have been in the industry since late 80s and (surely due to the kind of customers I worked with, so I am not implying that this applies to everyone and everywhere) and I have never seen anything even remotely "mission-critical" replacing Oracle or Microsoft stacks with Linux/Postgres. I am currently working on something based on ridiculously obsolete technology (Progress) which is running on Solaris, for example. The company I am working with is concerned about the chance that Progress will just die, but replacing it with Postgres is the least of our problems. The real problem is that a full rewrite would take maybe 5 years and nobody wants to start the ball rolling. In the meantime, we are "more than happy" to pay whatever the licensing is both for Progress and Oracle (for Solaris) and having them "on call" in case something breaks.
- kragen 3y agoi am sorry that my comment was unclear, and i would be happy to explain whatever it is that you are having trouble understanding > I have never seen anything even remotely "mission-critical" replacing Oracle or Microsoft stacks with Linux/Postgres yeah, this only rarely happens inside a single company. mostly the way this works is that companies that run their mission-critical systems on oracle and microsoft stacks get outcompeted in the market by companies running on linux and postgres, because they can solve their own problems instead of letting their vendors decide which problems are worth solving and what their profit margins should be allowed to be you have, i am sure, noticed that many more companies today run their mission-critical systems on linux than on solaris, though microsoft is still in the running and even in the lead in some areas
- Pamar 3y agoMaybe the problem is that the company or companies you have in mind operate mostly in the service business and are relative recent - i.e. dating back to the 90s at most (e.g. AirBnb). I sincerely doubt that for automotive/manufacturing, utilities or travel (the three industries I have most experience with) linux (or any specific IT technology) has ever made the difference between surviving and being eaten alive by competitors. In that universe IT services are a commodity. Just like Electrical Power: you cannot operate an automotice company without electrical power, but buying it from Utility Company A instead of Utility Company B does not matter at all. For sure when an entire industry adopts a completely new technology (e.g.: IOT Shipping) they will go for whatever seems to provide the best solution for their specific case. But their bread and butter stuff (ERP, CRM, Finance...) will either be some custom legacy app (or more probably a hodge-podge of balkanized legacy apps) or will be some customized behemoth like SAP, Oracle Finance, Microsoft Dynamics. Both SAP and Oracle products can run on Linux, granted. But in that case I think it will be a vendor-backed version of Linux, so the support will come from the same entity that provided the application stack.
- dmix 3y ago> it was a problem with an Oracle product, and took a bit over one week with higher and higher gurus being parachuted in by Oracle Europe. From my understanding that was basically Oracle's business model back in the day (or the model of a lot of employees). Extensive consultant billable hours for maintenance and integration after you buy it.
- elorant 3y agoMy point: nothing made by humans can guarantee 101% uptime. The main difference is how far any vendor will go to solve your problems. From my experience, IBM will go to the far side of the moon and back in order to solve your problem. It will probably cost you in fees as much as buying a new car, but there's no luck of resources or resilience from their part. And I admire them for that. As much as we like to idolize the latest and greatest in this forum, the truth is that when it comes to mission critical equipment you need someone that you know will fly an expert from a different country in the middle of the night if they have to.
- ThinkBeat 3y agoI never saw that anywhere I was, but every system will have its share of issues for sure. Something similar happened to a client a couple of years ago. They wanted to set up their "devops pipeline" on AWS. First they tried to solve it in house. After two months they gave up and brought in an AWS specialist. After two weeks, we had two more AWS specialist inclduing one really expensive. 1.5 months later we had the pipeline going, but fragile as hell. I have not been able to piece together how it could have possibly taken so long. I didn not work on this part of the project myself at all. Given that the entire back-edn was in C#, with VSProject configurations the whole bit, it would have taken less than week on Azure, if you kept some of the presets. But yeah Azure CI/CD can suck as well and its less configurable. Which is a curse or a benefit depending on your standpoint.