Live data from Hacker News

Supporting Linux kernel development in Rust

lwn.net

11–20 of 365 posts

Re: Supporting Linux kernel development in Rust

#11
post #5
post #2

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/ ) 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-road... ) (Edit: and the LLVM depe…

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

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)

Re: Supporting Linux kernel development in Rust

#12
post #5
post #2

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/ ) 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-road... ) (Edit: and the LLVM depe…

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

Mozilla’s trademark policies have been annoying enough in the past that Debian used to ship a fork with the branding stripped. Hyperbola continued this practice for a while, but stopped for a variety of reasons in the It’s Foss interview, and switched to a UXP-based browser. I’m writing this from a UXP-based browser because I find it much better than Firefox and I dislike Mozilla in general for more than one reason.

But no, there are other reasons outside of trademarks, some technical ones are in submisson’s article.

Re: Supporting Linux kernel development in Rust

#13
post #3

Looks like there is a lot of work involved to have anything done, remind me the issues that the Chrome team said 2 weeks ago.

Can you elaborate re: issues and lots of work required? I think it's generally to be expected that non-C language support in the kernel would be hard...

Re: Supporting Linux kernel development in Rust

#14

One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers and the features the existing kernel exports to userland in the form of syscalls. Would it be possible for a hypothetical new kernel, presumably written in Rust, to run an existing kernel such as Linux in a VM, just to tap into its drivers and emulate its syscalls? As more drivers are ported to the b…

This conference talk considered a re-write out-of-scope; they were only discussing how new code could be written in Rust.

Interesting idea, though!

Re: Supporting Linux kernel development in Rust

#15
post #2

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/ ) 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-road... ) (Edit: and the LLVM depe…

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.

Re: Supporting Linux kernel development in Rust

#16
post #2

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/ ) 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-road... ) (Edit: and the LLVM depe…

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

Re: Supporting Linux kernel development in Rust

#17
post #5
post #2

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/ ) 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-road... ) (Edit: and the LLVM depe…

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

Wait till we tell them that Linux is a trademark of Linus Torvalds.

Re: Supporting Linux kernel development in Rust

#18
post #16
post #2

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/ ) 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-road... ) (Edit: and the LLVM depe…

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

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

Re: Supporting Linux kernel development in Rust

#19
post #2

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/ ) 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-road... ) (Edit: and the LLVM depe…

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.

Re: Supporting Linux kernel development in Rust

#20
post #11
post #5

Earlier quoted context omitted.

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

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)

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.

Post reply on HN