From owner-freebsd-arch@freebsd.org Sun Feb 9 09:22:05 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2BEB023287D for ; Sun, 9 Feb 2020 09:22:05 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48Fk7v73jWz3P1M for ; Sun, 9 Feb 2020 09:22:03 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: (qmail 91386 invoked from network); 9 Feb 2020 09:22:01 -0000 X-APM-Authkey: 18389/1(18389/1) 2 Received: from unknown (HELO meld.njm.me.uk) (86.157.235.207) by smtp002.apm-internet.net with SMTP; 9 Feb 2020 09:22:01 -0000 Received: from triton.njm.me.uk (triton.njm.me.uk [192.168.144.133]) by meld.njm.me.uk (8.15.2/8.15.2) with ESMTP id 0199M18J022686; Sun, 9 Feb 2020 09:22:01 GMT (envelope-from njm@njm.me.uk) Received: from localhost (localhost [127.0.0.1]) by triton.njm.me.uk (8.15.2/8.15.2) with ESMTP id 0199M0s3052876; Sun, 9 Feb 2020 09:22:00 GMT (envelope-from njm@njm.me.uk) Date: Sun, 09 Feb 2020 09:22:00 +0000 From: "N.J. Mann" To: Poul-Henning Kamp cc: freebsd-arch@freebsd.org Subject: Re: updating cron and atrun Message-ID: <97A66670F59C9C626B5090E3@triton.njm.me.uk> In-Reply-To: <6701.1581190231@critter.freebsd.dk> References: <6701.1581190231@critter.freebsd.dk> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Rspamd-Queue-Id: 48Fk7v73jWz3P1M X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of njm@njm.me.uk has no SPF policy when checking 85.119.248.221) smtp.mailfrom=njm@njm.me.uk X-Spamd-Result: default: False [0.11 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.86)[-0.863,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.13)[-0.131,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[njm.me.uk]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[221.248.119.85.list.dnswl.org : 127.0.3.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:35259, ipnet:85.119.248.0/21, country:GB]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(0.31)[ipnet: 85.119.248.0/21(0.90), asn: 35259(0.72), country: GB(-0.08)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 09:22:05 -0000 Hi, On Saturday, February 08, 2020 19:30:31 +0000 Poul-Henning Kamp wrote: > > Thanks for looking into this. > > Is at(1) something people actually use these days, or should it be > disabled by default ? I do. I use it to run various homebrew scripts in response to external events. I needed a delay (sometime minutes, sometimes hours) between the event and the response and at(1) was a perfect fit. Cheers, Nick. -- From owner-freebsd-arch@freebsd.org Sun Feb 9 10:10:42 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D21BD233A7E for ; Sun, 9 Feb 2020 10:10:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48FlD11vn5z3wmN for ; Sun, 9 Feb 2020 10:10:40 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 59AA81AF101; Sun, 9 Feb 2020 10:10:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id 019AAbYe008969 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 9 Feb 2020 10:10:37 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id 019AAZoa008968; Sun, 9 Feb 2020 10:10:35 GMT (envelope-from phk) To: "N.J. Mann" cc: freebsd-arch@freebsd.org Subject: Re: updating cron and atrun In-reply-to: <97A66670F59C9C626B5090E3@triton.njm.me.uk> From: "Poul-Henning Kamp" References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8966.1581243035.1@critter.freebsd.dk> Date: Sun, 09 Feb 2020 10:10:35 +0000 Message-ID: <8967.1581243035@critter.freebsd.dk> X-Rspamd-Queue-Id: 48FlD11vn5z3wmN X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.91 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.978,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.97)[-0.972,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(0.04)[ip: (0.06), ipnet: 130.225.0.0/16(0.07), asn: 1835(0.08), country: EU(-0.01)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 10:10:42 -0000 -------- In message <97A66670F59C9C626B5090E3@triton.njm.me.uk>, "N.J. Mann" writes: >Hi, > >On Saturday, February 08, 2020 19:30:31 +0000 Poul-Henning Kamp wrote: >> >> Thanks for looking into this. >> >> Is at(1) something people actually use these days, or should it be >> disabled by default ? > >I do. I use it to run various homebrew scripts in response to external >events. I needed a delay (sometime minutes, sometimes hours) between >the event and the response and at(1) was a perfect fit. Right, it is absolutely useful to have, if you need it, and it should not be removed. But if, as I suspect, the vast majority of FreeBSD pointlessly add 288 lines to /var/log/cron every day, without anybody ever using the at(1) command, maybe we should disable it to save power and disk-wear ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Sun Feb 9 13:38:00 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A002123988D for ; Sun, 9 Feb 2020 13:38:00 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48FqqC2SLdz49Fv for ; Sun, 9 Feb 2020 13:37:58 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 0mmXjpM1NkqGX0mmZjtz8k; Sun, 09 Feb 2020 06:37:57 -0700 X-Authority-Analysis: v=2.3 cv=c/jVvi1l c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=l697ptgUJYAA:10 a=IPjA-QJCAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=Chdz1smtSHJfnHFK3T0A:9 a=QEXdDO2ut3YA:10 a=rd03tn_Jzo6Lv0OJAoBv:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [192.168.1.105] (S0106002401cb186f.gv.shawcable.net [70.67.125.17]) by spqr.komquats.com (Postfix) with ESMTPSA id 230201558; Sun, 9 Feb 2020 05:37:53 -0800 (PST) Date: Sun, 09 Feb 2020 05:37:51 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <8967.1581243035@critter.freebsd.dk> References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: updating cron and atrun To: freebsd-arch@freebsd.org, Poul-Henning Kamp , "N.J. Mann" From: Cy Schubert Message-ID: <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> X-CMAE-Envelope: MS4wfI3RDfzk3kSE5bna6iGjsNGKQ/vCy6OuZjjtXjLE5PP9vMJozRyWzW2DNAz4i2GsA7ZWinnYfStHBwg2+IHumQbQmMJGIeuZ2hIcNm5ySuvpv8DCRF28 GjgQcmfAIJPXbRz6PgUCTtEqBt4fjRDAXmLhxj99Dr2kdc/BvK3v/GbBXJuKxfxaAQ95d4hzSKOW54QDFAC32X5Oqf/Vq57QCWoDdd3pMMuJEdIhcGSC1Q+V 1efgapK7QxkC8vZd2F6L3A== X-Rspamd-Queue-Id: 48FqqC2SLdz49Fv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.9) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.68 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RWL_MAILSPIKE_GOOD(0.00)[9.134.59.64.rep.mailspike.net : 127.0.0.18]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[9.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.48)[ip: (-6.60), ipnet: 64.59.128.0/20(-3.21), asn: 6327(-2.50), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 13:38:00 -0000 On February 9, 2020 2:10:35 AM PST, Poul-Henning Kamp wrote: >-------- >In message <97A66670F59C9C626B5090E3@triton=2Enjm=2Eme=2Euk>, "N=2EJ=2E M= ann" >writes: >>Hi, >> >>On Saturday, February 08, 2020 19:30:31 +0000 Poul-Henning Kamp wrote: >>>=20 >>> Thanks for looking into this=2E >>>=20 >>> Is at(1) something people actually use these days, or should it be >>> disabled by default ? >> >>I do=2E I use it to run various homebrew scripts in response to >external >>events=2E I needed a delay (sometime minutes, sometimes hours) between >>the event and the response and at(1) was a perfect fit=2E > >Right, it is absolutely useful to have, if you need it, and it should >not be removed=2E > >But if, as I suspect, the vast majority of FreeBSD pointlessly add=20 >288 lines to /var/log/cron every day, without anybody ever using the >at(1) >command, maybe we should disable it to save power and disk-wear ? I use at at(1) and batch(1) all the time, on FreeBSD and other platforms= =2E Most people I know, professionally, don't know about these commands=2E = They add the 288 lines to cron every day=2E They're not interested when I e= xplain to them a better way to do it=2E What's worse, at $JOB, at(1) and ba= tch(1) have been uninstalled on Linux (while they remain on the other platf= orms) because the senior Linux person (who left our employ three weeks ago)= felt people didn't understand the utilities and, they could add anything t= o cron for a day if they wanted=2E=20 The idea of removing at(1) and batch(1) is not new=2E People generally hav= e no idea what they do and people are unwilling to chance using them or lea= rning something new because they're busy working=2E That's my experience=2E= =20 --=20 Pardon the typos and autocorrect, small keyboard in use=2E=20 Cy Schubert FreeBSD UNIX: Web: https://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-arch@freebsd.org Sun Feb 9 13:50:40 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D827239B98 for ; Sun, 9 Feb 2020 13:50:40 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Fr5q4fCYz49pZ for ; Sun, 9 Feb 2020 13:50:39 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 0myqjpQRjkqGX0mysjtzu9; Sun, 09 Feb 2020 06:50:38 -0700 X-Authority-Analysis: v=2.3 cv=c/jVvi1l c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=l697ptgUJYAA:10 a=YxBL1-UpAAAA:8 a=IPjA-QJCAAAA:8 a=6I5d2MoRAAAA:8 a=lJRbTvJ3zpmObT4y8VoA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=rd03tn_Jzo6Lv0OJAoBv:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 728D215E9; Sun, 9 Feb 2020 05:50:36 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 019DoadO084567; Sun, 9 Feb 2020 05:50:36 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 019DoZrf084564; Sun, 9 Feb 2020 05:50:35 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202002091350.019DoZrf084564@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-arch@freebsd.org, Poul-Henning Kamp , "N.J. Mann" Subject: Re: updating cron and atrun In-reply-to: <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> Comments: In-reply-to Cy Schubert message dated "Sun, 09 Feb 2020 05:37:51 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2020 05:50:35 -0800 X-CMAE-Envelope: MS4wfI5vBPyd88lIuRjwaXaekWyxCGbwISSmL72zx9qWrg6zGyYnE8oowJREvSKwXNaMP7/kcB1IM79r58K7JmQlSx1VvZDElCfLcyw3C5xyckGGiSZVNFh1 g2hmdOnXSLjWnJmWkRHJ5NIozTLEZjDNNbO96NOBOP/sDSSyyHVGK80t79Z5Qo3lVIiQkfYCcvCNqCJwH3o34VhUzgpJquoJGdi4FfurukbwQmOzZK23RWSI cpgS4d/j0uF5EYQWcA35DQ== X-Rspamd-Queue-Id: 48Fr5q4fCYz49pZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.13) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.18 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.48)[ip: (-6.59), ipnet: 64.59.128.0/20(-3.21), asn: 6327(-2.50), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 13:50:40 -0000 In message <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com>, Cy Schubert wr ites: > On February 9, 2020 2:10:35 AM PST, Poul-Henning Kamp wr > ote: > >-------- > >In message <97A66670F59C9C626B5090E3@triton.njm.me.uk>, "N.J. Mann" > >writes: > >>Hi, > >> > >>On Saturday, February 08, 2020 19:30:31 +0000 Poul-Henning Kamp wrote: > >>> > >>> Thanks for looking into this. > >>> > >>> Is at(1) something people actually use these days, or should it be > >>> disabled by default ? > >> > >>I do. I use it to run various homebrew scripts in response to > >external > >>events. I needed a delay (sometime minutes, sometimes hours) between > >>the event and the response and at(1) was a perfect fit. > > > >Right, it is absolutely useful to have, if you need it, and it should > >not be removed. > > > >But if, as I suspect, the vast majority of FreeBSD pointlessly add > >288 lines to /var/log/cron every day, without anybody ever using the > >at(1) > >command, maybe we should disable it to save power and disk-wear ? > > I use at at(1) and batch(1) all the time, on FreeBSD and other platforms. Mos > t people I know, professionally, don't know about these commands. They add th > e 288 lines to cron every day. They're not interested when I explain to them > a better way to do it. What's worse, at $JOB, at(1) and batch(1) have been un > installed on Linux (while they remain on the other platforms) because the sen > ior Linux person (who left our employ three weeks ago) felt people didn't und > erstand the utilities and, they could add anything to cron for a day if they > wanted. > > The idea of removing at(1) and batch(1) is not new. People generally have no > idea what they do and people are unwilling to chance using them or learning s > omething new because they're busy working. That's my experience. Looking at the wiki page, integration of atrun into cron as NetBSD has done, is obvious. Solaris, HP-UX and every other platform I've used (which is no longer produced today) have had the atrun functionality performed by cron itself. This is a no brainer. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Sun Feb 9 15:32:36 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6391523BC75 for ; Sun, 9 Feb 2020 15:32:36 +0000 (UTC) (envelope-from josh@kflag.net) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48FtMR2fKvz4G9K for ; Sun, 9 Feb 2020 15:32:35 +0000 (UTC) (envelope-from josh@kflag.net) Received: by mail-ed1-x52f.google.com with SMTP id j17so5698959edp.3 for ; Sun, 09 Feb 2020 07:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kflag.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MyZVHGVIibesbFVg5X36uBcw5zQXvuXD/nhcFSmubDs=; b=BKQbKXsCrRJYOsdW7Lp3q4hkvfiXuy2q2AtJKl5sK+49reBeu8ZTqAYprmgqXzehOh kHvBw5tedACNHInRWw3kzMdMcMKH8e5ufWbPzBFrdBHI+bTNAzTDxxlpcX10GHyXJEJs v3XcyVtFKFtrshSTSnNz73ocJ+DyB7F3SKfas= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MyZVHGVIibesbFVg5X36uBcw5zQXvuXD/nhcFSmubDs=; b=bn29qu3MtNW/7q/dpw2wO1X8wvjDiJ5QXUVg7Xok/MzwQGWvzYTOWZjW5zczs0KCJo +OJj8qrQz2cQmD9dKi0lBaycH8TBTjRJEZcFeRfGFk2tt+Tzx3ZTUfqf7PO00HiD6UHj RX+tmVLN/HcIlhNPZ95rlhyGjPYDYpYpRIMoiV91JVsJ5omRguQYNc7ockFUqrkUnKX8 FCFokEKNA8WEEj/TSbU2Vw69FaJK1bDxPmk9JbjfiId0g4q/NGYQdXQDiv1w4Ak8XY7O NcjlYDezsWfxA2OPFXTKu8lQ21XYHsmurUbMhoNIR1Ij3pWDXhxD/RqBhChd66xREYIe Q/qQ== X-Gm-Message-State: APjAAAWqT6u1zZlrCwq+mgXu1FaUsdQA/9S+VgjyHC+ruvfox+Kmqqnl dUkhCdJtf6p2Lp6Vd6w2hBOAkKNxm5AI7BdSHHhdGMWMvcw= X-Google-Smtp-Source: APXvYqyCtHsw3qbJ+aPz18tW6B6K2b7KDbW7SBx210qrb+KSeZFT33P5UScopY+U/4N04esFgzLo7pn8d8YfnKHvkxE= X-Received: by 2002:a05:6402:c0e:: with SMTP id co14mr6810231edb.192.1581262352531; Sun, 09 Feb 2020 07:32:32 -0800 (PST) MIME-Version: 1.0 References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> <202002091350.019DoZrf084564@slippy.cwsent.com> In-Reply-To: <202002091350.019DoZrf084564@slippy.cwsent.com> From: Josh Aas Date: Sun, 9 Feb 2020 15:32:21 -0500 Message-ID: Subject: Re: updating cron and atrun To: Cy Schubert Cc: freebsd-arch@freebsd.org, Poul-Henning Kamp , "N.J. Mann" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48FtMR2fKvz4G9K X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=kflag.net header.s=google header.b=BKQbKXsC; dmarc=none; spf=none (mx1.freebsd.org: domain of josh@kflag.net has no SPF policy when checking 2a00:1450:4864:20::52f) smtp.mailfrom=josh@kflag.net X-Spamd-Result: default: False [-1.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[kflag.net:s=google]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[kflag.net]; DATE_IN_FUTURE(4.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[kflag.net:+]; RCVD_IN_DNSWL_NONE(0.00)[f.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.77)[ip: (-9.56), ipnet: 2a00:1450::/32(-2.48), asn: 15169(-1.73), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 15:32:36 -0000 There seems to be a real question here about the value of at/atrun. Maybe a good compromise is to move that functionality to ports instead of the base system. If we integrate the functionality into cron then we're basically stuck with it in core. All functionality adds complexity, and complexity adds maintenance cost and risk. Sometimes that's totally worth it, but I don't think it's clear that saddling FreeBSD base with at/atrun because we integrated it with cron for unclear reasons is necessarily a good idea. On Sun, Feb 9, 2020 at 8:50 AM Cy Schubert wrote: > > In message <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com>, Cy > Schubert wr > ites: > > On February 9, 2020 2:10:35 AM PST, Poul-Henning Kamp wr > > ote: > > >-------- > > >In message <97A66670F59C9C626B5090E3@triton.njm.me.uk>, "N.J. Mann" > > >writes: > > >>Hi, > > >> > > >>On Saturday, February 08, 2020 19:30:31 +0000 Poul-Henning Kamp wrote: > > >>> > > >>> Thanks for looking into this. > > >>> > > >>> Is at(1) something people actually use these days, or should it be > > >>> disabled by default ? > > >> > > >>I do. I use it to run various homebrew scripts in response to > > >external > > >>events. I needed a delay (sometime minutes, sometimes hours) between > > >>the event and the response and at(1) was a perfect fit. > > > > > >Right, it is absolutely useful to have, if you need it, and it should > > >not be removed. > > > > > >But if, as I suspect, the vast majority of FreeBSD pointlessly add > > >288 lines to /var/log/cron every day, without anybody ever using the > > >at(1) > > >command, maybe we should disable it to save power and disk-wear ? > > > > I use at at(1) and batch(1) all the time, on FreeBSD and other platforms. Mos > > t people I know, professionally, don't know about these commands. They add th > > e 288 lines to cron every day. They're not interested when I explain to them > > a better way to do it. What's worse, at $JOB, at(1) and batch(1) have been un > > installed on Linux (while they remain on the other platforms) because the sen > > ior Linux person (who left our employ three weeks ago) felt people didn't und > > erstand the utilities and, they could add anything to cron for a day if they > > wanted. > > > > The idea of removing at(1) and batch(1) is not new. People generally have no > > idea what they do and people are unwilling to chance using them or learning s > > omething new because they're busy working. That's my experience. > > Looking at the wiki page, integration of atrun into cron as NetBSD has > done, is obvious. Solaris, HP-UX and every other platform I've used (which > is no longer produced today) have had the atrun functionality performed by > cron itself. This is a no brainer. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- Josh Aas (215) 206-2020 From owner-freebsd-arch@freebsd.org Sun Feb 9 16:05:22 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9F0A23C601 for ; Sun, 9 Feb 2020 16:05:22 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Fv5F4RXGz4Hcn for ; Sun, 9 Feb 2020 16:05:21 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 0p59jnsFF17ZD0p5BjbEaw; Sun, 09 Feb 2020 09:05:19 -0700 X-Authority-Analysis: v=2.3 cv=ZsqT1OzG c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=l697ptgUJYAA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=s3EZtcUAOfy32GJ4gGgA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 3A41816CC; Sun, 9 Feb 2020 08:05:15 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 019G5DdR051415; Sun, 9 Feb 2020 08:05:13 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 019G5Csj051412; Sun, 9 Feb 2020 08:05:13 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202002091605.019G5Csj051412@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Josh Aas cc: Cy Schubert , freebsd-arch@freebsd.org, Poul-Henning Kamp , "N.J. Mann" Subject: Re: updating cron and atrun In-reply-to: References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> <202002091350.019DoZrf084564@slippy.cwsent.com> Comments: In-reply-to Josh Aas message dated "Sun, 09 Feb 2020 15:32:21 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2020 08:05:12 -0800 X-CMAE-Envelope: MS4wfHdgmxATetuZ7Pid799T+at5/oBaY9Z+imDlrHyFgVOBlPz0FrKX1SKnbY4xNyrxw/XSr86lzLqs8xGWFszleeqtCe8+5WnXkHF24QjQpwMzmK2gi6CY X8cdQVObKDZ22pvIR0mnwqQV0TpPgdNxAzMGgydyi4FixrvmghFL11OmoT7oGd3asDepJdneHIT6DOCzq7BiCv9zMI+7wHRfqFrp5W2mJAd7h3hSz+2XCw5Q CTKec5SNRRooqUvai2Fp8E1E3WQHF4I+S7DJYKIxRGU= X-Rspamd-Queue-Id: 48Fv5F4RXGz4Hcn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.139) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.07 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RWL_MAILSPIKE_POSSIBLE(0.00)[139.136.59.64.rep.mailspike.net : 127.0.0.17]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[139.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.37)[ip: (-6.05), ipnet: 64.59.128.0/20(-3.21), asn: 6327(-2.50), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 16:05:22 -0000 In message , Josh Aas writes: > There seems to be a real question here about the value of at/atrun. > Maybe a good compromise is to move that functionality to ports instead > of the base system. If we integrate the functionality into cron then > we're basically stuck with it in core. All functionality adds > complexity, and complexity adds maintenance cost and risk. Sometimes > that's totally worth it, but I don't think it's clear that saddling > FreeBSD base with at/atrun because we integrated it with cron for > unclear reasons is necessarily a good idea. That is not a compromise. The functionality has been in cron in Solaris, AIX, HP-UX, DG/UX, Tru64, and now NetBSD for years, in some cases decades. Why such a reluctance to maintain basic functionality because it is either not understood or you never use it? Atrun should be integrated into cron, where all other major UNIX and UNIX-like systems have the function. However when we implement pkgbase crond(8), crontab(1), and at(1)/batch(1) should be three separate packages, like Linux distros do. crond(8) could be installed by default whereas crontab(1) and at(1)/batch(1) would not. Moving at(1) and batch(1) to ports would be tantamount to putting vi in ports because, well, nano is an easier to use editor. (Yes, we did that at $JOB on our RHEL servers for a while because vi is too hard for most people to use, it used up valuable space, and only installed it if a customer specifically requested it. That policy is no more but that it was makes my point. We now install vim and nano.) You get my point. The fact that some people don't understand a utility and don't have the time or patience to learn it (yes, we're all busy, like at $JOB, and taking time out to learn something, like at $JOB, has a cost) doesn't mean it's not useful. Coming from a SunOS, Solaris, HP-UX, DG/UX, Tru64 background, at(1) and batch(1) are a basic function of cron, even if some in the Linux community feel they're not. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Sun Feb 9 17:25:04 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D5EC23DC7C for ; Sun, 9 Feb 2020 17:25:04 +0000 (UTC) (envelope-from josh@kflag.net) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48FwsB482Dz4LsW for ; Sun, 9 Feb 2020 17:25:02 +0000 (UTC) (envelope-from josh@kflag.net) Received: by mail-ed1-x52f.google.com with SMTP id dc19so5874933edb.10 for ; Sun, 09 Feb 2020 09:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kflag.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W7+VUm/gVT9tZV7gQJFh1ikmZsClR9I7C5V7DeaPyNo=; b=Hp0M4lDWFUrZoYKBvvhWEIQQnjqH1jqTqOmgxC5aq+2QAp1YSQRHwwRnxlnIrypBrJ d7WgtAerNZvzfntXi0jwjuVqYyj5EaRiocy7j0qJdlN59gzlaY4Yyu+7TEQy0HpynFu9 2lr/ecn/tKgjS3QrYvN9wQYU1hpyfrfFftPMs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W7+VUm/gVT9tZV7gQJFh1ikmZsClR9I7C5V7DeaPyNo=; b=qxpSLoVrhuhLgHKTFnuhnVEqsJj7hYuMlkEYCBBkwrA2lL5SkjsUdQMwhBPAl9nuvW 1fcEDDBxHlRxRaSfQH+8bMfy96BIuAk9W5Yg3nu9JfCoFAirC9JvASJ+YvtBaCUgJtl7 aLdqyA3ZxnoHqjg+TapEG/FbKENpe1QLO8EckYpHNXhSAfPCBQr7eni5U1aoSa0tFaMq 1Dx7eeG3RrImBEl60MsKjpASBp0gtYyh6vu5h1qtrIboGUN0fAwtDPpsl1OYPPxLT4UN 3T+vau28VX4eOVb6Bjwpj+lgK3dKha2SzAKihVtpa2Otn5lVma/K7AFzwGWe+Ime6BDZ /Y9g== X-Gm-Message-State: APjAAAVo/5x3gjsaMF0BmFSj3R9ye46MCag3ZeGoeGfkJJn3S9InLi3V IkxGVPlv1Cj6onyGwZUyLR/JKGK5dTWtjumdTSxhLGnvowA5kQ== X-Google-Smtp-Source: APXvYqxLJ04nULYVgqDZAlpxWofIc2+CyfG6PxQFBwmNm7erwHi3659m6YJRRTtQWmxknNzi/n1N5hcOjcRcitOqr8c= X-Received: by 2002:a17:906:2649:: with SMTP id i9mr8518054ejc.120.1581269100848; Sun, 09 Feb 2020 09:25:00 -0800 (PST) MIME-Version: 1.0 References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> <202002091350.019DoZrf084564@slippy.cwsent.com> <202002091605.019G5Csj051412@slippy.cwsent.com> In-Reply-To: <202002091605.019G5Csj051412@slippy.cwsent.com> From: Josh Aas Date: Sun, 9 Feb 2020 17:24:50 -0500 Message-ID: Subject: Re: updating cron and atrun To: Cy Schubert Cc: freebsd-arch@freebsd.org, Poul-Henning Kamp , "N.J. Mann" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48FwsB482Dz4LsW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=kflag.net header.s=google header.b=Hp0M4lDW; dmarc=none; spf=none (mx1.freebsd.org: domain of josh@kflag.net has no SPF policy when checking 2a00:1450:4864:20::52f) smtp.mailfrom=josh@kflag.net X-Spamd-Result: default: False [-1.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[kflag.net:s=google]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[kflag.net]; DATE_IN_FUTURE(4.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[kflag.net:+]; RCVD_IN_DNSWL_NONE(0.00)[f.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.76)[ip: (-9.55), ipnet: 2a00:1450::/32(-2.48), asn: 15169(-1.73), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 17:25:04 -0000 I understand that some other operating systems have integrated atrun into cron, but that's not, in and of itself, a reason for FreeBSD to do it. Other operating systems do lots of things not worth copying in FreeBSD. I'm curious to hear if there are actual technical reasons that it's worthwhile for FreeBSD to do it. Even if such integration advantages do exist, they might rest on the assumption that at/atrun is worth keeping in base in the first place. >From what you and others have said, maybe at/atrun doesn't deserve "basic functionality" status you're ascribing to it. I don't know, I'm not an expert on this, but it's a perspective that seems worth considering. In an earlier email you said "People generally have no idea what they do and people are unwilling to chance using them or learning something new..." That doesn't sound like a description of "basic functionality" that necessarily needs to be a part of a base operating system. Vi is a very heavily used program, which many people appreciate being available in base. That is not the case for "at." It's something a small minority of people appreciate, but nonetheless, I agree that they should have access to it. Sounds to me like a great candidate for inclusion in ports. I imagine the default position should be that things are not in base unless there's a strong argument for it, not the other way around. Does FreeBSD have a set of written guidelines for what makes something appropriate for inclusion in the base system? On Sun, Feb 9, 2020 at 11:05 AM Cy Schubert wrote: > > In message om> > , Josh Aas writes: > > There seems to be a real question here about the value of at/atrun. > > Maybe a good compromise is to move that functionality to ports instead > > of the base system. If we integrate the functionality into cron then > > we're basically stuck with it in core. All functionality adds > > complexity, and complexity adds maintenance cost and risk. Sometimes > > that's totally worth it, but I don't think it's clear that saddling > > FreeBSD base with at/atrun because we integrated it with cron for > > unclear reasons is necessarily a good idea. > > That is not a compromise. The functionality has been in cron in Solaris, > AIX, HP-UX, DG/UX, Tru64, and now NetBSD for years, in some cases decades. > Why such a reluctance to maintain basic functionality because it is either > not understood or you never use it? > > Atrun should be integrated into cron, where all other major UNIX and > UNIX-like systems have the function. However when we implement pkgbase > crond(8), crontab(1), and at(1)/batch(1) should be three separate packages, > like Linux distros do. crond(8) could be installed by default whereas > crontab(1) and at(1)/batch(1) would not. > > Moving at(1) and batch(1) to ports would be tantamount to putting vi in > ports because, well, nano is an easier to use editor. (Yes, we did that at > $JOB on our RHEL servers for a while because vi is too hard for most people > to use, it used up valuable space, and only installed it if a customer > specifically requested it. That policy is no more but that it was makes my > point. We now install vim and nano.) You get my point. The fact that some > people don't understand a utility and don't have the time or patience to > learn it (yes, we're all busy, like at $JOB, and taking time out to learn > something, like at $JOB, has a cost) doesn't mean it's not useful. > > Coming from a SunOS, Solaris, HP-UX, DG/UX, Tru64 background, at(1) and > batch(1) are a basic function of cron, even if some in the Linux community > feel they're not. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > > > > > > -- Josh Aas (215) 206-2020 From owner-freebsd-arch@freebsd.org Sun Feb 9 18:09:33 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9453823E671 for ; Sun, 9 Feb 2020 18:09:33 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48FxrX1FScz4NVD for ; Sun, 9 Feb 2020 18:09:31 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 0r1LjrFwDkqGX0r1NjuVOb; Sun, 09 Feb 2020 11:09:30 -0700 X-Authority-Analysis: v=2.3 cv=c/jVvi1l c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=l697ptgUJYAA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=cFx_Lm0oVjccnbMKx5QA:9 a=CjuIK1q_8ugA:10 a=R6B07855qDQA:10 a=oFZIFQFHCoMA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 52C1D17CD; Sun, 9 Feb 2020 10:09:26 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 019I9QbA051987; Sun, 9 Feb 2020 10:09:26 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 019I9P9D051984; Sun, 9 Feb 2020 10:09:25 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202002091809.019I9P9D051984@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Josh Aas cc: Cy Schubert , freebsd-arch@freebsd.org, Poul-Henning Kamp , "N.J. Mann" Subject: Re: updating cron and atrun In-reply-to: References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> <202002091350.019DoZrf084564@slippy.cwsent.com> <202002091605.019G5Csj051412@slippy.cwsent.com> Comments: In-reply-to Josh Aas message dated "Sun, 09 Feb 2020 17:24:50 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2020 10:09:25 -0800 X-CMAE-Envelope: MS4wfKXjgEqkBKCOQg0Wdyajty4YpXprFZRiNIcqMzMm72w7TadhHPxXE52XgnrK1GDC2AYXMeiztJOOp41R+IojdTXZ6jhKDmmNlWoxo7JJeuN3qloo6Tw5 LMD/GaHNxDVUY7h50XSfLTZ5yMiYTMyP+y3Vc1nxE8ozDQSTmUwQEMdgd9kJ9tIA17H54xXKv2mMKoF1PR792vaNQMRMkzxez/UNQPPPp6cCqpfiHaDdQDcb b2lD3WgZzC4D1zr2SqhdKzkKhhGs3TOcEN8tJiwn5o0= X-Rspamd-Queue-Id: 48FxrX1FScz4NVD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.13) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.17 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.47)[ip: (-6.57), ipnet: 64.59.128.0/20(-3.21), asn: 6327(-2.50), country: CA(-0.09)]; RCVD_IN_DNSWL_LOW(-0.10)[13.134.59.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2020 18:09:33 -0000 In message , Josh Aas writes: > I understand that some other operating systems have integrated atrun > into cron, but that's not, in and of itself, a reason for FreeBSD to > do it. Other operating systems do lots of things not worth copying in > FreeBSD. I'm curious to hear if there are actual technical reasons > that it's worthwhile for FreeBSD to do it. Because at(1) and batch(1) are immensely useful everyday tools. > > Even if such integration advantages do exist, they might rest on the > assumption that at/atrun is worth keeping in base in the first place. Of course they are worth keeping. I haven't heard a good reason to remove them. > >From what you and others have said, maybe at/atrun doesn't deserve > "basic functionality" status you're ascribing to it. I don't know, I'm > not an expert on this, but it's a perspective that seems worth > considering. In an earlier email you said "People generally have no > idea what they do and people are unwilling to chance using them or > learning something new..." That doesn't sound like a description of > "basic functionality" that necessarily needs to be a part of a base > operating system. It explains why people are unwilling to use tools they've never used before. > > Vi is a very heavily used program, which many people appreciate being > available in base. I'm not advocating removal of vi. I'm drawing parallels, real life examples from $JOB. > That is not the case for "at." It's something a > small minority of people appreciate, but nonetheless, I agree that > they should have access to it. Do we really know that it's a small minority of people? How do you know that? I come from the position of having used the tools for 25 or more years. You come from the position of never having used or > Sounds to me like a great candidate for > inclusion in ports. Pkgbase will resolve this. You pick and choose what you want. I've advocated for pkgbase for a while. You can choose whether to install the cron in pkgbase, use one of the many cron-like tools in ports, or a collection of scripts. > I imagine the default position should be that > things are not in base unless there's a strong argument for it, not > the other way around. That's the point of pkgbase. Packages in base would have the status as ports, just like any Linux distro. You pick and choose what you want and packages would be grouped like they are in an anaconda install. > Does FreeBSD have a set of written guidelines > for what makes something appropriate for inclusion in the base system? Like many organizations (like $JOB) much of this isn't written down, like it should be. Just like $JOB it can be gleaned from mail archives. This is obviously not ideal because it's open to debate and subjective interpretation. This might be a good idea then again maybe not. If we take the justice system as an example, we can either codify things to death (like some jurisdictions do) or we codify less and base our decisions on precedence. This can be argued both ways. I think we do more of the latter here. My vote would be to base our cron on NetBSD or OpenBSD. Make cron, crontab, and at/batch build options and pkgbase packages. Additionally, a dialog to allow users to pick and choose which options to enable/disable to configure src.conf, similar to sysrc(8), might be compromise. As you don't use at(1) but other people do doesn't automatically suggest or require the removal of the tool. You're trying to convince us to remove a useful tool, the onus is on you to build a good case for removal. I haven't seen good business case in your arguments so far? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. > > On Sun, Feb 9, 2020 at 11:05 AM Cy Schubert wrote > : > > > > In message c > > om> > > , Josh Aas writes: > > > There seems to be a real question here about the value of at/atrun. > > > Maybe a good compromise is to move that functionality to ports instead > > > of the base system. If we integrate the functionality into cron then > > > we're basically stuck with it in core. All functionality adds > > > complexity, and complexity adds maintenance cost and risk. Sometimes > > > that's totally worth it, but I don't think it's clear that saddling > > > FreeBSD base with at/atrun because we integrated it with cron for > > > unclear reasons is necessarily a good idea. > > > > That is not a compromise. The functionality has been in cron in Solaris, > > AIX, HP-UX, DG/UX, Tru64, and now NetBSD for years, in some cases decades. > > Why such a reluctance to maintain basic functionality because it is either > > not understood or you never use it? > > > > Atrun should be integrated into cron, where all other major UNIX and > > UNIX-like systems have the function. However when we implement pkgbase > > crond(8), crontab(1), and at(1)/batch(1) should be three separate packages, > > like Linux distros do. crond(8) could be installed by default whereas > > crontab(1) and at(1)/batch(1) would not. > > > > Moving at(1) and batch(1) to ports would be tantamount to putting vi in > > ports because, well, nano is an easier to use editor. (Yes, we did that at > > $JOB on our RHEL servers for a while because vi is too hard for most people > > to use, it used up valuable space, and only installed it if a customer > > specifically requested it. That policy is no more but that it was makes my > > point. We now install vim and nano.) You get my point. The fact that some > > people don't understand a utility and don't have the time or patience to > > learn it (yes, we're all busy, like at $JOB, and taking time out to learn > > something, like at $JOB, has a cost) doesn't mean it's not useful. > > > > Coming from a SunOS, Solaris, HP-UX, DG/UX, Tru64 background, at(1) and > > batch(1) are a basic function of cron, even if some in the Linux community > > feel they're not. > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > > The need of the many outweighs the greed of the few. > > > > > > > > > > > > > > > > > > > -- > Josh Aas > (215) 206-2020 From owner-freebsd-arch@freebsd.org Mon Feb 10 21:38:11 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7417724530A for ; Mon, 10 Feb 2020 21:38:11 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48GfQn75N6z45Lh for ; Mon, 10 Feb 2020 21:38:09 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01ALSZOf005047; Mon, 10 Feb 2020 13:38:05 -0800 Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2051.outbound.protection.outlook.com [104.47.46.51]) by mx0b-00273201.pphosted.com with ESMTP id 2y37fbgvd3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Feb 2020 13:38:05 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UPVrDfgucQJAUvWX4IUFhrbF1+MBBl6+AH7MY/bnwu98bgO9gjRFbgZOCzxG53QCfSbi++Fa2/n40GdJA4L/Ke+z6qcWB605Uqpy/H6nteR9Yt5VsPgATwZdtWwEkDjHRwj0am5k2Qc84/mzA4yK7T+Sxp4vPxz+U8CnqEAqu6qUcFp+uo8qfFgp2gz+ksfRzFF9KklEJgVtHe9FRPdzE1QhWmWt3guua4zCbu3u1WvH5tOvc+b0R1AM50/i89VaFRozqUNq7U2jpMtdbWOHzD0jez22i+CgLUdGGRqv2LuE+CxZDmPaxAn5C03WBBPYDrIby5EpAPFcn7ju92XRyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2NrTAqwZXs5QGBB12Kc3sA+Z2BD5YT4LWljjQ9u+tp0=; b=JGRXsYQspsZ2asz9HCtBDf6kqbGeAk+9fgw9xt5ddeFYr23zBlMwTZYSEYMVzu0XOpKfwjcynP2mBE/SsXHP2n5PaF5uA3WJmWmmiVUTJCiX95FxEdl7U2KF1etvpG1ENShi9fSfX16YWJHPnDTUjXW4JOIpHURTmZ6zluVEVQehiPx5c0LfbHLOIfT3Wu+7Gl8FtLHsBU7RylIBwoa2zrfG31ym+E+n3flFUg32VyehYy6DzMlGAD+ccoqS9u/Re8sqCieT52G/yw4oZ+wK45Glsr07Cx+gn7xyoaMWOvgecLyKXLEukK8i3FdT8sKkNAXEmOEyAgA/o9FacCrZGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.13) smtp.rcpttodomain=phk.freebsd.dk smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none Received: from CH2PR05CA0007.namprd05.prod.outlook.com (2603:10b6:610::20) by BYAPR05MB5094.namprd05.prod.outlook.com (2603:10b6:a03:9d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.20; Mon, 10 Feb 2020 21:38:03 +0000 Received: from DM3NAM05FT026.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::209) by CH2PR05CA0007.outlook.office365.com (2603:10b6:610::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.16 via Frontend Transport; Mon, 10 Feb 2020 21:38:03 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.13 as permitted sender) Received: from P-EXFEND-EQX-02.jnpr.net (66.129.242.13) by DM3NAM05FT026.mail.protection.outlook.com (10.152.98.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2729.10 via Frontend Transport; Mon, 10 Feb 2020 21:38:02 +0000 Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 10 Feb 2020 13:38:02 -0800 Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 10 Feb 2020 13:38:02 -0800 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 10 Feb 2020 13:38:01 -0800 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.50.162]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 01ALbx9o021195; Mon, 10 Feb 2020 13:37:59 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id EDFC33157C; Mon, 10 Feb 2020 13:37:58 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id EC3E93157A; Mon, 10 Feb 2020 13:37:58 -0800 (PST) To: Josh Aas CC: Cy Schubert , Poul-Henning Kamp , "N.J. Mann" , , Subject: Re: updating cron and atrun In-Reply-To: References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> <202002091350.019DoZrf084564@slippy.cwsent.com> <202002091605.019G5Csj051412@slippy.cwsent.com> Comments: In-reply-to: Josh Aas message dated "Sun, 09 Feb 2020 17:24:50 -0500." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98531.1581370678.1@kaos.jnpr.net> Date: Mon, 10 Feb 2020 13:37:58 -0800 Message-ID: <584.1581370678@kaos.jnpr.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.242.13; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(346002)(376002)(39860400002)(189003)(199004)(70206006)(70586007)(7696005)(55016002)(9686003)(5660300002)(186003)(8676002)(7126003)(81166006)(81156014)(4744005)(3480700007)(86362001)(336012)(8936002)(478600001)(26005)(54906003)(26826003)(107886003)(316002)(356004)(6916009)(6266002)(4326008)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5094; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c64dc57f-c6a0-4b33-d7ec-08d7ae7181d8 X-MS-TrafficTypeDiagnostic: BYAPR05MB5094: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 03094A4065 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /NXxvFxviQ5vPOINutpui8FYrlCBpe1IZWnu8o8xsbfZ+bP5cP7sqFpXjh2UtxszKk1aQQwI1CQg6GN3+xVvnGhM4NSsKIgnltHaIydZLUFGirdoH+DoJ9QhY++vnV1ZgFJfvvrOFDKvw4xVTcGUM1/Um1JKeKlvKC+ibjB1B8jgeU7hU2Hn3x4uUcGO79XQ1uKDIf6HGGPaYCVGrgMsG/LyxaUNJkyKoCo3hFDMnQbq6CU4dwDu4bdtz8IBLwW6+Sx258OOjD5XKaRWwRXWsVgVwOmP+jLYQVE2Rvg7O6RCRplBOI0Ogr3PEmBKxR0AZ7Ub+osSY+/iRmBOj4fe9SMxV9mv/YXzGmYdyhv319H1iTf5OstXKI1k/+N2LlxskjcuD0v4LFNXNuSQW484KcWpW8rTx8rI7WlxB9XVyFTJC709wYT9aMM+e5TawNDH X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2020 21:38:02.8115 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c64dc57f-c6a0-4b33-d7ec-08d7ae7181d8 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.242.13]; Helo=[P-EXFEND-EQX-02.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5094 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-10_07:2020-02-10, 2020-02-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 lowpriorityscore=0 phishscore=0 clxscore=1011 malwarescore=0 suspectscore=0 priorityscore=1501 adultscore=0 spamscore=0 bulkscore=0 impostorscore=0 mlxlogscore=855 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002100150 X-Rspamd-Queue-Id: 48GfQn75N6z45Lh X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.72 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.62)[ip: (-3.99), ipnet: 67.231.152.0/24(-1.81), asn: 22843(-2.24), country: US(-0.05)]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; RCVD_IN_DNSWL_LOW(-0.10)[164.152.231.67.list.dnswl.org : 127.0.3.1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; ARC_ALLOW(-1.00)[i=1]; RCVD_COUNT_SEVEN(0.00)[11] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 21:38:11 -0000 Josh Aas wrote: > FreeBSD. I'm curious to hear if there are actual technical reasons > that it's worthwhile for FreeBSD to do it. Reduce the friction of people moving from other systems to FreeBSD? > considering. In an earlier email you said "People generally have no > idea what they do and people are unwilling to chance using them or > learning something new..." That doesn't sound like a description of > "basic functionality" that necessarily needs to be a part of a base > operating system. The whole argument about what the masses grok would lead everyone to adopt Windows. I've used at(1) extensively in the past, I consider it basic functionality. From owner-freebsd-arch@freebsd.org Mon Feb 10 22:32:47 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 043E024693B for ; Mon, 10 Feb 2020 22:32:47 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Ggdp1zbQz48HN for ; Mon, 10 Feb 2020 22:32:46 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-oi1-x241.google.com with SMTP id a22so10825777oid.13 for ; Mon, 10 Feb 2020 14:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uGkqIaeKBIL9GvzgjwNXm/8cz+YCA/PzwqDUp242STw=; b=gTGfVp8KPLwtfjgHiwg6KYnnzoQP1U98E2DRS6Z0q64lnKhHsbdhLZo1DEjSgFk8QU X6SpqbvRP5PCGWaLvH6dbHd4AMnNnkdtivgy8MU6c8WbY1umV2tuvwuvxZ690LZG1U80 7tEbtwa3UpA9m+JHC9ZD/IsVmRZsAEZM0Zeemdfw7Yk9nowNMRNxkqaFkT4COzRpQFAC bEth1L/DiDSCbu3HhwBHTwTeGW3qgYDT1Aif6vqyMrUGA6aubO07QW2S7pbhLe14tR2O PIVOnjlwfkXIH+tU8UufdvUVt8J4SNLp53LE9AH+jVpk57Gak6TldDwXGUaCNepJJUZK J2lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uGkqIaeKBIL9GvzgjwNXm/8cz+YCA/PzwqDUp242STw=; b=ToE46uNaxauN0dER0YkQnMBEtNo7bUoWe7JDdA7wI3N6U2K5nQ88m25Cmbkq7edOaX xUZJ1TC+cBiUvq64aXkeHSLIOESrmfuDX/mwGkTpDrdAJapDH7Rwhppe9u4bpxCJ3Fsl 1XYqvSzLIoadTCZiYjoueKGzuLSRCL2aKsyatAzQ8qS/NY1uhjkcGD69IDX3TFUSmuJl hr/YMUHdpK8SU02RYFIlDN9c1YDzW55wQRQV40V+bMbRW9+Quow5O5jVrx5/iu14SDvl k43PKzKxcUCFRZiGMG0Oa5wbKq2Ka8LdT0BhW222JO4uPksz6uLozitnkyz8ZFvOix2Y fuvw== X-Gm-Message-State: APjAAAUogqW3yfK+gCtL3de4ujq1BQhXdFLjtpVZZoI9iiE9NVjUF2XB 4raZTxmWpg2apM7Y/NA0aYB4TUeKM0uxnhg5VVI= X-Google-Smtp-Source: APXvYqyfG/bL5R8u6qMFgF81VlhBEBY4OhXn/6/L72bBWozpyzZYMh9Ke8mviobnA8werHkXunYQID+j9Mw9Bb4UaTg= X-Received: by 2002:aca:190a:: with SMTP id l10mr992586oii.56.1581373964771; Mon, 10 Feb 2020 14:32:44 -0800 (PST) MIME-Version: 1.0 References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> <202002091350.019DoZrf084564@slippy.cwsent.com> <202002091605.019G5Csj051412@slippy.cwsent.com> <584.1581370678@kaos.jnpr.net> In-Reply-To: <584.1581370678@kaos.jnpr.net> From: Xin LI Date: Mon, 10 Feb 2020 14:32:33 -0800 Message-ID: Subject: Re: updating cron and atrun To: "Simon J. Gerraty" Cc: Josh Aas , Poul-Henning Kamp , freebsd-arch@freebsd.org, "N.J. Mann" X-Rspamd-Queue-Id: 48Ggdp1zbQz48HN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=gTGfVp8K; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of delphij@gmail.com designates 2607:f8b0:4864:20::241 as permitted sender) smtp.mailfrom=delphij@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (2.02), ipnet: 2607:f8b0::/32(-1.95), asn: 15169(-1.72), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-Mailman-Approved-At: Tue, 11 Feb 2020 04:59:49 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 22:32:47 -0000 On Mon, Feb 10, 2020 at 1:38 PM Simon J. Gerraty via freebsd-arch < freebsd-arch@freebsd.org> wrote: > Josh Aas wrote: > > FreeBSD. I'm curious to hear if there are actual technical reasons > > that it's worthwhile for FreeBSD to do it. > > Reduce the friction of people moving from other systems to FreeBSD? > > > considering. In an earlier email you said "People generally have no > > idea what they do and people are unwilling to chance using them or > > learning something new..." That doesn't sound like a description of > > "basic functionality" that necessarily needs to be a part of a base > > operating system. > > The whole argument about what the masses grok would lead everyone to > adopt Windows. > > I've used at(1) extensively in the past, I consider it basic > functionality. > +1. Also note that it's not something that is high effort at all, because others have already implemented it, and did so in less than 700 lines of code, with license block included. I'd say bringing OpenBSD cron is a low hanging fruit if someone wants to do something in the project, and IMHO there is no reason to remove the functionality because of that. I have worked on bringing OpenBSD cron to FreeBSD a while ago (I think it was ~2012) but never committed it because subversion made my life hard (well, partially -- I should have created a branch on user/ but I didn't) to keep my local patches on the move to the point that eventually I have gave up maintaining it. Cheers, From owner-freebsd-arch@freebsd.org Fri Feb 14 22:42:29 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 788EB24502B for ; Fri, 14 Feb 2020 22:42:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48K7g92H91z4Mqs for ; Fri, 14 Feb 2020 22:42:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 410E410E6D for ; Fri, 14 Feb 2020 22:42:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f181.google.com with SMTP id l16so3417518qtq.1 for ; Fri, 14 Feb 2020 14:42:29 -0800 (PST) X-Gm-Message-State: APjAAAW0SN08ugfampanRIwIBb8tS+/dZ3L6X0znuIhsN1xsqwaCBM75 HTZhjGwHV7KFT6mjiIpSRH+uDX94fRJN44THA1Y= X-Google-Smtp-Source: APXvYqyGy3JG3glPDZNXN7o9kvF2Ok7gQXmMyAm2m8YEa5//d3bxoLIBE0Gz5BassOdaWBp7B6ecZwf5q5rVxH9pd5o= X-Received: by 2002:aed:3f70:: with SMTP id q45mr4374173qtf.310.1581720148756; Fri, 14 Feb 2020 14:42:28 -0800 (PST) MIME-Version: 1.0 From: Kyle Evans Date: Fri, 14 Feb 2020 16:42:15 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Return of config files to ^/etc To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 22:42:29 -0000 Hello, I've organized a review[0] to return most config files back to etc/. Many people were concerned about the mass exodus of etc/, and many have expressed a desire (privately or otherwise) for these files to return- some of these folks represent downstreams or consumer projects that went through the painful move the first time and would happily go through the pain again to restore the status quo. This does mean that we'd end up with a structure that's not compatible with stable/12, but is compatible with every branch before it. If you have an opinion for or against. please speak up now. I'd like to make sure we're moving in the correct direction as a developer community. Thanks, Kyle Evans [0] https://reviews.freebsd.org/D23690 From owner-freebsd-arch@freebsd.org Sat Feb 15 00:22:58 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CBAD02482DC for ; Sat, 15 Feb 2020 00:22:58 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48K9v64fXvz4VQg; Sat, 15 Feb 2020 00:22:58 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by mail-yw1-xc36.google.com with SMTP id l5so5092987ywd.4; Fri, 14 Feb 2020 16:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d52H6XH/1BMpG89d3vXVUT2qPr4MG9s5gbniQei+0H0=; b=ZD5jYgRA/7F5J1o4oTr7gcs4VLWtzQHPLRR4ZFbFDGbB+E80tk1sbKeRyCRx53/S7J JdUIEQjTvc3irwUiAxPjr3Z9VV0o6xlfpW191voycqtcBR71rITJWP/kuIgRertFyOTP kkXss9/xA3Z5T5trd58RcVbkKlptiPwNzSlSmIFix17gy7iQ5aqlGvIc2QGSGPFNd5YL FlLJdFqxaX6EnyPNp9o6MqgAbkvwKA+9MYNy3ICiaXz33N2GytlKePq++5IXGtacmCc3 Lh0i3j/yvmgooEylSyYa1wJgxhi5JMHclZOJiq0a+HbPDrHuSR8RL9yXH1UiZ++oXT2h EHog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d52H6XH/1BMpG89d3vXVUT2qPr4MG9s5gbniQei+0H0=; b=FUvyVLFSgIIXgvAgKJBRxhDt7fXNFfBdUNUbE8hqW3W9Fpm2o9M8N0nFywXGO/y31A WcJebRXOvuXyfNodlUJm1+yB5CKWtTMj7pQDrjiNiRexqTyQlt8azfBAMtzRUfoLevLT RSo+ow/KDhsHA53mWEMiHvxpJ+KGpFl0ZFAnjDSN01fVb+zHwoV6q8P6/2J6zwQz8WIj OlEHh+gCDylToU1MdyvpId5z94TCEJSotqBhe/5+94QG+AS0dLH78eKj4e2RPtvdFVxx pfV5MtkUzja3LHJzxp8wNwbMfW7R7JeSKQ8v54vrDJeTHOwRDjsHomwJWWRsvF/coRwW BYww== X-Gm-Message-State: APjAAAXlN8WVeUMjQ7BKLsuqbWSzHOF+imBMJv33nPb0/muzmKS8jo/8 gJRsxTLQ7piNKAdtsJ31/tG31es4n52cZR0kpL5eCQ== X-Google-Smtp-Source: APXvYqyLx2lDZSimWesgCPhHJRuvEWVPLz1qEFjfPuVVix718ONMVpLuvOVH9qodsq8q/SdiK4H9YsgVaAc9ZCgZIpY= X-Received: by 2002:a81:7845:: with SMTP id t66mr4773412ywc.222.1581726177689; Fri, 14 Feb 2020 16:22:57 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:8542:0:0:0:0:0 with HTTP; Fri, 14 Feb 2020 16:22:57 -0800 (PST) In-Reply-To: References: From: Oliver Pinter Date: Sat, 15 Feb 2020 01:22:57 +0100 Message-ID: Subject: Re: Return of config files to ^/etc To: Kyle Evans Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 48K9v64fXvz4VQg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 00:22:58 -0000 On Friday, February 14, 2020, Kyle Evans wrote: > Hello, > > I've organized a review[0] to return most config files back to etc/. > Many people were concerned about the mass exodus of etc/, and many > have expressed a desire (privately or otherwise) for these files to > return- some of these folks represent downstreams or consumer projects > that went through the painful move the first time and would happily go > through the pain again to restore the status quo. > > This does mean that we'd end up with a structure that's not compatible > with stable/12, but is compatible with every branch before it. > > If you have an opinion for or against. please speak up now. I'd like > to make sure we're moving in the correct direction as a developer > community. > > Thanks, > > Kyle Evans > > [0] https://reviews.freebsd.org/D23690 A very big yes. Please do it. It would be more straightforward and more backward compatible because the FreeBSD's repo is a monorepo. As far I remember, there was an mess around the password and groups file depending on the "default" shell. A sed magic or other black magic... > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Sat Feb 15 01:04:09 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A8949248E53 for ; Sat, 15 Feb 2020 01:04:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48KBpc5WrKz4XHQ; Sat, 15 Feb 2020 01:04:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id 2lsKjpJn0RnrK2lsLjZ8cu; Fri, 14 Feb 2020 18:04:06 -0700 X-Authority-Analysis: v=2.3 cv=L7FjvNb8 c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=l697ptgUJYAA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=8kpUjx5iP4ZCMYiC7DwA:9 a=CjuIK1q_8ugA:10 a=qa9l8WszXaMA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id 17C8E344; Fri, 14 Feb 2020 17:04:03 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id 01F142IG063965; Fri, 14 Feb 2020 17:04:02 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id 01F142eE063954; Fri, 14 Feb 2020 17:04:02 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202002150104.01F142eE063954@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Oliver Pinter cc: Kyle Evans , "freebsd-arch@freebsd.org" Subject: Re: Return of config files to ^/etc In-reply-to: References: Comments: In-reply-to Oliver Pinter message dated "Sat, 15 Feb 2020 01:22:57 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 2020 17:04:02 -0800 X-CMAE-Envelope: MS4wfEVua8a/wSo5Uzx2WFx7Nxnl0tqWUwBWLvSOWAG3z35l8ehqcA4xva5QcJWhkJNigy97yYBLCqMhExoyjLhQ0bW9+y4w5xfdFupK01SSdDYOS55+yvno yXsXFKY+ecWn5nHZs2KRPnO5Ex2xQFtMGoZHB07WY1TMKQt42iGm+dgSzij1t/cb7ETyhEsspHpLxM00QwWieuNLstlXgMlqhjU= X-Rspamd-Queue-Id: 48KBpc5WrKz4XHQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.139) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-4.07 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCVD_IN_DNSWL_LOW(-0.10)[139.136.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; IP_SCORE(-2.37)[ip: (-6.05), ipnet: 64.59.128.0/20(-3.22), asn: 6327(-2.51), country: CA(-0.09)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 01:04:09 -0000 In message , Oliver Pinter writes: > On Friday, February 14, 2020, Kyle Evans wrote: > > > Hello, > > > > I've organized a review[0] to return most config files back to etc/. > > Many people were concerned about the mass exodus of etc/, and many > > have expressed a desire (privately or otherwise) for these files to > > return- some of these folks represent downstreams or consumer projects > > that went through the painful move the first time and would happily go > > through the pain again to restore the status quo. > > > > This does mean that we'd end up with a structure that's not compatible > > with stable/12, but is compatible with every branch before it. > > > > If you have an opinion for or against. please speak up now. I'd like > > to make sure we're moving in the correct direction as a developer > > community. > > > > Thanks, > > > > Kyle Evans > > > > [0] https://reviews.freebsd.org/D23690 > > > A very big yes. Please do it. > It would be more straightforward and more backward compatible because the > FreeBSD's repo is a monorepo. > > As far I remember, there was an mess around the password and groups file > depending on the "default" shell. A sed magic or other black magic... Agreed. I was never enamoured with the move. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Sat Feb 15 10:22:59 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2BA1D256043 for ; Sat, 15 Feb 2020 10:22:59 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48KRCQ34w8z44jQ for ; Sat, 15 Feb 2020 10:22:58 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x434.google.com with SMTP id z7so13877808wrl.13 for ; Sat, 15 Feb 2020 02:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=W2qvNJ7J90gyZuOOQJq8EgynVoDeNXO248iTKLSzLcc=; b=nL2o+FmKqk/n3am5VH0qkZeEzbypQNHIHfjiSjvnUfujEAUWEigrxG01bf6DTLXg0F lkmgFS7eWJ6Zh1STI1f6Y80DIKSQx/1pkk95IYvTGDEXhvZzoeLnSKQr6IKF5MNPrBYS g3Zs5jnD4ii6HIjDW9rRIK+1RnzikkYHAXFv/+PdcngY/0+9evN5fXF6rMsOXMH42MFj 83raJRyG3kklnnFXKsDXpprlcMr5R85GcroDQCNL52+fz6PanOUHUpM/wwWhN8Xvamty TXspik+bgxY08JVdp0768qW5OjTaUeRVzwRFhOdi/4qvGd3XykJPevJAlXxHX6+JG33j gzFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=W2qvNJ7J90gyZuOOQJq8EgynVoDeNXO248iTKLSzLcc=; b=bWNkHDmqafyltDgXkgv9UT0x/46STarz8LzAghiQ3Yc3GAOBWt9ld/mnypwXk3VsAk ZoRz1lOxdPjRdYuypABTEkLGYVez3Oi6Zn8DYwG0Yx80SRfQLEj8BEwlytaRRHU3aQH0 hvbKNX1iiNSWD8HzTUOhtJ5Kv36nGHq7i9hR1GIZhrSCbMp0vzS9wKLi6bkUOhqVQRQV vOY7/ahrVobfKnuGo/atfQeOU61KsMJ2sQuHOVqCz/s/xTRQHP8+z6CEkdSBjAZPOeDU kt7tX0rVG+w2RaKHaBenXdIttiYBysRMEMb/GgDkZGJDd8yFBMCHmn3RxgCqF9LnqQl7 8kjw== X-Gm-Message-State: APjAAAWuYmTBYM0JlYGw5BKKy6bKMQpgtcvShalWh4ykl/ll9URZxWeo uGveweB0iM0P7HYwR8BY1nAMd+QC X-Google-Smtp-Source: APXvYqys/U+wmpU1ldSC1HQ9DoQnfXkvHCpXJ3xZmVQWgXZxmEayHdQIjjwLFeAML8IOSt+JVv54bg== X-Received: by 2002:adf:f7c4:: with SMTP id a4mr9587669wrq.361.1581762176328; Sat, 15 Feb 2020 02:22:56 -0800 (PST) Received: from ernst.home (p5B023038.dip0.t-ipconnect.de. [91.2.48.56]) by smtp.gmail.com with ESMTPSA id e18sm10367853wrw.70.2020.02.15.02.22.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Feb 2020 02:22:55 -0800 (PST) Date: Sat, 15 Feb 2020 11:22:54 +0100 From: Gary Jennejohn To: freebsd-arch@freebsd.org Subject: Re: Return of config files to ^/etc Message-ID: <20200215112254.7856e02a@ernst.home> In-Reply-To: <202002150104.01F142eE063954@slippy.cwsent.com> References: <202002150104.01F142eE063954@slippy.cwsent.com> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48KRCQ34w8z44jQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=nL2o+FmK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::434 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[56.48.2.91.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.38), ipnet: 2a00:1450::/32(-2.42), asn: 15169(-1.68), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[4.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 10:22:59 -0000 On Fri, 14 Feb 2020 17:04:02 -0800 Cy Schubert wrote: > In message om> > , Oliver Pinter writes: > > On Friday, February 14, 2020, Kyle Evans wrote: > > > > > Hello, > > > > > > I've organized a review[0] to return most config files back to etc/. > > > Many people were concerned about the mass exodus of etc/, and many > > > have expressed a desire (privately or otherwise) for these files to > > > return- some of these folks represent downstreams or consumer projects > > > that went through the painful move the first time and would happily go > > > through the pain again to restore the status quo. > > > > > > This does mean that we'd end up with a structure that's not compatible > > > with stable/12, but is compatible with every branch before it. > > > > > > If you have an opinion for or against. please speak up now. I'd like > > > to make sure we're moving in the correct direction as a developer > > > community. > > > > > > Thanks, > > > > > > Kyle Evans > > > > > > [0] https://reviews.freebsd.org/D23690 > > > > > > A very big yes. Please do it. > > It would be more straightforward and more backward compatible because the > > FreeBSD's repo is a monorepo. > > > > As far I remember, there was an mess around the password and groups file > > depending on the "default" shell. A sed magic or other black magic... > > Agreed. I was never enamoured with the move. > I'm in favor of this also. I never did understand the logic behind the change. -- Gary Jennejohn From owner-freebsd-arch@freebsd.org Sat Feb 15 15:13:05 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B1E123E5DC for ; Sat, 15 Feb 2020 15:13:05 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48KYf84QDyz4MRf for ; Sat, 15 Feb 2020 15:13:04 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf32.google.com with SMTP id l14so5698856qvu.12 for ; Sat, 15 Feb 2020 07:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=7tNUy8Y8W3MTWF8YvOYwGotvz/ixwNaxZlOSokjJVxw=; b=M1wLHFuiyIgdJV9Kc7fu809gOAHDlyeHf3uv8iQYca/KoLCCeQkTHkleQ4UP6gJYgX AL+kwuA+5ZD1cbvlVDlGRy4O4m0qj3lYsnMqbrwz3jYB4mg2Kw3p0exGNqN9P47LFd6h BvZ3jVzOSEDQuFi4QisSkdth3dlgyL9Rd/9hFfnu8yvhfoQObQNPNTvCIpshirTHaQas 8RhUMlaOhVhHHs2wCWfHaGf0heU1haRBq3xYTEoSQ4BI0XHifnBj0og8yTF0pOXboc6v QIFSbdzb1TGCT1KUsS2EYuXAqLKa3KaQ0EidnUpTdrTt1IZSSvo+imdaZ0/Vaxvbl7Hx m3MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=7tNUy8Y8W3MTWF8YvOYwGotvz/ixwNaxZlOSokjJVxw=; b=ZzlLN0Dr6ToBnRhHgwJSI7KAQBXPgsT+kRlOf+ONSDABfotYRst1/CD9VfZIOAXjOv ndQhHZGm2RTYuOJJ1vOKnUzPOA5hs95I/8JKBYWpW3fPEY699+F2Gt/G05GYl/bi8cEP crdGTs1aph719cjUWh1U5tc08EgA3ew6BlfatHDXjg7sDah/qMxndYi/AhBoVe5encDN u/chIJG4XLtBSsYfmmbhxyXSSdD1pcE4lf7W9+I5guHWxZk2RI9DcJjTOM/CsI3+JSbH S5mdMCBCG0GZ9QN8lhu9rpWaP4y23sRBzKsLWuCEWz4bJhvzuisF9B/ZImH43+DzsnXN qXMQ== X-Gm-Message-State: APjAAAW5KhICU5uofdr9FZW8un5LEQZrc4pBcFj1aXy8e6ptmrmLGZp8 Vg4WqSHjkglSd5RooPIiovucXw== X-Google-Smtp-Source: APXvYqwXr0pjg9J+n34V3JoRU8zltNrTnbOsLloqnjuoeSMa5X6SE7bnpy3g8q6xRGnQuOdiXCXCVw== X-Received: by 2002:ad4:56a7:: with SMTP id bd7mr6593921qvb.238.1581779582436; Sat, 15 Feb 2020 07:13:02 -0800 (PST) Received: from mutt-hbsd ([63.88.83.120]) by smtp.gmail.com with ESMTPSA id q130sm5532990qka.114.2020.02.15.07.13.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Feb 2020 07:13:01 -0800 (PST) Date: Sat, 15 Feb 2020 10:13:02 -0500 From: Shawn Webb To: Kyle Evans Cc: "freebsd-arch@freebsd.org" Subject: Re: Return of config files to ^/etc Message-ID: <20200215151302.z7tcf6ipzruean7u@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dvwtooazvcyylzkk" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 48KYf84QDyz4MRf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=M1wLHFui; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::f32 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-4.83 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-0.73)[ipnet: 2607:f8b0::/32(-1.90), asn: 15169(-1.68), country: US(-0.05)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 15:13:05 -0000 --dvwtooazvcyylzkk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Kyle, On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote: > Hello, >=20 > I've organized a review[0] to return most config files back to etc/. > Many people were concerned about the mass exodus of etc/, and many > have expressed a desire (privately or otherwise) for these files to > return- some of these folks represent downstreams or consumer projects > that went through the painful move the first time and would happily go > through the pain again to restore the status quo. >=20 > This does mean that we'd end up with a structure that's not compatible > with stable/12, but is compatible with every branch before it. >=20 > If you have an opinion for or against. please speak up now. I'd like > to make sure we're moving in the correct direction as a developer > community. I'm curious how long downstream projects would need to support both paradigms. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --dvwtooazvcyylzkk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl5ICngACgkQ/y5nonf4 4fqxdg/9Erslz6m6EpCttekZuVmel2wFBKyNurxbhr2xf2xyE2OnUsHqlRAfcr6/ Qu377NP5VDGNNpu8mw62DAvICrX9EIGH7wWYs3wK4O2yigI6OiSxlET5TVoc5kUp A14SWfguBIRNJspL5g8uVTG3MZ8QpaFALmjwqOEU93xjXhQ69ecAOrlzWcZdgE48 sgPLLowcFp4xNGPrOG/uM3B+sJR7dvs/+Qsk6W3wa7seYxP5B4wth27p97KpvaTi Ln810FsMikvASjN0ixWuRVWpVyKrJ+zJGDivA+gwFS9RGAdmMNYISYuQ9jx7KnJt l5a6P60xVT6Ip14ckVWzwpuegpfkKmNR9ZhaQTH0RF5d2Clbs2Lo+ZNvsxGr1P4t zMCtIW1rWgygycme2nUijZRbLFXah+JeHAPazlAYiTc2tPykf42buGTv+DdP2/3i jW0hm1XlIdE0yrj6HgC4bPvn1FvHK2nEOy0d0Fu/cPzmeDYrj035EprJTHMbP/L2 MQNqcrmerfdMhHEPBbWU1XLWQczwPV+ow4Gg8dv3/4QBxysurv7PtCQN7Sj5D47J LiYQ6r7PT8/PCUwP1CFLx3DhVW19gAOxi3vCYYhT5rHBSvM5q71H9SVBwEGmwAKP lcP1Nku5OWijiYe1y/1PVtZrFK/5V3O1d6pe+DMzxEWhEyflt7o= =hJbP -----END PGP SIGNATURE----- --dvwtooazvcyylzkk-- From owner-freebsd-arch@freebsd.org Sat Feb 15 16:08:26 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4385923F84D for ; Sat, 15 Feb 2020 16:08:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48KZt215zKz4Q3l for ; Sat, 15 Feb 2020 16:08:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 12ADF189AE for ; Sat, 15 Feb 2020 16:08:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f178.google.com with SMTP id k7so9094596qth.11 for ; Sat, 15 Feb 2020 08:08:26 -0800 (PST) X-Gm-Message-State: APjAAAVtK5sdePB5ILzTzl5jDk80MOzitMfw3yOfrXDAy1W59VcQGMUw XGtvcHHY1Syp1LrL0zERntmqqPDo4Yc7eeKupow= X-Google-Smtp-Source: APXvYqxhdcGwC4nJJfHvQSqH4yAaLjsRLOzXGyfK/zS/FAt4/rp/Cq02S2uU01GrHYwgMduLBlRKAGsiX7gn0LuCDiY= X-Received: by 2002:ac8:740f:: with SMTP id p15mr6601672qtq.211.1581782905634; Sat, 15 Feb 2020 08:08:25 -0800 (PST) MIME-Version: 1.0 References: <20200215151302.z7tcf6ipzruean7u@mutt-hbsd> In-Reply-To: <20200215151302.z7tcf6ipzruean7u@mutt-hbsd> From: Kyle Evans Date: Sat, 15 Feb 2020 10:08:14 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Return of config files to ^/etc To: Shawn Webb Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 16:08:26 -0000 On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb wrote: > > Hey Kyle, > > On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote: > > Hello, > > > > I've organized a review[0] to return most config files back to etc/. > > Many people were concerned about the mass exodus of etc/, and many > > have expressed a desire (privately or otherwise) for these files to > > return- some of these folks represent downstreams or consumer projects > > that went through the painful move the first time and would happily go > > through the pain again to restore the status quo. > > > > This does mean that we'd end up with a structure that's not compatible > > with stable/12, but is compatible with every branch before it. > > > > If you have an opinion for or against. please speak up now. I'd like > > to make sure we're moving in the correct direction as a developer > > community. > > I'm curious how long downstream projects would need to support both > paradigms. > The answer for both downstreams and us is "however long stable/12 is supported" for that particular project. Something that I've intentionally not pitched yet (to avoid conflating major issues) is the possibility of MFC'ing the move back to stable/12. It's feasible, but requires more care and attention than it does in head/. IIRC, when you attempt to merge an svn mv/cp to another branch, svn will stage it as a copy from the version in head/ that lives at the destination. So, when you try to MFC a mv/cp, you're effectively MFC'ing all changes before it unless you take care to assess and, as needed, revert those in the final diff. I will volunteer to do this work if the move back happens, but I will raise that as a follow-up issue. I suspect that it will be desired if we do the move in head, to ease the pain of merging back to our most recent branch. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Sat Feb 15 16:35:54 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4416F2405CB for ; Sat, 15 Feb 2020 16:35:54 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48KbTj5NCLz4RcJ; Sat, 15 Feb 2020 16:35:53 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id AC5EF13E42; Sat, 15 Feb 2020 16:35:52 +0000 (UTC) Date: Sat, 15 Feb 2020 16:35:51 +0000 From: Mark Linimon To: Kyle Evans Cc: "freebsd-arch@freebsd.org" Subject: Re: Return of config files to ^/etc Message-ID: <20200215163551.GA31668@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 48KbTj5NCLz4RcJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [-0.67 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.956,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; IP_SCORE(-0.18)[ip: (0.04), ipnet: 18.220.0.0/14(0.19), asn: 16509(-1.06), country: US(-0.05)]; RCVD_IN_DNSWL_MED(-0.20)[11.6.222.18.list.dnswl.org : 127.0.5.2]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.24)[-0.237,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Mailman-Approved-At: Sat, 15 Feb 2020 17:51:41 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 16:35:54 -0000 +1. My finger-memory lasts many years. mcl From owner-freebsd-arch@freebsd.org Sat Feb 15 19:36:34 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B21DB246719 for ; Sat, 15 Feb 2020 19:36:34 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48KgVB1vqLz3ClZ; Sat, 15 Feb 2020 19:36:33 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 01FJaUoS048416; Sat, 15 Feb 2020 11:36:30 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 01FJaUj4048415; Sat, 15 Feb 2020 11:36:30 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202002151936.01FJaUj4048415@gndrsh.dnsmgr.net> Subject: Re: Return of config files to ^/etc In-Reply-To: To: Kyle Evans Date: Sat, 15 Feb 2020 11:36:30 -0800 (PST) CC: Shawn Webb , "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 48KgVB1vqLz3ClZ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 19:36:34 -0000 > On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb wrote: > > > > Hey Kyle, > > > > On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote: > > > Hello, > > > > > > I've organized a review[0] to return most config files back to etc/. I read the review, I have issues I need to post in it, but at the moment dont have write access to reviews.freebsd.org due to broken https mangling by a captive portal. > > > Many people were concerned about the mass exodus of etc/, and many > > > have expressed a desire (privately or otherwise) for these files to > > > return- some of these folks represent downstreams or consumer projects > > > that went through the painful move the first time and would happily go > > > through the pain again to restore the status quo. > > > > > > This does mean that we'd end up with a structure that's not compatible > > > with stable/12, but is compatible with every branch before it. > > > > > > If you have an opinion for or against. please speak up now. I'd like > > > to make sure we're moving in the correct direction as a developer > > > community. I spoke up rather loudly in public when this first started to happen, so of cource I am in support of reverting to prior design. > > > > I'm curious how long downstream projects would need to support both > > paradigms. > > > > The answer for both downstreams and us is "however long stable/12 is > supported" for that particular project. As of now downstreams that support stable/11 are already in the position of having to support both. Further if this change does get back to stable/12 that life cycle whould greatly be reduced as the EOL of 12.1 would be fairly short after 12.2 was released, 3 months iirc. > Something that I've intentionally not pitched yet (to avoid conflating > major issues) is the possibility of MFC'ing the move back to > stable/12. It's feasible, but requires more care and attention than it > does in head/. IIRC, when you attempt to merge an svn mv/cp to another > branch, svn will stage it as a copy from the version in head/ that > lives at the destination. So, when you try to MFC a mv/cp, you're > effectively MFC'ing all changes before it unless you take care to > assess and, as needed, revert those in the final diff. > > I will volunteer to do this work if the move back happens, but I will > raise that as a follow-up issue. I suspect that it will be desired if > we do the move in head, to ease the pain of merging back to our most > recent branch. I'll volunteer to help you do that work if that move should need to happen. You may actually simplify the process if you use reverts to undo the change in ^head and merge the reverts back, I think that *might* just do the right things, but I would need to run some test cases. > Thanks, > Kyle Evans -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Sat Feb 15 20:04:00 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D8A4A24734E for ; Sat, 15 Feb 2020 20:04:00 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Kh5q5YJJz3K3D for ; Sat, 15 Feb 2020 20:03:59 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf33.google.com with SMTP id y2so5892033qvu.13 for ; Sat, 15 Feb 2020 12:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JtMhCiOU4755sss0LhzNlrGjpo5l86azFWRWeLopXTI=; b=T6SN3cq/whjmhPBBCaqkRORAHLh7L6z9p0HN4RRa1VbjyumVg2TVfw7qO9er3RjNSV lt5e2n/5XBpRGeYnVzsVVoK3BCOsJRBPGc8/GA/OyILJtJk5sZOoUgM6mXdBcPiF9c8G g8hZPpzKnXZu6ofLBBy08sHM65tVnwW23rcExSnB576JAHXsqhgquocLfQ+eOmuhbv97 ttDJ/xz2AL4ApV6s7fDAw08BjGugs9DuXTFcWXIsReHIvQsL8RjaLEfJFiOIl2HPsDx4 n9MITKDsZn47BTKGv4bLnftTXGCpSFDqD7CrcwgJFyexm1pMBnt+Wi2BqMTpLcHJqhwL maHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JtMhCiOU4755sss0LhzNlrGjpo5l86azFWRWeLopXTI=; b=eO2Ei1MWR3xlN5RyAhd1KdIedbh7latAtwcxgbRD7azIirjU+RUE6E+OolX/hnmu5E 2TBCgwwXjmh7Rto7FGkPMjLBdjhXOuyj0AoexW4q9oCsfD4+INCWxD2l0SzEuqbEfy1Y 1rvx6CU6yE9K3xiaG1qOgfaIR/RlM+iDG4mcfJZPr1RPPpGSqGQhO+EnWDR4sdw5ZFvJ o48XL9ngASPDQWPdEpDr/Jkgu2kzgXZvCqIHB6XuIK7B2vjH/Whok/FGCuMRbKtV8nss q00YMd/ycbsyZSK47Tc0ahEAF5VuH3NEb1H6ibhAr6ZXHCzBpG9yIKzLhFBy7u/cJm4R 6WQw== X-Gm-Message-State: APjAAAVKoLOG8AcekHwhF+H7n9WZru6bLDFyS9BPfqhwDNl396YjYCxE vlQCN6SJi9/0upGXtSo44lXpiXXDwc1KSw== X-Google-Smtp-Source: APXvYqxLy0xCtcc/5fvHG45Dm37dzVbPHOfaHQnOXL82B2UmgPNCLvv95DsBQzRcj9uhfKa1s5DzzQ== X-Received: by 2002:a0c:e58e:: with SMTP id t14mr7067515qvm.131.1581797033499; Sat, 15 Feb 2020 12:03:53 -0800 (PST) Received: from mutt-hbsd ([63.88.83.120]) by smtp.gmail.com with ESMTPSA id h13sm5892254qtu.23.2020.02.15.12.03.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Feb 2020 12:03:52 -0800 (PST) Date: Sat, 15 Feb 2020 15:03:53 -0500 From: Shawn Webb To: "Rodney W. Grimes" Cc: Kyle Evans , "freebsd-arch@freebsd.org" Subject: Re: Return of config files to ^/etc Message-ID: <20200215200353.xdmx4fq3fmgaeq2s@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <202002151936.01FJaUj4048415@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dbyatuhu3ymxowhl" Content-Disposition: inline In-Reply-To: <202002151936.01FJaUj4048415@gndrsh.dnsmgr.net> X-Rspamd-Queue-Id: 48Kh5q5YJJz3K3D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=T6SN3cq/; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::f33 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-6.15 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-2.05)[ip: (-6.60), ipnet: 2607:f8b0::/32(-1.90), asn: 15169(-1.68), country: US(-0.05)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 20:04:00 -0000 --dbyatuhu3ymxowhl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 15, 2020 at 11:36:30AM -0800, Rodney W. Grimes wrote: > > > I'm curious how long downstream projects would need to support both > > > paradigms. > > > > >=20 > > The answer for both downstreams and us is "however long stable/12 is > > supported" for that particular project. >=20 > As of now downstreams that support stable/11 are already > in the position of having to support both. Not all downstreams support stable/11 anymore, HardenedBSD being one of them. I'm not against reverting back to the old behavior, but I need to know what additional long-term tasking to add to my plate. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --dbyatuhu3ymxowhl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl5ITqUACgkQ/y5nonf4 4foE5A/+NmFY0CoRH+qhEl+/Bq+XNP1wvQUMZQ+6ddn1P6Q1IN4GdZkKUM6bBzhX XkjvXTbliDAzq+Sm82OOJt0xTWXWOn8djeGCLE+QfRuIuMd8WCIIFA72WFf3m6LA QOQUK4byNNj059LqGjFc1teSxVCOWMckl1Y/PQOv+P0c2vOP6onGVaKphXuMcvBU gNPFD8U3CE0E5XE+VNTRlMMYcUNP1eNIZP2MDsBY8KBWajepknoGtdhChaHLkEsq PtyU/9GQZwwnp93nI4spaFw2HsdrvKviCNbzbPoHALQTsIjgbx6dqqVria02k2uQ yL0sElrq5KMeTAr3gnWcz42fmpnlMmU4qNpOqhiI2MNM9SMnXxkEGS+SQ6eUbo5i jZlrEvySdc/OUTE3rhVSXrZhEXFpaIbossPVLW6VdYrGzgp7la/JBXCoUD77htt4 qor4Ca5c2ygZvRGNVKmIL6ErwbllPj4T6AONHUOSZoMijP9nTj8Mxbns/a74SMxr +O2Yx8x3Reb7B1T9V1CXEY11hIKkJy6Dd/gxYWPhr+j5uCTzl6bXqPzpwziGo5WV gsXi3XIkPmmxcj3Zr3yV3g7mBz+U+4E7btHP4GD3+uB5Hd3FK8COEpx1VUe8Vbsd 7QInsULaqAj+BsQzh0H35dcxh/3Ef0PV6CNvI4MJVjMfRXxvCDc= =3YK3 -----END PGP SIGNATURE----- --dbyatuhu3ymxowhl-- From owner-freebsd-arch@freebsd.org Sat Feb 15 20:57:34 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C6D092487ED for ; Sat, 15 Feb 2020 20:57:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48KjHf4qn5z459w for ; Sat, 15 Feb 2020 20:57:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 935DB1ABF2 for ; Sat, 15 Feb 2020 20:57:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f172.google.com with SMTP id d9so9429114qte.12 for ; Sat, 15 Feb 2020 12:57:34 -0800 (PST) X-Gm-Message-State: APjAAAWCxZAabjPud0ZZj67Io1RM6hBMazlL/i7z/VUQn0ESM4p1jjSX AucXpbSwX93xOBnHblB2laZPhO1j8kOMDq7EQm0= X-Google-Smtp-Source: APXvYqypkfPpy2ndCXYbEf6INB7LB0cdvOXV2dpNRfSvVqbooCcWek7Rtqsymjvh6Qzuh2Sy0ecidE3dDIdbbEvXdgY= X-Received: by 2002:ac8:739a:: with SMTP id t26mr5316695qtp.53.1581800254118; Sat, 15 Feb 2020 12:57:34 -0800 (PST) MIME-Version: 1.0 References: <202002151936.01FJaUj4048415@gndrsh.dnsmgr.net> In-Reply-To: <202002151936.01FJaUj4048415@gndrsh.dnsmgr.net> From: Kyle Evans Date: Sat, 15 Feb 2020 14:57:19 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Return of config files to ^/etc To: "Rodney W. Grimes" Cc: Shawn Webb , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 20:57:34 -0000 On Sat, Feb 15, 2020 at 1:36 PM Rodney W. Grimes wrote: > > > On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb wrote: > > > > > > Hey Kyle, > > > > > > On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote: > > > > Hello, > > > > > > > > I've organized a review[0] to return most config files back to etc/. > > I read the review, I have issues I need to post in it, but at the > moment dont have write access to reviews.freebsd.org due to broken > https mangling by a captive portal. > I will certainly be waiting on plenty of feedback for this one. > > Something that I've intentionally not pitched yet (to avoid conflating > > major issues) is the possibility of MFC'ing the move back to > > stable/12. It's feasible, but requires more care and attention than it > > does in head/. IIRC, when you attempt to merge an svn mv/cp to another > > branch, svn will stage it as a copy from the version in head/ that > > lives at the destination. So, when you try to MFC a mv/cp, you're > > effectively MFC'ing all changes before it unless you take care to > > assess and, as needed, revert those in the final diff. > > > > I will volunteer to do this work if the move back happens, but I will > > raise that as a follow-up issue. I suspect that it will be desired if > > we do the move in head, to ease the pain of merging back to our most > > recent branch. > > I'll volunteer to help you do that work if that move should need > to happen. > Thanks- I appreciate that! =-) > You may actually simplify the process if you use reverts to undo the > change in ^head and merge the reverts back, I think that *might* > just do the right things, but I would need to run some test cases. > I have a fear (completely unfounded- I make no claims that this is correct or has ever happened) that svn would do the completely wrong thing and try to restore the old version. The more I think about it, the more I suspect that most folks that want this would also want it to be MFC'd to eliminate the friction, so I'll do some inspection up-front to see if we'd really run into problems here. Fortunately, there's only one branch that we need to worry about this for that's only about one year old. I suspect we could get away with MFC'ing any stragglers up-front, as I don't recall any major groundbreaking stuff happening in etc/ since 12 branched...but my memory kinda sucks. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Sat Feb 15 21:12:53 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5B48E248D26 for ; Sat, 15 Feb 2020 21:12:53 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48KjdK1lfbz4B32 for ; Sat, 15 Feb 2020 21:12:53 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 2956B1AE5F for ; Sat, 15 Feb 2020 21:12:53 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f170.google.com with SMTP id l16so4821579qtq.1 for ; Sat, 15 Feb 2020 13:12:53 -0800 (PST) X-Gm-Message-State: APjAAAUv4kocbrwLeAhWhlTSpBREcUogU8u6l3N5o4F0lTSSp4CWWgkP YMxdZqq7Z3NUunwUd0+6SHEG/avRz+QycZg26m8= X-Google-Smtp-Source: APXvYqyYGVGPO5g4Y04Tsk5BPqWNNsQPBCTjOTqUuKlxKXDuNX3p7fTteEIcMPM1M+mgYz6fPZU4jmYu5vQMlWNCeQE= X-Received: by 2002:aed:3f70:: with SMTP id q45mr7638011qtf.310.1581801172804; Sat, 15 Feb 2020 13:12:52 -0800 (PST) MIME-Version: 1.0 References: <202002151936.01FJaUj4048415@gndrsh.dnsmgr.net> <20200215200353.xdmx4fq3fmgaeq2s@mutt-hbsd> In-Reply-To: <20200215200353.xdmx4fq3fmgaeq2s@mutt-hbsd> From: Kyle Evans Date: Sat, 15 Feb 2020 15:12:38 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Return of config files to ^/etc To: Shawn Webb Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 21:12:53 -0000 On Sat, Feb 15, 2020 at 2:04 PM Shawn Webb wrote: > > On Sat, Feb 15, 2020 at 11:36:30AM -0800, Rodney W. Grimes wrote: > > > > I'm curious how long downstream projects would need to support both > > > > paradigms. > > > > > > > > > > The answer for both downstreams and us is "however long stable/12 is > > > supported" for that particular project. > > > > As of now downstreams that support stable/11 are already > > in the position of having to support both. > > Not all downstreams support stable/11 anymore, HardenedBSD being one > of them. > > I'm not against reverting back to the old behavior, but I need to know > what additional long-term tasking to add to my plate. > Ideally, we will get this merged back to stable/12 (which should be possible in any event, it's just a matter of how much effort I'll need to put into it) and ease the burden of all involved -- those who still support stable/11, and those who would support 12/13. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Sat Feb 15 21:13:06 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E064D248D7C for ; Sat, 15 Feb 2020 21:13:06 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48KjdZ4P41z4B9K; Sat, 15 Feb 2020 21:13:06 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 01FLD4Kj049217; Sat, 15 Feb 2020 13:13:04 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 01FLD4aX049216; Sat, 15 Feb 2020 13:13:04 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net> Subject: Re: Return of config files to ^/etc In-Reply-To: To: Kyle Evans Date: Sat, 15 Feb 2020 13:13:04 -0800 (PST) CC: "Rodney W. Grimes" , Shawn Webb , "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 48KjdZ4P41z4B9K X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 21:13:06 -0000 > On Sat, Feb 15, 2020 at 1:36 PM Rodney W. Grimes > wrote: > > > > > On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb wrote: > > > > > > > > Hey Kyle, > > > > > > > > On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote: > > > > > Hello, > > > > > > > > > > I've organized a review[0] to return most config files back to etc/. > > > > I read the review, I have issues I need to post in it, but at the > > moment dont have write access to reviews.freebsd.org due to broken > > https mangling by a captive portal. > > > > I will certainly be waiting on plenty of feedback for this one. It is actually minor feedback, but more about methods than content. > > > Something that I've intentionally not pitched yet (to avoid conflating > > > major issues) is the possibility of MFC'ing the move back to > > > stable/12. It's feasible, but requires more care and attention than it > > > does in head/. IIRC, when you attempt to merge an svn mv/cp to another > > > branch, svn will stage it as a copy from the version in head/ that > > > lives at the destination. So, when you try to MFC a mv/cp, you're > > > effectively MFC'ing all changes before it unless you take care to > > > assess and, as needed, revert those in the final diff. > > > > > > I will volunteer to do this work if the move back happens, but I will > > > raise that as a follow-up issue. I suspect that it will be desired if > > > we do the move in head, to ease the pain of merging back to our most > > > recent branch. > > > > I'll volunteer to help you do that work if that move should need > > to happen. > > > > Thanks- I appreciate that! =-) Did you just stick a pitch fork in my hay bail? :-) > > You may actually simplify the process if you use reverts to undo the > > change in ^head and merge the reverts back, I think that *might* > > just do the right things, but I would need to run some test cases. > > > > I have a fear (completely unfounded- I make no claims that this is > correct or has ever happened) that svn would do the completely wrong > thing and try to restore the old version. Well isnt the "old version" what we want to get back to actually? Procedure above may be a bit wrong. Revert in ^head, then to take that back to a branch it existed in at time it was branch just revert that same commit from the branch. That should end with the "change" removed from both head and stable/12. But still some testing needs to be done. Last time I did major surgery the biggest issues I ran into on a branch was improperly recorded merge history that I had to fix first, then things more or less just worked as expected. Hint: record only merge history that is not with the diff that merged it is evil nasty crap! So is merge history recorded with another commit that is not the actual merge diff. And yes, I ran into both cases in the FreeBSD repository. > > The more I think about it, the more I suspect that most folks that > want this would also want it to be MFC'd to eliminate the friction, so > I'll do some inspection up-front to see if we'd really run into > problems here. Fortunately, there's only one branch that we need to > worry about this for that's only about one year old. I suspect we > could get away with MFC'ing any stragglers up-front, as I don't recall > any major groundbreaking stuff happening in etc/ since 12 > branched...but my memory kinda sucks. I agree with the suspecion of wanting the MFC'd. > > Thanks, > > Kyle Evans > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Sat Feb 15 21:34:56 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 872E02495E3 for ; Sat, 15 Feb 2020 21:34:56 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Kk6l2Jtjz4M8W; Sat, 15 Feb 2020 21:34:55 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by mail-yw1-xc2c.google.com with SMTP id l22so6055669ywc.8; Sat, 15 Feb 2020 13:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DnsfANCPavFV29HaVP6H12kqveRhx4MUhswcafQ/Bjg=; b=GNw2tFYQfRkGPMVMDazdmjJm19e8rwZWJ97lglKA7PUbpebjejwh2gueUoDCtElXuX sF/MevyXXTcgzIlLgKi0j6YRxNwI+gSV+lnSEP7a1twT+eV7jozstY2VAdWPCdBYQ7b/ Ac8Bs72ldWeFM+AIJa1i/0Md7IZB+H4PsEG5NeiVbUwPB75wuwMYk6ILbECBGZ83K+6m NL/MZU4QDy+qOhSAcTuAesHb0b8/iFt/ZkjrAcLmDkXBODNGIFh/ZcOAiXUXlPf55zdg sslZjywOMFvZ+vZTRW8ZMTRqNcFXDyiLPMyEybEb9JcVM9TypVzcxltTH8OCafHmH+1K DsiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DnsfANCPavFV29HaVP6H12kqveRhx4MUhswcafQ/Bjg=; b=W8GwQeNFFRJrmJeldH2o28ARV46LFrb+KDfu+z89ISuA40v6JEovhKTc1dEF+eOFeN THuDWyyCWrxQ4mJsaIPAh6fHhDxZun2Uj9AWDsmsGJ3xXNoAkzVA89Y9KqsU1dBSrds7 eoIkpkOmzDJlLvHzz1XogMia9s2nIHcp/zZAwGJa7hgGRQJsI1/3Txdx6+lsRzV0OlXB I9kLPc+SsARFCiz3uwmkH23cgRk8DCzwcvsUyINmlB74xmFw2siY3umx5Ou/8Qcr/u3v mAGyma1qj3LWY92nWyhayekIth6nakssoVbifrLtpyyuYPX0ICW7XFxdpK0ylPzgG/0n /RFw== X-Gm-Message-State: APjAAAX5iwFxaCNpNShE4yDkxQkUHc09JEuQhL+Dw25G9GGyq+eQtFKL GGDlRYKA4z3PPrl5eGZVTiLDcYoy5RZ1gO7h/98AvQ== X-Google-Smtp-Source: APXvYqz6W1M8mmrwyaSha1SnMb7VsRLyhPVpLr2EBt7jNtJHejou0aGJglNLO1/0vnrDs3I1g8VgZ4SlxpL68vyXPIE= X-Received: by 2002:a81:6e09:: with SMTP id j9mr7099223ywc.25.1581802494357; Sat, 15 Feb 2020 13:34:54 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:8542:0:0:0:0:0 with HTTP; Sat, 15 Feb 2020 13:34:53 -0800 (PST) In-Reply-To: <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net> References: <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net> From: Oliver Pinter Date: Sat, 15 Feb 2020 22:34:53 +0100 Message-ID: Subject: Re: Return of config files to ^/etc To: "Rodney W. Grimes" Cc: Kyle Evans , "freebsd-arch@freebsd.org" , Shawn Webb X-Rspamd-Queue-Id: 48Kk6l2Jtjz4M8W X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=GNw2tFYQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of oliverpntr@gmail.com designates 2607:f8b0:4864:20::c2c as permitted sender) smtp.mailfrom=oliverpntr@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[5]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.27), ipnet: 2607:f8b0::/32(-1.90), asn: 15169(-1.68), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[c.2.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 21:34:56 -0000 On Saturday, February 15, 2020, Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On Sat, Feb 15, 2020 at 1:36 PM Rodney W. Grimes > > wrote: > > > > > > > On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb < > shawn.webb@hardenedbsd.org> wrote: > > > > > > > > > > Hey Kyle, > > > > > > > > > > On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote: > > > > > > Hello, > > > > > > > > > > > > I've organized a review[0] to return most config files back to > etc/. > > > > > > I read the review, I have issues I need to post in it, but at the > > > moment dont have write access to reviews.freebsd.org due to broken > > > https mangling by a captive portal. > > > > > > > I will certainly be waiting on plenty of feedback for this one. > > It is actually minor feedback, but more about methods than content. > > > > > Something that I've intentionally not pitched yet (to avoid > conflating > > > > major issues) is the possibility of MFC'ing the move back to > > > > stable/12. It's feasible, but requires more care and attention than > it > > > > does in head/. IIRC, when you attempt to merge an svn mv/cp to > another > > > > branch, svn will stage it as a copy from the version in head/ that > > > > lives at the destination. So, when you try to MFC a mv/cp, you're > > > > effectively MFC'ing all changes before it unless you take care to > > > > assess and, as needed, revert those in the final diff. > > > > > > > > I will volunteer to do this work if the move back happens, but I will > > > > raise that as a follow-up issue. I suspect that it will be desired if > > > > we do the move in head, to ease the pain of merging back to our most > > > > recent branch. > > > > > > I'll volunteer to help you do that work if that move should need > > > to happen. > > > > > > > Thanks- I appreciate that! =-) > > Did you just stick a pitch fork in my hay bail? :-) > > > > You may actually simplify the process if you use reverts to undo the > > > change in ^head and merge the reverts back, I think that *might* > > > just do the right things, but I would need to run some test cases. > > > > > > > I have a fear (completely unfounded- I make no claims that this is > > correct or has ever happened) that svn would do the completely wrong > > thing and try to restore the old version. > > Well isnt the "old version" what we want to get back to actually? Not et all. There will be possible changes in the files in the newer place too. Like eliminating an architecture or improving defaults. For getting clue about what has been moved from svn is fine, but reverting - as I think - is not. > > Procedure above may be a bit wrong. Revert in ^head, then to take > that back to a branch it existed in at time it was branch just revert > that same commit from the branch. That should end with the "change" > removed from both head and stable/12. > > But still some testing needs to be done. Last time I did major > surgery the biggest issues I ran into on a branch was improperly > recorded merge history that I had to fix first, then things more > or less just worked as expected. Hint: record only merge history > that is not with the diff that merged it is evil nasty crap! So > is merge history recorded with another commit that is not the > actual merge diff. And yes, I ran into both cases in the FreeBSD > repository. > > > > > The more I think about it, the more I suspect that most folks that > > want this would also want it to be MFC'd to eliminate the friction, so > > I'll do some inspection up-front to see if we'd really run into > > problems here. Fortunately, there's only one branch that we need to > > worry about this for that's only about one year old. I suspect we > > could get away with MFC'ing any stragglers up-front, as I don't recall > > any major groundbreaking stuff happening in etc/ since 12 > > branched...but my memory kinda sucks. > > I agree with the suspecion of wanting the MFC'd. > > > > > Thanks, > > > > Kyle Evans > > > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Sat Feb 15 21:46:34 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D9916249F87 for ; Sat, 15 Feb 2020 21:46:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48KkNB5Hl9z4S9h for ; Sat, 15 Feb 2020 21:46:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 922A41B1F3 for ; Sat, 15 Feb 2020 21:46:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f174.google.com with SMTP id t13so9529314qto.3 for ; Sat, 15 Feb 2020 13:46:34 -0800 (PST) X-Gm-Message-State: APjAAAVCzCtx3dbTDD1Gv+VL5elJaNHC6PURrV1GG/p5cU185HWOEods okeFRXCXqkKRv0SDvaSweixT03M5yBW2q+iwbdk= X-Google-Smtp-Source: APXvYqwMWYj704CVBqH8csnRBHdrFaVa9NDTpa2sWwvvjx3phsA79KMCnAaQRyPdmrz8Fq5HgrroQeFHRYAfFOh8ZAQ= X-Received: by 2002:ac8:740f:: with SMTP id p15mr7486496qtq.211.1581803194042; Sat, 15 Feb 2020 13:46:34 -0800 (PST) MIME-Version: 1.0 References: <202002152113.01FLD4aX049216@gndrsh.dnsmgr.net> In-Reply-To: From: Kyle Evans Date: Sat, 15 Feb 2020 15:46:19 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Return of config files to ^/etc To: Oliver Pinter Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" , Shawn Webb Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2020 21:46:34 -0000 On Sat, Feb 15, 2020 at 3:34 PM Oliver Pinter wrote: > On Saturday, February 15, 2020, Rodney W. Grimes wrote: >> >> > On Sat, Feb 15, 2020 at 1:36 PM Rodney W. Grimes >> > wrote: >> > > >> > > > On Sat, Feb 15, 2020 at 9:13 AM Shawn Webb wrote: >> > > > > >> > > > > Hey Kyle, >> > > > > >> > > > > On Fri, Feb 14, 2020 at 04:42:15PM -0600, Kyle Evans wrote: >> > > > > > Hello, >> > > > > > >> > > > > > I've organized a review[0] to return most config files back to etc/. >> > > >> > > I read the review, I have issues I need to post in it, but at the >> > > moment dont have write access to reviews.freebsd.org due to broken >> > > https mangling by a captive portal. >> > > >> > >> > I will certainly be waiting on plenty of feedback for this one. >> >> It is actually minor feedback, but more about methods than content. >> >> > > > Something that I've intentionally not pitched yet (to avoid conflating >> > > > major issues) is the possibility of MFC'ing the move back to >> > > > stable/12. It's feasible, but requires more care and attention than it >> > > > does in head/. IIRC, when you attempt to merge an svn mv/cp to another >> > > > branch, svn will stage it as a copy from the version in head/ that >> > > > lives at the destination. So, when you try to MFC a mv/cp, you're >> > > > effectively MFC'ing all changes before it unless you take care to >> > > > assess and, as needed, revert those in the final diff. >> > > > >> > > > I will volunteer to do this work if the move back happens, but I will >> > > > raise that as a follow-up issue. I suspect that it will be desired if >> > > > we do the move in head, to ease the pain of merging back to our most >> > > > recent branch. >> > > >> > > I'll volunteer to help you do that work if that move should need >> > > to happen. >> > > >> > >> > Thanks- I appreciate that! =-) >> >> Did you just stick a pitch fork in my hay bail? :-) >> >> > > You may actually simplify the process if you use reverts to undo the >> > > change in ^head and merge the reverts back, I think that *might* >> > > just do the right things, but I would need to run some test cases. >> > > >> > >> > I have a fear (completely unfounded- I make no claims that this is >> > correct or has ever happened) that svn would do the completely wrong >> > thing and try to restore the old version. >> >> Well isnt the "old version" what we want to get back to actually? > > > Not et all. There will be possible changes in the files in the newer place too. Like eliminating an architecture or improving defaults. For getting clue about what has been moved from svn is fine, but reverting - as I think - is not. > Sorry, I missed this part of the chain- indeed, we don't want the old version, just the old location with appropriate changes. Considering this sequence of events: 1. ^/etc/defaults/devfs.rules moves to sbin/devfs/devfs.rules 2. rgrimes commits new hotness that's compatible with older branches to devfs.rules 3. jhb comes through and makes some change for a 13.0-only feature 4. rgrimes MFC's bits described in #2 5. kevans moves sbin/devfs/devfs.rules back To be explicit: #2 may be MFC'd to stable/12, but #3 may not My experience is that trying to MFC the move back (step #4) will pull in changes #2 *and* #3 implicitly (unless you're paying attention, then it's pretty explicit). Ideally, what we want is a version in stable/12 with #1 reverted but #2 still applied, and #3 *not*. This is the level of hell with MFC'ing sys/boot -> stand back to stable/11, except some changes after the sys/boot -> stand move had already been MFC'd, so I had to re-apply those changes manually or work out some other way to reconcile because it kept trying to pull a stale version back. Thanks, Kyle Evans