* 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.
There are legitimate reasons for moving the functionality of an external program into a library and using the library directly. Unfortunately, the reason for a PPoE library is not given. If I had to guess, it probably has something to do with running on an embedded platform. Or, possibly, the normal pppd binary requires too much of an operating system than systemd can provide at the point where networking needs to be set up.
These are my guesses. Your guess seem to be that Lennart is unaware or unwilling to consider orthogonal design?
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.
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.
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.
Poettering has already laid out his vision for obsoleting package managers.
Thinks Docker style containers, applied to the whole distro. Every lib or program put in its own BTRFS based container image, and via union mount magic (managed by systemd, natch) "always" (looking forward to the blog entries about its failures) given a proper run time environment.
Sounds like an idea that functions well in a niche and seems like complete nonsense in others.
The great thing about the historical diversity in Linux is that, contrary to the complaints of "pointless" differences by folks in this thread, the various distros represent honest differences of opinion about what's good in a system. If you want to do silly things with loopback mounts and containers, there's room for that in the universe, but it would be wrong to impose it on those who don't want or need it.
You and others speak as if nobody ever had a reason to make their distro work differently. That they're just all evildoers who change stuff for no reason. Maybe you can say there is some of that, or that it emerges as a net result, but in a lot of cases people have honest differences of opinion about the right thing to do. So if person 1 has idea A and person 2 has idea B, you're going to deny one of them to get their problem solved simply because they are scratching at the same itch from two angles? Sounds kind of like software fascism to me.
Many of the current incompatibilities between distributions are not due to evil reasons but mostly historical ones. The vast majority of distribution maintainers, ie. those who should care most about those differencies, already think that it should be time to get rid those differencies and this is the reason systemd has seen such widespread adoption.
Package management is already a sufficiently big differentiator that there's no need for separate network configuration systems.
> The vast majority of distribution maintainers, ie. those who should care most about those differencies, already think that it should be time to get rid those differencies
Sounds made up.
> and this is the reason systemd has seen such widespread adoption.
It seems more like a few very influential players are in favor and the smaller people must follow suit if they want to be compatible. The latter part doesn't seem nearly as voluntary as you suggest.
If you believe that this sounds made up you don't have to trust me, check directly with them in the appropriate venues (ie. IRC or mailing lists). Most of the Debian Developers I know are quite sure that how to configure network interfaces is definitely not the most awesome distribution differentiator, and are seriously aware of the big limitations of the current solution.
Also I don't know who you're referring to with "influential players" vs. "smaller people". How such "influential players" are forcing "smaller people" to do things they don't want? Care to elaborate?
Trying to obsolete the needless differences between linux distributions on the basic level.
The differences that everybody just re-implements all the time, but slightly differently and never decides to innovate or make the status-quo better.
I think you hit it on the head to point out that the phrase is meaningless. The whole systemd phenomenon is very Freudian, right down to its name, it's as if systemd fans seek a single component to point at and call "the system", to worship as pater familias. "The system" will not only free you from being precise about what components serve what purpose, it will end all arguments and bring order to their lives in a way that decentralized purpose built components will not.
Maybe they should just use OS X and be done with it.
"Basic OS building blocks" means that systemd aims to provide low-level tools that you can reliably depend on across distributions. In particular those pieces that are currently implemented through distribution-specific init scripts of various quality and robustness.
Network configuration in particular varies greatly from distribution to distribution, having a common, shared system would be a great improvement over the status quo.
Systemd's pid 0 process does not do anything with or about PPPoE. Networkd does. Networkd is a daemon which manages the network configuration and PPPoE makes sense in that context.
But can networkd operate without systemd sitting as pid0?
Btw, that very line is why we have these debates. There is no clear way to indicate if you are talking about just the init part or the whole of systemd. This in large part because the name has stayed while the goals have constantly shifted.
And sometimes i wonder if the proponents wants it this way, as they can play the "superior" card by constantly "correcting" detractors on the difference. Fueling further the impression that the discussion is not technical but political...
Bingo. No other init but systemd has a sprawling set of sub-daemons that duplicate existing daemons for features (but not interfaces), and insist on only working with systemd as the running init.
No, networkd relies on systemd udev integration and unit activation system.
Since systemd needed a way to understand networking enough to activate units only on certain network settings (no need to fire up avahi if no real network interfaces are available) factoring out a daemon to react to devices coming and going to configure them wasn't too much work.
You may thing that networkd duplicates some NetworkManager features, but it's a rather different, lower-level beast and they can work together just fine.
I'm not sure which other daemons systemd duplicates, care to elaborate?
timesyncd does not duplicate ntpd, it is just a client daemon (it's closer to a daemonised ntpdate), hostnamed, localed, machined do not duplicate anything, logind is the ConsoleKit successor addressing the known, unfixable issues in the latter.
timesyncd, hostnamed, localed may arguably be made to work on non-systemd systems with little effort (as they already do in the systemd-shims package), logind relies on the systemd-as-pid1 due to the need to set up cgroups (in preparation to the single hierarchy change planned by kernel people) but with some more work it can be made to work without systemd (see the systemd-shims package again). I'm not sure if networkd is shipped by systemd-shims, let me know if you care enough to check.
Not at all. Emacs is significantly extensible. systemd has no notion of a plugin or module system, or anything like that. Other init schemes do, though.
5. If that's what you are suggesting to do, you are not supposed to directly modify and recompile your init system for causal changes. If you want to change its behavior, use command line flags or configuration file.
I'm just going to assume you're not a troll, because your arguments are widespread, regardless.
Systemd is far more than an init system, it has 69 binaries !
It's actually far more than 69 binaries by now. That's a long outdated number. Nor did I ever imply systemd is just an init system. Where did you get that?
sysV init has no notion of plugin nor module system, but has a notion of script file
Where did I mention sysvinit? I wasn't talking about sysvinit. finit and initng are examples of plugin-based init systems.
Like systemd the init system
It would be very odd if an init system didn't have some way of configuring a service, don't you think? I don't see how this is meaningful at all - it's an absolute fundamental given.
But you can also plug yourself via the dbus api, which is far more powerful
Which, as I stated in a previous post, is nowhere near sufficient for the level of extensibility that I was referring to, such as that of Emacs. The D-Bus API is useful for writing layers of abstraction and remotely controlling and querying the daemon(s) in a more convenient way.
If that's what you are suggesting to do, you are not supposed to directly modify and recompile your init system for causal changes. If you want to change its behavior, use command line flags or configuration file.
And why the hell not?
There is no "not supposed to" here, it's only a) improperly designed architecture and b) lack of imagination that makes it so.
Yes, in systemd's case, such a thing is not meant to be done. The reason is because the init daemon is coupled with the process management and supervision framework, among other components. As other init designs have shown, a dynamic plugin architecture is practical and useful provided components are more loosely coupled.
I'm also curious as to why you mention "recompile". The whole point of plugins is that you don't need to do that.
It's really funny that systemd proponents make such bland arguments deeply rooted in tradition. The same ones they decry a lot of opponents for making.
Well, your opinion is well informed. Please accept my apologies for answering so lightly. I was also thinking you were a troll.
So, very quick points before going into the core of the discussion:
> finit and initng are examples of plugin-based init systems.
There is a lot of innovative init systems out there, and none of them seems to have been considered. I agree, that's a shame but as I see it, systemd is only a transitional state where new architectures will be considered. I see systemd more like the recognition of the pain of shell scripts. The current situation is definitely too instable to stay as it.
> I'm also curious as to why you mention "recompile". The whole point of plugins is that you don't need to do that.
I strongly disagree. Dynamic libraries can be a point of failure of the system in so many ways I can't even imagine them all. We speak of a critical component of the system, it should be completely controlled.
Also, about the lack of Emacs-like plugin system, I would be frightened by this kind of extensibility as it would make the audit of a system far more complicated. I think we need some boundaries, the kind of a full interpreter wouldn't be able to give.
The question, then, is _what kind of extensibility is needed and acceptable_ ?
You seems to have an opinion on the matter, I would be happy to hear it.
From my point of view, the system proposed by systemd is acceptable and I don't miss any feature. Maybe I didn't dig to extreme corners, but be assured that I dig at least more than a simple install. It's not that bad.
As you said. It has 69 binaries. 69 insecure turd bins to worry about in what should be an init system. But it is no longer an init system. It is a cancer on Linux.
Edit - so it is cool now to have Linux subservient to the init system? Really?
sysvinit also has no notion of services at all. If you've got a system that's sysvinit-based, take a look in /etc/inittab sometime - that one small file is essentially everything that sysvinit knows. Setting up the system, mounting filesystems, finding and starting/stopping services, etc is all started by a handful of somewhat standardised distro-specific scripts that are run by sysvinit and hardcoded in /etc/inittab.
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...
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.
This still smells funny. The fact that the whole project is handle as one may make the communication between developers and also program component too easy (coupling). Personally I'm a bit overwhelmed by all the 'special strings', flags and options added at each release.
The existing, working, reliable system is huge and unwieldy. I have a new idea, lets scrap all that obsolete old stuff and create a simpler smaller more modern implementation. Well, turns out replicating and embedding the rest of the world is really hard work, and the result is huge and unwieldy and usually less reliable and comprehensible because its newer. Recursively repeat until stack space exhausted or resource limitations make it too slow to ship...
Note this applies both to the tech side of putting an OS inside your OS, and also to the business side of product tying more and more products until everything imaginable is tied in, at which point the only hope for forward progress is reimplementing everything inside a component of it, of course.
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) reimplementation?
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.)
What's not to get? Your shiny new bloated init system just added another attack entry point. Enjoy! The hackers will!
Edit - so people think this will be secure and not exhibit some of the same classy bugs the other 68 binaries of systemd have shown? A flick through the bug tracker over there is a real eye opener.
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.
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.
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
I'm almost certain there's no need to write a whole new pppd from scratch.
All kind of software has bugs, even 30-years old stable software has bugs. The fact that developers are actively working on new releases, features and fixing existing problems shouldn't stop the software from being in stable distributions like Debian or Redhat.
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).
64 comments
[ 3.4 ms ] story [ 132 ms ] threadThese are my guesses. Your guess seem to be that Lennart is unaware or unwilling to consider orthogonal design?
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.
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.
You say it like that would be a bad thing.
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.
Thinks Docker style containers, applied to the whole distro. Every lib or program put in its own BTRFS based container image, and via union mount magic (managed by systemd, natch) "always" (looking forward to the blog entries about its failures) given a proper run time environment.
The great thing about the historical diversity in Linux is that, contrary to the complaints of "pointless" differences by folks in this thread, the various distros represent honest differences of opinion about what's good in a system. If you want to do silly things with loopback mounts and containers, there's room for that in the universe, but it would be wrong to impose it on those who don't want or need it.
Package management is already a sufficiently big differentiator that there's no need for separate network configuration systems.
Sounds made up.
> and this is the reason systemd has seen such widespread adoption.
It seems more like a few very influential players are in favor and the smaller people must follow suit if they want to be compatible. The latter part doesn't seem nearly as voluntary as you suggest.
Also I don't know who you're referring to with "influential players" vs. "smaller people". How such "influential players" are forcing "smaller people" to do things they don't want? Care to elaborate?
> Is a meaningless phrase.
What does "OS/Net consolidation" mean? Or "Base system"?
Maybe they should just use OS X and be done with it.
Network configuration in particular varies greatly from distribution to distribution, having a common, shared system would be a great improvement over the status quo.
Systemd's pid 0 process does not do anything with or about PPPoE. Networkd does. Networkd is a daemon which manages the network configuration and PPPoE makes sense in that context.
Btw, that very line is why we have these debates. There is no clear way to indicate if you are talking about just the init part or the whole of systemd. This in large part because the name has stayed while the goals have constantly shifted.
And sometimes i wonder if the proponents wants it this way, as they can play the "superior" card by constantly "correcting" detractors on the difference. Fueling further the impression that the discussion is not technical but political...
Pid1 /must/ be the first process as it's starting all the others; Shipping a network daemon w/ systemd doesn't imply the network daemon is pid1.
EDIT: Or if not, that's what I'm curious about.
Since systemd needed a way to understand networking enough to activate units only on certain network settings (no need to fire up avahi if no real network interfaces are available) factoring out a daemon to react to devices coming and going to configure them wasn't too much work.
You may thing that networkd duplicates some NetworkManager features, but it's a rather different, lower-level beast and they can work together just fine.
I'm not sure which other daemons systemd duplicates, care to elaborate?
timesyncd does not duplicate ntpd, it is just a client daemon (it's closer to a daemonised ntpdate), hostnamed, localed, machined do not duplicate anything, logind is the ConsoleKit successor addressing the known, unfixable issues in the latter.
timesyncd, hostnamed, localed may arguably be made to work on non-systemd systems with little effort (as they already do in the systemd-shims package), logind relies on the systemd-as-pid1 due to the need to set up cgroups (in preparation to the single hierarchy change planned by kernel people) but with some more work it can be made to work without systemd (see the systemd-shims package again). I'm not sure if networkd is shipped by systemd-shims, let me know if you care enough to check.
I have no idea how the hell this implies modules, plugins or extensibility on any level that even begins to scratch the surface of Emacs.
rolling eyes
Please, stop doing your karma bitch.
1. Systemd is far more than an init system, it has 69 binaries !
2. sysV init has no notion of plugin nor module system, but has a notion of script file
3. Like systemd the init system: http://0pointer.de/blog/projects/systemd-for-admins-3.html
4. But you can also plug yourself via the dbus api, which is far more powerful: http://www.freedesktop.org/wiki/Software/systemd/dbus/
5. If that's what you are suggesting to do, you are not supposed to directly modify and recompile your init system for causal changes. If you want to change its behavior, use command line flags or configuration file.
Systemd is far more than an init system, it has 69 binaries !
It's actually far more than 69 binaries by now. That's a long outdated number. Nor did I ever imply systemd is just an init system. Where did you get that?
sysV init has no notion of plugin nor module system, but has a notion of script file
Where did I mention sysvinit? I wasn't talking about sysvinit. finit and initng are examples of plugin-based init systems.
Like systemd the init system
It would be very odd if an init system didn't have some way of configuring a service, don't you think? I don't see how this is meaningful at all - it's an absolute fundamental given.
But you can also plug yourself via the dbus api, which is far more powerful
Which, as I stated in a previous post, is nowhere near sufficient for the level of extensibility that I was referring to, such as that of Emacs. The D-Bus API is useful for writing layers of abstraction and remotely controlling and querying the daemon(s) in a more convenient way.
If that's what you are suggesting to do, you are not supposed to directly modify and recompile your init system for causal changes. If you want to change its behavior, use command line flags or configuration file.
And why the hell not?
There is no "not supposed to" here, it's only a) improperly designed architecture and b) lack of imagination that makes it so.
Yes, in systemd's case, such a thing is not meant to be done. The reason is because the init daemon is coupled with the process management and supervision framework, among other components. As other init designs have shown, a dynamic plugin architecture is practical and useful provided components are more loosely coupled.
I'm also curious as to why you mention "recompile". The whole point of plugins is that you don't need to do that.
It's really funny that systemd proponents make such bland arguments deeply rooted in tradition. The same ones they decry a lot of opponents for making.
So, very quick points before going into the core of the discussion:
> finit and initng are examples of plugin-based init systems.
There is a lot of innovative init systems out there, and none of them seems to have been considered. I agree, that's a shame but as I see it, systemd is only a transitional state where new architectures will be considered. I see systemd more like the recognition of the pain of shell scripts. The current situation is definitely too instable to stay as it.
> I'm also curious as to why you mention "recompile". The whole point of plugins is that you don't need to do that.
I strongly disagree. Dynamic libraries can be a point of failure of the system in so many ways I can't even imagine them all. We speak of a critical component of the system, it should be completely controlled.
Also, about the lack of Emacs-like plugin system, I would be frightened by this kind of extensibility as it would make the audit of a system far more complicated. I think we need some boundaries, the kind of a full interpreter wouldn't be able to give.
The question, then, is _what kind of extensibility is needed and acceptable_ ?
You seems to have an opinion on the matter, I would be happy to hear it.
From my point of view, the system proposed by systemd is acceptable and I don't miss any feature. Maybe I didn't dig to extreme corners, but be assured that I dig at least more than a simple install. It's not that bad.
Well there's your problem
I love that people bash Lennart for code he didn't even write...
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.
https://wiki.debian.org/PPPoE
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.
http://en.wikipedia.org/wiki/Inner-platform_effect
Its an endless, fairly pointless, cycle.
The existing, working, reliable system is huge and unwieldy. I have a new idea, lets scrap all that obsolete old stuff and create a simpler smaller more modern implementation. Well, turns out replicating and embedding the rest of the world is really hard work, and the result is huge and unwieldy and usually less reliable and comprehensible because its newer. Recursively repeat until stack space exhausted or resource limitations make it too slow to ship...
Note this applies both to the tech side of putting an OS inside your OS, and also to the business side of product tying more and more products until everything imaginable is tied in, at which point the only hope for forward progress is reimplementing everything inside a component of it, of course.
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) reimplementation?
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.)
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.
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.
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
I'm almost certain there's no need to write a whole new pppd from scratch.
Am I the only one to see this as a reason that it should not be in stable distribs like Debian or Redhat ?