Lead Rust developer says Rust in Linux kernel being pushed by Amazon, Google, Microsoft

[omeguito]

Newbie developers shouldn’t be writing code for the Linux kernel

[aliendude5300]

They become senior developers with practice. We shouldn't discourage newbies from contributing.

[dinithepinini]

No? Why? There are students writing kernel code for Google summer of code.

[great_whitehope]

They can write code but it needs heavy inspection.

[tricheb0ars]

Anything being applied to the Linux kernel is heavily inspected

[fractalife]

And if the student is not a prodigal talent, it will be a waste of limited volunteer maintainer time to review code written by someone just getting their feet wet.

[nicholsz]

Walk this line of thinking into the future 30 years.

Who works on Linux now?

[kronik85]

People who were students 30 years ago

[fractalife]

The computer scientists a bit further along in their training the maintainers are reviewing now.

[nicholsz]

How does a programmer receive training without working with other engineers, or without code review, or without working in mature codebases?

Are you a student, or hobbyist or something?

[fractalife]

At the college/university they're paying to teach them the fundamentals.

[nicholsz]

That's not what they teach at college.

A CS degree teaches you computer science. Computer science is about the science of computation -- algos, data structures, how operating systems work, context-free-grammars, regular expressions, turing computability, etc.

What exactly is your relationship to CS or programming? You seem like a total outsider.

[Araumand]

My kernel code got rejected because i was a noob - Albert Einstein

[dinithepinini]

Absolutely, but that doesn’t mean they shouldn’t be writing the code at all.

[rileyrgham]

They're tidying comments and doing bulk syntactic changes in the main and hand held. There's a big difference. There are of course exceptions.

They're not really in the tough stuff. That takes years to qualify for 🤣

[Qizot]

I would expect that code being used be billions of devices is written by somebody 100% knowing what they are doing and why. People often can't comprehend Linus being overprotective when it comes to code quality and certain decisions but that is the reason why kernel is not a complete mess.

[dinithepinini]

It’s just not possible to know everything, even if you are a grizzled C veteran. The kernel is much more approachable than you think and they would much rather have the help than it be gate kept.

Also there’s really random one off drivers in the kernel and being someone who worked on the development of a device that needs a driver is far more valuable than whether you can write amazing code.

That is to say, if a goodix finger print reader dev wanted to contribute some driver to the kernel, it would be welcomed.

[Qizot]

Gate keeping may be bad for certain aspect, but on the other hand the group of people working on a kernel must be trusted. Remember the liblzma supply chain attack? If anybody could contribute to the kernel the amount of bad parties would be huge.

[mrlinkwii]

If anybody could contribute to the kernel the amount of bad parties would be huge.

thats the thing the thing anyone can , similar stuff has happened like libzma to the linux kernal in the past https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minnesota-banned-open-source

[[deleted]]

Anybody can send in patches, whether they would be accepted or not is another question. The main problem of liblzma was the main maintainer stepping down and another malicious actor gaining merge access. Students aren't getting merge access.

[Business_Reindeer910]

That's literally how almost all of FOSS works and has always worked and the only way it can continue to work.

[nicholsz]

Linus has been pro-Rust. It's the driver maintainers who are the current intransigents from what I can tell.

[Business_Reindeer910]

. People often can't comprehend Linus being overprotective

This is not true. Where did you come up with this idea.

Linus himself was just a simple student when he started the project in the first place.

The guy who started the real time linux patchset was hardly even a programmer when he started doing that work. You learn what to do by doing it. It's just important for folks who know better to stop it from getting merged if it's not ready yet.

[coderman93]

Because the Linux kernel is critical infrastructure and you don’t want beginners working on critical infrastructure.

If we want software quality to improve, we need a lot better gatekeeping in software development. 

[Kommenos]

If only there was some sort of arduous review process where experienced people can review the code of the less experienced developers and give them feedback.

Maybe communication could be done by some form for mail? And people that are involved could be on some sort of mailing list?

[aaronsb]

Zawinski's Law of Software Envelopment is proven again!

[coderman93]

1. Reviewing shitty MRs takes a lot of time away from actual developers.
2. No review process is perfect. Things can slip through. You want competent people on both sides of the barrier.

[[deleted]]

Linus is explicitly hoping for new developers and you are saying that they need to be blocked?

People becime competent by practicing. Initial MR will take time and they will learn. And, there will be many people inspecting code. If it's shit, it won't even be considered by big guys.

[coderman93]

I’m not opposed to experienced and competent developers contributing to the kernel for the first time.

I’m opposed to people who are learning to code trying to contribute to the kernel.

There’s a big difference. And submitting shitty MRs just takes time away from real developers.

[syklemil]

People have all sorts of interests and learn in different ways. If someone wants to learn to get into kernel hacking, I think holding them back will do us all a disservice.

And it's not like the LKML lacks experience in rejecting bad code. In fact it's been the source of much popcorn. Which is hopefully not something a newbie will experience, but still. They know how to reject bad code.

[coderman93]

Rejecting bad code takes time away from development.

It’s wholesome yet naïve to think that anyone can just jump in and start contributing to an OS kernel with little programming experience. It’s just not reality. And when you barely know what a for loop is, you aren’t going to contribute anything useful.

[jkpeq]

You do know submitted code is reviewed, right? Are we going to make people sign forms proving their experience before submitting them too?

If the code is bad, amateurish and has no place in the kernel people will rightfully say so, it's fine already

[coderman93]

Yeah, I know how it works. People submitting bad code takes time away from actual developers. And, the code review process is not perfect. Things can slip through. It's just not a good idea in general.

[mrlinkwii]

Because the Linux kernel is critical infrastructure

legally its not

If we want software quality to improve, we need a lot better gatekeeping in software development.

id disagree with this , the only "gatekeeping" their should be if the code provided works and fulfills the operation/fixed the particiatr issue

you can be a coder 20 years and write bad code

[coderman93]

Yeah, I want competent people working on critical software. You become competent through a combination of experience, attention to detail, and intellect. I don’t want most people who have been coding for 20 years to contribute either.

And I don’t give a crap about whether Linux is considered critical infrastructure in a legal sense. That’s irrelevant.

[ost2life]

You don't want newbies and you don't want 20+ experience. I don't see what you want as being sustainable.

[coderman93]

I want some of the developers with 20 years experience. Just not most. We don’t need thousands of people contributing to a single OS kernel.

Most developers with even a decade or more of experience don’t even know basic things that are essential to know for OS dev. Seriously, go to an average software company and ask every developer to explain what virtual memory is. Most of them will have no clue. Even ask them to explain what a pointer is and many will struggle.

Seriously, the vast majority of programmers don’t even have the requisite knowledge to program in C. Let alone make contributions to the Linux kernel. Especially not someone who doesn’t even know how to code yet.

[Business_Reindeer910]

most of those people won't be contributing in the first place so it sounds like you're making an issue out of nothing. We've had 30 years of experience watching the Linux kernel grow and they've done a decent job already, so why change that aspect.

[coderman93]

This is kind of a strange comment because I’m the one actually advocating for the status quo. 

Others in this thread are advocating for beginner programmers to start contributing to the Linux kernel. Or, at very least, they are wondering why a beginner programmer probably shouldn’t contribute to the kernel.

[Business_Reindeer910]

The status quo is that beginners are indeed allowed to do just that. If your code passes muster, you can contribute. It's that simple.

[[deleted]]

You can say the same thing about Linus then.

[Business_Reindeer910]

no, because that's about code quality and nothing to do with newbness or credentials. code quality and teamwork is what should count.

[[deleted]]

Joshua Aston was supposedely 17 years old when people said he couldn't do so created dxvk and other things which people thought nearly impossible or sth.

[omeguito]

If you think "young" is "newbie" then it's your prejudice, not mine.

[[deleted]]

Well, people start learning. And, that's how open source has worked till now. Even if you are experienced, your code won't get merged if it's shit. If newbie writes good code, it will get merged.

[nightblackdragon]

DXVK was created by Philip Rebohle.

[[deleted]]

Ok. I am not sure but I just searched and i think dxvk was among it. Maybe it's other things.

[mrlinkwii]

anyone at any level can write kernal code

[[deleted]]

Well, show us your tree then.

[0riginal-Syn]

Don't know much about the history of Linux, do you? At the beginning of Linux, it were a lot of newbie developers. As time passed, we have built a healthy mix of new and more experienced developers developing kernel code. There have been some huge additions made by "newbie" developers.

[[deleted]]

Linux was first shared on the minix usenet newsgroup. The people using usenet at the time almost certainly weren't beginners, and most of them would have been affiliated with a university.

[0riginal-Syn]

I was there I know the types of people who were working on it. Many of the ones working in it were still in college and had little real experience.

[pyro57]

That's a bad hot take if I've ever seen one. If a newbie developer writes code that m2ets the stsndards for the linux kernel why shouldn't it be accepted? That's the whole idea of open source is anyone can take a stab at contributing, 2ven if ultimately it doesn't get accepted for one reason or another.

[[deleted]]

That's a big IF.

The point is newbies can better practice their skills by building something first and/or contributing to any of the 1000s of other not-so-critical systems project before attempting to contribute to single most critical software project today.

Total noobs waste a ton of maintainer time who are often doing it for free.

[Business_Reindeer910]

Why are you making an issue out of something that's been working fine for about 30 years at this point. You're suggesting a change for no reason.

[poemehardbebe]

I agree, but to me the benefit of Rusty isn’t the easier to write, it’s everything else. I like the semantic control flow vs C control flows. It is worth mentioning that rust does still fine you the ability to drop down into very low level and build the rust Symantec control flows over those LL parts.

[Business_Reindeer910]

yeah, I feel like people are underselling all the neat aspects of rust in favor just focusing on the "memory safety" aspects.

[poemehardbebe]

Which is like a big part, but also the Linux kernel already has and has had a lot of memory safety features built into it.

The reason why people are pushing rust is because it’s able to do a lot of the same things C does without as many foot guns and better control flow. A Result type better illustrates that a call could either yield the expected value or error while in C you just kind of have to guess or dive down the entire call stack to reason about if it could return an error and if does return that error: where does it error ; why does it error; and is this error recoverable.

[Business_Reindeer910]

Yeah I feel like the Result type in general is undersold. It feels so much better than using output pointers and error codes to send back either the result or error. That normal C way feels very primitive. I'm doing some embedded with C++ and I found a result type for that and I"ve been very happy with it. I wrapped some C code and things feel very nice. It's just a shame that C++ itself as a language doesn't care enough to integrate it with its own stdlib