3 ms·

> I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness). So what h

> I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness). So what happens to users that depend on these archs & drivers - get left behind on the last non-Rust kernel?

steveklabnik 5y ago
The same as any other project that decides it may drop support: either stick on an old version, or work to add support for the platforms you care about. Rust's lack of platform support isn't because it is impossible for Rust to gain support for those platforms, but because users of those platforms haven't added support yet. Obviously that is easier said than done, and I doubt that Linux would make a decision like this, but the options are pretty straightforward if they did.
tinco 5y ago
Yes, why not? Must it absolutely be so that a 20 year old Macbook can run the latest kernel? One that isn't even released yet, it's just in the preliminary planning phase? It's not even like new software wouldn't run on it. Most software runs fine on 10 year old linux kernels. Also, by calling them 'users' you're anthropomorphising, who are these actual real human beings being "left behind"? edit: ok so it sounds a bit mean if you interpret it as if I'm not considering UnkleJoe to be a real human being. What I mean is, I don't think UnkleJoe is trying to get new devices to talk to his prehistoric PPC embedded system just for fun. An organisation is maintaining these systems, and that organisation is mooching off of Linux's excellent backwards compatibility. What's the economical cost of supporting that organisation, versus the economical costs of not implementing ksmbd in Rust?
- sangnoir 5y ago
  > Yes, why not? Security updates for one. People are always complaining about insecure IoT devices/routers that get conscripted into botnets. Dropping kernel support entirely compounds to manufacturer firmware negligence - meaning end users can't update to the latest Lineage/DD-WRT/OpenWRT firmware, even if they want to. > Most software runs fine on 10 year old linux kernels. If you had to wrangle with world of custom Android ROMs or open source router firmware - even as a user and not a developer - you know that software does not work fine on old kernels. Trying to support both old and new kernels is a royal pain, especially if you have add shims to support old kernels that lack new features. I thank $DIETY for Linus' pragmatic approach, I trust him to balance user support against developer zealotry. I wonder how long it'll take for Linux to go to shit after he retires. Kernel notes for v42.3: dropped support for Risc-V. Remaining supported archs are x64 and ARMv21-24
  - Thiez 5y ago
    > Security updates for one. I thought we were talking about new drivers being developed in Rust. Your IoT security upgrade probably doesn't include a hardware upgrade, so it will not require these new drivers. Regardless, it is the responsibility of the device manufacturer to support their old devices. It is their problem, hold them accountable.
    - sangnoir 5y ago
      > I thought we were talking about new drivers being developed in Rust The discussion moved to what happens to drivers that are not ported to Rust, and GP was arguing they should be abandoned/dropped - as opposed to requiring that all driver's be switched over to Rust first. > It is their problem, hold them accountable How can they be held accountable, pragmatically? Also, owning a CVE-riddled, insecure device is actually the user's problem. Open firmware can at least ameliorate the situation right now: where manufacturers cant be bothered to publish/upstream/update their drivers to the latest kernel API in the same language. Asking them to rewrite drivers in Rust and upstream is obviously a tall order - barring the passing of new legislation.

steveklabnik 5y ago

The same as any other project that decides it may drop support: either stick on an old version, or work to add support for the platforms you care about. Rust's lack of platform support isn't because it is impossible for Rust to gain support for those platforms, but because users of those platforms haven't added support yet. Obviously that is easier said than done, and I doubt that Linux would make a decision like this, but the options are pretty straightforward if they did.

tinco 5y ago

Yes, why not? Must it absolutely be so that a 20 year old Macbook can run the latest kernel? One that isn't even released yet, it's just in the preliminary planning phase? It's not even like new software wouldn't run on it. Most software runs fine on 10 year old linux kernels. Also, by calling them 'users' you're anthropomorphising, who are these actual real human beings being "left behind"? edit: ok so it sounds a bit mean if you interpret it as if I'm not considering UnkleJoe to be a real human being. What I mean is, I don't think UnkleJoe is trying to get new devices to talk to his prehistoric PPC embedded system just for fun. An organisation is maintaining these systems, and that organisation is mooching off of Linux's excellent backwards compatibility. What's the economical cost of supporting that organisation, versus the economical costs of not implementing ksmbd in Rust?

sangnoir 5y ago
> Yes, why not? Security updates for one. People are always complaining about insecure IoT devices/routers that get conscripted into botnets. Dropping kernel support entirely compounds to manufacturer firmware negligence - meaning end users can't update to the latest Lineage/DD-WRT/OpenWRT firmware, even if they want to. > Most software runs fine on 10 year old linux kernels. If you had to wrangle with world of custom Android ROMs or open source router firmware - even as a user and not a developer - you know that software does not work fine on old kernels. Trying to support both old and new kernels is a royal pain, especially if you have add shims to support old kernels that lack new features. I thank $DIETY for Linus' pragmatic approach, I trust him to balance user support against developer zealotry. I wonder how long it'll take for Linux to go to shit after he retires. Kernel notes for v42.3: dropped support for Risc-V. Remaining supported archs are x64 and ARMv21-24
- Thiez 5y ago
  > Security updates for one. I thought we were talking about new drivers being developed in Rust. Your IoT security upgrade probably doesn't include a hardware upgrade, so it will not require these new drivers. Regardless, it is the responsibility of the device manufacturer to support their old devices. It is their problem, hold them accountable.
  - sangnoir 5y ago
    > I thought we were talking about new drivers being developed in Rust The discussion moved to what happens to drivers that are not ported to Rust, and GP was arguing they should be abandoned/dropped - as opposed to requiring that all driver's be switched over to Rust first. > It is their problem, hold them accountable How can they be held accountable, pragmatically? Also, owning a CVE-riddled, insecure device is actually the user's problem. Open firmware can at least ameliorate the situation right now: where manufacturers cant be bothered to publish/upstream/update their drivers to the latest kernel API in the same language. Asking them to rewrite drivers in Rust and upstream is obviously a tall order - barring the passing of new legislation.