On Wed, Mar 13, 2013 at 6:37 PM, Reindl Harald <h.rei...@thelounge.net> wrote: > Am 13.03.2013 17:44, schrieb Kay Sievers: >> On Wed, Mar 13, 2013 at 5:30 PM, Kok, Auke-jan H >> <auke-jan.h....@intel.com> wrote: >>> On Wednesday, March 13, 2013, Kay Sievers <k...@vrfy.org> wrote: >>>> On Wed, Mar 13, 2013 at 3:17 PM, Reindl Harald <h.rei...@thelounge.net> >>>> wrote: >>>> >>>>> so and what are you guys saying if i explain you that >>>>> i WANT THIS MESSAGES bedcause I WANT to SEE >>>>> /dev/sda2: clean, 435608/1310720 files >>>> >>>> Now, that you ask, I would say: I don't care. :) >> >>> This is one of those cases where more information isn't actually providing >>> you with useful data. We should print out errors and warnings, but if >>> everything is working as it should, then nobody should care, and it should >>> remain silent. >>> >>> If you do care, then the right solution is to implement some notification >>> mechanism that can be added or is optional, and disabled by default. >>> >>> I'd rather spend my time figuring out how to get fsck issues all the way to >>> admin users instead... That seems much more useful. >> >> Right, as always, it is about sane defaults, and "clean" isn't any >> sane default to print, ever. >> >> If wanted, tools can support --verbose and print all their stuff, but >> there is no case to clutter the console with nonsense like "clean". We >> don't print "OK" for all other tools as well > > so all the green OK messages at boot are existing only in my brain > hint: disable rhgb and quiet
Yo confuse explicit, nicely and carefully layouted status output message, which can be configured and which behave, with random nonsense printed from *used* tools, which are not service entities, and nobody wants to hear from them when all is fine. The analogy is that bash always prints OK, when it's back and all went well, not when a managed service starts Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
