udev fork

udev fork

[sickmind]

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.

P.S. This maillist seems to be dead for quite a while and most of the
discussion moved to systemd-related lists, so I hope nobody would mind
if we use it as our primary maillist.

Re: udev fork

[sickmind]

On 17:49 Wed 12 Sep     , 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.
> 
> P.S. This maillist seems to be dead for quite a while and most of the
> discussion moved to systemd-related lists, so I hope nobody would mind
> if we use it as our primary maillist.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

BTW, I totally forgot to include a link to the repo. Here it is:
https://bitbucket.org/braindamaged/udev

Re: udev fork

[Greg KH]

On Wed, Sep 12, 2012 at 05:49:52PM +0000, sickmind@lavabit.com wrote:
> Hi,
> 
> I know that many people do not like the way udev development went
> recently,

What specifically are you objecting to?

> therefore we have a systemd-free fork of udev.

udev works without systemd running on the system just fine for me,
doesn't it for you?

> 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.
> 
> P.S. This maillist seems to be dead for quite a while and most of the
> discussion moved to systemd-related lists, so I hope nobody would mind
> if we use it as our primary maillist.

Who is "we"?

And note, if you are forking udev (which is fine by me, no objections),
be careful with the release numbers and naming, to keep others from
getting confused.

thanks,

greg k-h

Re: udev fork

[sickmind]

On 13:03 Wed 12 Sep     , Bruce Dubbs wrote:
> sickmind@lavabit.com wrote:
> > On 17:49 Wed 12 Sep     , 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.
> >>
> >> P.S. This maillist seems to be dead for quite a while and most of the
> >> discussion moved to systemd-related lists, so I hope nobody would mind
> >> if we use it as our primary maillist.
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> > BTW, I totally forgot to include a link to the repo. Here it is:
> > https://bitbucket.org/braindamaged/udev
> 
> A fork is way too much effort.  The only thing you need is a different 
> Makefile.  For a package that is Linux only, using autotools seems to be 
> a tremendous amount of overkill.
> 
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html
> http://anduin.linuxfromscratch.org/sources/other/udev-lfs-189.tar.bz2
> 
> Works for us.
> 
>    -- Bruce

This is not entirely true. A different makefile might be a temporary
solution, but udev is already dependent on libsystemd, and I'm afraid
this process may go much much further.

Re: udev fork

[Greg KH]

On Wed, Sep 12, 2012 at 06:09:09PM +0000, sickmind@lavabit.com wrote:
> On 13:03 Wed 12 Sep     , Bruce Dubbs wrote:
> > sickmind@lavabit.com wrote:
> > > On 17:49 Wed 12 Sep     , 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.
> > >>
> > >> P.S. This maillist seems to be dead for quite a while and most of the
> > >> discussion moved to systemd-related lists, so I hope nobody would mind
> > >> if we use it as our primary maillist.
> > >>
> > >> --
> > >> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> > >> the body of a message to majordomo@vger.kernel.org
> > >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > > BTW, I totally forgot to include a link to the repo. Here it is:
> > > https://bitbucket.org/braindamaged/udev
> > 
> > A fork is way too much effort.  The only thing you need is a different 
> > Makefile.  For a package that is Linux only, using autotools seems to be 
> > a tremendous amount of overkill.
> > 
> > http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html
> > http://anduin.linuxfromscratch.org/sources/other/udev-lfs-189.tar.bz2
> > 
> > Works for us.
> > 
> >    -- Bruce
> 
> This is not entirely true. A different makefile might be a temporary
> solution, but udev is already dependent on libsystemd, and I'm afraid
> this process may go much much further.

I don't understand, what specifically is your objection with something
that might happen in the future?  And, since it hasn't happened, how can
you object to it?

confused,

greg k-h

Re: udev fork

[sickmind]

On 11:05 Wed 12 Sep     , Greg KH wrote:
> On Wed, Sep 12, 2012 at 05:49:52PM +0000, sickmind@lavabit.com wrote:
> > Hi,
> > 
> > I know that many people do not like the way udev development went
> > recently,
> 
> What specifically are you objecting to?

Extra dependencies and L. Poettering's position that running udev
without systemd is a dead end and will not be supported in the future
(this seem to be already discussed here before).

> > therefore we have a systemd-free fork of udev.
> 
> udev works without systemd running on the system just fine for me,
> doesn't it for you?

Call me paranoid, but I'm afraid that won't last long.

> > 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.
> > 
> > P.S. This maillist seems to be dead for quite a while and most of the
> > discussion moved to systemd-related lists, so I hope nobody would mind
> > if we use it as our primary maillist.
> 
> Who is "we"?
> 
> And note, if you are forking udev (which is fine by me, no objections),
> be careful with the release numbers and naming, to keep others from
> getting confused.

Me, a bunch of other guys commiting code, and possible users.

Thanks for the advice.

Re: udev fork

[Greg KH]

On Wed, Sep 12, 2012 at 06:15:43PM +0000, sickmind@lavabit.com wrote:
> On 11:05 Wed 12 Sep     , Greg KH wrote:
> > On Wed, Sep 12, 2012 at 05:49:52PM +0000, sickmind@lavabit.com wrote:
> > > Hi,
> > > 
> > > I know that many people do not like the way udev development went
> > > recently,
> > 
> > What specifically are you objecting to?
> 
> Extra dependencies and L. Poettering's position that running udev
> without systemd is a dead end and will not be supported in the future
> (this seem to be already discussed here before).

What dependencies?  Run time?  Build time?  And why are dependencies
bad?  Do you have no ram in your system for them?

Personally, I think running a Linux system without systemd is a deadend,
but hey, what do I know about these things?  :)

> > > therefore we have a systemd-free fork of udev.
> > 
> > udev works without systemd running on the system just fine for me,
> > doesn't it for you?
> 
> Call me paranoid, but I'm afraid that won't last long.

Fear as a development motivator?  That's odd, really?

greg k-h

Re: udev fork

[Lucas De Marchi]

On Wed, Sep 12, 2012 at 3:28 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Sep 12, 2012 at 06:15:43PM +0000, sickmind@lavabit.com wrote:
>> On 11:05 Wed 12 Sep     , Greg KH wrote:
>> > On Wed, Sep 12, 2012 at 05:49:52PM +0000, sickmind@lavabit.com wrote:
>> > > Hi,
>> > >
>> > > I know that many people do not like the way udev development went
>> > > recently,
>> >
>> > What specifically are you objecting to?
>>
>> Extra dependencies and L. Poettering's position that running udev
>> without systemd is a dead end and will not be supported in the future
>> (this seem to be already discussed here before).
>
> What dependencies?  Run time?  Build time?  And why are dependencies
> bad?  Do you have no ram in your system for them?
>
> Personally, I think running a Linux system without systemd is a deadend,
> but hey, what do I know about these things?  :)
>
>> > > therefore we have a systemd-free fork of udev.
>> >
>> > udev works without systemd running on the system just fine for me,
>> > doesn't it for you?
>>
>> Call me paranoid, but I'm afraid that won't last long.
>
> Fear as a development motivator?  That's odd, really?

brain damaged?

Lucas De Marchi

Re: udev fork

[Bruce Dubbs]

Greg KH wrote:

> What dependencies?  Run time?  Build time?  And why are dependencies
> bad?  Do you have no ram in your system for them?

The configure scripts require packages that are not in LFS.  We do not 
want to add them just to satisfy a systemd build that we don't want. 
However creating a custom Makefile to build udev from the current 
systemd sources was not particularly hard.

> Personally, I think running a Linux system without systemd is a deadend,
> but hey, what do I know about these things?  :)

I understand that big distros only want to support one methodology, but 
in my opinion systemd is a solution only needed by a very small 
percentage of users.  It is quite opaque for new users trying to 
understand the boot process.  We don't use an initrd for the same reason.

The nice thing about Linux is that one size does not have to fit all.

   -- Bruce
      linuxfromscratch.org - Your distro, your rules.

Re: udev fork

[Greg KH]

On Wed, Sep 12, 2012 at 03:56:33PM -0500, Bruce Dubbs wrote:
> Greg KH wrote:
> 
> >What dependencies?  Run time?  Build time?  And why are dependencies
> >bad?  Do you have no ram in your system for them?
> 
> The configure scripts require packages that are not in LFS.

Like what?  Can't you add them?

> We do not want to add them just to satisfy a systemd build that we
> don't want. However creating a custom Makefile to build udev from the
> current systemd sources was not particularly hard.

So you don't offer systemd to any LFS user either?

> >Personally, I think running a Linux system without systemd is a deadend,
> >but hey, what do I know about these things?  :)
> 
> I understand that big distros only want to support one methodology,

No, that's not why they are switching to systemd.

> but in my opinion systemd is a solution only needed by a very small
> percentage of users.

I don't think you really understand what systemd offers.  I don't know
anyone who has used it that has wanted to switch back.  Also, it solves
numerous problems that people have been having for years.  And further,
it's becoming a requirement for large industry groups that use Linux,
because they too want what it offers.

That's not to say you don't want it, that's fine, I understand, but to
deride it by saying only a small number of users want it is
disingenuous.

> It is quite opaque for new users trying to understand the boot
> process.

The 100+ man pages are not descriptive enough? :)

> We don't use an initrd for the same reason.

That's fine, but then how do you support a separate /usr partition?  And
handle kernels built for a wide range of systems?

> The nice thing about Linux is that one size does not have to fit all.

Sure, and that's fine.  But I think you are shortchanging your users
here.  Again, just my opinion.  Best of luck,

greg k-h

Re: udev fork

[sickmind]

On 14:19 Wed 12 Sep     , Greg KH wrote:
> That's fine, but then how do you support a separate /usr partition? 

With fstab. Believe me, it still works unless you move everything to
/usr. But thats like blowing off your foot and then saying that everyone
needs a kludge from now on.

Re: udev fork

[Bruce Dubbs]

Greg KH wrote:
> On Wed, Sep 12, 2012 at 03:56:33PM -0500, Bruce Dubbs wrote:
>> Greg KH wrote:
>>
>>> What dependencies?  Run time?  Build time?  And why are dependencies
>>> bad?  Do you have no ram in your system for them?
>>
>> The configure scripts require packages that are not in LFS.
>
> Like what?  Can't you add them?

intltool, glib, gperf, gobject-introspection.

intl needs XML::Parser.  glib needs libffi and python and can use pcre, 
attr, d-bus, gamin, and gtk-doc.  gobject-introspection also needs glib 
and can use cairo and gtk-doc.  cairo needs libpng, glib, and pixman and 
can use fontconfig, gtk+, xorg libraries (and on and on).

They are all in BLFS but they are not needed for all users.  For 
instance, if you want to build a system and only want to add a web 
server, they are not needed.

>> We do not want to add them just to satisfy a systemd build that we
>> don't want. However creating a custom Makefile to build udev from the
>> current systemd sources was not particularly hard.
>
> So you don't offer systemd to any LFS user either?

We could add it to BLFS, but I think it would require us to redo all our 
boot scripts.  Users do have the systemd sources and are free to use it 
if they desire.

>>> Personally, I think running a Linux system without systemd is a deadend,
>>> but hey, what do I know about these things?  :)
>>
>> I understand that big distros only want to support one methodology,
>
> No, that's not why they are switching to systemd.
>
>> but in my opinion systemd is a solution only needed by a very small
>> percentage of users.
>
> I don't think you really understand what systemd offers.

Perhaps not, but we also have not had any requests for systemd.  I've 
been programming since 1965 and using Unix like systems since about 1988 
and have not run into the problems that systemd solves.  We all have 
different perspectives and I'm sure you have many instances where it is 
a good solution.

> I don't know
> anyone who has used it that has wanted to switch back.  Also, it solves
> numerous problems that people have been having for years.  And further,
> it's becoming a requirement for large industry groups that use Linux,
> because they too want what it offers.
>
> That's not to say you don't want it, that's fine, I understand, but to
> deride it by saying only a small number of users want it is
> disingenuous.

I didn't say that only a small number of users want it.  The vast 
majority of users don't know or care.  One major reason users want to 
build from source is because they think the major distros are bloated.

The major reason for us to even publish LFS/BLFS is to help users 
understand how things fit together.

>> It is quite opaque for new users trying to understand the boot
>> process.
>
> The 100+ man pages are not descriptive enough? :)

The fact that there are 100+ pages needed is the point.

>> We don't use an initrd for the same reason.
>
> That's fine, but then how do you support a separate /usr partition?  And
> handle kernels built for a wide range of systems?

We don't support every combination directly.  If /usr is on /dev/sda7, 
there is no problem.  Just put it in fstab.  We don't support encrypted 
partitions or other less common setups.  In our next version, we may 
merge /bin, /lib, and /sbin into /usr though.

>> The nice thing about Linux is that one size does not have to fit all.
>
> Sure, and that's fine.  But I think you are shortchanging your users
> here.  Again, just my opinion.

Our users are free to do what they think is right.  We even try to help 
when users do things outside of LFS/BLFS.  There is no shortchanging.

   -- Bruce

Re: udev fork

[Allin Cottrell]

On Wed, 12 Sep 2012, Bruce Dubbs wrote:

> Greg KH wrote:
>> On Wed, Sep 12, 2012 at 03:56:33PM -0500, Bruce Dubbs wrote:
>>> Greg KH wrote:
>>> 
>>>> What dependencies?  Run time?  Build time?  And why are dependencies
>>>> bad?  Do you have no ram in your system for them?
>>> 
>>> The configure scripts require packages that are not in LFS.
>> 
>> Like what?  Can't you add them?
>
> intltool, glib, gperf, gobject-introspection.
>
> intl needs XML::Parser.  glib needs libffi and python and can use pcre, attr, 
> d-bus, gamin, and gtk-doc.  gobject-introspection also needs glib and can use 
> cairo and gtk-doc.  cairo needs libpng, glib, and pixman and can use 
> fontconfig, gtk+, xorg libraries (and on and on).

Pkg X "can use" pkg Y (where Y is something that one might or might 
not want to install) is not an argument against requiring pkg X.

I'm one who thinks (on the basis of experience with home-rolled 
systems), that systemd really is a smarter, faster, more 
comprehensible, and more user-manageable way to get a Linux system 
up and running than sysvinit plus a big mess of shell scripts.

However, I take your point about some of the systemd dependencies, 
direct and indirect (even though systemd's configure script has a 
fair number of useful --disable-whatever options).

Why intltool, for instance? Systemd has a --disable-nls option in 
its configure script. But this is in fact just automake fraud; 
there's really no way to disable nls (and everything it brings in, 
including intltool), so far as I can tell.

--
Allin Cottrell
Department of Economics
Wake Forest University

Re: udev fork

[Bruce Dubbs]

Allin Cottrell wrote:
> On Wed, 12 Sep 2012, Bruce Dubbs wrote:
>
>> Greg KH wrote:
>>> On Wed, Sep 12, 2012 at 03:56:33PM -0500, Bruce Dubbs wrote:
>>>> Greg KH wrote:
>>>>
>>>>> What dependencies?  Run time?  Build time?  And why are dependencies
>>>>> bad?  Do you have no ram in your system for them?
>>>>
>>>> The configure scripts require packages that are not in LFS.
>>>
>>> Like what?  Can't you add them?
>>
>> intltool, glib, gperf, gobject-introspection.
>>
>> intl needs XML::Parser.  glib needs libffi and python and can use
>> pcre, attr, d-bus, gamin, and gtk-doc.  gobject-introspection also
>> needs glib and can use cairo and gtk-doc.  cairo needs libpng, glib,
>> and pixman and can use fontconfig, gtk+, xorg libraries (and on and on).
>
> Pkg X "can use" pkg Y (where Y is something that one might or might not
> want to install) is not an argument against requiring pkg X.

It is for LFS.  Every user builds every package from source.  That's the 
purpose of LFS.

> I'm one who thinks (on the basis of experience with home-rolled
> systems), that systemd really is a smarter, faster, more comprehensible,
> and more user-manageable way to get a Linux system up and running than
> sysvinit plus a big mess of shell scripts.

After dealing with LFS users for 10 years, my experience is different. 
If we were building a binary distro to distribute to users, I might 
agree with you, but we try to make things easy to understand.  The base 
LFS system has about 2000 lines of shell scripts.  Compare to about 150K 
of C code in systemd.  If a script has a problem, there are typically 
about 5 lines in a start or stop.  Plowing through all the C code is a 
lot more difficult.

> However, I take your point about some of the systemd dependencies,
> direct and indirect (even though systemd's configure script has a fair
> number of useful --disable-whatever options).

They have rejected patches that fix the problem.

> Why intltool, for instance? Systemd has a --disable-nls option in its
> configure script. But this is in fact just automake fraud; there's
> really no way to disable nls (and everything it brings in, including
> intltool), so far as I can tell.

That's why we have a hand crafted Makefile.  I don't understand why 
autotools are needed for a package that only has one target architecture.

Our Makefile (udev, gudev, keymap, and gir) is only 674 lines. 
Systemd's configure.ac is 812 lines and is a lot more difficult to 
understand if you are not an autotools wizard.

I'll also note that a complete LFS build and install for (base) udev 
takes about 10 seconds.  Boot time for a typical base LFS system is 8 
seconds.

   -- Bruce

Re: udev fork

[Allin Cottrell]

On Wed, 12 Sep 2012, Bruce Dubbs wrote:

> Allin Cottrell wrote:
>> On Wed, 12 Sep 2012, Bruce Dubbs wrote:
>> 
>>> Greg KH wrote:
>>>> On Wed, Sep 12, 2012 at 03:56:33PM -0500, Bruce Dubbs wrote:
>>>>> Greg KH wrote:
>>>>> 
>>>>>> What dependencies?  Run time?  Build time?  And why are dependencies
>>>>>> bad?  Do you have no ram in your system for them?
>>>>> 
>>>>> The configure scripts require packages that are not in LFS.
>>>> 
>>>> Like what?  Can't you add them?
>>> 
>>> intltool, glib, gperf, gobject-introspection.
>>> 
>>> intl needs XML::Parser.  glib needs libffi and python and can use
>>> pcre, attr, d-bus, gamin, and gtk-doc.  gobject-introspection also
>>> needs glib and can use cairo and gtk-doc.  cairo needs libpng, glib,
>>> and pixman and can use fontconfig, gtk+, xorg libraries (and on and on).
>> 
>> Pkg X "can use" pkg Y (where Y is something that one might or might not
>> want to install) is not an argument against requiring pkg X.
>
> It is for LFS.  Every user builds every package from source.  That's the 
> purpose of LFS.

I don't see it. "Can use" Y means it doesn't have to use Y: if 
you're building X from scratch and don't have a (pressing) use for 
whatever pkg Y provides, then say --disable-Y when configuring X (or 
maybe that's not even needed, if Y is auto-detected). Not a problem.

>> I'm one who thinks (on the basis of experience with home-rolled
>> systems), that systemd really is a smarter, faster, more comprehensible,
>> and more user-manageable way to get a Linux system up and running than
>> sysvinit plus a big mess of shell scripts.
>
> After dealing with LFS users for 10 years, my experience is different. If we 
> were building a binary distro to distribute to users, I might agree with you, 
> but we try to make things easy to understand.  The base LFS system has about 
> 2000 lines of shell scripts.  Compare to about 150K of C code in systemd.  If 
> a script has a problem, there are typically about 5 lines in a start or stop. 
> Plowing through all the C code is a lot more difficult.

OK, opinions may differ on this. But I'm not talking about making a 
distro either, just running a DIY Linux system (not strictly LFS, 
but making grateful use of LFS from time to time).

I've found that the C code of systemd "just works"; the only thing I 
have to worry about is the *.service files, which are easier to 
manage than shell scripts plus the menagerie of shell functions they 
call. I'm no more required to concern myself with systemd's C code 
that I was with sysvinit's C code.

>> However, I take your point about some of the systemd dependencies,
>> direct and indirect (even though systemd's configure script has a fair
>> number of useful --disable-whatever options).
>
> They have rejected patches that fix the problem.

That's relevant. Any specifics? Did you have a patch to really 
disable nls?

>> Why intltool, for instance? Systemd has a --disable-nls option in its
>> configure script. But this is in fact just automake fraud; there's
>> really no way to disable nls (and everything it brings in, including
>> intltool), so far as I can tell.
>
> That's why we have a hand crafted Makefile.  I don't understand 
> why autotools are needed for a package that only has one target 
> architecture.

For my part I like autoconf but consider automake the spawn of 
Satan, so I'm part-way with you on that. Makefiles that can be read 
by human beings -- and don't contain 95% irrelevant repetitive 
numbskull boilerplate -- are certainly my preference.

--
Allin Cottrell
Department of Economics
Wake Forest University

Re: udev fork

[Bruce Dubbs]

Allin Cottrell wrote:

>>> Pkg X "can use" pkg Y (where Y is something that one might or might not
>>> want to install) is not an argument against requiring pkg X.
>>
>> It is for LFS.  Every user builds every package from source.  That's
>> the purpose of LFS.
>
> I don't see it. "Can use" Y means it doesn't have to use Y: if you're
> building X from scratch and don't have a (pressing) use for whatever pkg
> Y provides, then say --disable-Y when configuring X (or maybe that's not
> even needed, if Y is auto-detected). Not a problem.

The dependency links are a problem.  Theoretically, you can build X 
without Y and then build Y and go back and rebuild X.  One or two times 
is not a big deal, but when the chain gets long, most users don't want 
to repeat the process.  As an extreme example, libreoffice takes almost 
10 hours to build on some systems.  If you leave out something, you 
don't want to do that again.

>>> I'm one who thinks (on the basis of experience with home-rolled
>>> systems), that systemd really is a smarter, faster, more comprehensible,
>>> and more user-manageable way to get a Linux system up and running than
>>> sysvinit plus a big mess of shell scripts.
>>
>> After dealing with LFS users for 10 years, my experience is different.
>> If we were building a binary distro to distribute to users, I might
>> agree with you, but we try to make things easy to understand.  The
>> base LFS system has about 2000 lines of shell scripts.  Compare to
>> about 150K of C code in systemd.  If a script has a problem, there are
>> typically about 5 lines in a start or stop. Plowing through all the C
>> code is a lot more difficult.
>
> OK, opinions may differ on this. But I'm not talking about making a
> distro either, just running a DIY Linux system (not strictly LFS, but
> making grateful use of LFS from time to time).
>
> I've found that the C code of systemd "just works"; the only thing I
> have to worry about is the *.service files, which are easier to manage
> than shell scripts plus the menagerie of shell functions they call. I'm
> no more required to concern myself with systemd's C code that I was with
> sysvinit's C code.

I can see your point, but sysv's init is only one small program.  The 
functions are all in one 800 line file of scripts (with substantial 
comments).

Everything gets installed with one 'make install', but you can look at 
any script with any text tool to see exactly what is happening.  It's 
really quite transparent.

>>> However, I take your point about some of the systemd dependencies,
>>> direct and indirect (even though systemd's configure script has a fair
>>> number of useful --disable-whatever options).
>>
>> They have rejected patches that fix the problem.
>
> That's relevant. Any specifics? Did you have a patch to really disable nls?

http://lists.freedesktop.org/archives/systemd-devel/2012-June/005407.html

   -- Bruce

Re: udev fork

[Paul Bender]

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.