Mailing List Archive

On Sun, Mar 2, 2014 at 10:57 AM, Mark Knecht <markknecht@gmail.com> wrote:
> Hi all,
> I'd like to check in and get some education concerning future
> configuration of my Gentoo machines. Thanks in advance.
>
> In the last few days there is a news announcement about needing to
> change kernel my configuration to enable CONFIG_FHANDLE to support
> udev-210. I'm currently at udev-208 and virtual/udev-208-r1 so no big
> deal yet. However reading the news announcement it appears this has
> more to do with systemd than anything else and I don't use systemd so
> does/will this effect my machines?

Yes, it will; udev (independently of systemd) is using FHANDLE to find
the devices in the computer.

udev is part of systemd, but it can be used separately. This is
supported by upstream (i.e., systemd). The change in the kernel config
is needed by udev.

> NOTE: I have no problem I know about today enabling CONFIG_FHANDLE
> if it's recommended.

It is: udev will not work without it. Even more: eudev (when they
catch up) will not work without it either, since eudev does no
original work; they just exorcise systemd from udev.

> That said there's an interesting (if it is to be believed) little
> rant thread over the last couple of days on LKML about Debian
> leadership forcing people into systemd.

The Debian Technical Committee took the technical decision of using
systemd as default init system. There is no "forcing" here; Debian is
ruled by a Constitution, and they (very slowly) followed their rules
and laws to reach that decision.

> I think the Gentoo devs forked
> udev to make either mdev or eudev but when it was announced it was too
> new for me so I just let it go by.

Gentoo, by default, uses udev without systemd. Again, this is
supported by upstream (i.e., systemd), nothing special about it.
*Some* Gentoo developers "forked" systemd into eudev, so you can have
a "udev without systemd" (although, as stated above, upstream supports
udev without systemd). I don't know the exact numbers, but it's my
impression (by reading -dev and -user), that eudev is used in Gentoo
(and only Gentoo) by a handful of people. The great majority is using
sys-fs/udev, and I'm willing to bet that more people are using systemd
directly than eudev.

> Maybe now it's time for me to look
> into making a change of some type? I see eudev in portage, but not
> mdev.

Using eudev will gain you nothing; the FHANDLE change will reach them
eventually. If you use mdev, you will have a noticeable loss of
functionality. I think even less people use mdev than eudev.

> A (really, really, really) quick scan of the current install docs
> makes me think sysvinit/OpenRC/udev is still the default for new
> installs. Is this true?

Yes, it's true, and no one will propose changing this, at least in the
near future. And even if systemd becomes the standard Gentoo init
system, OpenRC will be (almost surely) supported until the end of
times.

> If so why is this kernel change being
> required?

Because is new functionality provided by the kernel required by
*udev*, not (necessarily) systemd. Happens all the time; new
technology in the kernel is pretty useless if userspace doesn't start
taking advantage of it.

> Also, I seem to have virtual/udev installed which says it's about
> enabling switching between udev & eudev. However there are no files
> associated with virtual/udev. (equery files virtual/udev returns
> nothing)

That's why it's a virtual; a virtual pulls in different
implementations of the (in theory) same functionality.

> It appears I cannot install eudev without removing udev so
> this seems a big step to take:
[ snip]

It is a big step to take, and it will gain you nothing: eventually,
eudev *will* require FHANDLE, unless they diverge even more from
upstream, a thing I believe they cannot afford to do.

> At this point I'm not even sure what my other questions might be as
> I'm just trying to get my head around what others are using these
> days.

Well, it's undeniable that systemd usage is on the raising everywhere,
including Gentoo (specially since GNOME pulls it in). I myself use
systemd, and could not be happier.

However, OpenRC is (and will be for the foreseeable future) the
default init system.

> I do have a second Gentoo install on this system on an SSD so
> (once updated) I could do a switch there as a test.

My suggestion is for you to enable FHANDLE. From the kernel:

"""
config FHANDLE
bool "open by fhandle syscalls"
select EXPORTFS
help
If you say Y here, a user level program will be able to map
file names to handle and then later use the handle for
different file system operations. This is useful in implementing
userspace file servers, which now track files using handles instead
of names. The handle would remain the same even if file names
get renamed. Enables open_by_handle_at(2) and name_to_handle_at(2)
syscalls.
"""

It enables a couple of syscalls, and I don't think it will increase
much your kernel size. All systemd forks (including eudev) will need
it at some point, since it makes things easier for the developers. You
*could* use mdev instead of udev, but is **NOT** a drop in
replacement: you *will* lose some (if not much) functionality.

So just enable the thing and go on with your life.

My 0.02 ${CURRENCY}.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Sun, Mar 2, 2014 at 11:57 AM, Mark Knecht <markknecht@gmail.com> wrote:
> In the last few days there is a news announcement about needing to
> change kernel my configuration to enable CONFIG_FHANDLE to support
> udev-210. I'm currently at udev-208 and virtual/udev-208-r1 so no big
> deal yet. However reading the news announcement it appears this has
> more to do with systemd than anything else and I don't use systemd so
> does/will this effect my machines?

I'm going to avoid repeating Canek's points, which are basically
correct on the factual matters.

However, I will clarify a little about why you probably think the news
has something to do with systemd.

The big change in udev-210 is how persistent network device names are
implemented. The file that implements the rules is changing names,
which has an impact on your if you're trying to override it (your
override will no longer work if you don't change the name to follow
suit). Also, the new rule file now pulls in config settings from a
file that contains "systemd" in the filename. If you want to tweak
the persistent naming without disabling it entirely, it would make
sense to try to do so by editing that file, regardless of whether
you're using systemd. The file contains systemd in the name because
it is also used by systemd for network settings. So, you have udev (a
binary) loading a rule file (text) which loads a config file (text).
This is analogous to openrc running an init script which sources a
config file - editing the config file is preferable to editing the
script but nothing prevents you from doing either.

> I think the Gentoo devs forked udev to make either mdev or eudev
> but when it was announced it was too new for me so I just let it go
> by. Maybe now it's time for me to look into making a change of some
> type? I see eudev in portage, but not mdev.

Ok, just some definitions:
udev - the upstream project that you're familiar with - it has
recently merged with systemd, which has resulted in some changes that
some find objectionable (changes in install paths, incorporation of
systemd in file/path names, etc)

eudev - a fork of udev that attempts to basically do the same thing as
udev, but preserving the paths/etc used in the project prior to the
systemd merge.

mdev - shorthand for busybox mdev. This isn't a separate package. If
you have busybox installed you can use a function it supports which
will populate /dev based on detected devices, in a manner similar to
udev. It is much less functional that udev, but if you have a simple
system where you don't need hot-swap support and all the bells and
whistles, it will give you a /dev similar to what you probably would
find on most linux boxes 10 years ago.

> A (really, really, really) quick scan of the current install docs
> makes me think sysvinit/OpenRC/udev is still the default for new
> installs. Is this true? If so why is this kernel change being
> required?

Udev is changing upstream - presumably because the new kernel features
are helpful in some way. I haven't read the details.

> Also, I seem to have virtual/udev installed which says it's about
> enabling switching between udev & eudev. However there are no files
> associated with virtual/udev. (equery files virtual/udev returns
> nothing) It appears I cannot install eudev without removing udev so
> this seems a big step to take:

virtual/udev is a virtual package. Virtual packages are called
virtual because they don't install files. They exist for dependency
purposes - a package can depend on the virtual which lets you pick
whether you want to use udev or eudev or something else without lots
of things breaking.

Eudev is a fork of udev and cannot co-exist with it. It would be like
installing mariadb and mysql on the same system, or openoffice and
libreoffice. So, if you want to install it portage will helpfully
suggest uninstalling udev.

I won't tell you what you should be doing, but before you switch from
the defaults (openrc+udev+sysvinit) you should probably make sure you
understand what you're getting into. The upstream udev is certainly
what 99% of Linux users will be using in general for the foreseeable
future, though I can't really see you getting into trouble with eudev
or mdev (with many limitations on the latter). Migrating between them
isn't very hard at the moment, though if config files/etc start
diverging between eudev and udev that will make it harder to switch
(depending on how much you tweak on your system).

Rich

Hi Canek - good to hear from you.

On Sun, Mar 2, 2014 at 9:45 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sun, Mar 2, 2014 at 10:57 AM, Mark Knecht <markknecht@gmail.com> wrote:
>> Hi all,
>> I'd like to check in and get some education concerning future
>> configuration of my Gentoo machines. Thanks in advance.
>>
>> In the last few days there is a news announcement about needing to
>> change kernel my configuration to enable CONFIG_FHANDLE to support
>> udev-210. I'm currently at udev-208 and virtual/udev-208-r1 so no big
>> deal yet. However reading the news announcement it appears this has
>> more to do with systemd than anything else and I don't use systemd so
>> does/will this effect my machines?
>
> Yes, it will; udev (independently of systemd) is using FHANDLE to find
> the devices in the computer.
>
> udev is part of systemd, but it can be used separately. This is
> supported by upstream (i.e., systemd). The change in the kernel config
> is needed by udev.
>

So as an end user type I'm a little confused by this part of your
response. When you say udev is 'part of systemd' do you mean at the
project level? That's what I understand from your longer response
below.

>> NOTE: I have no problem I know about today enabling CONFIG_FHANDLE
>> if it's recommended.
>
> It is: udev will not work without it. Even more: eudev (when they
> catch up) will not work without it either, since eudev does no
> original work; they just exorcise systemd from udev.
>

Good to know and I've already read a little more about it and enabled
it in my kernel.

>> That said there's an interesting (if it is to be believed) little
>> rant thread over the last couple of days on LKML about Debian
>> leadership forcing people into systemd.
>
> The Debian Technical Committee took the technical decision of using
> systemd as default init system. There is no "forcing" here; Debian is
> ruled by a Constitution, and they (very slowly) followed their rules
> and laws to reach that decision.
>
>> I think the Gentoo devs forked
>> udev to make either mdev or eudev but when it was announced it was too
>> new for me so I just let it go by.
>
> Gentoo, by default, uses udev without systemd. Again, this is
> supported by upstream (i.e., systemd), nothing special about it.
> *Some* Gentoo developers "forked" systemd into eudev, so you can have
> a "udev without systemd" (although, as stated above, upstream supports
> udev without systemd). I don't know the exact numbers, but it's my
> impression (by reading -dev and -user), that eudev is used in Gentoo
> (and only Gentoo) by a handful of people. The great majority is using
> sys-fs/udev, and I'm willing to bet that more people are using systemd
> directly than eudev.
>
>> Maybe now it's time for me to look
>> into making a change of some type? I see eudev in portage, but not
>> mdev.
>
> Using eudev will gain you nothing; the FHANDLE change will reach them
> eventually. If you use mdev, you will have a noticeable loss of
> functionality. I think even less people use mdev than eudev.
>
>> A (really, really, really) quick scan of the current install docs
>> makes me think sysvinit/OpenRC/udev is still the default for new
>> installs. Is this true?
>
> Yes, it's true, and no one will propose changing this, at least in the
> near future. And even if systemd becomes the standard Gentoo init
> system, OpenRC will be (almost surely) supported until the end of
> times.
>
>> If so why is this kernel change being
>> required?
>
> Because is new functionality provided by the kernel required by
> *udev*, not (necessarily) systemd. Happens all the time; new
> technology in the kernel is pretty useless if userspace doesn't start
> taking advantage of it.
>

Understood.

>> Also, I seem to have virtual/udev installed which says it's about
>> enabling switching between udev & eudev. However there are no files
>> associated with virtual/udev. (equery files virtual/udev returns
>> nothing)
>
> That's why it's a virtual; a virtual pulls in different
> implementations of the (in theory) same functionality.
>
>> It appears I cannot install eudev without removing udev so
>> this seems a big step to take:
> [ snip]
>
> It is a big step to take, and it will gain you nothing: eventually,
> eudev *will* require FHANDLE, unless they diverge even more from
> upstream, a thing I believe they cannot afford to do.
>
>> At this point I'm not even sure what my other questions might be as
>> I'm just trying to get my head around what others are using these
>> days.
>
> Well, it's undeniable that systemd usage is on the raising everywhere,
> including Gentoo (specially since GNOME pulls it in). I myself use
> systemd, and could not be happier.
>
> However, OpenRC is (and will be for the foreseeable future) the
> default init system.

Humm. OK, so I've updated my main spinning rust kernel for FHANDLE. No
problems there. sysvinit/OpenRC/udev. All good.

As I write this I'm in my SSD backup Gentoo install. I haven't used it
in awhile so I'm emerging 668 packages. System setup as above but
maybe I'll consider switching this one to systemd just as a trial. At
this time it's not important on my personal machines. However my 86
year old father is the last Gnome holdout in the family. I've not
updated his box in quite awhile (cognitive issues, fewer GUI changes
are better for him) However if I do update then it will likely be
Gnome so having at least a little experience with systemd might be
good.


>> I do have a second Gentoo install on this system on an SSD so
>> (once updated) I could do a switch there as a test.
>
> My suggestion is for you to enable FHANDLE. From the kernel:
>
<SNIP>

Done, no noticeable impact after 20 minutes. All good.

>
> So just enable the thing and go on with your life.
>
> My 0.02 ${CURRENCY}.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

Again, THANKS for a wonderful response with lots of good information.
We're lucky to have you as one of the long-time Gentoo guys. I for one
greatly appreciate what little I understand. :-)

Cheers,
Mark

Thanks Rich. The picture is getting clearer and other than getting my
backup SSD installation up to date it's good to know there's no
difficult requirements for me to deal with at this time. Being that I
have been (for the last 5-6 years anyway) a 'stable' Gentoo user it's
to my advantage if things stay basically the same over time.

After your and Canek's responses it's clear that within my framework I
won't be moving to eudev or mdev. The only systemd question I might
need to answer going forward is for my dad's machine. He's got 15
years of email traffic in Evolution and I've not investigated running
Evolution in any desktop environment other than Gnome. There's no way
at this point to move him away from Evolution so I just need to figure
out over time (the next year maybe) how to best deal with that.

Cheers,
Mark

On Sun, Mar 2, 2014 at 10:10 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Mar 2, 2014 at 11:57 AM, Mark Knecht <markknecht@gmail.com> wrote:
>> In the last few days there is a news announcement about needing to
>> change kernel my configuration to enable CONFIG_FHANDLE to support
>> udev-210. I'm currently at udev-208 and virtual/udev-208-r1 so no big
>> deal yet. However reading the news announcement it appears this has
>> more to do with systemd than anything else and I don't use systemd so
>> does/will this effect my machines?
>
> I'm going to avoid repeating Canek's points, which are basically
> correct on the factual matters.
>
> However, I will clarify a little about why you probably think the news
> has something to do with systemd.
>
> The big change in udev-210 is how persistent network device names are
> implemented. The file that implements the rules is changing names,
> which has an impact on your if you're trying to override it (your
> override will no longer work if you don't change the name to follow
> suit). Also, the new rule file now pulls in config settings from a
> file that contains "systemd" in the filename. If you want to tweak
> the persistent naming without disabling it entirely, it would make
> sense to try to do so by editing that file, regardless of whether
> you're using systemd. The file contains systemd in the name because
> it is also used by systemd for network settings. So, you have udev (a
> binary) loading a rule file (text) which loads a config file (text).
> This is analogous to openrc running an init script which sources a
> config file - editing the config file is preferable to editing the
> script but nothing prevents you from doing either.
>
>> I think the Gentoo devs forked udev to make either mdev or eudev
>> but when it was announced it was too new for me so I just let it go
>> by. Maybe now it's time for me to look into making a change of some
>> type? I see eudev in portage, but not mdev.
>
> Ok, just some definitions:
> udev - the upstream project that you're familiar with - it has
> recently merged with systemd, which has resulted in some changes that
> some find objectionable (changes in install paths, incorporation of
> systemd in file/path names, etc)
>
> eudev - a fork of udev that attempts to basically do the same thing as
> udev, but preserving the paths/etc used in the project prior to the
> systemd merge.
>
> mdev - shorthand for busybox mdev. This isn't a separate package. If
> you have busybox installed you can use a function it supports which
> will populate /dev based on detected devices, in a manner similar to
> udev. It is much less functional that udev, but if you have a simple
> system where you don't need hot-swap support and all the bells and
> whistles, it will give you a /dev similar to what you probably would
> find on most linux boxes 10 years ago.
>
>> A (really, really, really) quick scan of the current install docs
>> makes me think sysvinit/OpenRC/udev is still the default for new
>> installs. Is this true? If so why is this kernel change being
>> required?
>
> Udev is changing upstream - presumably because the new kernel features
> are helpful in some way. I haven't read the details.
>
>> Also, I seem to have virtual/udev installed which says it's about
>> enabling switching between udev & eudev. However there are no files
>> associated with virtual/udev. (equery files virtual/udev returns
>> nothing) It appears I cannot install eudev without removing udev so
>> this seems a big step to take:
>
> virtual/udev is a virtual package. Virtual packages are called
> virtual because they don't install files. They exist for dependency
> purposes - a package can depend on the virtual which lets you pick
> whether you want to use udev or eudev or something else without lots
> of things breaking.
>
> Eudev is a fork of udev and cannot co-exist with it. It would be like
> installing mariadb and mysql on the same system, or openoffice and
> libreoffice. So, if you want to install it portage will helpfully
> suggest uninstalling udev.
>
> I won't tell you what you should be doing, but before you switch from
> the defaults (openrc+udev+sysvinit) you should probably make sure you
> understand what you're getting into. The upstream udev is certainly
> what 99% of Linux users will be using in general for the foreseeable
> future, though I can't really see you getting into trouble with eudev
> or mdev (with many limitations on the latter). Migrating between them
> isn't very hard at the moment, though if config files/etc start
> diverging between eudev and udev that will make it harder to switch
> (depending on how much you tweak on your system).
>
> Rich
>

On Sun, Mar 2, 2014 at 12:12 PM, Mark Knecht <markknecht@gmail.com> wrote:
> Hi Canek - good to hear from you.

Hi.

[snip]

> So as an end user type I'm a little confused by this part of your
> response. When you say udev is 'part of systemd' do you mean at the
> project level? That's what I understand from your longer response
> below.

Yeah, udev is part of systemd: [1].

[snip]

> Good to know and I've already read a little more about it and enabled
> it in my kernel.

Good.

[snip]

> Humm. OK, so I've updated my main spinning rust kernel for FHANDLE. No
> problems there. sysvinit/OpenRC/udev. All good.

Good.

> As I write this I'm in my SSD backup Gentoo install. I haven't used it
> in awhile so I'm emerging 668 packages. System setup as above but
> maybe I'll consider switching this one to systemd just as a trial. At
> this time it's not important on my personal machines. However my 86
> year old father is the last Gnome holdout in the family. I've not
> updated his box in quite awhile (cognitive issues, fewer GUI changes
> are better for him) However if I do update then it will likely be
> Gnome so having at least a little experience with systemd might be
> good.

If your father is still using GNOME 2, GNOME 3 could be almost
traumatic. Perhaps you could try MATE? It's going into the tree soon,
i believe. Or Xfce.

[snip]

> Done, no noticeable impact after 20 minutes. All good.

Good.

[snip]

> Again, THANKS for a wonderful response with lots of good information.
> We're lucky to have you as one of the long-time Gentoo guys. I for one
> greatly appreciate what little I understand. :-)

Thank you.

Regards.

[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Sun, Mar 2, 2014 at 12:32 PM, Mark Knecht <markknecht@gmail.com> wrote:
> Thanks Rich. The picture is getting clearer and other than getting my
> backup SSD installation up to date it's good to know there's no
> difficult requirements for me to deal with at this time. Being that I
> have been (for the last 5-6 years anyway) a 'stable' Gentoo user it's
> to my advantage if things stay basically the same over time.
>
> After your and Canek's responses it's clear that within my framework I
> won't be moving to eudev or mdev. The only systemd question I might
> need to answer going forward is for my dad's machine. He's got 15
> years of email traffic in Evolution and I've not investigated running
> Evolution in any desktop environment other than Gnome. There's no way
> at this point to move him away from Evolution so I just need to figure
> out over time (the next year maybe) how to best deal with that.

Please don't top post.

I've been using Evolution for more than 10 years, always with GNOME,
but I'm pretty sure you can run it in every other DE.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Sun, Mar 2, 2014 at 10:42 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sun, Mar 2, 2014 at 12:32 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> Thanks Rich. The picture is getting clearer and other than getting my
>> backup SSD installation up to date it's good to know there's no
>> difficult requirements for me to deal with at this time. Being that I
>> have been (for the last 5-6 years anyway) a 'stable' Gentoo user it's
>> to my advantage if things stay basically the same over time.
>>
>> After your and Canek's responses it's clear that within my framework I
>> won't be moving to eudev or mdev. The only systemd question I might
>> need to answer going forward is for my dad's machine. He's got 15
>> years of email traffic in Evolution and I've not investigated running
>> Evolution in any desktop environment other than Gnome. There's no way
>> at this point to move him away from Evolution so I just need to figure
>> out over time (the next year maybe) how to best deal with that.
>
> Please don't top post.
>

Sorry. I seldom do that and don't know why I did that time.

> I've been using Evolution for more than 10 years, always with GNOME,
> but I'm pretty sure you can run it in every other DE.
>

Probably true. The bar I need to hurdle, probably not much of a jump,
would be getting any new DE to simply look enough like what he
currently has in Gnome 2. I suspect that XFCE with identical wallpaper
and a little thought about placing the right app-start icons on the
desktop would be enough to give me 'plausible deniability' about
whatever changes I actually made under the hood.

Leaving out the issue of password changes I hope few folks have to
deal with the phone call where, after 10 years of no changes, a loved
one calls you and asks "What is this screen that is asking for my User
Name and Password want me to do? I don't remember..." I am so thankful
for both the remote administration capabilities of Linux and the
security model/lack of viruses. I cannot imagine how painful my life
would be today if he was still using Windows living 350 miles away.

Cheers,
Mark

On Sun, 2014-03-02 at 10:58 -0800, Mark Knecht wrote:
> On Sun, Mar 2, 2014 at 10:42 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> > On Sun, Mar 2, 2014 at 12:32 PM, Mark Knecht <markknecht@gmail.com> wrote:
> >> Thanks Rich. The picture is getting clearer and other than getting my
> >> backup SSD installation up to date it's good to know there's no
> >> difficult requirements for me to deal with at this time. Being that I
> >> have been (for the last 5-6 years anyway) a 'stable' Gentoo user it's
> >> to my advantage if things stay basically the same over time.
> >>
> >> After your and Canek's responses it's clear that within my framework I
> >> won't be moving to eudev or mdev. The only systemd question I might
> >> need to answer going forward is for my dad's machine. He's got 15
> >> years of email traffic in Evolution and I've not investigated running
> >> Evolution in any desktop environment other than Gnome. There's no way
> >> at this point to move him away from Evolution so I just need to figure
> >> out over time (the next year maybe) how to best deal with that.
> >
> > Please don't top post.
> >
>
> Sorry. I seldom do that and don't know why I did that time.
>
> > I've been using Evolution for more than 10 years, always with GNOME,
> > but I'm pretty sure you can run it in every other DE.
> >
>
> Probably true. The bar I need to hurdle, probably not much of a jump,
> would be getting any new DE to simply look enough like what he
> currently has in Gnome 2. I suspect that XFCE with identical wallpaper
> and a little thought about placing the right app-start icons on the
> desktop would be enough to give me 'plausible deniability' about
> whatever changes I actually made under the hood.
>
> Leaving out the issue of password changes I hope few folks have to
> deal with the phone call where, after 10 years of no changes, a loved
> one calls you and asks "What is this screen that is asking for my User
> Name and Password want me to do? I don't remember..." I am so thankful
> for both the remote administration capabilities of Linux and the
> security model/lack of viruses. I cannot imagine how painful my life
> would be today if he was still using Windows living 350 miles away.
>
> Cheers,
> Mark
>

I'm currently running Evolution on KDE 4.x so it will work fine with
other DE then Gnome.

Choice is the spice of life.

B

On 3/2/2014 1:10 PM, Rich Freeman <rich0@gentoo.org> wrote:
> The big change in udev-210 is how persistent network device names are
> implemented. The file that implements the rules is changing names,
> which has an impact on your if you're trying to override it (your
> override will no longer work if you don't change the name to follow
> suit). Also, the new rule file now pulls in config settings from a
> file that contains "systemd" in the filename.

<snip>

> The file contains systemd in the name because it is also used by
> systemd for network settings.

Well... !?@?#?$?%

Here we go again. Talk about 'a driving force to subsume everything it
touches'!?

So, "we use some files, so we change the name of every file we use to
have our name in it?"

In other words... why stop at that one file?

How much sense does *that* make? Seriously, that *really* irks me...

I think I'll go and Prepend 'Charles-' to the name of every document
I've ever created... can anyone say 'egotistical'?

> Ok, just some definitions:
> udev - the upstream project that you're familiar with - it has
> recently merged with systemd, which has resulted in some changes that
> some find objectionable (changes in install paths, incorporation of
> systemd in file/path names, etc)

This is I think the crux of the problem.

Why did udev *merge* with systemd, if there is no long term goal of
completely and totally subsuming it such that you cannot use udev
without also using systemd?

Imnsho, since it is a KERNEL thingie, it should have been maintained as
a totally separate package, or just admit the long term goal and be done
with it.

> Udev is changing upstream - presumably because the new kernel features
> are helpful in some way. I haven't read the details.

Now I'd really, really, REALLY like to hear what Linus thinks about
systemd/udev NOW. The only things I can find from him are 4 or so years
old. I can't imagine that stuff like this doesn't irk him too...

Would someone who stands a chance at getting a response out of him
*please* ping him for an opinion on this stuff? Blog or LKML post would
be fine...

On Mon, Mar 3, 2014 at 12:15 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> Imnsho, since it is a KERNEL thingie, it should have been maintained as a
> totally separate package, or just admit the long term goal and be done with
> it.

Well, that would require somebody to actually do the work. Just about
everybody involved in contributing to udev supports the change. There
is of course eudev which is more-or-less what you're already looking
for. The only issues with that are the name isn't "udev" and any
projects that vertically integrate might not work with it (Gnome,
etc).

> Now I'd really, really, REALLY like to hear what Linus thinks about
> systemd/udev NOW. The only things I can find from him are 4 or so years old.
> I can't imagine that stuff like this doesn't irk him too...
>
> Would someone who stands a chance at getting a response out of him *please*
> ping him for an opinion on this stuff? Blog or LKML post would be fine...

Honestly, there is no shortage of people offering their opinions.
What there is a shortage of is people actually doing work to make
(e)udev do anything differently. In the end people can complain as
much as they want, but unless they fork over effort or dollars or
something they won't get terribly far. That's why Mint/Mate/etc are
all so popular these days - somebody took the time to fork. In the
case of eudev there really isn't enough manpower to do anything beyond
tweaking the upstream releases to not use the new paths/etc. I doubt
that anybody is actually adding features to eudev that aren't already
in udev, which greatly reduces the likelihood of upstream packages
targeting it.

If it were in the kernel then Linus's opinion would carry a lot more
weight (like when he basically modified the ext3/4 code over the
objections of the maintainers to use ordered commits by default (it
has been a while and I'm foggy on the details) - a decision that I
fully support for what little that matters).

Rich

Tanstaafl posted on Mon, 03 Mar 2014 12:15:50 -0500 as excerpted:

> Why did udev *merge* with systemd, if there is no long term goal of
> completely and totally subsuming it such that you cannot use udev
> without also using systemd?
>
> Imnsho, since it is a KERNEL thingie, it should have been maintained as
> a totally separate package, or just admit the long term goal and be done
> with it.

Actually, the point of udev was /userland/ (not kernel) managed device
policy. The idea was to keep the policy out of the kernel, unlike the
now dead 2.4-kernel devfs. (Current kernels do contain a slight variant
of tmpfs called devtmpfs specific to devices, but that doesn't do policy;
it's designed to be managed by userspace, tho in the absence of a
userspace device manager, kernelspace will create default-named device-
nodes there.)

Meanwhile, for the record, the systemd and now udev folks have stated
that they would like to eventually merge udev fully into systemd, and
indeed, it's already shipped as a single tarball, but that udev is likely
to remain a separate binary that can be run stand-alone for some time,
because that's necessary in ordered to be able to keep a somewhat small
initramfs, with udev but without all the trappings of a full-fledged
systemd.

However, with the introduction of kdbus and other changes, I'm wondering
if they'll decide they might as well shoehorn systemd onto the initramfs
as well, and will then subsume the full udev binary as well...


(This said as an openrc user at least for the time being... even
apparently one of the only people actually running the live-git
openrc-9999, or at least all the bugs filed on it seem to be mine. I've
suspected for some time that I'll eventually switch to systemd, but was
at least originally hoping to avoid it until it quits actively blackholing
nearly everything it comes across and had some reasonable time to
stabilize without gobbling something else up. But when that'll be... who
knows? And I'm getting an itch to try it one of these days, or at least
seriously read up on it with a view to _consider_ trying it, tho if I do
it'll likely still be against my better judgment, since I don't see it
really stabilizing any time soon and I had originally planned to wait for
that. So I guess I sort of fall in the middle in this debate.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Mon, Mar 3, 2014 at 11:15 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 3/2/2014 1:10 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> The big change in udev-210 is how persistent network device names are
>> implemented. The file that implements the rules is changing names,
>> which has an impact on your if you're trying to override it (your
>> override will no longer work if you don't change the name to follow
>> suit). Also, the new rule file now pulls in config settings from a
>> file that contains "systemd" in the filename.
>
> <snip>
>
>> The file contains systemd in the name because it is also used by
>> systemd for network settings.
>
> Well... !?@?#?$?%
>
> Here we go again. Talk about 'a driving force to subsume everything it
> touches'!?

The networkd simple network manager is a new development in systemd,
not udev. They saw that both could share some configs, so they used
the directory under /etc that the whole project (systemd) uses. That's
all.

> So, "we use some files, so we change the name of every file we use to have
> our name in it?"

They *added* new configuration options, and udev (as part of the
systemd project) *followed through*.

> In other words... why stop at that one file?
>
> How much sense does *that* make? Seriously, that *really* irks me...

All the sense in the world, if you actually read the code and see how
the new networkd works.

> I think I'll go and Prepend 'Charles-' to the name of every document I've
> ever created... can anyone say 'egotistical'?

The project (like it or not) is called systemd. They are using the
/etc/systemd directory for configuration (as per long Unix tradition).
They haven't moved /etc/udev to /etc/systemd/udev for backwards
compatibility, but they could do it, and I think they *will* do it at
some point in the future. Again, nothing will change for udev, only
your machine will have a (*GASP!*) systemd directory somewhere.

>> Ok, just some definitions:
>> udev - the upstream project that you're familiar with - it has
>> recently merged with systemd, which has resulted in some changes that
>> some find objectionable (changes in install paths, incorporation of
>> systemd in file/path names, etc)
>
> This is I think the crux of the problem.
>
> Why did udev *merge* with systemd, if there is no long term goal of
> completely and totally subsuming it such that you cannot use udev without
> also using systemd?

This is FUD, Tanstaafl; they have promised that udev will be able to
work independently from systemd, and they have kept their promise.
They merged the two projects to share code (which they do) and because
systemd wants to be the basic plumbing of Linux; udev is obviously
needed for that.

But udev works without systemd, and it will continue to do so. The
*only* change is that now udev can use (not sure if it's mandatory)
some configuration files from /etc/systemd/network. Yo don't *need*
systemd to get udev working, and if you feel that a
/etc/systemd/network directory is going to give you the systemd
cooties, I personally think that's incredible obsessive. It's just a
directory *name*; it doesn't even contains executable code.

You can do the job (a simple sed before compilation is enough) to
exorcise the systemd name from all udev related files, but it's (IMHO)
idiotic. The project *is* systemd, like it or not; but it's Free
Software, go nuts and change all the "systemd" strings for "Charles"
if you so desire (I think a dev is doing that in an overlay).

> Imnsho, since it is a KERNEL thingie, it should have been maintained as a
> totally separate package, or just admit the long term goal and be done with
> it.

There is a kernel component and a userpace component for udev; they
are separated in the kernel and the systemd project. Also, the long
term goal is clear from the very beginning: systemd wants to be the
basic plumbing in Linux. That is orthogonal to having udev working
without systemd, and they have promised to support that, and it still
works that way and there is no sign whatsoever that it's going to
change.

If you get offended by a /etc/systemd/network directory, I think you
have more important issues, and they are unrelated to systemd/udev.

>> Udev is changing upstream - presumably because the new kernel features
>> are helpful in some way. I haven't read the details.
>
> Now I'd really, really, REALLY like to hear what Linus thinks about
> systemd/udev NOW. The only things I can find from him are 4 or so years old.
> I can't imagine that stuff like this doesn't irk him too...

I don't think Linus opinion matters at all; people wanting to write
and use some free software projects will continue to do so
independently of what Linus, RMS, ESR, or the Flying Spaghetti Monster
says. Having said that, I would not be surprised if Linus actually
likes the idea of an standardized Linux plumbing, even if he dislikes
some particular implementation details, or its authors.

> Would someone who stands a chance at getting a response out of him *please*
> ping him for an opinion on this stuff? Blog or LKML post would be fine...

It would be interesting to know what he thinks; but either way it
doesn't really matters, like it didn't really mattered when he stopped
using GNOME, nor when he started using it again. Few users, if any,
stopped or started using GNOME because of that.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Mon, Mar 3, 2014 at 11:44 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Tanstaafl posted on Mon, 03 Mar 2014 12:15:50 -0500 as excerpted:
>
>> Why did udev *merge* with systemd, if there is no long term goal of
>> completely and totally subsuming it such that you cannot use udev
>> without also using systemd?
>>
>> Imnsho, since it is a KERNEL thingie, it should have been maintained as
>> a totally separate package, or just admit the long term goal and be done
>> with it.
>
> Actually, the point of udev was /userland/ (not kernel) managed device
> policy. The idea was to keep the policy out of the kernel, unlike the
> now dead 2.4-kernel devfs. (Current kernels do contain a slight variant
> of tmpfs called devtmpfs specific to devices, but that doesn't do policy;
> it's designed to be managed by userspace, tho in the absence of a
> userspace device manager, kernelspace will create default-named device-
> nodes there.)

Exactly.

> Meanwhile, for the record, the systemd and now udev folks have stated
> that they would like to eventually merge udev fully into systemd, and
> indeed, it's already shipped as a single tarball, but that udev is likely
> to remain a separate binary that can be run stand-alone for some time,
> because that's necessary in ordered to be able to keep a somewhat small
> initramfs, with udev but without all the trappings of a full-fledged
> systemd.

If you use dracut to generate your initramfs, you can get a
full-fledged systemd inside it, so you can use the systemd in the
initramfs to start the systemd in the real filesystem. I use it like
that. Total size of the "bloated" initramfs? 11 megabytes. 10,660,755
bytes if you want to be precise. It's even reasonable for an embedded
system; and I have a lot of stuff there, it can be trimmed to be
really small, still keeping systemd inside.

Lets be clear: udev is *fully* merged into systemd. The share *code*.
They are the *same project*. But udev can run without systemd, and
that is not going to change. If anyone says otherwise, they are
spreading FUD.

BTW, and not really important, but systemd cannot run without udev.

> However, with the introduction of kdbus and other changes, I'm wondering
> if they'll decide they might as well shoehorn systemd onto the initramfs
> as well, and will then subsume the full udev binary as well...

Systemd is already "shoehorned" into my initramfs, and it works great,
thank you very much. I don't understand what you mean by "subsume the
full udev binary as well".

> (This said as an openrc user at least for the time being... even
> apparently one of the only people actually running the live-git
> openrc-9999, or at least all the bugs filed on it seem to be mine. I've
> suspected for some time that I'll eventually switch to systemd, but was
> at least originally hoping to avoid it until it quits actively blackholing
> nearly everything it comes across and had some reasonable time to
> stabilize without gobbling something else up. But when that'll be... who
> knows? And I'm getting an itch to try it one of these days, or at least
> seriously read up on it with a view to _consider_ trying it, tho if I do
> it'll likely still be against my better judgment, since I don't see it
> really stabilizing any time soon and I had originally planned to wait for
> that. So I guess I sort of fall in the middle in this debate.)

If you run OpenRC live, I think you'll be fine running systemd, even
209/210, which introduced so many changes I've been waiting to upgrade
my systems.

Come to the dark side. We have cookies.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Mon, 3 Mar 2014 12:40:59 -0500
Rich Freeman <rich0@gentoo.org> wrote:

>
> Honestly, there is no shortage of people offering their opinions.
> What there is a shortage of is people actually doing work to make
> (e)udev do anything differently. In the end people can complain as
> much as they want, but unless they fork over effort or dollars or
> something they won't get terribly far.
>

Work? What work?

I have never used udev/eudev/mdev or anything similar and, if I am allowed
to nave a choice, I never will.

Manually creating a /dev tree that perfectly reflects ones own system
is rather trivial. That's how Linux used to be and that's how Linux,
for the most part, still is. There is, or at least should be, no need
for udev or any substitute for udev.

IOW, udev should be developed as a nice, helpful option for those who
want such nice, helpful options. But it always should be just that: optional.
Once it stops being a choice then we begin to deviate greatly from
the once sacrosanct principles of free software.

Frank Peters

On Mon, Mar 3, 2014 at 12:12 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Mon, 3 Mar 2014 12:40:59 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>
>>
>> Honestly, there is no shortage of people offering their opinions.
>> What there is a shortage of is people actually doing work to make
>> (e)udev do anything differently. In the end people can complain as
>> much as they want, but unless they fork over effort or dollars or
>> something they won't get terribly far.
>>
>
> Work? What work?
>
> I have never used udev/eudev/mdev or anything similar and, if I am allowed
> to nave a choice, I never will.

You will always have that choice, since the software is free.

> Manually creating a /dev tree that perfectly reflects ones own system
> is rather trivial. That's how Linux used to be and that's how Linux,
> for the most part, still is. There is, or at least should be, no need
> for udev or any substitute for udev.

If you want to create a /dev tree for a computer that never gets new
hardware connected via USB, bluetooth, or another bus, yeah, it's
pretty trivial.

Too bad that kind of computer is going the way of the dodo.

> IOW, udev should be developed as a nice, helpful option for those who
> want such nice, helpful options. But it always should be just that: optional.
> Once it stops being a choice then we begin to deviate greatly from
> the once sacrosanct principles of free software.

We agree on that one. Of course, if a distribution wants to support as
many users as they could, they probably will choose the nice, helpful
options.

The alternatives will be always available, of course. It's just that
perhaps no distribution will want to do the "rather trivial" work of
generating a static /dev tree for *your* computer.

But is rather trivial, isn't it? So it doesn't matter.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Frank Peters <frank.peters@comcast.net> skribis:
> On Mon, 3 Mar 2014 12:40:59 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>
> >
> > Honestly, there is no shortage of people offering their opinions.
> > What there is a shortage of is people actually doing work to make
> > (e)udev do anything differently. In the end people can complain as
> > much as they want, but unless they fork over effort or dollars or
> > something they won't get terribly far.
> >
>
> Work? What work?
>
> I have never used udev/eudev/mdev or anything similar and, if I am allowed
> to nave a choice, I never will.
>
> Manually creating a /dev tree that perfectly reflects ones own system
> is rather trivial. That's how Linux used to be and that's how Linux,
> for the most part, still is. There is, or at least should be, no need
> for udev or any substitute for udev.
>
> IOW, udev should be developed as a nice, helpful option for those who
> want such nice, helpful options. But it always should be just that: optional.
> Once it stops being a choice then we begin to deviate greatly from
> the once sacrosanct principles of free software.

I second everything here. There is very little achieved by udev that
is of any appreciable benefit to a Gentoo user, who could easily
create nodes and set their permissions without having to do anything
complicated.

(Disclaimer: Currently I am using eudev, without pleasure.)

Canek Peláez Valdés <caneko@gmail.com> skribis:
> On Mon, Mar 3, 2014 at 12:12 PM, Frank Peters <frank.peters@comcast.net> wrote:
> > Manually creating a /dev tree that perfectly reflects ones own system
> > is rather trivial. That's how Linux used to be and that's how Linux,
> > for the most part, still is. There is, or at least should be, no need
> > for udev or any substitute for udev.
>
> If you want to create a /dev tree for a computer that never gets new
> hardware connected via USB, bluetooth, or another bus, yeah, it's
> pretty trivial.

What’s hard? You create nodes for those devices. If you have a lot of
devices, you create more nodes. With a script, you can create enough
nodes to wrap the earth a few times over. All udev does is create and
destroy nodes according to an unfathomable set of rules that changes
all the time.

On Mon, Mar 3, 2014 at 9:58 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
<SNIP>
>
> Come to the dark side. We have cookies.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

I like cookies. Cookies sounds good. You're not a bad man with candy are you?

OK, I updated my SSD backup install this weekend so it's totally
up-to-date. I'm curious enough and have good backups so I might be
willing to take a bite and see if it's sweet or poison. ;-)

QUESTION: I always use the plain Gentoo KDE profile as I run KDE.
Looks like I possibly would select the KDE/systemd profile, do the
work and then go through a learning process about how to get the right
services turned on?

If I understand this all then systemd, in it's current state, is going
to require removing udev as a stand-along package, will remove
sysvinit as systemd provides /sbin/init, and will also replace OpenRC
with it's own code for starting and stopping services? It's a big
change but it's one of the reasons why I built the backup install on
the SSD. None of this really touches my spinning rust install I use
daily.

Also, WRT to an earlier comment about udev being 'merged recently' I
found Kay Sievers note on this and that was somewhere in 2012. I agree
with Canek here that being that it's 18 month later and I didn't know
this and it's had no real effect on my machines it seems an
overreaction to get too worried about that. Yeah, in the future they
could possibly make it harder to use but eudev will know that's coming
and fork again I'd think, assuming anyone cares at that point.

Cheers,
Mark

- Mark

On Mon, Mar 3, 2014 at 12:36 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Canek Peláez Valdés <caneko@gmail.com> skribis:
>> On Mon, Mar 3, 2014 at 12:12 PM, Frank Peters <frank.peters@comcast.net> wrote:
>> > Manually creating a /dev tree that perfectly reflects ones own system
>> > is rather trivial. That's how Linux used to be and that's how Linux,
>> > for the most part, still is. There is, or at least should be, no need
>> > for udev or any substitute for udev.
>>
>> If you want to create a /dev tree for a computer that never gets new
>> hardware connected via USB, bluetooth, or another bus, yeah, it's
>> pretty trivial.
>
> What’s hard? You create nodes for those devices. If you have a lot of
> devices, you create more nodes. With a script, you can create enough
> nodes to wrap the earth a few times over. All udev does is create and
> destroy nodes according to an unfathomable set of rules that changes
> all the time.

I never said it was hard; but someone or something has to do it.

You don't remember /dev ca. 2002 or 2003? It was a mess.

Again, the important problem (the *interesting* problem), is to solve
the general case. That means having nodes for *all* possible hardware
out there, in *all* possible combinations.

Of course every single user can keep a neat and clean /dev directory.
The point is, most users don't want to do that. Using udev solves that
issue *for every possible user using every possible hardware
combination*.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Mon, Mar 3, 2014 at 1:38 PM, Mark Knecht <markknecht@gmail.com> wrote:
> If I understand this all then systemd, in it's current state, is going
> to require removing udev as a stand-along package, will remove
> sysvinit as systemd provides /sbin/init, and will also replace OpenRC
> with it's own code for starting and stopping services? It's a big
> change but it's one of the reasons why I built the backup install on
> the SSD. None of this really touches my spinning rust install I use
> daily.

I suggest you read the systemd docs. Installing systemd will not
remove sysvinit or openrc. However, after you change your kernel
command line they will not be run as pid1 or as a service manager, and
systemd has its own configuration for services. You can basically
switch back and forth as long as you maintain your settings in
parallel.

There is work to make it possible to use systemd without having openrc
installed. The main issue right now is a few packages use functions
in openrc which are not present in systemd, so that needs some
refactoring. However, having them both installed in parallel doesn't
really cost anything besides a few inodes (and not all that many).

Rich

Canek Peláez Valdés <caneko@gmail.com> skribis:
> Of course every single user can keep a neat and clean /dev directory.
> The point is, most users don't want to do that. Using udev solves that
> issue *for every possible user using every possible hardware
> combination*.

Which is why it is a nice _option_, unnecessary for Gentoo in general,
and foolish to make a _prerequisite_ to run a whole lot of
software. That’s exactly my point, and I think it was Frank’s as well.

The trouble comes not from udev itself but from ‘vertical integration’
involving udev, which is directly contrary to principles of good,
modular design.

On Mon, Mar 3, 2014 at 10:57 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Mar 3, 2014 at 1:38 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> If I understand this all then systemd, in it's current state, is going
>> to require removing udev as a stand-along package, will remove
>> sysvinit as systemd provides /sbin/init, and will also replace OpenRC
>> with it's own code for starting and stopping services? It's a big
>> change but it's one of the reasons why I built the backup install on
>> the SSD. None of this really touches my spinning rust install I use
>> daily.
>
> I suggest you read the systemd docs.

I agree. Prior to Canek's previous email I wasn't giving this much
real though. With his response, your additional info and some study of
the docs I may try it later this week.

> Installing systemd will not
> remove sysvinit or openrc. However, after you change your kernel
> command line they will not be run as pid1 or as a service manager, and
> systemd has its own configuration for services. You can basically
> switch back and forth as long as you maintain your settings in
> parallel.
>

OK, that helps with the worry that something goes wrong and the whole
system is left unbootable.

> There is work to make it possible to use systemd without having openrc
> installed. The main issue right now is a few packages use functions
> in openrc which are not present in systemd, so that needs some
> refactoring. However, having them both installed in parallel doesn't
> really cost anything besides a few inodes (and not all that many).
>
> Rich
>

Thanks,
Mark

On Mon, Mar 3, 2014 at 12:57 PM, Barry Schwartz
<chemoelectric@chemoelectric.org> wrote:
> Canek Peláez Valdés <caneko@gmail.com> skribis:
>> Of course every single user can keep a neat and clean /dev directory.
>> The point is, most users don't want to do that. Using udev solves that
>> issue *for every possible user using every possible hardware
>> combination*.
>
> Which is why it is a nice _option_, unnecessary for Gentoo in general,

Whoa, excuse me? Who are you to make that call? I'm a Gentoo user, and
I think udev is necessary. Besides, Gentoo uses udev *by default*
since, like, ever. That is not going to change, at least soon, and
probably never.

> and foolish to make a _prerequisite_ to run a whole lot of
> software.

That's your opinion, and you're entitled to it. I don't share it, and
(more importantly) the Gentoo devs don't share it, since udev is
installed and used by default in Gentoo. If you want to use eudev (or
mdev), you need to do it by yourself.

> That’s exactly my point, and I think it was Frank’s as well.

I understand; I'm just trying to explain why every Linux distro
(except a few niche ones) uses udev, and why most of them use systemd.

> The trouble comes not from udev itself but from ‘vertical integration’
> involving udev, which is directly contrary to principles of good,
> modular design.

We already had this discussion in -user (and they had it in Debian,
Arch, OpenSUSE and Fedora). Those "principles" you speak of are not
religious commandments; they are rules of thumb, and the sky doesn't
fall if you don't follow them to the letter.

And, also, it can be argued that systemd/udev has a good modular
design. From [1]:

"1. Myth: systemd is monolithic.

If you build systemd with all configuration options enabled you will
build 69 individual binaries. These binaries all serve different
tasks, and are neatly separated for a number of reasons. For example,
we designed systemd with security in mind, hence most daemons run at
minimal privileges (using kernel capabilities, for example) and are
responsible for very specific tasks only, to minimize their security
surface and impact. Also, systemd parallelizes the boot more than any
prior solution. This parallization happens by running more processes
in parallel. Thus it is essential that systemd is nicely split up into
many binaries and thus processes. In fact, many of these binaries[1]
are separated out so nicely, that they are very useful outside of
systemd, too.

A package involving 69 individual binaries can hardly be called
monolithic. What is different from prior solutions however, is that we
ship more components in a single tarball, and maintain them upstream
in a single repository with a unified release cycle."

That's all I will post related to the good or bad design of systemd;
we've had that conversation many times in different lists, and I will
not enter to it again. Specially since, every single time, the
consensus from the people that actually write and design code is that
systemd is quite good, or at least OK.

This thread is about the new /etc/systemd/network directory, and how
its cooties infect a machine.

Regards.

[1] http://0pointer.de/blog/projects/the-biggest-myths.html
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Mon, 3 Mar 2014 12:20:29 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> >
> > I have never used udev/eudev/mdev or anything similar and, if I am allowed
> > to nave a choice, I never will.
>
> You will always have that choice, since the software is free.
>

That's not true anymore. My USB scanners will not operate unless udev
is able to create an entry within the /dev tree.

Fortunately, I was able to discover a work-around that does not require
udev, but the point is that freedom of choice is starting to disappear.
Udev will eventually be the *only* way to deal with hardware.


>
> If you want to create a /dev tree for a computer that never gets new
> hardware connected via USB, bluetooth, or another bus, yeah, it's
> pretty trivial.
>
> Too bad that kind of computer is going the way of the dodo.
>

Also not true. We are, to be sure, experiencing explosive growth in
mobile computing but there is still a substantial number of traditional
desktop machines in operation for which udev is still quite unnecessary.

But, to continue your point, we can also claim that hardware itself
is going the way of the dodo. The way of the future is to have Linux,
and all other operating systems, existing on top of layers of virtualization
without the need for specific hardware concerns at all.

This possibility for total virtualization would still not be desirable
for all.

>
> The alternatives will be always available, of course.
>

I hope that you are right, but when I see distributions like "Linux
From Scratch," which purport to give the user total understanding
and control of his system, not including alternatives to udev I begin
to have serious doubts.

Frank Peters