Re: [HEADS-UP] systemd is now the default init system in rawhide

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

 



2010/7/27 Rudolf Kastl <che666@xxxxxxxxx>:
> 2010/7/27 Matt McCutchen <matt@xxxxxxxxxxxxxxxxx>:
>> On Mon, 2010-07-26 at 10:31 +0100, Bryn M. Reeves wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 07/24/2010 09:39 PM, Matt McCutchen wrote:
>>> > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote:
>>> >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote:
>>> >>>> Why is the systemd executable in /bin instead of /sbin?
>>> >>> Without looking too closely I believe systemd eventually seeks to replace
>>> >>> things like gnome-session daemon. It has session management in mind as
>>> >>> well as system.
>>> >>
>>> >> Still belongs in /sbin, unless it's meant to actually be executed directly
>>> >> by end-users.
>>> >
>>> > No.  If that were the criterion, update-mime-database would belong
>>> > in /sbin .
>>> >
>>>
>>> The FHS puts it like this:
>>>
>>> (a) "/bin contains commands that may be used by both the system
>>> administrator and by users, but which are required when no other
>>> filesystems are mounted (e.g. in single user mode). It may also contain
>>> commands which are used indirectly by scripts."
>>>
>>> (b) "/sbin contains binaries essential for booting, restoring,
>>> recovering, and/or repairing the system in addition to the binaries in
>>> /bin."
>>>
>>> So if the intent is that systemd will eventually be invoked (indirectly
>>> by some script/daemon) by users this seems justified by (a). On the
>>> other hand the page has this to say on "init":
>>>
>>> "The following files, or symbolic links to files, must be in /sbin if
>>> the corresponding subsystem is installed: ...
>>> init"
>>>
>>> It's arguable though whether this refers to SysV's init or is intended
>>> to be more general.
>>>
>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES
>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
>>
>> A hard link or symlink at /sbin/init is needed because tools look for it
>> there.  However, I think the main "systemd" executable belongs in /bin.
>> I read (b) as a subdivision of the category established by the previous
>> sentence: "Utilities used for system administration (and other root-only
>> commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin."  systemd
>> is not (going to be) root-only, hence it doesn't go in */sbin.  The
>> right comparison would be to /bin/dbus-daemon.
>>
>> --
>> Matt
>
> i do not understand how a daemon (like e.g. dbus-daemon) qualifies as
> "/bin : Essential user command binaries (for use by all users)" (taken
> from fhs 2.3).  one could argue if a daemon qualifies as "command".
> especially since it seems it has to be run before /usr is mounted it
> is never getting executed by (all) the users.
> From a usability point of view it is exactly those kinda commands i do
> not want in the user path because a user itsself should never have to
> execute it.
>
> to me it sounds more like: /sbin : System binaries. If the system
> doesent need it why do we start it that early?
>
> kind regards,
> Rudolf Kastl
>
> kind regards,
> Rudolf Kastl
>
>
>>
>> --
>> devel mailing list
>> devel@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>>
>

small addition:

if you want to move stuff to /bin how about ifconfig and ip. in this
regard our system is really a mess and instead of cleaning it up we
worked around by polluting the users PATH and completion with */sbin.
-- 
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