From: James Bottomley <James.Bottomley@HansenPartnership.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Jens Axboe <axboe@kernel.dk> Cc: Christoph Hellwig <hch@infradead.org>, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>, ksummit <ksummit-discuss@lists.linuxfoundation.org>, ksummit@lists.linux.dev Subject: [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust] Date: Sun, 19 Jun 2022 10:45:00 -0400 [thread overview] Message-ID: <ca6243160b36aa42f4d0ad23853b84e57ca366f1.camel@HansenPartnership.com> (raw) In-Reply-To: <cefa5e41b74c96c81003cfd421cf754a03cc7f52.camel@HansenPartnership.com> On Sun, 2022-06-19 at 10:27 -0400, James Bottomley wrote: > On Sun, 2022-06-19 at 16:53 +0300, Laurent Pinchart wrote: [...] > > Whether it's worth the gain or not is not for me to decide, > > but I'm certainly concerned that it could lead to a catastrophe if > > we don't carefully think about the issues, acknowledge them, and > > find ways to solve them. I don't think winging it is a real option > > here, but I'd be more than happy to be shown that my concerns are > > not founded :-) > > Have more faith in the community and open source process. We've > screwed up many times (devfs anyone ...) learned from the mistake and > fixed it. I'm happy to bet that accepting Rust will be no different > from all the other screwups we allowed in and later fixed. So I > don't think there will be a catastrophe. Either the rust experiment > works or it will become fairly quickly apparent if it doesn't and it > will get removed. The worst case, I suppose, is that the benefit is > marginal in which case there's no consensus on removal vs > continuation and we simply continue through inertia. I bet in that > situation Rust penetration will be fairly minimal and confined to > enthusiastic subsystems with the rest taking steps to isolate > themselves from it. What we'd need in this case is some opinionated > person running the tree and able to make the call for us ... now who > could that be? 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. 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. The biggest area where we currently squelch innovation is around anything that touches the user space ABI. Allegations of having to get everything right ab initio because we have to support it "forever" and all the subsequent wittering and second guessing are really stifling innovation in pretty much anything that could be exposed to user space. I really think, to counter this, we need a crash course reminder of all of our mistakes and how we climbed out of the hole they dug us into, because without that we're becoming too fearful of making mistakes. The object is not to avoid mistakes at any cost, it's to be confident that if you make them, you're good enough to find a pathway out of them again. James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com> Subject: [Ksummit-discuss] [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust] Date: Sun, 19 Jun 2022 10:45:00 -0400 [thread overview] Message-ID: <ca6243160b36aa42f4d0ad23853b84e57ca366f1.camel@HansenPartnership.com> (raw) Message-ID: <20220619144500.vTBi86CxHWRxq6ZwvGlcrOSB3k6QfrgChVDNVRZkrWQ@z> (raw) In-Reply-To: <cefa5e41b74c96c81003cfd421cf754a03cc7f52.camel@HansenPartnership.com> On Sun, 2022-06-19 at 10:27 -0400, James Bottomley wrote: > On Sun, 2022-06-19 at 16:53 +0300, Laurent Pinchart wrote: [...] > > Whether it's worth the gain or not is not for me to decide, > > but I'm certainly concerned that it could lead to a catastrophe if > > we don't carefully think about the issues, acknowledge them, and > > find ways to solve them. I don't think winging it is a real option > > here, but I'd be more than happy to be shown that my concerns are > > not founded :-) > > Have more faith in the community and open source process. We've > screwed up many times (devfs anyone ...) learned from the mistake and > fixed it. I'm happy to bet that accepting Rust will be no different > from all the other screwups we allowed in and later fixed. So I > don't think there will be a catastrophe. Either the rust experiment > works or it will become fairly quickly apparent if it doesn't and it > will get removed. The worst case, I suppose, is that the benefit is > marginal in which case there's no consensus on removal vs > continuation and we simply continue through inertia. I bet in that > situation Rust penetration will be fairly minimal and confined to > enthusiastic subsystems with the rest taking steps to isolate > themselves from it. What we'd need in this case is some opinionated > person running the tree and able to make the call for us ... now who > could that be? 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. 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. The biggest area where we currently squelch innovation is around anything that touches the user space ABI. Allegations of having to get everything right ab initio because we have to support it "forever" and all the subsequent wittering and second guessing are really stifling innovation in pretty much anything that could be exposed to user space. I really think, to counter this, we need a crash course reminder of all of our mistakes and how we climbed out of the hole they dug us into, because without that we're becoming too fearful of making mistakes. The object is not to avoid mistakes at any cost, it's to be confident that if you make them, you're good enough to find a pathway out of them again. James
next prev parent reply other threads:[~2022-06-19 14:45 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-18 20:33 [TECH TOPIC] Rust Miguel Ojeda 2022-06-18 20:42 ` Laurent Pinchart 2022-06-18 20:42 ` [Ksummit-discuss] " Laurent Pinchart 2022-06-18 20:44 ` Laurent Pinchart 2022-06-18 20:44 ` [Ksummit-discuss] " Laurent Pinchart 2022-06-18 20:49 ` Miguel Ojeda 2022-06-19 6:13 ` Christoph Hellwig 2022-06-19 6:13 ` [Ksummit-discuss] " Christoph Hellwig 2022-06-19 10:04 ` Laurent Pinchart 2022-06-19 10:04 ` [Ksummit-discuss] " Laurent Pinchart 2022-06-19 12:56 ` James Bottomley 2022-06-19 12:56 ` [Ksummit-discuss] " James Bottomley 2022-06-19 13:19 ` Jens Axboe 2022-06-19 13:19 ` [Ksummit-discuss] " Jens Axboe 2022-06-19 13:53 ` Laurent Pinchart 2022-06-19 13:53 ` [Ksummit-discuss] " Laurent Pinchart 2022-06-19 14:27 ` James Bottomley 2022-06-19 14:27 ` [Ksummit-discuss] " James Bottomley 2022-06-19 14:45 ` James Bottomley [this message] 2022-06-19 14:45 ` [Ksummit-discuss] [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust] James Bottomley 2022-06-22 9:59 ` Linus Walleij 2022-06-22 10:57 ` Laurent Pinchart 2022-06-22 12:01 ` Linus Walleij 2022-06-22 12:09 ` Laurent Pinchart 2022-06-22 23:13 ` NeilBrown 2022-06-23 11:37 ` James Bottomley 2022-06-25 12:03 ` [Ksummit-discuss] " Mauro Carvalho Chehab 2022-06-25 11:45 ` [Ksummit-discuss] [TECH TOPIC] Rust Mauro Carvalho Chehab 2022-06-25 14:15 ` James Bottomley 2022-06-25 16:18 ` Mauro Carvalho Chehab 2022-06-25 22:29 ` Linus Walleij 2022-06-26 2:52 ` Theodore Ts'o 2022-06-26 3:18 ` Al Viro 2022-06-19 13:49 ` Laurent Pinchart 2022-06-19 13:49 ` [Ksummit-discuss] " Laurent Pinchart 2022-06-19 19:08 ` Geert Uytterhoeven 2022-06-19 19:08 ` [Ksummit-discuss] " Geert Uytterhoeven 2022-06-19 20:57 ` Matthew Wilcox 2022-06-20 13:53 ` Linus Walleij 2022-06-20 14:08 ` James Bottomley 2022-06-21 15:11 ` Dan Carpenter 2022-06-23 10:58 ` [TECH TOPIC] Why is devm_kzalloc() harmful and what can we do about it Laurent Pinchart 2022-06-23 11:24 ` Dan Carpenter 2022-06-23 11:31 ` Laurent Pinchart 2022-06-21 9:49 ` [TECH TOPIC] Rust David Woodhouse
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ca6243160b36aa42f4d0ad23853b84e57ca366f1.camel@HansenPartnership.com \ --to=james.bottomley@hansenpartnership.com \ --cc=axboe@kernel.dk \ --cc=hch@infradead.org \ --cc=ksummit-discuss@lists.linuxfoundation.org \ --cc=ksummit@lists.linux.dev \ --cc=laurent.pinchart@ideasonboard.com \ --cc=miguel.ojeda.sandonis@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).