Samsung doesn’t actually make dimms as far as I know

They do both. This is what I have in my server, for example:

https://semiconductor.samsung.com/dram/module/rdimm/m321r8ga0eb2-ccp/

Disagree. Their priorities are backwards.

Company A releases a product, it runs closed-source proprietary firmware on-board, and it can’t be updated by the user even if bugs or compatibility issues are found later on in the product’s life cycle.

Company B releases a product, it runs closed-source proprietary firmware on-board, but it can be updated by the user if bugs or compatibility issues are found later on in the product’s life cycle.

According to the FSF, product A gets the stamp of approval, product B doesn’t. That makes no sense.

It has nothing to do with LLM poisoning, they just want attention

I use node_exporter + VictoriaMetrics + Grafana for network-wide system monitoring. node_exporter also has provisions to include text files placed in a directory you specify, as long as they’re written out in the right format. I use that capability on my systems to include some custom metrics, including CPU and memory usage of the top 5 processes on the system, for exactly this reason.

The resulting file looks like:

# HELP cpu_usage CPU usage for top processes in %
# TYPE cpu_usage gauge
cpu_usage{process="/usr/bin/dockerd",pid="187613"} 1.8
cpu_usage{process="/usr/local/bin/python3",pid="190047"} 1.4
cpu_usage{process="/usr/bin/cadvisor",pid="188999"} 1.0
cpu_usage{process="/opt/mealie/bin/python3",pid="190114"} 0.9
cpu_usage{process="/opt/java/openjdk/bin/java",pid="190080"} 0.9

# HELP mem_usage Memory usage for top processes in %
# TYPE mem_usage gauge
mem_usage{process="/usr/local/bin/python3",pid="190047"} 3.0
mem_usage{process="/usr/bin/Xvfb",pid="196573"} 2.4
mem_usage{process="/usr/bin/Xvfb",pid="193606"} 2.4
mem_usage{process="next-server",pid="194634"} 1.2
mem_usage{process="/opt/mealie/bin/python3",pid="190114"} 1.2

And it gets scraped every 15 seconds for all of my systems. The result looks like this for CPU and memory. Pretty boring most of the time, but it can be very valuable to see what was going on with the active processes in the moments leading up to a problem.

I think so. I’ve been using it for over a year, as another poster said Kagi feels like Google did 15 years ago, before it destroyed itself.

Every time I use a search on another machine, my first reaction is “oh my god what is all of this shit everywhere? ads, spam, AI slop, shopping garbage, etc”, then I quickly realize it’s not my computer and that’s just what Google looks like now.

dealing with incoming spam is just way more work than paying to have it hosted.

The right way to deal with spam is not to use filters in the first place. It’s not like Gmail or Proton or <insert your favorite email provider here>'s spam filters are perfect either, far from it, they still let a ton of shit through. The right way to deal with spam is to use unique aliases for each account that you can shut down if they leak.

In my opinion, Proxmox is worth it for two reasons:

1. Easy high-availability setup and control

2. Proxmox Backup Server

Those two are what drove me to switch from KVM, and I don’t regret it at all. PBS truly is a fantastic piece of software.

They explicitly said that the goal of buying it was to turn it into a rightwing propaganda machine

It’s a scam because the prices they’re charging right now don’t reflect the actual costs. AI companies are trying to get people and companies hooked on it so that once they crank the prices up by 10x to start turning a profit, they’ll be able to maintain some semblance of a customer base. If they were charging the real prices a year ago, the AI bubble would have never reached the levels it has, and these companies wouldn’t be worth what they are now. It’s all propped up on a lie.

Every couple of days. I don’t auto-update, but I’ve streamlined the process to the point that I can just open a single web page and see the number of pending updates for every system on my network, docker containers included, each one with a button. Clicking the button applies the update and reboots if necessary. So it takes about 15 seconds of effort to update everything, which is why I don’t mind doing it so often.

I don’t have any problems with building beautiful things like cathedrals or making art in the name of God

What about Catholics praying to little figurines and statues of saints? Because that’s been going on for a long time

I’ve experienced far fewer bugs on KDE 6 than Mint or Cinnamon, and I refuse to use GNOME. What else are you comparing against?

I am more surprised by how popular Proxmox seems to be here, which is really just adding a lot of unnecessary complexity

I switched to Proxmox for one reason: PBS. As far as I know there is no match with plain KVM. Proxmox also makes setting up and maintaining a high-availability setup very easy, which is a nice bonus.

I used to use 2FAS, but recently switched to a self-hosted instance of Ente

Got a friend or family member willing to let you drop a miniPC at their place?

You could also go the offline route - buy two identical external drive setups, plug one into your machine and make regular backups to it, drop the other one in a drawer in your office at work. Then once a month or so swap them to keep the off-site one fresh.

Also there’s really nothing wrong with cloud storage as long as you encrypt before uploading so they never have access to your data.

Personally I do both. The off-site offline drive is for full backups of everything because space is cheap, while cloud storage is use for more of a “delta” style backup, just the stuff the changes frequently, because of the price. If the worst were to happen, I’d use the offsite drive to get the bulk infrastructure back up and running, and then the latest cloud copy for any recently added/modified files.

The hard links aren’t between the source and backup, they’re between Friday’s backup and Saturday’s backup

If you want a “time travel” feature, your only option is to duplicate data.

Not true. Look at the --link-dest flag. Encryption, sure, rsync can’t do that, but incremental backups work fine and compression is better handled at the filesystem level anyway IMO.

There are two ways to maintain a persistent data store for Docker containers: bind mounts and docker-managed volumes.

A Docker managed volume looks like:

datavolume:/data

And then later on in the compose file you’ll have

volumes:
  datavolume:

When you start this container, Docker will create this volume for you in /var/lib/docker/volumes/ and will manage access and permissions. They’re a little easier in that Docker handles permissions for you, but they’re also kind of a PITA because now your compose file and your data are split apart in different locations and you have to spend time tracking down where the hell Docker decided to put the volumes for your service, especially when it comes to backups/migration.

A bind mount looks like:

./datavolume:/data

When you start this container, if it doesn’t already exist, “datavolume” will be created in the same location as your compose file, and the data will be stored there. This is a little more manual since some containers don’t set up permissions properly and, once the volume is created, you may have to shut down the container and then chown the volume so it can use it, but once up and running it makes things much more convenient, since now all of the data needed by that service is in a directory right next to the compose file (or wherever you decide to put it, since bind mounts let you put the directory anywhere you like).

Also with Docker-managed volumes, you have to be VERY careful running your docker prune commands, since if you run “docker prune --volumes” and you have any stopped containers, Docker will wipe out all of the persistent data for them. That’s not an issue with bind mounts.

Docker is far cleaner than native installs once you get used to it. Yes native installs are nice at first, but they aren’t portable, and unless the software is built specifically for the distro you’re running you will very quickly run into dependency hell trying to set up your system to support multiple services that all want different versions of libraries. Plus what if you want or need to move a service to another system, or restore a single service from a backup? Reinstalling a service from scratch and migrating over the libraries and config files in all of their separate locations can be a PITA.

It’s pretty much a requirement to start spinning up separate VMs for each service to get them to not interfere with each other and to allow backup and migration to other hosts, and managing 50 different VMs is much more involved and resource-intensive than managing 50 different containers on one machine.

Also you said that native installs just need an apt update && apt upgrade, but that’s not true. Services that are built into your package manager sure, but most services do not have pre-built packages for all distros. For the vast majority, you have to git clone the source, then build from scratch and install. Updating those services is not a simple apt update && apt upgrade, you have to cd into the repo, git pull, then recompile and reinstall, and pray to god that the dependencies haven’t changed.

docker compose pull/up/down is pretty much all you need, wrap it in a small shell script and you can bring up/down or update every service with a single command. Also if you use bind mounts and place them in the directory for the service along side the compose file, now your entire service is self-contained in one directory. To back it up you just “docker compose down”, rsync the directory to the backup location, then “docker compose up”. To restore you do the exact same thing, just reverse the direction of the rsync. To move a service to a different host, you do the exact same thing, just the rsync and docker compose up are now being run on another system.

Docker lets you compact an entire service with all of its dependencies, databases, config files, and data, into a single directory that can be backed up and/or moved to any other system with nothing more than a “down”, “copy”, and “up”, with zero interference with other services running on your system.

I have 158 containers running on my systems at home. With some wrapper scripts, management is trivial. The thought of trying to manage native installs on over a hundred individual VMs is frightening. The thought of trying to manage this setup with native installs on one machine, if that was even possible, is even more frightening.

Pretty much guaranteed you’ll spend an order of magnitude more time (or more) doing than than just auto-updating and fixing things on the rare occasion that they break. If you have a service that likes to throw out breaking changes on a regular basis, it might make sense to read the release notes and manually update that one, but not everything.