Discussion:
udev fork
s***@lavabit.com
2012-09-12 17:49:52 UTC
Permalink
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s***@lavabit.com
2012-09-12 17:51:33 UTC
Permalink
Post by s***@lavabit.com
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
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

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s***@lavabit.com
2012-09-12 18:09:09 UTC
Permalink
Post by s***@lavabit.com
Post by s***@lavabit.com
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.


--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Greg KH
2012-09-12 18:14:09 UTC
Permalink
Post by s***@lavabit.com
Post by s***@lavabit.com
Post by s***@lavabit.com
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Greg KH
2012-09-12 18:05:02 UTC
Permalink
Post by s***@lavabit.com
Hi,
I know that many people do not like the way udev development went
recently,
What specifically are you objecting to?
Post by s***@lavabit.com
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?
Post by s***@lavabit.com
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s***@lavabit.com
2012-09-12 18:15:43 UTC
Permalink
Post by Greg KH
Post by s***@lavabit.com
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).
Post by Greg KH
Post by s***@lavabit.com
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.
Post by Greg KH
Post by s***@lavabit.com
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.


--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Greg KH
2012-09-12 18:28:21 UTC
Permalink
Post by s***@lavabit.com
Post by Greg KH
Post by s***@lavabit.com
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? :)
Post by s***@lavabit.com
Post by Greg KH
Post by s***@lavabit.com
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Lucas De Marchi
2012-09-12 18:33:23 UTC
Permalink
Post by Greg KH
Post by s***@lavabit.com
Post by Greg KH
Post by s***@lavabit.com
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? :)
Post by s***@lavabit.com
Post by Greg KH
Post by s***@lavabit.com
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bruce Dubbs
2012-09-12 20:56:33 UTC
Permalink
Post by Greg KH
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.
Post by Greg KH
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Greg KH
2012-09-12 21:19:04 UTC
Permalink
Post by Bruce Dubbs
Post by Greg KH
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?
Post by Bruce Dubbs
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?
Post by Bruce Dubbs
Post by Greg KH
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.
Post by Bruce Dubbs
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.
Post by Bruce Dubbs
It is quite opaque for new users trying to understand the boot
process.
The 100+ man pages are not descriptive enough? :)
Post by Bruce Dubbs
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?
Post by Bruce Dubbs
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s***@lavabit.com
2012-09-12 21:30:23 UTC
Permalink
Post by Greg KH
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.

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bruce Dubbs
2012-09-12 22:11:46 UTC
Permalink
Post by Greg KH
Post by Bruce Dubbs
Post by Greg KH
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.
Post by Greg KH
Post by Bruce Dubbs
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.
Post by Greg KH
Post by Bruce Dubbs
Post by Greg KH
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.
Post by Bruce Dubbs
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.
Post by Greg KH
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.
Post by Greg KH
Post by Bruce Dubbs
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.
Post by Greg KH
Post by Bruce Dubbs
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.
Post by Greg KH
Post by Bruce Dubbs
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Allin Cottrell
2012-09-12 23:44:35 UTC
Permalink
Post by Bruce Dubbs
Post by Greg KH
Post by Bruce Dubbs
Post by Greg KH
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



--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bruce Dubbs
2012-09-13 00:14:22 UTC
Permalink
Post by Bruce Dubbs
Post by Greg KH
Post by Bruce Dubbs
Post by Greg KH
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


--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Allin Cottrell
2012-09-13 00:38:45 UTC
Permalink
Post by Bruce Dubbs
Post by Bruce Dubbs
Post by Greg KH
Post by Bruce Dubbs
Post by Greg KH
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.
Post by Bruce Dubbs
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.
Post by Bruce Dubbs
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?
Post by Bruce Dubbs
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bruce Dubbs
2012-09-13 02:29:05 UTC
Permalink
Post by Bruce Dubbs
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.
Post by Bruce Dubbs
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.
Post by Bruce Dubbs
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Bender
2012-09-13 02:43:36 UTC
Permalink
Post by s***@lavabit.com
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.



--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...