robryk @robryk@qoto.org

@freemo Silly me, didn't think of pasting URLs there. Anyway, I know that following users seems to work this way, so I'd assume that following all other followable stuff would also.

@freemo Seems to work. That said, I wouldn't know how to follow a single channel (because I don't really know what's the identifier that one should use for a channel as opposed to a user).

@freemo Haven't tried yet; will report back. I assume yes, but wanted to report that the "standard" way doesn't work.

@freemo It's not video.qoto.org's remote subscribe. It's remote subscribe of some other peertube instance (video.mycrowd.ca), where I wanted to subscribe using qoto.org (Mastodon) account.

@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).

@zleap @freemo @lucifargundam @Chrisleon27

This is an interesting linguistic principle (IIUC "only entities with agency can kill"; do I UC?). If we follow it always, I think we'll depart from the normal practice. For example:

Measles doesn't kill people (just people who give others measles or ones who are not careful enough and contract it).
High voltage doesn't kill people (just careless people kill themselves or others).
Dogs don't kill people (their owners do instead; though this is more borderline).
Bears don't kill people (people kill themselves by not avoiding bears well enough; this is way more borderline).

So, it seems that this principle isn't really applied very uniformly. My interpretation is that "X kills people" isn't a statement about reality, but a statement about best ways to avoid death/some sort of blame. I wonder if either of you have a different take on what that phrase means.

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.

@polychrome When would you want to use "Block"? Why note replace Block with Lie?

@freemo Note that HolyC is interpreted/JITed and used as the shell language in TempleOS. TempleOS really feels like a C-based LISP machine, if that makes sense.

@freemo In a similar vein: humans _produce_ a few hundred ml of water per day.

@moonbolt @timorl

I believe GIF is in the same situation: it used to be patented, with some not-very-clear general licenses, and patents have expired.

I understand the wish not to use things that weren't intended to be publicly usable by their original inventors' company, but do realise that this class of things contains many more things than one might think and that the limited lifetime of patents is designed precisely to allow such usage regardless of those wishes after some time.

@moonbolt @timorl

If one doesn't care about interoperability, why would one need to follow the standard exactly? Besides, there are lots of implementations of that standard with available source code, from which one can learn how the thing actually is supposed to work.

If I understand the Wikipedia article correctly, and if the article itself is correct, it used to be important (because anyone implementing some part of the standard was granted a license to some patent), but that is no longer the case (because the patent expired).

@freemo Which are the reasons that we've learned the hard way that would still apply to ships? I thought we learned the hard way that building them near a shore is bad due to flooding risks, but that doesn't apply to ships that can move away from the shore.

In the responses you mention that containing leaks is easier on land, and that ships are less secure (are they less secure than land vehicles?). I don't think these are lessons that we learnt the hard way, so were you referring to something else too?

@lucifargundam @freemo What does the HDD light (I presume) have to do with detecting a failing HDD? I would expect that the typical reason for a "stalled" computer is that you are using more RAM than you physically have, but less than the amount of swap space you have, so your RAM is effectively working at HDD throughputs and latencies.