From owner-freebsd-current@freebsd.org Fri Apr 22 09:04:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30CDCB1875D for ; Fri, 22 Apr 2016 09:04:14 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id BC3751237; Fri, 22 Apr 2016 09:04:13 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id 43A17DC0CD; Fri, 22 Apr 2016 12:04:12 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Fri, 22 Apr 2016 12:04:20 +0300 From: dan_partelly To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Cc: David Chisnall , freebsd-current Subject: Re: [CFT] packaging the base system with pkg(8) In-Reply-To: <20160422084109.GB1479@brick> References: <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> <20160421202023.GB33506@brick> <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> <20160422084109.GB1479@brick> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 09:04:14 -0000 This is one of the issue I perceive with using scripts/ intermediate programs as a glue, a problem which does not exist when the daemons are integrated tighter. You basically give up all the power which arises from inter-operating daemons give to the system. It is also the main problem FreeBSD's rc system presents. Because all is a scaffolding of shell scripts, it basically gives you 0 of the power modern service management offer. Most important are service life cycle management, restart policies, delegated administration and fault reporting. The only thing you gain is easy debugability (no small boon)but it is easily outweighted by all other advantages of a modern service manager. > > Well, even if we went this route, this wouldn't quite work, because > the automountd daemon actually doesn't need those notifications. > It's the "-media" map that does. Other parts of autofs don't have > any special code for media handling. About shell scripts in general as a glue: Yes, they are easily debuggable and customized. Yet I believe that all that power should be hidden,and it should be unnecessary to tap into it for 95% of administrative needs. It is my perception that less and less people are interested in exploring the countless ranges of customization such scaffolding of scripts offer. People are interested in sane defaults, easy to specify policies and fault reporting. Life is too short to explore myriad of customizations, unless you really have to. And most of the time, you dont need to. Thats not to say shell scripts dont have their place. They do. I use them too, both on unixes and tcl scripts for adding fast functionality in csico devices. But as a glue between essential operating system subsystems, it is my oppinion that we are 10 years too late in replacing them.