[gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

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?

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

   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. 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.

   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?

   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:

c2RAID6 ~ # emerge -pvDuN eudev

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-fs/eudev-1.3  USE="gudev introspection modutils
openrc rule-generator -doc -hwdb -keymap -kmod (-selinux) -static-libs
{-test}" ABI_X86="(64) (-32) (-x32)" 1,641 kB
[uninstall     ] sys-fs/udev-208  USE="acl firmware-loader gudev
introspection kmod openrc -doc (-selinux) -static-libs" ABI_X86="(64)
(-32) (-x32)"
[blocks b      ] sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-1.3)

Total: 1 package (1 new, 1 uninstall), Size of downloads: 1,641 kB
Conflict: 1 block
c2RAID6 ~ #

   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. 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.

Thanks,
Mark

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Rich Freeman]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

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
>

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[B Vance]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Tanstaafl]

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...

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Rich Freeman]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Frank Peters]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Barry Schwartz]

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.

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Barry Schwartz]

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.

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Frank Peters]

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

On Mon, Mar 3, 2014 at 1:10 PM, Frank Peters <frank.peters@comcast.net> wrote:
> 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.

The repositories for everything SANE related are out there, aren't
they? Grab the code from pre-udev times and update it to support the
new scanners.

The code is free, you can do it.

> 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.

Mmmh, not true. The *BSD deal with hardware, and they don't use udev.

You mean in Linux? If someone *willing and able* wants to write
support for hardware that doesn't uses udev, they could, and they
will.

Of course, most people willing and able actually works with udev and
systemd, and they think they are a really neat idea. But the code is
out there, if you are so determined to pursue that goal.

I, and most people I believe, would think is a waste of time, but
that's the beauty of Free Software; nobody can stop anyone to write
what they want.

>> 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.

Sorry, I believe you are wrong. I have a desktop computer, and I
connect a lot of hardware to it. Including bluetooth stuff.

I don't want to create a static /dev for it; I'm perfectly happy using
udev with my desktop computer.

> 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.

And systemd works *beautifully* inside containers. If you are really
interested, I recommend you reading about systemd-nspawn[1].

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

I don't see how I can make a cell phone call without a physical cell phone.

>> 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.

The alternatives will be always available, if someone writes code for
them and test them and fill bug reports for them. So, if you really
want the alternatives to work, help them. Contribute to its authors.

I'm perfectly happy with and standardized plumbing for Linux in general.

Regards.

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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

On Mon, Mar 3, 2014 at 11:10 AM, Frank Peters <frank.peters@comcast.net> wrote:
> 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.

While I understand your point these two comments contradict each
other, or more accurately, the first was inaccurate in the sense that
someone needed to create your /dev entry, either udev or you, it
didn't matter. Once it was there your scanner worked, correct?

Again, I do understand the concern. Never having run systemd I have it
also. However the more I read the more tame the concerns seem to be.
They do, however, still exist...

- Mark

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Frank Peters]

On Mon, 3 Mar 2014 11:20:50 -0800
Mark Knecht <markknecht@gmail.com> wrote:

> 
> While I understand your point these two comments contradict each
> other, or more accurately, the first was inaccurate in the sense that
> someone needed to create your /dev entry, either udev or you, it
> didn't matter. Once it was there your scanner worked, correct?
> 

With USB devices things are a bit different.  If I plug in a USB
gadget, the kernel will report a certain device.  If I then unplug
it and then immediately replug it, the kernel will report a different
device even though it is the same USB gadget.  For this reason, udev
can alleviate the uncertainty by automagically constructing the
correct device node.

However, until recently, USB scanners were accessed through a kernel
module and this allowed a static node to be created in the /dev tree.
Using the kernel module access, SANE could always find the scanner.
For some reason, the scanner module has been eliminated from the
kernel and now udev is unconditionally necessary for scanner access
(unless the user employs an awkward workaround).

This represents the future trend.  Udev will be an absolute, total
requirement for everything.

Admittedly, my views are in the (exteme?) minority.  So it's goodbye
simplicity and hello complicated junk.

I used to have a lot of fun building and tweaking my Linux system,
but that experience is fading fast.

Frank Peters

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Rich Freeman]

On Mon, Mar 3, 2014 at 4:51 PM, Frank Peters <frank.peters@comcast.net> wrote:
>
> This represents the future trend.  Udev will be an absolute, total
> requirement for everything.
>

There are other scenarios where things can break down.

I was using two pl2303 usb rs232 adapters with mythtv as
channel-changers and it required some udev rules to ensure that I
could get consistent names for each one.  Otherwise they are
indistinguishable and the kernel doesn't really care how they end up
getting named.  (I ended up mapping them to physical ports and
assigning symlinks accordingly).

This sort of thing isn't uncommon with usb.  For many users you can
definitely get by without udev, but honestly I don't see why you'd
want to.  It is really nice to be able to use disks based on labels,
uuids, and so on.  Udev adds a lot of convenience features beyond just
giving me a /dev/sda or whatever.

Rich

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

On Mon, Mar 3, 2014 at 1:51 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Mon, 3 Mar 2014 11:20:50 -0800
> Mark Knecht <markknecht@gmail.com> wrote:
>
>>
>> While I understand your point these two comments contradict each
>> other, or more accurately, the first was inaccurate in the sense that
>> someone needed to create your /dev entry, either udev or you, it
>> didn't matter. Once it was there your scanner worked, correct?
>>
>
> With USB devices things are a bit different.  If I plug in a USB
> gadget, the kernel will report a certain device.  If I then unplug
> it and then immediately replug it, the kernel will report a different
> device even though it is the same USB gadget.  For this reason, udev
> can alleviate the uncertainty by automagically constructing the
> correct device node.
>

OK, fair enough. However from the outside udev doesn't look like
magic, at least the way I used it as it's mostly about my modifying
some file to say 'this USB ID is this dev, this MAC address is this
network', and so on and so on.

While I'm arguably the least experienced person on this list I'm sure
someone with your skills could figure out your own scripts to do that
sort of thing, should you choose to.

> However, until recently, USB scanners were accessed through a kernel
> module and this allowed a static node to be created in the /dev tree.
> Using the kernel module access, SANE could always find the scanner.
> For some reason, the scanner module has been eliminated from the
> kernel and now udev is unconditionally necessary for scanner access
> (unless the user employs an awkward workaround).
>
> This represents the future trend.  Udev will be an absolute, total
> requirement for everything.
>
> Admittedly, my views are in the (exteme?) minority.  So it's goodbye
> simplicity and hello complicated junk.
>
> I used to have a lot of fun building and tweaking my Linux system,
> but that experience is fading fast.
>
> Frank Peters
>
>

Well Frank, you and I have been around here long enough to remember
each other and get old enough to start forgetting how long we've been
around here. Like you it used to be more fun. Probably like you I used
to be a lot younger too! :-)

Cheers,
Mark

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Barry Schwartz]

Frank Peters <frank.peters@comcast.net> skribis:
> 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.

Having built LFS and CLFS systems, I can say the process is not very
informative, at least not anymore. It is basically like those old
Radio Shack electronics kits where they told you what to solder where,
but you still were given very little if any idea how the device
worked. Stick udev here, stick pam there, etc. What you _do_ learn is
(a) how to bootstrap a Linux OS from another Linux OS (in a bit more
detail than you learn with modern Gentoo) and (b) how to use GNU
Autotools much more effectively. This is like learning how to solder,
but not like learning electronics.

I do not see what is so difficult to understand about our
position. Imagine if Gentoo started requiring that you use a generic
kernel, because upstream software no longer worked if you configured
your own kernel. You’d still be getting free-as-in-beer software, but
effectively you would have lost some of your liberty.

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Barry Schwartz]

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.)

[gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Duncan]

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

Re: [gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

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

Re: [gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

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

Re: [gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Rich Freeman]

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

Re: [gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

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

Re: [gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Drake Donahue]

On Mon, 2014-03-03 at 10:38 -0800, Mark Knecht 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.
> 
Two systems - one upgraded to systemd, one new install with systemd:
Two kernels for each system: - "CONFIG_GENTOO_LINUX_INIT_SYSTEMD=y" is
enabled on one kernel for each system and "
#CONFIG_GENTOO_LINUX_INIT_SYSTEMD is not set" disabled on one kernel for
each system
Both kernels boot for each system. 
Systemd initializes gentoo for the systemd enabled kernels
Openrc initializes gentoo for the systemd disabled kernels 
BTW Gnome 3.8 runs on both systemd initialized and openrc initialized
systems.  

http://wiki.gentoo.org/wiki/Systemd
https://wiki.gentoo.org/wiki/Systemd/upgrade
http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide

Re: [gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Mark Knecht]

On Mon, Mar 3, 2014 at 11:18 AM, Drake Donahue <donahue95@comcast.net> wrote:
> On Mon, 2014-03-03 at 10:38 -0800, Mark Knecht 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.
>>
> Two systems - one upgraded to systemd, one new install with systemd:
> Two kernels for each system: - "CONFIG_GENTOO_LINUX_INIT_SYSTEMD=y" is
> enabled on one kernel for each system and "
> #CONFIG_GENTOO_LINUX_INIT_SYSTEMD is not set" disabled on one kernel for
> each system
> Both kernels boot for each system.
> Systemd initializes gentoo for the systemd enabled kernels
> Openrc initializes gentoo for the systemd disabled kernels
> BTW Gnome 3.8 runs on both systemd initialized and openrc initialized
> systems.
>
> http://wiki.gentoo.org/wiki/Systemd
> https://wiki.gentoo.org/wiki/Systemd/upgrade
> http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide
>
>

Again, not enough time to study the docs yet, and I personally think
it was very clear from the title that this whole conversation is very
exploratory. Like Duncan, when I start to get the bug to look at
something down the road I know I'm gonna do it if for no other reason
than just to try it out.

All of that in mind the above comments about two kernels coupled with
Canek & Rich's comments about keeping parallel settings (I'll have to
go think about that) makes a lot of sense and is likely the way I'll
go.

If nothing else, I could always just do a systemd-based install from
scratch if I botch all of this somehow but I doubt that will happen.
Doing it in a VM is a possibility also. I've wanted to study LVM a bit
so maybe that's the way to try this out.

Thanks to all that have answered. I'll read anything else that comes
along but I've gotten lots of great thoughts and hints. Cheers to all.

- Mark

[gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Duncan]

Canek Peláez Valdés posted on Mon, 03 Mar 2014 11:58:18 -0600 as
excerpted:

> 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.

FWIW, 9 MiB (8091136 bytes) uncompressed cpio here, dracut generated 
including btrfs but with some of the normal dracut modules omitted.  
*NOT* host-only mode as I experienced some bugs with host-only 
(apparently now fixed but I had already done my manual module setup 
so...).

I'm only running an initramfs at all because some kernels ago when I 
originally setup my (dual-device raid1 mode) btrfs rootfs, the kernel 
command-line parser couldn't properly parse rootflags=device= , 
apparently due to splitting at the wrong equal-sign, so the only way I 
could mount rootfs direct from the kernel commandline was in degraded 
mode. =:^(  I'm not sure if that has been fixed or not, but I have the 
initramfs setup and working now, so it's not so pressing to find out.  
Anyway, I expect that someday I'll be able to omit that and go back to a 
direct (initr*less) kernel commandline root=/rootflags= boot.

> 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.

Like some of the other broken promises, including keeping it separate 
tarballs, because (break-reason straight from the horse's mouth) they 
don't care about source-based distros.

>> 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".

I suspect that after kdbus gets into wide use, they'll decide that they 
no longer need a separate udev at all, and despite promises to the 
contrary, it'll be so integrated into systemd (possibly even as a single 
binary, thus the subsumed wording) that only forks such as eudev will 
allow use of the one without the other.

Yes it'll break the promise, but they've already demonstrated they're 
willing to do that.

>> (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.

Interesting note there:  At the last upgrade I had a dracut -rX bump and 
the udev-210 bump, but dracut had a blocker on udev-210.  I'd have 
already updated if I wasn't running an initr*, but based on the blocker 
introduction changelog wording, current dracut can't see some of the 
moved udev files (didn't pay attention to exactly what, just decided to 
mask 210 for now and get on with life, as 208 seems to be working fine 
for me ATM) and thus doesn't include them, thus the blocker until dracut 
gets updated to look in the new locations as well.

> Come to the dark side. We have cookies.

I'd normally need a block of several days in a row off in ordered to do 
the necessary research (I intend to read most of the systemd for sysadmins 
guide, plus whatever gentoo-specific stuff is available, I won't upgrade 
until I understand at least the underlying theory in enough depth to be 
sufficiently comfortable dealing with a recovery from boot-failure 
situation, tho I recognize the real comfort only comes with practice).

Since I'm doing overtime most weeks ATM, that's not likely short-term.  I 
could do some of the research ahead of time, but I have to be in the 
right mood and not too tired to grok what I'm reading.  I'm not a 20-year-
old college student any more, and I can't so easily properly integrate 
entirely new knowledge on two hours sleep as I used to, back then. =:^(

But based on previous experience once I get in this sort of impatient "I 
wonder..." mood about an anticipated switch, I usually find myself 
actually trying it within a few months, so chances are I'll either be 
switched over, or alternatively have some solid experience and concrete 
answers as to why either it or me aren't ready for that, quite likely 
before year's end, and very possibly within 1H2014.  No hurry, but that's 
what previous experience suggests for timing once I start thinking about 
it like this, none-the-less.

-- 
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

Re: [gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Rich Freeman]

On Mon, Mar 3, 2014 at 2:43 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> But based on previous experience once I get in this sort of impatient "I
> wonder..." mood about an anticipated switch, I usually find myself
> actually trying it within a few months, so chances are I'll either be
> switched over, or alternatively have some solid experience and concrete
> answers as to why either it or me aren't ready for that...

I don't think there is really any other way to approach stuff like
this.  By all means do it in a VM or whatever, but feedback about
systemd/etc is far more useful when it comes from people who have
actually bothered to get it working.

Regurgitating arguments already floating around doesn't add nearly as
much value as actually trying something new and then doing something
to try to make it better...

Rich

[gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Duncan]

Duncan posted on Mon, 03 Mar 2014 19:43:26 +0000 as excerpted:

> I'm only running an initramfs at all because some kernels ago when I
> originally setup my (dual-device raid1 mode) btrfs rootfs, the kernel
> command-line parser couldn't properly parse rootflags=device= ,
> apparently due to splitting at the wrong equal-sign, so the only way I
> could mount rootfs direct from the kernel commandline was in degraded
> mode. =:^(  I'm not sure if that has been fixed or not, but I have the
> initramfs setup and working now, so it's not so pressing to find out.
> Anyway, I expect that someday I'll be able to omit that and go back to a
> direct (initr*less) kernel commandline root=/rootflags= boot.

FWIW, I tested a couple days ago with a current 3.14-rcX+ git kernel, and 
the kernel commandline parsing issue appears to still be there, so no 
simple way out of the initr* situation for me yet. =:^(

Maybe one of these days I'll go looking into it more intensely, and 
report a kernel bug if necessary.  I wonder if there's some other command 
I can double-equal check to see if it parses in the right place, and I've 
not even googled it yet, but that does seem the most likely problem, 
given that a NON-equals-including rootflags (btrfs' degraded option) was 
demonstrated to still work in my earlier testing, so the rootflags option 
is in general working, and btrfs is actually picking up general options 
passed to it that way.

'Cause it'd sure be nice to be able to just dump this initr* business 
again!

(Hmm, just musing, but as a definite non-coder but an otherwise 
reasonably advanced gentooer who never-the-less has kernel bug-reporting 
experience, and who routinely applies patches to other things and 
occasionally to the kernel as well, and who in very limited circumstances 
can actually come up with his own patches...  I obviously can't get too 
ambitious about creating my own kernel patches, but I wonder just how 
difficult it might be to patch the kernel btrfs code to use some other 
delimiter in place of the equals in "device="...  If I could successfully 
do that just for testing, hopefully conclusively proving my suspicion 
that the double-equals IS the problem, that would certainly make an 
actually practical bug report, while just a suspicion... not so much, 
particularly since I don't have a kernel version where it was known to 
work in the past, thereby making it a known regression, tho various hints 
I've seen in comments found on the net suggest that it must have at some 
point, altho there's also hints that it was some time ago, given the age 
of some of the comments saying it now doesn't work.)

-- 
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

[gentoo-amd64] Systemd Was: Please get me straight about sysvinit vs. systemd [...]

[Duncan]

Canek Peláez Valdés posted on Mon, 03 Mar 2014 11:58:18 -0600 as
excerpted:

> On Mon, Mar 3, 2014 at 11:44 AM, Duncan <1i5t5.duncan@cox.net> wrote:

>> 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.

I had seen hints to that effect, but as I was still running openrc it 
didn't have any immediate bearing on my dracut and initr* config, beyond 
USE=-systemd for dracut.

>> (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.

=:^)

As you /might/ have deduced by now from the hints of the past-tense "was" 
and "didn't" above, as well as the fact that I'm dredging up this 
slightly (10 days) stale thread to reply to...

Yeah, I'm actually replying from a systemd booted system, now.

As I was privately predicting for myself, but didn't want to promise even 
to myself[1], I was getting close to the tipping point and this thread, 
plus a couple extra days off, provided the trigger.

Since my experience may be of help to others considering the switch, here 
we go...

In addition to unfortunately not finding a proper good detail but not 
losing sight of the forest for the trees admin-level-targeted systemd 
guide, a problem I overcame by simply immersing myself in the idea, full 
systemd for admins series, multiple hour-ish videos, hours of thinking 
about it while doing other things, sleeping over what I was learning over 
several days...

There were five specific problems, three of which I've now overcome, with 
two less pressing ones to go:

1) Various fstab mount configuration issues (local-fs.target).

To my very pleasant surprise, systemd has a reasonably effective nested-
mount-dependency algorithm and can often figure out on its own which 
fstab configured mount-points are nested under and thus depend on 
others.  This actually simplified things considerably as one of my custom 
openrc services was basically a localmount that had to come after 
localmount but before some other service, in ordered to properly handle 
nested mountpoints, and systemd's nested-mount-dependency processing very 
nicely solved most of that automatically, without my having to worry 
about porting a custom service.

1a) Unfortunately, systemd's nested-mountpoint detection algorithm isn't 
smart enough to deal with symlinked paths, at least not in all cases.  
One of my mount-related problems was thus a bind-mount configured in 
fstab, that wasn't happening because the origin, on a different non-root 
filesystem, wasn't mounted yet, so the attempt to bind-mount it elsewhere 
failed, and local-fs.target was failing as a result of that failure.

I solved that one by changing the origin/device path for that fstab entry 
to point at the canonical path instead of the symlinked path.

1b) My fstab entry for tmpfs on /run had a size=2m option, plenty for 
/run on openrc, but NOT for systemd, as by the time it got to the /run 
remount it already had an 8-meg early-boot journal file there, so 
obviously the remount to 2-meg was failing!  Of course that was failing 
local-fs.target as well.

That one was hard to track down as I didn't expect systemd to be putting 
a journal there and thus couldn't imagine what the problem was, but once 
tracked down, given that I'm running 16-gig RAM, upping that to something 
a bit more reasonable for the new usage, size=512m, was an easy fix.

With those fixes, local-fs.target finally succeeded, and I could get 
farther in the boot, most services of course having an automatic 
dependence on local-fs.target.

2) Unit file .include deprecated, replaced by *.d/*.conf files.

2a) systemd-random-seed.service was failing, again due to a mount-point-
detection symlink issue -- my /var is on my rootfs, which is read-only 
mounted for normal operation (only rw mounted for updates and config 
changes), so /var/lib/ is a symlink to /home/var/lib, /home naturally 
being rw mounted in normal operation, and systemd was trying to read the 
random-seed off that symlinked /home location before it was mounted, 
because all it knew to check for was /var, which being on / was of course 
mounted.

This one I solved initially by creating a new systemd-random-seed.service 
file in /etc, .including the default service in /usr/systemd/system/, but 
with an added RequiresMountsFor= entry.

That worked, but later on I found a note in the TODO to document the fact 
that .include was deprecated and to point people to *.d/*.conf files 
instead.  So I decided to try that.  The problem with /that/ was that the 
TODO reference (and various other *.conf references I found) weren't 
fully fleshed out, and as a systemd newbie I had some difficulty trying 
to figure out what they were talking about.

But after absorbing systemd for a few days I finally realized that not 
yet fully documented allusions I was seeing were to (paths like, for this 
service) /etc/systemd/system/systemd-random-seed.service.d/whatever.conf.  
And after adding a *.conf file there with the appropriate

[Unit]
RequiresMountsFor=

... entry, I was able to delete my custom service file and return to 
using the shipped service file, appending the appropriate *.conf line to 
the shipped configuration that way.

2b) I wasn't satisfied with the default gpm unit file config either, but 
by the time I got to that, I knew .includes were deprecated, and was in 
the process of trying to figure out what the allusion to *.d/*.conf was 
all about.

But once I figured that out for random-seed, I was quickly able to add
/etc/systemd/system/gpm.service.d/execstart.conf , with a customized 
ExecStart= line. =:^)


3) Systemd network config.

This one took me awhile too.  After the above and a few other minor 
tweaks to general systemd/journald/logind configuration[2], the big 
problem was that I was still networkless.  I didn't want to install 
network manager or whatever for a simple single-NIC static IP config, I'm 
still on systemd-208 as I've not figured out the systemd/dracut thing 
yet, so I don't have the 209+ networkd yet, and the various static-ip-
configuring network.service units I could find via google (plus one on a 
systemd bug on bugs.g.o) all used ip, from iproute2, which I had never 
installed as the old ifconfig and route from net-tools had to that point 
done all I needed it to do.

IMO this one's likely the biggest current problem for the gentoo masses 
who might contemplate a systemd switch, as my other problems are due to 
my decidedly custom config or are reasonably covered on the wiki.g.o 
systemd page, while there's very likely quite a few gentooers still on 
ifconfig/net-tools and unfortunately there's very little network 
discussion on the wiki page at all, let alone a nice step-by-step in the 
gentoo documentation tradition, covering ifconfig/net-tools users among 
others. =:^(

I'm actually quite disappointed that the gentoo/systemd folks don't have 
some sort of virtual/network-manager package or the like setup, with the 
various network.service and similar files for each one, and good coverage 
on the wiki.  Given all the noise around systemd, and the vital role I'd 
guess a working network config plays for most gentoo boxes, you'd think 
that would be well covered.  Oh, well...  At least it appears now to be a 
quite temporary problem, to hopefully be solved with the networkd in 
210/211/whatever-the-next-unmasked/unblocked happens to be.

Anyway, a quick emerge --pretend iproute2 said it wasn't going to pull 
any other deps I didn't already have, and I decided a single additional 
reasonably core package that I really probably should have installed 
years ago was after all a pretty small price to pay, so I finally just 
bit the bullet and installed it, and then setup the network@.service file 
using the ip command from iproute2.

Not so painful after all, but it'll still be nice when I get 210 or 211 
or whatever installed, and can hopefully use the new networkd solution 
instead of the still unofficial custom hack I've installed to deal with 
networking for the time being.

Which brings me up to current, with those three issues behind me.

The remaining two issues are:

4) Dracut and systemd

4a) Dracut's USE=systemd, enable or disable?

What does that do and given that the current systemd-less initr* I'm 
running now works well booting regardless of whether init=systemd, init 
(openrc), or bash (rescue shell), will whatever changes systemd in the 
initr* brings be worth it, or not?

Of course since you mentioned that you're running with systemd in your 
init, I'm hoping you can be of help on this one. =:^)

4b) The ongoing systemd-209+ file "musical chairs" and the havoc that 
plays with dracut, thus the current >=systemd-209 blockage in dracut.

It'd sure be nice to have this resolved one way or another, particularly 
so given that 209+ brings the hopefully more final networkd solution to 
#3 above, as well.  I was actually hoping that the multi-device btrfs 
root kernel command-line rootflags issue was resolved so I could just 
drop the initr* thing now and thus wouldn't have to worry about dracut 
any more, but as I posted in the earlier post, unfortunately not.

5) A couple remaining minor service failures:

5a) ntp.service is still failing, for some reason.

While I was running ntp on the old mobo before I upgraded and thus 
haven't ever really run this one without it, I've no reason to think this 
machine's hardware is /bad/ at keeping time, so ntp isn't critical.  But 
it'll be nice to find whatever's going on there and fix it.

Based on an aside-comment I read when researching something else, I 
already have one lead to check on this one -- the comment said systemd's 
privatetmp option doesn't play well with /var/tmp being a symlink to /
tmp, and that's what I have here (with /tmp in turn being tmpfs), and I 
think the ntp unit might use privatetmp, so...  But I've yet to confirm, 
and then I'll have to look for alternatives, so...

5b) On openrc, I have a custom user-bootclean service that cleans up a 
few stray user files at boot, that systemd created an attempted port for, 
except it's failing.  I've not investigated that one at all yet, but just 
as I write this it occurs to me that the problem might be yet another 
symlinked path mount-dependency issue, so I now have one lead to 
investigate on that one, too.

5c) bind/named (not failing but reduced functionality)

There's a gentoo bug about this as well.  Openrc's named/bind initscript 
has an optional chroot feature.  Systemd has both a legacy chroot support 
feature and a newer kernel-namespaces-based chroot replacement, but the 
shipped named.service file doesn't make use of either one.  If nobody 
else gets to that bug before I get comfortable enough with systemd to try 
to address it myself, I'll try to come up with a systemd-style solution, 
potentially using namespaces, to parallel the gentoo/openrc named 
initscript's optional chroot feature.

https://bugs.gentoo.org/show_bug.cgi?id=496198


Other than that... a couple positives already. =:^)

1) As mentioned in problem #1 above, systemd has actually surprisingly 
good nested mountpoint dependency resolution.  My setup is complicated 
enough I really appreciate that, and now that I'm "dual-booting" openrc 
and systemd <g>, I definitely miss that feature on openrc!  =:^0

2) Speed, WOW!

I've had openrc's parallel boot option enabled for years, but systemd 
really does run circles around it!  I'd guess a lot of that's due to the 
socket-based activation along with the mount dependency resolution such 
that services that are only dependent on each other due to that can still 
start in parallel, and particularly with socket-based dependencies, the 
otherwise depending service can often actually fully initialize if it 
gets to that point before the depended service is up, as long as the 
socket is already active and buffering any data the depending service 
might try to write to it.

The fact that it's all C based and mostly declarative, with near-zero 
scripting and far /far/ less forking, thus short-circuiting a good 
portion of what even openrc's semi-C-based solution does, certainly helps 
as well.

And of course the fact that I'm on SSD, where all those services starting 
in parallel doesn't trigger a seek-storm on the spinning rust that's not 
there to have a seek-storm on, doesn't hurt!  (Systemd has a read-ahead 
service to counteract part of the parallel-init seek-storm issue, but 
spinning rust will still be a bit of a bottleneck.  I had switched to SSD 
and my boot times improved, but in hindsight on openrc, only to a point, 
because the service-dependency on openrc then became the bottleneck.  
With systemd's socket-based-activation and the like killing /that/ 
bottleneck too, the speed of SSD **REALLY** shows it's stuff!  I had no 
/idea/!)

I have a feeling that once I get settled in, I'll be doing far more full 
shutdowns, since boottimes really /are/ trivial on systemd.  And looking 
to the future, if logind ends up doing for kde5 login times what systemd 
did for boot times...  WOW!  The idea of shutdown and startup cycles 
being so trivial one might as well just shut down when going to microwave 
a snack, since bootup and session startup's literally mostly the time 
waiting for the human to type in the password...


---
Notes:

[1] Predicting but not promising, even to myself:  I've discovered that I 
work best without deadlines or too specific goals, which only tend to 
demotivate and drive procrastination.  Left to itself, at some point the 
drive to find some stable conclusion normally takes over, at which point 
it's generally a done deal, concluded far more rapidly and with more 
finality than it would be, had I tried to artificially drive it myself, 
or let others try to drive it for me.

[2] General configuration changes, well enough documented that I didn't 
have much problem with them:

(a)/etc/systemd/system/default.target symlink pointing at multi-user, 
since I login at the CLI and have XSESSION set so I can startx, so systemd 
would quick complaining about the missing *DM service.

(b) /etc/systemd/journald.conf:  Storage=volatile at least until I figure 
out whether I want to keep syslog-ng or not, appropriate RuntimeMaxUse 
and RuntimeKeepFree values, ForwardToConsole=yes and TTYPath=/dev/tty12, 
so I get the traditional TTY12 console log.

(c) Setting NAutoVTs and ReserveVT= in /etc/systemd/logind.conf

-- 
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

Re: [gentoo-amd64] Systemd Was: Please get me straight about sysvinit vs. systemd [...]

[Phil Turmel]

On 03/13/2014 09:45 AM, Duncan wrote:

[trim /]

> Yeah, I'm actually replying from a systemd booted system, now.

Fabulous report!

[trim /]

> 2) Speed, WOW!

Ok, now I'm going to have to try this, too.

Thank you!

Phil

Re: [gentoo-amd64] Systemd Was: Please get me straight about sysvinit vs. systemd [...]

[Rich Freeman]

On Thu, Mar 13, 2014 at 9:45 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> 3) Systemd network config.
>
> This one took me awhile too.  After the above and a few other minor
> tweaks to general systemd/journald/logind configuration[2], the big
> problem was that I was still networkless.

I ran into this issue a while ago.  I ended up enabling dhcpcd so that
it was launched by my target.  Since I just wanted dhcp that worked.

There is probably a better solution, and perhaps more recent versions
of systemd addresses this issue (I set it up a good year ago I think).

More recently I had issues with an NFS share needed by a service and
struggling with how to express that dependency (since the unit for the
mount is created by a generator).  For whatever reason it was also
trying to mount the share before running dhcp (even though the share
was tagged with _netdev, and obviously nfs will depend on the network
in general).  I'm sure that is all related to my network issues in
general.

So, overall I'd say it is a bit rough around the edges, but quite
capable.  I really liked how systemd handles fileshares, at least in
principle.

Rich

[gentoo-amd64] Re: Systemd Was: Please get me straight about sysvinit vs. systemd [...]

[Duncan]

Duncan posted on Thu, 13 Mar 2014 13:45:14 +0000 as excerpted:

> 2b) I wasn't satisfied with the default gpm unit file config either, but
> by the time I got to that, I knew .includes were deprecated, and was in
> the process of trying to figure out what the allusion to *.d/*.conf was
> all about.
> 
> But once I figured that out for random-seed, I was quickly able to add
> /etc/systemd/system/gpm.service.d/execstart.conf , with a customized
> ExecStart= line. =:^)

Turned out that didn't work after all.  I thought the modified ExecStart 
line would replace the previous one and thought it was working but I 
guess I hadn't tried a console mouse yet, as that didn't work.  I was 
getting an error due to the two execstart lines where only one was 
allowed.

So I ended up dup-ing the entire gpm.service file from /usr to /etc and 
editing the execstart line as necessary.

> 5) A couple remaining minor service failures:
> 
> 5a) ntp.service is still failing, for some reason.

> Based on an aside-comment I read when researching something else, I
> already have one lead to check on this one -- the comment said systemd's
> privatetmp option doesn't play well with /var/tmp being a symlink to /
> tmp, and that's what I have here (with /tmp in turn being tmpfs), and I
> think the ntp unit might use privatetmp, so...  But I've yet to confirm,
> and then I'll have to look for alternatives, so...

That was it.  PrivateTmp doesn't like a symlinked /var/tmp.

So I reset /var/tmp to a directory and setup an fstab entry to bind-mount 
the /tmp tmpfs to /var/tmp as well.  Seems to be working at first blush, 
tho I haven't rebooted enough times yet to be sure there's no possible 
service dependency issues with it, but so far, it's working. =:^)


> 5b) On openrc, I have a custom user-bootclean service that cleans up a
> few stray user files at boot, that systemd created an attempted port
> for, except it's failing.  I've not investigated that one at all yet,
> but just as I write this it occurs to me that the problem might be yet
> another symlinked path mount-dependency issue, so I now have one lead to
> investigate on that one, too.

I haven't fully figured out why it's failing yet, but I think I can 
manage that with a tmpfiles.d entry.  And openrc supports tmpfiles.d as 
well, so if I setup such an entry, openrc will hopefully handle that too, 
and I can simply delete the /etc/local.d/*.start file that's failing.  
That should be the clean modern solution in any case.

But I'm too sleepy now to think straight, so I'll have to sleep on 
actually setting up and testing that one, lest I make a stupid mistake 
and end up deleting the entire user's homedir!

-- 
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

[gentoo-amd64] Re: Systemd Was: Please get me straight about sysvinit vs. systemd [...]

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/13/2014 03:20 PM, Duncan wrote:
> Duncan posted on Thu, 13 Mar 2014 13:45:14 +0000 as excerpted:
> 
>> 2b) I wasn't satisfied with the default gpm unit file config either, but by the time I got to
>> that, I knew .includes were deprecated, and was in the process of trying to figure out what
>> the allusion to *.d/*.conf was all about.
>> 
>> But once I figured that out for random-seed, I was quickly able to add 
>> /etc/systemd/system/gpm.service.d/execstart.conf , with a customized ExecStart= line. =:^)
> 
> Turned out that didn't work after all.  I thought the modified ExecStart line would replace the
> previous one and thought it was working but I guess I hadn't tried a console mouse yet, as that
> didn't work.  I was getting an error due to the two execstart lines where only one was 
> allowed.
> 
> So I ended up dup-ing the entire gpm.service file from /usr to /etc and editing the execstart
> line as necessary.

The correct way to do this is to create the file with contents like the following:

[Service]
ExecStart=
ExecStart=/usr/bin/gpm --my --options

The first ExecStart= line is a special case that tells systemd to unset the ExecStart parameter
completely so you can override it (instead of adding additional commands to run on startup).

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTI/FyAAoJELHSF2kinlg44e8QAJkLXFOr0Dm5KE2fSw01+2JA
bSY56oZXoRV1d3dlzM7bfCMDRFTPW4MDWv1+qb6AdH/7+tcb8H/pk2pEgbJtjBw3
4oK9uIJOcwYXPlOZU8bVcwQ70cXItlET7waok0h1u0o7WDDabVJi+HFKWMhpHEH1
JYM9HnTMx8qujfBxvbOHuOenBRZXpejqrVqo82UPmf2Ot8I+YS5+ACb7Qm3znqFu
02fbkb9nfbonqL3YDliqlv3MavCuHBQUCKGFtYtWoEjr0V+GGv+pqHgPzefWcT0F
EBMeCOA506bJHgHs+zam010BXlXt+9okr22S5Scvcv/vUIFu7X1AhCcgEfMkTY0o
VdFFq0uPncyH51Xnc2GD9+NzYY1ddJu6xA+ysLzJz2JMe0EXRJf67dl2Zp3i/Y48
FegAevX34VzilkkBeC4ArP1yPoOXQccy/+lyQT3Q1e5Xwp/65jX0/R8RxIycTIZz
vYEc1o84X56ZfvnfzPAr5m0dF9Rg6CUEx0RfDS9mI2VsnjsWOS6otvmfgfGqvBsq
aFnrakCh6ZEcvtd1j76yHy3U1rbhbC0kjuaEkjICvCWmNzeQJabqRN1w9Kam5dvF
Dureh8SSP3JtxpY7f945yBlmNqewYCjHrjg0BSTlaTXMMLIfrBf11QuEp7vS4s1l
7mNWKZP2+HqooMu7WCsJ
=ZfwZ
-----END PGP SIGNATURE-----

[gentoo-amd64] Systemd and journald Was: Systemd

[Duncan]

Jonathan Callen posted on Sat, 15 Mar 2014 02:21:38 -0400 as excerpted:

> The correct way to do this is to create the file with contents like the
> following:
> 
> [Service]
> ExecStart=
> ExecStart=/usr/bin/gpm --my --options
> 
> The first ExecStart= line is a special case that tells systemd to unset
> the ExecStart parameter completely so you can override it (instead of
> adding additional commands to run on startup).

Thanks.  I'll try that.

(I had thought about it as I had read something to that effect, but I 
only thought it applied to resetting accumulatives, and save for oneshot 
types, execstart must be single-shot, thus the problem in the first 
place.  But if you say it works... and this /will/ be my first time using 
the reset technique.)

But I'm rebooted with openrc ATM.  I needed to test if the /var/tmp bind-
mount to the tmpfs on /tmp would work in openrc or not (it did), and 
decided while I was at it that I needed a break from worrying about 
systemd, to get some other things done, including an emerge update on top 
of something I was familiar with, since I hadn't updated in over a week, 
due to focusing on getting systemd working.

Meanwhile, my next big systemd-land hump to get over is deciding whether 
I want to reactivate syslog-ng as my general purpose logger (with journald 
set storage=volatile, as I set that temporarily while I figured things 
out), or whether I want to unmerge syslog-ng and switch entirely to 
journald, setting storage=persistent.

If I switch to journald I'll have to seriously investigate filtering, as 
among other things I've one script that does an sudo every 10 seconds 
(IIRC), and while I have sudo's logging already configured separately, 
there's still an sudo-related pamd entry spit to syslog for each of 
those.  I have syslog-ng set to simply dump those but I noticed them in 
journald when I set it to output to tty12, too -- when that script was 
running the tty12 output was unusable as it was all but 100% noise from 
that.  I was glad I had storage=volatile set!

The other alternative, since that 10-second sudo is actually log related 
too (being effectively a /var/log/messages tail to superkaramba when I'm 
in X/kde), is to figure out how to do something similar using journald, 
without the sudo but without giving the graphical user unlimited log-
checking privs (sudo is setup to allow that one very specific command, 
not anything else, presently).

But regardless, I'll need to learn how to manage filtering in journald 
anyway; this is simply the first and most pressing reason to do so, not 
the only one.

And of course if I switch to journald I'll need to adjust that script 
anyway... ideally by configuring journald to write an unprivileged tail 
log (say 20 lines or whatever) to somewhere on tmpfs so all I'll need to 
do in superkaramba is to have it output that file directly, avoiding the 
script entirely.

IOW, now I have to basically repeat for journald the same process I did 
for systemd in general, figure out what it would take to convert to it, 
and whether I actually want to, or whether I'd prefer to keep journald 
set to storage=volatile and simply forward to syslog-ng, mostly keeping 
the existing (somewhat advanced for a single host) syslog-ng 
configuration in place.

I'm thinking about just punting for now, activating syslog-ng pretty much 
with the existing config (changed my existing syslog-ng filters as 
necessary to deal with any systemd specific logging) in systemd, and 
keeping journald set storage=volatile.

But that's why I'm taking a rest from systemd ATM, back on openrc, to 
study journald at my leisure now that I have systemd itself more or less 
setup and am thus familiar with /its/ workings, and then give my 
subconscious time to weigh the syslog/journal options and come to its own 
decision, before I make the conscious decision and get down and dirty in 
the config, implementing it.

Meanwhile, with a bit of luck gentoo/systemd and the various upstreams 
will work thru the systemd-209+ networking and dracut related issues, and 
I'll have a more permanent networkd based systemd-network service config 
to replace my current temporary network.service hack, by the time I get 
the journald stuff worked out and hopefully switch over to systemd more 
or less permanently.

-- 
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

Re: [gentoo-amd64] Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Canek Peláez Valdés]

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