My recommendation is to put all of the variables in an environment file, and use systemd’s EnvironmentFile (in [Service] to point to it.

One of my backup service files (I back up to disks and cloud) looks like this:

[Unit]
Description=Backup to MyUsbDrive
Requires=media-MyUsbDrive.mount
After=media-MyUsbDrive.mount

[Service]
EnvironmentFile=/etc/backup/environment
Type=simple
ExecStart=/usr/bin/restic backup --tag=prefailure-2 --files-from ${FILES} --exclude-file ${EXCLUDES} --one-file-system

[Install]
WantedBy=multi-user.timer

FILES is a file containing files and directories to be backed up, and is defined in the environment file; so is EXCLUDES, but you could simply point restic at the directory you want to back up instead.

My environment file looks essentially like

RESTIC_REPOSITORY=/mnt/MyUsbDrive/backup
RESTIC_PASSWORD=blahblahblah
KEEP_DAILY=7
KEEP_MONTHLY=3
KEEP_YEARLY=2
EXCLUDES=/etc/backup/excludes
FILES=/etc/backup/files

If you’re having trouble, start by looking at how you’re passing in the password, and whether it’s quoted properly. It’s been a couple of years since I had this issue, but at one point I know I had spaces in a passphrase and had quoted the variable, and the quotes were getting passed in verbatim.

My VPS backups are more complex and get their passwords from a keystore, but for my desktop I keep it simple.

I hope this isn’t a step towards replacing the native app with an SPA.

This seriously got an out-loud chuckle from me. It’s funny, because it’s true! Thanks!

Sourcehut also supports Mercurial, so you also have an option to the herd mentality.

Sourcehut also has zero, or almost zero, JavaScript in the interface, so it doesn’t suck

Sourcehut is also componentized, so you can mix and match the pieces you want or need:

• VCS hosting
• masking list management
• issue management
• build server
• man server

Sourcehut is by far the best hosted VCS option at the moment. The Mercurial support alone puts it miles ahead of the others, which are all hobbled by tight coupling to git.

Are China Parties like Tupperware Parties, where friends get together and one shills a pyramid scheme? That’s what CP is, right?

E2E usually suffers from the same thing HTTP does: the MITM might not be able to read what you’re saying, but they know who you’re saying it to, and they may know in what context. This is a lot of information that can be used in profiling.

So you end up with systems like SimpleX, where everyone has a different UID for every contact, but that has its own problems, as anyone who’s used systems like that are aware. We haven’t really solved making that a good user experience for messaging; I don’t see it translating to broader social media any time soon.

Nostr has some really good specs and tooling that neatly addresses these topics, including great cryptography support, signing, ad-hoc IDs, and an entirely voluntary simple naming lookup; it doesn’t exactly solve zooko’s triangle, but it provides a toolset sufficient to mix and match characteristics for whatever your threat model is. Sadly, Nostr is utterly dominated by the crypto crowd (and is associated with some controversial personalities), and even if you’re not cryptocurrency-hostile, it’s a really dull echo chamber with little other content that has prevented people who might otherwise build interesting platforms in it from doing so.

Mastodon was around for ages before (the in practice centralized) Bluesky; why did it take Bluesky to open a mass exodus from X?

This is a hard problem to solve. Throwing E2E at it doesn’t make it easier; it’s just tossing a buzzword in.

What do you mean by “all right?” What are your concerns?

restic backups are encrypted by default; it should be safe to store them almost anywhere in the cloud. The container needs the credentials, but you can improve security with something like OpenBAO (Hashicorp Vauly fork, github.com/openbao/openbao), SOPS (gitgub.com/getsops/sops), infisical (github.com/Infisical/infisical), or any number of other secrets management tool.

Why don’t you like LDAP? OpenLDAP is a PITA (necessarily, I guess, to be considered “enterprise”), but lldap has been pretty nice to me. I mean, it’s the identity protocol, it’s just that the server software has been complex until relatively recently.

What would you use instead? A SQL DB with some custom schema, that just re-invents LDAP?

I like the motivation behind this, but have a allergy to running critical infrastructure like authentication on node.

To each their own, though, and good luck with the project. Diversity is life.

Do any of you know another solution to stream audio from my phone to my server

I use snapcast throughout my house and devices, but there’s no snap_server_ for Android.

I’ve been meaning to try roc, for which there is an Android client that will both play and serve.

Sonobus also claims to be many:many; I haven’t tried it either and it doesn’t look particularly active.

I don’t use UPnP or DLNA because of the security issues, so I can’t offer a suggestion about that. I thought DLNA was a pull oriented protocol - like, to send music from your phone you’d have to select and play on your computer with a DLNA client. Can you push media with DLNA?

I also have the prompt set to the host name. I’ve never understood why people included their usernames; I don’t log in to more than one account on each machine.

As long as it isn’t github.

Publish that puppy. It can’t hurt.

Don’t do it in github, though. Sourcehut is better; or if you crave that cluttered, JS-heavy feel, Gitlab.

Maybe! How is it better than keeping a README?

If it’s just a command, I put it in a readme. If it’s a series of commands, I put it in a shell script. What would your tool bring to the party, and if I’m going to turn to a third party solution, why shouldn’t I use Salt or Puppet instead?

If you do, use the -k option - it locks access to the rook service to only the user session. Rook works without it, but is more secure with it.

Have you ever used OwnCloud, before the fork?

I hated administrating OwnCloud, and that’s kept me away from NextCloud. OwnCloud was a big, resource hogging, hot mess; did NextCloud do a huge refactor and clean it up?

Shamelessly shilling my OSS project, rook. It provides a secret-server-ish headless tool backed by a KeePass DB.

• Headless server
• Optional and convenient integration with the kernel keyring (on Linux), for locking the server to only provide secrets to the user’s session
• Provides a range of search, list, and get commands
• Minimal dependencies and small code base make rook reasonably auditable

You might be interested in rook if you’re a KeePassXC user. Why might you want this instead of:

• Gnome secret-server, KDEs wallet, or pass? rook uses your (a) KeePass DB, while most other projects store secrets in their own DBs and require (usually manual) sync’ing when passwords change.
• One of the browser secret storage? Those also keep a bespoke DB which needs to be synced, and they’re limited to browser use. Rook supports using secrets in cron jobs or on the command line (e.g. mbsync, vdirsyncer, msmtp, etc, etc).
• KeePassXC? KeePassXC does provide a secret service that mocks Gnome secret-service, but you have to keep KeePassXC (a GUI app) running even if you only rarely use the UI. Rook can also be used on a headless machine.
• The KeePassXC command line tool? That requires entering the password for every request, making it tedious to use and impractical for automated, periodic jobs.

Rook is read-only, and intended to be complementary to KeePassXC. The KeePassXC command line tools are just fine for editing, where providing a password for every action is acceptable, and of course the GUI is quite nice for CRUD.

Kyria is a solid alternative. I was seduced away from it by the Piantor Pro and forgot about it, but the Halcyon Kyria looks perfect. I probably wouldn’t use those outer thumb keys much, but it doesn’t hurt they’re there, and there are plenty of more well-positioned thumb keys from which to choose.

I’d like more stagger on the body section than the birdy44 has, which looks like almost none; it has pinky stagger, but other than that no columnar stagger. The integrated track pads are lovely, though!

KLOR has the same thumb key positioning - the “m” key is too far in - you have to tuck your thumb to get it under your index, which is over the “m” key. It’s the same layout as the Piantor. I was hoping for a thumb cluster positioned more naturally under the resting thumb, with less horizontal thumb movement, like the ErgoDox (and siblings).

Gosh, yes, love that site. I don’t use it much since it’s almost impossible for it to stay comprehensive; for example, it’s missing both the Piantor and Piantor Pro, and the Piantor had been around for a couple years at least.

It is a wonderful tool, though. I think it’d be a full time job to keep it current with all commercially available keyboards, much less all of the bespoke builds.

Hah! I’m having trouble distinguishing between the Cantor and the Piantor Pro, which is what I’m currently using.

My issue with these is the thumb key placement. The innermost two are fine, but having to tuck my thumb almost into my palm to reach those outer (looking at the keyboards, or inner, if you look at each hand) keys is not very ergonomic for me. It’s also a fairly wide horizontal span to move the thumb, and sequences requiring inner:outer are both tedious and unavoidable.

I don’t doubt you like it; for me it’s not ideal.

Thanks for the suggestion!!