On Fri, Oct 24, 2014 at 03:50:48PM +0300, Aigars Mahinovs wrote: > On 24 October 2014 15:40, Josh Triplett <j...@joshtriplett.org> wrote: > > What makes the systemd case so drastically different that those who care > > about alternative init systems cannot follow the same procedure? > > The key difference is that until this year all packages worked on all > init systems (as in you could start any service or application with > any init system as PID 1, even with "init=/bin/sh").
Until recently, it was a painful endeavor to be the upstream of a daemon package, because init scripts were not portable between Linux distributions; each distribution tended to have to write their own. systemd actually viewed that as a *problem*, and *fixed* it; it *is* fairly reasonable now to ship a .service or .socket or other unit file upstream and expect distributions to not need to change it. And when functionality is missing, it's possible to get that functionality added; how long has it been since sysvinit added a new useful feature that daemons could use? Until recently, if you wanted your service to be restarted if it crashed, you had to use one of various separate packages to do so; sysvinit simply didn't *do* that. It *could* have; I'd love to know where we'd be a decade ago if sysvinit had had an /etc/inittab.d. A quick search turns up people asking for that in *1999*. There's a reason that systemd has had a meteoric adoption rate: it provides a huge number of features people not only want, but have wanted for years. In practice, demanding that packages work with all init systems, or even with *two* init systems, demands that they support the least-common-denominator of functionality provided by those init systems. That effectively makes any new feature added to an init system useless until duplicated. > The fact that the regression is introduced by an architectural > decision of systemd developers to tightly integrate system level > services into the init system (and not by a decision in Debian) causes > the feeling of loss of control. That's a very legitimate and accurate feeling. The people not doing the work don't have control. The people who are doing work on alternative implementations do have control of those implementations, and can make them as loosely coupled as they like. > Then asking others to implement > init-system-neutral versions of systemd-invented services just to keep > using software that used to work before is ... raising some hackles. "asking" for such alternative implementations isn't raising hackles; *demanding* is raising hackles. Even worse yet are the folks instead demanding that upstreams simply not use such services, or who insist that no possible use exists for such services. And in many cases, the systemd-invented services and features fill a gap for which no previously implementation existed, so "used to work before" is quite inaccurate. Not all features are optional; not every feature needs fallback code to cope with its lack. Doubly so if such fallback code does not already exist. - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024141435.GA16989@thin
