> 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 ?
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 con…
I think you are mistaking systemd pid1 and systemd the project, this is not in pid1 but in the networkd component.
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...
While he didn't write it, he did choose to include it. Still, as someone on the fence, I'd really rather just hear about the software itself.
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.
> Not at all. Emacs is significantly extensible. systemd has no notion of a plugin or module system, or anything like that 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.…
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.
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 s…
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 tr…
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.
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 af…
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.
systemd (init) operates as pid1; Networkd is spawned by init similar to ubuntu's NetworkManager or a classic /etc/init.d/network restart. 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.
I think he's asking if you could launch networkd from, say, a traditional init or Upstart. EDIT: Or if not, that's what I'm curious about.
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.
systemd (init) operates as pid1; Networkd is spawned by init similar to ubuntu's NetworkManager or a classic /etc/init.d/network restart. 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.
I think he's asking if you could launch networkd from, say, a traditional init or Upstart. EDIT: Or if not, that's what I'm curious about.
Systemd has a DBus API. http://www.freedesktop.org/wiki/Software/systemd/dbus/
Which is a programmatic way of essentially doing what systemctl does, querying Unit metadata, and subscribing to some events. 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.
To be fair, the entire open source ecosystem combined minus emacs doesn't scratch the extensibility of emacs...
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 separat…
Likely the existing pppd don't play well with systemd's automagical detection of network status, and the unit files that depend on that.
> So it's trying to obsolete the Linux distribution? You say it like that would be a bad thing.
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…
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.