Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 00/13] [RFC] Rust support
To:     Thomas Schoebel-Theuer <tst@schoebel-theuer.de>,
        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>
References: <20210414184604.23473-1-ojeda@kernel.org>
 <CAJTyqKP4Ud7aWxdCihfzeZ3dQe_5yeTAVnXcKDonciez-g2zWA@mail.gmail.com>
 <878s51e3jc.fsf@gmail.com>
 <7999ba57-9b95-265e-a189-d9ca01304b13@schoebel-theuer.de>
From:   "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Message-ID: <53413f58-269a-a1f6-2a97-e33819446609@metux.net>
Date:   Wed, 5 May 2021 15:58:43 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <7999ba57-9b95-265e-a189-d9ca01304b13@schoebel-theuer.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: tl
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 30.04.21 08:39, Thomas Schoebel-Theuer wrote:

Hi,

> 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).

ACK. And speaking for embedded world, 20+ product lifetime is pretty
common. During that lifetime you'd need to be able to pick out old
sources, so some changes and rebuild your code and having your system
still running seamlessly after the update. IOW: long-term
reproducability is absolutely vital. Linux does much better here than
many competitors (that eg. need proprietary build tools that don't
even run later machine generations)

> If the requirement "second source" (by either way) is not met by Rust at 
> the moment, this needs to be fixed first.

Yes, and also adding long-term reproducability as another vital requirement.

Rust seems to be a fast moving target. Even building a Rust compiler can
be a pretty complex task (if you're not a full time rust developer).

Gcc, in constrast, itself can be built on older compilers (even non-
gcc). How to do that w/ rustc ? According to my observations some while
ago, it needs a fairly recent rustc to compile recent rustc, so when
coming with an old version, one has to do a longer chain of rustc
builds first. Doesn't look exactly appealing for enterprise grade and
long term support.

> 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.

Correct, the amount of people who understand rust is pretty low, those
who also understand enough of linux kernel development, probably just
a hand full world wide. For any practical business use case this
practically means: unsupported.

I don't like the idea of Linux being catapulted back from enterprise
grade to academic toy.


--mtx
-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287