*   CPU usage
    *   storage IOPS
    *   `/dev/shm` size limit
    *   terminal/logging bps
    *   [capability][caps] restrictions
    *   [seccomp profiles](https://docs.docker.com/engine/security/seccomp/)
    *   [rlimit]
*   [limited hardware pass-thru](#hw)
*   [full hardware pass-thru](#hw)

Lack of a management daemon(^`containerd` in modern setups, `dockerd` in old ones) is not in that list because a good bit of Docker’s competition also lacks this, on purpose. Between that and the other items on the list, the fairest comparison is not to fully-featured container *engines* like Docker and Podman but to the container *runner* at their heart:

* **runc**: 14 MiB(^This is the runner underpinning `containerd`, thus also Docker, although it precedes it. Long before they created `containerd`, it underpinned `dockerd` instead. Because it is so primordial, a good many other container engines are also based on it.)
* **systemd-nspawn**: 1.3 MiB(^[This][sdnsp] is the bare-bones [OCI] image runner built into systemd, with a feature set fairly close to that of `container.npk`. The size above is for version 252 of this program’s parent [`systemd-container`][sdcnt] package as shipped on EL9.)
* **crun**: 0.5 MiB(^This is Podman’s alternative to `runc`, written in C to make it smaller. Early versions of Podman once relied on `runc`, and it can still be configured to use it, but the new default is to use the slimmer but feature-equivalent `crun`.)

In theory, this should result in zero change since it’s converting to the same output format as the input, but more than once I’ve seen it fix up some detail that RouterOS’s container image loader can’t cope with on its own.

Note, incidentally, that we don’t use Skopeo’s `oci-archive` format specifier. I don’t know why, but I’ve had less success with that.

[Skopeo]: https://github.com/containers/skopeo


# <a id="hw"></a>Hardware Pass-Thru
# <a id="hw"></a>Partial Support for Hardware Pass-Thru

Prior to RouterOS 7.20, the only support for hardware in containers was indirect. Examples:

*   Mounts allow access to USB storage, provided it’s formatted in a way that `/files` can see.
*   A third-party NIC might have a driver in the shipping RouterOS kernel, which would let you route traffic to the container via that NIC.

This release added the `/system/hardware` menu. If present, it lists devices you can map in via the `device` option when creating a container, typically generic USB peripherals, and then only when the shipped kernel includes a driver for it. If your router does not have this menu but it’s running RouterOS 7.20beta2 or higher, it means there are no supported devices available for use by this feature.