It is great to have a modern and safer language for kernel development… But additional dependencies and increased complexity of the toolchain is the price we pay for these improvements.
The way to easily obtain that dependency is to throw in the towel, drop the distributor’s toolchain, and install everything from the Rust repositories instead. The “getting started” page describes how to do this; inevitably, it involves one of those confidence-building “curl|bash” operations. The installer is entirely uninterested in where one might like one’s Rust stuff installed (it goes into ~/.cargo) and silently modifies the user’s Bash startup scripts to add the new directory into the PATH variable. The end result does work, though, and makes it easy to install the needed dependencies.
I just hope that it will become sufficiently mature, deterministic and reproducible… before the whole world starts depending on it.
Part of this depends on distributions as well. Rust is pretty insistent on “a new compiler very six weeks, and only the latest compiler is supported” model, which has benefits and drawbacks, but, most importantly, is completely at odds with how traditional distributions work.
I understand and share the old-school sentiment of “do not mess with my home directory and PATH!”. I agree with “deterministic and reproducible” part as an ideal (hardly achieved by any other language, regardless of its maturity).
On the other hand, the Cargo way does make sense in the modern world of cloud/virtual/CI environments. Many developers choose to develop on a beefy and rather temporary cloud instances nowadays. Doing sysadmins tasks in these kinds of environments does not make much sense.
A language ecosystem also wins by not being tied to whims of specific distros and their ways and throughput to package. LWN publishes about an article per month describing struggles of a distro X to keep up with packaging language Y libraries. As an example of a whimsical decision: I was very surprised to learn that Fedora packages a lot of Rust libraries, but not executables (that I actually wanted to install!).
Linux kernel source code will use vendored libraries anyway. I hope that Cargo interop with external build systems like Bazel/Linux kernel build system/etc is getting better.
The rule for a number of years now is that the last release of the year is an LTS release. So yes, 6.1 will get support for at least two years; longer than that depends on the level of interest.
It is great to have a modern and safer language for kernel development… But additional dependencies and increased complexity of the toolchain is the price we pay for these improvements.
I just hope that it will become sufficiently mature, deterministic and reproducible… before the whole world starts depending on it.
Part of this depends on distributions as well. Rust is pretty insistent on “a new compiler very six weeks, and only the latest compiler is supported” model, which has benefits and drawbacks, but, most importantly, is completely at odds with how traditional distributions work.
I understand and share the old-school sentiment of “do not mess with my home directory and PATH!”. I agree with “deterministic and reproducible” part as an ideal (hardly achieved by any other language, regardless of its maturity).
On the other hand, the Cargo way does make sense in the modern world of cloud/virtual/CI environments. Many developers choose to develop on a beefy and rather temporary cloud instances nowadays. Doing sysadmins tasks in these kinds of environments does not make much sense.
A language ecosystem also wins by not being tied to whims of specific distros and their ways and throughput to package. LWN publishes about an article per month describing struggles of a distro X to keep up with packaging language Y libraries. As an example of a whimsical decision: I was very surprised to learn that Fedora packages a lot of Rust libraries, but not executables (that I actually wanted to install!).
Linux kernel source code will use vendored libraries anyway. I hope that Cargo interop with external build systems like Bazel/Linux kernel build system/etc is getting better.
Has GKH announced whether this one will be LTS? Google isn’t coming up with anything concrete.
The rule for a number of years now is that the last release of the year is an LTS release. So yes, 6.1 will get support for at least two years; longer than that depends on the level of interest.