On Wed, Jun 17, 2015 at 11:38 AM, Avery Payne <avery.p.payne_at_gmail.com> wrote:
> On 6/16/2015 7:25 PM, Colin Booth wrote:
>>
>
> Supporting more than just Linux is important to my project, so this is of
> interest to me. What is the full name of the getty (including path)?
>
/usr/libexec/getty
This is true for at least freebsd and openbsd. I don't have any net,
dragonfly, or any of the derivatives to confirm but I'd be surprised
if they moved their getty location.
>
> Adding support for this isn't a big issue, so I somewhat disagree with your
> statement that a collection can't work vs everything must be included in a
> package. For that definition specifically, I can override the default $PATH
> that the scripts use and include /usr/libexec as needed; this is by design.
> Such a definition is stored as just another envdir setting so there really
> isn't some weird portability workaround involved. At runtime, if the
> directory or program isn't there then no harm, no foul.
>
> That being said, I do see your argument and understand that it would make
> more sense from a systems housekeeping perspective; why have every
> definition present, instead of just the ones installed?
It goes a bit deeper than that. For example, the maintenance burdon
for a project like supervision-scripts goes up exponentially as more
services are added since the maintainer needs to follow every service
that they are providing scripts for on the off chance some options get
deprecated or removed. With sysvinit on Debian, the package maintainer
for a given service was the person with the onus of making sure that
the packaged init script was correct, but it's a lot easier to
maintain the sshd init script if you're also handling packaging of
that service as well.
With systemd, assuming it wins the linux init wars completely, the
.service file can be shoved farther upstream into the service itself.
Yes the BSD package and port maintainers will need to still handle
their own rc files but the maintenance burdon goes down for the
packager because they no longer need to manage the corresponding
.service files. My theory about why systemd swept through the linux
world so fast is because it's very attractive to package maintainers
since one .service file will run everywhere (as opposed to there being
a Debian sysvinit script, a Gentoo openrc script, an archlinux rc
script, an Ubuntu upstart script, etc...). I don't have any
systemd-powered hosts right now, but I'd be highly surprised if
systemd shipped with every .service file that it supported.
If we really want to make process supervisors into first-class
citizens of the daemon management world, we need to get package
maintainers excited about run scripts in the same way that they got
excited about .service files. The goal should be to sit down at a
supervised system, install a daemon, and have it work under your
supervisor. Everything else (init replacement for example) is icing on
the cake.
Ideally there'd be a viable turn-key replacement for init, though I've
gotten a lot of mileage out of having sysvinit start s6-svscan on
production systems. Yes it's a half-way point but each system that I'm
running is significantly different at the early boot stages I don't
want to hand-craft half a dozen stage1 init and one-shot bundles due
to different hardware configurations and needs.
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Wed Jun 17 2015 - 20:47:33 UTC