Remote kernel execution should not be the bitter problem of development i.e. the identification of "human" capitol.
Perhaps formalisation lends values, which deploy in the analysis of field research.
Back to FreeBSD – Part 2 – Jails
21–30 of 33 posts
Re: Back to FreeBSD – Part 2 – Jails
#22The main drawback I saw on jails is that they are FreeBSD. The owner doesn’t mention, and I have not researched it, but can you run any Linux distribution in a FreeBSD jail?
If you mean an isolated linux instance _including a linux kernel_, that would be provided by a virtual machine running under the bhyve hypervisor on freebsd (https://docs.freebsd.org/en/books/handbook/virtualization/#v...). You probably could frankenkludge something like linux-userland-on-a-frebsd-kernel using jails but that certainly seems like the path less traveled, haha. :)
Re: Back to FreeBSD – Part 2 – Jails
#23Our report concludes SQL as "mostly" inept, pivoting to the following:
Identification of C++ develeopers
Compilation of C++ code into Python
Recursive .py scripts that are sector-enframings of the general "neural" framework deployment.
Re: Back to FreeBSD – Part 2 – Jails
#24Earlier quoted context omitted.
Very often you can, or could, because the software is portable (e.g. Node or Python or Postgres), and / or platform-independent (e.g. written in JS, Python, bash, etc). In my practice it was completely normal to build things inside a container to be deployed on Linux using the same sources and basically the same package names and versions as used on a developer macOS machine (which is BSD-like enough down below).
> macOS machine (which is BSD-like enough down below) That's like saying an Ubuntu .deb will work on Gentoo because it's all Linux anyway. It's not that simple. There is dependencies and there are differences in the packages, package managers and surrounding system for a reason. It's not 1:1. Perhaps the naming scheme happened to line up for the packages you where using, but this should be considered not assumed. It…
> It's not that simple.
It would tremendously benefit almost everyone if it were.
> There is dependencies and there are differences in the packages, package managers and surrounding system for a reason.
Yeah, the NIH syndrome. And sometimes, of course, there are decent technical reasons as well.
Re: Back to FreeBSD – Part 2 – Jails
#25The article is written by the people who created jail.run [0] Ten years in with Docker and Linux containers I felt something was very wrong so I looked at how Solaris and FreeBSD were doing it and I saw the light (too). I would agree with them: bringing the Dockerfile format to jails doesn't make any sense, unless you just want to attract curious Linux users. Dockerfiles are useful and familiar but are also an abomin…
Would Daemonless[0] solve this problem, or is it at least a step in the right direction? [0] https://daemonless.io/
Daemonless is a bit the linuxserver.io of FreeBSD to me. It is a collection of standardized images.
Behind each image you have a Containerfile [0] and a compose.yaml [1] And inside the Containerfile for Gitea you simply have a `RUN pkg install -y gitea` [2], so basically here it is the good old FreeBSD Gitea port [3]
I guess this is really a Linux/Docker users friendly wrapper on the 30 years old FreeBSD ecosystem?
When I came from Linux to FreeBSD, Gitea was one of the first service I ran in a jail to learn how it all works. What I was happy to discover is I just need to do `pkg -j mygiteajail install gitea` to install Gitea in the jail with all the rc scripts, etc.
The jail abstraction was just one option (`-y`) in pkg ! This is really the beauty of the all integrated FreeBSD. So to be honest the Daemonless have, in some case at least, made everything more complicated in my view...
- [0] https://github.com/daemonless/gitea/blob/main/Containerfile....
- [1] https://github.com/daemonless/gitea/blob/main/compose.yaml
- [2] https://github.com/daemonless/gitea/blob/9bb9151d31ae6574e5f...
Re: Back to FreeBSD – Part 2 – Jails
#26one thing that bit me with LXC: anything that needs its own kernel module won't work. jails have the same limitation — shared host kernel. ran into this trying to run a VPN server (needs DKMS for a custom wireguard fork) in an LXC container — module can't load, period. ended up on a full KVM VM.
Re: Back to FreeBSD – Part 2 – Jails
#27I'll bite: how do we take advantage of ZFS layering if not via the docker-style layering? I find dockerfile layering to be unsatisfying because step 5 might depend on step 2 but not 3 or 4... the linearisation of a DAG makes them harder to maintain and harder to cache cleanly (with us also having monster single-line CMDs all in the main of image results). So is there a better way that people are using?
FS layers are a poor replacement for a package manager, so maybe just don't use wrong tools for a job?
Re: Back to FreeBSD – Part 2 – Jails
#28The article is written by the people who created jail.run [0] Ten years in with Docker and Linux containers I felt something was very wrong so I looked at how Solaris and FreeBSD were doing it and I saw the light (too). I would agree with them: bringing the Dockerfile format to jails doesn't make any sense, unless you just want to attract curious Linux users. Dockerfiles are useful and familiar but are also an abomin…
Some time ago I entertained the idea of a Terraform provider for jails. There's no API tho, but that's fixable.
Re: Back to FreeBSD – Part 2 – Jails
#29I'll bite: how do we take advantage of ZFS layering if not via the docker-style layering? I find dockerfile layering to be unsatisfying because step 5 might depend on step 2 but not 3 or 4... the linearisation of a DAG makes them harder to maintain and harder to cache cleanly (with us also having monster single-line CMDs all in the main of image results). So is there a better way that people are using?
FS layers are a poor replacement for a package manager, so maybe just don't use wrong tools for a job?
[deleted]
Re: Back to FreeBSD – Part 2 – Jails
#30I think they understate the importance of accepting OCI and Dockerfile semantics as a path to an external "run one of these" and having it actually emerge as a jail based outcome. I get saying "we don't need these additional layers/abstractions" but what it ignores is me saying "I want to run this code, and what I have is a suite of Docker based behaviour and I want a low friction path to use that Docker compose meth…
Isn’t podman already supported? I wouldn’t be surprised that there already exist tools that will jail-ify that as well.