5 ms·

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

bojo 12y ago
systemd - the emacs of init systems.
- vezzy-fnord 12y ago
  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.
  - hwh 12y ago
    Systemd has a DBus API. http://www.freedesktop.org/wiki/Software/systemd/dbus/ http://www.freedesktop.org/wiki/Software/systemd/dbus/
    - vezzy-fnord 12y ago
      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.
      - Shish2k 12y ago
        To be fair, the entire open source ecosystem combined minus emacs doesn't scratch the extensibility of emacs...
  - mackwic 12y ago
    > 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 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/ 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.
    - vezzy-fnord 12y ago
      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.
      - mackwic 12y ago
        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.
sztanpet 12y ago
I think you are mistaking systemd pid1 and systemd the project, this is not in pid1 but in the networkd component.
- ealexhudson 12y ago
  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 12y ago
    I'm worried about "without an external pppd daemon" part.
  - drdaeman 12y ago
    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 12y ago
      The linux kernel has had native PPPoE support since 2.4. https://wiki.debian.org/PPPoE https://wiki.debian.org/PPPoE
      - drdaeman 12y ago
        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.
VLM 12y ago
When it crashes against limitations. http://en.wikipedia.org/wiki/Inner-platform_effect 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.

bojo 12y ago

systemd - the emacs of init systems.

vezzy-fnord 12y ago
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.
- hwh 12y ago
  Systemd has a DBus API. http://www.freedesktop.org/wiki/Software/systemd/dbus/ http://www.freedesktop.org/wiki/Software/systemd/dbus/
  - vezzy-fnord 12y ago
    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.
    - Shish2k 12y ago
      To be fair, the entire open source ecosystem combined minus emacs doesn't scratch the extensibility of emacs...
- mackwic 12y ago
  > 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 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/ 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.
  - vezzy-fnord 12y ago
    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.
    - mackwic 12y ago
      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.

sztanpet 12y ago

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

ealexhudson 12y ago
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 12y ago
  I'm worried about "without an external pppd daemon" part.
- drdaeman 12y ago
  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 12y ago
    The linux kernel has had native PPPoE support since 2.4. https://wiki.debian.org/PPPoE https://wiki.debian.org/PPPoE
    - drdaeman 12y ago
      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.

VLM 12y ago

When it crashes against limitations. http://en.wikipedia.org/wiki/Inner-platform_effect 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.