Pray tell, what has a firmware bug got to do with the meaning of a power cycle counter, otherwise that in this particular case you can't rely on a faulty counter? Let's not deflect attention to strawmen.

Load Cycle Count and Power Cycle Count aren't the same thing.

I'm calling it stupid because if you don't know anything about the time between the power cycles, you can at best assume that the power cycle count is a low-quality proxy for powered hours.

For any claim that the number of power cycles itself is a predictor of failure, you'd need to, you know, power cycle a bunch of drives at various rates until they die, and see if merely power cycling it more often makes it fail faster. Only in such conditions would the power cycle mean anything. Otherwise it's stupid and let's just stop with the stupidity, okay?

Are people seriously just that stupid? It's the count of how many times you powered it up. It has nowhere to go but up. It's not an indicator of any failure, except to the extent that power-cycling the drive can have an effect on its lifetime and/or reliability. The article also pretends like this was some sort of a "drive quality" indicator. I think people somehow can't parse what simple words mean anymore :( SIGH.

(I'd call the parent a troll if the article didn't perpetuate this same stupidity. Maybe the article was a troll too.)

Sure, but with changing viscosity the sound propagation in the liquid changes - especially that the quality of the resonance in the liquid scales with viscosity (viscous damping!). The speed of sound in the liquid changes too, but the change in the 0-60C range is about a factor of magnitude smaller than the change in viscosity.

I concur. There's one in a science museum I go to often, and it never fails to make me feel wobbly.

Except when different pieces of news from the same freakin' lander are reported on different Twitter handles. That's when multiple accounts are counterproductive. I think that ESA's approach to PR is a bit broken.

It's not as if you can't be logged into the same Twitter account from multiple locations...

Code reviews only work in practice on code of known quality level. I stress that by "known" I don't imply "perfect" or even "high" - I only mean that it must be known. The code review process must be tailored to the quality of people who do the work.

There's no way to properly implement code reviews of code that effectively comes from random sources. Most of the time you'll be either wasting the time on code that's very good, or you'll miss some serious issues.

I meant the repeated code.

LISP is different because there's much less leeway if you're doing it "purely". It's uncanny that way. That's also why one can be very productive in LISP - with some experience, you have a much smaller solution space to explore and you don't need to waste time making choices that are very much irrelevant to the functioning of the code.

Not only you're not alone, this is a rather common physics experiment (or should be), but it doesn't have much to do with density - it doesn't change fast enough with temperature. But there is something about water that changes rapidly as you go from cold to hot water: viscosity.

Water's viscosity decreases rather dramatically with temperature - about 25% per 10deg C or so. The Reynolds number, a key descriptor of the fluid flow in a given situation, is inversely proportional to viscosity, with factor 1. Thus, in the flow of water in the tap, as you go from "cold" (around 10C) to "hot" (around 60C), the Reynolds number increases by a factor of ~3.5. In the turbulent flow, such a change is easy to hear.

Most of us actually have this skill and use it, perhaps without realizing it. We go a step further, though: we are passive echolocators. We don't click, but we listen for the multiple echoes of sounds that are emitted by other things, including other people.

I do. The updates are so few that splitting them between the lander and the orbiter is nuts. Similarly, a split between @esa and @esascience is nuts as well.

Very, very many. The same as if you have asked 20 authors to write a chapter describing those algorithms, they'd never be word-for-word identical.

Most programming is adapting the well-known data structures and algorithms to various less-or-more-boring real life problems. Even if you're working on a completely breakthrough project, like the ESA's Rosetta just-landed-on-the-comet mission, most of the implementation's code is like any other spacecraft code, done dozens if not hundreds of times before.

Yet, proficiency at all the low-level "drudgery" is what differentiates a professional from someone who just pretends and sneaks their way around. It's as if you were a pianist who can only play their own compositions but can't play any of the classical staples.