I use fluxcd with helmrelease's which auto update the helm release. If the helm chart versions specify container versions, then updating the helm chart updates the containers in the deployments.
But for raw deployments, I found this, but not much else.
In addition to adding more worker instances, you can also increase the amount of threads each worker instance uses to vertically scale. It's about equivalent to adding a worker instance.
Openbsd is definitely more secure than secureblue. There is only so much you can do to handle the massive monolithic architecture of the Linux kernel. Further down the stack, many parts of Linux, like sudo, dbus, or systemd are regularly hit by zero days. The SELinux domain architecture that Secureblue is interesting, but SELinux is extremely complex and difficult to get right, compared to the much more simpler pledge and unveil sandboxing that openbsd offers.
In addition to that, there are further issues like the problematic way that user namespaces interact with browsers. (And user namespaces are frustrating in general, secureblue actually has a short article on their problems). For maximum security, you want to sandbox tabs from eachother using user namespaces (only works on chromium btw, firefox can't do this so it doesn't matter) — BUT, if you run your browser in a sanbox created by user namespaces, then you can't nest them, disallowing you from using that powerful tool to isolate tabs. So you are forced to make a choice: You can either sandbox the browser itself, in exchange for weakening the isolation between tabs, or you can strengthen the isolation between tabs, in exchange for weaking the sandbox around the browser itself. Giving the browser access to user namespaces is questionable though, because see above, user namespaces have led to a lot of vulnerabilities.
OpenBSD's pledge + unveil (but only on chromium again), does not really make such tradeoffs. It can sandbox tabs from eachother, while also sandboxing the browser itself. In addition to that, pledge + unveil do not present a massive kernel attack surface that people have had to restrict for having too many 0days. And this is just one of the many, many examples, where OpenBSD presents a better security posture than Linux.
Qubes is technically Xen, a different kernel than Linux. The Xen kernel virtualizes Linux distros, from which you can manage Qubes/Xen, or do normal Linux app stuff. But nothing stops you from using a BSD virtualized by Xen for management or usage. Qubes talks about why they use Xen here — but the short version is that they did not consider the Linux kernel's kvm secure enough for their usecase.
Damn. This is cool af. I've seen so ,any interesting things with epbf, like bpfilter, facebook's ebpf firewall which they discussed being more performant.
I wonder if an epbf alternative to selinux is possible?
What port was this sent to, and what webserver are you running (if it was sent to a webserver)?
This reminds me of the string to strigger the really bad apache vulnerabilities that lead to being able to read from the whole filesystem (path traversal), or get a shell on your system (remote code execution). It's likelu that bots are spray and praying attempts across the internet. As long as you're up to date, you should be good.
I've had similar experiences with this FPS game called krunker.io
Krunker.io is a browser based game, and it had a pretty bad cheating problem, and since it was a browser based gamr, the devs could never implement an anticheat that worked for long.
They implemented a deputization system, where certain respected members of the community would become "krunker police", and then you could call them from a lobby. They would then invisibly spectate, and record and ban cheaters. The system worked really well, actually. Cheaters were banned quickly, and the requirement collection of video evidence held those involved accountable.
But krunker players had another interesting way of handling cheaters. You see, krunker has really bad netcode, bad enough that you would have to lead hitscan weapons a variable amount depending on how much ping you had. Krunker was also a movement shooter, where you could slidehop and go really, really fasy. The combination meant that you could dodge the shots of cheaters. As I got better, I just stopped calling krunker police, and started beating them. One of my fondest memories was this one lobby full of good players, and when a cheater joined we stomped them below all of us on the ranking, taunting them all the way down. At the end, they tried to sell their cheats and we all laughed. "Why would I buy these cheats? I'm better than them". Eventually they ragequit. Good times.
But nooooo, nowadays modern game publishers need control over every part of the game. They demand control over the servers, refusing to let anybody host their own communities. They demand absolute control over the community, but refuse to actually moderate it and handle toxicity. And now, they're demanding control over the clients, forcing you to install rootkits on your computers so they can control those too.
Look, I dislike permissive licenses too, but you need a source to back this claim up.
Right now, each BSD does something special, that Linux (distro's) can't trivially replace, even if the usecase is more niche. NetBSD Dev's make efforts to get it running on many devices as they can. OpenBSD (and it's subprojects) are highly secure, moreso than Linux. Who do you think makes our beloved OpenSSH? OpenSSH noted for having very few vulnerabilities over it's two decade long existence, and OpenBSD itself is similar, which is insane because there are products with multiple bad vulnerabilities every year (Linux being one of them...). This is due to a highly security minded architecture - one that Linux lacks.
FreeBSD is like Linux before systemd. I like systemd, but systemd is really trying to be kubernetes on a single node. I like systemd because I like kubernetes, but I understand why someone wouldn't like it, and I question if "single node k8s" is the best architecture for a single server or personal desktop. The ports system results in freebsd packaging many server services that aren't packaged on Linux. Being able to manage those through the system package manager, and the conviniences that provides, is nice.
This reminds me of the way that forgejo lets you feed it an arbitrary openid url, so you can log in with any service you want, including your own server.
Also, is this compatible with lemmy? The last time I tried fediverse (mastodon) login, it was with owncast, but it didn't work with lemmy.
Have you used ovirt? It's currently being maintained by Oracle after Red Hat gave it up.
I've been meaning to try it, but the documentation is dense and hard to get through, and I unironically find the openstack install instructions more approachable in some ways...
My recommendation is to use an abstraction layer that runs qemu-kvm under the hood and automate that. Some people have mentioned libvirt, but Incus is another good option.
go run works by compiling the program to a temporary executable and then executing that.
can you guarantee that runs everywhere
It seems to depend on glibc versions, if that's what you are asking. You can force it to be more static by using a static musl python or via other tools. Of course, a binary for Linux only runs on Linux and the same for Windows and Mac. But yeah.
Also it should be noted that go binaries that use C library dependencies are not truly standalone, often depending on glibc in similar ways. Of course, same as pyinstaller, you can use musl to make it more static.
You can also do it with C. Or Csharp. Or many other programming languages. It's not a feature unique to Go, it's just that Go can only create static binaries.
What about a static site generator? Plaintext, markdown, but renders to html with headings and whatnot. Version control is because it's in git.
Read access control is difficult though. You could do some hacks like using encrypting files in the git repo (perhaps with SOPS), and then either using http basic auth to control access to specific pages or something like staticrypt. But these are not ideal solutions.
Bluetooth probably won't be able to give you good quality audio and mic input at the same time. It doesn't have enough bandwidth over a single channel, last time I tried. Of course that was probably like 5 years ago and things might've changed, like a theoretical workaround I thought about is the headset simply having two bluetooth reveivers and connecting twice. But yeah.
Edit: I suspect jgrffn's comment in the thread refutes the above. I might test later.
Most of the proprietary wireless 2.4 ghz usb adapters I have tried have worked fine and better than bluetooth since they can do good audio and mic at low latencies. I have used logitech and corsair but my logitechs died on me (one I bought had the left side die and the other the right side :/) and the corsair earmuffs fell apart after I made the mistake of not being perfectly dry once. So I can't really recommend my most used headsets.
I use fluxcd with helmrelease's which auto update the helm release. If the helm chart versions specify container versions, then updating the helm chart updates the containers in the deployments.
But for raw deployments, I found this, but not much else.