On 07/21/2010 10:42 PM, Lennart Poettering wrote: > On Wed, 21.07.10 22:13, Chuck Anderson (cra@xxxxxxx) wrote: > >> >> Well, there is some merit in the already stated argument for having >> good UI design. In this example, you could have used long-standing >> precedent of using -v -vv -vvv (or -q -qq -qqq, or --verbose=N) >> arguments instead of "status" "show" "check". Now you've created new >> lore of needing to know when to use "status" vs. "show" vs. "check", >> what the differences are between them, and what their order of >> increasing verbosity is. > > Well, I think good UI means that you distuingish computer parsable and > human readable tools. "status" is human readable. "show"/"check" are > computer-parsable. > I would recommend having 'status' maintain the same semantics as 'service foo status'. The new names aren't sufficiently more understandable to warrant breaking from long established naming scheme IMO. Generally I think maintaining similar CLI behavior with 'service' for common functionality is a good thing. Which situation is more desirable? Situation 1: Ted: "I heard systemctl is kind of replacing service..." # systemctl libvirtd status Unknown command 'libvirtd' Ted: "Huh? Oh, must need command first" # systemctl status libvirtd Could not find unit '/etc/systemd/libvirtd' Ted: "Whaa? <looks in /etc> I guess I need to specify the whole file?" # systemctl status libvirtd.service <semi-verbose output> Ted: "WTF!? I just want the status output! Do I need to parse all this? systemd/fedora sux" Situation 2: Ted: "I heard systemctl is kind of replacing service..." # systemctl libvirtd status running Ted: <content. expectations were met> <2 months later> Lennart: Hey User, try systemctl libvirtd status -v Ted: Whoa! Look at all that cool extra information! systemd/fedora rox! *air guitar* Granted, the user's conclusion in the first situation is bogus, but if someones first interaction with the new system is confusion and unnecessary readjustment of long held interface expectations, it's going to cause a lot of friction and ill will. Obviously some expectations will be invalidated, but limiting this should be a high priority IMO. Thanks, Cole -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
