[svlug] Devuan

Rick Moen rick at linuxmafia.com
Sun Jul 10 02:09:30 PDT 2016


Quoting Ivan Sergio Borgonovo (mail at webthatworks.it):

> It is an interesting piece of software but there were already alternatives.

Just trying to recall, pro bono publico:

udev, eudev, vdev, mdev.  And of course static /dev.  I'm probably
forgetting some.

Long discussion is possible about merits, omitted here (and partially
forgotten).


> That seems it is going nowhere other than in devuan.

At the risk of driving the point into the ground, as it's what I said
upthread, that means it's also avaible to Debian, because Devuan's repos
are (intentionally) compatible.  That would be excellent news to me and
other clued Debian users, as I'd really rather not have to rebuild
xserver-xorg packages if I don't have to.

(I remember compiling XFree86, and it was a monstrous process.)

Mind you, I'm not on a holy war against udev (nor even systemd).  udev
crept into systems without huge problems, and I only gradually became
aware that static /dev was no longer present (and indeed you are
_prevented_ from creating nodes manually using mknod in a udev-managed
/dev tree).  It has good reasons for existing and solves many use-cases
-- and it's a huge improvement over devfs, which was an awful code
hairball and, to the horror of most of us, ran in kernelspace.

It may be that dynamically managed /dev is a practical necessity even on
servers, but I intend to determine the answer to that question for
myself, for _my_ use-case.

See, one of the things I've slowly realised, as I catch up on the
systemd-centred flamewars of several years ago (in which I didn't
participate) is that the urge to make distro-packaged software meet all
needs for all users simultaneously exacts a cost in excess complexity,
and that some changes primarily for the benefit of novice users and 
to serve Desktop Environments (DEs), primarily GNOME, have exacted 
_too much_ cost.

My main Linux concern is servers, secondarily desktop computing without
DEs (e.g., with a window manager plus apps selected a la carte on a best
of breed basis without regard to DE religion).  Especially on the server
side, I need architectural simplicity, code with only the minimum
feature set I actually need, clean / well-defined software interfaces, 
high security, high reliability.

Among other things, that means that whenever I see a baroque piece of
software on my server, especially somewhere central to the system, I 
question its necessity.  Dynamic /dev makes me think 'Sorry, is there
any specific reason static /dev can't still work for me?'  Maybe yes,
maybe no, but I no longer just trust distro packagers' judgement
automatically, and expect to check that for myself.  And here's why:

Some years back, not long after noticing my Debian systems had /dev
managed by a shiny new daemon, I posted about it to Don Marti's
linux-elitists mailing list, wondering about the necessity.  Which drew
a rather surly, passive-aggressive rejoinder from Greg Kroah-Hartman,
the author/architect of udev.  Greg said:  My daughter needs to be able
to be able to casually plug a USB printer into my Linux box and have the
device node autopopulate and trigger the right behaviour to do printing,
and it's not reasonable to require her to wield root access to do that.

I reassured Greg that I wished only the best for his daughter, but that
many of us are _not_ Greg K-H's daughter and have different needs.

One size does not fit all -- yet distro packagers act like it does.
And that is a problem for me.  Fortunately, it's an eminently solvable
problem, because this is open source.  Let me elaborate on that:



> The problem is that to make everything run smoothly unless you're an 
> ubergeek with some special requirements you need adoption.

I do not concur.  Or, at least, I see shades of grey that I'm not sure
you acknowledge.

http://linuxmafia.com/faq/Debian/openrc-conversion.html starts out with
six shell commands that replace systemd on Debian 8 'Jessie' with your
choice of other packaged init, and make sure systemd cannot return.
Frankly, I stole those commands wholesale from other people's work,
tested them, and documented them.

That simple set of commands accomplishes, essentially effortlessly, what
any number of anti-systemd people, and for that matter pro-systemd
people, have gone around claiming is impossible -- and I didn't even
need to work them out, only document them on a Web page.  Point is, that
was low-hanging fruit, snagged with next to zero effort.  And it works 
irrespective of who adopts what.

I'm rather taken with the notion of running Rob Landley's mdev (part of
busybox) on servers, in the event that static /dev is no longer feasible
-- because it's simple, well tested, deterministic, has a tiny attack
surface, etc.  As a result of its simplicity, it doesn't 'need adoption'
to work fabulously -- within limits set by its modest feature set.

'But it's not supported!'  Um, sorry, what exactly needs 'support'?  It
Just Works{tm}.  No ubergeekery required.

There is a spectrum -- a set of shades of grey -- between following the
path of least resistance and taking what the distro packagers give you
without question on one end, and maintaining everything yourself on the
other.  I outline several of the steps on that spectrum in my page's
'Overcoming Dependency Obstacles' section.  

The trick is to get the best effect with the minimal means, in
accordance with Larry Wall's dictum about laziness being a virtue:
You can rely on a good third-party package repo.  You can rebuild a
package locally to change its dependencies using debuild or
dpkg-buildpackage.  You can make a local package using debhelper.  
Worst case, you can compile a non-packaged setup into /usr/local/*.

All of those are options (along with fibbing to the system about
satisfying package dependencies using 'equivs'), listed in roughly
increasing order of bother.  None of them requires ubergeekery.

And, if you solve a problem locally, you can publish your work as a repo
of debs, and everyone else can benefit.  Because open source, you know.

What you call the virtue of 'adoption' all too often means everyone gets
the least common denominator.  Everyone gets to be Greg K-H's daughter.
I'm sure Greg's daughter is a wonderful person, but *I* don't need to
plug her printer into *my* server and need it to be automatically
recognised and set up with a print queue.  

Everyone being Greg's progeny means everyone gets deeply suboptimal
everything -- and, dunno about you, I think I deserve better.


> Part of my point is: it qualifies for you and another small bunch of people.

Works for Me.{tm}

I'm out for solutions for the guy I shave.  Greg's kids can solve their
own problems.

-- 
Cheers,                                "Why struggle to open a door between us,
Rick Moen                              when the whole wall is an illusion?"
rick at linuxmafia.com                                                     -- Rumi
McQ! (4x80)



More information about the svlug mailing list