❦ 11 août 2012 01:12 CEST, Josselin Mouette <joss@debian.org> : >> Declaring "one area -- one chosen tool" is declaring the monopoly in the >> area. As with other monopolies, this often leads to "vendor" lock-in, >> stagnation, stopping developing the standards. Have seen examples of all >> that occasionally. > > That’s a very theoretical reasoning. Practically, when you have several > init implementations, what you can do is limited by the least capable of > them — even worse, instead of bringing more features, you can only use > the intersection of their functionality. There is a workaround for this: declaring that all daemons should support systemd (or upstart), support for other init being done through some compatibility layer or, exceptionally, by providing ad-hoc init scripts. This is the subject of one GSoC project (I don't know its status): http://wiki.debian.org/SummerOfCode2012/Projects#SysV-init_file_creator_from_systemd_service_files As long as the more capable init is used as reference, I really don't care if people try to fit alternate inits. If we cannot get a compatibility layer, I agree with you: we should move forward to a more capable (event driven) init. -- Identify bad input; recover if possible. - The Elements of Programming Style (Kernighan & Plauger)
Attachment:
pgpUHE72AOAnB.pgp
Description: PGP signature