From nobody Sun Oct 31 22:06:40 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 00FA5182617F; Sun, 31 Oct 2021 22:06:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hj9Hb3XYrz55xg; Sun, 31 Oct 2021 22:06:50 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 19VM6fFQ021901; Mon, 1 Nov 2021 07:06:41 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Mon, 1 Nov 2021 07:06:40 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: freebsd-stable@freebsd.org Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Message-Id: <20211101070640.247345226b0dc84717c3ee0b@dec.sakura.ne.jp> In-Reply-To: References: <8d25d2f4-24e2-5b19-5c81-2fe12dc937b7@quip.cz> <20211029074702.d69cba39a643f3f912f8ec81@dec.sakura.ne.jp> <940c9341-6938-05a1-d0b3-f20f07f9d3de@netfence.it> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Hj9Hb3XYrz55xg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [0.40 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N On Sun, 31 Oct 2021 18:15:25 +0100 Marek Zarychta wrote: > W dniu 29.10.2021 o〓08:29, Andrea Venturoli pisze: > > > > On 10/29/21 00:47, Tomoaki AOKI wrote: > > > >> But possibly we need to delete current smbfs code from base and switch > >> to ports (sysutils/*?) if it require some code having incompatible > >> license for base. > > > +1 for removing smbfs(5) from the base and eventually moving it to the > ports tree. I know some people are still using it with a bit of duct > tape and baling twine to workaround〓 SMBv{2,3) incompatibility. Keeping this in base as long as possible should be preferred, as changes throuout all filesystems would be easier to be missed that on ports. But borrowing GPL'ed (or any other BSD-incompatible licensed) codes would disallow it. > With SMBv1 support, only our smbfs(5) became useless a few years ago. No. It's much better than nothing. For example, DSM on Synology NAS disabled support for SMB1 and NTLM1 by default, but admin can easily enable them again through control panel. So it's usable (for local networks) at least for now. > Unfortunately, there is no replacement in the ports tree. To mount SMB > shares for Nextcloud the port net/pecl-smbclient can be used, but > definitely deploying Nextcloud to mount only SMB shares is overkill. > > > OTOH having a port is not in any way worse as having a broken piece of > > base. > > It sounds reasonable. Moreover, the story of net/wireguard-kmod has > proven that moving some modules into ports, where the software > development is done in a more flexible way, can be beneficial for both: > the developers and the community. > > My opinion is only the opinion of the FreeBSD user, but I believe that > sometimes the feedback from the userbase is important, especially that a > few months I was told by one of the younger *NIX admins that our > (FreeBSD) community is the best and he is willing to make a transition > of some services to FreeBSD as soon as he gets permission from the > management. > > With kind regards, > > -- > Marek Zarychta > > -- Tomoaki AOKI