From: Thomas Schoebel-Theuer <tst@schoebel-theuer.de>
To: Kajetan Puchalski <mrkajetanp@gmail.com>, mceier+kernel@gmail.com
Cc: ojeda@kernel.org, Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-doc@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Thomas Schoebel-Theuer <tst@schoebel-theuer.de>
Subject: Re: [PATCH 00/13] [RFC] Rust support
Date: Fri, 30 Apr 2021 08:39:36 +0200 [thread overview]
Message-ID: <7999ba57-9b95-265e-a189-d9ca01304b13@schoebel-theuer.de> (raw)
In-Reply-To: <878s51e3jc.fsf@gmail.com>
On 29/04/2021 13:25, Kajetan Puchalski wrote:
>
> Mariusz Ceier <mceier+kernel@gmail.com> writes:
>
>> Rust compiler license doesn't require for people to give back to the
>> community - corporation can create their own version of rust compiler
>> adding some proprietary extensions, develop drivers with it and even
>> if the drivers code will be GPL'd they won't be buildable by anyone
>> but that corporation.
>
> Could you explain exactly what the issue you see there is?
Kajetan and others, this is an interesting discussion for me. Let us
compare the kernel-specific scope with general OpenSource community and
industry scope.
Industry (where I am working) often requires a "second source" to avoid
the so-called "vendor lock-in", which is the key point of this part of
the discussion.
As soon as Copyleft is involved, the requirement of "second source" is
_permanently_ met: anyone may fork it at any time, creating another
source, (theoretically) avoiding a dead end eternally. Lock-in is
prevented at license level.
IMO this is a _requirement_ for Linux, otherwise its "business model"
wouldn't work in the long term (decades as is always necessary for basic
infrastructure / system software).
If the requirement "second source" (by either way) is not met by Rust at
the moment, this needs to be fixed first.
Other limitations like "development resources" might lead to similar
effects than lock-in. I am seeing the latter nearly every workday.
Software becomes "unmanageable" due to factors like technical debts /
resource restrictions / etc. Typical main reasons are almost always at a
_social_ / _human_ level, while purely technical reasons are playing
only a secondary role.
This is the link to what Greg said earlier in this discussion:
development resources and their _dedication_ (e.g. maintenance vs
creation of "new" things) is the absolute key.
Would Rust improve this problem area _provably_ by at least 30% ?
I am insisting on a _quantifiable_ 30% improvement because this is the
"magic theshold" in industry after which the motto "never change a
running system" can be overcome from an investment perspective, and also
from a risk perspective.
After this, another dimension is kicking in: maturity.
You always need to invest a high effort for achieving "sufficient
maturity". According to the Pareto principle, maintenance is typically
around 70% to 90% of total cost for key infrastructure.
In my working area where end-to-end SLAs of >99.98% have to met, the
Pareto ratio may be even higher.
Pareto's law, as well as Zipf's law, are more or less observational
"natural laws" holding for almost _any_ complex / dynamic system. Even
if you try to improve such universal laws, e.g. by investing a lot of
effort / resources / money into maintenance reduction techniques, you
typically end up at a similar _total_ effort for maintenance (including
the extra effort for reduction of "ordinary" maintenance) than before.
Otherwise, you would have found a way for bypassing natural laws like
the observed Pareto law. Even billions of years of biological evolution
on this earth weren't able to change this universal law in statistical
average (in global scale). Otherwise we couldn't observe it anymore.
Even if you could improve the Pareto ratio, my experience is that upper
management will kick in and raise the SLA level so that Pareto holds
again ;)
So I'm sceptical that new technologies like Rust will change fundamental
laws, e.g. with respect to relative maintenance efforts.
However, what _could_ be theoretically possible: _productivity_ gains,
improving both development of "new" things as well as "maintenance"
efforts, in total by more than 30% (but not the Pareto ratio between them).
So the question is: can Rust _provably_ lead to *quantifiable* total
productivity gains of at least 30% ?
If this would be the case, any business case needs further alternatives.
So it needs to be compared at least with alternative B: what would be
the effort and the productivity gain when introducing similar technology
non-disruptively into the current development ecosystem?
Even if this A-B comparison would lead to a conclusion that 30% cannot
be met by a new and partly disruptive technology like Rust, the
discussion can be fruitful. There is always a chance to introduce some
parts of a new technology into a well-proven and mature "old" technology
non-disruptively.
Cheers,
Thomas
next prev parent reply other threads:[~2021-04-30 6:39 UTC|newest]
Thread overview: 203+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 18:45 [PATCH 00/13] [RFC] Rust support ojeda
2021-04-14 18:45 ` [PATCH 01/13] kallsyms: Support "big" kernel symbols (2-byte lengths) ojeda
2021-04-14 19:44 ` Matthew Wilcox
2021-04-14 19:59 ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 02/13] kallsyms: Increase maximum kernel symbol length to 512 ojeda
2021-04-14 23:48 ` Nick Desaulniers
2021-04-14 18:45 ` [PATCH 03/13] Makefile: Generate CLANG_FLAGS even in GCC builds ojeda
2021-04-14 18:59 ` Nathan Chancellor
2021-04-15 10:18 ` Miguel Ojeda
2021-04-14 23:46 ` Nick Desaulniers
2021-04-15 0:47 ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 04/13] Kbuild: Rust support ojeda
2021-04-14 23:19 ` Nick Desaulniers
2021-04-15 0:43 ` Miguel Ojeda
2021-04-15 18:03 ` Nick Desaulniers
2021-04-16 12:23 ` Miguel Ojeda
2021-04-17 19:35 ` Masahiro Yamada
2021-04-16 13:38 ` Peter Zijlstra
2021-04-16 17:05 ` Linus Torvalds
2021-04-16 17:47 ` Miguel Ojeda
2021-04-16 18:09 ` Al Viro
2021-04-16 18:57 ` Miguel Ojeda
2021-04-16 20:22 ` Willy Tarreau
2021-04-16 20:34 ` Connor Kuehl
2021-04-16 20:58 ` Willy Tarreau
2021-04-16 21:39 ` Miguel Ojeda
2021-04-16 22:04 ` Willy Tarreau
2021-04-16 22:45 ` Al Viro
2021-04-16 23:46 ` Miguel Ojeda
2021-04-17 4:24 ` Willy Tarreau
2021-04-17 15:38 ` Miguel Ojeda
2021-04-16 21:19 ` Miguel Ojeda
2021-04-16 17:34 ` Miguel Ojeda
2021-04-19 19:58 ` David Sterba
2021-04-19 20:17 ` Matthew Wilcox
2021-04-19 21:03 ` Miguel Ojeda
2021-04-19 20:54 ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 05/13] Rust: Compiler builtins crate ojeda
2021-04-14 19:19 ` Linus Torvalds
2021-04-14 19:34 ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 06/13] Rust: Module crate ojeda
2021-04-14 18:45 ` [PATCH 08/13] Rust: Export generated symbols ojeda
2021-04-14 18:46 ` [PATCH 09/13] Samples: Rust examples ojeda
2021-04-14 19:34 ` Linus Torvalds
2021-04-14 19:42 ` Miguel Ojeda
2021-04-14 19:49 ` Matthew Wilcox
2021-04-16 11:46 ` Andrej Shadura
2021-04-14 23:24 ` Nick Desaulniers
2021-04-15 7:10 ` Greg Kroah-Hartman
2021-04-15 7:39 ` Nick Desaulniers
2021-04-15 12:42 ` Miguel Ojeda
2021-04-16 13:07 ` Sven Van Asbroeck
2021-04-16 13:20 ` Greg Kroah-Hartman
2021-04-14 18:46 ` [PATCH 10/13] Documentation: Rust general information ojeda
2021-04-14 22:17 ` Nick Desaulniers
2021-04-14 23:34 ` Miguel Ojeda
2021-04-14 18:46 ` [PATCH 11/13] MAINTAINERS: Rust ojeda
2021-04-14 21:55 ` Nick Desaulniers
2021-04-14 22:02 ` Miguel Ojeda
2021-04-14 22:36 ` Nick Desaulniers
2021-04-14 18:46 ` [PATCH 12/13] Rust: add abstractions for Binder (WIP) ojeda
[not found] ` <20210414184604.23473-8-ojeda@kernel.org>
2021-04-14 19:31 ` [PATCH 07/13] Rust: Kernel crate Linus Torvalds
2021-04-14 19:50 ` Miguel Ojeda
2021-04-14 19:44 ` [PATCH 00/13] [RFC] Rust support Linus Torvalds
2021-04-14 20:20 ` Miguel Ojeda
2021-04-15 1:38 ` Kees Cook
2021-04-15 8:26 ` David Laight
2021-04-15 18:08 ` Kees Cook
2021-04-15 12:39 ` Miguel Ojeda
2021-04-14 20:09 ` Matthew Wilcox
2021-04-14 20:21 ` Linus Torvalds
2021-04-14 20:35 ` Josh Triplett
2021-04-14 22:08 ` David Laight
2021-04-14 20:29 ` Miguel Ojeda
2021-04-18 15:31 ` Wedson Almeida Filho
2021-04-15 0:22 ` Nick Desaulniers
2021-04-15 10:05 ` Miguel Ojeda
2021-04-15 18:58 ` Peter Zijlstra
2021-04-16 2:22 ` Wedson Almeida Filho
2021-04-16 4:25 ` Al Viro
2021-04-16 5:02 ` Wedson Almeida Filho
2021-04-16 5:39 ` Paul Zimmerman
2021-04-16 7:46 ` Peter Zijlstra
2021-04-16 7:09 ` Peter Zijlstra
2021-04-17 5:23 ` comex
2021-04-17 12:46 ` David Laight
2021-04-17 14:51 ` Paolo Bonzini
2021-04-19 7:32 ` Peter Zijlstra
2021-04-19 7:53 ` Paolo Bonzini
2021-04-19 8:26 ` Peter Zijlstra
2021-04-19 8:35 ` Peter Zijlstra
2021-04-19 9:02 ` Paolo Bonzini
2021-04-19 9:36 ` Peter Zijlstra
2021-04-19 9:40 ` Paolo Bonzini
2021-04-19 11:01 ` Will Deacon
2021-04-19 17:14 ` Linus Torvalds
2021-04-19 18:38 ` Paolo Bonzini
2021-04-19 18:50 ` Linus Torvalds
2021-04-22 10:03 ` Linus Walleij
2021-04-22 14:09 ` David Laight
2021-04-22 15:24 ` Wedson Almeida Filho
2021-04-26 0:18 ` Linus Walleij
2021-04-26 14:26 ` Miguel Ojeda
2021-04-26 14:40 ` Wedson Almeida Filho
2021-04-26 16:03 ` Miguel Ojeda
2021-04-27 10:54 ` Linus Walleij
2021-04-27 11:13 ` Robin Randhawa
2021-04-29 1:52 ` Wedson Almeida Filho
2021-04-26 18:01 ` Miguel Ojeda
2021-04-22 21:28 ` Miguel Ojeda
2021-04-26 0:31 ` Linus Walleij
2021-04-26 18:18 ` Miguel Ojeda
2021-04-27 11:13 ` Linus Walleij
2021-04-28 2:51 ` Kyle Strand
2021-04-28 3:10 ` Miguel Ojeda
2021-05-04 21:21 ` Linus Walleij
2021-05-04 23:30 ` Miguel Ojeda
2021-05-05 11:34 ` Linus Walleij
2021-05-05 14:17 ` Miguel Ojeda
2021-05-05 15:13 ` Enrico Weigelt, metux IT consult
2021-05-06 12:47 ` Linus Walleij
2021-05-07 18:23 ` Miguel Ojeda
2021-04-16 4:27 ` Boqun Feng
2021-04-16 6:04 ` Nick Desaulniers
2021-04-16 18:47 ` Paul E. McKenney
2021-04-19 20:35 ` Nick Desaulniers
2021-04-19 21:37 ` Paul E. McKenney
2021-04-19 22:03 ` Miguel Ojeda
2021-04-16 20:48 ` Josh Triplett
2021-04-16 8:16 ` Michal Kubecek
2021-04-16 9:29 ` Willy Tarreau
2021-04-16 11:24 ` Peter Zijlstra
2021-04-16 13:07 ` Wedson Almeida Filho
2021-04-16 14:19 ` Peter Zijlstra
2021-04-16 15:04 ` Miguel Ojeda
2021-04-16 15:43 ` Peter Zijlstra
2021-04-16 16:21 ` Miguel Ojeda
2021-04-16 15:33 ` Wedson Almeida Filho
2021-04-16 16:14 ` Willy Tarreau
2021-04-16 17:10 ` Miguel Ojeda
2021-04-16 17:18 ` Peter Zijlstra
2021-04-16 18:08 ` Matthew Wilcox
2021-04-17 11:17 ` Peter Zijlstra
2021-04-17 11:46 ` Willy Tarreau
2021-04-17 14:24 ` Peter Zijlstra
2021-04-17 14:36 ` Willy Tarreau
2021-04-17 13:46 ` David Laight
2021-04-16 17:37 ` Willy Tarreau
2021-04-16 17:46 ` Connor Kuehl
2021-04-20 0:24 ` Nick Desaulniers
2021-04-20 3:47 ` Willy Tarreau
2021-04-20 5:56 ` Greg Kroah-Hartman
2021-04-20 6:16 ` Willy Tarreau
2021-04-29 15:38 ` peter enderborg
2021-04-17 13:53 ` Wedson Almeida Filho
2021-04-17 14:21 ` Willy Tarreau
2021-04-17 15:23 ` Miguel Ojeda
2021-04-18 15:51 ` Wedson Almeida Filho
2021-04-17 12:41 ` David Laight
2021-04-17 13:01 ` Wedson Almeida Filho
2021-04-16 15:03 ` Matthew Wilcox
2021-04-17 13:29 ` Wedson Almeida Filho
2021-04-16 15:58 ` Theodore Ts'o
2021-04-16 16:21 ` Wedson Almeida Filho
2021-04-17 15:11 ` Paolo Bonzini
2021-04-16 14:21 ` Miguel Ojeda
2021-04-17 20:42 ` Richard Weinberger
2021-04-28 18:34 ` Mariusz Ceier
2021-04-28 20:25 ` Nick Desaulniers
2021-04-28 21:21 ` David Laight
2021-04-29 11:14 ` Kajetan Puchalski
2021-04-29 11:25 ` Kajetan Puchalski
2021-04-29 14:06 ` Mariusz Ceier
2021-04-29 14:13 ` Sven Van Asbroeck
2021-04-29 14:26 ` Willy Tarreau
2021-04-29 15:06 ` Al Viro
2021-04-29 16:09 ` Mariusz Ceier
2021-04-30 6:39 ` Thomas Schoebel-Theuer [this message]
2021-04-30 8:30 ` David Laight
2021-05-05 13:58 ` Enrico Weigelt, metux IT consult
2021-05-05 14:41 ` Miguel Ojeda
2022-06-20 15:11 ` Olliver Schinagl
2022-06-27 17:44 ` Miguel Ojeda
2022-07-18 6:56 ` Olliver Schinagl
2022-07-20 19:23 ` Miguel Ojeda
2022-07-20 20:21 ` Nicolas Pitre
2022-07-27 7:47 ` Olliver Schinagl
2022-07-27 13:32 ` Nicolas Pitre
2022-07-27 8:05 ` Olliver Schinagl
2022-07-28 10:21 ` Gary Guo
2022-07-28 12:09 ` Greg Kroah-Hartman
2022-07-28 12:28 ` Gary Guo
2022-07-28 20:45 ` Olliver Schinagl
2022-07-29 8:04 ` Greg Kroah-Hartman
2022-07-28 20:43 ` Olliver Schinagl
2022-10-15 14:16 ` Olliver Schinagl
2022-10-16 1:44 ` Bagas Sanjaya
2022-10-16 1:50 ` Bagas Sanjaya
2022-10-16 13:23 ` Josh Triplett
2021-04-29 5:20 Mariusz Ceier
2021-04-29 5:21 Mariusz Ceier
2021-04-29 8:18 ` David Laight
2021-07-30 23:22 Dillan Jackson
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=7999ba57-9b95-265e-a189-d9ca01304b13@schoebel-theuer.de \
--to=tst@schoebel-theuer.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mceier+kernel@gmail.com \
--cc=mrkajetanp@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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: link
Be 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 NNTP newsgroup(s).