[arch-general] Gentoo udev fork w/o systemd
I want to bring to your attention that Gentoo is working on a udev fork called eudev that will - respect the Unix philosophy - be POSIX-compliant and get rid of glibcisms - have no unnecessary dependencies (systemd, kmod) - support separate /usr http://thread.gmane.org/gmane.linux.gentoo.project/2262 with the goal to make it default for Gentoo in the future, along with OpenRC. I know from past discussions on this mailing list that not everybody in the Arch community is happy with systemd. They are looking for contributors and this is an opportunity for cross-community collaboration. Regards, -J
I normally wouldn't respond to trolls on this list and really I'd rather have seen this post be moderated straight to where it belongs -- /dev/null. However.... On Mon, Nov 19, 2012 at 2:31 PM, Jérôme Bartand <moijerob@gmail.com> wrote:
I want to bring to your attention that Gentoo is working on a udev fork called eudev that will
- respect the Unix philosophy
Sorry, perhaps you could explain how current udev (udev, not systemd) defies this, and why it's relevant for a small set of binaries and library which only serve to handle uevents from the kernel. Please keep in mind when writing your response that udev is still entirely useable without systemd. No, Lennart's infamous post exclaiming how "standalone udev has no future" is not an indication that it's going to break any time soon.
- be POSIX-compliant and get rid of glibcisms
Why does this matter? Do you have any concept of what POSIX defines and doesn't define? udev is a piece of software which is intimately involved with the Linux kernel, and necessarily must be, to accomplish its goals. Furthermore, the "glibcisms" used by udev has nearly wholly been adopted by the other popular libcs -- eglibc, uclibc, and musl.
- have no unnecessary dependencies (systemd, kmod)
You seem to have this backwards. systemd relies on udev, not vice versa. kmod is a real thing which solves a real problem. Going back to module-init-tools causes unsolvable regressions which were addressed by the implementation of a library which userspace has been lacking for years, and which was developed after much talk at the Linux Plumbers conference a year ago. Jon Masters and Rusty Russel both strongly support the implementation of libkmod, as do other people who are well known in low level userspace and kernel space as well. Feel free to point out why this is a bad idea.
- support separate /usr
Please explain why udev makes this a non-reality. A properly working separate /usr without an initramfs is a unicorn. It's been broken long before udev did whatever you think it did to break it. It's hopelessly pointless to do, and if you're still bent on it, the modern initramfs implementations support mounting a separate /usr from early userspace, and cleanly unmounting it on shutdown. Do you have any concept of what the problems associated with this are? You can't possibly, or else you wouldn't be parroting this tripe.
Maybe you should have pointed out this thread: http://gentoo.2317880.n4.nabble.com/udev-ng-Was-Summary-Council-meeting-Tues... Which really only points out how flawed their non-existant plan is, and how much resistance they're getting to the idea. I can only assume you haven't actually read it.
with the goal to make it default for Gentoo in the future, along with OpenRC. I know from past discussions on this mailing list that not everybody in the Arch community is happy with systemd. They are looking for contributors and this is an opportunity for cross-community collaboration.
Feel free to join them. Your sinking ship awaits you.
[2012-11-19 16:30:10 -0500] Dave Reisner:
I normally wouldn't respond to trolls on this list and really I'd rather have seen this post be moderated straight to where it belongs -- /dev/null.
And you'd normally be right. I've let this message through because it's short, borderline troll but otherwise informative. Now you've turned that thread into a flamewar. Well done. -- Gaetan
On Mon, 19 Nov 2012 20:31:40 +0100 Jérôme Bartand <moijerob@gmail.com> wrote:
I want to bring to your attention that Gentoo is working on a udev fork called eudev that will
- respect the Unix philosophy - be POSIX-compliant and get rid of glibcisms - have no unnecessary dependencies (systemd, kmod) - support separate /usr
http://thread.gmane.org/gmane.linux.gentoo.project/2262
with the goal to make it default for Gentoo in the future, along with OpenRC. I know from past discussions on this mailing list that not everybody in the Arch community is happy with systemd. They are looking for contributors and this is an opportunity for cross-community collaboration.
Regards, -J
This has already been discussed on the forums, in the General Linux section: https://bbs.archlinux.org/viewtopic.php?id=153063. Please, keep the eudev-related issues there and do not pollute this ML, as I don't want to see 300 emails in my mailbox tomorrow... -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
[2012-11-19 15:37:06 -0600] Leonid Isaev:
This has already been discussed on the forums, in the General Linux section: https://bbs.archlinux.org/viewtopic.php?id=153063. Please, keep the eudev-related issues there and do not pollute this ML, as I don't want to see 300 emails in my mailbox tomorrow...
Just don't reply then. When are you going to get that your message contributes to the 300... ? -- Gaetan
On 11/19/2012 09:31 PM, Jérôme Bartand wrote:
I want to bring to your attention that Gentoo is working on a udev fork called eudev that will
- respect the Unix philosophy - be POSIX-compliant and get rid of glibcisms - have no unnecessary dependencies (systemd, kmod) - support separate /usr
I find this link to be more useful: http://cdn.memegenerator.net/instances/400x/30483828.jpg
with the goal to make it default for Gentoo in the future, along with OpenRC. I know from past discussions on this mailing list that not everybody in the Arch community is happy with systemd. They are looking for contributors and this is an opportunity for cross-community collaboration.
Regards, -J
-- Ionuț
On Mon, Nov 19, 2012 at 8:31 PM, Jérôme Bartand <moijerob@gmail.com> wrote:
I want to bring to your attention that Gentoo is working on a udev fork called eudev
Having read through their discussions, it seems that the main two things they would like to change is to be able to build udev without building systemd (this does of course not change the resulting code, but saves time if you have to build everything locally) and to make the dependency on kmod optional (this might make sense if you don't have module support in your kernel, but I think the difference would not be measurable in any way). Both of those things should be achievable by (trivial) patches to the buildsystem, so it is not clear to me why a full fork was necessary. Moreover, if you look at the commits that went in so far, most of it is shuffling code around without any functional change, except making back/forward porting of patches really hard... -t
On Tue, 20 Nov 2012 00:54:31 +0100 Tom Gundersen <teg@jklm.no> wrote:
Having read through their discussions, it seems that the main two things they would like to change is to be able to build udev without building systemd (this does of course not change the resulting code, but saves time if you have to build everything locally) and to make the dependency on kmod optional (this might make sense if you don't have module support in your kernel, but I think the difference would not be measurable in any way).
Odd, my take was that the main goal was trying to bring back a separate /usr. I did post to the arch-general mailing a while back about why the FSF is wrong on there being no need for a seperate /usr and putting everything in there without static core binaries in a smaller root is less reliable. I now wonder if that is because it was broken anyway and lennart gave a seemingly reasonable justification that may reduce the complaints. The other reason I noted was less dependency on upstream decisions or breakages and this one may have been the debian list but keeping dbus off servers.
On Tue, Nov 20, 2012 at 1:07 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
Odd, my take was that the main goal was trying to bring back a separate /usr.
There is nothing to be done in udev for this (just have a look in the eudev git repo; there are no commits "fixing" separate /usr), so that part of the discussion is likely based on a misunderstanding.
keeping dbus off servers.
No version of udev uses dbus, so that is not relevant. -t
On Mon, Nov 19, 2012 at 7:07 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
On Tue, 20 Nov 2012 00:54:31 +0100 Tom Gundersen <teg@jklm.no> wrote:
Having read through their discussions, it seems that the main two things they would like to change is to be able to build udev without building systemd (this does of course not change the resulting code, but saves time if you have to build everything locally) and to make the dependency on kmod optional (this might make sense if you don't have module support in your kernel, but I think the difference would not be measurable in any way).
Odd, my take was that the main goal was trying to bring back a separate /usr.
I did post to the arch-general mailing a while back about why the FSF is wrong on there being no need for a seperate /usr and putting everything in there without static core binaries in a smaller root is less reliable. I now wonder if that is because it was broken anyway and lennart gave a seemingly reasonable justification that may reduce the complaints.
The other reason I noted was less dependency on upstream decisions or breakages and this one may have been the debian list but keeping dbus off servers.
The issues with a separate /usr were internal gentoo ones. Their initramfs tool is not yet capable of mounting it, and their libkmod package installed files to /usr (which has since been changed). That's also the reason they removed the libkmod and libblkid support, but since the standalone tools like modprobe still link against those libraries there was no actual change in dependencies - just a few hundred extra processes spawned at boot. Note that they're rolling back those changes now, and are just going to make them "optional" dependencies instead (but they will still be required, you can just fork processes instead of calling library APIs). They also dropped the goal of "POSIX compatibility", and are just aiming to reduce "gnu-isms" instead even if it means bringing back race conditions. Gentoo is still using udev v171, and lots of the people assumed that they couldn't be using up-to-date udev versions without systemd as init. However, Arch managed to do that without any trouble, so it's another non-reason for the fork. Also, please keep in mind that this is not (yet) an official Gentoo project, it's just a project done by a Gentoo developer so he gets to use their infrastructure. It is definitely not supported by all Gentoo developers (Greg KH being one of the vocal opponents, along with several other core developers).
The issues with a separate /usr were internal gentoo ones. Their initramfs tool is not yet capable of mounting it, Wrong. And the actual problem are the users that do not want an initramfs -
and their libkmod package installed files to /usr (which has since been changed). That's also the reason they removed the libkmod and libblkid support, but since the standalone tools like modprobe still link against those libraries there was no actual change in dependencies - just a few hundred extra processes spawned at boot. Also a misunderstanding - the eudev fork was more of a research project. Part of figuring out how things work is removing the things that are not essential - that doesn't mean there's an intent to permanently remove
On 11/20/12 08:48, Daniel Micay wrote: [snip] things booted without one the last few decades, why add some machinery now that doesn't improve anything? (I mean, we could boot before, so what's the *feature* we gain ?) the capability.
Note that they're rolling back those changes now, and are just going to make them "optional" dependencies instead (but they will still be required, you can just fork processes instead of calling library APIs).
They also dropped the goal of "POSIX compatibility", and are just aiming to reduce "gnu-isms" instead even if it means bringing back race conditions. "They" being a few people with wildly varying goals. Making things build-able without a full gnu toolchain is just a good idea to some and insanity to others ...
Gentoo is still using udev v171, and lots of the people assumed that they couldn't be using up-to-date udev versions without systemd as init. However, Arch managed to do that without any trouble, so it's another non-reason for the fork. It's the regressions that force us to an old version, not the systemd stuff that's screwed on for no apparent reason. Same reason debian is currently "stuck" with the last known-good version.
Also, please keep in mind that this is not (yet) an official Gentoo project, it's just a project done by a Gentoo developer so he gets to use their infrastructure. It is definitely not supported by all Gentoo developers (Greg KH being one of the vocal opponents, along with several other core developers).
Thanks for pointing this out - this is a few people scratching an itch, and I think none of us wants to take over the world at the moment :)
On Tue, Nov 27, 2012 at 12:35 PM, Patrick Lauer <patrick@gentoo.org> wrote:
And the actual problem are the users that do not want an initramfs - things booted without one the last few decades, why add some machinery now that doesn't improve anything? (I mean, we could boot before, so what's the *feature* we gain ?)
Lots of stuff will silently fail, there is a list here: <http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken>. In most cases the failures are not serious enough that people care (such as locale handling failing in early boot), but they are still failures. Anyway it really has nothing to do with systemd or udev, both of which work fine without an initramfs and with a separate /usr.
Gentoo is still using udev v171 [...] It's the regressions that force us to an old version,
Is upstream aware of your bugs? I'm not currently aware of any open udev bugs, so if you still have problems with the latest version please let us know on the udev or systemd ML. Cheers, Tom
Am 20.11.2012 01:07, schrieb Kevin Chadwick:
Odd, my take was that the main goal was trying to bring back a separate /usr.
They believe that the problem is that udev refuses to work with /usr not mounted. They also believe the problem to be "solved" by just removing the test. They do not even remotely understand why separate /usr is broken, and that "fixing" this problem eventually results in installing everything to / and leaving /usr mostly empty. They also "fixed" udev by removing blkid support, although util-linux deprecated the "blkid -o udev" option a while ago. The general consensus seems to be that they have no idea what they are doing (see the statements of Greg K-H or Kay Sievers on the topic). I will buy some popcorn and watch with amusement when the fork dies.
participants (10)
-
Daniel Micay
-
Dave Reisner
-
Gaetan Bisson
-
Ionut Biru
-
Jérôme Bartand
-
Kevin Chadwick
-
Leonid Isaev
-
Patrick Lauer
-
Thomas Bächler
-
Tom Gundersen