stalkers who harassed and attacked me and my family
Wtf is wrong with these people?
entitlement and/or astro-turfing imo
kiwifarmers got on his ass
That’s really too bad… They are a super talented developer and they were doing something really cool, and making great progress too.
But if they were doing Asahi Linux for fun as a hobby, and if it isn’t fun anymore for a variety of reasons, then you really can’t blame them.
I’m not sure if there is a “right” or “wrong” here, as this is just one person’s side of the story that acknowledges, but mostly glosses over, the possibility that they made mistakes or behaved badly at times too.
But I can absolutely understand the basic concept of burning out because you don’t think your hard work is being appreciated, because people are making hard things even harder for you, or because users on the internet let their excitement about a thing push them too far into being entitled.
Hopefully Marcan can find some time to relax and do fun and rewarding things with their time.
But if they were doing Asahi Linux for fun as a hobby, and if it isn’t fun anymore for a variety of reasons, then you really can’t blame them.
I have 0 knowledge about this project, so my statement here is just a general statement.
But if a developer collects donations for promising something, then this is not just “for fun”, but they do have a moral obligation to try doing a good job.
It seems they overfullfilled their obligations (but all I know about it, are the words of the developer). So, as said above, this is a general statement.
edit: lol you guys are funny, but maybe read my comment. I talked about “doing his best” and about “things they promised”. You really think it is okay to say “I will try project A, I need donations” and then go on a holiday with the donated money and do nothing else? Do you thing this attitude will get people to donate anything?
Donations do not obligate anyone to do anything. It’s a donation, not pay. They should be done out of appreciation for someone’s time and effort, or to help support any potential work the project decides to do. But never with the expectation that you’re owed something back for donating.
You’re probably right from a legal perspective, but the difference between “donation” and “salary” is pretty murky in this context.
You really think it is okay to say “I will try project A, I need donations” and then go on a holiday with the donated money and do nothing else?
Yes. A donation is a donation, fullstop.
Would I feel good or morally okay doing such a thing? Absolutely no way. I acknowledge that internal inconsistency. If someone gives me something, I feel obligation to give back… simple as that.
Objectively speaking though, a donation is not a contract, and to expect a donation to have future influence is a messy method of doing business that should be viewed with a pretty critical eye. If a person giving money wants an obligation, they should pursue a contract… If they don’t care what happens after they give the money but just want to show support or appreciation, that’s where donations shine.
If I gave a donation to my favorite videogame dev, but then 2 hours later they stopped supporting that game, I’d still be happy I showed them support for what they had given me so far. I believe retroactively being unhappy about giving a donation shouldn’t cast the receiver in a bad light, and that it’s the giver that didn’t understand what they were doing and what the potential outcomes were.
Wow. The entitlement… maybe learn what a donation means
I’m not surprised by this.
The general attitude around R4L is that it’s largely unneeded and for every 1 person actively working against the project, there are 10 saying either “waiting and seeing if it works is the right decision” or “if rust is so good they should prove it.”
So as a R4L developer you’re expected by the community to fight an uphill battle with basically no support on your side.
We will likely keep having developers on that project continue to burn out and leave until the entire thing collapses unless the decision is made ahead of time to cancel the project.
Every time I read any news about Rust for Linux I leave disappointed by the entire kernel community.
I am with you on that last line. However, I remain more hopeful.
As long as Linus keeps merging code, Rust will eventually win. And by win I just mean that it will overcome the haters sufficiently to render their resistance futile.
There is only so much support infrastructure needed before large chunks of Rust can be committed ( at least on the driver side ). We are not so far away from that. Once real code starts to appear the “show me” will drive adoption elsewhere.
Take this case, it all started over a bit of code. The subsystem maintainer refuses to take it. But it does not require any changes to existing code. It just has to be merged.
Linus can take it directly. If he does that, the Rust folks can start to use it. The sub-system maintainer will lose in the end.
At some point, the battle will be lost by those trying to block Rust.
It all depends on Linus. We will see.
Take this case, it all started over a bit of code. The subsystem maintainer refuses to take it. But it does not require any changes to existing code. It just has to be merged. Linus can take it directly. If he does that, the Rust folks can start to use it. The sub-system maintainer will lose in the end. At some point, the battle will be lost by those trying to block Rust. It all depends on Linus. We will see.
Linus hasn’t been merging the necessary code, by virtue of supporting a maintainer who was very obviously trying to sabotage R4L; if Linus was going to stand up for R4L, this would have been the time.
What code has he not merged? Was his argument technical or political?
I see lots of R4L code being merged in each of the last few releases.
I also do not see the email where Linus supported Christoph. I see the one where he chewed out Hector for “social media brigading”. That is not the same thing as supporting the maintainer. Hector is not even the one submitting the Rust code in question. He just piled on in the LKML later.
The boiled down summary is:
-
Christoph rejects the patch because he doesn’t want to maintain it
-
Christoph says no and that he “will do everything [he] can do to stop [Rust support from being added to the DMA subsystem]”
By saying that Hector is the problem, he’s implicitly saying that Christoph is not the problem. By saying that the current process works–the very same process that just prevented R4L from submitting patches to the kernel, he’s implicitly endorsing Christoph’s actions.
Perhaps. That is not my read. I hear Linus saying that he trusts the process and that sticking with it is the solution to working through the problem. He does not say that a maintainer blocking a technically sound patch is a problem. He does not say that he would reject the patch. He does say that the approach taken by Hector ( who is not the one that submitted the patch ) is the wrong one. If Linus had said that the technical approach or the code quality was a problem, I would agree with you. He did not object to either of those things. What he said is that social media is not the solution.
The problem with your timeline is that it completely leaves out the event(s) that Linus is objecting to. I am hoping that is unintentional on your part.
I will know what Linus thinks when he either accepts or rejects the submission from the R4L team.
I didn’t include the social media “brigading” portion because Linus already addressed that in a different sub-thread.
If that does happen, I just hope there will be enough developers by then that can/will want to use it (as in, write rust code). Especially developers that can put up with the kernel process and its people.
Fair point. I do think burn out is a problem for the process in general. I guess Linux has always benefited from the long line of people looking to contribute. As long as progress is being made, I expect that to continue here.
I’m not sure why they feel it’s Linus’ responsibility to make Rust happen in the kernel. I’m certainly not happy someone is being harassed, but none of this is the fault of the Linux Foundation or the people that have been working on the kernel for decades.
If Rust is going to happen, then it’ll happen. Or fork it and make a Rust Linux with blackjack and hookers, and boy, will everyone left behind feel silly that they didn’t jump on the bandwagon. But nobody has to make your dreams their focus or even interact with it if they don’t want to. And these social media outbursts aren’t accomplishing what they think they’re accomplishing.
If Rust is going to happen, then it’ll happen.
How can it happen if individual maintainers say they’ll do everything in their power to keep Rust out of the kernel? There’s fundamentally no way forward. The R4L devs already gave every commitment they could, but some maintainers fundamentally don’t want it.
And before anyone brings it up: no, the maintainers weren’t asked to touch Rust code or not break Rust code or anything else.
Fact is Rust isn’t ready for every part of the kernel. C/Rust interop is still a growing pain for Linux and troubleshooting issues at the boundary require a developer to be good at both. It’s an uphill battle, and instead of inciting flame wars they could have fostered cooperation around the parts of the kernel that were more prepared. While their work is appreciated and they are incredibly talented, the reality is that social pressures are going to dictate development. At the end of the day software is used by people. Their expectations are not law, but they do need addressed to preserve public opinion.
Again: what cooperation is possible when the maintainer says “I’ll do everything in my power to keep Rust out of the kernel”? When they NACK a patch outside of their Subsystem?
Can a maintainer really NACK any patch they dislike? I mean I get that Hellwig said he won’t merge it. Fine. What if for example Kroah-Hartman says “whatever, I like it” and merges it nonetheless in his tree?
I doubt Greg is pulling in Rust until it has been through the mainline. That said, Linus can merge anything he wants.
It was an example. I don’t have a fucking clue how all the maintainers are named.
The main question was: why can a maintainer NACK something not in their responsibility? Isn’t it simply necessary to find one maintainer who is fine with it and pulls it in?
Or even asked differently: shouldn’t you need to find someone who ACKs it rather than caring about who NACKs it?
Let me just say that hierarchies are for breaking ties.
The normal process is that Linus prefers we all work through maintainers to cut down on the noise that comes to him. In this case, the maintainer is the reason the noise is coming to Linus. So, it will be up to him to settle it.
I’m not sure why they feel it’s Linus’ responsibility to make Rust happen in the kernel.
That’s not what’s being said here, as far as I can tell. Linus is not expected to somehow “make Rust happen”. But as a leader, he is expected to call out maintainers who block the R4L project and harass its members just because they feel like it. Christoph Hellwig’s behavior should not be allowed.
I’m not saying Marcan is necessarily correct, to be clear. It might well be that Linus chose to handle the issue in a quieter way. We can’t know whether Linus was planning on some kind of action that didn’t involve him jumping into the middle of the mailing list fight, eg contacting Christoph Hellwig privately. I’m merely pointing out that maybe you misunderstood what Marcan is saying.
Or fork it and make a Rust Linux with blackjack and hookers, and boy, will everyone left behind feel silly that they didn’t jump on the bandwagon.
That’s what they’re doing. But if you read the entire post carefully, he explains why maintaining a fork without eventually upstreaming it is problematic. And it’s not like they’re forcing their dream on the linux project, because the discussions have already been had and rust has officially been accepted into the kernel. So in the wider context, this is about individual maintainers causing friction against an agreed-upon project they don’t like.
I’m not placing blame on the Linux Foundation, Linus, or anyone else for that matter. However, I believe that if Linus has publicly endorsed the use of Rust in the kernel, that decision is already largely set in motion. On the other hand, if the community collectively opposes the integration of Rust with C and no action is taken to address these problems, and everyone say no, then there is little to no reason to make the initial statement.
Much of the work being produced by Rust developers seems to struggle, often because it’s not made in C and because of maintainers saying “No I don’t want any rust code near my C code”.
I recognize that there are various technical factors influencing this decision, but ultimately it was the creator’s choice to support it.
Or just boycott Linux and use Redox if you like Rust.
deleted by creator
And these social media outbursts aren’t accomplishing what they think they’re accomplishing.
I’m extremely technical, but not actively into Linux, though I’ve set up various distros dozens up times. These posts have driven me away from Linux in an extremely hard way - anyone with opinions like the Kernel team simply don’t deserve support, and Linus is clearly past his prime and making bad decisions. This has shown me that Linux is going to (likely already has) slowly stop improving due to its explicitly anti-progress leadership. Until a fork with good leaders manages to take a real market share, the OS will stagnate.
I’m sure this is a minority opinion, but to claim that the social media blitz hasn’t had its intended effect is objectively false. Fuck the kernel team.
Linus is pro-Rust. It is not clear from what you wrote that you realize that. He has merged plenty of Rust code. I personally expect him to merge the change that caused all this current drama (though I could clearly be wrong about that).
Right or wrong, this is how Linux kernel dev has always worked. How long did it take for real time to get in? How smoothly is the bcachefs merge going? Have you read any of the GPU driver chatter?
Honestly though, it is not just the kernel. How much different is the Wayland scene?
I am hardly defending Linux here by the way. I think the maintainers are blocking progress. I am merely pointing out that it is hardly new or unique.
Anyway, RedoxOS is quite progressive. They would probably love help from anybody that finds Linux kernel dev too stodgy.
Today, it is practically impossible to survive being a significant Linux maintainer or cross-subsystem contributor if you’re not employed to do it by a corporation. An interviewer to the Linux dev that’s mentioned in the article: “So what did you do next to try to convince the Linux kernel devs of the need for more focus on end-users?”
I appears as if Linux is a nest that is not built with a consistent set of user-centric principles. Instead, it seems that each part of the nest is built with a specific corporation or project in mind.
Assuming I’m right that Linux is built with project-based thinking and not product-based thinking, I do wonder what a user-centric Linux or another user-centric FLOSS OS would be like, an OS that is so smoothly built that users come to think of it not as an OS for tech-savvy people, but an obvious alternative that you install immediately after getting a computer.
If Linux is indeed built with project-based thinking, then I wonder why that is. The uncharitable explanation is that someone doesn’t want Linux to have a MacOS-like smooth and gorgeous experience. If you don’t think MacOS is smooth and gorgeous, I’ll address that.
I know some people have suffered immensely with Apple products not only because Apple builds devices that can’t be repaired, but because of things simply not working. However, there are many people who love Apple. That’s the kind of passionate advocacy that I would love to see in Linux, and not just around freedom and value-based judgements. I want Linux to be thought of as the least-friction tool for professional or recreational use. I want people to think of Linux as gorgeous and usable.
Of course, we can apply Hanlon’s razor to this situation (“Never attribute to malice that which is adequately explained by [ignorance or lack of skill or practice].”). Managing a product is difficult. Managing a community is difficult. When the nest’s design is not built by a team constantly seeking to care about users, but instead by a bunch of users pecking into the nest until their corner is shaped the way they want, it’s not surprising to see a lack of user-centricity.
I’d much rather see them commit their talent towards more open hardware. Apple hardware isn’t even that good.
The build quality may not be that good but the technology and the designs are excellent. I say that as somebody that does not use macOS (well, not much).
As somebody that buys older hardware, I cannot wait to use Linux on Apple Silicon in a year or two. When I do, I will be immensely appreciative of all the effort that is going into it now. It will feel pretty open to me by that point.
Most importantly though, people put effort into the things that they want to. I am thankful that they have that freedom.