Maybe he’s the right tool for the job

A “do everything” app is overkill. I am not a fan of many features Discord implemented over time. But the initial offering of having text chat, voice chat, video chat in one app makes sense. It’s just super convenient to switch the communication type depending on what you are currently doing, without having to onboard and switch between tools.

It’s also hard to draw a line, if you want to go “do one thing well”. Mumble also includes text chat, and user management, ACLs, etc. … for text chat one could use IRC, for user management there are IdPs, and so on. XMPP also doesn’t just do “one thing”. The “X” (= extensible) is heavily used and there are extensions for all kinds of things. Some of the big messengers out there are (or were) using XMPP under the hood (just without federation).

But then it’s not chat anymore. Or screenshare.

There are many good tools that solve individual issues. But Discord solved many of these issues in one tool, and that also has its charme.

Yes, experience matters a lot. I think the comparison of an coding agent being like a trainee is somewhat appropriate. Leave them to their own devices, and you likely don’t get something you should be shipping to production. But guide them appropriately, and they are helpful. The difference obviously is, that a trainee learns, an agent not so much. At least not on an abstract level. Of course the more code you have, the more patterns they can then copy. But if your baseline rots, so will the code the agent derives from that baseline.

It’s not a tool, it’s a chaos generator.

Just like humans. Bullshit code and bad developers existed before agents helped make them.

Aside from fundamentalists the usage of LLMs and coding agents will increase. It’s a tool in the toolbox now and many devs do or will play around with it. Some will have to learn to not overdo it; but that’s nothing new and a lot of fancy technologies or frameworks along the way caused some disruptions because people jumped on the hype train without applying some caution or critical thinking; but that evens out after a while.

Might be we see a big drop in usage when costs increase, but it’s also very very possible that the many technological advances we currently make (hardware to run models becoming more streamlined and the models themselves being tuned more and more) will mean, that we indeed reach a point where this can be done comparatively cheap and maybe even local (to some degree) without having to take out a loan.

I wouldn’t say “managed by LLM” though, just because you spot (partially) agent written commits. It’s hard to judge from the outside how much knowledge the maintainer puts into it. There a big band between vibe coding and fully manual coding. And if we are honest, even “fully manual” is a flexible term (does code completion count? does looking at stack overflow count? does looking at other implementations count? using a search engine?).

The world is changing, for better or worse. But cut devs some slack and let them get used to the tools. (And to re-iterate that: bad quality and bugs were a thing before agents as well. It just took longer.)

The machines I use regularly are all some form of ArchLinux (currently mostly CachyOS). Machines I use rarely I stick to LTS distros with few updates. Machines I don’t maintain myself I try to stick to immutable distros that just update themselves every once in a while (less chance of breakage).

Security is always applied in layers. The more the better. There’s a reason “encryption at rest” is a requirement in many audits.

Why full disk encryption is important: what happens when you switch servers or providers: can you be sure the disk gets wiped properly?

Or when your disk dies and gets replaced, what happens to the old disk? Will they physically destroy it or just throw it in the bin?

When encrypted, it doesn’t matter; no one will get data off of them. That’s why you encrypt servers.

Beautiful. Will keep an eye on it. Thank you!

One thing your answer dodges is the automation part. Do you plan on offering a cli to run individual workflows/scenarios? The UI is awesome for building and maintaining the workflows, but if I want to use them for automated testing for example I need to be able to run them headless.

Finally took the time to setup Woodpecker CI to replace Drone. Also finally linked it not only to my self hosted gitea, but also to github, so I can automate a few builds there as well.

In the process I also learned, that I can set up a whole bunch of pods in a single kube definition for podman/quadlets, which allows me to have a much cleaner setup. Previously I was only aware that you can define a single pod with multiple containers. It makes sense, but it never occurred to me before.

Sure. I also don’t want to shit talk XMPP. I prefer XMPP over Matrix any day. But it can be tricky (just like Matrix; which is funny, since Matrix set out to improve on the mistakes they claimed XMPP made).

The beauty of XMPP is this: you can use any server, and any client, and you can talk to anyone connected to the larger XMPP network, even if they made different server/client choices than you did.

That’s a very optimistic and naive view. XMPP consists of a shit ton of extensions, and different clients implement different subsets of these. So it’s very possible that two different clients fail to do an audio or video call, because the other decided to use a different extension than the other for not implement it at all.

Don’t let perfect be the enemy of good. Discord isn’t E2EE either. Having data under your control even if not encrypted is a big win.

Stalwart

Written in rust, contains SMTP, IMAP, JMAP, Sieve, CalDAV, CardDAV, WebDAV. Has an admin web ui. Sane defaults, minimal foot guns. No zoo of containers needed.