InitWare has dropped from its source tree a number of components found in systemd, the project from which it was originally forked, and components added to systemd post-forking will not necessarily be imported to the InitWare project. This page will serve to summarise why these components are not present in InitWare, with advice on alternatives.

Do not think that dropping a component necessarily means less functionality! InitWare has a modular focus. Consider the example of udev: its omission is accompanied by the addition of greater flexibility - you can use InitWare with various other device managers and get similar features. And ultimately, InitWare used with udev from elsewhere (i.e. the official systemd udev) provides the exact same featureset as does systemd with its own udev. See the Myths & Truths article.

Each entry begins (in bold) with a short description of the principal reason(s) why the component was dropped, followed by a brief explanation of the function of the component, and closing with a list of possible alternatives, if relevant.

Outwith scope. This is a device node manager. The reasoning for its integration into the systemd source tree is that both it and systemd have to implement high-level functionality in C, so Kay and Lennart prefered to have just one set of that functionality.

There is no need to maintain another udev in InitWare - use another implementation. Since InitWare continue to use libudev (or a compatible implementation on other platforms) for .device units if available, no functionality is thereby lost.

Alternatives:

• eudev, mdev on GNU/Linux.
• libdevattr on DragonFly BSD.
• libudev-devd on FreeBSD.

Outwith scope. A caching DNS resolver. I have no experience in programming anything like this, and thus do not feel it right to risk users' safety by trying to maintain it.

Alternatives:

• Unbound

Outwith scope. A network configuration manager. Likely to be quite unportable to other platforms. It has very little integration of note with the systemd service manager - network-online.target is basically no change to the situation before systemd existed.

In the future, we hope to have support for proper integration with other network managers via the Delegated Restarters mechanism. For example, we might use a delegated restarter to export NetworkManager's network interfaces as units in the graph, so that e.g. one could have a service unit that depends on somenetworkinterface.network. This would be a significant improvement over what systemd with systemd-networkd offers.

Alternatives:

• NetworkManager on GNU/Linux.
• Network AutoMagic (NWAM) on Illumos, Solaris.
• NetworkMgr on FreeBSD.

Provided elsewhere. ​A libdbus alternative slightly less programmer-hostile than libdbus itself, and a D-Bus introspection tool. Although InitWare does provide an sd-bus, we recommend using another project which already maintains it as an independent package instead: Basu.

Alternatives:

• Basu, an independent version of sd-bus ​and busctl, already portable to FreeBSD

All of these are outwith scope because they are not particularly integrated with systemd anyway, are fundamentally separate concerns, and require particular expertise to write well; in the cases of some of them like cryptsetup, it would be downright socially irresponsible and ethically intolerable to try to maintain them without that expertise.

• systemd-boot, a bootloader
• cryptsetup/cryptenroll, things related to encrypted disks etc.
• timesyncd, an NTP client
• systemd-repart etc, repartitioning tools

We haven't looked in depth at these systemd components and therefore are not yet sure on what course of action to follow with them.

• machined/machinectl
• portabled
• sysext
• homed