7 ms·

Probably a crazy unpopular opinion, but I kind of agree with the Hyperbola (GNU / formerly Linux-libre, in future using a fork of the OpenBSD kernel https://its

Probably a crazy unpopular opinion, but I kind of agree with the Hyperbola (GNU / formerly Linux-libre, in future using a fork of the OpenBSD kernel https://itsfoss.com/hyperbola-linux-bsd/ https://itsfoss.com/hyperbola-linux-bsd/) devs that Rust in Linux is not necessarily a good thing, for the reasons they mentioned when they announced they were switching kernels (https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/ https://www.hyperbola.info/news/announcing-hyperbolabsd-road...) (Edit: and the LLVM dependency).

TylerE 6y ago
I don’t see how that conplaint is at all meaningful to kernel development. It’s typical GNU/Pendantry. The kernel will not be shipping a rust compiler, patched or otherwise.
- boogies 6y ago
  The article mentions possible ABI compatibility challenges and I also think it’s not a good thing for a language in such critical applications to only have a single major implementation.
  - eptcyka 6y ago
    The linux kernel still can only be compiled with GCC. Of course, it's a single patch away from clang compatibility, but the kernel has never been compilable with much else but GCC.
    - pjmlp 6y ago
      Android and ChromeOS beg to differ, as Google has been using clang with them for at least around three years now.
      - eptcyka 6y ago
        Yes, clang compatibility is a single patch away. Google, unlike the vast majority of companies out there, is capable of maintaining it's own forks of the kernel.
jcranmer 6y ago
If I'm understanding correctly, the only reason for not using Rust is... Rust is trademarked?
- dijit 6y ago
  I'm generally in support of rust in the kernel, but in the interest of playing devils advocate: Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers? I can see why people would be opposed to that. I'm thinking about LLVM (and, obviously, rustc)
  - Silhouette 6y ago
    Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers? Like GCC? Your point is certainly valid, but I'm not sure it's a new problem.
  - JoshTriplett 6y ago
    Linux currently only compiles on GCC and Clang, and the latter is a recent development. rustc uses LLVM as a backend, just like Clang, and people are working on other backends. Linux maintainers didn't express any concerns about this being an issue.
  - danudey 6y ago
    The Linux kernel would only compile with GCC for... decades? I think? So it's not really a new thing. It would be really nice if the kernel did have first-class support for LLVM and Clang directly (rather than having to set a bunch of environment variables to set the compiler, the linker to use with that compiler, various variables, etc. That said, it would certainly be uncomfortable to move from "it compiles with Clang, though it's a pain, or GCC, which works fine" to "it compiles with GCC, if you don't use any of this functionality, or LLVM only, if you want any of these features or anything that depends on them".
    - JoshTriplett 6y ago
      Originally, we thought that Linux maintainers were asking us to only support kernels compiled with Clang, because they didn't want to support code built with two different compilers. However, in the session, Greg Kroah-Hartman specifically said that if it works to build Rust code with the LLVM-based rustc and C code with GCC and link the two together, and there aren't any problems in practice, then that's perfectly fine. So, we're currently expecting that supporting Rust will not place any requirements on the C compiler you use, unless you want to use cross-language LTO (which we'll eventually want to do, but it won't be a hard requirement for a working kernel).
badrabbit 6y ago
Maybe a GNU Rust compiler without the trademark is in order? The state of KSPP is not nice as well. I wish Ada was more popular. From what I know, it has much of the security guarantees rust has and it has been battle tested.
- guerrilla 6y ago
  I'm not sure, but aren't they saying that they wouldn't be able to call it "GNU Rust" [1] in the same way they can't call IceCat "GNU Firefox"? 1. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
  - homarp 6y ago
    well, plenty of names to play with:) GNR: Gnr Not Rust TRust: Treated Rust ...
    - gpm 6y ago
      How do you pronounce GNR? It think it needs to be a vowel, or an R. Some attempts: GRR: Gnu Renames Rust, GAR: Gnu assimilates rust, GER: Gnu non Est Rust (gnu is not rust, but in latin to get an E), GIR: Gnu Isn't Rust, GOR: Gnu Oxidizes Rust, GUR: Gnu Unseats Rust.
      - homarp 6y ago
        pronounces it Gnar or Gener, depending if you are a gif or a jif person. You can also go for GunsNRoses, but they won't like it and complain. Which might be good for visibility at the beginning.
    - el_oni 6y ago
      Or something like "oxide", ferrite, maGNUtite. Play with iron ores or compounds
      - 6y ago
JoshTriplett 6y ago
The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog posts for details), systemd is not spelled "SystemD", gettext has no dependency on Java (and the link in that post explains that). And in general, decisions about what technologies to use are made by those who show up and do the work to build viable solutions, not by people who snark. It's a rant by an obscure one-developer distribution that formerly used the Linux kernel. Some people are never happy no matter what you do, and if you make the mistake of treating their rants as useful feedback, you get a list of 30 more demands before they'd consider gracing your little project with the honor of their all-important usage again.
- ColanR 6y ago
  I think you were being "inaccurate and hyperbolic". > Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for) What they actually said in the article: > Historically, some features began as optional ones until they reached total functionality. Then they became forced and difficult to patch out. Even if this does not happen in the case of HDCP, we remain cautious about such implementations.
  - JoshTriplett 6y ago
    My comment was entirely based on the second link. Direct quote from that: > Linux kernel forcing adaption of DRM, including HDCP. (Which linked to a patch adding driver support for handling HDCP, with absolutely no possibility of it somehow being forced.) Regarding the quote from that interview: sure, and there's also no guarantee that the Linux kernel won't drop support for every architecture except SPARC, except of course for all the people involved not putting up with it. In what possible universe would Linux developers decide it was a good idea to mandate HDCP? It's completely unfounded and unsupported hyperbole and fearmongering, without even a hint of potential truth. It's also roughly consistent with what I'd expect from someone who thinks that gettext daring to have support for Java and C# format strings is a horrific problem that should be ripped out by the roots.
Macha 6y ago
The licensing complaints about Rust apply equally to Python, which they package without objection: https://www.hyperbola.info/packages/extra/x86_64/python/ https://www.hyperbola.info/packages/extra/x86_64/python/
- cylon13 6y ago
  Not exactly: [0] > Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No. We are not against all trademarks, only those which explicitly prohibit normal use, patching, and modification. > As an example, neither Python PSF nor Perl Trademarks currently prohibit patching the code without prior approval. They do prohibit abuse of their trademarks, e.g. you cannot create a company called “Python”, but this does not affect your ability to modify their free software and/or apply patches. > Due to the anti-modification clause, Rust is a non-permissive trademark that violates user freedom. [0] https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
  - Macha 6y ago
    Well, good luck calling your modified Python release Python: https://github.com/naftaliharris/tauthon/issues/47 https://github.com/naftaliharris/tauthon/issues/47
  - jcranmer 6y ago
    I suspect whomever wrote that hasn't actually read the trademark policies in detail, or conferred with lawyers about it. Neither Python's nor Perl's agreements explicitly cover the case in detail, but Perl does mention this: > Licensed redistributors of Perl code are permitted by their licenses to use the Perl logo in connection with their distribution services, on product packaging, and in promotional materials. IANAL, but that text would especially suggest to me that you would have no right to use the trademark even to distribute an unmodified binary of Perl without approval. I suspect the real reason is Debian and Mozilla had a very public, well-known spat over licensing, and Python and Perl have not had very public, well-known spats with anybody.
ArchOversight 6y ago
Once again the GPL camp takes and relicenses a project so that further improvements they make can't be used by the original authors. Shame really.
- boogies 6y ago
  They can be used by the original authors, if the original authors stop intentionally licensing their code so weakly that anyone can make changes that no one else can even see.
- JetSetWilly 6y ago
  If they didn't want people to be able to make changes that cannot be used upstream, there's a license for that. It's called the GPL.
bitwize 6y ago
I'd be more concerned about the fact that the Rust Evangelism Strike Force is hellbent on getting everybody to depend on their exhausts-all-32-bit-address-space-to-build compiler and toolchain -- in addition to whatever toolchain the project currently uses, at least as long as the strangler pattern is being applied to migrate the code base to 100% Rust. GNU software in particular has always been such that the core stuff is bootstrappable from just C. But it seems, from an RESF standpoint, that the fact that any C code is out there running at all is a crisis-level problem.
- JoshTriplett 6y ago
  Standing reminder: the Rust project is not a fan of rabid Rust over-evangelism (e.g. "Rewrite It In Rust", "Rust Evangelism Strike Force"), and sees it as damaging and unhelpful. We discourage that kind of thing wherever we see it. We're much more in favor of a measured, cautious approach.

TylerE 6y ago

I don’t see how that conplaint is at all meaningful to kernel development. It’s typical GNU/Pendantry. The kernel will not be shipping a rust compiler, patched or otherwise.

boogies 6y ago
The article mentions possible ABI compatibility challenges and I also think it’s not a good thing for a language in such critical applications to only have a single major implementation.
- eptcyka 6y ago
  The linux kernel still can only be compiled with GCC. Of course, it's a single patch away from clang compatibility, but the kernel has never been compilable with much else but GCC.
  - pjmlp 6y ago
    Android and ChromeOS beg to differ, as Google has been using clang with them for at least around three years now.
    - eptcyka 6y ago
      Yes, clang compatibility is a single patch away. Google, unlike the vast majority of companies out there, is capable of maintaining it's own forks of the kernel.

jcranmer 6y ago

If I'm understanding correctly, the only reason for not using Rust is... Rust is trademarked?

dijit 6y ago
I'm generally in support of rust in the kernel, but in the interest of playing devils advocate: Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers? I can see why people would be opposed to that. I'm thinking about LLVM (and, obviously, rustc)
- Silhouette 6y ago
  Would adding more and more dependence on rust mean that it ties the kernel to a single set of compilers? Like GCC? Your point is certainly valid, but I'm not sure it's a new problem.
- JoshTriplett 6y ago
  Linux currently only compiles on GCC and Clang, and the latter is a recent development. rustc uses LLVM as a backend, just like Clang, and people are working on other backends. Linux maintainers didn't express any concerns about this being an issue.
- danudey 6y ago
  The Linux kernel would only compile with GCC for... decades? I think? So it's not really a new thing. It would be really nice if the kernel did have first-class support for LLVM and Clang directly (rather than having to set a bunch of environment variables to set the compiler, the linker to use with that compiler, various variables, etc. That said, it would certainly be uncomfortable to move from "it compiles with Clang, though it's a pain, or GCC, which works fine" to "it compiles with GCC, if you don't use any of this functionality, or LLVM only, if you want any of these features or anything that depends on them".
  - JoshTriplett 6y ago
    Originally, we thought that Linux maintainers were asking us to only support kernels compiled with Clang, because they didn't want to support code built with two different compilers. However, in the session, Greg Kroah-Hartman specifically said that if it works to build Rust code with the LLVM-based rustc and C code with GCC and link the two together, and there aren't any problems in practice, then that's perfectly fine. So, we're currently expecting that supporting Rust will not place any requirements on the C compiler you use, unless you want to use cross-language LTO (which we'll eventually want to do, but it won't be a hard requirement for a working kernel).

badrabbit 6y ago

Maybe a GNU Rust compiler without the trademark is in order? The state of KSPP is not nice as well. I wish Ada was more popular. From what I know, it has much of the security guarantees rust has and it has been battle tested.

guerrilla 6y ago
I'm not sure, but aren't they saying that they wouldn't be able to call it "GNU Rust" [1] in the same way they can't call IceCat "GNU Firefox"? 1. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
- homarp 6y ago
  well, plenty of names to play with:) GNR: Gnr Not Rust TRust: Treated Rust ...
  - gpm 6y ago
    How do you pronounce GNR? It think it needs to be a vowel, or an R. Some attempts: GRR: Gnu Renames Rust, GAR: Gnu assimilates rust, GER: Gnu non Est Rust (gnu is not rust, but in latin to get an E), GIR: Gnu Isn't Rust, GOR: Gnu Oxidizes Rust, GUR: Gnu Unseats Rust.
    - homarp 6y ago
      pronounces it Gnar or Gener, depending if you are a gif or a jif person. You can also go for GunsNRoses, but they won't like it and complain. Which might be good for visibility at the beginning.
  - el_oni 6y ago
    Or something like "oxide", ferrite, maGNUtite. Play with iron ores or compounds
    - 6y ago

JoshTriplett 6y ago

The vast majority of the text in that post is inaccurate and hyperbolic. Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for), Rust does not require internet access to use (and the trademark comments are not particularly accurate either), the Kernel Self Protection Project is alive and well and making new improvements in every new version of the kernel (see Kees Cook's regular blog posts for details), systemd is not spelled "SystemD", gettext has no dependency on Java (and the link in that post explains that). And in general, decisions about what technologies to use are made by those who show up and do the work to build viable solutions, not by people who snark. It's a rant by an obscure one-developer distribution that formerly used the Linux kernel. Some people are never happy no matter what you do, and if you make the mistake of treating their rants as useful feedback, you get a list of 30 more demands before they'd consider gracing your little project with the honor of their all-important usage again.

ColanR 6y ago
I think you were being "inaccurate and hyperbolic". > Linux is not "forcing adoption of HDCP" (it's just something Linux has a driver for) What they actually said in the article: > Historically, some features began as optional ones until they reached total functionality. Then they became forced and difficult to patch out. Even if this does not happen in the case of HDCP, we remain cautious about such implementations.
- JoshTriplett 6y ago
  My comment was entirely based on the second link. Direct quote from that: > Linux kernel forcing adaption of DRM, including HDCP. (Which linked to a patch adding driver support for handling HDCP, with absolutely no possibility of it somehow being forced.) Regarding the quote from that interview: sure, and there's also no guarantee that the Linux kernel won't drop support for every architecture except SPARC, except of course for all the people involved not putting up with it. In what possible universe would Linux developers decide it was a good idea to mandate HDCP? It's completely unfounded and unsupported hyperbole and fearmongering, without even a hint of potential truth. It's also roughly consistent with what I'd expect from someone who thinks that gettext daring to have support for Java and C# format strings is a horrific problem that should be ripped out by the roots.

Macha 6y ago

The licensing complaints about Rust apply equally to Python, which they package without objection: https://www.hyperbola.info/packages/extra/x86_64/python/ https://www.hyperbola.info/packages/extra/x86_64/python/

cylon13 6y ago
Not exactly: [0] > Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No. We are not against all trademarks, only those which explicitly prohibit normal use, patching, and modification. > As an example, neither Python PSF nor Perl Trademarks currently prohibit patching the code without prior approval. They do prohibit abuse of their trademarks, e.g. you cannot create a company called “Python”, but this does not affect your ability to modify their free software and/or apply patches. > Due to the anti-modification clause, Rust is a non-permissive trademark that violates user freedom. [0] https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
- Macha 6y ago
  Well, good luck calling your modified Python release Python: https://github.com/naftaliharris/tauthon/issues/47 https://github.com/naftaliharris/tauthon/issues/47
- jcranmer 6y ago
  I suspect whomever wrote that hasn't actually read the trademark policies in detail, or conferred with lawyers about it. Neither Python's nor Perl's agreements explicitly cover the case in detail, but Perl does mention this: > Licensed redistributors of Perl code are permitted by their licenses to use the Perl logo in connection with their distribution services, on product packaging, and in promotional materials. IANAL, but that text would especially suggest to me that you would have no right to use the trademark even to distribute an unmodified binary of Perl without approval. I suspect the real reason is Debian and Mozilla had a very public, well-known spat over licensing, and Python and Perl have not had very public, well-known spats with anybody.

ArchOversight 6y ago

Once again the GPL camp takes and relicenses a project so that further improvements they make can't be used by the original authors. Shame really.

boogies 6y ago
They can be used by the original authors, if the original authors stop intentionally licensing their code so weakly that anyone can make changes that no one else can even see.
JetSetWilly 6y ago
If they didn't want people to be able to make changes that cannot be used upstream, there's a license for that. It's called the GPL.

bitwize 6y ago

I'd be more concerned about the fact that the Rust Evangelism Strike Force is hellbent on getting everybody to depend on their exhausts-all-32-bit-address-space-to-build compiler and toolchain -- in addition to whatever toolchain the project currently uses, at least as long as the strangler pattern is being applied to migrate the code base to 100% Rust. GNU software in particular has always been such that the core stuff is bootstrappable from just C. But it seems, from an RESF standpoint, that the fact that any C code is out there running at all is a crisis-level problem.

JoshTriplett 6y ago
Standing reminder: the Rust project is not a fan of rabid Rust over-evangelism (e.g. "Rewrite It In Rust", "Rust Evangelism Strike Force"), and sees it as damaging and unhelpful. We discourage that kind of thing wherever we see it. We're much more in favor of a measured, cautious approach.