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.
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.
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.
I've been using various UNIXes and clones since the 90s so I do generally know what's going on but I also have no desire to fill my brain with the syntax to the new new new commands to configure an Ethernet interface on Linux etc, or the work necessary to understand fully why VA-API on a certain chip has specific quirks that break freerdp, nor the toil of backporting and patching the necessary libraries, or the specific dance required to set up a machine to TFTP new firmware onto one of the switches, or.... You get the idea.
I'm also not a fan of all the complexity of Kubernetes, one directory with simple to read files makes it a lot more transparent what's where and how it's set up, and the commit history + changelogs make it relatively clear what's changing and why. No distributed database or fancy bootstrapping, just a ubiquitous config format and tool to apply. Changes at the granularity of "a new host is available at A.B.C.D, configure it as a dev server" or "add a new Debian system container named 'blah' to X, bridge it to the research network only, limit to 16 hyperthreads / 64 gb ram, set up for development on git://<whatever>". It works ok for now.
The next major change will be when models that run locally are capable enough to drive the config changes themselves.
- 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.
Thanks for checking it out and taking the time to give feedback. You made some good points. After staring at the site for so long, you go blind to these types of things, so you're helping a lot here.
>no video chat, no screen sharing
Screen sharing and video chat were added just a few days ago, and I wanted to get that tested more before mentioning it so prominently.
>No downloadable version isn't a feature. What's a PWA?
At the moment, we're a small team, and not all engineers. None of us know Swift or Kotlin, but aren't against learning. Usage is something we want to see before investing that much time into writing these, so in the meantime, a PWA is the best middle ground.
One key differentiator from Discord is that we're not against third party clients, so if in the meantime someone comes out with one we're not going to make any efforts to stop it.
>The name makes it sound like a Discord clone
I see what you mean, if you had a magic wand, what would you call it?
>"Live audio space" doesn't explain whether it's drop-in voice channels like discord/slack huddles or scheduled audio calls
We have video now, but to answer directly, it's similar to a Space on X.
Thank you for the feedback, I will be working this weekend to make these things better articulated on the website!
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.
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.
> * 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.
It's a tool for user age verification that happens to be something you can use to manage services.
Did you miss my point about it being a filthy kitchen sink?
>This is the same system state as using docker compose with docker
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.
This shit is also incredibly fiddly. Ever had "docker compose" and "docker-compose" do subtly different things which drive your team mate to pull their hair out? I have.
Podman should stop trying to piggyback off docker if it's trying to be an alternative.
>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
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.
> 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.
>I suspect there's not really a point in responding to this since you've already made up your mind.
I suspect you ignored the point because you didnt want to address the point.
My repeating it seems to only have highlighted your wish to continue avoiding it here.
>Nevertheless, yes I am aware the systemd project contains many modular components.
Another red herring. "Modular" really isnt the point here.
It's certainly one way to justify throwing even more shit in an already overloaded kitchen sink though.
>You skipped the second part of my sentence where I reminded you that Podman is daemonless.
No, you skipped the part where I acknowledged that it was daemonless-by-default but you actually DO need to run a podman daemon if you're using docker compose with podman.
>Take this up with docker?
They're not responsible for podman trying to piggyback on their tools.
> 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.
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.
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.
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.
[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.
For me the main issue with git-bug is that they are not dogfooding it. However, it's also one of the few projects that is actually trying to solve the core problem, rather than skirting around it. (well I now learned of radicle in this thread and they seem to store issues in git and even have PR support I think)
> For me the main issue with git-bug is that they are not dogfooding it.
This is incorrect.
$ git remote get-url origin
ssh://git@github.com/git-bug/git-bug.git
$ for n in bugs identities; do echo "${n} on the remote: " $(git ls-remote origin "refs/${n}/\*" | wc -l); done
bugs on the remote: 453
identities on the remote: 311
That said, yes, GitHub is still our source of truth, as our web application does not currently support "guest" access, and there are other platform features that our community uses that we do not currently have support for (e.g. discussions and pull requests). Big changes to the web ui are coming soon, which will help to unlock the ability to do these things.
I've also been in talks with the Radicle team about possible collaboration.
Oh cool! I've come across git-bug a while ago, glad to see you're using it.
I didn't know git-bug doesn't support PRs yet. I think pull requests should be modeled as a kind of issue. It's an issue with some metadata that points to a commit (and besides the usual issue operations like add new comment or edit a comment, you also have the operation of editing the commit associated with the PR)
If git-bug gains suppport for Github discussions, it should also be able to import discussions from other places like a discourse forum. I think it would be kinda neat for projects that want to be self contained
> I've also been in talks with the Radicle team about possible collaboration.
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.
I mean really? Oh I can't see someone heading down to the copy shop to scan every page of war and peace and then print it out when you can get a used one for less than the paper cost..
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.
There are lots of rural places the USPS doesn't deliver to. They require you to get your mail at a PO Box at the nearest post office, or have a mailbox at a common spot on the nearest public road (which might be a fair distance from your house).
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.
reply