robryk @robryk@qoto.org

@chjara TBF some of those are just dependencies of others. If you insist on listing dependencies, then HTTP should also be on the list.

@timorl So, actually, everything gets significantly easier if you have access to locations that collectively cover all the sensors with their line of sight and have some slightly larger available electrical power (I'd expect that it's impractical to provide each sensor with a solar panel that will actually work without maintenance).

In a way also all solutions that I know of rely on something of that sort: but those places are possibly managed by other people (e.g. cell towers or TTN gateways).

Another possibility to consider (which wouldn't work at all for my purposes) would be a store-and-fetch system: you have sensors that store measurements and have a moving station that queries them for results. In that setup the largest problem is having the sensors be ready to receive when the station arrives without wasting lots of power.

Oh, one thing you might find not intuitive: time spent receiving (or listening for a signal that doesn't come) costs at least an order of magnitude less power than as time spent transmitting. IOW, listening is very much not free.

@petros

@timorl s/during Covid/during lockdowns that meant that outdoor swimming pools were closed/ @petros

@timorl Yes.

So, the story is that during Covid I wanted to be able to learn the temperature of a small lake ~5km away without cycling there each time. I asked around at work, and the conclusion was that (a) LoraWAN as the reporting protocol makes most sense (i.e. will allow for a multi-year operating time from a single cheapish battery) (b) The Things Network is a reasonable way of using some community-provided receivers to relay those reports to the Internet. Notably it was strictly better than:
- mobile (_much_ higher energy consumption),
- Lora to a receiver of mine (which would need to be in ~line of sight),
- WiFi (energy consumption + range),
- BT 5.0 (no community-provided network of relays).

I ended up using https://www.dragino.com/products/lora-lorawan-end-node/item/155-lsn50-v2.html (a version with a temperature sensor provided). That device has a couple (3?) ADCs. You can connect w/e you want to them and it comes in a box with a waterproof (the box is IP68) cable gland. Default firmware is reasonable, and is open source.

Downsides:
- people who have designed The Things Network do not understand how to design distributed systems and have taken design choices that unforcedly make interfacing with it annoying,
- the standard feedback loops ("allow the relay to tell you how to adjust your bitrate, if you don't hear back from any relay for long enough decrease it") seem to be broken in situations when the constraining factor is not attenuation but collisions[1] and also are divorced from the choice of sampling rate,
- (not a downside, but missed opportunity) the data transmitted _by that device's default firmware_ is just one sample at a time; it would make much more sense to transmit stuff like most recent sample + averages over last {hour,day,...} to get more useful data in face of packet loss.

My particular setup fell into disrepair when I stopped having a need to use it, and at some point packet loss skyrocketed. I suspect that a relay in the vicinity disappeared, but due to annoyances around a long-ongoing migration in The Things Network I couldn't tell (all the relevant relays were using The Old Thing, so The New Thing didn't report their identity apart from saying that this packet was received by The Old Thing... did I mention that I was annoyed by TTN?).

[1] using lower bitrate gives you a larger SNR, but also makes your transmission longer; thus, if the transmissions are not getting through due to collisions you should _increase_ bitrate.

@petros

@trisschen What is the expected behaviour? That they land in a temporary directory or that they don't touch the disk at all?

@chjara

See also https://1lib.ch/book/1335175/8d95b5

Nitpicking: the issue is inventing contraptions that generate heat (and have undesired side effects). A heat engine alone could be used with temperature differences that exist regardless.

So, apparently swiss aviation regulator has restricted the number of passengers on a single historic aircraft as a permanent safety measure (in response to an accident from 2018).

If we ignore the effect on the price (by way of reducing total passenger throughout), I think this actually reduces safety. Ensuring safety of an aircraft takes work that mostly doesn't change depending on the number of passengers. Thus, aircraft with fewer passengers require more effort per passenger. So if the amount of passengers remains constant, we end up with more work (incl. more work for authorities) for the same level of safety.

Is there a mechanism (other than reducing the total number of participants) that could cause this change to improve safety?

@pixel

> - people were harassed for adopting it, basically making the FFMC something "that admins adopt if they don't want to moderate content"

I don't get this part. If adopting it explicitly would invite any negative consequences for the admin, wouldn't ones who didn't want to bother moderating just not moderate and not adopt it publicly?

@pixel

I just learned of https://github.com/pixeldesu/fediverse-friendly-moderation-covenant (from the koyu.space's open singups announcement) and noticed the "this is from a bygone era" warning that you've added a few days ago. That warning confuses me: I don't understand what changes make it undesirable to adopt such rules. Would you mind elaborating a bit on that?

(Obviously feel free to not answer, or answer in any less public way if you prefer that.)

@koyuchan

I looked at the rules and was initially really confused about CWs for "Scary Bugs" (first reaction: huh? you really want discussion of security issues to be CWed?), until I realized you meant insects. :)

@moonbolt It just occurred to me that you might enjoy http://freefall.purrsia.com and might be unaware of it.

@chjara Yeah, then it's more likely to be actually an issue with the driver. I wonder how well specified that interface is, and whether userspace does something importantly different depending on which gpu is used.

@chjara Also, this might be a userspace bug. If the userspace continues to leak file descriptors or something like that, then kernel memory usage (accounted to that process, but still kernel) _will_ increase.

@chjara So it seems that the leak generates some process-associated objects that are actually destroyed with the process, but not destroyed when w/e in userspace requests them to be.

This isn't as weird as it might sound. For example, if vma (virtual memory area) coalescing (i.e. stitching together two adjacent mappings that happen to be equivalent to one mapping -- because they point at appropriately distant offsets in the same file) didn't work, the way Golang uses heap might cause kernel to keep creating more and more vmas, until they all get destroyed when the process exits.

Try looking at /proc/slabinfo and compare contents when the leak has leaked lots of memory and when it hasn't. (Slab is an allocator in kernel for objects of known and fixed sizes: if the leak is in one of those classes, then you can narrow down _what_ is leaking.) If you can find the leak there, it should be much easier to debug.

So, apparently not all dessicants are safeish to eat: CaO is apparently used as a dessicant (the reason it's not safe to eat is that it generated a surprisingly large amount of heat when reacting with water).

I'm curious why are dessicants from lime preferred (ever). The pictured bag is from a package of seaweed, which makes me doubly surprised: one might e.g. not notice that the dessicant bag has ruptured.

@luci Fully? Partially we kinda have them and, as can be expected, most problems are at the interface (or forced by the available interfaces).

Also, you might be amused by https://abstrusegoose.com/171