Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> They take more than a year planning a big OS upgrade.

That sounds painful.

I think the author is really advocating for a faster feedback cycle. Imagine if instead of a big upgrade every X months, you had a tiny upgrade every day, which didn't require rebooting and happened in the background.

Breaking changes could surface the same day they were shipped and be rolled back or fixed.

Now imagine that conservative players also constantly upgrade, but always stay 6 months behind the bleeding edge, getting only releases marked as "tried and true". Eg, if something had to be rolled back or patched, they skip over the bad version.

Wouldn't that make upgrades much less painful for companies like you describe?



You do realize he's talking about a stock exchange? Even a millisecond downtime is unacceptable. Some things don't even need backup, others need testing on identical hardware in identical configuration before deployment. That's just the way it is.


To be fair, it's _unscheduled_ downtime that's not acceptable for a stock exchange. They have scheduled downtimes all the time. For example, as far as I can tell the NYSE is only "up" 9:30am-4pm local time, Monday to Friday, and not on certain holidays.

Now this does mean that you have to make very sure that the upgrade you start at 4pm on Friday will be totally done and bug free by 9:30am on Monday, of course.

And I agree with your larger point that in a situation like that testing done by someone else in a different configuration is of limited (though nonzero) utility.


I understand, and I admit I haven't done anything like that. But isn't it still easier to thoroughly test a day or week's worth of OS changes at a time than to test 6 month's worth or a year's?




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: