For iOS, Go Map!! (source) has a similar quests system. I don’t know how well they hold up to StreetComplete though, I’ve never used the latter.

Also, obligatory https://wiki.openstreetmap.org/wiki/How_to_contribute!

Ah, alright. Thanks for looking!

I wouldn’t even know how to hold a local music library on macOS these days. The app that used to be iTunes is now just called Music right?

Yeah. I have a local library consisting of some albums I bought, some which aren’t on streaming services, and some other stuff such as game soundtracks + also use Apple Music streaming. They complement each other really well.

The bingo one actually uses crossbeam channels instead of mutexes, so that’s nice. I haven’t looked too closely at it though.

I don’t think you can do too much about the Spectrum one if you want to keep the two threads, but here’s what I would change related to thread synchronization. Lemmy doesn’t seem to allow me to attach patch files for whatever reason so have an archive instead… https://dblsaiko.net/pub/tmp/patches.tar.bz2 (I wrote a few notes in the commit messages)

Just to give the reason for Rc<RefCell> in the current project. I’m reading in a M3U file and I’m going to be referencing it against an Excel file. So in the structure for the m3u file, I have two BtreeMaps, one for order by channel number and one by name. Each containing references to the same Channel object.

So basically it’s channels indexed by channel number and name? That one is actually one of the easy cases. Store indices instead:

struct Channels {
  data: Vec<Channel>,
  by_number: BTreeMap<u32 /* or whatever */, usize>,
  by_name: BTreeMap<String, usize>,
}

// untested but I think it should compile
fn get_channel_by_name(ch: &Channels, name: &str) -> Option<&Channel> {
  Some(&self.data[*ch.by_name.get(name)?])
}

Not for the built-in Eq derive macro. But you can write your own derive macros that do allow you to take options, yeah.

Do you have some public code you could link to that you’re having this issue with? There isn’t a one-size-fits-all solution for Rc/RefCell, I think.

Whoa nice, I need to keep this in mind.

Interesting. I can’t find anything about the FLAC licensing issues. Do you have a link?

(Also, correction — Wikipedia says macOS in general can play FLAC. I guess it’s just the Music app that can’t import them.)

Yep. Lack of format support is usually to blame on the one who doesn’t support the format. You can absolutely blame Apple for this too though, their apps can’t open e.g. Matroska video or FLAC.

And perplexingly, they don’t support uploading HEIC, their own image format of choice, on the web iCloud Photos. So there’s that too.

(At this point my music library is stored as ALAC because it’s well supported in both Linux and Apple’s OSes. Really wish it wouldn’t have to be that way though. Someone needs to tell them about ffmpeg.)

For example they used to have their own video container .mov

It’s always very very funny every time someone mentions MOV, because while it’s very similar to MP4, it’s actually an open format while MP4 isn’t (!). You actually have to pay for the MP4 standard document while Apple just gives you the MOV documentation.

Also at least taking a screen capture on macOS still gives you a MOV container, actually.

The article starts with a table of contents with the change highlights as the first item.

Now that I think about it, dovecot drops permissions for security reasons (login runs as the “dovenull” user). It’s probably not a good idea to try to circumvent that actually.

What do you mean by “more powerful” wrt CMake?

CMake is a turing-complete language with some APIs that Meson either doesn’t have an equivalent yet because it’s comparatively new (for example, until 2023, there was no built in way to get a relative path from two paths, and if you wanted that you had to shell out to an external program), or they aren’t going to add because it doesn’t fit their design.

Meson is (intentionally) limited in terms of extensibility, instead it tries to come with everything built in that you need, even down to specific library support like Qt, from what it seems like to me. For example, you cannot define your own functions, it ships builtin modules but does not allow other packages to provide their own (for example like KDE’s Extra CMake Modules), to name a few that I’m familiar with and why I was put off using it so far.

I have yet to see how actually limiting that is, going to try to move the project I’ve been working on for years that relies on some of these CMake features to Meson soon and see how it fares. But considering that big projects like GNOME use it all over the place it’s probably workable in practice, I’ll just have to rethink the existing approach a bit.

Is that considered bait?

Wasn’t it? Go’s build system is very much not what I would call an example of good design (exhibit A: load-bearing comments and file names).

Nice!

I meant that for my one IP address, I set it to have a PTR to multiple domain names.

Don’t do that, yeah. If set it should always point to one domain name, the canonical name for that host, and the domain name should resolve back to that IP.

See https://serverfault.com/questions/618700/why-multiple-ptr-records-in-dns-is-not-recommended

Try Meson first, it should support compiling GNU assembly via the C compiler from what I can find. I’ve been using CMake for years because it is more powerful (finally trying out Meson though for a new project) but in contrary to Meson it is easy to use the wrong way if you don’t know what you’re doing. Meson is very clean in comparison, and also very easy to get started with. (And both these are absolutely better than autotools)

(If only c++ build systems caught up to Golang lol)

Terrible bait

Try this I suppose

userdb {
  args = username_format=%n /etc/passwd
  driver = passwd-file
}

And maybe similar with passdb and /etc/shadow?

What do you have your passdb set to if you don’t mind me asking?

The defaults. Doesn’t show up in doveconf -n.

Currently I have multiple PTR records for all the subdomains I’m using, which hasn’t caused problems yet…

Wait, what? PTR is set on an IP address, not on a domain name. It should resolve to the canonical domain name of the host behind that IP.

Your postfix is set to deliver to lmtp:unix:private/dovecot-lmtp so you need to create the socket there:

 service lmtp {
-  unix_listener lmtp {
+  unix_listener /var/spool/postfix/private/dovecot-lmtp {
     group = postfix
     mode = 0600
     user = postfix
   }
 }

(though for me the path is /var/lib/postfix/queue/private/dovecot-lmtp. YMMV)

What would you suggest I set the PTR record to?

Set system hostname, PTR, and myhostname to NAME.domain.com where NAME is a unique name that you made up (e.g. I have ‘polaris.dblsaiko.net’). This also makes adding more hosts later less awkward (as opposed to having the hostname be domain.com).

For the IMAP login issue, I’m pretty sure this is the cause looking at the “unknown user” error:

userdb {
  args = username_format=%u /etc/dovecot/users
  driver = passwd-file
}

Have you set up the users in that file (/etc/dovecot/users) if you even want to do that instead of just using passwd? Also note %u is the full user string including domain. Not sure how that plays together with auth_username_format=%n which is just the user name.

Personally I just have

userdb {
  driver = passwd
}

so I don’t have anything further to go off of.

Okay, there are two different issues here. First, the mail delivery.

You have

mydomain = domain.com
myhostname = mail.domain.com

and getting

Relay access denied (in reply to RCPT TO command)

This means that received mail is addressed to a domain that is not configured for local delivery, and the mail server is not accepting it to be relayed to the actual target server. This is a good thing, you do not want to have a public relay under any circumstances because it would mean people could make your server launch spam anywhere.

As for why it’s not configured to accept that domain for local delivery, you need to look at the mydestination setting:

mydestination (default: $myhostname, localhost.$mydomain, localhost)

The list of domains that are delivered via the $local_transport mail delivery transport. […]

(from postconf(5).)

You left it at the default value, so it will accept mail addressed to mail.domain.com, localhost.domain.com, and localhost. You’ll probably want to set that to additionally contain $mydomain (at least that is how mine is configured).

Also, something else:

My server’s hostname is domain.com not mail.domain.com (mail.domain.com is what my MX record points to), but this shouldn’t really matter as I configured postfix with:

You’ll want those to match up, system hostname and postfix’s myhostname, since you’ll need to set the PTR record of your IP to match the hostname your SMTP server identifies itself as, and otherwise your server’s IP resolves to mail.domain.com while the canonical hostname is domain.com. It will work for mail, it’ll just not be nice when your server’s IP resolves to mail.domain.com for stuff that isn’t mail and that isn’t the canonical hostname. I recommend giving it some other hostname (or just setting both to mail.domain.com if the system just handles mail).