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?

None necessary, but thanks.

Lamenting that a phone or tablet can’t use zwave for networking is really strange.

It would be, if anyone were doing that.

So Thread is a low-power radio, and Matter is the protocol? Does it is the same frequency ranges - 2.4 and 5 GHz? Or does it have a different spectrum? One of the reasons I chose zwave initially was because the standard allows far more devices in the spectrum than ZigBee, and WiFi crowding is already an issue with only all of the phones, tablets, computers, and devices that I couldn’t get in zwave.

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.

How are the battery lives of your devices? I have motion sensors throughout my house connected via zwave, and I replace their button batteries about every 18 months. Does Matter run over a low energy technology?

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.

The end, though, is the same. lemmy.ml well still want their version, so they can have their own content rules. What you’re suggesting is functionally centralization, which is already an issue for Lemmy based on its design; consolidation would aggravate it.

Eventually, lemmy.ml !linux users would want to have their own community to enforce rules programming.dev won’t. Diaspora is inevitable. Consolidation fixes the wrong problem - a better solution would facilitate less centralization.

So:

• Lemmy provides the information
• It’s the client responsibility to do the interleaving

Yeah?

Hmm. Would that be good, though? Different rules, different moderators. Wouldn’t an aggregation system based on subscription be better? Consolidating would result in a consolidation of power into the hands off a few.

Consolidation would also encounter trouble when server admins disagree with moderators about community rules. When conflicts happen - which they inevitably would - we’d have a situation where the community would split as some moderators recreate a new community on a different server. It was hard enough when lemm.ee shut down, and that have communities no option but to switch; if the reason for a move is policy and not server shutdown, the chaos would be far worse.

The more I think about it, the worse consolidation sounds.

I figured it might be a client thing. Someone else did mention Piefed does this.

This might be the impetuous to fire up a self-hosted instance.

Neat! So, I have to switch to a Piefed account or run my own Piefed server? Does this mean that Piefed performs this aggregation in your feed when you’re browsing your subscriptions?

Did you look at Pelican?

I have not, but I will. I may also look at Zola, although it, too, appears at the surface level to be tightly coupled with markdown.

the template language is buggy and inscrutable

It’s just Go templates, which are pretty solid; I’d be surprised by any bugs, unless they’re in the Hugo short codes. The syntax is challenging, even if you’re a Go developer and use it all the time. It’s a bespoke DSL, and a pretty awful one: it’s verbose, obtuse, and makes some common things hard.

Go is my language of choice, but my faith gets shaky whenever I have to use templates.

I’m not a huge fan of Python; despite its popularity, it’s got a lot of problems, not least of which is the whole Python 2/3 fiasco; which, years later, is still plaguing us. However, if I can containerized it so it isn’t constantly breaking in the background when I do a system update, I’m not opposed to using a project written in it. At least it isn’t Node; I won’t let that crap onto any server I admin.

Edit: Zola has the same problem as Hugo.

Ah, Ok.

I do as (or a similar workflow): I rsync the content directory and let Hugo on the server render. My sites are public, but perhaps they’re just much smaller or not as popular; Hugo renders even my largest site in about a second, but for a large, slow, heavy-use production situation I could see a push-and-swap process for a more atomic site update.

I don’t see the degradation you do, but there are so many possible variables.

My biggest gripe about Hugo is how limited it is in supporting source document formats. There’s no mechanism for hooking in different formats, and the team is reluctant to merge PRs for other formats. When I started with Hugo, I had a large repository of essays spanning a decade and written in a variety of markup, from asciidoc (which I used for years), to reST, to markdown; and markdown is by far the worst. I was faced with converting everything to markdown, which was usually a lossy process because markdown is so limited, or not publishing all of that history. And now we have djot, which is almost the perfect plain text markup language, but I again have to first do a lossy conversion to markdown to get Hugo to consume it. It low-key sucks, and I’m actively looking for an alternative that has a more flexible AST-based model for which new formats can be added; something that consumes a format like pandoc’s AST.

Hugo has a watch mode, right? It should rebuild if it detects changes.