Hi Thiago,

I'm glad to be here :) I'm grateful for the community's feedback on vdev!

Regarding the path to take, I think going with (2) for now while keeping
option (1) on the table is probably the best strategy. Unlike vdev, eudev
is ready to go today, and already serves as a drop-in replacement for udev.

Why have option (1) at all? The reason is that I don't know what the
systemd developers have planned for udev, but it is clear that at any given
moment they could intractably entangle udev, systemd, and kdbus, and make
life a lot harder for eudev as an unintended side-effect. Lennart has
warned as much, to be fair, but as far as I know there is no timetable and
no ETA for when this entangling will happen (it could be tomorrow, for
example). This concerns me because it is my understanding that eudev is a
"shadow fork" of udev--that is, eudev is as successful as it is in part
because the developers can merge most new features from upstream udev with
little effort, freeing them to focus on doing the legwork to ensure that
eudev builds separately from systemd. However, future entanglements with
systemd and kdbus could make this much harder, to the point that eudev has
no choice but to diverge from udev, thereby increasing the maintenance
burden considerably. This precarious situation is one motivating factor in
my creating vdev--we must have a drop-in replacement for udev beyond the
influence of the systemd developers that's ready to go in case maintaining
eudev suddenly becomes intractable.

The bigger motivating factor in vdev, however, is that like you I see that
systemd offers a lot of compelling features that I would love to have, but
only if having them does not introduce unpalatable OS designs. One
important feature--the feature vdev addresses--is providing a way for
unprivileged programs to access privileged files, such as device nodes,
according to higher-level policies. While I think this is a wonderful
feature since it facilitates multi-seat and lets programs like X and
Wayland run without privileges, systemd's logind solution requires programs
to depend on its dbus interface (leading to undesirable tight coupling).
By contrast, vdev's strategy is to equivocate about device nodes via the
filesystem, so programs benefit without having to be aware that they are
interacting with vdev at all.

Another useful feature to me is reliable service state tracking. While I'm
happy that systemd addresses this problem, I'm not happy that I have to
effectively cede control of cgroups to systemd to do so, and couple any
future cgroup interactions to systemd's dbus API. I have a partial
solution to this, though--I've written a filesystem called runfs [1] that
has the property that once a process dies, runfs automatically unlinks all
of the files it created in it. This way, I can start a daemon and have it
write a PID file to runfs, and then I can check to see if the daemon is
still running simply by stat'ing the PID file (it will not be present if
the daemon has died). It does not need to use cgroups to work, and
programs can benefit from runfs without knowing that they're using it :)

I don't have a strong opinion on consoled/kmscons as long as the in-kernel
VT remains as a viable option for things like early boot debugging, or
handling unforeseen corner cases that stop the userspace console daemon
from starting. I think it's a welcome addition, but I don't want it badly
enough that I'm willing to replace a good chunk of my userspace to get it.

Best,
Jude

[1] https://github.com/jcnelson/runfs

On Tue, Dec 30, 2014 at 2:55 PM, Martinx - ジェームズ <thiagocmartinsc@???>
wrote:

> 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
>>
>>
>