Discussing vdev from Devuan Project

KuroNeko · n00b Joined: 08 Oct 2014 Posts: 23

I think most of you already took notice of vdev.
I think its configuration syntax is rather easy to read, might worth to check it out:
https://github.com/jcnelson/vdev/commit/e82e98eb1991a853d81327426519d6be024b1eff

It also looks rather nice, because it would make (almost completely) logind useless and could be used on different kernels beside linux. What do you think about it?

Neko

Split from systemd or openrc - which one do you use? as it deserves its own topic. — JRG

steveL · Posted: Tue Jan 06, 2015 1:45 pm Post subject:

judecn · n00b Joined: 07 Jan 2015 Posts: 17

Anon-E-moose · Posted: Wed Jan 07, 2015 11:15 am Post subject:

krinn · Watchman Joined: 02 May 2003 Posts: 7470

depontius · Advocate Joined: 05 May 2004 Posts: 3509

Now that we're talking about vdev, and after having read the introduction, I've been mulling another perspective on systemd vs the world. It has been touched on in various ways on various forum threads. I may be rewording what has been said before, I'd prefer to think this is a condensation.

It comes down to this, where does policy reside?

Linus has been rather admant about keeping policy out of the kernel. Unforuntately policy has been something of a hot potato, largely because it's boring, unpopular work. Linus is right, in that policy should not be in the kernel, rather the mechanisms for implementing and enforcing it should be, but the policy itself should be in userspace. For the most part users don't want to fuss with it either, they just want policy that gives them a secure system and doesn't get in their way. Most of the time they also don't realize that those two goals are completely inconsistent. Thus far it seems that package owners usually don't want to own policy either, probably because it generates too many bugs, and you can't come up with one-size-fits-all - someone is always going to complain. So I suspect that by default policy ownership defaults to the distributions, and that policy actually ends up being a fairly significant distinguishing feature between distributions. It's also a rather thankless job, once again because nothing will satisfy everyone.

Enter systemd, which seems to embrace policy ownership. Since policy is so difficult to get right, and so thankless, it seems that most distrbutions are happy to let systemd have that piece of the pie. At the moment I don't think they've realized that they're also surrendering their differentiation as well - their reason to exist. There is also something really odd about the social networking situation surrounding systemd - if you don't like the systemd way, you're <insert deprecating adjective(s) here> and are just plain wrong. So far systemd is getting away with setting the default policy wherever it's used. I presume it's possible to change that default policy, but from what I can see it's harder to do than /etc/sudoers or /etc/pam.d/*.conf, takes a lot more learning, etc. So distributions are doing less of it, let alone end users.

I welcome vdev. I'm a little leery of C++ in that low-level a role, as are others. I would say that one of the most important things, along with all of the other most important things you've mentioned, will be some sample policies, for use as learning tools and pick-one-to-use.
_________________
.sigs waste space and bandwidth

saellaven · l33t Joined: 23 Jul 2006 Posts: 646

steveL · Posted: Wed Jan 07, 2015 7:38 pm Post subject:

judecn · n00b Joined: 07 Jan 2015 Posts: 17

tclover · Guru Joined: 10 Apr 2011 Posts: 516

Anon-E-moose · Posted: Wed Jan 07, 2015 9:26 pm Post subject:

one could always statically link libstdc++ (it is A solution)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

krinn · Watchman Joined: 02 May 2003 Posts: 7470

judecn · n00b Joined: 07 Jan 2015 Posts: 17

Thank you everyone for your feedback. It has given me some helpful insights into how to work on vdev going forward.

I should point out I'm coming from the Debian (and Devuan) community, and I'm motivated to create vdev because I need a long-term replacement for udev and parts of ConsoleKit/systemd-logind. This is a nights/weekends project for me; I use systemd at my $DAYJOB but for various reasons I'm not comfortable relying on it for my personal machines. Unfortunately, udev's eventual merger with systemd threatens to leave a lot of non-systemd Linux users wanting for dynamic device management, and it's not clear to me how the merger will affect the eudev project (but I think it's clear that udev upstream doesn't want to have to care). To avoid a repeat of the political fallout the merger is causing, I've been asking around the community to get a sense of what people currently expect from a device file manager *before* releasing it, so I can design vdev around its potential users' needs from the get-go.

That said, let me take a moment to address some of the concerns in this thread regarding vdev:

vdev relies on libraries installed to /usr, in particular libstdc++. (Thanks to saellaven, depontius, and krinn for bringing this up).

I'm embarrassed to admit it, but this did not occur to me when I started vdev, since all of my previous Linux, FreeBSD, and OpenBSD installs had /usr on the same physical disk as /. I didn't know it was a problem, and I apologize if I came off as arrogant for overlooking this. I will take steps in vdev to remove dependencies on /usr, including libstdc++ (as I mentioned earlier, the dependency is still small enough that removing it now is feasible).

Multi-seat setups and dependencies on a device manager are an evolutionary dead end. (Thanks to steveL for bring this up).

Regarding dependency on a device manager, I agree that dependency on a particular device manager implementation is a bad idea. This is why vdev's public API is the filesystem--regardless of what agent manages device nodes and the /dev directory structure (be it a program, a filesystem, or the administrator), the semantics of /dev will be defined independently of the implementation. The reasoning behind this design choices is that it would make coupling programs to vdev difficult, since neither I nor other userspace programmers get to control the semantics of the interface. Moreover, it looks to me like libudev API really just wraps functionality which can already be found in the VFS, so making a libudev-compat shouldn't be a big issue down the road (but to be fair, it seems that this is going to be more of an issue for binary distributions than source distributions like Gentoo, since the latter offer more freedom to compile out libudev dependencies).

Regarding multi-seat being a dead-end, I agree in principle--I think it's clear that with the cost of storage and computing falling as quickly as they are, multi-seat as we know it today (and probably LTSP) will be remembered historically as a stop-gap solution until there were enough cheap, reliable personal computers for everyone. Nevertheless, this need is still here today and I think it will be here for a while (and I personally find some aspects of it useful, particularly in the context of reasoning about policies governing device node access in containers). Fortunately, the functionality that implements per-process access control is well-isolated from the rest of vdev--there is already a plan to make it possible to compile this out if it isn't needed.

vdev doesn't need to be a one tool with all deps in it. (Quoting krinn directly).

I totally agree. Moreover, I never want users to feel like they have to fight vdev's design, nor would I ever want to compel the adoption of a bad design. I can add built targets for equivalents of vdev-boot and vdev-ssl or the like, to support multiple configurations (although I should point out that the ssl dependency lives in libpstat, not vdev, and compiling it out there will eventually be a supported compile-time option).

I've read the README file on gihub... and was going to say nice... well, I was surprised with the implementation (FUSE). (Thanks to tclover for pointing this out).

The key benefit of FUSE is that it can tell vdev which task is trying to access which device node, which is necessary for it to be able to hide device nodes from unprivileged processes. However, as mentioned above, this will be something that can be compiled out if it's not needed. Because the access control logic lives underneath the filesystem, other programs shouldn't break if it is missing since it doesn't affect POSIX filesystem semantics (but the user might need to take different steps to keep unprivileged programs from accessing privileged device nodes).

Again, thank you all for taking the time to give me useful feedback. If there are more concerns, please don't hesitate to let me know.

The Doctor · Moderator Joined: 27 Jul 2010 Posts: 2678

NeddySeagoon · Posted: Sat Jan 10, 2015 9:44 am Post subject:

The Doctor,

I think is more a question of how long eudev will be able to track udev by porting systemd-udev code.
At some point, to keep eudev alive it will need to reverse engineer systemd-udev functionality and reimplement it, or even diverge altogether. Thats much harder as eudev will also need to implement the functionality of systemd-udev bugs. Someone somewhere will write code that depends on the bugs. Ask AMD when they first made their own Intel compatible processor.

Personally, I don't see eudev as more than a stop gap and a way to keep the worst excesses of systemd in check, while eudev lives anyway.

judecn,

Being a bit of a dinosar, I have a static /dev. It all seems to work for me. I realise its not for everyone. I think its useful to keep the old ways alive because the day may come when its systemd or static.
I know which one I want, or maybe its choose the least worst.

Good luck with vdev and Devuan.
Debian missed an opportunity to stop the Red Hat rot. The choice was really drop Gnome or adopt systemd. They made the wrong choice for the entire FOSS community.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

depontius · Advocate Joined: 05 May 2004 Posts: 3509

jonathan183 · Guru Joined: 13 Dec 2011 Posts: 318

szatox · Advocate Joined: 27 Aug 2013 Posts: 3131

I just wonder why would a device manager depend on openssl :roll:

judecn · n00b Joined: 07 Jan 2015 Posts: 17

judecn · n00b Joined: 07 Jan 2015 Posts: 17

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Don't blindly default to the worst possible option just because everyone else does it. I suspect there would've been less protests if not for the choice of library.

Jaglover · Posted: Sun Jan 11, 2015 12:18 am Post subject:

judecn · n00b Joined: 07 Jan 2015 Posts: 17

John R. Graham · Posted: Sun Jan 11, 2015 4:33 am Post subject:

judecn · n00b Joined: 07 Jan 2015 Posts: 17