

Tailscale already does though, I think.
https://tailscale.com/docs/features/tailscale-funnel
Although it might work differently.


Tailscale already does though, I think.
https://tailscale.com/docs/features/tailscale-funnel
Although it might work differently.


FreeBSD, OpenBSD and NetBSD are behind Linux.
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.
Different, and not popular don’t mean bad.


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 create static binaries that bundle the python interpreter and dependencies.
It’s the onefile option in pyinstaller: https://pyinstaller.org/en/stable/usage.html#cmdoption-F
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.


oh I have tested this game somewhat, although I’ve never actually played it. It is very impressive.


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.


This is technically yaml I think, a list (with one entry) of lists that contains mostly single items but also one other list. You should be able to parse this with a yaml parser like pythons built in one.
Note that yaml is picky abiut the syntax though, so it wouldn’t be able to handle deviations.


I won’t lie, I use curl | bash as well, but I do dislike it for two reasons:
Firstly, it is much, much easier to compromise the website hosting than the binary itself, usually. Distributed binaries are usually signed by multiple keys from multiple servers, resulting in them being highly resistant to tampering. Reproducible builds (two users compiling a program get the same output) make it trivial to detect tampering as well.
On the other hand, websites hosting infrastructure is generally nowhere near as secure. It’s typically one or two VPS’s, and there is no signature or verification that the content is “official”. So even if I’m not tampering with the binary, I can still tamper with the bash script to add extra goodies to it.
On the other hand (but not really relevant to what OP is talking about), just because I trust someone to give me a binary in a mature programming language they have experience writing in, doesn’t mean I trust them to give me a script in a language known for footguns. A steam bug in their bash script once deleted a user’s home directory. There have also been issues with AUR packages, which are basically bash scripts, breaking people’s systems as well. When it comes to user/community created scripts, I mostly trust them to not be malicious, and I am more fearful of a bug or mistake screwing things up. But at the same time, I have little confidence in my ability to spot these bugs.
Generally, I only make an exception for running bash installers if the program being installed is a “platform” that I can use to install more software. K3s (Kubernetes distro), or the Nix package manager are examples. If I can install something via Nix or Docker then it’s going to be installed via there and not installed via curl | bash. Not every developer under the sun should be given the privilege of running a bash script on my system.
As a sidenote, docker doesn’t recommend their install script anymore. All the instructions have been removed from the website, and they recommend adding their own repo’s instead. Personally, I prefer to get it from the distro’s repositories, as usually that’s the simplest and fastest way to install docker nowadays.


Docker compose’s don’t really need to be maintained though. As long as the app doesn’t need new components old docker composes should work.
EDIT: Oops, it does look like spacebarchat’s docker images have last been updated over 2 years ago:
https://hub.docker.com/r/spacebarchat/server
EDIT2: Although this is outdated, I think their github repo has an action to autobuild docker images on pushes. Still investigating.
EDIT3: Okay, they don’t seem to be actually ran.
But using nix to build a docker image is pretty cool.
EDIT4: Oh shit, the docker image build workflows were added just 2 hours ago. Of course they haven’t been ran!
Docker support soon, probably.
EDIT5: the workflow ran, but it looks like it’s private for now.
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.