5 ms·
The third principle of Continuous Delivery is "If something is difficult or painful, do it more often". So, if leapseconds are actually painful for you, then m
by bradknowles 8y ago
The third principle of Continuous Delivery is "If something is difficult or painful, do it more often".
So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds.
OTOH, if you think leapseconds are painful now, just you wait until you postpone this pain and do it even less frequently.
- faho 8y ago>The third principle of Continuous Delivery is "If something is difficult or painful, do it more often". That only works assuming you need to do it at all. If leap seconds are useless (to the majority of users) or insufficient, not doing them is preferable to doing them constantly.
- planteen 8y ago> So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds. That is what a lot of organizations do, "smearing" the leap second since they know their systems can't handle the discontinuity. I think this shows that software has failed in general at handling leap seconds correctly. As another said, I think leap seconds are unnecessary complexity with the frequency at which they happen.
- ycombobreaker 7y agoOn the contrary, I think that the smearing behavior is an indication that leap seconds poison an otherwise-useful model of reality. The discontinuity is an annoying edge case driven by the fact that "time error" accumulates, so it seems to me that that a 1-day smear is a more natural approximation than an instantaneous discontinuity. That, and tuned for the attention span of human organizations.
- twic 8y agoThat principle is more of a koan than actual concrete advice. For example, deleting your entire codebase and firing all your developers is painful, but even the most continuous deliverer wouldn't advise you to do that more often.
- _jal 8y agoDo you also pee in front "wet floor" signs? Getting past pedantry, the advice is obviously about foreseeable, repeating parts of normal business, and it applies to more than devops. A long time ago (tail end of the "desktop publishing revolution"), I was a production assistant, and then manager at a magazine. We published six times a year. Towards the end of my first year there, I realized we had the same problems, right down to our Advertising Director's emotional meltdown, every. single. issue. After getting to know folks working at other magazines and people at our press, I noticed that the monthlies seemed to run smoother with less drama, and the weeklies were even better at it. Eventually I realized it was because they had to be. If there was some minimum amount of human drama that had to happen, it was forced into exhibitions that didn't disrupt the (tight) schedules. If last-minute changes from flakey advertisers came in, they didn't cause a firedrill, they just didn't run, because that issue is already on the press and we're talking about the issue after next now. And so on. The general principle is actually very straightforward, and applicable all over the place, including your personal life. If you have high-friction processes, devoting time and attention to them is the way you make them lower-friction processes. And while it may be possible to do that without doing things over and over until you get there, it probably is not possible for you to get there without repetition, else you'd not have the problem in the first place.
- saagarjha 8y agoDoesn't every company do this slowly as they replace code and developers?
- indigo945 8y agoThe obvious correction is to change the duration of a second such that a year is exactly $integer seconds long. While this will make the duration of second drift from year to year, that drift is so small that everyday devices like consumer-grade computers could just ignore it, provided they're NTP synced once every five years or so. Physicists can just keep using whatever they're using and call it by a different name. Ideal solution all-around.
- taneq 8y agoThe core issue is that the number of days per year is messy, so it's not possible to have a 'nice' number of seconds in a day and also in a year. The best solution is probably just to use a nice number of seconds per day and accept the fact that in 100ish years summer will start in March, not December. It's not like we need to build our entire society around planting and harvest any more.
- macspoofing 8y agoThat's not anywhere close to "the best solution"
- taneq 8y agoThis discussion isn't going to be very meaningful unless you wanna tell us what 'best' means to you.
- macspoofing 7y agoThat's fair. I simply can't see the best solution relying on getting rid of deeply ingrained culutural norms that span thousands of years.
- taneq 7y agoYeah, I can see that being an issue, at least until a decent proportion of humanity lives off-world. I can't see people living in the asteroid belts adding arbitrary leap-seconds. Of course, once you start dealing with astronomical distances and speeds, the whole concept of a single universal measure of time kind of goes out the window anyway so it's probably going to get worse, not better. :P (FWIW my definition of 'best' here is something along the lines of 'simple, no special rules or tinkering, gets translated to a human-readable local time on demand'. Which is pretty much how Unix epoch works, come to think of it.)
- taneq 8y agoThat third principle is about facing (and implicitly, automating) your difficult-but-necessary processes. Outside of that narrow scope it's terrible advice. Being in a car crash and converting a country from one system of units to another are both difficult and painful and you should do either as seldom as possible.