The cockpit based server-manager is really nice and a big step forward.
It is responsive and I love the modern looks;
Big thumps up and looking forward to its release. 
(Do not forget the above while reading the next.)
I love graphs but they need to be meaningful and accurate.
- IMO the dashboard-cpu graph is not accurate, it represents the single-thread load. On a multicore system , let’s say 4 cores, the y-axis should show 400% (or the value divided by 4). And this does not even take the scaling-governor (actual clock speed) in to account. To reproduce install stress and pound one core for a while (stress -c 1 --timeout 30s) and observe the cpu graph going to 100%.
- The memory graph is not meaningful, it seems to represent used memory+buffers+cache and do not see the point to have an live stream graph of this value. Goodness is in the pipeline from the cockpit project
here and here . Still, would a streaming representation of memory IO per second be more useful? - The auto-scaling y-axis of {Disk, Network}-IO/s make those graphs hard to interpret. I have to admit to be unable to give a better suggestion.
Cockpit has some dependencies which are not really needed, specific for my raid-less test-system mdadm, but also NetworkManager and Udisks. To my understanding the latter two for their dbus capabilities. Despite the demonstration of shear possibilities of dbus with the streaming graphs; are my feelings regarding dbus as the ideal IPC for a server at least ambiguous.
Therefor very happy to see the nethserver-api implementation which does not heavily rely on the dbus. I’m curious about the thoughts/background to break with the upstream cockpit-philosophy on this topic.
Again I really like this
(and it work’s on arm too 
)