From: Paul Bender <pebender@san.rr.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev fork
Date: Thu, 13 Sep 2012 02:43:36 +0000 [thread overview]
Message-ID: <50514858.9010700@san.rr.com> (raw)
In-Reply-To: <20120912174951.GA32608@glow>
On 9/12/2012 10:49 AM, sickmind@lavabit.com wrote:
> Hi,
>
> I know that many people do not like the way udev development went
> recently, therefore we have a systemd-free fork of udev. At the moment
> most of the changes (except for systemd integration) have been ported,
> and no stability issues are noticed. I hope it will be useful for those
> who don't like systemd being pushed in their systems.
First, I believe that the overhead of maintaining a systemd+udevd
configuration that allows disabling of all systemd dependencies is
relatively trivial. Therefore, not doing so (especially when others are
submitting patches to help it along) is the height of seppuku
arrogance/laziness on the part of the systemd+udevd development team.
Having said this, as the maintainer of MiniMyth, I have found the
disjoint nature of sysvinit and udev to be cumbersome in a world of
hotplug hardware that requires starting/stopping userspace daemons or
changing userspace configuration. I (and I imagine others) have found
hotplug requires combining of init that starts/stops services and udev
that can trigger what services need to be started and stopped. In order
to solve this problem for MiniMyth some years ago, I wrote my own custom
sysvinit and udev scripts that make it work for MiniMyth. However, this
has been a kludge. If the tighter integration of init and hotplug makes
this more simple over time (and this is a big if and often change makes
things more complicated), then I believe there value.
However, for systems that do not need hotplug (of which there are many),
requiring the overhead of systemd at either build or run time is a bad idea.
This is just my opinion based on my experience. Take it or leave it.
prev parent reply other threads:[~2012-09-13 2:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 17:49 udev fork sickmind
2012-09-12 17:51 ` sickmind
2012-09-12 18:05 ` Greg KH
2012-09-12 18:09 ` sickmind
2012-09-12 18:14 ` Greg KH
2012-09-12 18:15 ` sickmind
2012-09-12 18:28 ` Greg KH
2012-09-12 18:33 ` Lucas De Marchi
2012-09-12 20:56 ` Bruce Dubbs
2012-09-12 21:19 ` Greg KH
2012-09-12 21:30 ` sickmind
2012-09-12 22:11 ` Bruce Dubbs
2012-09-12 23:44 ` Allin Cottrell
2012-09-13 0:14 ` Bruce Dubbs
2012-09-13 0:38 ` Allin Cottrell
2012-09-13 2:29 ` Bruce Dubbs
2012-09-13 2:43 ` Paul Bender [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50514858.9010700@san.rr.com \
--to=pebender@san.rr.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.