this post was submitted on 03 Sep 2024
434 points (97.4% liked)

Linux

48212 readers
2058 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

Linux people doing Linux things, it seems.

you are viewing a single comment's thread
view the rest of the comments
[–] r00ty@kbin.life 61 points 2 months ago (8 children)

Here's what I think. Both opinions are correct.

Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C in order to be working at the kernel level. It's not going to happen.

I don't really know too much about rust. Maybe one day I'll actually mess around with it. But the one time I looked at a rust git repo I couldn't even find where the code to do a thing was. It's just different enough to be problematic that way.

So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.

Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don't want to learn a new language in order to help isn't going to make many friends on that team.

[–] witx@lemmy.sdf.org 62 points 2 months ago* (last edited 2 months ago) (2 children)

But that's the thing where you are wrong. They clearly state they don't want C developers to learn Rust. In the particular video posted he was saying "I want you to explain to me how this particular API works so that I can do it"

The concerns about who fixes what on a merge when the C code breaks Rust code are valid, but that's easily fixed by gathering with the Rust developers, explaining the changes and letting them fix it.

[–] DemocratPostingSucks@lemm.ee 7 points 2 months ago (2 children)

You could alternatively phrase "But that's the thing where you are wrong" as "But here's the crux of why I disagree", it's a bit more personable

[–] areyouevenreal@lemm.ee 19 points 2 months ago (1 children)

This isn't a disagreement. One person is stating something incorrect. You can disagree on opinion, but facts are facts. The person being referred to here isn't asking others to learn Rust, they are just asking for more information about the already existing C code so that they can write their Rust code to interoperate with it. This misunderstanding is exactly why that developer was getting heckled on stage, and is the reason why now one has left the project. I would appreciate it if you didn't make a misunderstanding sound like a valid opinion. Enough damage has already been done.

[–] DemocratPostingSucks@lemm.ee -1 points 2 months ago (4 children)

It doesn't matter if you know it's a fact, and i agree with you for the record. It's about bringing people along with you - you catch more flies with honey than vinegar - and creating good vibes in the softwaresphere

[–] areyouevenreal@lemm.ee 10 points 2 months ago (1 children)

That to me sounds like exactly the reason why developers like the above have left. They are having to take on the burden of gently letting down other devs who are angry over a simple misunderstanding. A misunderstanding that wouldn't have happened if they had been listening or bothered to ask first before jumping to conclusions. Imagine someone heckles you on stage and you have to respond kindly. I certainly wouldn't. If someone had listened to my talk, misinterpreted it, then heckled me over it you can bet I would be angry and would respond in kind. To then see this misinformation being spread again would drive me nuts. I can see why they left.

The bottom line for me is that Rust devs who work on this stuff for free shouldn't be getting hounded by C devs just for asking for proper documentation that frankly they should have provided in the first place. I say this as someone who is skeptical of Rust for various reasons.

[–] ulterno@lemmy.kde.social 2 points 2 months ago* (last edited 2 months ago)

They are having to take on the burden of gently letting down other devs who are angry over a simple misunderstanding.

I feel like, if anyone would be happily willing to do that in their free time, they would have been a Politician or an HR and not a Developer.

I'm pretty n00b as a dev, but if I were to see someone misinterpreting my explanation, the most I would do is rephrase the same in a more understandable manner.
Definitely not going to resort to using "people management tactics", specially not in an Open Source Free Work setting, where the expectation is that the other person wants the good of the project as much as I do ^[as compared to a corporate setting, where if they are getting money to sit and do nothing, they will prefer that].

Facts are more important than feelings, specially when written text is the medium, where the reader can, at any time, go back and re-read to make sure they are at the same page, which a responsible, non-sleepy, non-drunk person would do in such a case.

On this note, I went and re-read the above comment and I realise, the "But that’s the thing where you are wrong." sentence is kinda useless. If the previous commenter were to have read the rest, they would realise that's where they were wrong. Mental note to not use useless stuff like this as the first sentence in a reply, because I probably have the habit


Yes, I know I joined both circumstances, this comment thread and the condition of the Rust Linux dev. It seemed relevant to me.

[–] Buddahriffic@lemmy.world 6 points 2 months ago

How to Win Friends and Influence People by Dale Carnegie should be required reading for everyone. It's full of things that are so obvious in hindsight but go against our natural instincts so we blunder through attempts to persuade not realizing that we might be increasing resistance rather than decreasing it.

Like the whole, "you might be right but you're still an asshole" thing. Being correct just isn't enough. In some cases you get crucified and then after some time has passed, the point you were trying to convince others of becomes the popular accepted fact. And they might even still hate you after coming around on the point you were trying to make.

That book won't turn you into a persuasive guru, but it will help avoid many of the pitfalls that make debates turn ugly or individuals stubborn.

Or, on the flip side, you can use the inverse of the lessons to become a more effective troll and learn how to act like you're arguing one thing while really trying to rile people up or convince them of the opposite. I say this not so much to suggest it but because knowing about this can make you less susceptible to it (and it's already a part of the Russian troll farm MO).

[–] itsprobablyfine@sh.itjust.works 5 points 2 months ago

Yup. Often best to use phrases like 'oh my understanding was x, am I missing something' or 'Wait I don't see how you're accounting for x, what am I missing?' or 'i looked at the source a few times and it seems to be indicating x, not y, am I misunderstanding the impact of z?'. Basically, people are much more willing to admit err when you are. If you start a 'debate' by recognizing you could be wrong you immediately soften the ground for both parties. Plus, everyone walks away feeling like 'we' won since we 'beat the problem' . Also, sometimes you actually are missing something and now when it's explained to you you don't feel like a jerk. Good vibe kinda shit

[–] Malfeasant@lemm.ee 3 points 2 months ago

Have you ever tried catching flies? Vinegar works better than honey, after all, flies eat shit.

[–] witx@lemmy.sdf.org 9 points 2 months ago

I see your point, but in this case I feel OP was misinterpreting the situation

[–] Giooschi@lemmy.world 22 points 2 months ago (1 children)

But the one time I looked at a rust git repo I couldn't even find where the code to do a thing was.

IMO that tells more about how the project was organized and names things than the language used.

So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.

As the other commenter pointed out, there's Redox. The issue is that this completly disregards an incremental approach: you have to rewrite everything before it comes usable, you can't do it piece by piece. Currently the approach of Rust for Linux is not even to rewrite things, but to allow writing new drivers in Rust.

Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don't want to learn a new language in order to help isn't going to make many friends on that team.

Have you seen the conference video? That's not just refusal to learn a new language, it's open hostility. And it's not the only instance, for example Asahi Lina also reported unreasonable behaviour by some maintainers just because she wrote Rust code, even when Rust was not involved.

[–] areyouevenreal@lemm.ee 8 points 2 months ago (1 children)

I think the point of redox is more than just rewriting Linux in Rust. Architecturally they are very different. Redox uses the more modern microkernel approach, whereas Linux is a modular monolith. There are advantages and disadvantages to both designs. They are actually polar opposites in fact. The compromise is something called a hybrid kernel which is used by Windows NT.

[–] Octorine@midwest.social 3 points 2 months ago (1 children)

This is true, but the differences go even further than that. Redox is intentionally non-posix-compliant. This means that userspace programs written for posix operating systems may or may not need patching to even compile.

Part of the philosophy of Redox is to follow the beaten path mostly, but not be afraid of exploring better ideas when appropriate.

[–] Croquette@sh.itjust.works 2 points 2 months ago (1 children)

What part of posix is redox trying to get away from?

[–] Octorine@midwest.social 2 points 2 months ago (1 children)

I'm not sure. I remember seeing an example in the docs, but I can't find it now. Actually the docs in general are a lot less opinionated than I remember them.

One thing that I did find is that the ion shell document mentions that it isn't a posix compliant shell because they would have had to leave out a bunch of features.

[–] Croquette@sh.itjust.works 1 points 2 months ago

Makes sense. Posix was created a long time ago and there are most probably some features that could be changed

[–] technotony@sh.itjust.works 15 points 2 months ago (3 children)

RedoxOS! There's been solid progress too, beyond just having a functional microkernel, they have many of the userspace tools/their version of coreutils, even a desktop environment already mostly implemented!

My understanding is that it shouldn't be too bad to port some other things over as well. The main issue I had was just the lack of drivers, especially since it's still tricky even on Linux, and the microkernel architecture (though more secure) also means there's no way to reuse any of those from Linux

[–] Overshoot2648@lemm.ee 5 points 2 months ago

They are actually looking into using the Linux Kernel for modular drivers in a really interesting way.

[–] jaypatelani@lemmy.ml 3 points 2 months ago (1 children)

Same with Ironclad kernel and OS written in Ada Programing language. Nice to see these systems development

[–] ulterno@lemmy.kde.social 1 points 2 months ago

Gives me vibes of a second iteration of the OS writing boom. Though this time, the kernel mostly.

[–] r00ty@kbin.life 1 points 2 months ago

I think this overall is a better idea. I'm going to say this because, I thought I'd look into rust today. So I installed it, setup vscode to work with it etc. And it's all up and running. I thought I would port over a "fairly simple" C# project I wrote recently as a bit of a test.

While I've generally had success (albeit with 30+ tabs open to solve questions I had about how to do certain things, and only making it about 20% into the task) I'm going to say that it's different enough from C, C++ and C# (all of which I can work with) that I really don't think it is fair to expect C developers that have day jobs and work on the kernel in their spare time to learn this. It's fundamentally different in my opinion.

Now, I don't condone any bad attitude and pushing away of rust developers from the project. But there's no way they're going to want to do anything to help which involves learning a new language. It's just not going to happen.

Likewise, C is not a language most new developers are learning. So, I feel like over time there won't be so much of an influx of new kernel developers and any Rust based kernel could find itself with more contributors over time and taking over as the de-facto kernel.

In terms of Redox (not looked into it yet). So long as there's a different team working on the userspace tools. I would say the main task should be getting a solid kernel with drivers for most popular hardware etc in place. The existing GNU tools will do until there's a kernel that is able to compete with the C one. But that's just my opinion.

[–] KingThrillgore@lemmy.ml 14 points 2 months ago* (last edited 2 months ago) (1 children)

Good news there's a project that aims to implement Unix in Rust called Redox and it's already a good enough project for studying microkernel design

[–] OsrsNeedsF2P@lemmy.ml 10 points 2 months ago (1 children)
[–] KingThrillgore@lemmy.ml 5 points 2 months ago (1 children)
[–] barryamelton@lemmy.ml 4 points 2 months ago* (last edited 2 months ago) (1 children)

Not even, it will suffocate on its own by having the capitalists keeping their changes from each other. Like a bucket of crabs; where if one crab is about to get free the others grab onto it and pull it down.

Kernels really benefit from being "forced" to share the code changes as the GPL license, they are too tied to HW, and HW needs a lot of capital when iterating.

[–] TheHarpyEagle@pawb.social 3 points 2 months ago

Permissive licenses mean faster and more widespread adoption, it's up to project maintainers if the tradeoff is worth it. Ideally a company would realize that an open source part of their project probably isn't radically going to affect their revenue stream, but you don't just have to convince devs, you have to convince the suits and lawyers, and they will tell you to just build your own rather than give up any precious IP.

[–] vga@sopuli.xyz 10 points 2 months ago* (last edited 2 months ago)

Yeah, the Rust guys' proposition is roughly this:

Hey you guys with 20-30 years of experience doing a single thing very well. Let's nullify most of that skillset and replace it with a thing we're good at.

Don't worry, we will teach you.

They're not technically wrong about Rust being a better choice for a kernel, of course. They're just incredibly misinformed about the social hurdles they need to climb over for it to happen.

[–] Anti_Face_Weapon@lemmy.world 8 points 2 months ago (1 children)

Honestly, if anyone has become a master in C, they can become a rust master in short order. It's different, but not THAT different. The roots are the same.

[–] vga@sopuli.xyz 3 points 2 months ago* (last edited 2 months ago) (1 children)

I don't know. Rust seems like a better C++ to me rather than a better C. Plain C is a very simple language.

[–] Anti_Face_Weapon@lemmy.world 2 points 2 months ago

That's fair, but my point still stands.

[–] pathief@lemmy.world 2 points 2 months ago

Just go ahead and write a very basic working kernel in rust.

I don't get this stance, really. If I want to write a driver in Rust I should start by creating a completely new Kernel and see if it gains momentum? The idea of allowing Rust in kernel drivers is to attract new blood to the project, not to intentionally divert it to a dummy project.

Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C

If you watch the video, no one asked anything from the C developers other than documentation. They just want to know how to correctly make the Rust bindings.

Note that Rust is not replacing C code in the Kernel, just an added option to writing drivers.