10 ms·
Anyone knows how this could be done in practice? I mean, in programming you'd solve a problem like this by defining a proper set of interfaces and making sure e
by stinos 12y ago
Anyone knows how this could be done in practice? I mean, in programming you'd solve a problem like this by defining a proper set of interfaces and making sure each implementation adheres to it. Form what I read in this thread, part of the problem seems to be there is no such interface and hence developpers depeninding on an init system have to choose A or B or do twice the work.
- peterwwillis 12y agoFrom what I understand of systemd, it's more a factor of there being an entirely new inter-process communication mechanism, combined with a lot of custom applications. And because it's this top-down monolithic design, either you use systemd as your init, or you get none of the functionality of the custom programs... so it's all-or-nothing. On top of that, the people who don't want to use it are against the idea of supplanting the core technology they're used to. So you have this one camp that's all "fuck yeah new technology", and another camp that's like "get that shit out of my box." In a way it's like GNOME vs KDE, but almost at the very heart of the operating system. You just have to pick one and go with it, or you don't really get the benefit of either. The 'set of interfaces' you mention should (imho) be patches to systemd to allow it to work as not-pid-1, so that you can still take advantage of its contributory applications without having to supplant your init system. That way you could use 'a gtk application in a kde workstation', but with systemd and sysvinit.