4 ms·

> 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 you

• 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.
    • feld 12y ago
      > It's not that bad. Well there's your problem
• systemdturd 12y ago
  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?
• makomk 12y ago
  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.