:: Re: [Dng] What to do with udev? Som…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Martinx - ジェームズ
Fecha:  
A: Jude Nelson
Cc: dng@lists.dyne.org
Asunto: Re: [Dng] What to do with udev? Some ideas...
Hi Jude,

One thing that matters most (for me), is that you're here, working on this,
with Devuan team. This is very important!

Also, when talking about eudev, we have this:


q: plans when udev becomes systemd-only ? (after kdbus merge):

https://github.com/gentoo/eudev/issues/95


I can see why ("the reasons / motivation") the distros all over the globe,
are being forced to use systemd / dbus (on servers!!), and udev is one of
those (biggest) reasons... Otherwise, if we have a high quality udev
replacement, then, who cares about systemd? With a drop-in replacement for
udev, we can easily kick systemd! I know that there are that logind thing,
the gnome drama and etc but, first things first. :-P

>From what I'm seeing, eudev might hit a dead-end, sooner or later, making

it harder and harder to build a systemd-free Linux distro. I mean, when
system-udev enforces systemd=PID1, then, sysvinit-core|upstart will be
dead. Right?!

Unless, eudev start walking on its own path (Feasible? Viable?)...

So, vdev (and the proposed alternatives, including plain static /dev),
seems the way to go in the long run, for a systemd-free Linux distribution.


The question that remains: which path is a "way to go"?!

1- build a new "udev", lets say, vdev? or;

2- stick with eudev and, "after kdbus got merged" (when systemd-udev
becomes useless without systemd = PID1), eudev will follow its own path,
forever...


If we stick with "2", then, I think that it worth putting huge efforts into
eudev, to make it a high quality piece of software. Including a big
crowdfunding campaign everywhere! Of course, if desirable.

Nevertheless, I'm must confess, I'm still divided... All of this work,
isn't a waste of time and effort? I mean, systemd seems to be making the
life easier for a lot of projects! Even Enlightenment devs (I'm there on
e-devel list) are talking about the huge benefits of systemd, that it will
make E-Development easier, for example, when using it with Wayland/DRM,
also, `enlightenment_start` binary will not be required anymore (when with
systemd), less code for E team to maintain, and etc...     :-)        :-/
    :-)       +_+


So, are we going to succeed (yes, we can do this)? Or this is a waste? Lets
not lie to ourselves... I know we can build a systemd-free distro, I know
that... But, honestly, I like the ideas behind systemd (new VT code
(consoled), native multiseat support, CGroup Process that can not "scape"
systemd) but, its implementation / architecture creeps the heel outta me!
Also, the attitudes of systemd developers makes me sick. They have no
"social skills" and a terrible bug handling. And I don't like to be forced
to use this, or that. Choice is always important, but too many choices are
also a bad thing.

Cheers!
Thiago

On 30 December 2014 at 01:45, Jude Nelson <judecn@???> wrote:

> Hi TJ,
>
> I totally agree. I'm creating vdev to be a replacement for udev in the
> long term, but it will need a *lot* of testing before I'm comfortable
> recommending it as the default device manager in *any* distribution.
>
> That said, I hope to have an alpha package in a few days. It will be able
> to run side-by-side with udev/eudev/mdev/static dev.
>
> Jude
> On Dec 29, 2014 3:10 PM, "T.J. Duchene" <t.j.duchene@???> wrote:
>
>> If I might offer my two cents, I'm afraid that I must agree. Don't get
>> me wrong, the vdev proposal is quite interesting, but for the first
>> release, I believe the best route is to stick with building udev apart from
>> the systemd source tree. To do it any other way will probably cause
>> software issues that we do not presently have the developer resources to
>> solve - especially if we are already going to be busy trying to compile or
>> provide metadata for all the packages in Debian Jesse.
>>
>> On Fri, Dec 26, 2014 at 2:05 AM, dima <dima@???> wrote:
>>
>>>
>>> You can't just switch to vdev, because many packages depend on libudev.
>>> Only udev and eudev provide it.
>>>
>>> eudev is the only realistic option right now, because it's a drop-in
>>> replacement. Moreover, it's the only udev alternative with feature-parity.
>>>
>>> By the way, I'm not sure whether vdev is ready for the prime time.
>>>
>>> On Thu, 25 Dec 2014 22:26:49 -0500
>>> "Martinx - ジェームズ" <thiagocmartinsc@???> wrote:
>>>
>>> > Guys,
>>> >
>>> > I'm wondering here about what to do with `udev`, which is `systemd` in
>>> > fact...
>>> >
>>> > What about this:
>>> >
>>> >
>>> > 1- Rename current `udev` package to `systemd-udev`;
>>> >
>>> > 2- Add `vdev`;
>>> >
>>> > 3- Add `eudev`;
>>> >
>>> > 4- Add `mdev`;
>>> >
>>> > 4- Create a new Metapackage called `udev`, that will Depends on `eudev
>>> |
>>> > vdev | mdev | systemd-udev`.
>>> >
>>> >
>>> > This will be very similar to the new `init` Metapackage on Jessie, that
>>> > Depends on `systemd-sysv | sysvinit-core | upstart`.
>>> >
>>> > What do you guys think?
>>> >
>>> > Also, I would like to know more about the quality of `eudev` and if it
>>> > worth keeping it, since `systemd` developers will remove its "netlink"
>>> > support (am I right)? Then, `systemd-udev` will depends on `systemd` as
>>> > PID1 in the future (through KDBUS, if I'm not wrong), making it very
>>> hard
>>> > to keep `eudev` up to date. Source:
>>> >
>>> http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
>>> >
>>> > I would like to evaluate `vdev` soon as possible.
>>> >
>>> > Best!
>>> > Thiago
>>>
>>>
>>> --
>>> Dima Krasner <dima@???>
>>> _______________________________________________
>>> Dng mailing list
>>> Dng@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>>
>>
>>
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>