koala

Incus has a great selection of images that are ready to go, plus gives scripted access to VMs (and LXC containers) very easily; after incus launch to create a VM, incus exec can immediately run commands as root for provisioning.

Well, it's more procedural than object-oriented because it's easier to avoid object-oriented programming than procedural code :D

(Note: I wouldn't call defining classes OOP until you start using inheritance. Overriding __str__ and stuff might count, but not a lot to me.)

Personally, as time goes on, I use inheritance less.

Nextcloud is in EPEL 10. You'll get updates along with the rest of the OS.

I have been using EPEL 9 Nextcloud for a good while and it's been a smooth experience.

If you want specifically Docker, I would not choose an EL10 distro, really. I have been test driving AlmaLinux 10 and it's pretty nice, but I would look elsewhere.

IMHO, it really depends on the specific services you want to run. I guess you are most familiar with Docker and everything that you want to run has a first-class-citizen Docker container for it. It also depends on whether the services you want to run are suitable for Internet exposure or not (and how comfortable you are with the convenience tradeoff).

LXC is very different. Although you can run Docker nested within LXC, you gotta be careful because IIRC, there are setups that used to not work so well (maybe it works better now, but Docker nested within LXC on a ZFS file system used to be a problem).

I like that Proxmox + LXC + ZFS means that it's all ZFS file systems, which gives you a ton of flexibility; if you have VMs and volumes, you need to assign sizes to them, resize if needed, etc.; with ZFS file systems you can set quotas, but changing them is much less fuss. But that would likely require much more effort for you. This is what I use, but I think it's not for everyone.

I don't use Nextcloud calendars or address books. But I assume they are included in regular backups.

I pay about 50€ for all absolute overkill Hetzner dedicated server (128gb of RAM).

I live in two different flats in different cities because of personal circumstances.

I switched to Emacs over two years ago because I was getting too comfortable in VS Code. If VS Code didn't have the "dodgy" stuff, I would recommend it to everyone without reservation.

Emacs has been a pleasant surprise. The latest versions have introduced Eglot (LSP), EditorConfig and a few other odds and ends that make it very close to being usable with very little configuration. My latest suggestion for getting started is JUST two lines of config, and I think you can scale easily.

I just wish Emacs had started from the outset with more common keybindings- it makes it hard to recommend because you need to make a significant investment. I think it's worthwhile, but still...

However, due to how it's evolving lately, I suspect it might become even easier to get started with time. If they rolled in to base Emacs automatic LSP installation, that would be huge, for instance.

I assume you basically want protection against disasters, but not high uptime.

(E.g. you likely can live with a week of unavailability if after a week you can recover the data.)

The key is about proper backups. For example, my Nextcloud server is running in a datacenter. Every night I replicate the data to a computer running at home. Every week I run a backup to a USB drive that I keep in a third location. Every month I run a backup to a USB drive on the computer I mentioned at home.

So I could lose two locations and still have my data.

There is much written about backup strategies, for example https://en.wikipedia.org/wiki/3-2-1_backup_rule ... Just start with your configuration, think what can go wrong and what would happen, and add redundancy until you are OK with the risks.

What volume of data you are discussing? How many physical nodes? Can you give a complete usage example of what you want to achieve?

In general, there's a steep change in making things distributed properly, and distributed systems are often designed for big and complex situations, so they "can afford" being big and complex too.

Running LanguageTool locally is a bit of a pain, with some manual steps. Plus you have to fetch some data files. You can find around a few projects like this one to make it easier to run LanguageTool.

And yes, as the poster mentioned, LanguageTool keeps some code exclusive to their paid version. There's a bit of a tension because they ask people not to extend OSS LanguageTool with their paid features.

There's also this interesting clone, but it seems abandoned.

I dunno, I still have a soft spot for Proxmox. I want ZFS, so it's about the only game in town with support.

(TrueNAS Scale looks good, but it would increase too much my Hetzner costs, because of their requirement of having a dedicated root pool. And I don't want an LTS distro that supports root-on-ZFS "oficially". That narrows the field quite a bit.)

(For work and for my workstations, I'm very pleased with Incus on top of Debian... but that's because I don't need ZFS on those.)

Ah, sucks :(

I'm looking forward to see where Incus OS goes, or TrueNAS Scale. Honestly, I was very tempted to automate a procedure to take a Proxmox ZFS install and replace the Proxmox bits with Incus bits :) Incus + ZFS as an appliance would be nice. I kinda don't want to think about the underlying OS.