> This may be unsatisfying for many people but the impossibility of enforcing fireworks bans in the US captures an important component of the American zeitgeist. It is annoying for me sometimes but I recognize that this reflects an aspect of American culture that you can’t just erase.
I've taken to describing this aspect of Americana as "the fatal need to have a pretty good time", after the Minced Mockingbird post[0].
Yeah that's an unfortunate downside of the daemon-less design. Service management (like dependencies, health checks, etc) are outsourced to systemd since there's nothing locally available to monitor them. The fact that the documentation doesn't mention this is a major miss.
> 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).
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.
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 :).
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.
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.
- 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.
I've taken to describing this aspect of Americana as "the fatal need to have a pretty good time", after the Minced Mockingbird post[0].
[0] https://www.mincingmockingbird.com/products/fatal-american-n...