robryk @robryk@qoto.org

@freemo MathJax issue: https://qoto.org/web/statuses/107122108820756990 renders as lots of whitespace and broken text in 3 column view for me. Screenshot attached.

When I look at the DOM, I see lots of spans with font size of 800%~900%.

I was slightly wrong. In actuality, \(I = C_1^T*J*C_1 + C_2^T*J*C_2\) for some \(C_{1,2}\). I should write it up fully, which I'll do soon (tm).

An easy way to see why the original was wrong is that this is the difference between \((a^T+b^T)M(a+b)\) and \(a^TMa+b^TMb\). I could have also been clued in by the impossible properties I claimed C has in [1].

Why the standard way to describe rotational inertia of a body is to specify its moment of inertia matrix?

Moment of inertia matrices are somewhat weird: not every symmetric semipositive-definite matrix is a valid moment of inertia matrix (note that there can be no body that has nonzero moment of inertia about exactly one of its principal axes).

Moment of inertia matrix is expected to satisfy I_{around e} = e^T*I*e [0]. At the same time I_{around e} = \sum m_i*r_{perp to e}^2 = \sum m_i*(r_{b1}^2+r_{b2}^2) where b1 and b2 are some orthogonal basis of the surface perpendicular to e.

This creates a natural idea: if we define J := \sum m_i*r_i^T*r_i, then I = C^T*J*C (see [1] for value of C), _and_ every semipositive definite J corresponds to an object that could possibly exist.

So, why don't we use this J instead of I? I think it is less confusing, and seems to be way better e.g. if we're numerically trying to find a moment of inertia that optimizes for something.

[0] So I = \sum m_i*||r_i||^2*Proj_{perp to r_i}^T*Proj_{perp to r_i}

[1] C = \sum_{i != j}e_i^T*e_j (btw. it's not immediately obvious to me that this definition is invariant wrt orthonormal base change, and if you have a succinct description of why it is so, I'd appreciate seeing it)

When a vertical stream of liquid is high enough, usually the stream starts to fragment into drops. The standard explanation for that that I believe is that the falling liquid is sped up, so the stream narrows, and at some point the stream is narrow enough that droplets are a lower energy state from a surface tension POV.

I today noticed that streams of my shower gel either never fragments into drops, or they require a height that I cannot provide before that happens.

Imagine a ball (of uniform density) rolling on a horizontal plane without slipping. Due to its symmetry its angular speed in the reference frame of the plane will remain constant over time if it's not disturbed[1]. Its angular speed has three components. What I found surprising (but is obvious if we present it this way) is that by only nudging the ball horizontally you can't get it to spin around the vertical axis: so, horizontal nudges allow one to explore only a 2d subspace of the 3d space of the angular speeds.

tl;dr I got surprised by a consequence of the fact that while rotations around different axes do not commute, infinitisemal rotations (and thus angular speeds) do commute.

[1] If its density was not symmetric, it could undergo precession and nutation.

@freemo qoto's Webfinger seems not to allow cross-origin requests, or at least Firefox thinks so.

When I try to use PeerTube's remote subscribe feature in Firefox (I tried to use it on video.mycrowd.ca), it fails and I see that a request to https://qoto.org/.well-known/webfinger?resource=acct:robryk@qoto.org has failed due to "CORS Allow Origin Not Matching Origin".

When I inspect response headers that trigger this, I see that they do contain "Access-Control-Allow-Origin: *" header, which should be enough to declare that the response can be provided across origins. However, the header is sent twice.

What I suspect is going on is that A-C-A-O is only supposed to have a single value. Specifying it twice is equivalent (according to HTTP spec IIRC) to specifying it once and concatenating values separated with a comma. "*,*" is not a value of A-C-A-O that allows cross-origin access, so Firefox refuses to provide the response back to the cross-origin requester.

Could you figure out why qoto is sending two copies of A-C-A-O in its responses? You can trigger that behaviour by doing `curl 'https://qoto.org/.well-known/webfinger?resource=acct:robryk@qoto.org' -H 'Origin: https://video.mycrowd.ca' -v`. Note that if the request has no `Origin` header, the reponse has only one A-C-A-O header.

How did spacecraft orient themselves using what was available in 1960s?

The obvious thing for things in Earth orbit is to find the Earth horizon and Sun; maybe find the direction the radio signals arrive from and/or their polarization.

If we are further from Earth, we need to figure it out before we can communicate, so the radio signals approaches don't work. Similarly, there's no horizon to speak of. Yet we managed to do it in 60s.

The first thing we can do is find Sun (simple: the brightest thing around) and Earth. How do we find Earth with no camera and no image processing? We know how far in angular distance we expect Earth to be from sun. So, we point an axis of our spacecraft at the sun and slowly rotate, while a photometer points at the correct angle off that axis. Once the photometer finds something bright enough (and not too bright), we stop the roll and keep tracking that bright thing, assuming it's Earth. We could (I don't know if that was ever done) instead use a radio receiver with an antenna that's angled in the same way.

What if the angular distance between Sun and Earth is too small (so that we wouldn't be able to get any sensible accuracy in the roll direction)? We do the same roll-and-observe-photometer trick to find Canopus, a very bright off-eclipctic star (it's in the southern hemisphere -- -50deg declination -- which is why e.g. I haven't ever knowingly seen it). It being off-eclipctic ensures that occlusions are rare, and it being _very_ bright makes it hard to confuse it with any other start (we discriminate by brightness and angular distance from the sun).

I knew about the concept of star trackers, but for a long time didn't know how they searched for the star. Picking the second brightest star (well, third) and constraining the sun-star angle is what I was missing.

Ref: https://ntrs.nasa.gov/api/citations/19750002096/downloads/19750002096.pdf (+ interesting details on how do we set up remote overrides for systems that are necessary for communication to happen using 60-70s technology

BTW This write-up ignores the questions of accuracy nearly completely; in part because I'm still confused how did the photoresistor-based sun trackers achieve an accuracy of a tenth of a degree (their fine alignment relied on driving the attitude so that two resistors' resistances were equal; I would expect their bias to creep due to some hard-to-predict differences in aging of different photoresistors, whether due to manufacting defects, or something as silly as different amounts of dust impacts, because the direction of motion wrt local dust was pointed in some slowly-changing direction wrt Sun and Canopus).

T(or rather, on a recent day)IL: If you have an electronic device with more than one fuse, you should galvanically isolate (e.g. via optocouplers) signal lines between the areas powered via those fuses. Otherwise, if one fuse blows, you'll end up powering the part of the circuit behind the blown fuse via signal lines and ESD/overvoltage protection diodes (that are connected from the signal lines to positive power rail, to limit the voltage on the signal line).

You _can_ get away without galvanic isolation (e.g. by putting resistors in series and accepting the current that can be drawn through that resistor at ~your VCC), but that is harder to reason about, and potentially requires testing of many combinations of blown fuses.

Forgot to ask: Do you have similarly confusing riddles (maybe about something other than physics)? I would love to hear some.

A colleague mentioned today that the April Fools tradition of pranking unsuspecting people into believing something false can be very unwelcome on the receiving side. That made me think of better ways to observe April Fools and I think I've found a slightly Discordian one that I wish I'd thought of years ago.

Let's share puzzles/riddles that often leave the listener very confused and help them realize that something they might have believed about the world is inaccurate. I think it's much better, because it's educational, there's no temptation not to ask the recipient whether they wish to take part beforehand, and I don't expect recipients to feel like they're being made fun of.

Let me start with a physics puzzle I'm fond of:

Consider a car that travels northward with speed v. Assume there are no losses (no rolling friction, vacuum, etc.) so the car travels at constant speed with engine off. At a point in time, the car engages its engine and speeds up to 2*v northward. How much work did the car engine do?

Well, we can compute the increase of car's kinetic energy: m/2*((2v)^2-v^2)=m/2*3v^2

Alas, let us consider a different (inertial) reference frame: one that moves northward with speed v (note that it's not tied to the car, even though it starts stationary in it). In that reference frame the car sped up from 0 to v, so the increase in car's kinetic energy is m/2*v^2.

What gives? How much energy did the engine actually have to use to speed the car up?

h/t to Ryszard Zapała, my HS physics teacher

#freecad I'm trying to design some pretty simple shapes using FreeCAD (using Part Design and Sketcher) and I keep encountering weird issues, including things that look like caching problems (I need to twiddle a value back and forth to see effects of other changes reflected) and outright crashes (https://tracker.freecadweb.org/view.php?id=4523 and another that boils down to "this file crashes FreeCAD if I try to edit ~anything in it").

I am most likely using it in a weird way. However, I didn't expect that amount of issues (esp. crashes) even if I was using it completely incorrectly. Is it expected that FreeCAD will be crashy-when-used-weirdly, or maybe is it the fault of my distro (NixOS), or something else?

If only I didn't want chamfers, I would just use solvespace. Unfortunately, chamfers on non-side edges of extrusions are very annoying there.