AFAICT, the noise is the point. The people with loud vehicles (and this includes the rattling bass and coffee can mufflers on low-end econoboxes) are selfish assholes, desperate for attention, often compensating for a failure in another part of their lives. "Loud pipes save lives" has zero data to back it up.

This is the sort of thing that tempts me - an enchanting vision, like something out of "Death on the Nile", only minus the death. Just a small floating hotel that takes you to interesting places, not a floating amusement park combined with buffet.

I might be misunderstanding your requirements; "embedded" can mean so many things these days. But what do you think of ECL (https://ecl.common-lisp.dev/main.html)?

This is exactly why I hew to squash+rebase. As I like to put it "I don't care about every little sneeze a developer had." Git has spoiled me with this, where I have the power to commit to my private repo anything I damn well please, but in the end I can clean things up and keep the central repo clean and bisectable[0].

Any VCS that doesn't offer these (squash, rebase, bisect) is a complete non-starter for me.

[0] - https://blog.carbonfive.com/always-squash-and-rebase-your-gi...

I have to ask, as someone into alpine touring and ski mountaineering (but not racing), what difference would backcountry skiing make to this advice? I imagine you'd need sharpening more often, due to twin factors of A) more rock and hard ice and B) really wanting that control on ungroomed (ie, icy) slopes at high angles.

I don't consider myself "really pushing it", but would like to have every ounce of control I can get when heading downhill. I'm enough of a beginner that I will often side-slip or even just hike completely down a slope I don't like the looks of.

As an amateur alpine tourist who is deathly afraid of that feeling of "loss of control" from incredible downhill speeds, this is exactly what I do.

That said, I'm here reading because I want to know if the heuristic for sharpening changes when A) one is mostly off-piste (rock, hard ice, etc) and B) really want those edges sharp for ungroomed (ie, icy) slopes.

I mean, everyone dies. Not that I'm elevating Mt. Everest climbers, but at least they're aspiring for something.

Now, if the message you're trying to get across is it takes more than motivation, and life is rife with failure, that I can get behind. But "don't try, there's no point" is the laziest, most self-serving twaddle ever to be uttered (and no, it's not Nihilism either).

Specifically, you can play with it yourself with a tool like ZynAddSubFX's (https://zynaddsubfx.sourceforge.io/) virtual keyboard, where you can enable microtonal under scale settings and tweak to whatever tuning you want (see https://www.youtube.com/watch?v=hdPPPeq82hw&t=669s for where the video above starts showing this).

A simpler and shorter video discussing the history of just intonation and equal temperament, with examples: https://www.youtube.com/watch?v=bCYcS57eCqs

The API security thing, yes, that makes sense. Personally, I run a number of servers for small groups where the sensitive stuff is SSL only - you won't even get an error going to port 80, other than the eventual timeout. But for reasons above, I cannot just turn port 80 off, and it's perfectly safe redirecting to 443.

"Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work."

Too true! I find it helps if I think of it as an engineering problem: "what can I say that will make these people not commit the same error again?" A bit dehumanizing and manipulative, but can be super effective at shifting away from blaming and belittling (almost never works), and towards mentoring.

Always, always assume this is the case - it might frustrate you to no end, but until you have conclusive evidence something is "wrong", it's best to ignore it and toodle along with whatever you're supposed to be working on (I always encounter these head scratchers when working on legacy code, my tasking being something unrelated).

Unless you're being totally earnest, this one reads like "I'll take it under advisement"[0]

[0] - https://getyarn.io/yarn-clip/ed82da6b-db48-49aa-a105-f190e63...

Nobody's perfect, but there are ways people can get better. Or just take advantage of tools that can help automatically catch these sorts of errors. This is precisely why people create regression tests and set them up to run in the CI/CD, to reject changes that break them.

As for being less of an asshole, no shortcuts with that - just exercise your empathy, put yourself in their shoes, take a deep breath, then go to bed. Tomorrow morning, if you still feel the need to pen a blog post, maybe write out a technical solution without assigning blame.

Communication always has been, and continues to be, the hardest part of software development.

This is a joke right? This is exactly how you calculate expected weight gain/loss.

What I find remarkable is how badly people want to ignore just how bad fast food is for you. They'll use anything to dismiss completely the whole debate.