Besides Materia itself I've been bouncing around some other ideas for the Podman quadlet ecosystem. The biggest one is Athanor[1], which re-uses the same plan-execute system and primitives provided by Materia to backup Podman volumes.

I've also been kicking around a clustering system for Podman volumes called Firmament that uses Serf and the built-in Podman import/export API to move volumes to where they need to be in the cluster. But this will probably wait until Materia hits 1.0 before I really start putting effort into it. Or if my homelab needs something like it, whichever comes first :).

[0] https://github.com/stryan/materia ,main site https://primamateria.systems [0] https://github.com/stryan/athanor

It sounds like you were trying to login to Mozilla's Element web client and it was only set up to authenticate against the Mozilla homeserver but A) that's a client setting unrelated to federation or really the protocol in general and B) not what you were supposed to be doing to begin with.

I will admit thought, timers are up there in terms of being the clunkiest systemd unit type to use on a regular basis. I get why they're split up into two files and require different start vs enable syntax's, but man sometimes I just want to create a file that runs a script and be done with it.

Personally, I prefer Assisted-By. Co-Authored-By implies a level of respect and self-direction I don't think LLM's deserve.

ClusterdOS appears to be a kubernetes-in-a-box multiple node setup that's goal is to work so well that the user doesn't know or care what it's doing. I wouldn't trust an LLM with managing one machine by itself, let alone a whole cluster of them running the incredibly complex mess that Kubernetes is (and that's not even counting the 8 other layers of software this is), so this feels like an order of magnitude worse.

[0] Using LLMs for sysadmin research or boilerplate writing is one thing, but after a certain amount of use you're really just paying $X a month for Anthropic to manage your systems for you. I'd rather just pay a real person to do it at that point. I'd also rather people get over their pathological fear of learning how to run a server but I've given up on that.

The article itself reminds me of the enthusiasm I felt for plan9 when I first heard about it back in uni. I also thought everyone should have their own compute grids and that clustered computing was the future; of course now I realize there's a lot of reasons why that doesn't actually work. Considering this appears to be a start-up ad, I hope the author knows something I don't.

> I see what you mean, if you had a magic wand, what would you call it?

Naming things is, of course, the hardest part of programming so somewhat hypocritically I can't say I have an answer :) . It probably depends more on what you view your target audience as and what your main selling point is. Discord worked as a name since it falls in line with a lot "gamer branding". If you have a theme going on I'd go with that, otherwise the age old traditions of picking a random communication related or mashing two words together (Linphone, Threema, Skype, etc) are probably the easiest.

Personally I think I'd go with "Microcosm" or something similar. Sounds cool, abbreviates well to just "micro". Or maybe something with "vox" in it. Honestly it probably doesn't matter too much, people will get used to saying anything.

- No screenshots on front page, I have no idea what it looks like

- no video chat, no screen sharing

- No downloadable version isn't a feature. What's a PWA?

- "Live audio space" doesn't explain whether it's drop-in voice channels like discord/slack huddles or scheduled audio calls

- The name makes it sound like a Discord clone

From a technical perspective:

- Not FOSS, can't self-host or federate. What makes this less likely to rug pull than Discord/any of the other alternatives

- No information on who is making this

- No information on how messages are encrypted

- Webpage looks vaguely AI generated

- Bot API is A) hidden at the bottom of the very long tutorial, B) seems to be limited to normal user actions (I could be wrong!), and C) desperately needs an index or sidebar

- Unclear whether anonymous channels are truly anon or just anon on the client side

Some stuff seems neat: I am intrigued by anonymous channels and from your feature table it hits more table-stakes features than most Discord alternatives. But I would give it a few touch ups if you want it to stand out.

Good talk buddy.

> Did you miss my point about it being a filthy kitchen sink?

I suspect there's not really a point in responding to this since you've already made up your mind.

Nevertheless, yes I am aware the systemd project contains many modular components. Some of which are good (systemd-the-service-manager that is what I was referring to), some of them are bad, and some of them are just odd (still haven't wrapped my head around systemd-homed's purpose). Podman integrates with the systemd service manager, not the rest of the project, so I'm really not concerned about that: there is no point where I am unable to use quadlets because I don't have, say `systemd-timesyncd` installed.

On the gripping hand, Quadlets are just a systemd-generator so there's nothing stopping you from getting that exact same benefits of Quadlets with some other service manager. You'd just have to write that implementation (and probably your own bespoke service manager) and will probably miss out on some of the niceties systemd provides to anything it manages.

> One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point in the trash.

You skipped the second part of my sentence where I reminded you that Podman is daemonless. There is no long-running Podman daemon/service/etc, it is spun up on demand and then stops when the action is done. Having a second process instance is not a daemon, and I'm not sure how you would have expected this to work otherwise.

> Ever had "docker compose" and "docker-compose" do subtly different things which drive your team mate to pull their hair out? I have.

..Take this up with docker?

> Personally I suspect it languished because Red Hat simply cant abide the idea that somebody out there might avoid using systemd for something. > They happily built a docker compose to quadlets converter but they cant bring themselves to make podman compose not be a piece of shit even though it wouldnt be a lot of work.

I don't think `podman-compose` was ever an official Red Hat project. I don't think there was every really much interest in ironing out all the corner cases, especially before compose was actually fully specced, and once Podman itself implemented the spec the interest has been drying up.

Assuming you're referring to podlet[0] for the latter, that was never a Red Hat project.

[0] https://github.com/containers/podlet

Systemd is a tool for managing services. Containers are services. Why require an entirely separate bespoke service manager when you're already running one?

> * docker compose where i have to run a whole separate podman service to lie to docker compose about not actually being docker.

This is the same system state as using docker compose with docker: you have a client program speaking to a backing daemon. Only difference here is the Podman service, being daemonless, only runs when needed (assuming you're setting up things the documented way by enabling the podman socket).

> * podman compose which would be the obvious solution if it didnt just plain suck.

Yeah I haven't had the best luck with it either. But part of the reason it's languished is that it makes more sense to just reimplement the Compose spec on the backend rather than re-invent the wheel and create a new compose client as well.

There's also the fourth option of writing Kubernetes yaml and applying that with `podman kube play`. Honestly this is probably closer to being the podman equivalent of docker compose but since it involves writing The Bad YAML (kubernetes) rather than The Good YAML (compose) most people don't use it.

I always felt it the other way around: docker compose files are weird blobs of YAML that I have to hunt down the location of or parse their under-speced labels to find the location of. I can't make them depend on any non-container services[0], the break my firewall rules[1], and I have to use a whole mess of bespoke tooling just to do normal start/stop/restart operations with them instead of using the same commands I use for literally any other service.

> With quadlets, you delegate everything to systemd. You have to break the configuration up into a bunch of tiny unit files and then separately copy them to /etc or a dedicated user's dotfiles.

The nice thing about quadlets is exactly that, they integrate with systemd and by extension the rest of the system. I don't have to think about `webapp.container` as a "Docker container" I can think of it as just `webapp.service`, like any other piece of software I would install and run. All the related files are in one of the well-speced file locations that follow the same hierarchy as anything else on the system (user -> etc -> /usr), optionally grouped in folders[2].

> Good luck SSH'ing into an unfamiliar system and understanding at a glance what it's doing.

Just use the same tools you'd use on any other systemd system: `systemctl list-units`, `systemctl status`, etc. Versus having to hunt down compose files either manually or by parsing the under-specified labels on the containers.

> (Even moreso if you created dedicated users for each application, which I understand is the recommended solution.)

TBH I've rarely seen this advice. Most people I know just run it as root (which is what I do) or as a `podman` user. But even in this situation it should be pretty easy to figure out whats' running, as you know it's all running as one user and is hard-namespaced to only rely on resources available in that account.

> If I'm just holding it wrong and there exists some better tooling to manage podman in prod that I don't know about, I'm happy to hear about it.

Quadlets are just files that created systemd services, so basically any configuration management or deployment tool will manage them fine. Ansible has a dedicated Quadlet role that works pretty well, or just git clones+`systemctl start`. This would probably be the recommended way if you're not using k8s/etc.

Alternatively, you can just `git clone /etc/containers/systemd/`, `systemctl start container` like with docker compose. If you're running multiple containers, either refer to them with `Wants=`/etc in the Quadlet files, create a `.target` file that references them all, or put them all in a `.pod` and start the pod. I think this is the part were most people stumble though: when you're used to treating containerized software as a separate kind of "thing" it's a little weird to go back to treating it like normal services.

I've been writing something to help with deploying quadlets GitOps-style[3] that will hopefully fill the "more than one server but less than kubernetes" deployment gap.

[0] Unless I wrap the compose steps in a systemd unit, at which point now I have two problems.

[1] Caveat, this has probably gotten better overall but I still run into compose-related firewall issues about once or twice a year

[2] The newer versions of Podman also support `.quadlets` files, that merge all the quadlets into one file.

[3] https://github.com/stryan/materia . There's also https://github.com/orches-team/orches and https://github.com/ubiquitous-factory/quadit

[0] http://nethack4.org/

I use it for my project[0] to keep issues centralized with the repo, but I still use Github Discussions as a pseudo-bug tracker to let random users provide input. If it's a bug I add it to git-bug and sync it to Github issues for public viewing[1], but if you want use bug reports that's not really going to work.

[0] https://github.com/stryan/materia

[1] Ironically I got this workflow idea from ghostty and mise, both of which require users to submit bug reports as discussions first and only generate tagged issues once an actionable bug is determined.