3 ms·

>I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation. You're giving th

>I'm pretty sure that it's rather unlikely that Mozilla has a major screw up in the Gecko rendering engine or their javascript implementation. You're giving the Firefox guys too much credit. Bugs do happen even in web browsers and not all corporate websites are made by people that don't know about programming or standards. The thing is: somebody pays (sometimes a whole lot) to use an webapp and you have to guarantee that your site will work for him on a given browser version. This means you actually test the product in various ways. You can't just put blind trust into Firefox that is will just be perfect from now on. >Even if so, the accelerated release cycle will ensure that it'll be fixed right away. Yeah, and who pays for the downtime, losses, etc. in the mean time? As an user I like Chrome and I see the value of having it autoupdate on my parent's computer so I don't have to manage that myself. But in a corporation some pretty big money are starting to depend on browsers so you can't just believe new updates won't subtly break something.

eftpotrm 15y ago
While I don't dispute the honest good intentions here, I do, strongly, dispute the cost benefit analysis. They're testing every last security fix, every last point release, every last sneeze from the platform vendors against everything in their entire app pool. That might've been viable Way Back When; now, I doubt it. There's just too much changing at too many levels. What about if the user combines this service pack with these security fixes but not that one, this particular browser release, running over a remote link with either a 3G modem or a home firewall and a particular model of router? Bugs happen, both in the platform and in the app. I've had my code suddenly fail due to a new version before, too. Once, in ten years, and a dev team of two had a fix up and running in a few hours. What's the cost to the business to run all this checking? What's the cost to the business to be running older, less secure, less featureful versions of the software? What would be the cost of the likely scale of failure if they were broken by a new release (factoring in the very, very low likelihood of that happening)? What would be the business interruption cost of having the app down? What would be the opportunity cost of having to pull developers off their other projects and push them quickly onto fixing this internal app? If it's an internal app, you've likely got a small enough, contained enough userbase that it's manageable for you to have a short period of downtime occasionally - I've never known such a service that didn't, frankly. If it's a public app, good luck to you trying to tell your customers they can't use this new version. If it's a third-party app, that's their problem. If Oracle want to tell me their latest, greatest, very expensive CRM dashboard isn't compatible with a new browser point release, exactly what am I paying them all that money for? Stop being officious. Stop being risk averse beyond reason. Look at the actual numbers and just let it run.

eftpotrm 15y ago

While I don't dispute the honest good intentions here, I do, strongly, dispute the cost benefit analysis. They're testing every last security fix, every last point release, every last sneeze from the platform vendors against everything in their entire app pool. That might've been viable Way Back When; now, I doubt it. There's just too much changing at too many levels. What about if the user combines this service pack with these security fixes but not that one, this particular browser release, running over a remote link with either a 3G modem or a home firewall and a particular model of router? Bugs happen, both in the platform and in the app. I've had my code suddenly fail due to a new version before, too. Once, in ten years, and a dev team of two had a fix up and running in a few hours. What's the cost to the business to run all this checking? What's the cost to the business to be running older, less secure, less featureful versions of the software? What would be the cost of the likely scale of failure if they were broken by a new release (factoring in the very, very low likelihood of that happening)? What would be the business interruption cost of having the app down? What would be the opportunity cost of having to pull developers off their other projects and push them quickly onto fixing this internal app? If it's an internal app, you've likely got a small enough, contained enough userbase that it's manageable for you to have a short period of downtime occasionally - I've never known such a service that didn't, frankly. If it's a public app, good luck to you trying to tell your customers they can't use this new version. If it's a third-party app, that's their problem. If Oracle want to tell me their latest, greatest, very expensive CRM dashboard isn't compatible with a new browser point release, exactly what am I paying them all that money for? Stop being officious. Stop being risk averse beyond reason. Look at the actual numbers and just let it run.