Re: [gentoo-amd64] Boycott Systemd

[Rich Freeman]

On Sun, Sep 21, 2014 at 10:02 PM, Frank Peters <frank.peters@×××××××.net> wrote:
> On Sun, 21 Sep 2014 20:45:17 -0400
> Rich Freeman <rich0@g.o> wrote:
>> You can create device nodes using mknod, and I'd be
>> shocked if that ever went away.
>>
>
> But now certain static USB nodes, in particular those for
> scanners, have been removed in favor of dynamic allocation
> using udev or its equivalents.  When this happened I was
> certainly shocked, and it could be the beginning of a trend.

Fair point, although to some extent this reflects the nature of how
modern devices work.  Back in the day you had a few serial/parallel
ports and you could tell which one was which because they all used
different IO ports or IRQs that were hard-coded into the designs.  Now
you just have one USB host controller which is really the only actual
true hardware device on the system and everything that is hooked up to
it is virtualized.  Plug-and-play really did away with the way device
nodes tended to work, and systems like udev are probably the cleanest
solution.  I for one am happy that I haven't had to configure an IRQ
since the 90s.

>
>>
>> Just what is it that you actually
>> need the kernel to do for you that you don't think will still be
>> around in 20 years?  Linus is VERY conservative about removing system
>> calls.
>>
>
> There are things which are not system calls that could easily be
> changed.  It is not too far fetched to consider a time if and when
> systemd became so popular and entrenched that the kernel would be
> hard-coded to pass control only to systemd and nothing else.

That seems extremely unlikely.  How many people ran anything other
than sysvinit as their init for the 15 years or so before upstart came
along?  Making the kernel dependent on systemd would defeat the whole
purpose of having a separation between userspace and kernelspace.

>
>>
>> If the whole world moves to systemd the biggest problem you'll have is
>> that you'll have to write your own service startup scripts, but from
>> the sound of things you're doing that anyway.  Most of the services
>> you probably run aren't linux-exclusive either, so while it seems
>> likely that many will start reporting their status to systemd it seems
>> unlikely that they will refuse to work without it.
>>
>
> There are a growing number of applications that will no longer compile
> without either dbus or udev.  In fact, even though I don't use them,
> I had to install both eudev and dbus in order to be able to use certain
> applications (I just substituted a symlink to /bin/true in place of
> dbus-launch to keep that unnecessary daemon from starting).

Well, it seems likely that dbus will be a kernel module before long,
so it will be readily available.  I'm sure there are plenty of
programs that don't work if you don't have any number of kernel
options disabled.  Kdbus is viewed as the future standard mechanism
for linux inter-process communication, so programs relying on it
should be as surprising as programs that rely on ptys.

Much of the issue boils down to the linux world becoming more
complex/functional.  Back when you could assume that your printer was
attached to a parallel port and spoke postscript things were simpler.
Today people want to plug in their USB headset and have the computer
know to use the USB headset for their teleconference and put the
output in the speakers when the phone rings.  That just isn't going to
work with a world where you output a sound by directing a .au file to
a device node.

--
Rich