I'm developing a somewhat similar system[1], based purely on very easy to develop plugins, agentless, and integration with third parties where needed (Prometheus, for example).But without big corporate backup it is being difficult to keep the development pace.
Cockpit deals with dbus, and systemd is conveniently available there (hostnamectl, etc). storaged, networkmanager, and other functionality is not dependent on systemd, so it's really just the system journal, changing the hostname, and checking service status which would fail without systemd.
Docker is not required at all either, though it's an option.
* http://cockpit-project.org/guide/latest/feature-systemd.html
It should of course be obvious that Cockpit does explicitly deal with systemd. Desktop Bus is a transport layer, and the important thing about it is what DBus servers are on the other side of the broker are being talked to. In the case of Cockpit they are things like systemd's own idiosyncratic API for process #1 ...
* https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...
... systemd's hostnamed server ...
* https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...
* https://www.freedesktop.org/wiki/Software/systemd/hostnamed/
... and systemd's timedated server.
* https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a...
* https://www.freedesktop.org/wiki/Software/systemd/timedated/
Cockpit also hardwires use of systemd's journalctl program.
* http://cockpit-project.org/guide/latest/feature-journal.html
* https://github.com/cockpit-project/cockpit/blob/0dd4ee7bac14...
But it uses these because they are readily available over dbus. Not because cockpit has a hard dependency on systemd.
While that functionality wouldn't work, it would be really trivial to write your own using cockpit.spawn() to call `date`... or `hostname ...` instead of hostnamed or timedated. The truth is that hostnamed and timedated are simply better than the CLI tools.
However, I'm sure the Cockpit team would welcome a patch.
More to the point, there is absolutely nothing in Cockpit which is explicitly using systemd APIs outside of dbus, and this would not be hard to work around.
I know it's cool on HN to hate on systemd, but this is dumb. Cockpit already uses bare `hostname`: https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a...
It would be a 20 line patch to break the systemd "dependency" on hostnamed. This is not a project intrinsically linked to systemd.
Even your hardwired "example" of journalctl is literally calling a process, which could just as easily be "cat /var/log/messages". It's 'hardwired' because systemd is the standard these days, whether you like it or not. However, extending the promise to simply do that if journalctl fails is trivial.
Maybe your idea of 'hard' dependencies and mine are very different. To me, a 'dependency' on, say, Python, means that there are Python calls all over the place which a reliance on specific semantics. That means that stubbing it out for Ruby or Lua or whatever would be hard. It is not "we wrote our application with this in mind, but we could patch it into stubbable modules in 3 minutes".
Again, no hate for systemd here, I was just pointing out what I had read in the documentation and making it known. FYI my laptop runs Elementary OS which fully depends on systemd and I have no issues with that situation, nor do I "hate" it. If I did I would run a different OS on it. systemd is part of Linux for the majority of distros, it's likely here to stay, and these days it's stable enough for daily use.