From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (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 02C91137A for ; Wed, 22 Jun 2022 10:58:31 +0000 (UTC) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id EB3EEDD; Wed, 22 Jun 2022 12:58:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1655895503; bh=gh1RlTRhHumPzOhv9+kkYzuq6vQ1SAOwnCcJZHYS77c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f01ejDXFiPopbW4lMGmZdrH3OTlYZDg4hjBfBgLutgNrf3i8Rb36sZcmYjNERCMyY 0kNam8N268JvmGoLxUH6cze5a4SQkEIBCOUfjeMlKlMzuqMzENdE7R3SoqM+nHKR+K UOeGaO3DPJmL7xgXNg5KW8kBW8W5Syc63QNe0nco= Date: Wed, 22 Jun 2022 13:57:58 +0300 From: Laurent Pinchart To: Linus Walleij Cc: James Bottomley , Jens Axboe , Christoph Hellwig , Miguel Ojeda , ksummit@lists.linux.dev, ksummit Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust] Message-ID: References: <2513dc4528c71d34d400c104e91ada6517869886.camel@HansenPartnership.com> Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Hi Linus, On Wed, Jun 22, 2022 at 11:59:03AM +0200, Linus Walleij wrote: > On Sun, Jun 19, 2022 at 4:45 PM James Bottomley wrote: > > > I think there's a growing problem in Linux which is exemplified by this > > Rust debate but which goes way beyond it: We're becoming too fearful of > > making big decisions to sustain innovation in some areas. > > I agree. > > > This really > > is a creeping cancer of inertia that has destroyed many projects before > > us and if we're not careful, we'll go the same way. > > Strong words. This phenomenon is known from organization theory. > Organization theory exist in dry and tasteless versions and some more > colorful and spicy versions. Let's revisit the most spicy and colorful of > them all, Cyril Norhcote Parkinson, a true representative of the > atomic space age. > > In his famous book "Parkinson's Law" from 1957 (a book passed to > me from my great grandfather, and annoyingly relevant to this day), > in the last chapter titled "Pension point, or the age of retirement" he > touches on the subject. There might be an illicit copy here, page 42: > http://sas2.elte.hu/tg/ptorv/Parkinson-s-Law.pdf > > Parkinson is writing satire and it is a clear hyperbole. But it isn't funny > if it isn't relevant. He saw the same thing as you see, and just > state (apparently based on nothing but his own experience) that a > persons "age of wisdom" is followed by the "age of obstruction". > Just constant risk avoidance. Blaeh. Boring. > > I don't know about eBPF, but Rust is nice. Let's merge it and see what > happens. As one of my friends working in embedded systems said: > "this is the only new thing I have seen in my career, the rest is just > repetitions of the past", and I agree with that. The past two years may have increased the reluctance of following the strategy of "let's ignore any possible warning, it's going to be fine". There's a set of non-technical issues around kernel development, from community management to hiring skilled developers. I understand lots of the concerns that have been expressed (including some by myself) in that context. Some may be classified as unfounded fears (it would be so much easier if we could tell in advance which ones are founded and which ones are not), and I think using rust in Linux could actually help in some of the non-technical areas (by attracting developers from different horizons to the kernel for instance). This doesn't mean that all concerns should be ignored, and I read most of them more as constructive feedback trying to find solutions than just attempts to stall progress here. For instance, I see a widespread concern that, as rust spreads in more places through the kernel, it will generate extra work for people who are not able or ready yet to handle this. This can be handled in two ways: we can ignore that concern, and deal later with the potential conflicts it could generate, or we could try to address it already. Could the second option be extra work to handle an issue that may not materialize ? Yes, of course. I see it more as an opportunity myself. For instance, we could address that concern by creating and advertising a support channel for developers and maintainers who need help dealing with rust impacting their work (e.g. when doing tree-wide reworks) could get help, and making sure we'll have a few rust-in-linux maintainers there who can provide support (it could be a mailing list, an IRC channel, ...). Not only would it send the message that the rust-in-linux community listens to concerns and cares, but it would also result in having a useful support resource from day one, as well as showing that this project really has the means it requires to move forward. > My biggest worry is that the kernel community can become irrelevant > for young people as a demographic. Young people like things like > Rust and web-based merge requests on github. They are also very > smart. So I see it as partly an inclusion problem. If you put rust and github in the same bag, you'll drastically increase the size of the mob that will chase you with pitchforks :-) -- Regards, Laurent Pinchart