Re: [PATCH 00/13] [RFC] Rust support

From: Thomas Schoebel-Theuer
Date: Fri Apr 30 2021 - 02:39:47 EST


On 29/04/2021 13:25, Kajetan Puchalski wrote:

Mariusz Ceier <mceier+kernel@xxxxxxxxx> 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