this post was submitted on 03 Sep 2024
430 points (97.4% liked)
Linux
48328 readers
632 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
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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
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.
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
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.
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.
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).
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
Have you ever tried catching flies? Vinegar works better than honey, after all, flies eat shit.
I see your point, but in this case I feel OP was misinterpreting the situation
I've inserted myself into your C project because only idiots write C. Rust is the one true god, mUh MeMoRy sAfteY! Now please explain to me how C works.
LMAO
That's not what they're asking. It's not about how C works, it's about how specific APIs written in C work, which is hard to figure out on your own for anyone who is not familiar with that specific code. You'll have to explain that to any developer coming new into the project expected to work with those APIs, no matter their experience with C.