From owner-freebsd-arch@freebsd.org Sun Dec 16 09:34:20 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DC111342F29 for ; Sun, 16 Dec 2018 09:34:20 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CBC1377F66 for ; Sun, 16 Dec 2018 09:34:19 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8CD361342F28; Sun, 16 Dec 2018 09:34:19 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AA2B1342F27 for ; Sun, 16 Dec 2018 09:34:19 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (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 A829477F65 for ; Sun, 16 Dec 2018 09:34:18 +0000 (UTC) (envelope-from gnn@neville-neil.com) X-Originating-IP: 118.169.45.207 Received: from [10.0.1.2] (118-169-45-207.dynamic-ip.hinet.net [118.169.45.207]) (Authenticated sender: gnn@neville-neil.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 0DDFB40005 for ; Sun, 16 Dec 2018 09:34:10 +0000 (UTC) From: "George Neville-Neil" To: freebsd- Subject: A proposal for code removal prior to FreeBSD 13 Date: Sun, 16 Dec 2018 17:34:05 +0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Rspamd-Queue-Id: A829477F65 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of gnn@neville-neil.com designates 217.70.183.194 as permitted sender) smtp.mailfrom=gnn@neville-neil.com X-Spamd-Result: default: False [-4.05 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.176.0/21]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; DMARC_NA(0.00)[neville-neil.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.96)[-0.962,0]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.183.70.217.rep.mailspike.net : 127.0.0.17]; IP_SCORE(-0.78)[ipnet: 217.70.176.0/20(-2.08), asn: 29169(-1.80), country: FR(-0.02)]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: spool.mail.gandi.net]; NEURAL_HAM_SHORT(-0.90)[-0.899,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; RCVD_IN_DNSWL_LOW(-0.10)[194.183.70.217.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; 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, 16 Dec 2018 09:34:20 -0000 Howdy, A few of us are working on a list of programs and other code that we'd like to remove before FreeBSD 13. If others with to collaborate on this removal, or discuss it, please do so here. The list is being maintained on the project WIki: https://wiki.freebsd.org/WhatsGoing/FreeBSD13 Best, George From owner-freebsd-arch@freebsd.org Sun Dec 16 16:32:35 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BE0013318EA for ; Sun, 16 Dec 2018 16:32:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 96F368DB79 for ; Sun, 16 Dec 2018 16:32:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5955F13318DE; Sun, 16 Dec 2018 16:32:34 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BBAA13318DD for ; Sun, 16 Dec 2018 16:32:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B36E58DB78 for ; Sun, 16 Dec 2018 16:32:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72a.google.com with SMTP id g125so5834274qke.4 for ; Sun, 16 Dec 2018 08:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZQCi9jAfqHscxwuvf9zQVuQcGlXE2AyGvzuknCDD3kg=; b=Goi2wRQV5qBSMa7SWMRF5uQ3J++Yqk7nWvY9o51ImlnyHjgdjQ54Dwn60WhXnLwu2Z EBz2MBDLxFQXduJOJJCSDLyBjrzW/iIVtTVNPQCy3oLFKjiSVH2+FevqQ6q0bcMfiHmx 7/Z2C0csGB6mBDwBHDTjwuR8XtraU6MMjd9YKc59YUgdFkWJSVqHOWu+WX/pKUzdACUy RpGwbLediTLQfOgzUdHNWecNOUHv+eWUhz9Xe1RSP1JMN+UWXZ/j+XlH/TAy3lETZcgQ eGTvtBI0yya8kvBfsMEEdZfi1uFBk5Fc4/MTmshbl4aj6rkZutQ0Zo6veuC6esVH8gfX +X8A== 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=ZQCi9jAfqHscxwuvf9zQVuQcGlXE2AyGvzuknCDD3kg=; b=j7g38jU/t3V3AhUf4c54cQJPpKM6ZM7uEFfY1i0yjsY37aedsL794yjeSnaKUMfemG lBJdHQmKnYIOfOrMc3/7yNHquhlCSu90DOyUnzpzbe0bPlxkhR9o9t+bysKWzybCeuRS 6aQuFMV9R089cASG2WIfuG4KTBBXxe74HqzfuYQ4rTBcXZJCyXEjuxhT/oAjhydS3k89 DrSoZ2Lt+HcK5/o5ORHRYqVt2M4oVq2mdnM8WCT7KINX8Uh1C0sJvJ1XMWHwAyuOJxEQ TbroIYULqgVVQar5dHfGjrn0PE6+Cjc8q+p2NShUYns9EWeAPrxQRBkrIxpfFsYcJdBx Lgaw== X-Gm-Message-State: AA+aEWZs69uQZuY0bFTTWG026OXLvUHNJchadervB9Ed85tWKJK7FQeU LSii6jULIgR1NF7JP9+sbrfYKXaKzhg6GokhzV/6DfVv29c= X-Google-Smtp-Source: AFSGD/WykH34oikTsO4VeBbmhZmJNyMPGmat0XK7s337IuInxBavIZ6BqMSRKrjBzAsSZZpx1/ueuNF9kjP2fUzpnJg= X-Received: by 2002:a37:9604:: with SMTP id y4mr9921901qkd.279.1544977953057; Sun, 16 Dec 2018 08:32:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 16 Dec 2018 09:32:22 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: George Neville-Neil Cc: freebsd- X-Rspamd-Queue-Id: B36E58DB78 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.94)[-0.945,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,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: Sun, 16 Dec 2018 16:32:35 -0000 On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil wrote: > Howdy, > > A few of us are working on a list of programs and other code that we'd > like to remove before FreeBSD 13. If others with to collaborate on this > removal, or discuss it, please do so here. > > The list is being maintained on the project WIki: > https://wiki.freebsd.org/WhatsGoing/FreeBSD13 I'm in the process of writing some of the criteria I've been using to drive discussions. I've promised a formal policy for a long time, but that's turning out to be harder than I thought to write and have just documented the criteria I look at to do the cost / benefit analysis for things. It's skewed a bit towards old drivers and old architectures (or platforms within those architectures), but it's likely a useful snowman to work towards something better. https://wiki.freebsd.org/ObsoleteCriteria This doesn't get into the process at all of who to have the conversation with, what steps you go through to ensure that there's a transition plan for current users (if there's enough to warrant it), etc. It's just a set of things I've found useful to think about and that I think the project should adopt (with refinement) as a standard template to use when making these calls. I also hope that there's sufficient public discussion of the proposed removals individually. While you can't always get 100% agreement, you still need to have the discussions to make sure that you aren't blind to data that would stay your hand on deletion (or maybe even hasten it). Warner From owner-freebsd-arch@freebsd.org Sun Dec 16 16:45:13 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BE6E1331FFA for ; Sun, 16 Dec 2018 16:45:13 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C25228E2B2 for ; Sun, 16 Dec 2018 16:45:12 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 8103E1331FF5; Sun, 16 Dec 2018 16:45:12 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F7F51331FF4 for ; Sun, 16 Dec 2018 16:45:12 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 E88468E2B1 for ; Sun, 16 Dec 2018 16:45:11 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id wBGGj7JS092077; Sun, 16 Dec 2018 08:45:07 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id wBGGj7qn092076; Sun, 16 Dec 2018 08:45:07 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201812161645.wBGGj7qn092076@pdx.rh.CN85.dnsmgr.net> Subject: Re: A proposal for code removal prior to FreeBSD 13 In-Reply-To: To: George Neville-Neil Date: Sun, 16 Dec 2018 08:45:07 -0800 (PST) CC: freebsd- 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: E88468E2B1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.975,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-0.999,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: Sun, 16 Dec 2018 16:45:13 -0000 > Howdy, > > A few of us are working on a list of programs and other code that we'd > like to remove before FreeBSD 13. If others with to collaborate on this > removal, or discuss it, please do so here. > > The list is being maintained on the project WIki: > https://wiki.freebsd.org/WhatsGoing/FreeBSD13 I am going to ask that all parties who want to "deprecate" code first work with imp@ (Warner) to formalize the policy and procedure for doing such that was promised by "release 12.0", then start on this activity of deciding what can and can not go. The ad hoc history of deprecation, especially without even following our current model, is not helping the projects image with users going "wtf, they took out foo???" timed was removed outside of current procedure, and that should be corrected ASAP, as one developer has already spoken up that they are using it. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Sun Dec 16 20:51:48 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BC92133B1FE for ; Sun, 16 Dec 2018 20:51:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4B82A96832 for ; Sun, 16 Dec 2018 20:51:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 0FBF2133B1FD; Sun, 16 Dec 2018 20:51:47 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0F31133B1FC for ; Sun, 16 Dec 2018 20:51:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 85EEC9682F for ; Sun, 16 Dec 2018 20:51:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7CBD014874; Sun, 16 Dec 2018 20:51:39 +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 wBGKpcJv080967 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 16 Dec 2018 20:51:38 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id wBGKpa3N080966; Sun, 16 Dec 2018 20:51:36 GMT (envelope-from phk) To: "Bjoern A. Zeeb" cc: "Rodney W. Grimes" , freebsd- , George Neville-Neil Subject: Re: A proposal for code removal prior to FreeBSD 13 In-reply-to: <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net> From: "Poul-Henning Kamp" References: <201812161645.wBGGj7qn092076@pdx.rh.CN85.dnsmgr.net> <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80964.1544993496.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Dec 2018 20:51:36 +0000 Message-ID: <80965.1544993496@critter.freebsd.dk> X-Rspamd-Queue-Id: 85EEC9682F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,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: Sun, 16 Dec 2018 20:51:48 -0000 -------- In message <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net>, "Bjo= ern A . Zeeb" writes: >> timed was removed outside of current procedure, and that should >> be corrected ASAP, > >No, it should not. There is a stable branch, with shipping releases, >and support until at least June 30, 2020, possibly longer. > >The questions are: >[...] (e) Has anybody ever run timed(8) on FreeBSD in the first place ? (f) What was wrong with them ? -- = 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 Dec 16 19:11:10 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A6451337759 for ; Sun, 16 Dec 2018 19:11:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0E221930B3 for ; Sun, 16 Dec 2018 19:11:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: by mailman.ysv.freebsd.org (Postfix) id C33D31337758; Sun, 16 Dec 2018 19:11:09 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1B2E1337757 for ; Sun, 16 Dec 2018 19:11:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FBDC930AC for ; Sun, 16 Dec 2018 19:11:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7C8408D4A250; Sun, 16 Dec 2018 19:11:06 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 604FAD1F835; Sun, 16 Dec 2018 19:11:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id IHDCbe8VgGp9; Sun, 16 Dec 2018 19:11:03 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 24D0BD1F7F3; Sun, 16 Dec 2018 19:11:02 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Rodney W. Grimes" Cc: "George Neville-Neil" , freebsd- Subject: Re: A proposal for code removal prior to FreeBSD 13 Date: Sun, 16 Dec 2018 19:11:56 +0000 X-Mailer: MailMate (2.0BETAr6133) Message-ID: <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net> In-Reply-To: <201812161645.wBGGj7qn092076@pdx.rh.CN85.dnsmgr.net> References: <201812161645.wBGGj7qn092076@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4FBDC930AC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.985,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: Sun, 16 Dec 2018 19:11:10 -0000 On 16 Dec 2018, at 16:45, Rodney W. Grimes wrote: I’ll ignore the “turning FreeBSD into change-management procedures” part. > timed was removed outside of current procedure, and that should > be corrected ASAP, No, it should not. There is a stable branch, with shipping releases, and support until at least June 30, 2020, possibly longer. The questions are: (a) will the request still be relevant then? (b) do we still want to support it then? (c) with pkgbase hopefully coming, will it still matter or is it better off to be “3rd party” software? (d) if it’s coming back, do we have a developer to care about it and take care of the original reason that triggered the removal? > as one developer has already spoken up that > they are using it. s/developer/user/ ; whether he is a developer as well is not the point. /bz From owner-freebsd-arch@freebsd.org Sun Dec 16 17:00:00 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 740461332480 for ; Sun, 16 Dec 2018 17:00:00 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB5F8E82F for ; Sun, 16 Dec 2018 16:59:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 5D589133246D; Sun, 16 Dec 2018 16:59:59 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AB7D133246C for ; Sun, 16 Dec 2018 16:59:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 9A2CB8E829 for ; Sun, 16 Dec 2018 16:59:58 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id wBGGxt5a092109; Sun, 16 Dec 2018 08:59:55 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id wBGGxtSi092108; Sun, 16 Dec 2018 08:59:55 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> Subject: Re: A proposal for code removal prior to FreeBSD 13 In-Reply-To: To: Warner Losh Date: Sun, 16 Dec 2018 08:59:55 -0800 (PST) CC: George Neville-Neil , freebsd- 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: 9A2CB8E829 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.973,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: Sun, 16 Dec 2018 17:00:00 -0000 > On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > wrote: > > > Howdy, > > > > A few of us are working on a list of programs and other code that we'd > > like to remove before FreeBSD 13. If others with to collaborate on this > > removal, or discuss it, please do so here. > > > > The list is being maintained on the project WIki: > > https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > > > I'm in the process of writing some of the criteria I've been using to drive > discussions. I've promised a formal policy for a long time, but that's > turning out to be harder than I thought to write and have just documented > the criteria I look at to do the cost / benefit analysis for things. It's > skewed a bit towards old drivers and old architectures (or platforms within > those architectures), but it's likely a useful snowman to work towards > something better. https://wiki.freebsd.org/ObsoleteCriteria THANK YOU!!! > This doesn't get into the process at all of who to have the conversation > with, what steps you go through to ensure that there's a transition plan > for current users (if there's enough to warrant it), etc. It's just a set > of things I've found useful to think about and that I think the project > should adopt (with refinement) as a standard template to use when making > these calls. Can you also draft a short proposal on the "process" of deprecation? Based I guess on our current model, with the addition of some of the macros and other stuff you and Brooks worked on, the gone_in stuff is what I am thinking. How to do the head commit with the deprecation notices, merge that back if applicable, then do the remove when appropriate. Basically a more complete flushed out version of: https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules @ 17.4. We should also IMHO do some work smithing and rearrangement to make this read much more as steps, some of the steps as listed have substeps that appear to be overlooked often. Something like this: 17.4. Deprecating Features When it is necessary to remove functionality from software in the base system, follow these guidelines whenever possible: 1. Use of the deprecated feature generates a warning. 2. Mention is made in the manual page and the release notes that the option, utility, or interface is deprecated. (I removed the word possible here, we should always mention deprecation of features in the release notes) 3. The option, utility, or interface is preserved until the next major (point zero) release. 4. The option, utility, or interface is removed and no longer documented. It is now obsolete. 5. Note its removal in the release notes. (Again, made this non-optional, removals must have release notes entries) > > I also hope that there's sufficient public discussion of the proposed > removals individually. While you can't always get 100% agreement, you still > need to have the discussions to make sure that you aren't blind to data > that would stay your hand on deletion (or maybe even hasten it). > > Warner -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Sun Dec 16 15:41:13 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60A6B132C9CA for ; Sun, 16 Dec 2018 15:41:13 +0000 (UTC) (envelope-from db@db.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CB9F58BBDD for ; Sun, 16 Dec 2018 15:41:12 +0000 (UTC) (envelope-from db@db.net) Received: by mailman.ysv.freebsd.org (Postfix) id 8B59B132C9C9; Sun, 16 Dec 2018 15:41:12 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79BCC132C9C7 for ; Sun, 16 Dec 2018 15:41:12 +0000 (UTC) (envelope-from db@db.net) Received: from artemis.db.net (artemis.db.net [45.32.229.41]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2428BBDB for ; Sun, 16 Dec 2018 15:41:11 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (artemis.db.net [45.32.229.41]) by artemis.db.net (Postfix) with ESMTP id E1D26101F5; Sun, 16 Dec 2018 15:41:03 +0000 (UTC) Received: by night.db.net (Postfix, from userid 1000) id 13CDC39874; Sun, 16 Dec 2018 10:41:03 -0500 (EST) Date: Sun, 16 Dec 2018 10:41:03 -0500 From: Diane Bruce To: George Neville-Neil Cc: freebsd- Subject: Re: A proposal for code removal prior to FreeBSD 13 Message-ID: <20181216154103.GA12712@night.db.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 1F2428BBDB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,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: Sun, 16 Dec 2018 15:41:13 -0000 On Sun, Dec 16, 2018 at 05:34:05PM +0800, George Neville-Neil wrote: > Howdy, > > A few of us are working on a list of programs and other code that we'd > like to remove before FreeBSD 13. If others with to collaborate on this > removal, or discuss it, please do so here. badblocks -- - db@FreeBSD.org db@db.net http://artemis.db.net/~db From owner-freebsd-arch@freebsd.org Sun Dec 16 19:21:07 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF2C91337C0B for ; Sun, 16 Dec 2018 19:21:07 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4C0937A0 for ; Sun, 16 Dec 2018 19:21:07 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 35B8C1337C03; Sun, 16 Dec 2018 19:21:07 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 245C61337C02 for ; Sun, 16 Dec 2018 19:21:07 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 778CC93790 for ; Sun, 16 Dec 2018 19:21:06 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id wBGJL3F2092571; Sun, 16 Dec 2018 11:21:03 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id wBGJL3GH092570; Sun, 16 Dec 2018 11:21:03 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201812161921.wBGJL3GH092570@pdx.rh.CN85.dnsmgr.net> Subject: Re: A proposal for code removal prior to FreeBSD 13 In-Reply-To: <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net> To: "Bjoern A. Zeeb" Date: Sun, 16 Dec 2018 11:21:03 -0800 (PST) CC: George Neville-Neil , freebsd- 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: 778CC93790 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; REPLY(-4.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, 16 Dec 2018 19:21:08 -0000 > On 16 Dec 2018, at 16:45, Rodney W. Grimes wrote: > > I?ll ignore the ?turning FreeBSD into change-management > procedures? part. > > > timed was removed outside of current procedure, and that should > > be corrected ASAP, > > No, it should not. There is a stable branch, with shipping releases, > and support until at least June 30, 2020, possibly longer. Your confusing "correcting the lack of deprecation notice" with "reverting the removal". As it stands now no deprecation notice has been made per 17.4 of the handbook, that is bad and wrong. The "corrections" needed are to stable/12 now, as direct commits, since it wasnt done correctly in head: 1) timed needs to spit out a message when it is invoked. 2) timed(8) needs a deprecation notice added. 3) The above should be flagged with relnotes: yes so that the 12.1 release notes can state that timed is going away in 13. > > The questions are: > (a) will the request still be relevant then? > (b) do we still want to support it then? > (c) with pkgbase hopefully coming, will it still matter or is it better > off to be ?3rd party? software? > (d) if it?s coming back, do we have a developer to care about it and > take care of the original reason that triggered the removal? I would say it was removed without proper due process and could ask for a revert, but at this time I am not, I am only asking that the proper procedures be minimally adbered to. > > > as one developer has already spoken up that > > they are using it. > > s/developer/user/ ; whether he is a developer as well is not the point. It can be, as often developers are speaking for much more than just a user, any of the develoeprs who support a large deployed base have far more pull in my book than a loan user off in the corner. > > > /bz > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Sun Dec 16 21:32:51 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0985133CBE0 for ; Sun, 16 Dec 2018 21:32:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EE90169A82 for ; Sun, 16 Dec 2018 21:32:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id B26E8133CBDC; Sun, 16 Dec 2018 21:32:50 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FFE4133CBDB for ; Sun, 16 Dec 2018 21:32:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0310369A7F for ; Sun, 16 Dec 2018 21:32:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82d.google.com with SMTP id v11so12110347qtc.2 for ; Sun, 16 Dec 2018 13:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=STBgZsuRG3+448ysic5SgC0Isiawa7HjiPl7ooKqMGo=; b=rcjIPOZsyLvPMwjqOEEeWDGAtYAyt26aqTBoZOHkjuOlpZ6uIMrjKUDmpS/VZ0ui/V WyQRBAswIb5cooDSKQSR99QNGV0AbRWm+tvPQHEWHlwO9pXHg0do39gG+/jtVa4Z8eYW kA3YFsAwVP0r0jkXRgyDqEx79mMtxy0D0gpW1ZaF6sgM+zaHlg3Fs6zloq9XnbuKEqCW PJIeFkU5Zzmc7ZDizi09CJobO6vqGJbWcZjKw2jlFajgwHKgIDT0br9AQm4TniKnEg2i n0i3bh7Q/IYZVyTbLzVmVnQHRy0vYy6fLmjFldsf2xvTGwDr1UVxu9ztqYvAKQV+JjqO MykA== 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=STBgZsuRG3+448ysic5SgC0Isiawa7HjiPl7ooKqMGo=; b=hMA8MNNXv3ifSd8koX2ro7u/4Bf6J9CmOnaO0Pun+Qjce+NjRFo5IE6EZuMXB7pp6h glbyk6Wt5ps/gidRLeeVqt/F+JOFfwoeJ5IxJjY/uPKSQL7xGidPQaq6dwcQLn5zsjIf 6/BRp9Bq9RAcuVjNW9ZLH4z/8ho/BOX0Ks7N9uPZBLybB4Q899c/xT7547fnHzCCJbu9 l2d9b5E8MQoUI31z59A5DME2dFCRleIQlMljyPLvy+QL1CnXbZEJVOAHHNIae1+pUw0h AJQNj3LaPexXF7cCsVCV7tn0UGshAO4FzalZc5go5y8hkaMNLjaomAOluMzFRS4zsXHu AXVw== X-Gm-Message-State: AA+aEWax71iGc5USn7YAvbV/FSaWPL+v3PzHXU9UVj/5otBgHTqynMl5 2Ae9/mhMzdk3FNGmQI0kncIC8eTksAWGTM6Ujne5RW1Y X-Google-Smtp-Source: AFSGD/UWMfldQ5HGRNrdW/QJHJFrluoA4K2a48L99pPwrJecx/ZRQ2KgpeM2C43b1TiZ3DHZxSV2WKEz77dvCd2/JkY= X-Received: by 2002:ac8:42c1:: with SMTP id g1mr11364661qtm.118.1544995969162; Sun, 16 Dec 2018 13:32:49 -0800 (PST) MIME-Version: 1.0 References: <201812161645.wBGGj7qn092076@pdx.rh.CN85.dnsmgr.net> <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net> <80965.1544993496@critter.freebsd.dk> In-Reply-To: <80965.1544993496@critter.freebsd.dk> From: Warner Losh Date: Sun, 16 Dec 2018 14:32:36 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: Poul-Henning Kamp Cc: "Bjoern A. Zeeb" , "freebsd-arch@freebsd.org" , George Neville-Neil , "Rodney W. Grimes" X-Rspamd-Queue-Id: 0310369A7F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; REPLY(-4.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: Sun, 16 Dec 2018 21:32:52 -0000 On Sun, Dec 16, 2018, 1:55 PM Poul-Henning Kamp -------- > In message <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net>, > "Bjoern A > . Zeeb" writes: > > >> timed was removed outside of current procedure, and that should > >> be corrected ASAP, > > > >No, it should not. There is a stable branch, with shipping releases, > >and support until at least June 30, 2020, possibly longer. > This is a bit of a specious argument. While I agree we have time to correct any lack, arguing stable branch lifetimes in prior discussions hasn't been helpful to getting consensus. It's basically telling at someone rather than offering a useful arguement. In this case, we can trivially extract timed into a port and we'd be done. Since the remedy is easy, and this is current, we have the luxury of time needed for rational discourse. >The questions are: > >[...] > (e) Has anybody ever run timed(8) on FreeBSD in the first place ? > (f) What was wrong with them ? > They have. However, the numbers are low. This should not be in base. I'll extract into a github repo (since that has been trivial in the past and preserves history), but someone else will have to do the port. Again, this borders on an ad hominem attack, which history has shown to be not useful in reaching consensus. Warner > From owner-freebsd-arch@freebsd.org Sun Dec 16 22:01:19 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A654133E7C7 for ; Sun, 16 Dec 2018 22:01:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0F656B556 for ; Sun, 16 Dec 2018 22:01:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YaqtRfIVM1kSvZGF._._nBIUecSNXXrYafHE3jryRzDK8bNW3HVaH0.gDTEXNhh qVZkTNz1l24hqdgzE89f1ktPL2a2KXYd2Jd73cq.piu7YDsoZBE11RSZYk8yPLKoOwyFlTyVDpYc 0sNrYmvwbKp1xWJ_48ukn8FsQIWy.ia6Fn16OUo0Mz5FNwzlq3EWNZzZep1JQLveorYxbdDooQFn RsOwbVY4xMkulXe5fcXsm7ilXu6ATouOZRAAjszSSbK1lmtwR_I9UuM22voUdwbhMXgMWGzMXasZ IFzOh.13EIYX6ap8sMVVBQ_h_MRDKnVV5rlJxAu.YSFDRHnO0sDG1kGUOV9CIomTOQ6c79Di0m_a 6UryjmUdILy4R4KYhT6wRyUh9KFgegNmnGYhrXHoHmBVRIJzTPqKJsmui_ldXP8TMA2yqLRMGzJ5 Swhw5ZuShHmzss2nYywhL8dHgCHijWGuLc5zJ.4eR.FshFTP0vU1SpH9q6LnelKDrHiIHFtBWC6I Hs468QPbxsYtAd9EPmmMXj05BYjuf_VZIWRPa68emPwc0sGapHIh1UyC1lgtX4.d3YG5vnAkiD5J DppoMbeBa9.PAW_2G1DcXVFdJ4Ah17oKOrlMh4FJIzJCilh4ONuG_czRpydtHQUVfz0IeWwFBZcq 7YXB9zQJXwjxBTIrObGCEcsTTLi6BdlRGxdwTr.dcdovRB5CQS1GztRo4PEY8qVOso6DDCYtflMU GHIrY1c.2EDIlTZn8v9DBQzO4CpQKnCSmgfuV4HJXIzAWQTzurSLdh4LWIsaUQ8A10gSKio4BtA9 EscXjl.LdOdIXDDiAGJ4EacQImvES6ly4BSCu8QQCbtn8dqfbl2LlJjJ7reIhr.2ro.ucmU7r7rY 3S2xJPFVPNzj05JZsEMjCyurgiNuQYHUO7Q5aYAw9V6wTpXHXvl3zmN5g7i2DOuth69HiPhOHsKu UedHos30gObjo58W72UiVluAIwjUTFJJkXby5_3IOFAD.VIDf7m2urUjdF_i8oGRmmEj3kW.jpAC CbROKU9TIUdKVYQ3hRoJ7TqB2rVX1HIJkxDxYUtnWZMIbQ4QfNCz3W8NK Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Sun, 16 Dec 2018 22:01:12 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp403.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d2ca7a7e0bed290ab9eda4387939fd47 for ; Sun, 16 Dec 2018 22:01:10 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A proposal for code removal prior to FreeBSD 13 Message-Id: <4876C5E3-3169-41EC-9A79-7613F92A9C6D@yahoo.com> Date: Sun, 16 Dec 2018 14:01:08 -0800 To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: A0F656B556 X-Spamd-Bar: +++++ X-Spamd-Result: default: False [5.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.89)[0.888,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; NEURAL_SPAM_MEDIUM(0.98)[0.979,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(1.68)[ip: (5.44), ipnet: 74.6.128.0/21(1.70), asn: 26101(1.36), country: US(-0.08)]; NEURAL_SPAM_LONG(1.00)[0.998,0]; RCVD_IN_DNSWL_NONE(0.00)[124.132.6.74.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[124.132.6.74.rep.mailspike.net : 127.0.0.17] 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, 16 Dec 2018 22:01:19 -0000 Warner Losh imp at bsdimp.com wrote on Sun Dec 16 16:32:35 UTC 2018 : > On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > wrote: >=20 > > Howdy, > > > > A few of us are working on a list of programs and other code that = we'd > > like to remove before FreeBSD 13. If others with to collaborate on = this > > removal, or discuss it, please do so here. > > > > The list is being maintained on the project WIki: > > https://wiki.freebsd.org/WhatsGoing/FreeBSD13 >=20 >=20 > I'm in the process of writing some of the criteria I've been using to = drive > discussions. I've promised a formal policy for a long time, but that's > turning out to be harder than I thought to write and have just = documented > the criteria I look at to do the cost / benefit analysis for things. = It's > skewed a bit towards old drivers and old architectures (or platforms = within > those architectures), but it's likely a useful snowman to work towards > something better. https://wiki.freebsd.org/ObsoleteCriteria >=20 > . . . Given discussions such as the one for -r341682 ( one message being = https://lists.freebsd.org/pipermail/svn-src-head/2018-December/120994.html= ), is a requirement for 64-bit atomics in order to support SMP going to potentially eliminate platforms like the multi-processor 32-bit powerpc support (some old PowerMac models are examples)? Should it be an example in WhatsGoing and a new ProjectPolicy? (While I sometimes have access to a couple of such old PowerMacs and experiment with FreeBSD on them, there is no reason FreeBSD should consider that in any way. I'm just referencing an existing example context.) Separately: Is there a fairly complete list of the Project Policies someplace? Each possibly with the matching MD requirements implications (when there are some)? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arch@freebsd.org Mon Dec 17 01:27:37 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EDB91345800 for ; Mon, 17 Dec 2018 01:27:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A729972412 for ; Mon, 17 Dec 2018 01:27:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id 189so6457650qkj.8 for ; Sun, 16 Dec 2018 17:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U9AkXEBea8Gvg6xnjUJoesJfXBptSBmJr7nRM4Yl/5A=; b=cg34voB2XKdRnATBvbZMJVZB/TDj8dhWH51jd7zaJuPXTA4ct22ZtruPqllufryjWc Hl5TH1pYVJxQzJQtwaM6LUVX695m4pJqiY+gBPQpRZhniG3VEvRDEf3alwr9wlG0Bc49 e3WnBTkWgvGfiz+1BZOTfPq8e9Oc3fjCrvBjb/9KrIMbrN7ae9EEYIBTYhZz1+g4N5gK lm6rLdJVxqwV9h/rDY6cTwr7qUadb9+MH7S1AZ3rackfpb/0vB9gIYSF1MZQW8k8eVd3 W7VDGZv0QIkwEaR+ojO4CZhZ+QcpDmEpBfV3wEbQ1MAphL6SiTXzkY3kwGMChzxI9ECk Kvtg== 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=U9AkXEBea8Gvg6xnjUJoesJfXBptSBmJr7nRM4Yl/5A=; b=aD1nRDdfY4lQlBnpk1OBg/cigJe9Xj7/UVPrNpLV56PavbVqNe8oDxXj8LQxby2YC3 QJzS4pcvjXo10Qejv+yXH6rF2W3W+anYpDpCFcXAq25EcZprFZ8Vsc0pn3JFzc9tLput Z4SDvfbPUGOSH4LvZh/2kZYrYTkdgepCh5GX68A9cJzlbdaGLXHAPLwjozo0VNWcx6/+ vFZZzV/Iiflqpxipnwp5jb/wIX2F2QTLPppgCWxsPzCxHc1+Xfgso8+WHH3X11QCPJ2X QBHskWGAZVJEDqeM0gu2Tv6TmZSmPCCJJvDF4bSg4APxsSoJ6PV7+Uxyk5yTbPDkWRUS MQLA== X-Gm-Message-State: AA+aEWadj4PQaGKOXKNjs6pqMSRGW92PO71SYSGnpjE4+JNefxVgqlM8 vys2ZbdYLHVplEMBIW2YPJfMjaoOA/1cT8JMBPUZd4ZU X-Google-Smtp-Source: AFSGD/XfWsUPHgd8maBdHrarI0MHoZ5MkbbBWCpHnBH7fJnErfm502ZrxQXjWpC0jDgCa0Fh6SMM7+7h5vBmr8NiMWg= X-Received: by 2002:a37:6e86:: with SMTP id j128mr11045386qkc.46.1545010056029; Sun, 16 Dec 2018 17:27:36 -0800 (PST) MIME-Version: 1.0 References: <4876C5E3-3169-41EC-9A79-7613F92A9C6D@yahoo.com> In-Reply-To: <4876C5E3-3169-41EC-9A79-7613F92A9C6D@yahoo.com> From: Warner Losh Date: Sun, 16 Dec 2018 18:27:25 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: Mark Millard Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: A729972412 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=cg34voB2 X-Spamd-Result: default: False [-5.23 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[0.3.7.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]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.26)[ip: (-8.25), ipnet: 2607:f8b0::/32(-1.63), asn: 15169(-1.33), country: US(-0.08)]; RCVD_COUNT_TWO(0.00)[2] 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, 17 Dec 2018 01:27:37 -0000 On Sun, Dec 16, 2018 at 5:34 PM Mark Millard via freebsd-arch < freebsd-arch@freebsd.org> wrote: > Given discussions such as the one for -r341682 ( one message being > https://lists.freebsd.org/pipermail/svn-src-head/2018-December/120994.html > ), > is a requirement for 64-bit atomics in order to support SMP > going to potentially eliminate platforms like the multi-processor > 32-bit powerpc support (some old PowerMac models are examples)? > Should it be an example in WhatsGoing and a new ProjectPolicy? > Maybe. That's not a terrible idea, but we have a lot of things that are currently just unwritten rules, and I'm not keen to write them all down. I don't have the time. I do have the time to toss together something for mips, and see what the implications are, so I'm limiting myself to that. > Is there a fairly complete list of the Project Policies someplace? > Each possibly with the matching MD requirements implications (when > there are some)? > There should be a list, but there isn't. Some are well documented, others no doubt live just in a few people's heads. I'd love to see it, but that windmill is too large for me to tilt at. It's hard to reconstruct a list we should have maintained incrementally over the last 25 years. It might also not be bad to manage longer-term transitions via some kind of roadmap that looks out a release or three. But before we can get to that point, we need to clean up the accumulated technical debt wrt obsolescence in the code base today. Warner From owner-freebsd-arch@freebsd.org Mon Dec 17 01:15:47 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF86F1345300 for ; Mon, 17 Dec 2018 01:15:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF9571F37 for ; Mon, 17 Dec 2018 01:15:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id CD61A13452FF; Mon, 17 Dec 2018 01:15:45 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAC4613452FE for ; Mon, 17 Dec 2018 01:15:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 437CA71F36 for ; Mon, 17 Dec 2018 01:15:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x735.google.com with SMTP id 68so6448232qke.9 for ; Sun, 16 Dec 2018 17:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bqwu5BuPL9z44oC2QeT/bL0rmzgjkFYRjilX1aSc/+A=; b=ckV6jBrcxSIB4B4k0en0eG7pbcOe59waTB8HOhZx/GVPx8OtVQA2pHnsmfpMSfZtU8 /IH7pOaLTE14Fb/4vFpQ2ovryUE1Q7SRBlRvEK5MNHRzIlt0WB0vQs3mCBOs3GJ0t32E Wh06CQ/5drnehE5iarheB/wmlO6Is22uXYdoB2d5sxTfvnBq5pQgFlt9HgG+mVsRLdzT f7WuaGKu/LhvSRPsBmaVd3/dGKS2JQhTT4hqR+yE45nTqhAKgZKWE8WAeckPuPuZSXoy ZcJ29PcHRd12wUOwp86jiggslXHf2jh8yvD3x7Y6yVJhTcUDn+EAPf4hTqlFiyoSMTAg wDVw== 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=Bqwu5BuPL9z44oC2QeT/bL0rmzgjkFYRjilX1aSc/+A=; b=tnGKZcv3arGRoNivcnxXdzHx9GJrDqRvi1PcgbAObDICS1az9HFbpU3s2muC4PhJhX /nfc91d+w7W/IWIhNrpzN7UIejV0wj0eBZeowLE+GX61TI8V8TP9WGL0we9OmTmEua6O A+bX1n+G4jrsJcmcCfM4ym8Ej25kSYEUqZ7F6KT8mVnKVjQJh3gcOFOx+t9/1V+dXgiJ xHoFbLgMeWKxqApJ/d0MN6H1oeVTmQpeca91JG27XE0JLOTq36+pP26gUnUBbW6Bvql4 XANn7nZQ64l/tmegsKaJObhnuJMFCVVxgVkY+3/drHvUVUUNvgNcrWUxyLLmg2XJTX6P CzIg== X-Gm-Message-State: AA+aEWaAmcghWRjzd3ZQ6VTi2YnwMeDYrrhr9udWxkHLty8ObZqy3cr+ Xpm7lx9T1HCI9U1B/Ul/SyPlD0rRVWWioUoJm8nozyrZ X-Google-Smtp-Source: AFSGD/VXUTgW/X24snhDVuTKDWLX7WeVzOjbSY2XmJCu9APd9JEPxzRbB6JJfujVLdzYnkeRa7Pcj3RqR9Gvn1pmnHI= X-Received: by 2002:a37:6c05:: with SMTP id h5mr10720433qkc.175.1545009344603; Sun, 16 Dec 2018 17:15:44 -0800 (PST) MIME-Version: 1.0 References: <201812161645.wBGGj7qn092076@pdx.rh.CN85.dnsmgr.net> <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net> In-Reply-To: <261A6437-3ECC-43FF-ADA2-EE430477BB92@lists.zabbadoz.net> From: Warner Losh Date: Sun, 16 Dec 2018 18:15:33 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: "Bjoern A. Zeeb" Cc: "Rodney W. Grimes" , freebsd- , George Neville-Neil X-Rspamd-Queue-Id: 437CA71F36 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.962,0]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 17 Dec 2018 01:15:47 -0000 On Sun, Dec 16, 2018 at 1:45 PM Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > I=E2=80=99ll ignore the =E2=80=9Cturning FreeBSD into change-management > procedures=E2=80=9D part. > OK. I can't let that slide by without comment. What we've had for the past 10 years hasn't worked. Evidence: there's a lot of junk in the tree. People have been afraid to deprecate because there's too much friction. Why's that? Because when people just got a bug up their butt and deleted stuff, people complained (and rightly so). So we, as a project, have been afraid to do anything. I started breaking that log-jam about 6 or 9 months ago when I started the ball rolling on getting rid of the really old arm bits. I learned a lot from that. We learned a lot from the 10/100 stuff. I've learned from other things big and small. That's why I wrote up the evaluation criteria: to try to move to a data-driven process. Sadly, we have no telemetry in our systems due to longly held notions that it's too invasive to do it, so we didn't have it, even on an opt-in basis. We have very little usage data. Absent, that we have to guess. Every single set of guesses I made in my deprecation quest has had at least one flaw in it. These flaws, however, have often been brought to light by socializing the plan widely and letting people comment. In some cases, the comments were addressed as "you don't understand, let me explain it" and in other cases it was "I didn't understand, let me amend my proposal". In both cases the proposal was better after the review. But it's tricky... without the proper guidance, these discussions can go off into the weeds quickly (so people have been reluctant to do them). The key, imho, is making them of small enough scope that all the issues that arise can be dealt with, yet big enough to make it worth the other costs. Honestly, it's gone much more smoothly than I feared when I started. The more I've talked to people (not just developers, or the echo chamber of people I talk to a lot), the more I find the weird places FreeBSD is in use, the more data I gather, the more that I can understand what's going on. And the more I've talked to people about what I'd like to do, the more they are understanding when things don't go like they'd hoped because they know they have had their say fairly considered. So what I've started writing up isn't some mandatory straight jacket for the project, but instead a set of best practices. This has worked well in the past, that hasn't worked, etc. Everybody wants to do their job, including deprecation, with a minimum of friction. But that doesn't necessarily mean "just do it": that path just back loads the friction to after the commit and leaves too much hard feelings. And we don't want to talk it to death before the commit: nobody wants that either. And we've been stuck, as a project, for a long time. I'm hoping to break the log jam and find some guidelines that will help us, as a project talk to all the stakeholders about the issues in a productive way that lets us move forward= . So this isn't at all about process for process sake, nor about creating a new straight jacket to replace the old one of fear that we've worn for too long. It's about using an open approach to hopefully solve this problem once and for all so we can remove what we need to in a healthy and functional way. Sorry for the bit of a rant, but I've been working on this now for a while and don't want to see us return to the bad-old-days. Warner From owner-freebsd-arch@freebsd.org Mon Dec 17 02:22:50 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A2C91348456 for ; Mon, 17 Dec 2018 02:22:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (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 3DADA7586E for ; Mon, 17 Dec 2018 02:22:47 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id YiYNg78G082YcYiYOgTkn4; Sun, 16 Dec 2018 19:22:45 -0700 X-Authority-Analysis: v=2.3 cv=NNSrBHyg c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=2ur7OfE09M0A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=7Qk2ozbKAAAA:8 a=bwMe9klDAAAA:8 a=CjxXgO3LAAAA:8 a=YVOhz5M6AAAA:8 a=qBNBEYK8NDfPaENezUIA:9 a=pNVR8HU0O-pp4oI2:21 a=VDy_9tyRED5suvJa:21 a=CjuIK1q_8ugA:10 a=VNLA6R8-XPsA:10 a=EsyWbJrJ7QmuwIqft8sA:9 a=H3b9sZRW7BjJYh5-:21 a=ooDWF_agynDIWXds:21 a=mjY856s3pmdkwkYW:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=1lyxoWkJIXJV6VJUPhuM:22 a=JhGllAdGin1EU15OQ7Be:22 a=sbbTL3E6IKcx-RquDtO-:22 Received: from [192.168.1.76] (d23-16-123-169.bchsia.telus.net [23.16.123.169]) by spqr.komquats.com (Postfix) with ESMTPSA id C88143C69; Sun, 16 Dec 2018 18:22:42 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: A proposal for code removal prior to FreeBSD 13 Date: Sun, 16 Dec 2018 18:22:44 -0800 To: Mark Millard , "freebsd-arch@freebsd.org" Message-Id: <20181217022242.C88143C69@spqr.komquats.com> X-CMAE-Envelope: MS4wfGifXbH58EI60oUskBKR4nYiJTsQv6VmE7Xd9ZI0zUWwV2QWy+JltLImNsW2uu51tKRozxO7auGjyefhCJn1as8gccOzMG8Y7ZQqqTrqIe3mdVQZ9lUr Ux1LXzChZp21htYFywlYWfntwkyXuZxotHE734lbiou9XoT6sPwH2A+aqV7aj2vPJ4kZKWtCJj6mhJeqNWd5UMkhMym7+9u9UBQ= X-Rspamd-Queue-Id: 3DADA7586E X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-3.13 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; URI_COUNT_ODD(1.00)[7]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[spqr.komquats.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.91)[-0.915,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[137.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:+,1:+]; IP_SCORE(-2.01)[ip: (-4.97), ipnet: 64.59.128.0/20(-2.77), asn: 6327(-2.22), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, 17 Dec 2018 02:22:50 -0000 Picking a random email to reply to, the process should also include determi= nation whether to migrate the software /feature to ports is required. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Mark Millard via freebsd-arch Sent: 16/12/2018 16:34 To: freebsd-arch@freebsd.org Subject: Re: A proposal for code removal prior to FreeBSD 13 Warner Losh imp at bsdimp.com wrote on Sun Dec 16 16:32:35 UTC 2018 : > On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > wrote: >=20 > > Howdy, > > > > A few of us are working on a list of programs and other code that we'd > > like to remove before FreeBSD 13. If others with to collaborate on thi= s > > removal, or discuss it, please do so here. > > > > The list is being maintained on the project WIki: > > https://wiki.freebsd.org/WhatsGoing/FreeBSD13 >=20 >=20 > I'm in the process of writing some of the criteria I've been using to dri= ve > discussions. I've promised a formal policy for a long time, but that's > turning out to be harder than I thought to write and have just documented > the criteria I look at to do the cost / benefit analysis for things. It's > skewed a bit towards old drivers and old architectures (or platforms with= in > those architectures), but it's likely a useful snowman to work towards > something better. https://wiki.freebsd.org/ObsoleteCriteria >=20 > . . . Given discussions such as the one for -r341682 ( one message being https://lists.freebsd.org/pipermail/svn-src-head/2018-December/120994.html = ), is a requirement for 64-bit atomics in order to support SMP going to potentially eliminate platforms like the multi-processor 32-bit powerpc support (some old PowerMac models are examples)? Should it be an example in WhatsGoing and a new ProjectPolicy? (While I sometimes have access to a couple of such old PowerMacs and experiment with FreeBSD on them, there is no reason FreeBSD should consider that in any way. I'm just referencing an existing example context.) Separately: Is there a fairly complete list of the Project Policies someplace? Each possibly with the matching MD requirements implications (when there are some)? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ 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 Mon Dec 17 04:49:54 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1F9D13258B7 for ; Mon, 17 Dec 2018 04:49:54 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 20CD08235E for ; Mon, 17 Dec 2018 04:49:54 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id D8A2013258B6; Mon, 17 Dec 2018 04:49:53 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B604F13258B5 for ; Mon, 17 Dec 2018 04:49:53 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (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 348C98235D for ; Mon, 17 Dec 2018 04:49:53 +0000 (UTC) (envelope-from gnn@neville-neil.com) X-Originating-IP: 118.169.45.207 Received: from [10.37.129.2] (118-169-45-207.dynamic-ip.hinet.net [118.169.45.207]) (Authenticated sender: gnn@neville-neil.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 9E4A720006; Mon, 17 Dec 2018 04:49:21 +0000 (UTC) From: "George Neville-Neil" To: "Rodney W. Grimes" Cc: "Warner Losh" , freebsd- Subject: Re: A proposal for code removal prior to FreeBSD 13 Date: Mon, 17 Dec 2018 12:49:17 +0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: In-Reply-To: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> References: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Rspamd-Queue-Id: 348C98235D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,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: Mon, 17 Dec 2018 04:49:55 -0000 On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil >> >> wrote: >> >>> Howdy, >>> >>> A few of us are working on a list of programs and other code that >>> we'd >>> like to remove before FreeBSD 13. If others with to collaborate on >>> this >>> removal, or discuss it, please do so here. >>> >>> The list is being maintained on the project WIki: >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 >> >> >> I'm in the process of writing some of the criteria I've been using to >> drive >> discussions. I've promised a formal policy for a long time, but >> that's >> turning out to be harder than I thought to write and have just >> documented >> the criteria I look at to do the cost / benefit analysis for things. >> It's >> skewed a bit towards old drivers and old architectures (or platforms >> within >> those architectures), but it's likely a useful snowman to work >> towards >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > THANK YOU!!! > >> This doesn't get into the process at all of who to have the >> conversation >> with, what steps you go through to ensure that there's a transition >> plan >> for current users (if there's enough to warrant it), etc. It's just a >> set >> of things I've found useful to think about and that I think the >> project >> should adopt (with refinement) as a standard template to use when >> making >> these calls. > > Can you also draft a short proposal on the "process" of deprecation? > Based I guess on our current model, with the addition of some of the > macros and other stuff you and Brooks worked on, the gone_in stuff > is what I am thinking. How to do the head commit with the deprecation > notices, merge that back if applicable, then do the remove when > appropriate. Basically a more complete flushed out version of: > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules > @ 17.4. We should also IMHO do some work smithing and rearrangement > to > make this read much more as steps, some of the steps as listed have > substeps that appear to be overlooked often. > > Something like this: > 17.4. Deprecating Features > > When it is necessary to remove functionality from software in > the base system, follow these guidelines whenever possible: > > 1. Use of the deprecated feature generates a warning. > 2. Mention is made in the manual page and the release > notes that the option, utility, or interface is deprecated. > (I removed the word possible here, we should always > mention deprecation of features in the release notes) > 3. The option, utility, or interface is preserved until > the next major (point zero) release. Given the age of some of the things in our tree, of which timed was a classic example, I hardly think that this rule will work in our favor. Removing old code reduces our attack surface, and keeping something that's been dead for years, for another 2 years, seems problematic at the very least. Some of the software now on the proposed removal list should have been gone by 11 or 12. Best, George From owner-freebsd-arch@freebsd.org Mon Dec 17 04:59:15 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D24401325D18 for ; Mon, 17 Dec 2018 04:59:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 38BA18279D for ; Mon, 17 Dec 2018 04:59:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id F0D591325D17; Mon, 17 Dec 2018 04:59:13 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE4311325D16 for ; Mon, 17 Dec 2018 04:59:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D4CF8279C for ; Mon, 17 Dec 2018 04:59:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id v11so12812031qtc.2 for ; Sun, 16 Dec 2018 20:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sFibhANZ0sVTlk5AhXfkmJw8Eu58m6AhqgqlSjF3gjo=; b=euNM20s/sVpFaSNO6Rn70qvB51bvxmiLkgzKcHusgdAUWv9xDe+CwCP3IXbn6eojgJ zeaFbZv7iL5ms2CSI8GsQ7OsiDdPt//TS+5O1r3ePCgcQVBXIqCjl7+7jFx0GEb2jipb AeBNpp3f5J/MQ8WB1qDRZElTI4ZFEOW79xPtc3MKzGKIrVNCbSJiREH+1GKpvk4wuY77 g+nIHzJU604/+PquG16GFK96Bzb9fe7G5urjK+IzPQRR4CPG5jYqP8dPBNsLH4uS4h6v JIOKHFJLFSkYi4lEbH73T8DUNJ+80pVXpR2coqVhfrr82lw3cYPM5P73/6cEMlaOa5TI PpMA== 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=sFibhANZ0sVTlk5AhXfkmJw8Eu58m6AhqgqlSjF3gjo=; b=M6lZnk7mku5TGFPGU5bHRqM81Gh9ALFMWFJEex18dG6cws6+3iiy1HmF9blrGrdKuH cJjRHyiZvhrG8Ye6KaTJCDtCo67Ic1BdJmDLBWcggxS3wc6L0qlXSZjLh25Ovuzt62rH tJyGEwA+IlnOg6FA+MRrC+mYjSISOC/r0YEu50o513WOGuI6SHMzvgSDB6KELVOFUW6J IcRSRxmdB/icrLKfmY9/J35X2BXmqbVe7aPhkoIZSE9jShYjDpuRD0iF8Op/e9D9vdmN xScUAKlSHyWbNs0XiJItQhzgsmFvYoKvgARhjirJ7wx0Fvyb+qViedJFzjm1TtDeYrOS RIfQ== X-Gm-Message-State: AA+aEWa60Md52pDKPtIJUbBPz8sQ87CuOSBw0z9cohn0+QnL9txS39uR x6f5VwHNYhcOR/hu3s/DQmgyjYoX6kuwPHU14K8U8A== X-Google-Smtp-Source: AFSGD/WX4jc83iTG1nBW56HETyQqKjjyHxckSfEi5UOb81puOLkBBjkzeEC34MZpamTrmUuGmkTU2pcI2ILvZWxfc9k= X-Received: by 2002:a0c:f143:: with SMTP id y3mr12013939qvl.21.1545022752763; Sun, 16 Dec 2018 20:59:12 -0800 (PST) MIME-Version: 1.0 References: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Sun, 16 Dec 2018 21:58:59 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: George Neville-Neil Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 6D4CF8279C X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,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: Mon, 17 Dec 2018 04:59:15 -0000 On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil > > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: > > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > >> > >> wrote: > >> > >>> Howdy, > >>> > >>> A few of us are working on a list of programs and other code that > >>> we'd > >>> like to remove before FreeBSD 13. If others with to collaborate on > >>> this > >>> removal, or discuss it, please do so here. > >>> > >>> The list is being maintained on the project WIki: > >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > >> > >> > >> I'm in the process of writing some of the criteria I've been using to > >> drive > >> discussions. I've promised a formal policy for a long time, but > >> that's > >> turning out to be harder than I thought to write and have just > >> documented > >> the criteria I look at to do the cost / benefit analysis for things. > >> It's > >> skewed a bit towards old drivers and old architectures (or platforms > >> within > >> those architectures), but it's likely a useful snowman to work > >> towards > >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > > > THANK YOU!!! > > > >> This doesn't get into the process at all of who to have the > >> conversation > >> with, what steps you go through to ensure that there's a transition > >> plan > >> for current users (if there's enough to warrant it), etc. It's just a > >> set > >> of things I've found useful to think about and that I think the > >> project > >> should adopt (with refinement) as a standard template to use when > >> making > >> these calls. > > > > Can you also draft a short proposal on the "process" of deprecation? > > Based I guess on our current model, with the addition of some of the > > macros and other stuff you and Brooks worked on, the gone_in stuff > > is what I am thinking. How to do the head commit with the deprecation > > notices, merge that back if applicable, then do the remove when > > appropriate. Basically a more complete flushed out version of: > > > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules > > @ 17.4. We should also IMHO do some work smithing and rearrangement > > to > > make this read much more as steps, some of the steps as listed have > > substeps that appear to be overlooked often. > > > > Something like this: > > 17.4. Deprecating Features > > > > When it is necessary to remove functionality from software in > > the base system, follow these guidelines whenever possible: > > > > 1. Use of the deprecated feature generates a warning. > > 2. Mention is made in the manual page and the release > > notes that the option, utility, or interface is deprecated. > > (I removed the word possible here, we should always > > mention deprecation of features in the release notes) > > 3. The option, utility, or interface is preserved until > > the next major (point zero) release. > > Given the age of some of the things in our tree, of which timed was a > classic example, I hardly think that this rule will work in our favor. > Removing old code reduces our attack surface, and keeping something > that's been dead for years, for another 2 years, seems problematic at > the very least. Some of the software now on the proposed removal list > should have been gone by 11 or 12. > If it's old, we should remove it. The one major release thing is nice to have in the steady state where you are caught up and retire things just in time. For the backlog we have, though, it will just get in the way. But in this case all we need to do is a direct commit to fix the man page in 12 to say it is gone in 13.... Warner > From owner-freebsd-arch@freebsd.org Mon Dec 17 05:38:32 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0C9C132D20F for ; Mon, 17 Dec 2018 05:38:31 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 32F3183CB3 for ; Mon, 17 Dec 2018 05:38:31 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id EB07A132D20E; Mon, 17 Dec 2018 05:38:30 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8768132D20D for ; Mon, 17 Dec 2018 05:38:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (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 4438383CB2 for ; Mon, 17 Dec 2018 05:38:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) X-Originating-IP: 118.169.45.207 Received: from [10.37.129.2] (118-169-45-207.dynamic-ip.hinet.net [118.169.45.207]) (Authenticated sender: gnn@neville-neil.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id E92451C0005; Mon, 17 Dec 2018 05:38:20 +0000 (UTC) From: "George Neville-Neil" To: "Warner Losh" Cc: "Rodney W. Grimes" , freebsd- Subject: Re: A proposal for code removal prior to FreeBSD 13 Date: Mon, 17 Dec 2018 13:38:15 +0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: In-Reply-To: References: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Rspamd-Queue-Id: 4438383CB2 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,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: Mon, 17 Dec 2018 05:38:32 -0000 On 17 Dec 2018, at 12:58, Warner Losh wrote: > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil > wrote: > >> >> >> On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: >> >>>> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil >>>> >>>> wrote: >>>> >>>>> Howdy, >>>>> >>>>> A few of us are working on a list of programs and other code that >>>>> we'd >>>>> like to remove before FreeBSD 13. If others with to collaborate >>>>> on >>>>> this >>>>> removal, or discuss it, please do so here. >>>>> >>>>> The list is being maintained on the project WIki: >>>>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 >>>> >>>> >>>> I'm in the process of writing some of the criteria I've been using >>>> to >>>> drive >>>> discussions. I've promised a formal policy for a long time, but >>>> that's >>>> turning out to be harder than I thought to write and have just >>>> documented >>>> the criteria I look at to do the cost / benefit analysis for >>>> things. >>>> It's >>>> skewed a bit towards old drivers and old architectures (or >>>> platforms >>>> within >>>> those architectures), but it's likely a useful snowman to work >>>> towards >>>> something better. https://wiki.freebsd.org/ObsoleteCriteria >>> >>> THANK YOU!!! >>> >>>> This doesn't get into the process at all of who to have the >>>> conversation >>>> with, what steps you go through to ensure that there's a transition >>>> plan >>>> for current users (if there's enough to warrant it), etc. It's just >>>> a >>>> set >>>> of things I've found useful to think about and that I think the >>>> project >>>> should adopt (with refinement) as a standard template to use when >>>> making >>>> these calls. >>> >>> Can you also draft a short proposal on the "process" of deprecation? >>> Based I guess on our current model, with the addition of some of the >>> macros and other stuff you and Brooks worked on, the gone_in stuff >>> is what I am thinking. How to do the head commit with the >>> deprecation >>> notices, merge that back if applicable, then do the remove when >>> appropriate. Basically a more complete flushed out version of: >>> >> https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules >>> @ 17.4. We should also IMHO do some work smithing and rearrangement >>> to >>> make this read much more as steps, some of the steps as listed have >>> substeps that appear to be overlooked often. >>> >>> Something like this: >>> 17.4. Deprecating Features >>> >>> When it is necessary to remove functionality from software in >>> the base system, follow these guidelines whenever possible: >>> >>> 1. Use of the deprecated feature generates a warning. >>> 2. Mention is made in the manual page and the release >>> notes that the option, utility, or interface is deprecated. >>> (I removed the word possible here, we should always >>> mention deprecation of features in the release notes) >>> 3. The option, utility, or interface is preserved until >>> the next major (point zero) release. >> >> Given the age of some of the things in our tree, of which timed was a >> classic example, I hardly think that this rule will work in our >> favor. >> Removing old code reduces our attack surface, and keeping something >> that's been dead for years, for another 2 years, seems problematic at >> the very least. Some of the software now on the proposed removal >> list >> should have been gone by 11 or 12. >> > > If it's old, we should remove it. The one major release thing is nice > to > have in the steady state where you are caught up and retire things > just in > time. For the backlog we have, though, it will just get in the way. > But in > this case all we need to do is a direct commit to fix the man page in > 12 to > say it is gone in 13.... > Works for me. Thanks, George From owner-freebsd-arch@freebsd.org Mon Dec 17 07:22:40 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEF6A1331FC4 for ; Mon, 17 Dec 2018 07:22:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E882287330 for ; Mon, 17 Dec 2018 07:22:39 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id A6BCA1331FC2; Mon, 17 Dec 2018 07:22:39 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 847251331FC1 for ; Mon, 17 Dec 2018 07:22:39 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 064558732D for ; Mon, 17 Dec 2018 07:22:38 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id wBH7MS8W094819; Sun, 16 Dec 2018 23:22:28 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id wBH7MRhO094818; Sun, 16 Dec 2018 23:22:27 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201812170722.wBH7MRhO094818@pdx.rh.CN85.dnsmgr.net> Subject: Re: A proposal for code removal prior to FreeBSD 13 In-Reply-To: To: Warner Losh Date: Sun, 16 Dec 2018 23:22:27 -0800 (PST) CC: George Neville-Neil , "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: 064558732D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-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: Mon, 17 Dec 2018 07:22:40 -0000 > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil wrote: > > > > > > > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: > > > > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > > >> > > >> wrote: > > >> > > >>> Howdy, > > >>> > > >>> A few of us are working on a list of programs and other code that > > >>> we'd > > >>> like to remove before FreeBSD 13. If others with to collaborate on > > >>> this > > >>> removal, or discuss it, please do so here. > > >>> > > >>> The list is being maintained on the project WIki: > > >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > > >> > > >> > > >> I'm in the process of writing some of the criteria I've been using to > > >> drive > > >> discussions. I've promised a formal policy for a long time, but > > >> that's > > >> turning out to be harder than I thought to write and have just > > >> documented > > >> the criteria I look at to do the cost / benefit analysis for things. > > >> It's > > >> skewed a bit towards old drivers and old architectures (or platforms > > >> within > > >> those architectures), but it's likely a useful snowman to work > > >> towards > > >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > > > > > THANK YOU!!! > > > > > >> This doesn't get into the process at all of who to have the > > >> conversation > > >> with, what steps you go through to ensure that there's a transition > > >> plan > > >> for current users (if there's enough to warrant it), etc. It's just a > > >> set > > >> of things I've found useful to think about and that I think the > > >> project > > >> should adopt (with refinement) as a standard template to use when > > >> making > > >> these calls. > > > > > > Can you also draft a short proposal on the "process" of deprecation? > > > Based I guess on our current model, with the addition of some of the > > > macros and other stuff you and Brooks worked on, the gone_in stuff > > > is what I am thinking. How to do the head commit with the deprecation > > > notices, merge that back if applicable, then do the remove when > > > appropriate. Basically a more complete flushed out version of: > > > > > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules > > > @ 17.4. We should also IMHO do some work smithing and rearrangement > > > to > > > make this read much more as steps, some of the steps as listed have > > > substeps that appear to be overlooked often. > > > > > > Something like this: > > > 17.4. Deprecating Features > > > > > > When it is necessary to remove functionality from software in > > > the base system, follow these guidelines whenever possible: > > > > > > 1. Use of the deprecated feature generates a warning. > > > 2. Mention is made in the manual page and the release > > > notes that the option, utility, or interface is deprecated. > > > (I removed the word possible here, we should always > > > mention deprecation of features in the release notes) > > > 3. The option, utility, or interface is preserved until > > > the next major (point zero) release. > > > > Given the age of some of the things in our tree, of which timed was a > > classic example, I hardly think that this rule will work in our favor. > > Removing old code reduces our attack surface, and keeping something > > that's been dead for years, for another 2 years, seems problematic at > > the very least. Some of the software now on the proposed removal list > > should have been gone by 11 or 12. Not giving the users proper and adaquate notification is asking for problems as well. In the case of amd(8) at least the man page has had a obsolete notice in it with a pointer to autofs for some time (my 11.1 systems have such notice, not sure how far back that goes.) And again, age is not the correct metric, BSD is near 40 years old, I think the word you want is obsolete, which is more correct. Also timed appears to be in use, so what might be dead to you is useful to someone else. I would also argue that the attack surface of timed is much smaller than the attack surface of ntpd, shall we remove ntpd to reduce our attack surface? I can not recall any cve against timed, I can recall many against ntpd. > > > > If it's old, we should remove it. The one major release thing is nice to > have in the steady state where you are caught up and retire things just in > time. For the backlog we have, though, it will just get in the way. But in > this case all we need to do is a direct commit to fix the man page in 12 to > say it is gone in 13.... Yes, we can short circuit the process, but we should not just skip the process. Need to fix both the man page and the binary to output a message when it is invoked, and that needs to be commited to both stable/11 and stable/12. The prefered method would of been to do the notification stuff in head, then merge that back to stable/11 and /12, then do the remove in head. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Mon Dec 17 14:47:56 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17E33134203A for ; Mon, 17 Dec 2018 14:47:56 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7C92970F9F for ; Mon, 17 Dec 2018 14:47:55 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3D0551342039; Mon, 17 Dec 2018 14:47:55 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E405B1342038 for ; Mon, 17 Dec 2018 14:47:54 +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 C5DD170F9E for ; Mon, 17 Dec 2018 14:47:53 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id YuBQg9YKw82YcYuBSgV2w3; Mon, 17 Dec 2018 07:47:51 -0700 X-Authority-Analysis: v=2.3 cv=NNSrBHyg c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=2ur7OfE09M0A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=bwMe9klDAAAA:8 a=VTWyxu5DedH-0-nXvmIA:9 a=ltAi-Rp98VTtnzWf:21 a=DxOPEib6MtH8yqOx:21 a=CjuIK1q_8ugA:10 a=y67m5O9eZnAA:10 a=SUeZF4jyd0UA:10 a=2kzxNj7n_G1ZtbSJKisA:9 a=Dzz8gfxZjkyELpAn:21 a=j3PwbsZ1kHy_883a:21 a=y0QbNfLZVMJjxdVI:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=JhGllAdGin1EU15OQ7Be:22 Received: from [25.81.116.22] (unknown [72.143.225.69]) by spqr.komquats.com (Postfix) with ESMTPSA id D9D354793; Mon, 17 Dec 2018 06:47:46 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: A proposal for code removal prior to FreeBSD 13 Date: Mon, 17 Dec 2018 06:47:47 -0800 To: "Rodney W. Grimes" , Warner Losh CC: "freebsd-arch@freebsd.org" , George Neville-Neil Message-Id: <20181217144746.D9D354793@spqr.komquats.com> X-CMAE-Envelope: MS4wfD4+M8eDXY9fSrfTFkIqAHNq6ve76itk/Nl+HsOJVEPvfE4DWpdWC6udZKSMJW5xciCAoIPchGUU4gSrPNp//xl0ET9ujugZ2JWPMHOLzUPBKvn8d8xh 4EJzswnM6WHajhvTLwDGDX7/s8rHvhWw9LNMlL84K8RUZkwHfAqTy1zVyQc9h8bwqosw96/Rp+S1VtHHN0liLCjGAK74ov50ijdQ8pidZGEnSCAL1u0ZhONl EvBXLbl7ioppL5BkODTtfPD9mmiy6QL8IFAhxXrJInai1IqvAHiabOFUEMDGwYHC X-Rspamd-Queue-Id: C5DD170F9E X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.10 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: spqr.komquats.com]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; 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:+,1:+]; IP_SCORE(-1.89)[ip: (-4.36), ipnet: 64.59.128.0/20(-2.78), asn: 6327(-2.22), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, 17 Dec 2018 14:47:56 -0000 A couple of points: Yes, I don't recall amd(8) or timed(8) ever having CVEs against them -- we = cannot predict the future though. Ntp is another matter. Hardly a year goes= by when we receive yet another update due to a CVE, sometimes more. (Sadly= ntp is maintained only for security patches, all other development has cea= sed.) --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Rodney W. Grimes Sent: 16/12/2018 23:23 To: Warner Losh Cc: freebsd-arch@freebsd.org; George Neville-Neil Subject: Re: A proposal for code removal prior to FreeBSD 13 > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil wrote: >=20 > > > > > > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: > > > > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > > >> > > >> wrote: > > >> > > >>> Howdy, > > >>> > > >>> A few of us are working on a list of programs and other code that > > >>> we'd > > >>> like to remove before FreeBSD 13. If others with to collaborate on > > >>> this > > >>> removal, or discuss it, please do so here. > > >>> > > >>> The list is being maintained on the project WIki: > > >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > > >> > > >> > > >> I'm in the process of writing some of the criteria I've been using t= o > > >> drive > > >> discussions. I've promised a formal policy for a long time, but > > >> that's > > >> turning out to be harder than I thought to write and have just > > >> documented > > >> the criteria I look at to do the cost / benefit analysis for things. > > >> It's > > >> skewed a bit towards old drivers and old architectures (or platforms > > >> within > > >> those architectures), but it's likely a useful snowman to work > > >> towards > > >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > > > > > THANK YOU!!! > > > > > >> This doesn't get into the process at all of who to have the > > >> conversation > > >> with, what steps you go through to ensure that there's a transition > > >> plan > > >> for current users (if there's enough to warrant it), etc. It's just = a > > >> set > > >> of things I've found useful to think about and that I think the > > >> project > > >> should adopt (with refinement) as a standard template to use when > > >> making > > >> these calls. > > > > > > Can you also draft a short proposal on the "process" of deprecation? > > > Based I guess on our current model, with the addition of some of the > > > macros and other stuff you and Brooks worked on, the gone_in stuff > > > is what I am thinking. How to do the head commit with the deprecatio= n > > > notices, merge that back if applicable, then do the remove when > > > appropriate. Basically a more complete flushed out version of: > > > > > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#r= ules > > > @ 17.4. We should also IMHO do some work smithing and rearrangement > > > to > > > make this read much more as steps, some of the steps as listed have > > > substeps that appear to be overlooked often. > > > > > > Something like this: > > > 17.4. Deprecating Features > > > > > > When it is necessary to remove functionality from software in > > > the base system, follow these guidelines whenever possible: > > > > > > 1. Use of the deprecated feature generates a warning. > > > 2. Mention is made in the manual page and the release > > > notes that the option, utility, or interface is deprecated. > > > (I removed the word possible here, we should always > > > mention deprecation of features in the release notes) > > > 3. The option, utility, or interface is preserved until > > > the next major (point zero) release. > > > > Given the age of some of the things in our tree, of which timed was a > > classic example, I hardly think that this rule will work in our favor. > > Removing old code reduces our attack surface, and keeping something > > that's been dead for years, for another 2 years, seems problematic at > > the very least. Some of the software now on the proposed removal list > > should have been gone by 11 or 12. Not giving the users proper and adaquate notification is asking for problems as well. In the case of amd(8) at least the man page has had a obsolete notice in it with a pointer to autofs for some time (my 11.1 systems have such notice, not sure how far back that goes.) And again, age is not the correct metric, BSD is near 40 years old, I think the word you want is obsolete, which is more correct. Also timed appears to be in use, so what might be dead to you=20 is useful to someone else. I would also argue that the attack surface of timed is much smaller than the attack surface of ntpd, shall we remove ntpd to reduce our attack surface? I can not recall any cve against timed, I can recall many against ntpd. > > >=20 > If it's old, we should remove it. The one major release thing is nice to > have in the steady state where you are caught up and retire things just i= n > time. For the backlog we have, though, it will just get in the way. But i= n > this case all we need to do is a direct commit to fix the man page in 12 = to > say it is gone in 13.... Yes, we can short circuit the process, but we should not just skip the process. Need to fix both the man page and the binary to output a message when it is invoked, and that needs to be commited to both stable/11 and stable/12. The prefered method would of been to do the notification stuff in head, then merge that back to stable/11 and /12, then do the remove in head. --=20 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 Mon Dec 17 17:33:13 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8E661346F69 for ; Mon, 17 Dec 2018 17:33:13 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 370EF8172E for ; Mon, 17 Dec 2018 17:33:13 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id ED5071346F68; Mon, 17 Dec 2018 17:33:12 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7DCC1346F67 for ; Mon, 17 Dec 2018 17:33:12 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E27768172C for ; Mon, 17 Dec 2018 17:33:10 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C0CB.dip0.t-ipconnect.de [46.82.192.203]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id wBHGMsdK099671 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Dec 2018 16:23:03 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id wBHGMoEs035399 for ; Mon, 17 Dec 2018 17:22:50 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id wBHGMbb6000716 for ; Mon, 17 Dec 2018 17:22:50 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201812171622.wBHGMbb6000716@fire.js.berklix.net> to: arch@freebsd.org Subject: Re: A proposal for code removal prior to FreeBSD 13 From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Aachen Kent User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Sun, 16 Dec 2018 08:45:07 -0800." <201812161645.wBGGj7qn092076@pdx.rh.CN85.dnsmgr.net> Date: Mon, 17 Dec 2018 17:22:37 +0100 X-Rspamd-Queue-Id: E27768172C X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.95 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.18)[0.181,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[berklix.com]; MX_GOOD(-0.01)[land.berklix.com,slim.berklix.com]; NEURAL_SPAM_LONG(0.93)[0.926,0]; NEURAL_SPAM_MEDIUM(0.87)[0.867,0]; R_SPF_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[203.192.82.46.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(0.08)[ipnet: 144.76.0.0/16(2.93), asn: 24940(-2.50), country: DE(-0.01)]; 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: Mon, 17 Dec 2018 17:33:14 -0000 "Rodney W. Grimes" wrote: > > Howdy, > > > > A few of us are working on a list of programs and other code that we'd > > like to remove before FreeBSD 13. If others with to collaborate on this > > removal, or discuss it, please do so here. > > > > The list is being maintained on the project WIki: > > https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > > I am going to ask that all parties who want to "deprecate" code > first work with imp@ (Warner) to formalize the policy and procedure > for doing such that was promised by "release 12.0", then start on > this activity of deciding what can and can not go. Good idea. > The ad hoc history of deprecation, especially without even > following our current model, is not helping the projects > image with users going "wtf, they took out foo???" Yes. > timed was removed outside of current procedure, and that should > be corrected ASAP, as one developer has already spoken up that > they are using it. Yes Warner wrote: > In this case, we can trivially extract timed into a port and we'd be done. If the demolisher won't write a port please revert it to src/ I followed https://wiki.freebsd.org/WhatsGoing/FreeBSD13 Timed links, i didnt find why removed or what should replace it to continue support of timed protocol. There'll be lots of old heregenous nets in the world, some behind firewalls, still using timed. "Poul-Henning Kamp" wrote: > (e) Has anybody ever run timed(8) on FreeBSD in the first place ? > (f) What was wrong with them ? My net first used timed for a Symmetric 375 "Half a Vax" designed by Bill J. UCB 4.2, with src/ , sys/ failed http://www.berklix.com/~jhs/symmetric/ timed is still useful behind a wall. Cheers, Julian -- Julian Stacey, Computer Consultant Sys.Eng. BSD Linux Unix, Munich Aachen Kent First referendum stole 700,000 votes from Brits in EU; 3,700,000 globaly. Lies criminal funded; jobs pound & markets down. 1.9M new voters 1.3M dead. Email your MP: "New referendum fast!" http://berklix.org/brexit/#mp From owner-freebsd-arch@freebsd.org Mon Dec 17 20:41:09 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C77F3134BE4B for ; Mon, 17 Dec 2018 20:41:09 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5906E8961A for ; Mon, 17 Dec 2018 20:41:09 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net ([IPv6:2001:470:e254:11:a9dd:d4d:d709:aa92]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id wBHKf1m5076211; Mon, 17 Dec 2018 15:41:08 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host [IPv6:2001:470:e254:11:a9dd:d4d:d709:aa92] claimed to be torb.pix.net To: freebsd-arch@freebsd.org References: Subject: Re: A proposal for code removal prior to FreeBSD 13 From: Kurt Lidl Message-ID: <0dc5af5a-750a-1d56-6383-a18c817d275f@pix.net> Date: Mon, 17 Dec 2018 15:41:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 17 Dec 2018 20:41:09 -0000 I would like to request that rarpd remain in the system, or if it must go, a port needs be made of the code. I have old hardware, that gets boots periodically to check exact system behaviour, that requires rarpd to netboot. This hardware has been at the basis of some surprising "prior art" type discoveries. So it's essential to me that FreeBSD still be able to act as its netbooting server and NFS server. Thanks. -Kurt From owner-freebsd-arch@freebsd.org Mon Dec 17 20:56:08 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD9C9134C270 for ; Mon, 17 Dec 2018 20:56:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E3F28A075 for ; Mon, 17 Dec 2018 20:56:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x836.google.com with SMTP id v11so15799094qtc.2 for ; Mon, 17 Dec 2018 12:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=Zj2fJFmYWs8R3zhPE018PDn4tr4uD4fm1lrQUQUCVtY=; b=ZUDeykYZsl3JVRYhixObP8ZTHFezT0B7WW8o3ZI0Pyl1bvpHkBtj4PVr6s3to1a4ZW S3MMPgZk/YjH0I5GvpZrMbV2LukC9S2aGJfR8s+Ru3r6E9jJxZsxpUxnoHZ1VIk/jqPb G1daFBnBXJG7TnapJqPCuCXUJMiEk10P2FYg1oCtxX/p5DVckrHwgMFkZWQa0tYNSLmc aI1Iio4iE0S3cQEQ5lq0FNLPepFuYqB7fUW8GdDQRkRJC5cVsu7+D+ud9vD3kOvBrt/O J6a/3wG7mE7Une7nyzsIImuHkSkIZ/faDwdDu6UGCIylEWYBy14LuiHHaT/pT6J5iuuf Ivng== 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:cc; bh=Zj2fJFmYWs8R3zhPE018PDn4tr4uD4fm1lrQUQUCVtY=; b=h/nD1tVU6gdLyu4t3tSVUknLLeKUnE+RtSoOMbYB1ACWudUQahYyzTAUaZwX+TCoZn udolh6U+jRv1uS/ls1A4mDAND4EnOdWwsEDelbyXhErvkExMwQ7YTWxol/vNHTSdR5sX XuPlvWji4IC9TSMy49EY7aF2cZwNcGKWjTJ/74ZqPMw342CnmbxOB9nBx2kDyFF9YJUh l7NQCgxQMOl5GiWgW5tI0pTyslTGySCKrNd7V30z5tTCpK0g6YYbQcyeqlAfrJjA/TzY 57vBWAqnAyaypLdCJxQtRs3kM29mrRBxlJ+EG2TG6uIPAMQ4Zyh+HVbwnrx2PDmUBWPX uBMQ== X-Gm-Message-State: AA+aEWYglVzi9NOg7hF+hNUfVm/26kV+tACmx7bzAHW/T8pA5xW2gLOH MQe5ov3jZNg5xF4o4P3JJr+sKNTmiA6wPwNxiLGV9vJBsnE= X-Google-Smtp-Source: AFSGD/UFpjkzTvK5co7QiZ1xASXMQkRwmJLJ64k1XJs0tZTp5QTqH0a63QDg2LlOGXiux16TJhuB4ARi+DVNd6uq8t8= X-Received: by 2002:ac8:3f2d:: with SMTP id c42mr14966690qtk.33.1545080166248; Mon, 17 Dec 2018 12:56:06 -0800 (PST) MIME-Version: 1.0 References: <20181217022242.C88143C69@spqr.komquats.com> In-Reply-To: <20181217022242.C88143C69@spqr.komquats.com> From: Warner Losh Date: Mon, 17 Dec 2018 13:55:55 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 1E3F28A075 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ZUDeykYZ X-Spamd-Result: default: False [-2.97 / 15.00]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MISSING_TO(2.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.979,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.966,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_SHORT(-0.76)[-0.760,0]; IP_SCORE(-2.25)[ip: (-8.13), ipnet: 2607:f8b0::/32(-1.69), asn: 15169(-1.36), country: US(-0.08)]; RCVD_IN_DNSWL_NONE(0.00)[6.3.8.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]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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, 17 Dec 2018 20:56:08 -0000 On Sun, Dec 16, 2018 at 7:23 PM Cy Schubert wrote: > Picking a random email to reply to, the process should also include > determination whether to migrate the software /feature to ports is required. > For those interested, I've created a timed repo. At least the program. It doesn't have the docs or rc files associated with it yet. I've also created a blogspot entry for how to do this. It's a bit tedious, but doable. https://bsdimp.blogspot.com/2018/12/splitting-up-git-repo-single-directory.html I'll noodle around with how to do the other bits to preserve history and write part 2 of this blog :). I've uploaded this to http://github.com/bsdimp/timed. Warner From owner-freebsd-arch@freebsd.org Mon Dec 17 21:15:13 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36E44134C988 for ; Mon, 17 Dec 2018 21:15:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC488B02D for ; Mon, 17 Dec 2018 21:15:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 39D2E134C985; Mon, 17 Dec 2018 21:15:12 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06167134C984 for ; Mon, 17 Dec 2018 21:15:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9533C8B02A for ; Mon, 17 Dec 2018 21:15:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x835.google.com with SMTP id k12so15807936qtf.7 for ; Mon, 17 Dec 2018 13:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oJeIvsbThWVrljC7xhRCRzwH4JtiFxPJwY4oXu3CWV4=; b=R8gEmpdbtMy6jyp38RzPw/rWsg8yxK++JuZLF4nPyi0tm7lxazTNitVXKDub7TSVI+ HJW9XAsnua+HcbwhE/zRf04ZDZ4AMCu3ygjp8fzbQhcN1eMqy52AI8g97PvdrzF7roo1 e3+2BpfZnmSPObIhcXD8ocPhW+HDyvhAEv3s0zpAPraV8n5YSLsL8PYUdDzF59sVVO6k OMNs4XHz8MD/8XuO/Sf9Kh4uGowzGXywCo2vwZ1RE8aC4Q4f0WlRgIbzMfFjc5/eZuSH eCqJx0bzZB51ZAlz3Un/N/HHl/GrgaD4rfRGqqzlQxlntjujqi65X1iWKEicYQyfC7nz ARNA== 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=oJeIvsbThWVrljC7xhRCRzwH4JtiFxPJwY4oXu3CWV4=; b=LU1fHa7x/RYa2ddhqM6ttODFaZmqzIYXJcLz+RkCnBIUEGGb0jLDng6cNMSJIo+9ld ul9p1Z47CYujzlrhDSFBkckXAmWTaPTTJXyT68JnkFx4Vm300PIRQtbN1d+tlJdiOXo9 tMH85ajhmOB3KIuVIb+5wI+RyjYDYCjcVdMu1sE42yURT6hacotVcvfv+HN7Jrbz/CaQ 7UY32znw1ancxbPT9Ym0HDVGYpBcJb+crg8f6kNas2strPU64Sh5izAq9SXu57l0R0hN jrf4M3w87e2XcM9LyjYfS8Vk/j6Z4H5ONswWOjrZCYkm1++mHgITmTTpOq0/Uz6j3F7C pGxg== X-Gm-Message-State: AA+aEWY4rUqitNXmxWgY1Ii4n1hT6+yMrLSZG1Xua0kTq+kVx2RuQjvi oh54Vt3/FLj+qShX+3ljRwhyK7FscQeDny8gNLgRmg== X-Google-Smtp-Source: AFSGD/WiqGzP4w3J9giPh9sEjDrGpc/OIf/lKHL4zakyyzmPFmszsg5MzTDCF8O7Nbw9JPXxuauQgKNP9pW2u1/W0YI= X-Received: by 2002:a05:6214:1087:: with SMTP id o7mr14860744qvr.115.1545081310946; Mon, 17 Dec 2018 13:15:10 -0800 (PST) MIME-Version: 1.0 References: <201812170722.wBH7MRhO094818@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201812170722.wBH7MRhO094818@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Mon, 17 Dec 2018 14:15:00 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: "Rodney W. Grimes" Cc: George Neville-Neil , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 9533C8B02A X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; REPLY(-4.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: Mon, 17 Dec 2018 21:15:13 -0000 On Mon, Dec 17, 2018 at 12:22 AM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil > wrote: > > > > > > > > > > > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: > > > > > > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > > > >> > > > >> wrote: > > > >> > > > >>> Howdy, > > > >>> > > > >>> A few of us are working on a list of programs and other code that > > > >>> we'd > > > >>> like to remove before FreeBSD 13. If others with to collaborate on > > > >>> this > > > >>> removal, or discuss it, please do so here. > > > >>> > > > >>> The list is being maintained on the project WIki: > > > >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > > > >> > > > >> > > > >> I'm in the process of writing some of the criteria I've been using > to > > > >> drive > > > >> discussions. I've promised a formal policy for a long time, but > > > >> that's > > > >> turning out to be harder than I thought to write and have just > > > >> documented > > > >> the criteria I look at to do the cost / benefit analysis for things. > > > >> It's > > > >> skewed a bit towards old drivers and old architectures (or platforms > > > >> within > > > >> those architectures), but it's likely a useful snowman to work > > > >> towards > > > >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > > > > > > > THANK YOU!!! > > > > > > > >> This doesn't get into the process at all of who to have the > > > >> conversation > > > >> with, what steps you go through to ensure that there's a transition > > > >> plan > > > >> for current users (if there's enough to warrant it), etc. It's just > a > > > >> set > > > >> of things I've found useful to think about and that I think the > > > >> project > > > >> should adopt (with refinement) as a standard template to use when > > > >> making > > > >> these calls. > > > > > > > > Can you also draft a short proposal on the "process" of deprecation? > > > > Based I guess on our current model, with the addition of some of the > > > > macros and other stuff you and Brooks worked on, the gone_in stuff > > > > is what I am thinking. How to do the head commit with the > deprecation > > > > notices, merge that back if applicable, then do the remove when > > > > appropriate. Basically a more complete flushed out version of: > > > > > > > > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules > > > > @ 17.4. We should also IMHO do some work smithing and rearrangement > > > > to > > > > make this read much more as steps, some of the steps as listed have > > > > substeps that appear to be overlooked often. > > > > > > > > Something like this: > > > > 17.4. Deprecating Features > > > > > > > > When it is necessary to remove functionality from software in > > > > the base system, follow these guidelines whenever possible: > > > > > > > > 1. Use of the deprecated feature generates a warning. > > > > 2. Mention is made in the manual page and the release > > > > notes that the option, utility, or interface is deprecated. > > > > (I removed the word possible here, we should always > > > > mention deprecation of features in the release notes) > > > > 3. The option, utility, or interface is preserved until > > > > the next major (point zero) release. > > > > > > Given the age of some of the things in our tree, of which timed was a > > > classic example, I hardly think that this rule will work in our favor. > > > Removing old code reduces our attack surface, and keeping something > > > that's been dead for years, for another 2 years, seems problematic at > > > the very least. Some of the software now on the proposed removal list > > > should have been gone by 11 or 12. > > Not giving the users proper and adaquate notification is asking > for problems as well. > > In the case of amd(8) at least the man page has had a obsolete > notice in it with a pointer to autofs for some time (my 11.1 > systems have such notice, not sure how far back that goes.) > > And again, age is not the correct metric, BSD is near 40 years > old, I think the word you want is obsolete, which is more correct. > Also timed appears to be in use, so what might be dead to you > is useful to someone else. > You can't say it's in use, other than one person saying they have it up and running. That's not data, but an anecdote. We have no data to show one way or another. However, given how little it's changed in the last 25 years since it was imported to the tree, it's not unreasonable to conclude that it's not in active use. Couple with that the significant technical issues with the method of timekeeping its trying to do, and it's easy to see why people wouldn't want to use it. > I would also argue that the attack surface of timed is much > smaller than the attack surface of ntpd, shall we remove ntpd > to reduce our attack surface? I can not recall any cve against > timed, I can recall many against ntpd. > ntpd is useful. timed, not so much. ntpd is widely deployed, timed not so much. ntpd is actively maintained, timed hasn't changed in 30 years in any meaningful way. Etc. On all these factors, timed should go. The rest doesn't matter. So few people use timed that it's not worth having in the tree. It's age is but one factor as is lack of meaningful maintenance, but it too militates against. In fact, all the commits after its import have been make-work for the most part. This is a poster child for why software in the tree needlessly creates friction: At least 5 different people had to spend time on this bit of code making sure it was up to whatever tree-wide thing they were doing. Individually, this isn't so bad, but with enough of these it becomes a real problem. So it's not just any one of these factors, before you try to argue one point I might have overstated. It's that the cost of having it in the tree, all things considered, outweighs the benefit it gives to the project when viewed as a whole over all these factors. There's a general consensus that's true, with a tiny number of people holding a contrary view. That qualifies as "rough consensus" in my book. that was the old standard before we filibustered things to death with the mistaken notion that even on decenter is enough to keep something around. It's time to come up with some clear guidelines that embody the "rough consensus" standard of old, while recognizing that with a larger audience of stakeholders we'll see more of the 'long tail' than we ever did when the group was smaller (the law of large numbers tells us to expect this). We've not made that transition, and we need to do so. We have to find some useful way to talk about retirement of features, architectures, platforms, etc because we don't have enough manpower to maintain everything that ever entered the tree forever. We have to make sure that the burden things place on other developers are, on the whole, out weighted by the benefit to the project. Since both of these factors lack hard data to back-up assertions, we must instead substitute our collective wisdom. There will be differences of opinion as to the cost and worth of things, but the average of those opinions generally have been shown to be good so long as the sample size is large and diverse enough. > > If it's old, we should remove it. The one major release thing is nice to > > have in the steady state where you are caught up and retire things just > in > > time. For the backlog we have, though, it will just get in the way. But > in > > this case all we need to do is a direct commit to fix the man page in 12 > to > > say it is gone in 13.... > > Yes, we can short circuit the process, but we should not just skip > the process. Need to fix both the man page and the binary to output > a message when it is invoked, and that needs to be commited to both > stable/11 and stable/12. > It's a daemon. We should not have it blast random bits. There's no need for it and the bits would get lost anyway. Also, changes to the could break things in unanticipated ways if they can't be meaningfully tested. A direct commit to the man page is all we need do here. > The prefered method would of been to do the notification stuff in > head, then merge that back to stable/11 and /12, then do the remove > in head. > True, but that wasn't done here. Warner From owner-freebsd-arch@freebsd.org Tue Dec 18 01:09:49 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C23E13509B4 for ; Tue, 18 Dec 2018 01:09:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CFB446B111 for ; Tue, 18 Dec 2018 01:09:48 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 935E613509A9; Tue, 18 Dec 2018 01:09:48 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5571013509A7 for ; Tue, 18 Dec 2018 01:09:48 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.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 6DE946B105 for ; Tue, 18 Dec 2018 01:09:47 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id wBI19gFb098409; Mon, 17 Dec 2018 17:09:42 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id wBI19eaK098408; Mon, 17 Dec 2018 17:09:40 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201812180109.wBI19eaK098408@pdx.rh.CN85.dnsmgr.net> Subject: Re: A proposal for code removal prior to FreeBSD 13 In-Reply-To: To: Warner Losh Date: Mon, 17 Dec 2018 17:09:40 -0800 (PST) CC: George Neville-Neil , "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: 6DE946B105 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.998,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: Tue, 18 Dec 2018 01:09:49 -0000 > On Mon, Dec 17, 2018 at 12:22 AM Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil > > wrote: > > > > > > > > > > > > > > > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: > > > > > > > > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > > > > >> > > > > >> wrote: > > > > >> > > > > >>> Howdy, > > > > >>> > > > > >>> A few of us are working on a list of programs and other code that > > > > >>> we'd > > > > >>> like to remove before FreeBSD 13. If others with to collaborate on > > > > >>> this > > > > >>> removal, or discuss it, please do so here. > > > > >>> > > > > >>> The list is being maintained on the project WIki: > > > > >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > > > > >> > > > > >> > > > > >> I'm in the process of writing some of the criteria I've been using > > to > > > > >> drive > > > > >> discussions. I've promised a formal policy for a long time, but > > > > >> that's > > > > >> turning out to be harder than I thought to write and have just > > > > >> documented > > > > >> the criteria I look at to do the cost / benefit analysis for things. > > > > >> It's > > > > >> skewed a bit towards old drivers and old architectures (or platforms > > > > >> within > > > > >> those architectures), but it's likely a useful snowman to work > > > > >> towards > > > > >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > > > > > > > > > THANK YOU!!! > > > > > > > > > >> This doesn't get into the process at all of who to have the > > > > >> conversation > > > > >> with, what steps you go through to ensure that there's a transition > > > > >> plan > > > > >> for current users (if there's enough to warrant it), etc. It's just > > a > > > > >> set > > > > >> of things I've found useful to think about and that I think the > > > > >> project > > > > >> should adopt (with refinement) as a standard template to use when > > > > >> making > > > > >> these calls. > > > > > > > > > > Can you also draft a short proposal on the "process" of deprecation? > > > > > Based I guess on our current model, with the addition of some of the > > > > > macros and other stuff you and Brooks worked on, the gone_in stuff > > > > > is what I am thinking. How to do the head commit with the > > deprecation > > > > > notices, merge that back if applicable, then do the remove when > > > > > appropriate. Basically a more complete flushed out version of: > > > > > > > > > > > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules > > > > > @ 17.4. We should also IMHO do some work smithing and rearrangement > > > > > to > > > > > make this read much more as steps, some of the steps as listed have > > > > > substeps that appear to be overlooked often. > > > > > > > > > > Something like this: > > > > > 17.4. Deprecating Features > > > > > > > > > > When it is necessary to remove functionality from software in > > > > > the base system, follow these guidelines whenever possible: > > > > > > > > > > 1. Use of the deprecated feature generates a warning. > > > > > 2. Mention is made in the manual page and the release > > > > > notes that the option, utility, or interface is deprecated. > > > > > (I removed the word possible here, we should always > > > > > mention deprecation of features in the release notes) > > > > > 3. The option, utility, or interface is preserved until > > > > > the next major (point zero) release. > > > > > > > > Given the age of some of the things in our tree, of which timed was a > > > > classic example, I hardly think that this rule will work in our favor. > > > > Removing old code reduces our attack surface, and keeping something > > > > that's been dead for years, for another 2 years, seems problematic at > > > > the very least. Some of the software now on the proposed removal list > > > > should have been gone by 11 or 12. > > > > Not giving the users proper and adaquate notification is asking > > for problems as well. > > > > In the case of amd(8) at least the man page has had a obsolete > > notice in it with a pointer to autofs for some time (my 11.1 > > systems have such notice, not sure how far back that goes.) > > > > And again, age is not the correct metric, BSD is near 40 years > > old, I think the word you want is obsolete, which is more correct. > > Also timed appears to be in use, so what might be dead to you > > is useful to someone else. > > > > You can't say it's in use, other than one person saying they have it up and > running. That's not data, but an anecdote. We have no data to show one way > or another. I didn't say it was in use, I said "Age is not the correct metric". In use or not in use would be a correct metric. > However, given how little it's changed in the last 25 years > since it was imported to the tree, it's not unreasonable to conclude that > it's not in active use. Change is probably a marginal metric, things that work well tend to just keep working, without fuss or change. timed works, works very well, and has no reason to be mucked with, so I would not expect any change to that code. Your drawing, IMHO, very bad conclusions from a poor metic. > Couple with that the significant technical issues > with the method of timekeeping its trying to do, and it's easy to see why > people wouldn't want to use it. > > > > I would also argue that the attack surface of timed is much > > smaller than the attack surface of ntpd, shall we remove ntpd > > to reduce our attack surface? I can not recall any cve against > > timed, I can recall many against ntpd. > > > > ntpd is useful. timed, not so much. ntpd is widely deployed, timed not so > much. ntpd is actively maintained, timed hasn't changed in 30 years in any > meaningful way. Etc. On all these factors, timed should go. Your "not so much" is very subjective. ntpd may or maynot be actively maintained as pointed out by others. Change != used, unchanged != unused, please stop drawing conclusions that are marginal at best. > > The rest doesn't matter. So few people use timed that it's not worth having > in the tree. It's age is but one factor as is lack of meaningful FFS, age is a totally incorrect metric, if you cant see that then maybe you should realized that much of our code is VERY old and has ages beyond timed, should we axe it? Age has 0 bearing on usefull, used, etc. > maintenance, but it too militates against. In fact, all the commits after > its import have been make-work for the most part. This is a poster child > for why software in the tree needlessly creates friction: At least 5 > different people had to spend time on this bit of code making sure it was > up to whatever tree-wide thing they were doing. Individually, this isn't so > bad, but with enough of these it becomes a real problem. > > So it's not just any one of these factors, before you try to argue one > point I might have overstated. It's that the cost of having it in the tree, > all things considered, outweighs the benefit it gives to the project when > viewed as a whole over all these factors. There's a general consensus > that's true, with a tiny number of people holding a contrary view. That > qualifies as "rough consensus" in my book. that was the old standard before > we filibustered things to death with the mistaken notion that even on > decenter is enough to keep something around. It's time to come up with some > clear guidelines that embody the "rough consensus" standard of old, while > recognizing that with a larger audience of stakeholders we'll see more of > the 'long tail' than we ever did when the group was smaller (the law of > large numbers tells us to expect this). We've not made that transition, and > we need to do so. We have to find some useful way to talk about retirement > of features, architectures, platforms, etc because we don't have enough > manpower to maintain everything that ever entered the tree forever. We have > to make sure that the burden things place on other developers are, on the > whole, out weighted by the benefit to the project. Since both of these > factors lack hard data to back-up assertions, we must instead substitute > our collective wisdom. There will be differences of opinion as to the cost > and worth of things, but the average of those opinions generally have been > shown to be good so long as the sample size is large and diverse enough. I did not object to it going, you do not have to make a case for that, BUT I do object to the "reason" being "it is old", that is an incorrect reason. The reasons are more correctly: 1) It is only used by a small group of people (we should define what the size of that group is that makes things deprecatable.) The non existant data we have that leads us to think it is ok to remove timed may be wrong, and the 17.4 commiters procedure is designed to help catch that. 2) It has a reasonable replacement in ntpd 3) It has a small, but perhaps measurable maintance cost. (Though this well now be born by who ever if anyone bothers to maintain your git version) > > > > If it's old, we should remove it. The one major release thing is nice to > > > have in the steady state where you are caught up and retire things just > > in > > > time. For the backlog we have, though, it will just get in the way. But > > in > > > this case all we need to do is a direct commit to fix the man page in 12 > > to > > > say it is gone in 13.... > > > > Yes, we can short circuit the process, but we should not just skip > > the process. Need to fix both the man page and the binary to output > > a message when it is invoked, and that needs to be commited to both > > stable/11 and stable/12. > > > > It's a daemon. We should not have it blast random bits. There's no need for > it and the bits would get lost anyway. Also, changes to the could break > things in unanticipated ways if they can't be meaningfully tested. It is not only a daemon, it has an interactive command component called timedc, and even then we *must* address this daemon issue for deprecating. To rely on a note in a man page is not a good plan. Daemons often can and do spit out startup messages, these are not "blasting random bits" and your hyperbola is not helping you make a good case. And if our skill levels are so low we can not add a startup message to timed and a message to timedc I hate to think of the state of the more complex code. > > A direct commit to the man page is all we need do here. We disagree, and stated procedure bears weight to my side. > > > The prefered method would of been to do the notification stuff in > > head, then merge that back to stable/11 and /12, then do the remove > > in head. > > > > True, but that wasn't done here. Sadly true. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Tue Dec 18 04:50:44 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A92DC133FF93 for ; Tue, 18 Dec 2018 04:50:44 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 38E6277678 for ; Tue, 18 Dec 2018 04:50:44 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E83AC133FF92; Tue, 18 Dec 2018 04:50:43 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3E49133FF91 for ; Tue, 18 Dec 2018 04:50:43 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 37DCD77671 for ; Tue, 18 Dec 2018 04:50:43 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1545108634; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=DEtjJTignFRIvdGJFDvkBriapBCd4smNsATr84/RZrQYfV4OgH3r0NSIPrESnowxfLK98zTppEnm6 /Jui2TX65KGe/jx+iIJ5jRJZF9Ry3urLey3ikNbyR2hJLTefNIiI0KKOwzp3JWW4kH+L1DX4/tWErv 3eeeOpjOkc6VTiwybNsHrvT5MWbsVJL+/Wu8+dHhypjl1VXze/rdaue/ng26VeKilO+EFRYoa2qau+ TpE59+HgwDe+L3lIm3XEbVMpxAnssdPQqyoeXeDhsgEEcWSKB1aPx2GwwKYX20OClY7Awj9RB/DuxG MEcIt+64SUMklex1oYJj9QBo/1sYR0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=qsRpcHqH8e0yF8GFXNvEVqMft9wHisPqLXXu7+IjdAo=; b=gaMH5AeYnR2UKF5ARXPvlcOo8uMxKKGv6pmgVsjO8vdDUjbUMT+ReRCE7QiiYgMWG6qAI3YTt/1wo W834jG+oCa1O2qZnJIY5L6a45hYpV9vY28JSeRtuqQox8XlKGD18YDtEd81MhaIH3rEUGJWAe51xy+ a0QM7atGlgRPNnCGBB3AtGY3YLHkD0OtNKV0gfVLVt1ozJh9I+uUi6ntwVyvYc/bDuccP0zQFos8ET V2ehRduzkR8bw7Sq3vbPefBRb2g7Ecy4+5r2ZnZYo/Qbe1ZsoMm2Uk4hJjs6s5To4O7tOCONzWfHVN pWOyr8GJIA99ZIDA7XcHeQryfGZx7Yg== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=qsRpcHqH8e0yF8GFXNvEVqMft9wHisPqLXXu7+IjdAo=; b=MqlbpG9h3e3no+SCrUSkh+sde5Y8KQoJLkxd+A5VPvFyGdUDlM3j/AOal252clFcAWAF8CrngGdlu ENs7v1Q+8UCGjQ5GXkdDCWXUQ1hYUTl/u0paBN9Cda1jwb/mOM6V/8biqQtO3luJXfFZNO66HT2OpC KKgn4jscJaUm/Seh4iF0FMlUVEKJ1vF9qgv2SSmrpHP92JAukoUAPzPa18Bhk6w0vA0yYcewIgFEAH ffOYJOVZDSw5sGGTsVHZxwKo6MGvDVJEkjWxqBw2lt6DreWlGETdjlCCulzL8Ggy91Tv80Uv2IYbzk CVUYcjq5b1JtPDTcNXSy1lAyjkWMGlA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 71844b59-0280-11e9-a887-bd2f23b465e5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 71844b59-0280-11e9-a887-bd2f23b465e5; Tue, 18 Dec 2018 04:50:32 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBI4oTiZ092765; Mon, 17 Dec 2018 21:50:29 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1545108629.76088.116.camel@freebsd.org> Subject: Re: A proposal for code removal prior to FreeBSD 13 From: Ian Lepore To: "Rodney W. Grimes" , Warner Losh Cc: "freebsd-arch@freebsd.org" , George Neville-Neil Date: Mon, 17 Dec 2018 21:50:29 -0700 In-Reply-To: <201812180109.wBI19eaK098408@pdx.rh.CN85.dnsmgr.net> References: <201812180109.wBI19eaK098408@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 37DCD77671 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.970,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: Tue, 18 Dec 2018 04:50:45 -0000 On Mon, 2018-12-17 at 17:09 -0800, Rodney W. Grimes wrote: > > > > ntpd is useful. timed, not so much. ntpd is widely deployed, timed not so > > much. ntpd is actively maintained, timed hasn't changed in 30 years in any > > meaningful way. Etc. On all these factors, timed should go. > > Your "not so much" is very subjective. > ntpd may or maynot be actively maintained as pointed out by others. > Change != used, unchanged != unused, please stop drawing conclusions > that are marginal at best. Can we please stop this ridiculous fiction that ntpd is not maintained before people in other parts of the internet start pointing at us and laughing at what a bunch of uninformed rubes we are? The ntpd developers have, in the past six months, accepted and then released an enhancement that originated right here in freebsd. Just two days ago they accepted a patch from me for a small bugfix. Ntpd is very much actively maintained. -- Ian From owner-freebsd-arch@freebsd.org Tue Dec 18 16:01:14 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4429713356B7 for ; Tue, 18 Dec 2018 16:01:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 72227733A4 for ; Tue, 18 Dec 2018 16:01:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 350A413356B2; Tue, 18 Dec 2018 16:01:12 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF2EB13356B1 for ; Tue, 18 Dec 2018 16:01:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7615A733A2 for ; Tue, 18 Dec 2018 16:01:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72a.google.com with SMTP id g125so9545878qke.4 for ; Tue, 18 Dec 2018 08:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5mLN8/sMCNeZpMJU1gldtVdXzOs8JhvuwAhj5sYSDT8=; b=CCwpSoebrxD1gYnBVDHa4iR2bLlVVkW99hfgMnv/AcC93VVc4ppy724ES3jZqQiDIZ bqM8KIFPQHOYp41dKEaepKuehCfWcb2+dkCYOfWmlLO8k5iwmhXPu6QBPHuiOZpOMf6K pjfBWU1yC5h61Q8NTu0eIcVEFDk8Kmex0ebvq9PSEPpc89MtGrOXbT+ciINU239FXi4D +EGo/rAoNtX917OSFvCmi6ciFodNTjyZ5+OafUAOXtAElm48Wusg1j8G/xrdw8MRownM H2a7QCExJu9vdPsWv1eUyiweBqm64Y6bWJGHe95B0t5ApEDEOYt9l1xznlNU+d/EGlwL c0mQ== 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=5mLN8/sMCNeZpMJU1gldtVdXzOs8JhvuwAhj5sYSDT8=; b=iXis5hO4v2l7oLSLtEHklgm14wtajGASnQxfUyGpIC7NgOcakI++jbSmzAvdEnLB0M wH53pBZDWxgBBEMOIynKTXZcqYz6/IdHoXItZczj8M9KvR3yTIJjtUFu50MmiS09aIBF PVsqpuMYxnbEd42d9Oq/7KooETu9pZRVx2d4k4nVGqkmXoEXDD7HDw2G17XziURnSIwj QWbQUvu8mXNcd5Lz3p6NuZ3yFvBZUhCcoYuZxP3Mlgm5BxYAa4bAyE1OUn6NYpHdWcT0 EzhLzXVFBY1L30kHTQRFVVYwAm/w03ZKQedNMsOpr2krgSulDw38wo3Ypps+dun6EcTO cunw== X-Gm-Message-State: AA+aEWZ6ePNiL6B5rP7NYRIYrPz1urIY4ShizcxOQIpsFSCQJeEz7zq5 s/Ng6HwhFY4qUCsdIedYQ/lI1as33MAX2MqrOVZK54Fh X-Google-Smtp-Source: AFSGD/VwYS5igTvrZijRqfQa8Ck4G71zIWqfNs5HmnP03IpAfs0PVLjOCkrg8qAe393SjjUXda1JozVmGaMM9kEnyCg= X-Received: by 2002:a37:6c05:: with SMTP id h5mr16799591qkc.175.1545148870761; Tue, 18 Dec 2018 08:01:10 -0800 (PST) MIME-Version: 1.0 References: <201812180109.wBI19eaK098408@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201812180109.wBI19eaK098408@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 18 Dec 2018 09:00:57 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: "Rodney W. Grimes" Cc: George Neville-Neil , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 7615A733A2 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.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: Tue, 18 Dec 2018 16:01:14 -0000 On Mon, Dec 17, 2018 at 6:09 PM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Mon, Dec 17, 2018 at 12:22 AM Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil < > gnn@neville-neil.com > > > > wrote: > > > > > > > > > > > > > > > > > > > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: > > > > > > > > > > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil > > > > > >> > > > > > >> wrote: > > > > > >> > > > > > >>> Howdy, > > > > > >>> > > > > > >>> A few of us are working on a list of programs and other code > that > > > > > >>> we'd > > > > > >>> like to remove before FreeBSD 13. If others with to > collaborate on > > > > > >>> this > > > > > >>> removal, or discuss it, please do so here. > > > > > >>> > > > > > >>> The list is being maintained on the project WIki: > > > > > >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 > > > > > >> > > > > > >> > > > > > >> I'm in the process of writing some of the criteria I've been > using > > > to > > > > > >> drive > > > > > >> discussions. I've promised a formal policy for a long time, but > > > > > >> that's > > > > > >> turning out to be harder than I thought to write and have just > > > > > >> documented > > > > > >> the criteria I look at to do the cost / benefit analysis for > things. > > > > > >> It's > > > > > >> skewed a bit towards old drivers and old architectures (or > platforms > > > > > >> within > > > > > >> those architectures), but it's likely a useful snowman to work > > > > > >> towards > > > > > >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > > > > > > > > > > > THANK YOU!!! > > > > > > > > > > > >> This doesn't get into the process at all of who to have the > > > > > >> conversation > > > > > >> with, what steps you go through to ensure that there's a > transition > > > > > >> plan > > > > > >> for current users (if there's enough to warrant it), etc. It's > just > > > a > > > > > >> set > > > > > >> of things I've found useful to think about and that I think the > > > > > >> project > > > > > >> should adopt (with refinement) as a standard template to use > when > > > > > >> making > > > > > >> these calls. > > > > > > > > > > > > Can you also draft a short proposal on the "process" of > deprecation? > > > > > > Based I guess on our current model, with the addition of some of > the > > > > > > macros and other stuff you and Brooks worked on, the gone_in > stuff > > > > > > is what I am thinking. How to do the head commit with the > > > deprecation > > > > > > notices, merge that back if applicable, then do the remove when > > > > > > appropriate. Basically a more complete flushed out version of: > > > > > > > > > > > > > > > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules > > > > > > @ 17.4. We should also IMHO do some work smithing and > rearrangement > > > > > > to > > > > > > make this read much more as steps, some of the steps as listed > have > > > > > > substeps that appear to be overlooked often. > > > > > > > > > > > > Something like this: > > > > > > 17.4. Deprecating Features > > > > > > > > > > > > When it is necessary to remove functionality from software in > > > > > > the base system, follow these guidelines whenever possible: > > > > > > > > > > > > 1. Use of the deprecated feature generates a warning. > > > > > > 2. Mention is made in the manual page and the release > > > > > > notes that the option, utility, or interface is > deprecated. > > > > > > (I removed the word possible here, we should always > > > > > > mention deprecation of features in the release notes) > > > > > > 3. The option, utility, or interface is preserved until > > > > > > the next major (point zero) release. > > > > > > > > > > Given the age of some of the things in our tree, of which timed > was a > > > > > classic example, I hardly think that this rule will work in our > favor. > > > > > Removing old code reduces our attack surface, and keeping something > > > > > that's been dead for years, for another 2 years, seems problematic > at > > > > > the very least. Some of the software now on the proposed removal > list > > > > > should have been gone by 11 or 12. > > > > > > Not giving the users proper and adaquate notification is asking > > > for problems as well. > > > > > > In the case of amd(8) at least the man page has had a obsolete > > > notice in it with a pointer to autofs for some time (my 11.1 > > > systems have such notice, not sure how far back that goes.) > > > > > > And again, age is not the correct metric, BSD is near 40 years > > > old, I think the word you want is obsolete, which is more correct. > > > Also timed appears to be in use, so what might be dead to you > > > is useful to someone else. > > > > > > > You can't say it's in use, other than one person saying they have it up > and > > running. That's not data, but an anecdote. We have no data to show one > way > > or another. > > I didn't say it was in use, I said "Age is not the correct metric". > In use or not in use would be a correct metric. > There is no single metric. This code is old. Old code has more security issues than new. That's a small factor towards removal. > > However, given how little it's changed in the last 25 years > > since it was imported to the tree, it's not unreasonable to conclude that > > it's not in active use. > > Change is probably a marginal metric, things that work well > tend to just keep working, without fuss or change. > timed works, works very well, and has no reason to be > mucked with, so I would not expect any change to that > code. Your drawing, IMHO, very bad conclusions from > a poor metic. > Change rate is important. There have been no new features added to timed in 30 years. However, the state of the art in time keeping has advanced significantly since then. The only changes here have been churn: marking licenses, converting from K&R, minor tweaks to appease Coverity, moving files around. That's code that's not living, breathing code. Did anybody use newer research to get better synchronization? Has anybody added frequency estimates to improve accuracy? Has anybody looked at ways for the networks of people using timed to be self-organizing? Nope on all these. Look at UFS. It's of similar age, and has had much work done on it since then. Heck, even cat, cp, dd, and other utilities we've had around since V7 have all seen significant work done and continue to see new features as the needs arise. > > Couple with that the significant technical issues > > with the method of timekeeping its trying to do, and it's easy to see why > > people wouldn't want to use it. > > > > > > > I would also argue that the attack surface of timed is much > > > smaller than the attack surface of ntpd, shall we remove ntpd > > > to reduce our attack surface? I can not recall any cve against > > > timed, I can recall many against ntpd. > > > > > > > ntpd is useful. timed, not so much. ntpd is widely deployed, timed not so > > much. ntpd is actively maintained, timed hasn't changed in 30 years in > any > > meaningful way. Etc. On all these factors, timed should go. > > Your "not so much" is very subjective. > ntpd may or maynot be actively maintained as pointed out by others. > Change != used, unchanged != unused, please stop drawing conclusions > that are marginal at best. > Nope. This is incorrect. NTP is absolutely actively maintained. The NTP working group has dozens of draft standard papers today (timed has had none in 30 years). The ntp code base has had dozens of commits in the last 6 months, and hundreds in the last few years that I could find. In contrast, there have been no real commits to timed since kris@ fixed the interoperability issues in 2001, and the next set of real commits were back in 1996 or 1997 depending on how you count them. Real programs that are used get changes. People find bugs. While this isn't conclusive evidence, it is suggestive. When you look at active software projects vs inactive ones, it's clear as day. > > > The rest doesn't matter. So few people use timed that it's not worth > having > > in the tree. It's age is but one factor as is lack of meaningful > > FFS, age is a totally incorrect metric, if you cant see that then > maybe you should realized that much of our code is VERY old and has > ages beyond timed, should we axe it? Age has 0 bearing on usefull, > used, etc. > Please don't yell at me. FFS? Really? you've already lost the argument. And you are trying to conflate two different issues. timed is not useful. Technically, it's a crappy solution. It uses only phase errors to adjust the clocks, but not frequency. It uses the median time of the ensemble, which is very sensitive to systemic frequency errors which can cause the whole ensemble to wander off into the weeds. It's statistical code is simplistic. These factors make it less than robust. The data is also unencrypted / unauthenticated, with no provision to change that. This makes it spoofable. It would take considerable effort to change these features. All of these problems with timed are a result of its age. While age isn't necessarily a problem, it's a useful factor to consider. > > maintenance, but it too militates against. In fact, all the commits after > > its import have been make-work for the most part. This is a poster child > > for why software in the tree needlessly creates friction: At least 5 > > different people had to spend time on this bit of code making sure it was > > up to whatever tree-wide thing they were doing. Individually, this isn't > so > > bad, but with enough of these it becomes a real problem. > > > > So it's not just any one of these factors, before you try to argue one > > point I might have overstated. It's that the cost of having it in the > tree, > > all things considered, outweighs the benefit it gives to the project when > > viewed as a whole over all these factors. There's a general consensus > > that's true, with a tiny number of people holding a contrary view. That > > qualifies as "rough consensus" in my book. that was the old standard > before > > we filibustered things to death with the mistaken notion that even on > > decenter is enough to keep something around. It's time to come up with > some > > clear guidelines that embody the "rough consensus" standard of old, while > > recognizing that with a larger audience of stakeholders we'll see more of > > the 'long tail' than we ever did when the group was smaller (the law of > > large numbers tells us to expect this). We've not made that transition, > and > > we need to do so. We have to find some useful way to talk about > retirement > > of features, architectures, platforms, etc because we don't have enough > > manpower to maintain everything that ever entered the tree forever. We > have > > to make sure that the burden things place on other developers are, on the > > whole, out weighted by the benefit to the project. Since both of these > > factors lack hard data to back-up assertions, we must instead substitute > > our collective wisdom. There will be differences of opinion as to the > cost > > and worth of things, but the average of those opinions generally have > been > > shown to be good so long as the sample size is large and diverse enough. > > I did not object to it going, you do not have to make a case for that, > BUT I do object to the "reason" being "it is old", that is an incorrect > reason. The reasons are more correctly: > Being too old isn't the only reason. That's one of the many reasons articulated. The age of the code, the lack of innovation, the severe technical deficiencies, the sparse use, the lack of maintainer, the opinion of the domain experts in this field (Ian, myself, George and Poul-Hennig) which say this is poo, the nature of the commits in the last decade suggesting it's more of a drag on the tree than a help, etc. All strongly suggest it's time to go. Don't get hung up on any one of these being insufficient on its own: taken all together it's clear timed costs more than the benefit it brings to the project. > 1) It is only used by a small group of people (we should > define what the size of that group is that makes things > deprecatable.) The non existant data we have that leads > us to think it is ok to remove timed may be wrong, and > the 17.4 commiters procedure is designed to help catch > that. > 2) It has a reasonable replacement in ntpd > 3) It has a small, but perhaps measurable maintance cost. > (Though this well now be born by who ever if anyone > bothers to maintain your git version) > It will be. My github branch is complete now. All that it needs is someone to create a port and I'll move it over to the project repo space. I'm doubtful anybody will step up, but I've done the hard work of extraction. > > > > > > If it's old, we should remove it. The one major release thing is > nice to > > > > have in the steady state where you are caught up and retire things > just > > > in > > > > time. For the backlog we have, though, it will just get in the way. > But > > > in > > > > this case all we need to do is a direct commit to fix the man page > in 12 > > > to > > > > say it is gone in 13.... > > > > > > Yes, we can short circuit the process, but we should not just skip > > > the process. Need to fix both the man page and the binary to output > > > a message when it is invoked, and that needs to be commited to both > > > stable/11 and stable/12. > > > > > > > It's a daemon. We should not have it blast random bits. There's no need > for > > it and the bits would get lost anyway. Also, changes to the could break > > things in unanticipated ways if they can't be meaningfully tested. > > It is not only a daemon, it has an interactive command component > called timedc, and even then we *must* address this daemon issue > for deprecating. To rely on a note in a man page is not a good > plan. > > Daemons often can and do spit out startup messages, these are > not "blasting random bits" and your hyperbola is not helping > you make a good case. > > And if our skill levels are so low we can not add a startup message > to timed and a message to timedc I hate to think of the state of > the more complex code. > Unless we can test the code, it has a good chance to be broken. I don't think there's wide-spread consensus that all these things must be done without fail every time. In this case, there's no point: it's just make work. It would be better to create something in rc.d that prints out a message / sends it to syslog / etc when a deprecated daemon is in use. That way it's super low risk (timed_deprecated=yes in /etc/defaults/rc.conf) and is a reusable solution that will remove this friction point. > > A direct commit to the man page is all we need do here. > > We disagree, and stated procedure bears weight to my side. > Stated procedure is broken. We need to refine it. You know a procedure is not serving the needs of the group when it is routinely ignored. What is needed in this case isn't more enforcement, but a better procedure that's more concrete and easier for people to use. At lot of the process was our best guess at what to do at the time, but we never got around to testing our best guess and refining the bits that we got wrong. And now the atmosphere around this issue has become too dysfunctional for people to do the work that needs to be done. We need to fix that. > > > The prefered method would of been to do the notification stuff in > > > head, then merge that back to stable/11 and /12, then do the remove > > > in head. > > > > > > > True, but that wasn't done here. > > Sadly true. > Yea. But it wasn't done for a reason. If we can't take a look at why it wasn't done here, or in many other cases, then we're doomed to have this same freak-out after the fact. That doesn't help anybody. Warner From owner-freebsd-arch@freebsd.org Tue Dec 18 18:33:21 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C39F8133A520 for ; Tue, 18 Dec 2018 18:33:21 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 545B3816E6 for ; Tue, 18 Dec 2018 18:33:21 +0000 (UTC) (envelope-from se@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 14260133A51F; Tue, 18 Dec 2018 18:33:21 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CACE5133A51D for ; Tue, 18 Dec 2018 18:33:20 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56920816E5 for ; Tue, 18 Dec 2018 18:33:20 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd21.aul.t-online.de (fwd21.aul.t-online.de [172.20.27.66]) by mailout04.t-online.de (Postfix) with SMTP id E989441A85D6; Tue, 18 Dec 2018 19:33:11 +0100 (CET) Received: from Stefans-MBP-WLAN.fritz.box (JlX5q8ZT8hrf+S9f0g1sa3W9zjW2E+ddL6+vtRq9v97wkWv7vvRuOpgkr-lWExEQh2@[93.200.55.147]) by fwd21.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1gZKB5-26ErAG0; Tue, 18 Dec 2018 19:33:11 +0100 Subject: Re: A proposal for code removal prior to FreeBSD 13 To: Warner Losh , "Rodney W. Grimes" Cc: "freebsd-arch@freebsd.org" , George Neville-Neil References: <201812180109.wBI19eaK098408@pdx.rh.CN85.dnsmgr.net> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Message-ID: Date: Tue, 18 Dec 2018 19:33:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: JlX5q8ZT8hrf+S9f0g1sa3W9zjW2E+ddL6+vtRq9v97wkWv7vvRuOpgkr-lWExEQh2 X-TOI-MSGID: e87d5e48-2dda-45ab-bb52-b89590abb236 X-Rspamd-Queue-Id: 56920816E5 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.998,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: Tue, 18 Dec 2018 18:33:22 -0000 Am 18.12.18 um 17:00 schrieb Warner Losh: > Being too old isn't the only reason. That's one of the many reasons > articulated. The age of the code, the lack of innovation, the severe > technical deficiencies, the sparse use, the lack of maintainer, the opinion > of the domain experts in this field (Ian, myself, George and Poul-Hennig) > which say this is poo, the nature of the commits in the last decade > suggesting it's more of a drag on the tree than a help, etc. All strongly > suggest it's time to go. Don't get hung up on any one of these being > insufficient on its own: taken all together it's clear timed costs more > than the benefit it brings to the project. > >> 1) It is only used by a small group of people (we should >> define what the size of that group is that makes things >> deprecatable.) The non existant data we have that leads >> us to think it is ok to remove timed may be wrong, and >> the 17.4 commiters procedure is designed to help catch >> that. >> > 2) It has a reasonable replacement in ntpd >> 3) It has a small, but perhaps measurable maintance cost. >> (Though this well now be born by who ever if anyone >> bothers to maintain your git version) >> > > It will be. My github branch is complete now. All that it needs is someone > to create a port and I'll move it over to the project repo space. I'm > doubtful anybody will step up, but I've done the hard work of extraction. I do not use timed, but I'd be willing to create a port and perform the same steps as done for the removal of CTM from head. Just give me some time (I'm quite busy before the holidays), but I should have sufficient spare time within the next 2 weeks ... Regards, STefan From owner-freebsd-arch@freebsd.org Tue Dec 18 18:39:44 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92F20133A720 for ; Tue, 18 Dec 2018 18:39:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 027CB8192A for ; Tue, 18 Dec 2018 18:39:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id B17D8133A71F; Tue, 18 Dec 2018 18:39:43 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8ECC1133A71E for ; Tue, 18 Dec 2018 18:39:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2950381929 for ; Tue, 18 Dec 2018 18:39:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x830.google.com with SMTP id n32so19294914qte.11 for ; Tue, 18 Dec 2018 10:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZIUsm/HI3dhaYE363xG03ZUaLoWmwuIqfxsx1B39dWA=; b=uUgQiZVNDMNlRypbymH+C7nkLi3H/qsyxBWiJM/W7fO1DDVSxEnqckhekbiZcw0/YB 5YVm7NMk7Fy6sxduzb50VxHXNKYut38kn1FYrfdy2ZN85u9WaF/zDGbrbGaIsCyrhp5O RGlh8BxMMtv3ostHhb8xeUc/2UbPrq/dkjNDexlk0V0kq5x2rAqk/EYm6ipT/gvVCSnm AX/zQ+5EuzV4j02yTmXnIsO0gMW//s28qGGK9t3XE5U5kHBgEnIDfhTuS1ngCD/pKvt7 6G+AKiboHtTKVPKSwr6OVUGaUjNAjfSu6yO/GlNXZHMsuRUMDVQNL+ZKrx+UctDff0SF 1EkQ== 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=ZIUsm/HI3dhaYE363xG03ZUaLoWmwuIqfxsx1B39dWA=; b=i1tISkQe0O7g/zZruo+QhYzcwt4nZeXxbvnzb34+QiL2dNaQQybFtI0fqLE5aUBQ+z VqidGaMvaIL+/3iNBafaPBkO+OMDmUetF2jCIpfO+NZmawMH4Cv+B1R2BATLycsYo9XC mnPlsMNY0gDRxqBEv+G5pRz0hZvaQjFLYmk4Tqaataw9ncHQVU2/+ShmGt1MQiF4wXGI DqgQeraJvBWCu7Q0jkxSGkHazChT5rGFhz4vdjM8QbKf+M8PzfiwgRY1HJmB6P4/gagP m2JW+vhuHDLPNsfygW0Z9ywBl6geafrFCFHVe/IQCP3pHzTAHI8oRwfv0JxGGP9giROK fMKA== X-Gm-Message-State: AA+aEWbPdtqt4mKIIVqt3TOY4YMsxNnffBbG0dpMRG+o0WTZLq0KTI0k 8JRgdzcPexcnsZ2DGeXgN0wxgjq1nIYfWxH1jqRPQw== X-Google-Smtp-Source: AFSGD/X4gCGcxTI0u/ywhb05UNmTXuh3mqMFxF8TU7KXPW8vv9YMWlLfZEbbE9ukxdx/uefmu9246pxaG6dGPzrpl7Q= X-Received: by 2002:ac8:42c1:: with SMTP id g1mr19039759qtm.118.1545158382412; Tue, 18 Dec 2018 10:39:42 -0800 (PST) MIME-Version: 1.0 References: <201812180109.wBI19eaK098408@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Tue, 18 Dec 2018 11:39:29 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: Stefan Esser Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" , George Neville-Neil X-Rspamd-Queue-Id: 2950381929 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997,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: Tue, 18 Dec 2018 18:39:44 -0000 On Tue, Dec 18, 2018 at 11:33 AM Stefan Esser wrote: > > It will be. My github branch is complete now. All that it needs is > someone > > to create a port and I'll move it over to the project repo space. I'm > > doubtful anybody will step up, but I've done the hard work of extraction. > > I do not use timed, but I'd be willing to create a port and perform the > same steps as done for the removal of CTM from head. > > Just give me some time (I'm quite busy before the holidays), but I should > have sufficient spare time within the next 2 weeks ... > If you, or anybody else, wants to pick this up at any time in the future, the repo isn't going anywhere. When you find the time, get in touch and I'll get things pushed over to the freebsd account, just like I did for ctm. Warner From owner-freebsd-arch@freebsd.org Tue Dec 18 23:39:09 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B8AE1342B0F for ; Tue, 18 Dec 2018 23:39:09 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0FA8CE97 for ; Tue, 18 Dec 2018 23:39:09 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id D1E941342B0E; Tue, 18 Dec 2018 23:39:08 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C05771342B0D for ; Tue, 18 Dec 2018 23:39:08 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6077C8CE94 for ; Tue, 18 Dec 2018 23:39:06 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52C0CB.dip0.t-ipconnect.de [46.82.192.203]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id wBINcl1f085137 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2018 23:38:52 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id wBINchM4047791; Wed, 19 Dec 2018 00:38:44 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id wBINcHKi057605; Wed, 19 Dec 2018 00:38:25 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201812182338.wBINcHKi057605@fire.js.berklix.net> To: Warner Losh cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" , George Neville-Neil Subject: Re: A proposal for code removal prior to FreeBSD 13 From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Aachen Kent User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Tue, 18 Dec 2018 09:00:57 -0700." Date: Wed, 19 Dec 2018 00:38:17 +0100 X-Rspamd-Queue-Id: 6077C8CE94 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [0.16 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.18)[-0.178,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.06)[-0.059,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[land.berklix.com,slim.berklix.com]; NEURAL_HAM_SHORT(-0.57)[-0.572,0]; R_SPF_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[203.192.82.46.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(0.08)[ipnet: 144.76.0.0/16(2.92), asn: 24940(-2.51), country: DE(-0.01)]; 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: Tue, 18 Dec 2018 23:39:09 -0000 > And you are trying to conflate two different issues. timed is not useful. Exageration is not useful ;-) Timed is useful. > Technically, it's a crappy solution. OK. But in a heterogenous net, it's nice to retain flexibility. > The data is also > unencrypted / unauthenticated, with no provision to change that. This makes > it spoofable. Some suggested years past: Run over a ssh. Not tried as here it's inside a wall. Cheers, Julian -- Julian Stacey, Computer Consultant Sys.Eng. BSD Linux Unix, Munich Aachen Kent First referendum stole 700,000 votes from Brits in EU; 3,700,000 globaly. Lies criminal funded; jobs pound & markets down. 1.9M new voters 1.3M dead. Email MP: "A new referendum will buy UK & EU more time (Art 50.3), to avoid a hard crash, & consider all options." http://berklix.org/brexit/#mp From owner-freebsd-arch@freebsd.org Wed Dec 19 01:14:39 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE5C5134586D for ; Wed, 19 Dec 2018 01:14:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3301890418 for ; Wed, 19 Dec 2018 01:14:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id EAB1E134586C; Wed, 19 Dec 2018 01:14:38 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8118134586B for ; Wed, 19 Dec 2018 01:14:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6768190417 for ; Wed, 19 Dec 2018 01:14:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x734.google.com with SMTP id g125so10500688qke.4 for ; Tue, 18 Dec 2018 17:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nOIfegSwgCdeZrue+N/q0VezOeVsN1ab0y8Hq+XTUXk=; b=k2te4VHPQJZxhEqXPtIRpxVNunxsp0tu7ByYcBCWFFVJbc/HQG/MXIqP/2fZXew824 0su2sjT30HAt4uH5zFMjeRTeubAH74ojC9W9uVRDdwIEZPYhAoq9fZQ+xhzROTEWhpwm wP27jPl2ZwMNVYl8G51nmG+6iBmNXJYNEOaYQLetu9zYjCmoS2UdXKGeVXX+0mQCM9Wc qjwR5t7yAT0NNruAismWn7pcFHwC/qYukWiWXbewnvGqXgjKRmUZe0f8Q7571iOIDnHa BX19ZB/AJOGWM73Jqvyxfo9hCWoAg463ZBTZQ1p1XKkaSK0ZEgZQs3dNJCJ12yr2oKxv e3PQ== 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=nOIfegSwgCdeZrue+N/q0VezOeVsN1ab0y8Hq+XTUXk=; b=Di6nCOHjojhPqjdlTIhAk8f0Mc/6U8XIjDpXCEmSw8pwp6H3OJ//7U6brLMXB4oO0J lzIMbY3Nljs/N3K2MioOYj+VWnVHOtRj78nSzd2BXvl2Lr7vPRMwOtRqpsMh2AR3avPT VmlrfJPVdJ5i22J5Db8RKvuytZ5OsK37Au6p8AML1a8I7pxcqejfVxb72Mh/EjJSLo9w Hou74bMjNzBMbtkmHicx8QKcVqMn6u2QDccMJplYuJRSqjyW/l4Q6bVlgADHdYGukY+o DAmngv0q0oq0XWB2ji5GX98HyKKl8IFg4NWp0qIEvO44rYUjxv5X0iTQcFwbBlrJuyX0 MJZw== X-Gm-Message-State: AA+aEWbs+dOyPYnku5o0dDhi5vtr2Ezu5PWR/dDX23UR6RCG0q0wGR+/ B5ImZd2DLuAinf8UTvWjzEOOdtma8xQtOITIpCxo4P3p6eg= X-Google-Smtp-Source: AFSGD/X+gYXVzTm4Q9AS8XF5hxTX73uvwmyotqnMKEnAvjA1uU+YKcF8PIByGJgkQ/47yB8zfPcgbo0W4tkCG2qor1Q= X-Received: by 2002:a37:6c05:: with SMTP id h5mr18593373qkc.175.1545182077363; Tue, 18 Dec 2018 17:14:37 -0800 (PST) MIME-Version: 1.0 References: <201812182338.wBINcHKi057605@fire.js.berklix.net> In-Reply-To: <201812182338.wBINcHKi057605@fire.js.berklix.net> From: Warner Losh Date: Tue, 18 Dec 2018 18:14:25 -0700 Message-ID: Subject: Re: A proposal for code removal prior to FreeBSD 13 To: "Julian H. Stacey" Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" , George Neville-Neil X-Rspamd-Queue-Id: 6768190417 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; 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: Wed, 19 Dec 2018 01:14:40 -0000 On Tue, Dec 18, 2018 at 4:38 PM Julian H. Stacey wrote: > > And you are trying to conflate two different issues. timed is not useful. > > Exageration is not useful ;-) Timed is useful. > It has an extremely use usefulness index to the vast majority of our user base. Absent good metric data about what our users have deployed, I can't say that with certainty. But given the difficulty of running a timed network, both in terms of setup and operations, as well as its severe technical limitations wrt to competitors (ntp, ptp, openntp, etc) I'd be very very surprised if the number of current deployments are in double digits. > > Technically, it's a crappy solution. > > OK. But in a heterogenous net, it's nice to retain flexibility. > I'm not sure I understand how that helps. timed is a bit of a niche thing, that works only on a local area segment over ICMP. ntp, on the other hand, is widely implemented and deployed and gets through most firewalls. > > The data is also > > unencrypted / unauthenticated, with no provision to change that. This > makes > > it spoofable. > > Some suggested years past: Run over a ssh. Not tried as here it's inside a > wall. > >From the timed man page: "The average network time is computed from measurements of clock differences using the ICMP timestamp request message." How are you going to run that on top of ssh? I didn't think ssh had a ICMP mode... However, having said all that, there's a volunteer who will package up timed into a port. I'm working with him right now to fix some minor issues in the straight copy of the timed stuff into my repo and that should be live shortly after that, so anybody that needs it can do 'pkg add timed' Warner From owner-freebsd-arch@freebsd.org Thu Dec 20 22:06:52 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91AA41355957 for ; Thu, 20 Dec 2018 22:06:52 +0000 (UTC) (envelope-from steve.48@daum.net) Received: from mail-smail-vm32.hanmail.net (mail-smail-vm32.hanmail.net [203.133.180.216]) (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 425A970061 for ; Thu, 20 Dec 2018 22:06:48 +0000 (UTC) (envelope-from steve.48@daum.net) Received: from mail-hmail-smtp2.pg1.krane.9rum.cc ([10.194.31.52]) by mail-smail-vm32.hanmail.net (8.13.8/8.9.1) with SMTP id wBKM6gTU013320; Fri, 21 Dec 2018 07:06:42 +0900 X-Hermes-Message-Id: mBL76g4gL763255335 Received: from mail-qpsmtp-vm12 ([10.61.241.139]) by hermes of mail-hmail-smtp2.pg1.krane.9rum.cc (10.194.31.52) with ESMTP id mBL76g4gL763255335 for ; Fri, 21 Dec 2018 07:06:42 +0900 (KST) Received: from [92.223.73.112] (HELO DESKTOP-D0OTJLM) (92.223.73.112) by (8.12.9/8.9.1) with ESMTPA; ?, 21 12?? 2018 07:06:42 +0900 Errors-To: X-Originating-IP: 92.223.73.112 Message-ID: <02aee523-43455-41e31504525347@desktop-d0otjlm> Reply-To: "James" From: "James" To: freebsd-arch@FreeBSD.org Subject: WTS : Macbook Pro & WS-C3750X-24P-S Date: Fri, 21 Dec 2018 03:35:39 +0530 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Priority: 3 X-HM-UT: C5gMTqBD87o3qNfCuqS9wHzEMPO8LqqEtoQRYYyfyfY= X-Rspamd-Queue-Id: 425A970061 X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of steve.48@daum.net designates 203.133.180.216 as permitted sender) smtp.mailfrom=steve.48@daum.net X-Spamd-Result: default: False [6.98 / 15.00]; HAS_REPLYTO(0.00)[purchasing@briztechnology.com]; HAS_XOIP(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:203.133.180.0/24]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: mx4.hanmail.net]; HAS_X_PRIO_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:9764, ipnet:203.133.160.0/19, country:KR]; IP_SCORE(0.59)[ipnet: 203.133.160.0/19(1.61), asn: 9764(1.29), country: KR(0.06)]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.36)[0.360,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[daum.net]; NEURAL_SPAM_MEDIUM(0.95)[0.951,0]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_LONG(0.89)[0.887,0]; RCVD_IN_DNSWL_NONE(0.00)[216.180.133.203.list.dnswl.org : 127.0.5.0]; RCVD_ILLEGAL_CHARS(4.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; GREYLIST(0.00)[pass,body] X-Spam: Yes 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: Thu, 20 Dec 2018 22:06:52 -0000 Make us an offer on the following clean pull tested Intel CPU's Intel Xeon E5-4669 V3 SR22M Qty 33pcs Intel Xeon E5-4669 V4 SR2SG Qty 5pcs Intel Xeon E5-2699A V4 SR30Y Qty 5pcs WS-C3750X-24P-S Qty 30 WS-C3850-48P-S QTY : 5 Refurb Apple MacBook Pro Core i5 2.5 13" 2012 model A1278Part number MD101LL/A Specs INTEL CORE I5-3210M 2.5ghz 4GB 500GB DVDRW....QTY28pcs Make us an offer If you are Interested Please kindly contact us Best regards James Toner +1 709 500 2483\ purchasing@briztechnology.com 219 Stavanger Dr, St. John's, NL A1A 5E8, Canada http://www.briztechnology.com