The leap day system handles the mean, the leap seconds handle the variance around the mean. The need for leap seconds is not predictable—they zero out accumulated error.
My attitude has always been that code review is best thought of as the gate where code goes from being owned by the author to being owned by the team or project. The code I'm reviewing is not your code, it is code that is about to become our code.
Maintainability is a major factor in that, of course.
At least a few years ago (~2014), the fare search was actually nearly instant, but all major airfare search sites added a delay because customers had the impression they were getting a better deal when they had to wait. It seems like the delay has been dialed back lately.
I’m not sure why people are making a big deal of it. At my gym it took maybe 3 minutes. You tie a knot and show you know how to take up slack. And it only needs to be done once.
There is a second test for lead but most people take a class and get the lead card during the class.
The Debian images (https://raspi.debian.net/) haven't been updated recently and don't support the Pi 5 at all. And support for other hardware is inconsistent.
> As of 12:30am PST I have located the Box and successfully executed a Rickroll Injection Attack on the target system. Out of respect for the artist I will not be revealing the Box's location, but for any veteran Mission resident only a couple obvious locations exist.
It seems like every article about nix goes on and on about DLL hell. I've been using Debian/Ubuntu for 15+ years and never really experienced dependency hell. I guess maybe this is thanks to hard work by Debian maintainers and rarely needing to run a bleeding edge library, but also, why do we need to run bleeding edge versions of everything and then invent an incredibly complicated scheme to keep multiple copies of each library, most of which are completely compatible with each other?
And then when there's a security problem, who goes and checks that every version of every dependency of every application has actually been patched and updated? Why would I want to roll a system back to an (definitely insecure) state of a few months ago?
What problem does Nix solve that SO numbers (properly used) doesn't?
I have many of the same questions about Snap and even Docker.
I think the problem is that often the order you want it in a clean history is not exactly the chronological order it was developed. Eg you may build out a feature vertically, tweaking the interfaces between the components as you go along. But a clean, atomic git history would probably introduce each component in a finished state in separate commits.
The main issue is that on a longer branch, you have to fix all the rebase conflicts on the oldest commit. Then, if you changed something in the conflict zone, you fix it again on the next commit, because the next commit used to be based on something else. Sometimes git rerere can help with this, but I find it fairly unreliable (could be user error!) If you do a merge, you only need to resolve it all once.