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