-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/09/2016 01:03 AM, Kent Fredric wrote: > On 9 February 2016 at 18:27, Anthony G. Basile > <bluen...@gentoo.org> wrote: >> all the vitriolic attacks i get about eudev come from the gentoo >> community. outside of this community i get praise. > > > In case my earlier messages stating a desire to exercise much > caution gave the wrong impression, I just want to state for the > record I think its awesome eudev exists, and I think its awesome > other distro's are using it. > > Just when it comes to "Change the defaults", I want to be certain > about the path we're setting ourselves up for on this very > important component, because here, a change of defaults paves a > broader path for eudev to be a potential leading competition to > systemd. > > Because if we do that, I feel we must be so sure of ourselves that > eudev can be a profitable choice for at least a moderately long > term, even in the event we get no more support from the systemd > codebase. > > Having it in tree and having users who know what they're doing > being able to choose their own risk factors and say "yeah, eudev is > the right choice for what I'm doing" is one thing. > > But stating implicitly that "Hey, this is the default", this needs > to be the *best* recommendation we can make based on all the other > factors and other defaults Gentoo uses. > > Because new users *will* be inclined to pick the default, and > *existing* users of the *current* default are likely to see the > default change, and reason "well, the default has changed, so the > new default is the new best thing", and will be inclined to > switch. > > And the worst thing we could have is a combination of bad defaults > that leads new users to have a poor first experience because they > used all the default recommendations, and their system made magic > smoke instead of booting. > > In short, to change *this* default, it seems pertinent that we > *know* that the change we're making *is* better and a more reliable > long-term choice than the *current* default, and if there is *any > reasonable doubt*, we should delay changing until that reasonable > doubt is expunged. >
I can understand your concerns wrt defaults, but I don't know very many Gentoo users that stick to defaults. Part of what draws people to Gentoo is the very fact that you can customize every layer of the stack, from kernel to user-facing GUI applications. The default service manager is OpenRC, and it works great with eudev. I've not had a single issue with eudev since I started using it. It accepted any of the rules I had written for older udev before systemd swallowed it, and I just don't have any issues. I can't think of any reason eudev can't be a drop-in replacement, at least at the current tim e. sys-fs/udev is only for systems that aren't already running systemd, as "!sys-apps/systemd" is in sys-fs/udev's ebuild. Given that systemd+eudev is the only possible combination I can think of that may cause problems, I don't think changing the default from sys-fs/udev to sys-fs/eudev is a problem, at all. The default is currently systemd-udev, and udev's been mostly unchanged since systemd swallowed it, aside from the push for kdbus that the systemd team is pushing the kernel guys to implement. Once *that* happens, eudev will need to either use that interface to maintain "full" feature parity, or fork off on its own. Given that the push for kdbus is more a political API move than anything, I can see eudev sticking to the current interface and working just fine. The kdbus switch is completely internal and people actually using udev won't notice much of anything except the necessity for a new kernel version. If current users of udev end up being required to switch to systemd in order to retain udev, then there will most certainly be more interest in eudev and its development. I see only positives for this. I've used OpenRC and eudev since I started using Gentoo in 2012. I don't predict switching from udev to eudev being difficult for anyone running something like, say, runit, since it's really a drop-in replacement. *after* kdbus is implemented in udev, *maybe*, but unlikely since it's something really low level and there's no way the systemd team would require big changes on the user/admin facing side of things unless you aren't already running systemd. Their goal is to make it so easy that people don't have to inspect the internals, which gives them free reign to start conflicts with other distros and forks. Have there been any real cases of issues switching between the two? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWud1gAAoJEAEkDpRQOeFwhXcP+gK9gMmk+CMQ8gRJbJcpHTot nKAL4WotZc+st4TvyBSY1PklVT2s5GEQAfsHW4tvCYZAMQxaCceerWnCgJOhJynv 8fxxTaIkSivO0y6Q7PPEqFrnc3AhtQG8GWvDOUosVSX2xlTQ6kLXV/kjaS4vqd+i K+G095gpn+tPKLsCuBS6+nHRYXJSEDJBL6b1cK0S37XNjBCaMAOo4kW3Qp6EEWAO +oO1HH44gVQZdqDjdR/5J45zMeg7Y9KrzvZkD8QWbzAhui3X2Z/GsXpmnKw4vH2u 3dbXfFcPVZDJQ8PeJMTevglO8Weh6esoQTj83xjvY1luOwFn6Rvc2rPyulPHS+cJ istKk1H1OvjgN8lK/3kAZ2fUAt2SFFvJIwFe0rNHzvVOv93sJcFhbCtrQIhqbvkf kkBdSVHCDpxbYWtMvLIjbd73qsOjpvhTF+0MGMZlkAAinGoIFp/o4RqD4pqre0Nr lmdGdmC/hufFTIf6ROEnCU7tkK6lWjzXN110E/Lekf8QEFZgjihFi0q+rkv7gi0c B24fealTeqg1CFd2CrF5T/n6XG0FWovF6hOChg8OfN203pYRBSQgvFH6c9Kt4PP1 /CbVa0CGfuCNkDgQv10jwL9wQ+dNDKpwQC3r8CMPdeUYlqWZnRtz4/P8K0FjjUJs 8txys/VjkIqxdIuR9b10 =dov4 -----END PGP SIGNATURE-----
