On Tue, 16 Feb 2016 20:14:03 +0100
Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote:

> Alexis Ballier schrieb:
> > I also fail to see how udev using a new linux ipc would make it require
> > systemd. Quoting Lennart:
> > "You need the userspace code to set up the bus and its policy and handle
> > activation. That's not a trivial task. For us, that's what sytemd does
> > in PID 1. You'd need to come up with an alternative for that."
> >
> > If it's just that, it's not limited to udev, but anything using
> > kdbus/bus1, and would mean openrc/${favorite init system} will have to
> > do the same thing anyway. But again, almost 2 years is extremely
> > old considering all the flux that has been around kbus.  
> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel 
> IPC system comes next. But if upstream udev makes use of the systemd 
> userspace interface to the kernel IPC system, then OpenRC would have to 
> implement the same interface in order to have working udev.
> Also given the close relationship between systemd and udev, there is no 
> guarantee that supporting other users of kdbus/bus1 will make udev 
> automagically work. As these two are released together, there is no 
> reason to have a stable, public API between them.

This all is going into some bickering nonsense and noise made by
systemd haters just to feed their troll, FUD and whatever else they
made around here.

So, yes, we should definitely switch to semi-maintained,
semi-documented fork made plainly of systemd hate. Because certainly
project that is created plainly for political reasons is better.
Because it will certainly be technically better if people have to focus
on copying regular udev maintainers and reworking their changes to keep
them working on forked codebase.

And after all, as someone said, this will give eudev proper testing.
Because why default to something tested and working when you can throw
your random fork on our users. After all, if we force them to use it,
they will eventually start co-maintaining it, and it will no longer be

Best regards,
Michał Górny

Attachment: pgp9m0EQxaIJ1.pgp
Description: OpenPGP digital signature

Reply via email to