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@xxxxxxxxx -- +49-151-27565287
