nitrolife

If you’re installing an HBA at home, it’s better to immediately install something like a Noctua NF-A4x10 on it. You should also immediately check the type of hardware initialization. If the system boots into EFI and the HBA is old and only supports BIOS, there may be problems. Otherwise, everything works perfectly with almost every device.

Because of the Wayland architecture, you simply cannot do it differently. Because Wayland is not a window manager, but a subsystem for working directly with video. This is not a new X11 server, it’s a different architecture. Therefore, by default, no matter where you choose, the render will be output to tty0 of your main server. You have only 2 options - use Wolf as is or manually assemble https://github.com/games-on-whales/gst-wayland-display and limit it to one video card via systemd. gst-wayland-display literally forcibly transfers the render not to tty0, but immediately to the stream for Moonlight.

So it’s not that Wolf is too complicated, it’s just that what you want is a rather complicated case.

UPD: although it is possible that you will be able to do this using wlheadless-run, but this will most likely be worse in terms of performance compared to gst-wayland-display. Although for a simple KDE session, I think there is no difference.

UPD2: I checked and, as I thought, regular applications will get along fine if you run them through wlheadless-run, but everything that requires vulkan may break. it’s the same with video cards. Simply specifying primary will not guarantee the use of a fixed card. But just for office work, I think it will be fine. however, as soon as the case starts to go beyond the standard, everything will start to break down if you have more than one GPU.

Just use wolf: https://games-on-whales.gitbook.io/wolf/stable/en/user/quickstart.md. Everything is ready out of the box. However, for a KDE session, you’ll have to rebuild KDE in the container instead of wolf-ui.

Never mind what’s ideal, in reality, one of my servers is running on a Core 2 Duo T7600 and when I installed ubuntu on it, it took 24 minutes to boot due to the unzipping of the base snap image in ubuntu server. Older hardware does not become faster just because os requirements change. And yes, I left ubuntu as soon as snap came out, i think that was 2018.

UPD: and of course I’m not going to change one of the local servers just because Canonical decided to release another system. Thanks. For 20 years the processor has been routing packets and will do so for another 20 without any problems. Just switched to another OS.

SNAP in the recommended packages of the ubuntu-server metapackage. Ubuntu installs all recommended packages by default. So SNAP is in the server installation, moreover, it can’t even be simply removed without completely blocking in apt policy.

SNAP also doesn’t work well with old hardware because of compression. It’s ironic to recommend system riddled with incompatible compression to someone who explicitly wrote in a post that they would be using outdated hardware.

If you’re planning to use old hardware for hosting, don’t use Ubuntu. SNAP will kill performance.

So your choice is Debian.

P.S. VPS is already a Virtual Private Server and you can’t install ProxMox or any virtualization on it. If you want experiments, look into containers.

In any program, you still have to execute a challenge somewhere. No program will issue certificates without that. In the case of certbot, you can simply write a small post hook that will transfer the certificates to cloudflare.

Just don’t expose SSH to internet. It’s a complex protocol with many CVEs. And you realyy don’t need access to SSH from anywhere. Replace access from ineternet to a WireGuard tunnel that has almost zero attack surface area and properly configured iptables rules. And that’s it.

I think the problem has been slightly exaggerated. If you’re not hosting several dozen services, you can reduce your attack surface down to one Nginx server. For an even stricter setup, just enable mTLS.

My provider doesn’t provide IPv6, but I rented a server in a data center, bought a subnet, and tunneled it home via WireGuard. So the scheme is roughly: VPS (fd00:1::/64) <-> (fd00:1::/64) Home router (realv6/64) <-> Home network

Router configuration:

/etc/sysctl.d/10-ipv6-privacy.conf

net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

/etc/radvd.conf

interface br0 {
    AdvSendAdvert on;
    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 30;

    AdvManagedFlag on;      # M=1 → Address via DHCPv6
    AdvOtherConfigFlag on;  # O=1 → Additional options via DHCPv6

    # SLAAC is still possible for Android
    prefix realv6::/64 {
        AdvOnLink on;
        AdvAutonomous on;   # Allow SLAAC
    };

    RDNSS realv6::1 {
        AdvRDNSSLifetime 1800;
    };
    DNSSL home.lan {
        AdvDNSSLLifetime 1800;
    };
};

/etc/kea/kea-dhcp6.conf

{
  "Dhcp6": {
    "interfaces-config": {
      "interfaces": [ "br0" ]
    },

    "lease-database": {
      "type": "memfile",
      "persist": true,
      "lfc-interval": 86400,
      "name": "/var/lib/kea/dhcp6.leases"
    },

    "renew-timer": 21600,
    "rebind-timer": 43200,
    "preferred-lifetime": 43200,
    "valid-lifetime": 86400,

    "subnet6": [
      {
        "id": 1,
        "subnet": "realv6::/64",
        "interface": "br0",
        "pools": [
          { "pool": "realv6::1000 - realv6::ffff" }
        ],
        "option-data": [
          { "name": "dns-servers",   "data": "realv6::1" },
          { "name": "domain-search", "data": "home.lan" }
        ]
      }
    ],

    "loggers": [
      {
        "name": "kea-dhcp6",
        "output-options": [
          { "output": "stdout" }
        ],
        "severity": "WARN"
      }
    ]
  }
}

And of course, iptables is necessary. Something like: /etc/iptables/ip6tables.rules

# Generated by ip6tables-save v1.6.0 on Thu Sep  8 13:29:11 2016
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
#BASE INPUT
-A INPUT -i eno1 -j DROP
-A OUTPUT -o eno1 -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eno1 -j DROP
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p ipv6-icmp -j ACCEPT
COMMIT

Yes, it is. But I have llama-swap, openweb-ui. If you spend some time on the llama-swap configuration, then the you have a good chance to run the model on 2 cards is through llama.cpp. The winnings, however, will not be x2 of course and will fall non-linearly from the number of cards. And you need motherboard with good PCI-E lines (2 pci-e x16 or more). But it’s still cheaper than one large card. Example:

HIP_VISIBLE_DEVICES=0,1 \
/opt/llama.cpp/build/bin/llama-server \
  --host 127.0.0.1 \
  --port 8082 \
  --model /storage/models/model.gguf \
  --n-gpu-layers all \
  --split-mode layer \
  --tensor-split 1,1 \
  --ctx-size 32768 \
  --batch-size 512 \
  --ubatch-size 512 \
  --flash-attn on \
  --parallel 1

There is a less stable but more productive one: --split-mode row

P.S. By the way, one RX9070XT on my instance translates posts and comments. You can test it if you want. =)

not a very popular opinion, but if you want an inexpensive, really inexpensive variant, take the AMD MX9070XT. AMD is not the most popular AI cards, but they are not bad with ROCm and for the price of 5090 you can put 5 cards (80 GB vram)