Re: nosh per-user service management
I understand your point. But it is not practical, as it requires users
to become system administrators, which makes no sense. I am not
speaking of access rights in the operating system, but of the
knowledge and experience that is required by user to set such a
service.
While it may be easy for you and for me too, it is certainly not easy
matter for users. That is why they are called "users", not
administrators.
That is why, for users, we have /etc/skel, to give them files and
settings, how we, system administrators, think they shall be setup.
All my staff members are using GNU Emacs, but they certainly don't
know and will not think of command line options, they are interested
in editing only. So, setting a daemon, is not an option for any of
users I have. The practicality becomes impossible.
The option for users to set the supervised daemon services is always
there, they can install userbase daemontools or similar. If they know
how. So great majority do not know how. That is why they need help of
system administrators.
Jean
On Sun, Dec 11, 2016 at 06:18:13PM +0000, Jonathan de Boyne Pollard wrote:
> Jean Louis:
>
> > So, placing user daemons into system supervision may not be the best
> > option, due to so many customization that have to be done for the user,
> > especially for GNU Emacs -- as one cannot know which programming
> > languages and their variables are required.
> >
>
> I just explained that these are *not* system-wide services, but per-user
> ones. A user who is setting up environment variables for xyr own needs to
> run emacs as a service simply sets up environment variables for xyr own
> needs against the per-user service. Indeed, I already showed how that is
> done. Once again:
>
> > Adjust its environment, if desired, in the conventional way
> >
> > $ system-control --user set-service-env emacs DISPLAY :15.2
> >
> > or (if /usr/local/sbin is on one's path)
> >
> > $ rcctl set --user emacs DISPLAY :15.2
>
> The idea that this is somehow difficult because one might have to set an
> environment variable named GUILE_LOAD_PATH in this way, is just plain wrong.
> This is just an envdir in a conventional place in a service directory. It's
> actually easier to manipulate than a $HOME/.{z,}profile or a
> $HOME/.login_conf for setting such an environment variable so that one could
> spawn the daemon in an interactive login session.
Received on Mon Dec 12 2016 - 09:56:17 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC