Mailing List Archive

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

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

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

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.

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

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

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

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

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

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

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