<500 lines and uses only the rust standard library to make auditing easy.
This will be a game changer for porting to NixOS to new init systems, and even new kernels.
So, it's good time to be experimenting with things like Nitro here!
https://docs.aws.amazon.com/whitepapers/latest/security-desi...
Giving the readme a brief scan, it doesn't look like it currently handles service dependencies?
And your software can do it, if it's written with the assumption that it will be pid1, but most non-init software isn't. And rather than write your software to do so, it's easier to just reach for something like tini that does it already with very little overhead.
I'd recommend reading the tini readme[0] and its linked discussion for full detail.
ostree+grub could be much better at handling failover like switches and rovers that then need disk space for at least two separate A/B flash slots and badblocks and a separate /root quota. ("support configuring host to retain more than two deployments" https://github.com/coreos/rpm-ostree/issues/577#issuecomment... )
Theoretically there's a disk space advantage to container layers.
Native Containers are bare-metal host images as OCI Images which can be stored in OCI Container Registries (or Artifact registries because packages too). GitHub, GitLab, Gitea, GCP, and AWS all host OCI Container/Artifact Registries.
From >>44401634 re bootc-image-builder and Native Containers and ublue-os/image-template, ublue-os/akmods, ublue-os/toolboxes w/ "quadlets and systemd" (and tini is already built-in to Docker and Podman) though ublue/bazzite has too many patches for a robot:
> ostree native containers are bootable host images that can also be built and signed with a SLSA provenance attestation; https://coreos.github.io/rpm-ostree/container/
SBOM tools can scan hosts, VMs, and containers to identify software versions and licenses for citation and attribution. (CC-BY-SA requires Attribution if the derivative work is distributed. AGPL applies to hosted but not necessarily distributed derivative works. There's choosealicense.com , which has a table of open source license requirements in an Appendix: https://choosealicense.com/appendix/ )
BibTeX doesn't support schema.org/SoftwareApplication or subproperties of schema:identifier for e.g. the DOI URN of the primary schema.org/ScholarlyArticle and it's :funder(s).
...
ROS on devices, ROS in development and simulation environments;
Conda-forge and RoboStack host ROS Robot Operating System as conda packages.
RoboStack/ros-noetic is ROS as conda packages: https://github.com/RoboStack/ros-noetic
gz-sim is the new version of gazebosim, a simulator for ROS development: https://github.com/conda-forge/gz-sim-feedstock
From >>44372666 :
> mujoco_menagerie has Mujoco MJCF XML models of various robots.
Mujoco ROS-compatibility: https://github.com/google-deepmind/mujoco/discussions/990
Moveit2: https://github.com/moveit/moveit2 :
> Combine Gazebo, ROS Control, and MoveIt for a powerful robotics development platform.
RoboStack has moveit2 as conda packages with clearly-indicated patches for Lin/Mac/Win: ros-noetic-moveit-ros-visualization.patch: https://github.com/RoboStack/ros-noetic/blob/main/patch/ros-...
...
Devcontainer.json has been helpful for switching between projects lately.
devcontainer.json can reference a local container/image:name or a path to a ../Dockerfile. I personally prefer to build a named image with a Makefile, though vscode Remote Containers (devcontainers extension) can build from a Dockerfile and, if the devcontainer build succeeds, start code-server in the devcontainer and restart vscode as a client of the code-server running in the container so that all of the tools for developing the software can be reproducibly installed in a container isolated from the host system.
It looks like it's bootc or bootc-image-builder for building native container images?
bootc-image-builder: https://github.com/osbuild/bootc-image-builder
Aside from the overreach, I think there are some legitimate issues with systemd:
- It's really hard to make services reliable. There are all sorts of events in systemd which will cause something to turn off and then just stay off.
- It doesn't really help that the things you tell it to do (start/stop this service) use the same memory bits as when some dependency turns something on.
- All the commands have custom, nonstandard outputs, mostly for human consumption. This makes it really hard to interface with (reliably) if you need to write tooling around systemd. Ini files are not standardized, especially systemd's.
- The two way (requires, requiredby) dependencies make the control graph really hard to get a big picture of
FWIW here's mine, where I wrote a bit more about the issues: https://github.com/andrewbaxter/puteron/
As far as a different process supervisor, I'm not sure. I've used supervisord and agree it's kind of awkward. I have heard of these but don't know much about them: