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.
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.
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.
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 have no idea how the hell this implies modules, plugins or extensibility on any level that even begins to scratch the surface of Emacs.