From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx.treblig.org (mx.treblig.org [46.235.229.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 492101B0423; Fri, 7 Feb 2025 18:54:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.229.95 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738954457; cv=none; b=GlCiSQyEH0+5AigkHVQCH7HwUJnXmGgL8bDrgqczS/dj6cFeefswWUMUEgD9yPvCYgZVdtjaTOWLY5ivoPR/UwajKnfwY58hYoEWqsdHTd3Ipq6HgqGS7+LRObgZWGPDqPs/5m1eutoU/WS2BduyCdm8ZI7u4hsmrK5jOR+iOS4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738954457; c=relaxed/simple; bh=39tM/FelPk8IXPE4RyvCWWz+ddMpywlUPjAZQcKRfUY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=djIFkZK4wBwSdW1XlTA3KHSyZPQ4RfFaBeoljoiFaKMJHPdGPcNfDCzrUvZ51nJuexbeStTDPLNq8A6azYwMeR0Pk7Qc03iOhvxFKYq0sT/Pj7soz33iWCTFYAa597CpbY6EhRMSwtPZCwgGRJrVv8kLXma1ETeStpVcZFAHufk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=treblig.org; spf=pass smtp.mailfrom=treblig.org; dkim=pass (2048-bit key) header.d=treblig.org header.i=@treblig.org header.b=smKJK53u; arc=none smtp.client-ip=46.235.229.95 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=treblig.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=treblig.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=treblig.org header.i=@treblig.org header.b="smKJK53u" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=treblig.org ; s=bytemarkmx; h=Content-Type:MIME-Version:Message-ID:Subject:From:Date:From :Subject; bh=EAcqYwz2jmB6Mvusczq8VIeE3A07B10hda1ej7t/Xe8=; b=smKJK53uK4eErOQV PDjUcgn3F89vn7KLBPpz/VkKUhnQuII8VRw7zR8UyeMBeNDJVSAxi12sNrwyadDFDtWWS0Xndz4SO ldx/PvWRDZgBXjf3APTyUBa4sguVxsFYPwiU+wjnbnjcsxAIN3j1R+6So9KLN5tk4s1TeG0wbhl9I rtezlIgvdtv+ZV8v5FYvDOMipJ1I7B05/bma9ABqItWYzGj2COLa8SutJ+aD4qvEuqArt9WCn1WBe 0KuZ0ejFNeLfXX43LM1Wdk/qqTCWEkPFLm7EN38d/H/iQs5HGCi0olpebtywvE+qzfaW1r/QB3y/a ADK20FLy8pv2gt+KiQ==; Received: from dg by mx.treblig.org with local (Exim 4.96) (envelope-from ) id 1tgTU3-00ELPl-1K; Fri, 07 Feb 2025 18:53:47 +0000 Date: Fri, 7 Feb 2025 18:53:47 +0000 From: "Dr. David Alan Gilbert" To: Hector Martin Cc: Konstantin Ryabitsev , Danilo Krummrich , Dave Airlie , Jason Gunthorpe , Greg KH , Linus Torvalds , phasta@kernel.org, Christoph Hellwig , Miguel Ojeda , Abdiel Janulgue , daniel.almeida@collabora.com, aliceryhl@google.com, robin.murphy@arm.com, rust-for-linux@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Valentin Obst , open list , Marek Szyprowski , airlied@redhat.com, "open list:DMA MAPPING HELPERS" , DRI Development Subject: Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.) Message-ID: References: <2025013148-reversal-pessimism-1515@gregkh> <20250131135421.GO5556@nvidia.com> <2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st> <208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st> <4c0a7cf9-26e1-4a19-8a6e-7c30bc3aef86@marcan.st> <20250207-mature-pastel-rottweiler-e6dbd9@lemur> <1bbdf8b7-a70b-4994-865e-7fcb8d53ebef@marcan.st> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1bbdf8b7-a70b-4994-865e-7fcb8d53ebef@marcan.st> X-Chocolate: 70 percent or better cocoa solids preferably X-Operating-System: Linux/6.1.0-21-amd64 (x86_64) X-Uptime: 18:48:07 up 275 days, 6:02, 1 user, load average: 0.06, 0.05, 0.00 User-Agent: Mutt/2.2.12 (2023-09-09) * Hector Martin (marcan@marcan.st) wrote: > On 2025/02/08 2:14, Konstantin Ryabitsev wrote: > > On Fri, Feb 07, 2025 at 05:16:28AM +0900, Hector Martin wrote: > >> And what I see, is very little effort to improve that status quo, or at > >> least very little that yields any actual change that isn't just > >> band-aids (e.g. tooling like b4, which is nice and appreciated, but > >> doesn't fix any underlying issues). And that's not going to change no > >> matter how many long technical arguments we have on the MLs (or even off > >> MLs, since MLs are also not particularly good for this, and I've seen > >> multiple arguments only reach a resolution after being redirected to IRC). > > > > From my perspective, there are several camps clashing when it comes to the > > kernel development model. One is people who are (rightfully) pointing out that > > using the mailing lists was fine 20 years ago, but the world of software > > development has vastly moved on to forges. > > > > The other camp is people who (also rightfully) point out that kernel > > development has always been decentralized and we should resist all attempts to > > get ourselves into a position where Linux is dependent on any single > > Benevolent Entity (Github, Gitlab, LF, kernel.org, etc), because this would > > give that entity too much political or commercial control or, at the very > > least, introduce SPoFs. > > > > At best, I can hope to make both camps grumpily agree to coexist. > > > > I *am* very wary of Benevolent Entities, because we have too many very recent > > examples of companies "realigning priorities" when political winds shift. > > Programs and initiatives that have until recently been poster board examples > > of progress and benevolence are shuttered and defunded. I am concerned that > > we're only a couple of mood swings away from someone deciding that free > > software should not be allowed to exist because it benefits America's foes. > > Many of us remember all too well when large tech giants treated Linux as a > > "cancer" to be opposed, and I can certainly see that idea easily re-entering > > some Big Brain in Charge. > > > > From my perspective, I would like to ensure that Linux development can > > continue without a hard dependency on a single centralized forge -- whether > > controlled by a large commercial entity, or even a standalone one that is > > operated by kernel.org. It's becoming shockingly difficult to operate a public > > resource on the web unless you're willing to put it behind a large commercial > > CDN that will protect you from hostile bots (and if you do that, you're back > > to depending on the whims of a Benevolent Entity). > > > > We're trying to get lore.kernel.org to the point where it's like a global > > messaging bus that is indexed and searchable. Currently, you mostly have to > > send things to a mailing list for them to end up on lore, but it's gradually > > becoming less and less the case. We're already bridging with bugzilla and we > > should be able to bridge with forges soon, too (currently delayed again > > because I'm scrambling to move kernel.org frontends away from Equinix). Who > > knows, we may be actually leapfrogging the forge era of software development > > straight into "AI" agents era -- but that remains to be seen. > > > > Anyway, all of this is to say that I'm happy that you've found b4 useful, but > > I wouldn't view it as a band-aid -- it's just a very small and email-centric > > way to interact with the kernel lore. > > > > The centralization concern is valid, but there are technical solutions > to this, such as forge federation. It's possible to set up a forge > environment to be less of a SPoF, such as by ensuring all data is open > and archiveable to allow for migration and backup restore, even by third > parties (you can make practically ~all forge data public except for > login passwords, and we have email-based reset processes for those). > It's also possible to simply shard, and let different subsystems choose > their own forge infrastructure, so downtime has a more limited effect. > > Meanwhile, for better or worse, much of Linux infra *is* centralized - > for example, the mailing lists themselves, and a lot of the Git hosting. Although, many of the subsystems have their own patchworks or other systems anyway dotted in random places. It's actually something I find quite hard, it might seem there is *a* Linux contribution process, but if you do fixups or devices all over rather than in one subsystem you end up tripping over the oddities of each maintainer; then trying to figure out when they're prepared to take a patch, or where to check for whether they've taken it, or whether to expect it to turn up in -next can all be quite random. > - Hector Dave > > -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/