Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hector Martin – [Patch] Maintainers: Remove Myself

lkml.org

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#31

Post by menaerus »

steveklabnik wrote: post #24
menaerus wrote: post #22

Earlier quoted context omitted.

It has certainly not been made simply because of the fact that Linus is not a boss to the people who are contributing or maintaining the code. There was however a decision to have Rust as an experiment in the kernel but not such that it will bend and change the rules and put a technical burden on everyone else. This issue is solely a technical burden and not a good guy vs bad guy, as many Rust developers would like i…

Linus is not a boss, that's correct, but he is the BDFL. He doesn't always choose to make every decision himself, but the decision to allow Rust in the tree was made by him. > not such that it will bend and change the rules and put a technical burden on everyone else. Absolutely. That is very important. We are in agreement here. > This issue is solely a technical burden Here are the entirety of the arguments made: "N…

So do you disagree with the fact that merging and testing the code will be much more difficult or you simply choose to ignore it for the sakes of idealogical wars?

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#32

Post by steveklabnik »

menaerus wrote: post #31
steveklabnik wrote: post #24

Earlier quoted context omitted.

Linus is not a boss, that's correct, but he is the BDFL. He doesn't always choose to make every decision himself, but the decision to allow Rust in the tree was made by him. > not such that it will bend and change the rules and put a technical burden on everyone else. Absolutely. That is very important. We are in agreement here. > This issue is solely a technical burden Here are the entirety of the arguments made: "N…

So do you disagree with the fact that merging and testing the code will be much more difficult or you simply choose to ignore it for the sakes of idealogical wars?

I think that statement is too broad to be useful. To make a decision like this, you need to actually argue the real pros and cons of doing so, rather than just saying "it's much more difficult."

All of this was brought up and discussed thoroughly when the experiment was greenlit, and any difficulties created by including Rust, "much more" or no, was deemed an acceptable tradeoff for the benefits of doing so. That's engineering.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#33

Post by steveklabnik »

uecker wrote: post #30
steveklabnik wrote: post #27

Earlier quoted context omitted.

> (to the extend this is the case, I haven't checked) It's not his area. > Also the patch adds a file kernel/dma.rs so I am confused about your comment. It adds rust/kernel/dma.rs, not kernel/dma. That is, it adds that file here: https://github.com/torvalds/linux/tree/master/rust/kernel not here: https://github.com/torvalds/linux/tree/master/kernel/dma

If it is not his area, he should have no power to stop it anyway, so it is even more strange to call it "sabotage". Or has any kernel developer the right to nack anything? This seems unlikely to me. So then it is just some disagreement.

You have to remember that Linux development isn't done like most open source projects where there's one upstream tree everyone sends patches to. Linus pulls in whatever code he wants. A nack means that Hellwig won't pull it into his tree, but that doesn't mean it can't go in someone else's, and end up upstream anyway. The only reason he was even cc'd on the patch is because he's the relevant subsystem maintainer being wrapped, as a courtesy.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#34

Post by uecker »

steveklabnik wrote: post #33
uecker wrote: post #30

Earlier quoted context omitted.

If it is not his area, he should have no power to stop it anyway, so it is even more strange to call it "sabotage". Or has any kernel developer the right to nack anything? This seems unlikely to me. So then it is just some disagreement.

You have to remember that Linux development isn't done like most open source projects where there's one upstream tree everyone sends patches to. Linus pulls in whatever code he wants. A nack means that Hellwig won't pull it into his tree, but that doesn't mean it can't go in someone else's, and end up upstream anyway. The only reason he was even cc'd on the patch is because he's the relevant subsystem maintainer bein…

As I said, the idea that this is then "sabotage" is completely ridiculous and just shows how toxic this maintainer was that now removed himself.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#35

Post by vsgherzi »

uecker wrote: post #29
vsgherzi wrote: post #18

Earlier quoted context omitted.

I agree that memory safety gets over-hyped and is often treated like a silver bullet solution. However, I do believe the problems of memory unsafely to be real and to be a threat (just less than what the popular opinion is). We've tried using static analyzers and C and AI driven detection to limited success, we cannot guarantee correct C code, this is just a hard problem when a project as big and important as the ker…

There are definitely people using static analysis to write memory safe C. This is not really practical though, but getting a reasonable level of memory safety is very much possible using tools and good design. People dismiss this because it is not perfect, but this completely fails to take into account that - in practice - Rust is also far from being memory safe due to use of unsafe. Whether it was proposed by Linus…

Rust is memory safe by every definition. Unsafe is an escape hatch that is only used when safe won’t work and assumptions can be made by the programmer. This is a needed solution and does not take away from rust as a safe language.

To me Linus is the leader so if he wants to try it we should try it. If he wants it gone then it should be removed all the same. Linus did not include rust for something like a programming paradigm it’s for the safety of the kernel and hope to attract more younger contributors.

The kernel will eventually need to evolve and I think this experiments are extremely important to prevent the kernel from turning irrelevant.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#36

Post by menaerus »

steveklabnik wrote: post #32
menaerus wrote: post #31

Earlier quoted context omitted.

So do you disagree with the fact that merging and testing the code will be much more difficult or you simply choose to ignore it for the sakes of idealogical wars?

I think that statement is too broad to be useful. To make a decision like this, you need to actually argue the real pros and cons of doing so, rather than just saying "it's much more difficult." All of this was brought up and discussed thoroughly when the experiment was greenlit, and any difficulties created by including Rust, "much more" or no, was deemed an acceptable tradeoff for the benefits of doing so. That's e…

Sure, engineering is all about the tradeoffs, there's no black and white.

So, what is an advantage of mixing two different languages over one kernel module, in this example DMA? What problem does introducing another language solve and what would be the alternatives?

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#37

Post by steveklabnik »

menaerus wrote: post #36
steveklabnik wrote: post #32

Earlier quoted context omitted.

I think that statement is too broad to be useful. To make a decision like this, you need to actually argue the real pros and cons of doing so, rather than just saying "it's much more difficult." All of this was brought up and discussed thoroughly when the experiment was greenlit, and any difficulties created by including Rust, "much more" or no, was deemed an acceptable tradeoff for the benefits of doing so. That's e…

Sure, engineering is all about the tradeoffs, there's no black and white. So, what is an advantage of mixing two different languages over one kernel module, in this example DMA? What problem does introducing another language solve and what would be the alternatives?

> So, what is an advantage of mixing two different languages over one kernel module,

This is not what is happening. What is happening is the C module is getting a Rust wrapper, to make Rust code be able to call into it more easily. This is because Rust is currently being used for drivers, and DMA is very useful for drivers, so they need to call into the C code somehow.

> What problem does introducing another language solve and what would be the alternatives?

The ones Linus found persuasive are mostly that Rust's memory safety can bring more stability and security to the kernel, and that Rust is likely to attract new developers. Obviously that's just some of it, but those are the main technical and social benefits from including Rust.

The alterative is to not do it.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#38

Post by uecker »

vsgherzi wrote: post #35
uecker wrote: post #29

Earlier quoted context omitted.

There are definitely people using static analysis to write memory safe C. This is not really practical though, but getting a reasonable level of memory safety is very much possible using tools and good design. People dismiss this because it is not perfect, but this completely fails to take into account that - in practice - Rust is also far from being memory safe due to use of unsafe. Whether it was proposed by Linus…

Rust is memory safe by every definition. Unsafe is an escape hatch that is only used when safe won’t work and assumptions can be made by the programmer. This is a needed solution and does not take away from rust as a safe language. To me Linus is the leader so if he wants to try it we should try it. If he wants it gone then it should be removed all the same. Linus did not include rust for something like a programming…

Safe Rust is memory safe when used exclusively while unsafe Rust is obviously not memory safe, and a mix might also not be. If you use unsafe blocks carefully in Rust it is still quite memory safe but if you use unsafe blocks carelessly is not very memory safe. My favorite example is the CVE in a matrix transpose function: https://github.com/advisories/GHSA-5gmm-6m36-r7jh A similar error in C would be taken by Rust proponents as clear sign how dangerous C is. Overall, in practice, the safety of Rust is not so clear as proponents claim, except when strictly sticking to the safe part.

I think the experiment is a mistake and the kernel would obviously stay relevant even without this. But I am happy to let Linus make this decision. I just think it is a poor decision.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#39

Post by vsgherzi »

uecker wrote: post #38
vsgherzi wrote: post #35

Earlier quoted context omitted.

Rust is memory safe by every definition. Unsafe is an escape hatch that is only used when safe won’t work and assumptions can be made by the programmer. This is a needed solution and does not take away from rust as a safe language. To me Linus is the leader so if he wants to try it we should try it. If he wants it gone then it should be removed all the same. Linus did not include rust for something like a programming…

Safe Rust is memory safe when used exclusively while unsafe Rust is obviously not memory safe, and a mix might also not be. If you use unsafe blocks carefully in Rust it is still quite memory safe but if you use unsafe blocks carelessly is not very memory safe. My favorite example is the CVE in a matrix transpose function: https://github.com/advisories/GHSA-5gmm-6m36-r7jh A similar error in C would be taken by Rust p…

I agree, unsafe rust is only meant to be used when absolutely needed. It’s up to the programmer. Frivolous use of unsafe should be rejected from any respectable code base.

I didn’t mean to say that without it the kernel would be irrelevant. I meant more that this is just one possibility for the future of the kernel and I think it’s important that we try as it has to always be better. Given the response from current maintainers I also question if the experiment should continue.

Re: Hector Martin – [Patch] Maintainers: Remove Myself

#40

Post by gigatexal »

talldayo wrote: post #23
gigatexal wrote: post #17

Earlier quoted context omitted.

The Apple hardware is compelling enough that I think they will keep it up. We are funding them — at least I am trying to

If I poured out a beer for every "compelling" chipset depreciated by the mainline Linux kernel, I'd be going out to buy 6-packs on a weekly basis. It's a neat initiative, but you should have been preparing for this result since the beginning. No official support means no official support.

What chipsets were deprecated that are still mainstream?
Post reply on HN