Related: spicy foods. I used to be basically intolerant of it but now hate eating non-spicy versions of foods I’ve grown accustomed to. Spicy peppers and hot chili powder have become a crutch for my otherwise mediocre cooking skills.

Mitochondrion

I mean… just rotate it 90 degrees ((()))

Corpse, Corps, Horse, and Worse

I will keep you, Susy, busy,

Make your head with heat grow dizzy;

Tear in eye, your dress you’ll tear;

Queer, fair seer, hear my prayer.

banger poem

Best I can tell from quick internet searches: Old English: wīfmann/menn (“female person/s”). The w rounded the following vowel giving a wo- pronunciation, which for some reason (umlaut?) stuck for the singular but not the plural. The spelling of the plural changed to match that of the singular in spite of the pronunciation.

* Everything here carries the caveat “in some dialects, …” because English

Nah, reach is a huge advantage. I’m not sure how rapier fencing differs from regulation sabre/epée/foil, but here’s my 2 cents from that perspective:

Smaller people are not, as a rule, substantially quicker than larger. If you see any difference in your experience, it’s likely a selection bias (shorter people have to be quicker to compete at the same level). The shorter person must enter the strike range of the taller person before the taller person comes within theirs and must be significantly quicker or more skilled to overcome that dead space. If the taller person can maintain a proper distance, gg. Taller people can also lunge farther, giving a wider active range.

Targeting is a smaller issue than you make it out to be; footwork and maintaining balance, which reposition the core, are at least as important as leaning to dodge, and advantage the taller person (longer legs = more movement range). If the taller person is coming from above as you say, they can just continue their slash (sabre) downward toward that less mobile core, or squat a bit deeper if the arc won’t reach. If instead you were referring to a poke, they’re either already targeting the torso anyway (foil) or whatever body part is most easily reachable (epée; still often torso, but cheeky wrist/arm strikes can be something of an equalizer here), and anyway they are already striking at a range that the shorter person cannot, making a successful counterattack more difficult.

Besides reach, a height difference is brutal when it comes to sabre fencing; the shorter person is restricted to targeting arms and torso (can’t reach the head easily), so the taller person can anticipate strikes from fewer angles. The taller person can come from any direction and has gravity on their side for own overhead strikes. Those suck to defend against.

So could we produce a surface tension-free water?

Homie dats a gas. Or supercritical fluid, which actually is indeed used for “washing” (SC CO2 is used to decaffeinate coffee). However, like others said, surface tension /= cleaning ability. Part of what soap does is increase the effective solubility of things that are not normally soluble.

This post made me go try something in clojure again and man I forgot just how fucking good the language is. Everything fits together so nicely.

Mr. fancypants with a garage over there. Meanwhile, ain’t no public chargers for miles around here.

you mean let.

and then letting Hindley-Milner do the rest

Committee members be like “Oh, I definitely read your thesis titled “New Palladium-Catalyzed Reactions for the Manufacture of Pharmaceuticals”. So what is the band gap of thallium antimonide doped with 5% polonium in foot-pounds per mol? Why aren’t you answering? Even my undergrads know this!”

Man I just built a new rig last November and went with nvidia specifically to run some niche scientific computing software that only targets CUDA. It took a bit of effort to get it to play nice, but it at least runs pretty well. Unfortunately, now I’m trying to update to KDE6 and play games and boy howdy are there graphics glitches. I really wish HPC academics would ditch CUDA for GPU acceleration, and maybe ifort + mkl while they’re at it.

So many solver solutions that day, either Z3 or Gauss-Jordan lol. I got a little obsessed about doing it without solvers or (god forbid) manually solving the system and eventually found a relatively simple way to find the intersection with just lines and planes:

1. Translate all hailstones and their velocities to a reference frame in which one stone is stationary at 0,0,0 (origin).
2. Take another arbitrary hailstone (A) and cross its (rereferenced) velocity and position vectors. This gives the normal vector of a plane containing the origin and the trajectory of A, both of which the thrown stone must intersect. So, the trajectory of the thrown stone lies in that plane somewhere.
3. Take two more arbitrary hailstones B and C and find the points and times that they intersect the plane. The thrown stone must strike B and C at those points, so those points are coordinates on the line representing the thrown stone. The velocity of the thrown stone is calculated by dividing the displacement between the two points by the difference of the time points of the intersections.
4. Use the velocity of the thrown stone and the time and position info the intersection of B or C to determine the position of the thrown stone at t = 0
5. Translate that position and velocity back to the original reference frame.

It’s a suboptimal solution in that it uses 4 hailstones instead of the theoretical minimum of 3, but was a lot easier to wrap my head around. Incidentally, it is not too hard to adapt the above algorithm to not need C (i.e., to use only 3 hailstones) by using line intersections. Such a solution is not much more complicated than what I gave and still has a simple geometric interpretation, but I’ll leave that as an exercise for the reader :)

Oh absolutely, I don’t blame KDE or arch repos lol. I did see that it was a KDE update but somehow didn’t clock the version number. I had it in my head that KDE6 was much farther off.

Didn’t realize this was happening and yay -Syu went brrr and it broke my shit. Probably doesn’t help that I’m running nvidia with linux (endeavouros). Wayland doesn’t work at all (black screen on login with only mouse ptr, wrong resolution), while Xorg is now much less smooth e.g. on the switching desktop animations. Moving windows around and in-window graphics are fine. Some graphical config stuff changed too; I’m still taking inventory.

I’m also currently playing with nvidia vs nvidia-dkms with different kernels to see if that solves anything.

EDIT: Looks like that my configuration was failing to set nvidia_drm modeset=1 correctly due to my unfamiliarity with dracut. Manually adding nvidia_drm.modeset=1 to my kernel cmdline makes Wayland work (and quite well at that), though Xorg is still laggy.

True Functional Programmers will probably correct my lack of nuance here, but my understanding is that the IO monad is basically just scribbling some category theory formalities on top of IO ops so that everything is still technically a pure function. You can think of the IO monad as representing the “state” of the rest of the universe outside of your program, which your program reads or modifies. As you pass through your monadic bind ops (i.e., as you read or write IO), the state is carried through implicitly and “modified” as appropriate. All functions, then, are just transforming data (i.e., either your program’s data or the rest of the universe), so everything is pure.

deleted by creator

:)

fails self-restraint check

gen β, not ß

• edited to correct a tragic ragey blunder

<esc> <esc> <esc> <esc> <esc> <esc> :wa! <cr>