Default services enabled

[Reindl Harald]

Am 19.08.2011 18:46, schrieb Lennart Poettering:
> On Fri, 19.08.11 18:00, Reindl Harald (h.reindl at thelounge.net) wrote:
>
> Heya,
>
>> * no feedback of systemctl and wrong from /sbin/service-wrapper
> Like most Unix commands systemctl will not output anything in case of
> success, only on failure. See cp, ln, mv, rm for similar behaviour.

if you are replacing /sbin/service which gave feedback over all the
years you have to give feedback too and not make the same crap like
apple

and NO it does also not give feedback if service fails

>> * systemctl does not stop .socket if you stop .service
> And it shouldn't. There's an item on the todo list to add a warning if
> the user stops a service unit but leaves the socket unit running.

it should

if you say it shouldn't you have a hughe design-mistake in the whole
software - if i say "service stop anythign" i mean stop and not
that any dumkb software fires it up

if you can give a warning you can also stop the socket
this is what the user expects and if your software-design
is not able to act logically it is broken

>> * useless auto-completion for systemctl
> Hmm? Bug#?

"service restart htt"

you can type TAb the whole day and will get no auto-completion
if the service is running - shos me you are not really using your
own software and i did not think a bugreport for such basics
is needed

>> * no progress while fs-check on boot
> The way I'd like to see this fixed is that fsck's -C switch can
> optionally take a path like /dev/console to output its progress
> bar. Then again, ideally the progress information would be passed on to
> Plymouth instead of the console. In both cases systemd should probably
> not be involved.
sorry to say but: it does nobody interest what you like
a fs-check on a 4 TB disk without any feedback is unnaccpetable
because inak KVM-Session you see not disk-LED's and do not hear the
drive - so with your behavior in the worst case somebody forces
a hard restart while fsck is running
>> D* no green Ok / red FAILED at boot time, only a desert of text
> Not really true.
>
> First of all, we will output "Starting ..." and "Started ..." messages
> as the boot proceeds if you remvoe "quiet" from the kernel cmdline. If a
> service fails, we will even say that and highlight it in red. What we
> won't do however is mark success in green, in order to keep visual
> distraction minimal.
i first disable the dumb quite-option on every install

i recommend you take a look at a F14 boot and yours
it is a hughe differene having a red colored FAILED or your text-desert with
no difference and the output of the service-description instead a short name
is simply a design-mistake

> On top of that, at any time you can type in "systemctl" and you'll get
> colorful output of what services successfully started and which ones
> didn't. This is a substantial improvement over classic SysV where the
> boot time output scrolled away quickly and only screen-scraping could
> help to get a bit of an idea what actually started properly and what
> didn't.
yes it is a improvent to get htis after the boot but if you restart a server
you nromally watch the boot and have no reason to login as long you see
nothing red - this was broken by the usability-pifall how systemd boots

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110820/ae5ad902/attachment.bin