Re: Why do we use systemd

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

 



On 09/07/14 05:35 AM, users-request@xxxxxxxxxxxxxxxxxxxxxxx wrote:
On  7 Date: Wed, 09 Jul 2014 00:36:37 -0700 From: Joe Zeff
On 07/08/2014 11:40 PM, lee wrote:
>When something is disguised or hidden, it is not disabled.  It is
>camouflaged or concealed.  Camouflage, concealment, hiding, disguise and
>masking can all be used for*preventing*  from being disabled.
No.  When a service is disabled it can still be started after boot, but
when it's masked, it can't be started at all.

Do understand that I'm defending neither systemd nor the deveolper's
choice of terminology.  I'm merely correcting what looks like a
misstatement of how it works.

Yes! And how it *works* is not what that term, used normally describes. Which is the point being made.
'Disabled' should imply 'NEVER'
'Masked' is not a word which should be used in this context.

Selinux got the terms correct, IMHO there is NO reason why systemd should not use the same terms:

ENABLED  means ALWAYS
PERMISSIVE  means SOMETIMES
DISABLED means NEVER

These are the start-up default states and should have no effect on using start or stop directly. Systemd however mis-manages this as well, so that you cannot start a 'masked' service

So 'masked' is actually NEVER NOT EVEN WHEN YOU WANT IT. and DISABLED means SOMETIMES, but there is no way to set a state where the computer cannot under any circumstances but you can MANUALLY.*

This thread contains numerous instances of why systemd is not well architected, although what it does do, it seems to do well. What it tries to do seems to be a 'reach which exceeds its grasp'. And to boot, the documentation, although extensive is far too abstract and blatherfull to be actually useful.

Geoff

*I mean that I should not have to 'unmask', 'start' and 'mask' the service to achieve an 'only-when-*I*-want-it' start-up of a service. Setting 'disabled' means that the system can start it whenever it feels the need.


			

--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux