https://gist.github.com/yunfachi/6c073cc6edc18f78cfc60bb9bb3f7143

Osmand?

You’re assuming it is useful enough to find the person, and not just A person.

What’s scary here is the lack of training/understanding on the investigation side… This is just ignorance.

the family deserves to know that we tried everything

Like, have you tried praying? We don’t have any data, so it may be effective.

I run RSS2email and… read my RSS as emails, delivered fresh every morning :)

https://github.com/rss2email/rss2email

Grats, looks like a capable system 😃

Been using self-hosted, static website builder https://simonrepp.com/faircamp/ with satisfying results here

Keep instance small, with all users in the same timezone. Use NixOS, let it update everynight automatically and safely. It’s good enough for a small service, downtime is mostly when people are sleeping.

Try again elsewhere, you’ll eventually find the right place!

Assembling a second dynamics (analog compressor). First one took me over 8h of work.

Mastodon is part of Lemmy?

At this point though, you might as well skip AI and commission an artist (photographer, painter, fx).

I hope you understand how this is discouraging: at present, federation is anything but straightforward.

There’s also a question of perspective. If you approach federation with the mindset that it will be like the sort of SSO you get with using google products, microsoft ecosystem, or facebook to log in to many websites, then yes: it’s doesn’t look straightforward.

If you approach it with the perspective that the coupling between fediverse applications being more loosely coupled, and have the way email work in mind, then it is actually more natural. Each application can do their own thing, and provide all or partial compatibility with the fediverse. Think of a blog application, which rely on the fediverse only for the comment section of each blog posts, but also does other things specific to that application. Taking the example of email again, nobody thinks they should be able to log-in to microsoft outlook using their gmail account, or to gmail using their home-made account, in order to read and send emails.

There’s a narrative aspect to it too.

Wouldn’t that overload popular instances even more? Right now, popular instances only need to accommodate their users, but with a “fediverse-wide” auth, soon they’ll also have to serve content to people who followed that popular link to their content?

Is it so desirable to sent even more info, this time potentially non-public, if you decide to interact with the other instance?

This includes partial information about your online identity, namely identifying you uniquely. Not all instances should be considered trustworthy, so your log-in token may get re-used by a malicious instance to post things in your name here and there. Kind of a silly situation, favorable to spammers for example.

Have you tried the archive link? There’s no need to sign in with it

Users can already do so, what would instance-level block bring?

I’ll let you compare the nix 2.4 manual page (https://web.archive.org/web/20211201073051/https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake.html) with the current one (https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake.html).

The flakes interface of nix may change in the future, and you should be prepared to update your code, documentation etc. if and when that happens. Consider flakes have been around since nix 2.4 and the interface haven’t drastically changed since then. If that risk sounds acceptable to you, then do use it :)

There is an ongoing effort to get flakes away from the experimental category, but as you may guess, it is a big chunk to stabilize all at once. The original RFC was closed https://github.com/NixOS/rfcs/pull/49 a long while ago, due to it describing the experimental feature, and not the final one. AFAIK, there’s no “one” RFC being discussed on finalizing an initial stable version of flakes (but I could swear I’ve heard of one).

I had “weathering steel” in mind, butt you’re right, even in this case, rust still eats at it, just slower.