Re: [HEADS-UP] systemd for F14 - the next steps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux