4 ms·

How is that an awful UI? What should it be? It's a flexible way to get what you want. You want to automatically start the daemon on next boot, but not on instal

by vbernat 10y ago

How is that an awful UI? What should it be? It's a flexible way to get what you want. You want to automatically start the daemon on next boot, but not on install? You can do it. You want to prevent daemon restart on upgrade, you can do it. You want to whitelist some daemons, like the SSH server, you can. Ubuntu inherits this behaviour from Debian. Some people think that daemons should be started after install because the users installed the daemon to run it, some others don't. A choice has to be made. Packages where the daemon is an optional part of the functionality usually comes with either the daemon disabled (eg rsync), or with the daemon in a separate package.

regularfry 10y ago
> How is that an awful UI? Let's start with the easy stuff: how long did it take you to notice that the example in the GP's comment was wrong? Did you have to check Google, or do you have the `policy-rc.d` magic number exit codes memorised? The `policy-rc.d` mechanism moves the decision as to whether to run a daemon on installation to a really unexpected place. What should it be? Well, what I always ended up googling for was an option in the `apt` system, because that's what handles installation. I want `apt-get install foo --no-start-daemon`. I want something self-documenting I can set in `/etc/apt/preferences`, if I ever want the choice persisted. > You can do it doesn't make for a good UI. It makes for a Turing tarpit. Systems should make the common case easy; in my experience the common case is either you want a fully-working system, with everything started automatically and usable defaults in place, or you want services stopped so that you can configure them and start them later. I've never heard of anyone wanting per-service whitelisting - not to say that people don't do this, just that it's sufficiently rare in my experience that having the default optimised for that use case sucks. > A choice has to be made. I'm not arguing about the default. I'm saying that the specific mechanism you have to use to change the default behaviour shouldn't take googling to figure out.
- JdeBP 10y ago
  > What [place] should it be? Perhaps echo disable 'foo.*' >> /etc/systemd/system-preset/20-regularfry.preset as (as can be seen) some people hope one day Ubuntu will respect, per its manual? * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772555 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772555 * http://manpages.ubuntu.com/manpages/xenial/en/man5/systemd.preset.5.html http://manpages.ubuntu.com/manpages/xenial/en/man5/systemd.p... Your several cases are, respectively, the aforegiven for the administrator-chosen per-service controls, echo enable '*' >> /etc/systemd/system-preset/99-default.preset for the fully auto-starting system (unless specifically overridden) specified by the administrator, echo enable '*' >> /usr/lib/systemd/system-preset/99-default.preset for the fully auto-starting system (unless overridden by administrator or specific packaging) specified by the operating system builders, echo disable '*' >> /usr/lib/systemd/system-preset/99-default.preset for the fully disabled requiring manual start system (unless overridden by administrator or specific packaging) specified by the operating system builders, and echo disable '*' >> /etc/systemd/system-preset/00-admin.preset for the fully disabled requiring manual start system specified by the administrator.
  - regularfry 10y ago
    Perhaps, and I realise this may be a revolutionary thought, this is not somewhere systemd needs to exert itself. The `system-preset` interface is barely any better than `policy-rc.d` from the point of view of someone installing a package.
    - JdeBP 10y ago
      You'll find yourself in opposition to Major Hayden, the author of the headlined article, who wrote in May: > automatic management of running daemons shouldn’t be handled by a package manager. There's also the argument that determining whether a daemon should or should not be automatically started very much is the province of the service management subsystem, as automatic service start/stop/restart is very much what service management properly deals in.
      - regularfry 10y ago
        You're confusing interface with implementation.

by vbernat 10y ago

regularfry 10y ago

> How is that an awful UI? Let's start with the easy stuff: how long did it take you to notice that the example in the GP's comment was wrong? Did you have to check Google, or do you have the `policy-rc.d` magic number exit codes memorised? The `policy-rc.d` mechanism moves the decision as to whether to run a daemon on installation to a really unexpected place. What should it be? Well, what I always ended up googling for was an option in the `apt` system, because that's what handles installation. I want `apt-get install foo --no-start-daemon`. I want something self-documenting I can set in `/etc/apt/preferences`, if I ever want the choice persisted. > You can do it doesn't make for a good UI. It makes for a Turing tarpit. Systems should make the common case easy; in my experience the common case is either you want a fully-working system, with everything started automatically and usable defaults in place, or you want services stopped so that you can configure them and start them later. I've never heard of anyone wanting per-service whitelisting - not to say that people don't do this, just that it's sufficiently rare in my experience that having the default optimised for that use case sucks. > A choice has to be made. I'm not arguing about the default. I'm saying that the specific mechanism you have to use to change the default behaviour shouldn't take googling to figure out.

JdeBP 10y ago
> What [place] should it be? Perhaps echo disable 'foo.*' >> /etc/systemd/system-preset/20-regularfry.preset as (as can be seen) some people hope one day Ubuntu will respect, per its manual? * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772555 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772555 * http://manpages.ubuntu.com/manpages/xenial/en/man5/systemd.preset.5.html http://manpages.ubuntu.com/manpages/xenial/en/man5/systemd.p... Your several cases are, respectively, the aforegiven for the administrator-chosen per-service controls, echo enable '*' >> /etc/systemd/system-preset/99-default.preset for the fully auto-starting system (unless specifically overridden) specified by the administrator, echo enable '*' >> /usr/lib/systemd/system-preset/99-default.preset for the fully auto-starting system (unless overridden by administrator or specific packaging) specified by the operating system builders, echo disable '*' >> /usr/lib/systemd/system-preset/99-default.preset for the fully disabled requiring manual start system (unless overridden by administrator or specific packaging) specified by the operating system builders, and echo disable '*' >> /etc/systemd/system-preset/00-admin.preset for the fully disabled requiring manual start system specified by the administrator.
- regularfry 10y ago
  Perhaps, and I realise this may be a revolutionary thought, this is not somewhere systemd needs to exert itself. The `system-preset` interface is barely any better than `policy-rc.d` from the point of view of someone installing a package.
  - JdeBP 10y ago
    You'll find yourself in opposition to Major Hayden, the author of the headlined article, who wrote in May: > automatic management of running daemons shouldn’t be handled by a package manager. There's also the argument that determining whether a daemon should or should not be automatically started very much is the province of the service management subsystem, as automatic service start/stop/restart is very much what service management properly deals in.
    - regularfry 10y ago
      You're confusing interface with implementation.