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
