Okay, I hath returned.

So I used to play a game called krunker.io. It was browser game, but I would use a native, electron based client. I spent a lot of time tinkering to figure out what options would maximize performance, and because I had a laptop with an Nvidia gpu, a few special flags were needed. Here was the full command that I would run to run the client:

gamemoderun prime-run ./crankshaft-portable-linux-x86_64.AppImage -no-sandbox --ignore-gpu-blocklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers --enable-zero-copy --disable-gpu-vsync --disable-frame-rate-limit --ozone-platform-hint=wayland > /dev/null 2>&1

You probably don’t want gamemoderun. But you can play with the rest of the flags there. I don’t remember what was needed and what was there for performance. I’m pretty sure that the first two arguments there were needed though.

I don’t think anubis can proxy webdav. So that breaks.

Instead of putting anubus at 443, put it at the port 80 block. Or at the 5555 block.

What you probably need to do is make it so that webdav traffic isn’t proxied through anubis.

I know this issue, I had a similer issue trying to get the client for krunker.io working with my nvidia gpu. I might have the solution saved somewhere, this comment is so I can remind myself to check.

2 main reasons.

1. Using cloud environments is a pretty cheap and easy way to do data prevention loss, which is what corpos call it when they implement measures to prevent data from getting leaked. If you store all the data in this and gate this behind 2fa, then getting the main device hacked leaks no data provided the “cloud os” is logged out.

2. Chromebook users. Docs suck, onlyoffice web sucks less.

Similar: anuraos, https://github.com/MercuryWorkshop/anuraOS

Anuraos is special because it uses a js linux emulator to execute linux apps. Very, very slowly. But it’s there and there is even gui support.

Yes, but there is something important to remember.

By default, most Linux installs put there kernels in /boot, which is not on the btrfs partition. This is not an issue on distros that keep multiple kernel versions, but it can cause issues on distros that only provide one kernel version (Arch and Arch based distros).

Because the kernels are not stored on the btrfs partition, they are not restored by btrfs snapshots. And if the rest of the system, including kernel modules, are a mismatched version due to restoration, then it means your system is unbootable.

A simpler fix is to install ArchLinux’s linux-tls package, which is the stable version of Linux that doesn’t update constantly.

But what I do to get around this, I put /boot on the btrfs partition, and /boot/efi is the seperate efi partition where grub is installed. Then, kernels are restored when I restore a snapshot.