stryan

> but instead to create a bespoke mechanism involving a bunch of tiny files, all of which is insanely system (linux) specific, and therefore completely non-portable.

To nit pick slightly, it's not really a bespoke mechanism it's just re-using the mechanisms provided by systemd. Quadlets are implemented as a systemd generator in order to re-use the existing service management system that exists on essentially all major Linux distros. Quadlets are less a direct competitor with compose (hence why Podman implements the compose spec) and more a way to better integrate containers with the rest of a system. The closer Podman native equivalent to compose is Kube files.

Swapped a few years back (pre 5.0), haven't looked back. For compose files I'd look into using quadlets.

For quick conversions you can use compose files directly with podman-compose or docker compose pointed at the podman socket[0].

There's also podlet[1] which converts compose files into native quadlets. It does a pretty good job of taking care of everything for you and for a lot of simple to medium complexity compose files it will Just Work. There's talk of making it into a library of some kind so other tools can transparently convert compose files to quadlets so hopefully we'll see more stuff like it.

Otherwise, writing your own Quadlet files isn't too hard if you're at all familiar with systemd unit files. Most `docker run` or `podman run` arguments have direct quadlet conversions so once you get used to the INI format versus yaml it's pretty easy to see a compose file and churn out the equivalent quadlet(s).

[0] https://www.redhat.com/en/blog/podman-docker-compose

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

We know they've been kicking the idea around since the first line up and I believe pretty decent leaks saying they were working on it were out around 2019.

I see a lot of people using Komodo for it, though if I had to pick I'd go with Doco CD[0]. You can also use standard Ansible for just cron+bash script to git pull.

On the Podman side, I wrote a tool named Materia[1] for it, but there's also the wonderful Ansible quadlet role as well as Quadit and Orchess.

[0] https://github.com/kimdre/doco-cd

[1] https://primamateria.systems or https://github.com/stryan/materia

I've been working on getting another major release out for my side project Materia[0], hopefully by or on the solstice. Materia is a GitOps continuous delivery tool for Podman quadlets: it handles installing/removing/updating files, installing secrets, restarting services and dependencies, rolling back failed updates, and more. I've been working on this for almost two years now and am pretty happy with how its coming along and the growing user base. Plus it's been a fun excuse to try out some new things, like creating a Varlink API or different CI/CD setups.

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

That's not how federation works? You wouldn't log into Mozilla's matrix server with another Matrix server's login, you would just join the :mozilla.org rooms with your normal Matrix account. That's the whole point of federation.

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.

Yeah I run my steps as one-shot commands to try to avoid that, but the timer/service split can be very annoying like that.

Should have been more clear: I use RandomizedOffsetSec= to add a random offset to a set start time (usually 4am), to prevent overloading the backup server, not truly random start times.

Timers can work with arbitrary units (not just a similarly-named service unit) so they can be surprisingly flexible. I have a timer on my servers that starts a backup.target that fires off a full "restic backup","restic prune", "restic forget" backup cycle each morning with randomized start times and notifications. The actual restic-* units are Podman Quadlets so the whole setup runs agnosticaly of what's on the server, just as long as it has Podman and Systemd installed.

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.

My projects also require Assisted-by attribution as that's what the Fedora AI policy requires and that was the first major org with a coherent AI policy that I found when choosing it. Not sure which came first, that or Claude hijacking Co-Authored-By.

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

It's a new batch each day, but it's not drank in the same day it's brewed I suspect. Probably a week or two later, going off some quick research into "running ales", a similar English style of brewing.

I'm assuming you're at least overseeing the creation/updates of the Ansible playbooks and have some familiarity with what is being managed outside of that. While I personally would not do that[0], I can see the reasoning behind it.

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.

As far as I can tell and from some quick researching of the guys previous experience, that's all it is. I think the implication is that LLM's will be architecting and deploying the cluster setups at some point? Which sounds horrific so I'm assuming I am interpreting it long

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.

Glad you're taking it in-stride, I was worried I was a little too direct. Everyone and their mom is making a Discord competitor these days but being Not-Discord isn't enough to stand out.

> 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.

From a normie perspective:

- 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.

Having the core of your app be written in languages you self-admittedly don't understand is a bold move. I've been a big fan of the ansible-matrix playbooks for a while now so I'm willing to see this play out, but it doesn't fill me with confidence.

Yeah, I wouldn't be surprised if a lot of the mindset differences come down to people used to using Docker Compose as a development environment being uncomfortable with managing things on a real/traditional/production/whatever-you-want-to-call-it server. Compose treats things as sort of a hermetically-sealed "Application" versus a collection of services. Quadlets are more the latter, and of course that's all Docker Compose is as well but it's a decently good abstraction over it.

> It's a tool for user age verification that happens to be something you can use to manage services.

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

> * use systemd, red hat's favorite kitchen sink for handling everything

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.

> Having your whole application with its containers, volumes, and networks all defined together in one easy-to-read YAML file is a way better experience. Deployment is two steps: 1. `git clone foo` 2. `docker compose up -d`. You can see the state of the application containers with `docker compose ps`. You can run multiple compose applications on the same host and manage them separately by putting them in different directories.

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

Possibly to avoid conflicts with Nethack4[0], which was a fork of the Nethack 3.x series back when development was stalled. I think the guy behind it later joined the main Nethack dev team.

[0] http://nethack4.org/

Glad to hear about the web UI changes, git-bug has been really great for my projects that exist across forges so I look forward to testing it out :)

git-bug is great but it doesn't handle PRs nor does it have a method for users without commit rights to submit bugs to the project. I know they're working on the latter (something with the web UI?) but until then you still need some kind of public infra for issue management if you want the general public to be able to submit issues.

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.

You can copy physical books for storage/otherwise personal use IIRC so it's not quite as locked down as a DRMd book. Not sure what the legal state of hand copying a book and then loaning it out as it probably doesn't come up much.

They won't deliver to the house but they'll still deliver to that area. Amazon/etc wouldn't even deliver to the area without the infrastructure of the USPS.

Practically speaking, USPS does a lot of last mile package delivery that no one else wants to do, including Amazon. If USPS wasn't delivering to those locations no one would be. And we're not talking middle-of-no-where-Wyoming locations, plenty of places east of the Mississippi have only USPS too.

There's all sorts of philosophical arguments as well: government services shouldn't need to turn a profit, all citizens need to be able to interact with the State and the post office provides a way to do that, mail-in voting, Post Offices can offer stuff like general delivery for those without permanent addresses, etc.

Mason installs LSP servers (and other tooling if desired). So if you're managing your LSP servers elsewhere (distro package manager, etc), it's probably not doing much.

Mason was always just a package manager for LSP servers. It used to be you needed the nvim-lspconfig plugin to properly configure LSP servers to work with neovim; to help with that there was the mason-lspconfig plugin that basically mapped LSP servers (as installed by mason) to nvim-lspconfig LSP configurations to make it all Just Work.

Now nvim-lspconfig and mason-lspconfig are no longer required thanks to the `vim.lsp.config`/`vim.lsp.enable` setup so you don't need them unless you want the little bit of automagic setup. Mason you can retain if you find it easier to install LSP servers through it, otherwise you can drop that too. Personally I manage my LSP tooling through distro/mise and replaced the lspconfig plugins with just a few autocommands and manually grabbing the config files from nvim-lspconfig git repo as needed.

Yep, using snapper, same as tumbleweed.

> what is "atomic and transactional Linux"?

Linux distros that are updated with full system snapshots instead of package by package, similar to Android. The key difference is most of / is mounted read-only[0] and is only changed by distribution provided updates so you and the distro team always know exactly what's running.

> What are the advantages to the alternatives?

Greater control and stability since its essentially always running in a supported configuration. Easy roll-backs to a previous update if something goes wrong. You always know exactly what your system is running if you want to keep it in sync across machines (more useful in a server setting).

> What other projects are similar

Kalpa is a "sibling" project to AeonOS, which is atomic OpenSUSE but with Gnome (and other changes, which I'll get to). There's also the Fedora Atomic line of Fedora Kinoite and Silverblue (KDE and Gnome respectively), U-Blue, Bazzite, SteamOS, and more. I think most major distro lines have an Atomic variant at this point.

> What is the motivation for this project in particular?

For Kalpa specifically, it's to offer a KDE alternative to AeonOS. Originally there was just AeonOS, which was OpenSUSE MicroOS (an atomic version of OpenSUSE Tumbleweed) with GNOME installed. Aeon has diverged greatly from MicroOS though and I think it no longer uses it as an upstream. AeonOS also refused to support KDE[1], so Kalpa was created. Kalpa still uses MicroOS as its upstream and I'm not sure if there's any plans to change that.

> Most importantly, why should I want to use it?

I use it on my personal laptop because it lets me have all the benefits of a rolling distro (up to date packages) without the stability concerns. Updates apply automatically in the background and I know when I reboot I'll always have a working system available to me.

[0] /etc is mounted as an overlay FS so you can still make changes to it. /var, /usr/local, and /srv are also still user-writable. I think /mnt is too but I forget off hand.

[1] Aeon is generally anti-customization and does its best to only offer one way of doing things. This is to prevent configuration drift and reduce the maintenance burden per snapshot. GNOME also has a more regular release cadence, which makes it much easier to integrate than KDE (or so I've been told..)

Kalpa is great and hits way above its alpha status; I've been running it on my laptop for months now with zero issues. It's been really nice to not have to worry about updates, just gotta reboot it every now and then and most things just work.