Skill issue. I have to constantly convince the models that what I want to do is in fact possible, and that the "alternate paths" they give are things I already considered but discarded because of various reasons.

It's gotten to the point where I would ask them to search for blogs directly, but they still try to give me hallucinated slop that isn't actually what I want instead of following my instructions of being a search engine that filters out all the SEO slopspam that's so prevalent nowadays.

I currently am doing:

https://blogsearch.io/

https://marginalia-search.com/

To find blogs directly.

Although I do almost exclusively Linux/Kubernetes stuff, and very little programming atm, that might be why I have a different experience.

Back when chatgpt wasn't as broad (and people hadn't posted blogs on as many things) I used to assign students things that chatgpt would find impossible do solve, and I got great glee from watching them spend a day trying to get chatgpt to do it entirely for them, before they gave up and had to actually learn. They can learn from chatgpt ofc, idrc, but it wouldn't be able to do ut for them.

Nowadays, things like "set up nextcloud with caddy instead of apache" have 10 thousand (real, non hallucinated) blogposts about them, which have been fed into chatgpt so it can do that without much difficulty.

It is getting harder to find things that beginners can do that chatgpt can't, but as soon as you move beyond the level of advanced beginner (also called being stuck in tutorial hell) in linux, you quickly find the LLM can't do everything for you.

Tailscale works great, but their free tier is limited to a total of 8 users, which is enough for a tiny minecraft server, but doesn't seem to be enough for your usecase.

For 10-15+ users, you probably want to self host a VPN on your own VPS. Like, you can self host headscale, which is tailscale but self hosted. : https://github.com/juanfont/headscale [1]

I wouldn't port forward game servers, because they often lack authentication (login and stuff), and then they also have security issues due to not receiving updates. If your game server isn't truly public, then it's easier to just have people use the tailscale client to connect to your VPN.

[1] Although I would recommend headscale to OP for it's simplicity, it is very barebones, and software like netbird or netmaker is more close to a truly self hosted tailscale, with things like more advanced accounts, OIDC integration, authorization, and so on. But they are more annoying to host and set up.

This was not a simple configuration change but a manual, labor-intensive purge.

AI slop pattern.

Also the article appears to be completely unsourced. Here are what I believe to be the main sources:

https://joeyh.name/blog/entry/no_LLM_code_in_dependencies/

https://git-annex.branchable.com/no_llm_code/

"Just patch" is advice for a windows administrator, where updates break everything so you have to sit and baby them and apply them manually.

On Linux, there are ways to enable automatic security updates, including automatic reboots, so you can safely receive the mitigations your distro provides. That way, you don't have to worry about forgetting to patch (until the distro release becomes unmaintained, at least).

Now, dirty frag was a zero day, meaning that it was released and probably in the wild before a mitigation was pushed out to handle it. So you did need to apply an actual configuration patch... unless you had some form of kernel based isolation, which I mention as #2 of my other comment in this thread: https://programming.dev/post/52129409/24414213

Excellent writeup, and I appreciate the transparency. I have some suggestions on how to mitigate something like this from happening in the future.

1. Use a separate DBMS (that is, a separate postgres/mariasql/etc container) for each service. Give each one service unique passwords, which you can define in the docker compose.

This is simpler than trying to control postgres permissions granularity. Even if one application that connects to a database gets owned, it doesn't have access to other postgres databases, preventing data leaks/exfiltration.

2. Use a virtual machine or application container based runtime for your containers.

Kata containers is a container runtime, that is virtual machine.

There is also Gvisor and Syd Box, which are application kernels. Application kernels are reimplimentations of the parts of the Linux kernel needed to run apps, and in this case both Gvisor (Go) and Syd Box (Rust) are in memory safe langauges.

Kata containers are faster, but you will need nested virtualization in order to use them. Application kernels are slower, but you can install them anywhere, including hosts where virtualization is disabled (like a VPS that doesn't let you enable nested virtualization.

Both take a tiny bit more resources intensive due to no longer being able to share the host kernel, but for most part, it is worth it. They don't bring an entire kernel along, just what is needed to run apps.

Both offer similar levels of isolation, and preventing applications running inside them from touching the host kernel directly. They effectively manage to prevent issues like copy fail, dirty frag, and so on, from owning your host.

They are fairly easy to install, docker has some docs here: https://docs.docker.com/engine/daemon/alternative-runtimes/ . But if you are using podman or kubernetes, you can also install them there.

3. Enable automatic security updates (and reboots) on stable distros.

A large part of the draw of stable Linux like Debian or Red Hat, is that they only do security updates. They don't do feature updates, or even bug fixes (except for critical ones). In doing so, there is essentially a guarantee of reliability, where it is impossible for updates to break anything.

This makes it possible to enable automatic security updates, and you can even configure it to automatically reboot in order to load a new kernel that includes mitigations against issues like dirty frag. Make sure your docker containers are configured to automatically restart and everything will be smooth.

"Just patch" is a good but it is never enough, and I am frustrated hearing it so frequently. The way I view it is, any time I have to patch, what I really need to do is to improve my security architecture so I never have to "patch" this specific issues again. Patches are the exact kind of security toil that I complain about in this comment.

Show is better than tell:

Often, when viewing images, firefox "caches" the image in order to be able to load it faster when visiting that site again. Left unchecked, this cache (of images and other assets) can pretty much infinitely grow. Many other apps also have big caches.

Bleachbit actually is useful. Instead of hunting through your system and accidentally rm -rfing the wrong folder and losing all your precious firefox profile data, it enables you to quickly nuke all caches, freeing up a significant amount of space. I would probably free up 15gb+ if I ran it based on these images.

EDIT: just ran it. I freed up 6gb of space. Not 15gb. Huh. Still, pretty good though, and if you are space starved (I used to use a machine with only 32 gb of storage TOTAL), then it's useful to keep things slim.

https://github.com/spacebarchat/spacebarchat

Literally reverse engineered discord, made open source.

I don't see any mention of games so far.

A minecraft server is always a good time with friends, and there are hundreds of other game servers you can self host.

#1 things holding back Nix adoption is piss poor documentation

The docs are bad because there is this massive split between flakes and nonflakes , where flakes are considered "unstable" and "experimental" but a ton of people use them. The official docs, due to flakes being experimental, can't really touch on that topic at all, and the unofficial docs will mostly be flakes only. And some things can only be done via flakes or only via channels, so that furthers the issue.

There was another discourse post about it, and it was agreed that the nix team just needs to choose something, as the problem is the split and indecisivice, rather than flakss or channels (old way) being uniquely bad.

where Nix “3rd party” tooling shines is in documentation

Determinate systems nix ships with flakes enabled by default. Official nix does not. This means thay determinate nix has a much easier time documenting their product as they exclusively use flakes.

The problem and potential conflict of interest documented in that thread, is that many of the determinate systems employees are big nix contributors with much power over nix official

including Eelco Dostra, the inventor of nix and the creator of flakes. Despite clearly doing recent work with flakes, and clearly contributing to making flakes the "default" in determinate nix, very little effort has been put into making flakes official by these same contributors.

The fear is that nix official is being intentionally kept bad, in order to push the product of determinate systems nix.

https://owncast.online

One lgbtq+ streamer I know dual streams to owncast

The directory is a list of live owncast streams.

Also, you should be able to chat on owncast streams with fediverse accounts, but the last time I tried, I wasn't able to log log in with my lemmy account.

I disagree, because they are not the same thing.

Immutable means read only root.

Atomic means that updates are done in a snapshotted manner somehow. It usually means that if an update fails, your system is not in a half working state, but instead will be reverted to the last working state, and that updates are all or nothing.

I create a btrfs snapshot before updates on my Arch Linux system. This is atomic, but not immutable.*

There is also "image based" which distros like ublue (immutable, atomic) are, but Nixos (also immutable and atomic) are not.

*only really before big updates tbh, but I know some people do configure snapshits before all updates.

Discord is adding ads soon. Currently, they don't enforce the TOS violation of custom clients, but maybe after they add ads, they will begin to do so. I would be very careful with any of this.