On the terraform comment, things that change together ship together is a good mantra.
If you keep having to make edits in two independent systems every time you want to make one change, something is wrong. If you’re leaving footguns around because changing one thing affects two or more systems, but you aren’t at liberty to change them both in production, that’s also something wrong.
Right, but you have to consider the cost of incorporating bug fixes without fully testing them. That too can introduce new failures that are noticed by customers first.
They mean the K in KVM could trivially have a keylogger. For the computers attached to that KVM. Audio is for logging for computers not attached to the device in question. Which could be up to and including a whole server room save a couple machines.
Ultrawideband never caught on because it turns out that the speed of light and sound in air is frequency dependent, so you have to know the distance to the target pretty accurately and then skew the signal to send or receive. (Imagine a phased array antenna but also with a frequency domain to work out as well).
But that doesn’t mean you can’t make it function in a loud server room. The whole point of it is working in and around noise.
Microphones and LEDs have been used famously for side channel attacks and also to circumvent air gaps. From a Least Power point of view this is troubling.
Someone last winter was asking for help with large docker images and it came about that it was for AI pipelines. The vast majority of the image was Nvidia binaries. That was wild. Horrifying, really. WTF is going on over there?
Something I only figured out in the ‘10s is that the main tax of code smells is during debugging. Debugging when taken to the level of art is less about sorting all of the possible causes for a problem by likelihood but by ease of validation.
Things that are cheap to check should be checked first unless they are really unlikely. You change the numbers game from trying to make the biggest cleaving lines possible, to smaller bites that can be done rapidly (and perhaps more importantly, mentally cheaply).
Code smells chum the waters. Because where there is smoke sometimes there is fire, and code smells often hide bugs. You get into Tony Hoare’s Turing award speech; either no bugs are obvious, or there are no obvious bugs.
So I end up making the change easy and then making the easy change because we have more code each week so the existing code needs to be simpler if someone is going to continue to understand the entire thing.
Perl doesn’t seem to have figured this out at all.
The big pearl of wisdom I took from Larry Wall seemed to be counter to the culture I experienced looking in from the outside. That always confused me a bit about Perl.
And that was, paraphrased: make the way you want something to be used be the most concise way to use it and make the more obscure features be wordy.
This could have been the backbone of an entire community but they diminished it to code golf.
> if difficulty itself becomes a badge of honour, you've created a trap: anything that makes the system more approachable starts to feel like it's cheapening what you achieved. You become invested in preserving the barriers you overcame.
The mentality described here has always galled me. Half the reason I’m willing to scramble up these hills is to gain the perspective to look for an easier way up the next time. It’s my reward for slogging through, not for the gathering of sycophants.
I’m not sure you’ve mastered a thing until you’ve changed the recipe to make it a little bit better anyway. My favorite pumpkin pie recipe, isn’t. As written the order of operation creates clumps, which can only be cured with an electric mixer. You shouldn’t need an electric mixer to mix pumpkin pie filling. If you mix all the dry ingredients first, you get no clumps. And it’s too soupy. Needs jumbo eggs, not large. So that is my favorite recipe.
But maybe this is why I end up writing so many tools and so much documentation, instead of hoarding.
If you keep having to make edits in two independent systems every time you want to make one change, something is wrong. If you’re leaving footguns around because changing one thing affects two or more systems, but you aren’t at liberty to change them both in production, that’s also something wrong.
reply