#bsd — Public Fediverse posts

Just re-tested #GPUSPH on the #SteamDeck. Needed a bit to reorient myself, so I documented what is needed and added some information to the documentation.

I don't think anybody is going to run any serious testcase on it, but I like the fact that it does work on it. I should probably recheck also that it at least builds correctly on the various BSDs and on GNU Hurd.

Also I'm finding out that #FreeBSD is adding support for #HIP #ROCm

https://freebsdfoundation.org/blog/freebsd-foundation-intern-sourojeet-adhikari-on-bringing-rocm-to-freebsd/

so it'll be interesting to see if GPUSPH can be built on it *with* GPU support rather than just in CPU mode. (Does any BSD have #CUDA support?)

#BSD #GNUHurd #NVIDIA #AMD #GPGPU #GPU

I've always appreciated the simplicity of the BSDs. Power, yes, but without unnecessary complexity.

BastilleBSD and vm-bhyve have been my trusted companions for many years. But whenever I used Linux, I missed them.

That's why, years ago, I started putting together a collection of shell scripts (and some Python, although to a much lesser extent) to create something somewhere in between.

A bit of Bastille, a bit of vm-bhyve, a bit of Proxmox: unprivileged Linux system containers and virtual machines, managed from the command line.

Live backups. And live restore: bringing a workload back online before all its data has finished copying from the backup. Multiple storage backends. Encryption at the storage or individual workload level. Different networks. Isolation of each workload (a bit like illumos zones), with additional layers of protection.

Each container has its own UID/GID mapping. VMs run under separate unprivileged identities, with namespaces, seccomp and resource limits adding further layers of protection.

Pull-based backups from external hosts, with different levels and types of encryption. With raw encrypted ZFS replication, the backup server doesn’t even need the decryption keys. Backups are pulled over SSH by an external server. The workload host holds no credentials to log in to that server.

It also runs on a 1 GB Orange Pi PC 2, where I’ve tested both containers and native ARM64 KVM guests. And on a Orange PI One, armv7 and 512MB, it can run some lxc containers without problems, from the SD, using f2fs.

Simple disaster recovery. Because after those 142 servers went up in flames in Strasbourg, disaster recovery became something I care a lot about.

Currently supported and tested on Alpine Linux, Debian 13 and Armbian. On Debian, LXC containers also run under enforcing AppArmor profiles, adding another layer of protection.

Few commands. Lots of power. And it's called "Jail It!"

I'm not going to release it, at least not for now. I need to focus on my other projects, and Jail It! still needs some cleaning up.

But it works. And it does its job very well.

For containers, there's absolutely nothing running in the background. For VMs, just a small Python helper. No continuously running services. You connect via SSH, run your commands, and that's it.

Still, for anyone curious enough to have a look, I've put together a short demo on Asciinema:

https://asciinema.org/a/BbwGs99U9UJDLAzZ

Well, "short" might be a bit of an exaggeration. It's quite long, but I think it's worth watching all the way to the end.

#Linux #LXC #KVM #FreeBSD #Virtualization #OwnYourData #BSD #SelfHosting #Homelab #SysAdmin #DisasterRecovery