Gentoo Announces Eudev Project -- Its Udev Fork

[ryao]

To complete the version:


Is that what eudev was all about? Running newer udev on very old kernel release?

It is one of the things that the notion of compatibility covers. Anyway, none of these kernels are particularly old. 2.6.32 is a LTS kernel that is used in RHEL6.

[ninez]

So if I understand this right in systemd-devs pov if you wanted to use only udev you have to compile whole systemd at the same time. This would be ok binary distros like ubuntu and tho upstart, but not in source distros like gentoo. If I would want to use only udev with gentoo I don't want to compile something that are not needed, it's just a waste of time and resources of my own computer. And what Hubbs suggested with his patches is to add two configure flags that make possible to compile only udev.

that's not true though. You don't have to compile all of systemd to get udevd and friends (but unfortunately, you would still need the systemd sources, which includes things you don't need). with a few quick modifications, you can compile them independently; http://www.freedesktop.org/wiki/Soft.../MinimalBuilds it looks fairly simple to do, create a couple of (empty) .pc files, use PKG_CONFIG_PATH to point to them, then you can compile each component with 'make udevd' (etc).

anyway, that isn't really the crux of why they are forking from what i gather, just one issue (that sounds like it can already be easily resolved anyway and is already documented).

[ryao]

that's not true though. You don't have to compile all of systemd to get udevd and friends (but unfortunately, you would still need the systemd sources, which includes things you don't need). with a few quick modifications, you can compile them independently; http://www.freedesktop.org/wiki/Soft.../MinimalBuilds it looks fairly simple to do, create a couple of (empty) .pc files, use PKG_CONFIG_PATH to point to them, then you can compile each component with 'make udevd' (etc).

anyway, that isn't really the crux of why they are forking from what i gather, just one issue (that sounds like it can already be easily resolved anyway and is already documented).

It is true that you can patch the build system to build udev independently, although that is a fragile hack. The Gentoo developers maintaining udev were not willing to maintain that outside of upstream and systemd upstream was not willing to do that. You could consider things from the perspective of what systemd's developers did and what the Gentoo udev maintainers did. Many of us did not like the end result and the only way that both groups (i.e. the existing maintainers and the rest of us) could be happy was for us to fork. Honestly, the existing Gentoo udev maintainers do not like having another udev in the tree, but their unwillingness to patch systemd udev to accommodate what the rest of us wanted necessitated it.

At this point, we have found plenty of decisions that the systemd developers made that we do not like, so the purpose of the fork has expanded beyond just patching a few things. In particular, we want to improve support for non-GNU userlands and tool chains, enforce peer review on all changes made and provide proper documentation of changes. That is in addition to fixing bugs that involve system configurations that Fedora does not use and making the build system simpler and more flexible. For the record, systemd's developers do not want any of this because their priorities differ from ours and that is okay.

[waitejasoe]

the systemd crowd there was a promise to keep udev independent enough for others to use it without systemd.

[GreatEmerald]

Yea, overall it looks like there are good reasons for a fork like that. Both projects are going different ways. I only hope that they will maintain a good relationship with one another to avoid any unnecessary duplicate work.

[RealNC]

I only hope that they will maintain a good relationship with one another

lol. You haven't been reading this thread at all, did you. As it stands, the systemd devs are laughing about the eudev devs, treating them like the village idiot. Yes, lots of friendship and good relations.

[GreatEmerald]

That tends to happen at the start of forks. After a while they get to see the benefits of cooperation, and then everyone wins.

[bnolsen]

The two projects have orthogonal priorities. eudev favors long term compatibility as a modular component while systemd favors the single tree approach where support for older versions of components is pointless. Both have merits.

I'll take the modularity any day. I never quite understood the massive drive to shave absolutely every ms off boot time. Strangely enough since Arch switched over to systemd the new boot system actually seems slower to me. I've been having problems with systemd hanging and blowing out cpu, etc. It hasnt' been exactly been a smooth transition.

[crazycheese]

I'll take the modularity any day. I never quite understood the massive drive to shave absolutely every ms off boot time. Strangely enough since Arch switched over to systemd the new boot system actually seems slower to me. I've been having problems with systemd hanging and blowing out cpu, etc. It hasnt' been exactly been a smooth transition.

Modularity is one thing. Workaround over workaround is another one. Software needs to be rewritten from scratch over period of time to fix architectural problems.

[ninez]

It is true that you can patch the build system to build udev independently, although that is a fragile hack. The Gentoo developers maintaining udev were not willing to maintain that outside of upstream and systemd upstream was not willing to do that. You could consider things from the perspective of what systemd's developers did and what the Gentoo udev maintainers did. Many of us did not like the end result and the only way that both groups (i.e. the existing maintainers and the rest of us) could be happy was for us to fork. Honestly, the existing Gentoo udev maintainers do not like having another udev in the tree, but their unwillingness to patch systemd udev to accommodate what the rest of us wanted necessitated it.

Thanks for the clarification ryao I knew it was at least _possible_ to build them separately, although since i use systemd - i never bothered to try / needed to do that. My feeling is that the systemd guys want systemd to be 'the one ring to rule them all', it's just too bad that in some ways they seem to be a little short-sided on why certain people would need udev to be more compatible / independent (of systemd).

At this point, we have found plenty of decisions that the systemd developers made that we do not like, so the purpose of the fork has expanded beyond just patching a few things. In particular, we want to improve support for non-GNU userlands and tool chains, enforce peer review on all changes made and provide proper documentation of changes. That is in addition to fixing bugs that involve system configurations that Fedora does not use and making the build system simpler and more flexible. For the record, systemd's developers do not want any of this because their priorities differ from ours and that is okay.

this... yes, i had assumed/imagined right from the start that it was likely use cases similar to the one's you've listed above - that ultimately caused the fork. (well, and the systemd maintainers disregard / causing breakage).

anyway, best of luck with eudev - i am sure people will find it useful.

I'll take the modularity any day. I never quite understood the massive drive to shave absolutely every ms off boot time. Strangely enough since Arch switched over to systemd the new boot system actually seems slower to me. I've been having problems with systemd hanging and blowing out cpu, etc. It hasnt' been exactly been a smooth transition.

are you still using sysv-compatibility?? - i've heard of that causing issues, in at least some cases. Have you looked into what is screwing you up at boot?? Archwiki has an article on this;

https://wiki.archlinux.org/index.php...d#Optimization

I know someone else whom had initial issues with startup, it turned out to be a very minor thing to fix.

Myself, i didn't run into any problems with systemd. When i was using sysv + e4rat - i thought booting was fast (vs. not using e4rat), then i ditched them both for systemd and instantly my boot time was reduced - then i optimized it a bit and shaved off another 2/3 seconds. i'm not overly concerned about boot time - but i don't mind cutting it in half, either