
Systemd v218 - lelf
http://lists.freedesktop.org/archives/systemd-devel/2014-December/026189.html
======
andor
This is cool:

    
    
      * systemctl gained a new "edit" command. When used on a unit
        file this allows extending unit files with .d/ drop-in
        configuration snippets or editing the full file (after
        copying it from /usr/lib to /etc). This will invoke the
        user's editor (as configured with $EDITOR), and reload the
        modified configuration after editing.

------
drdaeman
I don't get it (and don't want to download and read systemd source). Could
someone explain?

The docs say:

> native PPPoE library has been added to sd-network, systemd's library of
> light-weight networking protocols. This library will be used in a future
> version of networkd to enable PPPoE communication _without an external pppd
> daemon._ (emphasis mine)

Usually, it works like this - a separate entity (either as a separate daemon
that talks to pppd through a pipe or as rp-pppoe.so plugin to Samba's pppd)
does the PPPoE session discovery and management, then passes decapsulated PPP
frames to a full-fledged PPP daemon implementation. Which is a quite large
entity.

Did they implement only PPPoE part (that is, just handling encapsulated PPP
frames) or systemd now has a full-fledged PPP (with all the important
subprotocols like LCP, EAP, IPCP and possibly IP6CP) _re_ implementation?

Not like I care about systemd gaining PPP support. Heck, they want to build
their own OS core - that's great. What I don't get is why rewrite things that
aren't broken in the first place? (Samba's pppd may be a bit messy and has
some nearly-dead stuff like IPX support, but is generally fine.)

~~~
digi_owl
Likely the existing pppd don't play well with systemd's automagical detection
of network status, and the unit files that depend on that.

~~~
drdaeman
Why not just spawn pppd from networkd?

They can write a full-fledged pppd replacement, but can't just have pppd as a
child process and happily control it? (May possibly need a tiny patch or two,
but that's barely an issue)

I'd get it if one needs some very tight integration, but pppd is self-
sufficient, fairly controllable and well-tested.

Looks like NIH syndrome to me. But maybe I'm missing something from the
picture and pppd isn't a good fit. Then, okay.

~~~
digi_owl
I'm no insider, so all i can say is that i suspect
[http://ewontfix.com/15/](http://ewontfix.com/15/) holds the key.

Existing pppd would have to be using one of simple, forking, oneshot or idle
to indicate that it is up. And quite possible they have deemed that too
unreliable for whatever use case they have.

The other options would be to modify the existing pppd to use dbus or notify.
And at that point they may well have gone with reimplementing the parts of ppp
they need for their existing use case.

~~~
drdaeman
My memory is a bit blurry, but IIRC with `nodetach` option pppd would fit
"simple" category or its derivatives well.

Teaching it to notify via dbus is as trivial as passing a bunch of `connect
/usr/lib/networkd/ppp/ip-down`-type options or writing a simple plugin library
to do dbus messaging or `sd_notify` calls. Available plugin API hooks should
allow for anything necessary to have a good understanding of pppd's state and
provide a good amount of control over it (link state changes, authentication,
IP address negotiation, idling etc) when necessary:
[http://ftp.samba.org/pub/unpacked/ppp/PLUGINS](http://ftp.samba.org/pub/unpacked/ppp/PLUGINS)

I'm almost certain there's no need to write a whole new pppd from scratch.

------
pianoforted
Why should an init.d replacement have something even remotely to do with
PPPoE? What ever happened to orthogonal design?

~~~
sztanpet
You are also conflating the "init.d" replacement with the project that is
aiming to provide basic OS building blocks.

networkd is quite orthogonal to pid1, what it is not orthogonal to is that
nowadays almost every system needs network connectivity so bringing up the
network is part of the basic system. And systemd (the project) is trying to be
the basic building blocks from which you can build an OS out of.

~~~
vezzy-fnord
_basic OS building blocks_

Is a meaningless phrase.

 _bringing up the network is part of the basic system_

I'm not even sure what the implication is here. That such a thing was not
possible before systemd?

 _And systemd (the project) is trying to be the basic building blocks from
which you can build an OS out of._

So it's trying to obsolete the Linux distribution? You're going to have to
define some terminology first, I'm afraid.

~~~
pantalaimon
> So it's trying to obsolete the Linux distribution?

You say it like that would be a bad thing.

~~~
vezzy-fnord
systemd is targeting the totally wrong layer of the stack for such a thing.
What makes a distribution is its package manager. We already have solutions
like Nix for this, though they sadly might not break the mainstream if
Lennart's proposed btrfs volume scheme comes into fruition.

I'd say that experimentation and divergence in systems and application
software, particularly if it's easily enabled thanks to the bazaar approach of
Linux, is definitely a good thing. Trying to erect unshakable foundations
around what is just an OS kernel will only stifle the marketplace of ideas.

Of course, wanting a fully integrated OS is most certainly not a bad thing.
This can be done either by using a BSD, or on the individual distribution
level if it's sufficiently advanced.

~~~
UnoriginalGuy
There's no reason third party components couldn't slot into systemd. It is
quite modular. It is just a different method of intercommunication, not the
end of intercommunicating modular components.

~~~
digi_owl
Who do i hear Hotel California playing in my head?

------
davecheney
When will this madness stop? Will systemd not be satisfied til it has subsumed
the universe into one great pid 1 singularity?

~~~
sztanpet
I think you are mistaking systemd pid1 and systemd the project, this is not in
pid1 but in the networkd component.

~~~
ealexhudson
And it's substantially south of 1000 lines of code. It's not a full PPP
daemon, but it is enough to set up (it seems) PPPoE - useful, example, for
small embedded DSL routers.

I love that people bash Lennart for code he didn't even write...

~~~
drdaeman
I'm worried about "without an external pppd daemon" part.

There's no point in PPPoE without PPP. And if they say "without external pppd"
this means they're going to ship a full-fledged PPP daemon.

~~~
eggnet
The linux kernel has had native PPPoE support since 2.4.

[https://wiki.debian.org/PPPoE](https://wiki.debian.org/PPPoE)

~~~
drdaeman
Yes, that's the difference with rp-pppoe.so (using kernel module to handle
encapsulation, userspace code only sets up the sockets) and pppd's pty option
(got it a bit wrong in my other comment in this thread, believed it's a pipe,
thanks for correcting) with separate process to do so. It doesn't really
matter.

More than this, Linux kernel has kernel-mode PPP. But still a few parts of
PPP, and all accompanying control protocols (especially authentication-related
ones like EAP - you don't want that beast in the kernel!) are done in
userspace.

------
jmnicolas
> _Many many bug fixes_

Am I the only one to see this as a reason that it should not be in stable
distribs like Debian or Redhat ?

~~~
xenophonf
Those bug fixes get back-ported, and the bugs fixed may have been introduced
in versions of systemd released after whatever got included in RHEL/Debian.
Speaking as someone constantly frustrated at the glacial pace at which RHEL
and Debian-stable update themselves (which is admittedly a feature), it's nice
to see them adopting somewhat modern stuff when they make major releases (if
systemd v208+backports could be considered modern).

------
RexRollman
What a monstrosity.

