From nobody Sat Aug 09 11:42:44 2025 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 4bzfCf0NCmz6468w for ; Sat, 09 Aug 2025 11:42:54 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (dglawrence.com [50.76.111.10]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mailx.dglawrence.com", Issuer "mailx.dglawrence.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bzfCd4XXvz3bwQ; Sat, 09 Aug 2025 11:42:53 +0000 (UTC) (envelope-from dg@dglawrence.com) Authentication-Results: mx1.freebsd.org; none Received: from mailx.dglawrence.com ([10.19.1.8]) by dglawrence.com (8.15.2/8.15.2) with ESMTPS id 579Bgj2H045792 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 Aug 2025 04:42:46 -0700 (PDT) (envelope-from dg@dglawrence.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dglawrence.com; s=ab7ba439; t=1754739766; bh=6fMAwzl9lJoM+fUslCY05j+tarYJxok819nFFxSG4y8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=RZquW94jymwnP+IuXkk0Gl28CkOodxh4cJi9h3F3h4bQI5r3WVDf70NuJKcBS1+mF 5NLzu8vmJ1sG7OzAMdfqMOqWdIB7noVmL3PR0F9e/MG4NnD3SHdntxoVJnq5oFlC8w XulPmV2aJD3U8p+GR3SNWZQVfUhiosqn7I4jWZ80= Received: (from dg@localhost) by mailx.dglawrence.com (8.15.2/8.15.2/Submit) id 579BgiCV045791; Sat, 9 Aug 2025 04:42:44 -0700 (PDT) (envelope-from dg@dglawrence.com) Date: Sat, 9 Aug 2025 04:42:44 -0700 From: David G Lawrence To: Warner Losh Cc: Tomoaki AOKI , Michal Meloun , FreeBSD Current Subject: Re: PKGBASE Removes FreeBSD Base System Feature Message-ID: <20250809114244.GU26557@mailx.dglawrence.com> References: <20250809062925.GN26557@mailx.dglawrence.com> <929543B2-633E-44B5-B6F6-F292CCEADAB3@freebsd.org> <20250809065247.GO26557@mailx.dglawrence.com> <96820ff6-bdb0-4d25-ad78-502e30b7e479@FreeBSD.org> <20250809185418.7d272536dd5862d0bdfd39c2@dec.sakura.ne.jp> <20250809101145.GS26557@mailx.dglawrence.com> 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=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (dglawrence.com [10.19.1.8]); Sat, 09 Aug 2025 04:42:46 -0700 (PDT) X-Rspamd-Queue-Id: 4bzfCd4XXvz3bwQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7922, ipnet:50.76.0.0/14, country:US] > > > > kmod in the ports is a different problem ??? it shows the inability of > > > > FBSD developers to implement these things on their own, so this > > > > solution has some problems. And don't kill me, I fully understand > > that > > > > it's not possible , but that doesn't change the previous fact. > > > > > > > > Michal > > > > > > Sometimes yes, but sometimes no. > > > > > > On early but widely testable developement phase for drivers, especially > > > SD card drivers, network (including but not limited with WiFi) drivers > > > and disk controllers, base is not a good place even for FreeBSD-native > > > drivers. > > > > > > This is because turnaround time for implememt (fix) / test / commit > > > on base is usually take much longer days (or even months!) than in > > > ports. So recently, AFAIK, some drivers are first developed as > > > kmod ports, and once stabilized, merged into main branch of src. > > > > > > What comes in my mind is rtsx driver for Realtek SD card reader driver. > > > > Tomoaki, > > > > I see what you're saying and I agree completely. But, I think this is > > pointing squarely at problem in the development paradigm for src > > committers. > > It should not take weeks or months to fix/test/commit/repeat in src. It > > didn't used to be that way, so if it is now, then something has broken > > in the paradigm, and _that_ needs to be fixed. > > > > Fun fact: bectl would completely fix the pkg delete issue. But I digress: > rm -rf In the wrong spot also will kill base. It's a strange hill to die > on. It also ignores common use cases, like wifibox, that make a system > critically dependent on ports that in simplwr times didn't happen... > > But some perspective on rtsx. the rtsx driver is an obscure edge case 1000 > times less popular than the sdhci driver. And even that is 1000x less > popular than nvme. Given limited time and lack of ability to buy the rtsx > hardware easily, it's hard to justify using my time for that driver when > testing patches for other drivers is easier and benefits more people. > That's why I passed over some of the changes there, especially since there > were big issues with that driver initially that would have taken a lot of > time to articulate. That is how I have prioritized my time on the thousands > of fixes i have done for people, many the same day. Using it as a > posterchild for src being slow overstates the problems typical patches have > gwtting in. > > I have been trying to solve the actual, underlying problems behind it: > getting the pipeline flowing better through reduced friction for > submissions (some good, but many lousy and it takes time to sort and you > never know if a lot of feedback will produce a better outcome for any given > problematic patch). Getting a deeper bench onboard and growing aspects of > our culture are also key areas needing help. I've had a hard time getting > others to help, assume ownership, follow through on promises, etc. If you > want to help fix things, it's helping me fix this problem. Fixing that > increases the scarse developer resources and helps make it easier to fix > more issues. But 4 years in, it is a problem resistant to easy solutions. > > Warner ...and for the record, I didn't have any idea about where the problem is/was, but now I see it clearly, and I did not intend to critizise anyone. I, as well as anyone I think, understand that FreeBSD is a volunteer project and any time that a developer puts into it is a _gift_, and we must never lose sight of that. But now I'm going to say something controversial: I was disappointed by the reaction about AI, and how it could help the project, in the developers list. While I fully appreciate the concerns about "stealing" other people's work (indirectly through the training of the vast corpus of the Internet) - i.e., the potential to violate copyright, what was said in that thread - to dismiss what AI could do for the project, for the development cycle - was exceptionally, tragically, myopic. Most people in the world (and here I mean 5 Sigma +) have no idea what's about to hit them. I've been deep in AI research recently and I can tell you, first hand, well...we're in for interesting times ahead. We can either embrace it or be tossed into the scrap heap of history. -DG * Dr. David G. Lawrence * * DG Labs Pave the road of life with opportunities.