7 ms·

I question if you've worked with large enterprises. They freeze everything for a decade or more. Think about a bank with 500 offices, a dozen tellers at each

by DougN7 10y ago

I question if you've worked with large enterprises. They freeze everything for a decade or more. Think about a bank with 500 offices, a dozen tellers at each office. Having their internal web app that everyone uses go down because of an auto upgrade could cost them hundreds of millions. They have a very different risk appetite.

tomelders 10y ago
Ive actually been working in banks mainly. But on the business side. At the upper echelons there is a real appetite for change. Banks realise that they have become software companies, but that their businesses are groaning under the weight of antiquated systems and processes and it is holding them back. But even the board can only affect so much. The only reason an auto update would take down an app is if all development has stopped. As part of the process you should be testing against upcoming releases of chrome so you spot these problems well in advance. But if dev has stopped, then yes, you will have a problem.
- riprowan 10y ago
  Dev stops. That's reality. If you hand-wave it away, your tellers go down, and you, the CIO, lose your job. Not all software is under your direct control. Once business processes achieve a stable working state, it is imperative that they maintain uptime, sometimes in excess of six-sigma uptime. Imagine your business is NASA. Are you going to let mission systems auto-update 18 secs before launch?
  - tomelders 10y ago
    I think we can all agree that NASA is a special case. Also, is it 100% true that they dont update software on actuve systems mid mission? What if they discover a critical bug?
    - DougWebb 10y ago
      Of course NASA updates software mid-mission; they're famous for sending software updates out to deep-space probes and rovers to fix things as critical as communication issues, which is quite a neat trick. What they don't do is allow updates to happen automatically. They're carefully pre-tested, and the update is carefully planned and scheduled. Their goal, like most enterprises, is to minimize risk, and bugs that you know about and understand the impact of are much less risky than updated software you haven't been able to test yet.
      - tomelders 10y ago
        In this example though, your app is the mars rover and Chrome is the rest of the Universe. The Universe auto updates. So you need to update your rover when that happens.
    - raarts 10y ago
      NASA is not a special case. What about medical equipment, weapons , oil industry, stock trading, I bet other people here can think of more examples.
  - illumin8 10y ago
    The dirty truth is that every piece of software or infrastructure you deploy immediately becomes "technical debt," and you know the thing about debt is that it charges interest. You can choose to neglect paying on your debt for some period of time, but it always comes back, more expensive, later. Case in point: the IT leaders that refused to upgrade from Windows XP and Server 2003 are now paying astronomical prices for "extended support" and "migration/rehosting." If they would have simply invested in maintenance to ensure compatibility with newer OS/browser combinations, they would not have this problem. Pay now, or pay much much more later. Tech debt is a huge problem in IT, and ignoring it won't make it go away.
    - raarts 10y ago
      The prices charged for extended support are high but not astronomical and I don't think you answered the question on NASA.
  - qyv 10y ago
    I think the point here is that there is no such thing as a stable state in software. Maintaining old infrastructure to support old applications is not a steady-state, it is a degrading state. As bugs and exploits are discovered and patched in new versions of windows/browsers/databases/frameworks/libraries/etc the old systems degrade to a vulnerable, un-maintainable, unsupported and often un-upgradeable state.
- neiled 10y ago
  Not only does Dev stop, but the people that built the app, agreed on the specs and really understood it, all left too. Auto update is unfortunately something that's just not worth the risk in a lot of cases.
  - tomelders 10y ago
    Thats called bad management.
    - tossedaway334 10y ago
      It is the reality of the situation in a vast amount of companies.
      - fuck_google 10y ago
        And its only going to get worse by disabling automatic updates.
      - CaptSpify 10y ago
        Only because we let them. I'm very much against auto-updating software, but I still don't see this as a good argument against them. It's not that companies can't keep up, it's that companies choose not to keep up. In this aspect, taking away their choice is the winning move, imo
        tossedaway334 10y ago
        The only thing you do by "taking away their choice" is to force them to use alternatives that are not Google Chrome.
        CaptSpify 10y ago
        I would argue that's a good thing
  - johnward 10y ago
nommm-nommm 10y ago
They used to, this is no longer the norm though. The norm is moving to patching systems regularly.
illumin8 10y ago
That doesn't mean this is a good practice. In fact, I would argue that this type of thinking has created far more harm than good for both the IT industry as well as the companies that adopt this harmful practice. Case in point: many of these same companies that refuse to upgrade systems for a decade or more are still running Windows XP and Server 2003. Due to the negligence of their IT leadership, they are now vulnerable to all types of security vulnerabilities that won't be patched, and have put both their business and their customer's private data at risk. This is no different than a state or local government refusing to maintain critical infrastructure like bridges and tunnels. Negligence might be viewed as conservatism for a few years, but when the bridge collapses because routine maintenance wasn't performed, it becomes clear that the administration who neglected maintenance was at fault. The sooner the cancerous idea, that IT software can be frozen in some golden state of perpetually providing business value with zero maintenance required, dies, the better. Modern, thoughtful IT leadership realizes the value in a continuously updated, secure browser. Chrome is already winning the browser war in the Enterprise for this reason alone. This just provides additionally needed controls like white-listed extensions that are known to be safe.
- gajjanag 10y ago
  > That doesn't mean this is a good practice. In fact, I would argue that this type of thinking has created far more harm than good for both the IT industry as well as the companies that adopt this harmful practice. > Case in point: many of these same companies that refuse to upgrade systems for a decade or more are still running Windows XP and Server 2003. Due to the negligence of their IT leadership, they are now vulnerable to all types of security vulnerabilities that won't be patched, and have put both their business and their customer's private data at risk. There are legitimate reasons for this though. The way I understand it, a big chunk of the problem is that many software vendors refuse to properly separate security related updates from regular updates. Firefox at least has an ESR version, AFAIK there is no equivalent for Chrome. See also attitudes like that mentioned in: https://news.ycombinator.com/item?id=9164251 https://news.ycombinator.com/item?id=9164251 Similar examples can be given for MATLAB - I know of many professors who ask students to run some old and fixed version of MATLAB for many years - they do not want to waste their time dealing with the breakage that inevitably happens with newer releases. If all vendors actually put in effort into maintaining LTS versions, the situation could be different. I do agree that the idea of perpetual business value with zero maintenance in a frozen state doesn't make sense - but as a business, I would always be interested in minimizing my maintenance burden.
heartbreak 10y ago
I'd say that this enterprise version of Chrome will finally fit in a financial institutions's baseline target for their patch management system. Take a look at page 45 (page 27 of the PDF itself): https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturity_June_2015_PDF2_c.pdf https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturit...

by DougN7 10y ago

tomelders 10y ago

Ive actually been working in banks mainly. But on the business side. At the upper echelons there is a real appetite for change. Banks realise that they have become software companies, but that their businesses are groaning under the weight of antiquated systems and processes and it is holding them back. But even the board can only affect so much. The only reason an auto update would take down an app is if all development has stopped. As part of the process you should be testing against upcoming releases of chrome so you spot these problems well in advance. But if dev has stopped, then yes, you will have a problem.

riprowan 10y ago
Dev stops. That's reality. If you hand-wave it away, your tellers go down, and you, the CIO, lose your job. Not all software is under your direct control. Once business processes achieve a stable working state, it is imperative that they maintain uptime, sometimes in excess of six-sigma uptime. Imagine your business is NASA. Are you going to let mission systems auto-update 18 secs before launch?
- tomelders 10y ago
  I think we can all agree that NASA is a special case. Also, is it 100% true that they dont update software on actuve systems mid mission? What if they discover a critical bug?
  - DougWebb 10y ago
    Of course NASA updates software mid-mission; they're famous for sending software updates out to deep-space probes and rovers to fix things as critical as communication issues, which is quite a neat trick. What they don't do is allow updates to happen automatically. They're carefully pre-tested, and the update is carefully planned and scheduled. Their goal, like most enterprises, is to minimize risk, and bugs that you know about and understand the impact of are much less risky than updated software you haven't been able to test yet.
    - tomelders 10y ago
      In this example though, your app is the mars rover and Chrome is the rest of the Universe. The Universe auto updates. So you need to update your rover when that happens.
  - raarts 10y ago
    NASA is not a special case. What about medical equipment, weapons , oil industry, stock trading, I bet other people here can think of more examples.
- illumin8 10y ago
  The dirty truth is that every piece of software or infrastructure you deploy immediately becomes "technical debt," and you know the thing about debt is that it charges interest. You can choose to neglect paying on your debt for some period of time, but it always comes back, more expensive, later. Case in point: the IT leaders that refused to upgrade from Windows XP and Server 2003 are now paying astronomical prices for "extended support" and "migration/rehosting." If they would have simply invested in maintenance to ensure compatibility with newer OS/browser combinations, they would not have this problem. Pay now, or pay much much more later. Tech debt is a huge problem in IT, and ignoring it won't make it go away.
  - raarts 10y ago
    The prices charged for extended support are high but not astronomical and I don't think you answered the question on NASA.
- qyv 10y ago
  I think the point here is that there is no such thing as a stable state in software. Maintaining old infrastructure to support old applications is not a steady-state, it is a degrading state. As bugs and exploits are discovered and patched in new versions of windows/browsers/databases/frameworks/libraries/etc the old systems degrade to a vulnerable, un-maintainable, unsupported and often un-upgradeable state.
neiled 10y ago
Not only does Dev stop, but the people that built the app, agreed on the specs and really understood it, all left too. Auto update is unfortunately something that's just not worth the risk in a lot of cases.
- tomelders 10y ago
  Thats called bad management.
  - tossedaway334 10y ago
    It is the reality of the situation in a vast amount of companies.
    - fuck_google 10y ago
      And its only going to get worse by disabling automatic updates.
    - CaptSpify 10y ago
      Only because we let them. I'm very much against auto-updating software, but I still don't see this as a good argument against them. It's not that companies can't keep up, it's that companies choose not to keep up. In this aspect, taking away their choice is the winning move, imo
      - tossedaway334 10y ago
        The only thing you do by "taking away their choice" is to force them to use alternatives that are not Google Chrome.
        CaptSpify 10y ago
        I would argue that's a good thing
- johnward 10y ago

nommm-nommm 10y ago

They used to, this is no longer the norm though. The norm is moving to patching systems regularly.

illumin8 10y ago

That doesn't mean this is a good practice. In fact, I would argue that this type of thinking has created far more harm than good for both the IT industry as well as the companies that adopt this harmful practice. Case in point: many of these same companies that refuse to upgrade systems for a decade or more are still running Windows XP and Server 2003. Due to the negligence of their IT leadership, they are now vulnerable to all types of security vulnerabilities that won't be patched, and have put both their business and their customer's private data at risk. This is no different than a state or local government refusing to maintain critical infrastructure like bridges and tunnels. Negligence might be viewed as conservatism for a few years, but when the bridge collapses because routine maintenance wasn't performed, it becomes clear that the administration who neglected maintenance was at fault. The sooner the cancerous idea, that IT software can be frozen in some golden state of perpetually providing business value with zero maintenance required, dies, the better. Modern, thoughtful IT leadership realizes the value in a continuously updated, secure browser. Chrome is already winning the browser war in the Enterprise for this reason alone. This just provides additionally needed controls like white-listed extensions that are known to be safe.

gajjanag 10y ago
> That doesn't mean this is a good practice. In fact, I would argue that this type of thinking has created far more harm than good for both the IT industry as well as the companies that adopt this harmful practice. > Case in point: many of these same companies that refuse to upgrade systems for a decade or more are still running Windows XP and Server 2003. Due to the negligence of their IT leadership, they are now vulnerable to all types of security vulnerabilities that won't be patched, and have put both their business and their customer's private data at risk. There are legitimate reasons for this though. The way I understand it, a big chunk of the problem is that many software vendors refuse to properly separate security related updates from regular updates. Firefox at least has an ESR version, AFAIK there is no equivalent for Chrome. See also attitudes like that mentioned in: https://news.ycombinator.com/item?id=9164251 https://news.ycombinator.com/item?id=9164251 Similar examples can be given for MATLAB - I know of many professors who ask students to run some old and fixed version of MATLAB for many years - they do not want to waste their time dealing with the breakage that inevitably happens with newer releases. If all vendors actually put in effort into maintaining LTS versions, the situation could be different. I do agree that the idea of perpetual business value with zero maintenance in a frozen state doesn't make sense - but as a business, I would always be interested in minimizing my maintenance burden.

heartbreak 10y ago

I'd say that this enterprise version of Chrome will finally fit in a financial institutions's baseline target for their patch management system. Take a look at page 45 (page 27 of the PDF itself): https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturity_June_2015_PDF2_c.pdf https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturit...