sigh It's only funny and ironic if you think that Chrome needing a restart is exactly the same as Windows needing a restart. You're a smart guy, I'm sure you don't think that.
But, for what it's worth, I do think Chrome's update process could be even better. I have a copy of Joe Zobkiw's "A Fragment of Your Imagination" gathering dust on one of my bookshelves; it was a primer on building applications with plugin-style ('code fragment') architectures for MC68k and PPC. It was written in 1995, and with just a little bit of tweaking, it would have been possible to use the text in the book to build applications which could do hot upgrades.
So this was a solved problem, in 1995 at the very least. And that's ignoring the microkernel example that Linux has blessed us with for so many years.
That 17 years have passed and companies with Google's resources still can't build their applications that way makes me really grumpy.
> I have seen a Windows 2003 small business server running on hardware from 7 years ago and it never took more than 10 minutes for it to apply updates even 3 or 4 months late.
Never mistake your experiences for everyone else's experiences!
OK, story time. Quick background: a good corporate client of ours got a new administrative manager, he accepted bids for a big-deal network & server upgrade instead of sticking with the relationship we had with the client, they ended up going with another outfit which sold them a wickedly overpriced server running SBS 2008, Active Directory, Exchange, the works. Some of the knobs were turned the wrong direction and even after sinking a lot of money into it the server couldn't do what the client wanted it to do in the first place. So we inherited a mess not of our design.
We eventually get everything back to a stable state, and decide a while later that we should probably get the server caught up on updates. Now, the one nice thing about SBS 2008 updates is that the server will continue its AD and sharing services while it's preparing for shutdown and installing updates. The bad thing about it is that it doesn't give any time estimate and there's no sane way to cancel the update process once it's started. So, we make arrangements with the client -- they don't have failover for this -- and start the update process on a Friday afternoon.
8 hours later the update process finishes. I had a really unhappy tech at that point. It's a secure facility, we're not supposed to have any external or remote access, somebody needed to babysit the stupid thing on-site the entire time. Plus, we bill by the hour, so client's not super happy either. But, industry says we can't not install updates, right?
So, a week later, we schedule the next round of updates. And it looks like it's going to do the same stupid thing again. Again, no ETA, no way to do just some of them and the rest later. No, it's just, "Now installing update 5 (of 70)...". For hours. I don't want to ruin my tech's Friday night for the second week in a row, so I tell him to go home and I make arrangements to be there first thing Monday morning to make sure everything's copacetic.
On Monday morning, it wasn't. The update process had stuck somehow, somewhere around 59 of 70 or something like that. The server had never rebooted, we couldn't tell if it was truly stalled or if the update process was still continuing but just really really slow. Despite the huge warnings to the contrary, we had little choice but to hard reboot the stupid thing and do damage control afterward. Everything turned out OK, but there's nothing that'll move your breakfast through your bowels quite like rebooting a big client's "everything under one roof" server in the middle of an update.
So.
Go ahead and tell me how Chrome's update process is just like that. :-)
>Never mistake your experiences for everyone else's experiences!
Perhaps you should do the same thing! The said Windows 2003 SBS server running from 2005 running AD never had any issues, not even a hardware one which is very surprising and is up to date to this date.
There can be very many reasons for your experience including software configuration, corrupted files, bad RAM etc., but which one of our experiences is typical? Yours or mine?
>Despite the huge warnings to the contrary, we had little choice but to hard reboot the stupid thing and do damage control afterward. Everything turned out OK, but there's nothing that'll move your breakfast through your bowels quite like rebooting a big client's "everything under one roof" server in the middle of an update.
Operating systems are extremely complex beasts and some have issues even with something as tightly controlled hardware and software like OS X or iOS. Comparing them to a browser is not really fair.
But, for what it's worth, I do think Chrome's update process could be even better. I have a copy of Joe Zobkiw's "A Fragment of Your Imagination" gathering dust on one of my bookshelves; it was a primer on building applications with plugin-style ('code fragment') architectures for MC68k and PPC. It was written in 1995, and with just a little bit of tweaking, it would have been possible to use the text in the book to build applications which could do hot upgrades.
So this was a solved problem, in 1995 at the very least. And that's ignoring the microkernel example that Linux has blessed us with for so many years.
That 17 years have passed and companies with Google's resources still can't build their applications that way makes me really grumpy.
> I have seen a Windows 2003 small business server running on hardware from 7 years ago and it never took more than 10 minutes for it to apply updates even 3 or 4 months late.
Never mistake your experiences for everyone else's experiences!
OK, story time. Quick background: a good corporate client of ours got a new administrative manager, he accepted bids for a big-deal network & server upgrade instead of sticking with the relationship we had with the client, they ended up going with another outfit which sold them a wickedly overpriced server running SBS 2008, Active Directory, Exchange, the works. Some of the knobs were turned the wrong direction and even after sinking a lot of money into it the server couldn't do what the client wanted it to do in the first place. So we inherited a mess not of our design.
We eventually get everything back to a stable state, and decide a while later that we should probably get the server caught up on updates. Now, the one nice thing about SBS 2008 updates is that the server will continue its AD and sharing services while it's preparing for shutdown and installing updates. The bad thing about it is that it doesn't give any time estimate and there's no sane way to cancel the update process once it's started. So, we make arrangements with the client -- they don't have failover for this -- and start the update process on a Friday afternoon.
8 hours later the update process finishes. I had a really unhappy tech at that point. It's a secure facility, we're not supposed to have any external or remote access, somebody needed to babysit the stupid thing on-site the entire time. Plus, we bill by the hour, so client's not super happy either. But, industry says we can't not install updates, right?
So, a week later, we schedule the next round of updates. And it looks like it's going to do the same stupid thing again. Again, no ETA, no way to do just some of them and the rest later. No, it's just, "Now installing update 5 (of 70)...". For hours. I don't want to ruin my tech's Friday night for the second week in a row, so I tell him to go home and I make arrangements to be there first thing Monday morning to make sure everything's copacetic.
On Monday morning, it wasn't. The update process had stuck somehow, somewhere around 59 of 70 or something like that. The server had never rebooted, we couldn't tell if it was truly stalled or if the update process was still continuing but just really really slow. Despite the huge warnings to the contrary, we had little choice but to hard reboot the stupid thing and do damage control afterward. Everything turned out OK, but there's nothing that'll move your breakfast through your bowels quite like rebooting a big client's "everything under one roof" server in the middle of an update.
So.
Go ahead and tell me how Chrome's update process is just like that. :-)