On Tue, 21 Oct 2014 16:03:10 +0200 Josselin Mouette <joss@debian.org> wrote: > The Wanderer <wanderer@fastmail.fm> wrote: > This is the problem. The init system should not be providing > "features" which other software might, post-boot and pre-shutdown, > want to make use of. (AFAIK sysvinit never did, and most - possibly > all? - of the other init-system candidates don't either.) Such > features should be provided separately, independent of what may > happen to be running as PID 1. > > These features cannot exist separately. Quoting the systemd position > statement: > > […] while it is true that a handful of trivial interfaces are not > really related to systemd (and could be split out if needed), most of > these features cannot be implemented without close integration to PID > 1. It is not possible to split the system cgroups arbitrator from the > process which starts services and sessions in cgroups. It is not > possible to ensure the relation of a log to a service if you do not > have awareness of how the service was launched. Et caetera. > "not possible" is always an intolerably extreme position in software. "Not currently possible" is very common, "not supported", "not easily possible", "not practical", "not convenient" or "not without potentially compromising security" are common too but all are open to new ideas and new implementations. Security itself is a spectrum and many use cases merit lower security to gain convenience, many other use cases have a perfectly sane reason to require security at the cost of (nearly all) convenience. It is always possible to push an interface between two 'rigid' free software components - it might not be secure in some forms and there may be latency but to say that a method of software A interacting with software B is "not possible" is a wild exaggeration and extremely short-sighted. Who knows what will become possible in the future? It is an error for any software project to state that the position of the project on any one matter is that the software to implement the solution to a problem is "not possible". A relation of a log to a service is mere configuration - a conffile is all that is needed for that example. Any software, currently possible or not, is just a SMOP after all... (Note: In common with a lot of us, I don't have time to work on any other software than the load I have currently... but that does *not* preclude someone else joining the effort and doing some of it. It is not currently possible for me to take on more software development but it is not impossible.) -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: PGP signature