Asahi Linux lead developer Hector Martin resigns from Linux kernel • Hacker News Board

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#851

Post by _ph_ » Sat, Feb 08, 2025, 6:39 PM UTC

roca wrote: post #454

alberth wrote: post #268

Earlier quoted context omitted.

And Linus’ immediate reply https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU... (not taking either side, just interesting to read the reply)

This part of the reply exemplifies one of the big problems in the kernel community: > You think you know better. But the current process works. Regardless of how badly broken the kernel development process is, Linus and others observe that Linux continues to dominate and conclude that therefore the development process "works". Success in the market blinds the successful vendor to their defects. Sound familiar? If Lin…

Or worse: Linux is so widespread and managed to practically kill most Unix alternatives, that progress in OS development is slowed down globally. I would strongly prefer Linux being an OS with a lot of progress to stagnation and possible no alternative in the next decades.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#852

Post by stainablesteel » Sat, Feb 08, 2025, 6:43 PM UTC

AndyKelley wrote: post #422

I've been saying this for years now: the rust4linux folks are putting so much effort into trying to upstream their work, seems like they should instead put that effort into maintaining a fork. Arguably it would be less hours spent porting than arguing with humans. Certainly more pleasant! Then one of two things will happen: * Rust will prove its worth and their fork will be the better operating system. Distros will s…

completely agree on the fork side of things, just show its merits already or be done with it

i think it's going to fail because of rust as a language, not because the ideas in rust are bad but because there's infinite complications

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#853

Post by lII1lIlI11ll » Sat, Feb 08, 2025, 6:58 PM UTC

okanat wrote: post #818

lII1lIlI11ll wrote: post #585

Earlier quoted context omitted.

No, it is not the entire point. No one is really doubting whether you can write a driver in Rust, C++ or Swift. The whole experiment is whether you can slowly move in to existing mature kernel subsystems without being too disruptive.

If the minority maintainers scream every time they see other languages due to their insecurities, technical inability and stubbornness, and their overreactions get a pass, it is not the fault of Rust, C++ or Swift. The source of the disturbance is not the people who are making an effort to cause as little disturbance. Blatant NIMBYism is the problem here and you cannot reduce it by accepting everything.

In general, upstreaming code to Linux involves interacting with difficult and sometimes outright hostile people. I've certainly had my share of both with much smaller changes. IMO pushing something like R4L requires very thick skin and almost infinite amount of patience. Bitching about that won't get you far, you need to be able to either work with or around those people.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#854

Post by uecker » Sat, Feb 08, 2025, 6:58 PM UTC

_ph_ wrote: post #842

Gibbon1 wrote: post #693

Earlier quoted context omitted.

Keep believing that Rust magically prevents you from getting owned when you fuck up.

That is a fallacy. No one has claimed that Rust magically prevents you from getting owned. Quite to the contrary: there is no magic in preventing most, if not all memory handling errors. Which are the most common reason for security problems. Removing one category of errors entirely would free a lot of resources to deal with the remaining ones.

Even the "removing one category of errors" is not true when you use unsafe blocks in Rust, which is done generously in system programming.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#855

Post by WesolyKubeczek » Sat, Feb 08, 2025, 7:01 PM UTC

docandrew wrote: post #247

I don’t see why forking is not an option here. If the upstream maintainers don’t want to adopt it, the Rust folks can gradually rewrite the bits they want to and let the market decide. Use the Ballmer “embrace, extend, extinguish” model.

Because forking requires a lot of hard work and time to even get acknowledged, while bringing Rust into the kernel, given enough PR, establishes a whole new hierarchy in which not only do they get to be at the top of right away, but they also get to depose the old guard!

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#856

Post by _ph_ » Sat, Feb 08, 2025, 7:02 PM UTC

uecker wrote: post #854

_ph_ wrote: post #842

Earlier quoted context omitted.

That is a fallacy. No one has claimed that Rust magically prevents you from getting owned. Quite to the contrary: there is no magic in preventing most, if not all memory handling errors. Which are the most common reason for security problems. Removing one category of errors entirely would free a lot of resources to deal with the remaining ones.

Even the "removing one category of errors" is not true when you use unsafe blocks in Rust, which is done generously in system programming.

Is that so? How large parts of the Rust kernel drivers in existence are inside unsafe blocks?

Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#857

Post by shadowgovt » Sat, Feb 08, 2025, 7:03 PM UTC

I think it looks like both sides are making some pretty valid points here.

Those who are nervous about embracing Rust further are just fine. Rust is still a young language. It shows an awful lot of promise, but it isn't a magic cure for safety and security concerns, especially at the kernel level. It is entirely possible that Linux is a bad fit for the language, and the real way to get ta Rust kernel is for a team to come together and implement a kernel in Rust, from scratch, perhaps with POSIX compatibility.

On the flip side, Hector is entirely correct that the overall process of maintaining and improving Linux is incredibly baroque and grounded squarely in some tooling that just stinks in the modern ecosystem. It has worked for Linux for ages. It is also increasingly making working on Linux a specialized project space because nobody else manages projects like this. Hector is fine leaving if he finds that process two owners to be worth his volunteered time. And it is entirely possible that there will come a day when the value of the project itself is outweighed by the cost of interacting with the project and Linux will get supplanted in the common ecosystem by something else.

In short, Hector is probably making the right move here. If he wants to continue working on a problem like this, a new operating system might actually be the right solution.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#858

Post by [deleted] » Sat, Feb 08, 2025, 7:11 PM UTC

darthrupert wrote: post #824

rdtsc wrote: post #527

Earlier quoted context omitted.

> If shaming on social media does not work, then tell me what does, because I'm out of ideas. That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for. > Rust folks: Please don't waste your time and mental cycles on drama like this [...] they know they're going to be on the losing side o…

Threatening with social media seems to me like a professional suicide, especially when it's followed by a doubling down and a complete lack of anything resembling an apology. I'm amazed that Hector is doing this fully in public using his real name.

[deleted]

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#859

Post by rc00 » Sat, Feb 08, 2025, 7:18 PM UTC

steveklabnik wrote: post #841

harshreality wrote: post #802

Earlier quoted context omitted.

I think this is an important data point, too: Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298... Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PR…

Greg replied and explained that this is a mischaracterization https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosm...

You are misrepresenting the current state. The thread was unfortunately diverted before Jason's question received an appropriate response and conclusion: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...

> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.

> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".

> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.

The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.

Re: Asahi Linux lead developer Hector Martin resigns from Linux kernel

#860

Post by steveklabnik » Sat, Feb 08, 2025, 7:19 PM UTC

wahern wrote: post #505

steveklabnik wrote: post #503

Earlier quoted context omitted.

Just to be super clear about it, Rust does not do strict aliasing. That’s a totally different set of rules than Rust’s aliasing rules.

I know Rust doesn't do "strict aliasing", literally speaking. But that's partly because Rust's borrowing rules change the framing of the term strict aliasing as used in C, etc. It's similar for terms like "undefined behavior", where there's sometimes a certain amount of pedanticism from Rust developers that merely serves to deflect the point of contention. Is this wrong? https://doc.rust-lang.org/nomicon/aliasing.htm…

Oh, and "undefined behavior" has effectively the same definition in Rust and in C and C++. There's wording differences:

C/C++: behavior for which this document imposes no requirements

Rust: is not bound by any specification

But that's just a wording difference, not a semantic difference.

There are some instances where Rust and C/C++ use similar words to mean different things, but that's also changed over time. For example, Rust used to use rvalue and lvalue, but has moved to

"place expression", defined as "lvalue" in C and "glvalue" in C++

"value expression", defined as "rvalue" in C and "prvalue" in C++

The only reason to not use the C++ terms here is that these are the only two value categories in Rust, and it's unlikely to need all of the other three that C++ has.

You're not wrong that there's stuff called the same but has different meanings, for example, "reference," but what can you do.