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.
JuxtaposedJaguar@lemmy.ml
on 14 Feb 22:59
collapse
You’re probably right from a legal perspective, but the difference between “donation” and “salary” is pretty murky in this context.
Sanguine@lemmy.dbzer0.com
on 13 Feb 20:50
nextcollapse
If this person was given a grant or funding via a kickstarter or something I would agree with the obligation idea, but donations are exactly that, a voluntary gift to the dev for the work they have done so far and may continue to do in the future. There are no “moral obligations” to continue the project.
Alpacrastinator@lemmy.world
on 14 Feb 07:29
nextcollapse
Wow. The entitlement… maybe learn what a donation means
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.
Isn’t this the guy who got called out for trying to use social media brigading to force Linux kernel rust patches through? There’s a good chance those stalkers are fictional.
mostlikelyaperson@lemmy.world
on 14 Feb 09:56
nextcollapse
If you are replying with “isn’t this the guy” it means you didn’t bother to read the post, which also removes the merits of you questioning if what he is claiming is fiction or not.
But people on HN provided context and it indeed seem he was stalked and harassed, but through his VTuber persona and there was even a GDocs document with the details.
Edit: His VTuber persona is Asahi Lina
JuxtaposedJaguar@lemmy.ml
on 14 Feb 22:56
nextcollapse
Slightly OT but I always thought Asahi Lina was a woman. TIL.
It’s never been confirmed that they are the same person, and they both operate as if they are completely separate people. Lina goes by she/her on stream as well.
I’d much rather see them commit their talent towards more open hardware. Apple hardware isn’t even that good.
Whooping_Seal@sh.itjust.works
on 13 Feb 22:51
nextcollapse
I think it’s important to see these types of efforts, while I’ll never go out and buy a MacBook the effort isn’t wasted since it gives current users more freedom and future people buying used laptops more options for Linux compatible hardware.
Without a project like this, that hardware will end up being e-waste a lot sooner than it should be, when Apple drops support. At least to me I see an ethical and moral imperative for projects like this, but I also understand people’s grievances with Apple.
LeFantome@programming.dev
on 14 Feb 17:54
collapse
If people can use Linux on their Apple hardware after macOS stops supporting it, it keeps them from having to buy new Apple hardware a little longer.
LeFantome@programming.dev
on 14 Feb 17:51
collapse
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.
arisunz@lemmy.blahaj.zone
on 13 Feb 18:42
nextcollapse
fuck gatekeepers. the linux kernel doesn’t deserve new, talented people bringing fresh, useful and modern approaches to the project; their time and effort is only wasted there. i know it’s not right, but part of me wishes linux rots and something better takes its place.
bitterness aside, i hope marcan gets the rest he needs. i wish him the best.
There are already several Rust Kennel From Scratch projects that are reasonably progressed. Redox is one, Asterinas is another.
The latter is I think aiming for Linux ABI compatibility.
patatahooligan@lemmy.world
on 14 Feb 12:14
collapse
The latter is I think aiming for Linux ABI compatibility.
I had never hard of Asterinas, but this sounds like a the best approach to me. I believe alternative OS’s need to act as (near) drop-in replacements if they want to be used as daily drivers. ABI-incompatible alternatives might be fine for narrower use cases, but most people wouldn’t even try out a desktop OS that doesn’t support most of the hardware and software they already use.
Most people using our software just wanted to play pirated games (something we did not support, condone, or directly enable)
He wasn’t on whatever team that released a tool that asked “Oh hey just asking do you intend to run pirated games? Just need to know for setup” then soft bricking the console if you say yes?
toothbrush@lemmy.blahaj.zone
on 13 Feb 19:29
nextcollapse
I read the “thin blue line” email and it seems… reasonable and sensible? And seeing how he is so appaled by it makes me question his judgement a bit.
arisunz@lemmy.blahaj.zone
on 13 Feb 20:02
nextcollapse
knowing where “thin blue line” comes from, you don’t see anything wrong with a maintainer randomly dropping it on the mailing list?
toothbrush@lemmy.blahaj.zone
on 13 Feb 21:28
nextcollapse
Alright, fair. I was more refering to the content of the message, not the (botched) metaphore of maintainers as a force of order.
arisunz@lemmy.blahaj.zone
on 14 Feb 00:04
collapse
ah, fair enough. i guess that’s kind of the thing with potential dogwhistles. if you know, you know.
beeng@discuss.tchncs.de
on 13 Feb 21:28
nextcollapse
You scrolled half a wiki page to the part that fits your narrative.
The metaphor of a thin blue line is that they “the police” are not in the typical sense very large, like an army, but they do keep the order with a thin presence of rule and order. Sounds like what maintainers do in this case.
arisunz@lemmy.blahaj.zone
on 14 Feb 00:02
collapse
The “thin blue line” symbol has been used by the “Blue Lives Matter” movement, which emerged in 2014
But you link to a Wikipedia article that says:
New York police commissioner Richard Enright used the phrase in 1922. In the 1950s, Los Angeles Police Chief Bill Parker often used the term in speeches, and he also lent the phrase to the department-produced television show The Thin Blue Line. Parker used the term “thin blue line” to further reinforce the role of the LAPD. As Parker explained, the thin blue line, representing the LAPD, was the barrier between law and order and social and civil anarchy.
The Oxford English Dictionary records its use in 1962 by The Sunday Times referring to police presence at an anti-nuclear demonstration. The phrase is also documented in a 1965 pamphlet by the Massachusetts government, referring to its state police force, and in even earlier police reports of the NYPD. By the early 1970s, the term had spread to police departments across the United States. Author and police officer Joseph Wambaugh helped to further popularize the phrase with his police novels throughout the 1970s and 1980s.
The term was used for the title of Errol Morris’s 1988 documentary film The Thin Blue Line about the murder of the Dallas Police officer Robert W. Wood.
I have no idea about this guy’s politics, but it’s a pretty well known phrase with a lot of different contexts.
arisunz@lemmy.blahaj.zone
on 14 Feb 00:01
collapse
we don’t live in the 80s though. we live in contemporary times where things have different now meanings to what they did 40 years ago. meanings that might be influenced by recent happenings. hope that helps!
This is just being disingenuous. They clearly mean the origin of the current usage, which is rooted in police “sheepdog” ideology and all that fascist bullshit. Not that the old usage was much better considering the state of police gangs in LA and the kind of laws they were enforcing in the 60s.
I usually see “thin blue line” (and the flag) used by reactionaries, racists, and white nationalists. Especially since BLM. Don’t know what sort of politics Ts’o has, other than he’s probably not an anarchist (ACAB!), but I guess (benefit of the doubt and all) he could be some ignorant lib with a head full of copaganda, so getting out the code of conduct for racist dogwhistles might be a bit premature.
It comes from The Thin Red Line, which is about some Scottish regiment standing up to a Russian cavalry charge. Even if you don’t know that, it seems quite obviously a military metaphor, and that indicates a militaristic view of what policing should be like, veneration of the police as heroes, and total ignorance about what the police actually are and do.
corsicanguppy@lemmy.ca
on 13 Feb 20:46
nextcollapse
seems quite obviously
That’s highly subjective. Remember this is a global resource with environments different from your own.
I fail to see how anyone could interpret what can only refer to holding the line as not a heroic act and a military metaphor. And that’s how it’s used, and that’s what it means, and that’s where it comes from.
And Ts’o clearly knows this as well, since it he appropriately uses it as a metaphor for keeping chaos at bay and out of the kernel.
beeng@discuss.tchncs.de
on 13 Feb 21:40
nextcollapse
A thin line between chaos and order. That line is blue if it’s the police.
Its literally the first thing in the wiki page. “Line” between apposing forces is the “order”. ie Mantainers in this case.
The first time I heard the phrase was from a TV show with Mr Bean when I was like 9 or 10.
As another commenter said, I think the article guy is a bit sensitive or took it the wrong way, since “the thin blue line” when talking about maintainers is very much like they are acting as defense to “outside” forces. Whether that is good or bad for Linux, is debated.
I’m not just talking about the US police. I’ve never been to the US, and I assure you the police is shit here too. Ts’o is American, and that “thin blue line” saying seems especially American or Anglo. I’ve never heard that over here. So I’m not sure how that’s even relevant to the discussion.
BLM and ACAB are very American centric movements/sentiments. Hence why I took your comments to be American focused.
Whilst I’ve heard the phrase “thin blue line” before, it’s never been something associated with racist overtones or subjugative ones in my experience. More that the police is a small community protecting the larger population.
As such, someone using it context of not allowing the proliferation something is reasonable, if possibly histrionic in this case.
A few months ago (Oct 18 2024) Linus and his sidekick signing the kernel, not only admitted they were going to comply with US Stat.Dep. doctrine and remove developers (on long term good standing) on the basis of nationality and national origin of the employers, they exploded into a rant, clearly admitting to being nationalist and in distrorting history to fit their rhetoric.
In greenwashing nationalism (you can say racism underlying this national hate speech) into the base of most open and free code, nationalism now is not free as in beer it is free as in “freedom”? This is as large of a difference as socialism and ethno-socialism.
The linux community … the end user … DOESN’T give a damn, only wants the latest and badest of development in his gaming machine.
Once you make a slip and slide exception you can’t prevent any more in the future. First will be “justified nationalism”, then “not so justified racism”, then “sexism”, then will be the gas chambers for anyone who forks anything away from Führera (Fedora + Führer).
If using any kernel later than 10 18 2024 I see it as the nationalist/racist fork.
I expect the original to continue by developers who don’t use race/ethnicity/gender as a basis for accepting/rejecting contributors.
Are you referring to the time they kicked out a bunch of people employed by the companies associated with the Russian government and that are under direct sanctions for supporting the war?
People are not under sanctions, and no linux developer worked for the Russian government, and since when has a war affected who works on what open source project. There are wars all over the place all the damn time …
I am not talking about the sanctions, I am talking about the additional remarks on how nationalist and racist both the leaders of the project appeared to be from their statements.
Companies are under sanctions. Companies that are connected to the Russian government. Government that is actively wages a terrible unjust war. A war that shouldn’t happen.
People who are working in those companies were banned for the duration of them working for and supporting companies that are under sanctions.
If that’s a problem for you you are being obtuse either on purpose or, I hope, because you’re underinformed.
This war was forced into Russia due to the blocking and surrounding it with NATO bases clearly against it, and by trying to block and substitute its primary exports to EU.
The violent overthrow of the then democratic government in Ukraine, the arming, training, and directing a Neo-Nazi para-military unit to take over, after forcing half the political parties in being illegal, had nothing to do with Russia. If there is someone underinformed, confused, and lacking historical facts it is not me, and better change your arrogant tone if you seriously want to discuss something and not just throw propaganda mud.
Don’t take me wrong, I hate Putin just as much as I hate Biden or Trump, don’t misinterpret what I say
But between hating Trump and discriminating against you because you are from Nebraska is the difference between a racist and a non-racist …
Something the linux-duo-Fins can not separate, hence their delirium with nationalist rhetoric and lack of historical understanding.
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.
arisunz@lemmy.blahaj.zone
on 13 Feb 21:14
nextcollapse
why they feel it’s Linus’ responsibility to make Rust happen in the kernel
who does? are you talking about marcan? because as far as i can see, what they’re asking for is for linus to make a stance and actually say whether R4L is a thing they want or not. because linus’ attitude so far has been “let’s wait and see” which hasn’t been all that helpful, as said in the blog post.
vanderbilt@lemmy.world
on 14 Feb 04:14
nextcollapse
Ultimately Linus’ opinion here does not matter in the positive. He can say Rust in kernel is good, but that does not summon the skill and work to make it happen. He can say it’s bad and quash it, at the potential expense of Linux’s future. His position of avoiding an extreme is a pragmatic one. “Let them come if they may, and if they do not it was less a loss for us.”
arisunz@lemmy.blahaj.zone
on 14 Feb 05:12
nextcollapse
see, i could maybe agree with this if it weren’t for the amazing work from R4L that already has been and continues to be done, despite subsystems maintainers putting their foot down and going “Not In My Back Yard, bucko!”. how many more maintainers does R4L have to lose before Linus realizes he might need to take a stance as a project lead?
JuxtaposedJaguar@lemmy.ml
on 14 Feb 22:53
collapse
Linus can merge whatever patches he wants to, and the stonewalling subsystem maintainers would have to deal with it–like he did with the eBPF scheduler. R4L maintainers already wrote the patches, they literally just needed to be merged.
arisunz@lemmy.blahaj.zone
on 14 Feb 13:19
collapse
aughhhhhh here’s your upvote. git out.
MazonnaCara89@lemmy.ml
on 13 Feb 21:19
nextcollapse
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.
It’s also his legitimate choice to wait. He can’t see the best way forward and is deciding to wait on his decission or let the community decide instead of him. As much as we like to think of him as autocrat in some way, he respects people that work on kernel and he respects their time. The smartest move is often to wait on a decision. And even if it’s not a smartest move in this case, it can still be better than making a wrong decission that will demoralize the community even more.
Isn’t it reasonable for a maintainer to say “no rust here” when they don’t know rust, don’t want to learn it, and have decades of experience in C, and are maintaining that part of the system
But that’s not what’s happening here. The guy who said no is not the maintainer of the rust code, and is not expected to touch the rust code at all.
LeFantome@programming.dev
on 15 Feb 21:05
collapse
The project has said it is a goal to move to a dual language model. So, no, it is not reasonable.
What would be reasonable would be technical arguments or pragmatic logistical concerns with the goal of finding solutions. What would be reasonable would be asking for and accepting help.
None of the reasonable stuff is happening. So, it not reasonable.
FooBarrington@lemmy.world
on 13 Feb 21:50
nextcollapse
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.
ryannathans@aussie.zone
on 13 Feb 22:26
nextcollapse
Then rust isn’t going to happen in every area of the kernel yet
FooBarrington@lemmy.world
on 14 Feb 07:13
collapse
Which means unnecessary duplication of code, because every driver has to track kernel Interfaces separately. Why? What’s the advantage?
vanderbilt@lemmy.world
on 14 Feb 04:10
nextcollapse
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.
FooBarrington@lemmy.world
on 14 Feb 07:44
collapse
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?
I’ve been following this debate for a bit and as far as I can tell it’s not so much that they’ll do what they can to keep rust out but more to make sure that the people who want to develop in rust are the ones who end up maintaining that part of the code and not the current maintainers.
FooBarrington@lemmy.world
on 14 Feb 11:19
collapse
I accept that you don’t want to be involved with Rust in the kernel, which is
why we offered to maintain the Rust abstraction layer for the DMA coherent
allocator as a separate component (which it would be anyways) ourselves.
Which doesn’t help me a bit. Every additional bit that the another
language creeps in drastically reduces the maintainability of the kernel
as an integrated project. The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this. You might not like my answer, but I will do
everything I can do to stop this.
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?
LeFantome@programming.dev
on 14 Feb 21:19
nextcollapse
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?
LeFantome@programming.dev
on 17 Feb 04:30
collapse
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.
Yes, but asking him in this case was basically a courtesy, the code isn’t going into anything he manages. He can reject it, but that’s an opinion, not a decision. It can still be merged if the regular maintainer (or someone senior like Linus himself) approves.
I already did: maintain your own tree, and prove it out, that it’s better.
If the maintenance load is so light, it’ll be easy work to do, to keep the tree in line with upstream.
If it’s so obviously technically better, people will see it, and more people will push to mainline your tree.
It’s work. And you need to convince others on technical merit. So, do the work.
Just like what folks did with OpenBSD, the grsecurity tree.
FooBarrington@lemmy.world
on 14 Feb 12:30
collapse
The maintainer literally says the issue is that there are two languages. There is no way to convince them, there’s nothing anyone can do.
Which doesn’t help me a bit. Every additional bit that the another
language creeps in drastically reduces the maintainability of the kernel
as an integrated project. The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this.
The maintainer didn’t say “I worry about the maintainability, please prove that it works outside the tree” (this concern was already discussed when the R4L experiment was officially OK’d). They are explicitly saying they’ll block Rust in the kernel, no matter what.
The maintainer literally says the issue is that there are two languages. There is no way to convince them, there’s nothing anyone can do.
Sure there is! Maintain your own tree, like I said. Eventually, it’ll be proven to be workable. Or not.
The maintainer didn’t say “I worry about the maintainability, please prove that it works outside the tree” (this concern was already discussed when the R4L experiment was officially OK’d). They are explicitly saying they’ll block Rust in the kernel, no matter what.
No, they aren’t. They are blocking how it’s being done, with R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with, because they don’t want to build their own C interfaces, that match the already existing ones.
I don’t know how to better explain this to you.
Try to understand the problem better, so maybe you’ll be able to understand why maintaining your own tree to prove the conceptual implementation works, and doesn’t hand maintenance overhead to another party.
FooBarrington@lemmy.world
on 14 Feb 13:27
collapse
Why lie about something so easy to check? Here’s the maintainer himself saying that the issue isn’t “R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with”:
I accept that you don’t want to be involved with Rust in the kernel, which is
why we offered to maintain the Rust abstraction layer for the DMA coherent
allocator as a separate component (which it would be anyways) ourselves.
Which doesn’t help me a bit. Every additional bit that the another
language creeps in drastically reduces the maintainability of the kernel
as an integrated project. The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this. You might not like my answer, but I will do
everything I can do to stop this.
And, again, prove him wrong, maintain a tree that shows it’s workable, and with minimum maintainability concerns. If there truly are minimal maintenance concerns, a separate tree would be quite simple to maintain!
FooBarrington@lemmy.world
on 14 Feb 14:48
collapse
For the last time, the decision to include Rust has already been made. The “prove him wrong by developing out-of-tree” has already happened.
Apparently, it hasn’t happened. Because nobody else beside R4L is helping it along.
Sorry, but ya’ll just have more work to do, is all. Do it, or don’t, I don’t care. I honestly don’t care one iota if Rust ever gets in the kernel, or not. What I do care about is that the Linux kernel remains a stable project.
Take the advice, or don’t. Its on you.
FooBarrington@lemmy.world
on 14 Feb 15:00
collapse
There’s no advice to take for working with maintainers who’ll abuse their power to stop a project they don’t like.
Ok, so then just toss in the towel, and make your own kernel, with hookers, blow, and Rust. Sorry.
Because the only “power” maintainers have is over the Linux kernel tree. They have no power over your own tree you maintain, with your Rust team. They have no power over the Rust kernel projects already working.
Hell, they don’t even have the power to keep you from taking their driver work, to build on! In fact, it’s encouraged!
This may come as a shock to you, and other proponents of the R4L team: The world does NOT revolve around you, and your preferred development language.
FooBarrington@lemmy.world
on 14 Feb 15:50
collapse
Or I can ask Linus to do his job properly and lead on this issue, whether it’s for or against R4L.
You seem to be under the impression that I’m somehow involved with R4L or Rust, or that I even use Rust. None of these are true. I’m just seeing an example of bad project management, and people like you that keep lying to justify the maintainers decision.
Or I can ask Linus to do his job properly and lead on this issue, whether it’s for or against R4L.
Linus owes you, nor anybody not signing his paycheck, a goddamed thing. Did you bother to read the article linked here?
You seem to be under the impression that I’m somehow involved with R4L or Rust, or that I even use Rust.
Ok then.
I’m just seeing an example of bad project management, and people like you that keep lying to justify the maintainers decision.
Nobody committing code to the Linux project, nor anybody doing the administrivia work owes anyone not involved in the project a goddamned thing. If you think you can manage it better, then fork, and do it.
Otherwise, you’re expecting other people to do free labor for you, and to do it to your specs. The world doesn’t work that way, and nobody owes you their labor.
Labor does. Laying out demands on labor does nothing, unless you’re the one meeting their material needs.
FooBarrington@lemmy.world
on 14 Feb 16:43
collapse
Linus owes you, nor anybody not signing his paycheck, a goddamed thing.
No, he owes the community to fulfill his role in this community project. He’s not a king or a monarch or whatever you think he is. If he’s not ready to fulfill this role, he should step down as project lead.
No, he owes the community to fulfill his role in this community project
Not really. He owes nobody his labor. If people don’t like how he runs it, they can fork, and run it as they please.
He’s not a king or a monarch or whatever you think he is.
Of course he’s not. And, neither are you. Neither of you can place demands on others to perform free labor.
If he’s not ready to fulfill this role, he should step down as project lead.
Well, he thinks he is fulfilling his role. You don’t. So, its up to you to show everyone how to do it right.
I’ve found most people who claim others “aren’t doing it right” actually mean that “they aren’t doing it how I want it to be done, and therefore I demand they do the work per my spec, even though I’m not meeting any of their material needs.”
You’ve brought this up in several comments. given the situation, what do you think is the answer to replacing a huge c codebase with rust under the specific conditions of Linux development (open source, overwhelmingly maintained by 9-5 lifers employed by disparate organizations, in use everywhere for everything) when maintainers say they’ll oppose it?
Microsoft made the news a year or so ago announcing a rewrite of some libraries in rust, but conditions and limitations in Redmond are very different than those faced by the kernel team.
FooBarrington@lemmy.world
on 14 Feb 13:55
collapse
given the situation, what do you think is the answer to replacing a huge c codebase with rust under the specific conditions of Linux development (open source, overwhelmingly maintained by 9-5 lifers employed by disparate organizations, in use everywhere for everything) when maintainers say they’ll oppose it?
Nobody is trying to replace a huge C codebase.
The project lead OK’d the R4L experiment (which, again, is NOT about replacing C). Why should individual maintainers be able to completely block this outside their own subsystems?
What im building towards is: if r4l isn’t about replacing c code then it doesn’t need to be in the kernel. If its about replacing c code (which it absolutely should be, that’s the whole point of memory safe languages like rust) then r4l people need to have a clear process and understanding of how they expect to accomplish that goal and be open about it.
FooBarrington@lemmy.world
on 14 Feb 15:30
collapse
So why can’t rust modules use the c bindings?
They can, if wrappers are written. These wrappers were blocked by a maintainer.
What im building towards is: if r4l isn’t about replacing c code then it doesn’t need to be in the kernel.
Why? It needs to be in the kernel for new code to get written in Rust. Why can it only be in the kernel if the goal is to replace existing code?
r4l people need to have a clear process and understanding of how they expect to accomplish that goal and be open about it.
This is where you lose me. I’m not a good programmer or a very smart person, but I have enough experience with c, c++ and rust to know that those wrappers don’t need to be in the kernel if the kernel has c bindings.
If I were writing something in rust I could just include the r4l wrapper for the kernels c bindings and everything would work fine. The wrapper doesn’t need to be in the kernel.
There’s a fundamental disconnect here. When people speaking about r4l including official statements from the r4l project say “our plan to add rust, a language intended to address shortcomings of c, to the kernel is only for new code, not a rewrite of existing systems.” I don’t believe them.
Not only do supporters of and contributors to the r4l project make offhanded remarks about how different things would be better if they were written in rust but if they truly believed in the language’s superiority to c then they would be trying to replace existing c code with rust.
Then the whole rust using and supporting world melts down when people oppose adding it into an existing huge c codebase.
Then they all complain that they’re being discriminated against for “nontechnical reasons”, which is becoming a great dog whistle for if you should just disregard someone’s opinion on rust outright.
Perhaps that explains some of why I don’t believe rust people when they flip out over not being allowed to do the thing that no one else is allowed to do either.
FooBarrington@lemmy.world
on 14 Feb 16:27
collapse
but I have enough experience with c, c++ and rust to know that those wrappers don’t need to be in the kernel if the kernel has c bindings.
I think you have a fundamental misunderstanding of the topic.
If I were writing something in rust I could just include the r4l wrapper for the kernels c bindings and everything would work fine. The wrapper doesn’t need to be in the kernel.
We’re talking about device drivers, which are part of the Linux kernel. If you develop these wrappers outside the kernel tree, you’re making the situation even worse, since the kernel suddenly has a new dependency.
This approach was never considered, even by the maintainers that blocked wrappers, because it would be far worse than every other possibility.
Instead the question is: does every driver have to include a copy of the wrapper, or can there be one copy that’s used by all the drivers? And obviously one copy makes far more sense than N different copies.
I’ll skip over the rest of your comment, since it all seems to be built on a broken foundation.
Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!
That’s how you get things added to the kernel!
If it was about adding rust code to the kernel, which is what r4l universally says they’re doing, then they’d be taking that approach instead of farting around with the chicken and egg problem trying to get rust everything first.
That’s the whole point of the part of my comment that you dismissed out of hand. They’re nearly universally behaving in a way that it takes actual concerted brainpower to read as anything other than duplicitous.
And then when people say “hey, why don’t you not act like that” you get responses like “Linus said we could!” And “nontechnical nonsense” and “Dino devs”.
I don’t think that’s a broken foundation.
FooBarrington@lemmy.world
on 14 Feb 18:27
collapse
Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!
That is what they are already doing and it’s introducing unnecessary work! There’s nothing about “hypothetical rust drivers”, it’s the case right now.
That’s how you get things added to the kernel!
Weird, how come C drivers don’t have to track these interfaces in their own trees? Why is this the way to get Rust code added to the kernel, but all other code doesn’t have to jump through these hoops?
I’m not at a computer with the source on it, so if you get to it before me, how many rust drivers are there? How many that would use the rust dma wrapper?
I ask because last year there were relatively few.
People writing in c don’t have to use a wrapper because there’s no need to wrap c code for use by other c code.
More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.
FooBarrington@lemmy.world
on 14 Feb 19:38
collapse
I’m not at a computer with the source on it, so if you get to it before me, how many rust drivers are there? How many that would use the rust dma wrapper?
… of course there aren’t many Rust drivers so far, since the project is still young, and it’s evidently still facing hurdles and not really accepted by everyone. But if there’s already a couple of Rust drivers and Rust has explicitly been accepted into the Kernel, we’re already past your “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future”, so why argue such irrelevant points?
More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.
They are not irrelevant points and hopefully I can show why.
So I went fishing through the kernel rust directory and didn’t find any drivers. It’s late and I definitely missed a lot (I didn’t even go through the drivers branch, but should rust code be there? I thought it all lived in /rust…), but the r4l page lists the nvme driver, an implementation of existing functionality in rust that is in the words of its description page “not suitable for general use”. The r4l page also has the null block driver, which is not a strictly speaking useful thing for actually doing stuff with the computer but is a great way to do a bunch of goofy crap and its page on the r4l website explains why it’s being rewritten in rust.
I just want to pause here in the comment and say that the null block driver is actually a phenomenal thing to be rewriting in rust for so many reasons.
Then there’s the android binder driver which is not something I understand enough to comment on, but is a rewrite in rust. I also saw a puzzlefs driver on the r4l page. Puzzlefs is an experimental file system written in rust to begin with so it’s no surprise the Linux driver is rust.
Last the r4l page offers two gpu drivers, the apple one that asahi uses and the nvidia nova one which seems to be in the early stages of development.
As I said, I probably missed some drivers and other rust code that needs to use —since it’s our topic of discussion— the c dma bindings through a wrapper.
But if all six of those used the dma c bindings wrapper then that’s still far short of my agreement with you that the right way would be to write a bunch of good rust shit that uses the wrapper then say “hey, if we move this wrapper into dma directly it’ll save 10k lines of code because it’s a hundred lines and used in a hundred things”.
Instead it’s used by three rewrites (the point of r4l!), an experimental file system, a in development gpu driver and the asahi mac driver.
For a third time, I’m absolutely 100% sure there’s more rust drivers than that, but enough to make the argument that you’re taking a hundred lines out of a hundred places?
When I was younger I was involved in local government. I was idealistic and thought that having been accepted at the table, the correctness of my ideas would be evident and they would be accepted and implemented quickly. Of course I was very wrong and was surrounded by competing interests vying for limited resources so the force of my argumentation had almost no effect.
What was effective was constructing scenarios that made it almost impossible for people to act in ways other than what I wanted.
I chose a narrative analogous to the common rust person complaint of “political reasons” here on purpose because ultimately instead of appealing to an authority to settle the chicken or egg problem for them (which is somehow not political, despite the authority existing within some governing structure but whatever!) rust devs should be saying “who the fuck cares, I’m headed to market with a cartload of chickens and eggs, you gonna give me a stall to sell out of or am I gonna be clogging up the thouroughfares?”
LeFantome@programming.dev
on 14 Feb 21:30
collapse
If we are going to be honest, let’s not be misleading.
Nobody is looking to replace C in the kernel just to switch out the language. This is not a “rewrite it in Rust” initiative.
What the R4L folks want is to be able to write “new” code in Rust and for that code to call into the C parts of the kernel in an idiomatic way (idiomatic for Rust). So they need to create Rust interfaces (which they, the R4L side, are doing). This whole controversy is over such an example.
At this point, we are talking about platform specific drivers.
Now, new kernel code is written all the time. Sometimes newer designs replace older code that did something similar. So yes, in the future, that new code may be written in Rust and replace older code that was written in C. This will be a better design replacing an inferior one, not a language rewrite for its own sake.
Core kernel code is not getting written in Rust for a while though I do not think. For one thing, Rust does not have broad enough architecture support (platforms). Perhaps if a Rust compiler as part of GCC reaches maturity, we could start to see Rust in the core.
That is not what is being talked about right now though. So, it is not a reasonable objection to current activity.
I don’t know if the code marcan was talking about is still going to be merged. It wasn’t actually being blocked, but that doesn’t mean it was approved either.
So, not blocked, merged in, already maintaining a tree, just one maintainer isn’t sold yet on the implementation.
Im just not seeing a problem then? Aside from the person experiencing burnout, which I get. But burnout may not indicate a cultural problem, either. Especially if the person is coming off of a rough year, personally.
LeFantome@programming.dev
on 15 Feb 21:00
collapse
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.
DieserTypMatthias@lemmy.ml
on 14 Feb 09:12
nextcollapse
Or just boycott Linux and use Redox if you like Rust.
patatahooligan@lemmy.world
on 14 Feb 11:58
nextcollapse
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.
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.
LeFantome@programming.dev
on 14 Feb 21:17
collapse
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.
syklemil@discuss.tchncs.de
on 14 Feb 17:33
collapse
Thing is, there is already Rust in Linux, and Torvalds wants more, faster. He’s being sabotaged by C purists, who at this point should stop acting unprofessionally, or at the very least make their own “only C” fork if they disagree with his leadership so much.
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.
DarkDarkHouse@lemmy.sdf.org
on 14 Feb 09:32
collapse
Don’t desktop environments e.g., GNOME, KDE, fit the bill here? Sure they have their problems, but they are IMO about as polished as macOS or Windows.
I agree that GNOME and KDE are gorgeous and very polished in many ways. However, I have had some problems in GNOME, Fedora, or Open Suse:
fractional scaling is not immediately available in Fedora or OpenSuse, at least to users who don’t know how to use the terminal [Edit: Thanks, DannyBoys for pointing out that Ubuntu may have fractional scaling enabled by default and that experimental fractional scaling on GNOME can be activated, at a battery cost]
the track-pad two-finger scrolling is painful (compared to a Mac) to me and to people who have used my laptop with Fedora or OpenSuse
sometimes it’s hard for me to get software, especially outside of .debs. For example, in Fedora I had trouble getting Signal Desktop installed from a source that I felt comfortable with (maybe this speaks to my ignorance in how Fedora packages are set up and distributed more than the reality of insecurity, but even this is part of the issue: I couldn’t find any reassurance). To be fair, Open Suse gave me that reassurance, because I understood that YAST was somehow more directly tied to the source (I could be wrong, but that was my impression). However, YAST’s software download software is a far cry from the kind of UX that the GNOME Software app is or the Apple App Store.
Despite these problems, I do have to say that GNOME is absolutely gorgeous. It’s precisely the kind of user-centricity that I want to see in Linux.
However, the end-users aren’t the only users. There are also developers! For example, I remember listening to the developer of the Mojo language talking with Richard Feldman, and the developer said that the development of the Swift language made it clear to him that Apple is aggressively user-centric. I don’t doubt that there are many problems with Swift as with Apple products in general, but I don’t see that kind of discourse in Linux coming from the main maintainers. Instead, there seems to be a vanguard arguing for a better developer experience (such as writing kernel code in Rust), and they find loads of friction. Heck, key developers are leaving Linux!
Edit: Clarified what is strictly my interpretation.
Yup. Modern MacOS is only pleasant to use if you have absolutely no preferences on how your computing environment should work and am willing to completely accept the walled garden.
Fair enough. Now that I think about it, maybe the developer experience in Apple products are not universally lauded.
For example, I remembered Pirate Software saying that he didn’t develop for Mac because it was a pain, including having to pay Apple $100 yearly to distribute code without issues. Additionally, I remember my brother meeting a Spotify developer, and the Spotify developer said that Apple makes great hardware but lackluster software.
At the same time, it seems like Swift is not a hated language. The 2023 and 2024 Stack Overflow developer survey reports that, even though few people use Swift (~5% of developers), there’s ~60% of admiration for the language.
DannyBoy@sh.itjust.works
on 14 Feb 16:07
nextcollapse
I’ve been using fractional scaling on my laptop with GNOME since I installed it about four years ago. It’s a bit heavy on battery usage but it’s worked as expected for all this time.
Oh. I see I was wrong. Amazing. I should look into that! How did you enable it? I did a quick search and found I just need to do gsettings set org.gnome.mutter experimental-features “[‘scale-monitor-framebuffer’]”; is that it?
I’m sorry for having said something untrue. For example, DannyBoy points out that GNOME and whatever Ubuntu uses do have fractional scaling.
However, is my experience untrue? Was I lying when I said that my track-pad two-finger scrolling is frustrating? Furthermore, it’s not unusual for people at work to try my track-pad and it being way too sensitive or too un-sensitive, but no in between.
Was I lying when I said that, for me, it’s hard to get software? Was I lying when I said that maybe this is a skill issue on my part, but even that is indicative of a lack of easy ways of getting reassurance in the way that Apple makes it easy to find software in their App Store?
Was I lying when I said that, to me, GNOME is gorgeous?
Was the creator of the Mojo language lying when he recounted his experience developing Swift?
Was I lying when I said that developers are leaving Linux?
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.
LeFantome@programming.dev
on 14 Feb 16:33
collapse
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.
refalo@programming.dev
on 14 Feb 22:10
nextcollapse
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.
LeFantome@programming.dev
on 15 Feb 20:48
collapse
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.
JuxtaposedJaguar@lemmy.ml
on 14 Feb 22:46
collapse
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.
LeFantome@programming.dev
on 15 Feb 20:46
collapse
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.
JuxtaposedJaguar@lemmy.ml
on 16 Feb 02:21
collapse
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.
LeFantome@programming.dev
on 17 Feb 02:48
collapse
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.
JuxtaposedJaguar@lemmy.ml
on 18 Feb 04:30
collapse
I didn’t include the social media “brigading” portion because Linus already addressed that in a different sub-thread.
threaded - newest
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.
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.
If this person was given a grant or funding via a kickstarter or something I would agree with the obligation idea, but donations are exactly that, a voluntary gift to the dev for the work they have done so far and may continue to do in the future. There are no “moral obligations” to continue the project.
Wow. The entitlement… maybe learn what a donation means
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.
Wtf is wrong with these people?
kiwifarmers got on his ass
entitlement and/or astro-turfing imo
Ikr
Isn’t this the guy who got called out for trying to use social media brigading to force Linux kernel rust patches through? There’s a good chance those stalkers are fictional.
The very same, yes.
If you are replying with “isn’t this the guy” it means you didn’t bother to read the post, which also removes the merits of you questioning if what he is claiming is fiction or not.
But people on HN provided context and it indeed seem he was stalked and harassed, but through his VTuber persona and there was even a GDocs document with the details.
Edit: His VTuber persona is Asahi Lina
Slightly OT but I always thought Asahi Lina was a woman. TIL.
It’s never been confirmed that they are the same person, and they both operate as if they are completely separate people. Lina goes by she/her on stream as well.
yet you claim marcan is lina with zero proof?
I’d much rather see them commit their talent towards more open hardware. Apple hardware isn’t even that good.
I think it’s important to see these types of efforts, while I’ll never go out and buy a MacBook the effort isn’t wasted since it gives current users more freedom and future people buying used laptops more options for Linux compatible hardware.
Without a project like this, that hardware will end up being e-waste a lot sooner than it should be, when Apple drops support. At least to me I see an ethical and moral imperative for projects like this, but I also understand people’s grievances with Apple.
If people can use Linux on their Apple hardware after macOS stops supporting it, it keeps them from having to buy new Apple hardware a little longer.
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.
fuck gatekeepers. the linux kernel doesn’t deserve new, talented people bringing fresh, useful and modern approaches to the project; their time and effort is only wasted there. i know it’s not right, but part of me wishes linux rots and something better takes its place.
bitterness aside, i hope marcan gets the rest he needs. i wish him the best.
In short, you’re for the “make a new kernel from scratch” plan. It’s okay to just say that without being hateful on the competition.
There are already several Rust Kennel From Scratch projects that are reasonably progressed. Redox is one, Asterinas is another.
The latter is I think aiming for Linux ABI compatibility.
I had never hard of Asterinas, but this sounds like a the best approach to me. I believe alternative OS’s need to act as (near) drop-in replacements if they want to be used as daily drivers. ABI-incompatible alternatives might be fine for narrower use cases, but most people wouldn’t even try out a desktop OS that doesn’t support most of the hardware and software they already use.
Speaking of his Wii homebrew work,
He wasn’t on whatever team that released a tool that asked “Oh hey just asking do you intend to run pirated games? Just need to know for setup” then soft bricking the console if you say yes?
I read the “thin blue line” email and it seems… reasonable and sensible? And seeing how he is so appaled by it makes me question his judgement a bit.
knowing where “thin blue line” comes from, you don’t see anything wrong with a maintainer randomly dropping it on the mailing list?
Alright, fair. I was more refering to the content of the message, not the (botched) metaphore of maintainers as a force of order.
ah, fair enough. i guess that’s kind of the thing with potential dogwhistles. if you know, you know.
archive.org/details/thethinbluelinecomplete
Starring Rowan Atkinson
Its simply the Police in general…
You scrolled half a wiki page to the part that fits your narrative.
The metaphor of a thin blue line is that they “the police” are not in the typical sense very large, like an army, but they do keep the order with a thin presence of rule and order. Sounds like what maintainers do in this case.
i scrolled half a wiki page to link to… facts.
That’s not where “it comes from” though. Since if it were,it wouldnt need to be half a page down.
It’s associated yes, but not in everybodies mind is that the case.
You imply it comes from:
But you link to a Wikipedia article that says:
I have no idea about this guy’s politics, but it’s a pretty well known phrase with a lot of different contexts.
we don’t live in the 80s though. we live in contemporary times where things have different now meanings to what they did 40 years ago. meanings that might be influenced by recent happenings. hope that helps!
You’re the one who brought up the origin of the term, why would you do that if you’re wanting to refer to the contemporary meaning?
This is just being disingenuous. They clearly mean the origin of the current usage, which is rooted in police “sheepdog” ideology and all that fascist bullshit. Not that the old usage was much better considering the state of police gangs in LA and the kind of laws they were enforcing in the 60s.
I usually see “thin blue line” (and the flag) used by reactionaries, racists, and white nationalists. Especially since BLM. Don’t know what sort of politics Ts’o has, other than he’s probably not an anarchist (ACAB!), but I guess (benefit of the doubt and all) he could be some ignorant lib with a head full of copaganda, so getting out the code of conduct for racist dogwhistles might be a bit premature.
It comes from The Thin Red Line, which is about some Scottish regiment standing up to a Russian cavalry charge. Even if you don’t know that, it seems quite obviously a military metaphor, and that indicates a militaristic view of what policing should be like, veneration of the police as heroes, and total ignorance about what the police actually are and do.
That’s highly subjective. Remember this is a global resource with environments different from your own.
I fail to see how anyone could interpret what can only refer to holding the line as not a heroic act and a military metaphor. And that’s how it’s used, and that’s what it means, and that’s where it comes from.
And Ts’o clearly knows this as well, since it he appropriately uses it as a metaphor for keeping chaos at bay and out of the kernel.
A thin line between chaos and order. That line is blue if it’s the police.
Tell me you are only familiar with stuff going on with the US and nowhere else without telling me.
How does this comment say anything about that?
Its literally the first thing in the wiki page. “Line” between apposing forces is the “order”. ie Mantainers in this case.
The first time I heard the phrase was from a TV show with Mr Bean when I was like 9 or 10.
As another commenter said, I think the article guy is a bit sensitive or took it the wrong way, since “the thin blue line” when talking about maintainers is very much like they are acting as defense to “outside” forces. Whether that is good or bad for Linux, is debated.
In the same way a swastika is no longer linked to an ancient peace symbol.
You’re talking about the US police. A lot of the world have police forces that serve the people.
I’m not just talking about the US police. I’ve never been to the US, and I assure you the police is shit here too. Ts’o is American, and that “thin blue line” saying seems especially American or Anglo. I’ve never heard that over here. So I’m not sure how that’s even relevant to the discussion.
BLM and ACAB are very American centric movements/sentiments. Hence why I took your comments to be American focused.
Whilst I’ve heard the phrase “thin blue line” before, it’s never been something associated with racist overtones or subjugative ones in my experience. More that the police is a small community protecting the larger population.
As such, someone using it context of not allowing the proliferation something is reasonable, if possibly histrionic in this case.
Going to need you to cite your sources on that one. …com.au/…/62e5fad93d835c9f432923375e5e833d
A few months ago (Oct 18 2024) Linus and his sidekick signing the kernel, not only admitted they were going to comply with US Stat.Dep. doctrine and remove developers (on long term good standing) on the basis of nationality and national origin of the employers, they exploded into a rant, clearly admitting to being nationalist and in distrorting history to fit their rhetoric. In greenwashing nationalism (you can say racism underlying this national hate speech) into the base of most open and free code, nationalism now is not free as in beer it is free as in “freedom”? This is as large of a difference as socialism and ethno-socialism.
The linux community … the end user … DOESN’T give a damn, only wants the latest and badest of development in his gaming machine.
Once you make a slip and slide exception you can’t prevent any more in the future. First will be “justified nationalism”, then “not so justified racism”, then “sexism”, then will be the gas chambers for anyone who forks anything away from Führera (Fedora + Führer).
If using any kernel later than 10 18 2024 I see it as the nationalist/racist fork. I expect the original to continue by developers who don’t use race/ethnicity/gender as a basis for accepting/rejecting contributors.
Are you referring to the time they kicked out a bunch of people employed by the companies associated with the Russian government and that are under direct sanctions for supporting the war?
People are not under sanctions, and no linux developer worked for the Russian government, and since when has a war affected who works on what open source project. There are wars all over the place all the damn time …
I am not talking about the sanctions, I am talking about the additional remarks on how nationalist and racist both the leaders of the project appeared to be from their statements.
Companies are under sanctions. Companies that are connected to the Russian government. Government that is actively wages a terrible unjust war. A war that shouldn’t happen.
People who are working in those companies were banned for the duration of them working for and supporting companies that are under sanctions.
If that’s a problem for you you are being obtuse either on purpose or, I hope, because you’re underinformed.
This war was forced into Russia due to the blocking and surrounding it with NATO bases clearly against it, and by trying to block and substitute its primary exports to EU.
The violent overthrow of the then democratic government in Ukraine, the arming, training, and directing a Neo-Nazi para-military unit to take over, after forcing half the political parties in being illegal, had nothing to do with Russia. If there is someone underinformed, confused, and lacking historical facts it is not me, and better change your arrogant tone if you seriously want to discuss something and not just throw propaganda mud.
Oh, here it is. I was waiting when the pretense will go away. 15 рублей получишь в кассе.
if you have a rational argument please translate it, if you have run out respect the rest of the discussion and keep it in English
I had zero respect for putinsuckers from the beginning, and since you just outed yourself as one, this “discussion” ended.
Don’t take me wrong, I hate Putin just as much as I hate Biden or Trump, don’t misinterpret what I say
But between hating Trump and discriminating against you because you are from Nebraska is the difference between a racist and a non-racist …
Something the linux-duo-Fins can not separate, hence their delirium with nationalist rhetoric and lack of historical understanding.
I think your wires finally crossed. This was the response of a madman.
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.
who does? are you talking about marcan? because as far as i can see, what they’re asking for is for linus to make a stance and actually say whether R4L is a thing they want or not. because linus’ attitude so far has been “let’s wait and see” which hasn’t been all that helpful, as said in the blog post.
Ultimately Linus’ opinion here does not matter in the positive. He can say Rust in kernel is good, but that does not summon the skill and work to make it happen. He can say it’s bad and quash it, at the potential expense of Linux’s future. His position of avoiding an extreme is a pragmatic one. “Let them come if they may, and if they do not it was less a loss for us.”
see, i could maybe agree with this if it weren’t for the amazing work from R4L that already has been and continues to be done, despite subsystems maintainers putting their foot down and going “Not In My Back Yard, bucko!”. how many more maintainers does R4L have to lose before Linus realizes he might need to take a stance as a project lead?
Linus can merge whatever patches he wants to, and the stonewalling subsystem maintainers would have to deal with it–like he did with the eBPF scheduler. R4L maintainers already wrote the patches, they literally just needed to be merged.
“Let’s wait and C”.
aughhhhhh here’s your upvote. git out.
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.
It’s also his legitimate choice to wait. He can’t see the best way forward and is deciding to wait on his decission or let the community decide instead of him. As much as we like to think of him as autocrat in some way, he respects people that work on kernel and he respects their time. The smartest move is often to wait on a decision. And even if it’s not a smartest move in this case, it can still be better than making a wrong decission that will demoralize the community even more.
Isn’t it reasonable for a maintainer to say “no rust here” when they don’t know rust, don’t want to learn it, and have decades of experience in C, and are maintaining that part of the system
Yes.
But that’s not what’s happening here. The guy who said no is not the maintainer of the rust code, and is not expected to touch the rust code at all.
The project has said it is a goal to move to a dual language model. So, no, it is not reasonable.
What would be reasonable would be technical arguments or pragmatic logistical concerns with the goal of finding solutions. What would be reasonable would be asking for and accepting help.
None of the reasonable stuff is happening. So, it not reasonable.
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.
Then rust isn’t going to happen in every area of the kernel yet
Which means unnecessary duplication of code, because every driver has to track kernel Interfaces separately. Why? What’s the advantage?
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 you quote where that was said?
I’ve been following this debate for a bit and as far as I can tell it’s not so much that they’ll do what they can to keep rust out but more to make sure that the people who want to develop in rust are the ones who end up maintaining that part of the code and not the current maintainers.
Sure: lore.kernel.org/…/20250131075751.GA16720@lst.de/
Can’t get more explicit than this.
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.
Yes, but asking him in this case was basically a courtesy, the code isn’t going into anything he manages. He can reject it, but that’s an opinion, not a decision. It can still be merged if the regular maintainer (or someone senior like Linus himself) approves.
It will happen via it being better, and being shown to be better. And it will take time to unseat 30 years of C.
Not if they’re being prevented from showing to be better by C devs who, literally, “will do everything [they] can do to stop this”.
Nobody is trying to unseat 30 years of C.
Nobody prevents anyone from maintaining their own tree, thereby proving it works.
And yes, Rust is trying to replace C, in the kernel. Let’s start off by being honest here, k?
Yet the Linux project officially OK’d the R4L experiment, so why does this stuff still have to be kept out-of-tree?
No, Rust is not trying to replace C in the kernel.
Sure, why don’t you give it a try?
Yes, it’s been ok’d. That means it’s ok to go in, once proven.
So, R4L peeps need to figure out how to convince maintainers that is works.
So, go do it?
How do you convince a maintainer that NACKs a PR outside his subsystem while explicitly saying:
Please explain how one can convince such an individual.
I already did: maintain your own tree, and prove it out, that it’s better.
If the maintenance load is so light, it’ll be easy work to do, to keep the tree in line with upstream.
If it’s so obviously technically better, people will see it, and more people will push to mainline your tree.
It’s work. And you need to convince others on technical merit. So, do the work.
Just like what folks did with OpenBSD, the grsecurity tree.
The maintainer literally says the issue is that there are two languages. There is no way to convince them, there’s nothing anyone can do.
The maintainer didn’t say “I worry about the maintainability, please prove that it works outside the tree” (this concern was already discussed when the R4L experiment was officially OK’d). They are explicitly saying they’ll block Rust in the kernel, no matter what.
I don’t know how to better explain this to you.
Sure there is! Maintain your own tree, like I said. Eventually, it’ll be proven to be workable. Or not.
No, they aren’t. They are blocking how it’s being done, with R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with, because they don’t want to build their own C interfaces, that match the already existing ones.
Try to understand the problem better, so maybe you’ll be able to understand why maintaining your own tree to prove the conceptual implementation works, and doesn’t hand maintenance overhead to another party.
Why lie about something so easy to check? Here’s the maintainer himself saying that the issue isn’t “R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with”:
And, again, prove him wrong, maintain a tree that shows it’s workable, and with minimum maintainability concerns. If there truly are minimal maintenance concerns, a separate tree would be quite simple to maintain!
For the last time, the decision to include Rust has already been made. The “prove him wrong by developing out-of-tree” has already happened.
Apparently, it hasn’t happened. Because nobody else beside R4L is helping it along.
Sorry, but ya’ll just have more work to do, is all. Do it, or don’t, I don’t care. I honestly don’t care one iota if Rust ever gets in the kernel, or not. What I do care about is that the Linux kernel remains a stable project.
Take the advice, or don’t. Its on you.
There’s no advice to take for working with maintainers who’ll abuse their power to stop a project they don’t like.
Ok, so then just toss in the towel, and make your own kernel, with hookers, blow, and Rust. Sorry.
Because the only “power” maintainers have is over the Linux kernel tree. They have no power over your own tree you maintain, with your Rust team. They have no power over the Rust kernel projects already working.
Hell, they don’t even have the power to keep you from taking their driver work, to build on! In fact, it’s encouraged!
This may come as a shock to you, and other proponents of the R4L team: The world does NOT revolve around you, and your preferred development language.
Or I can ask Linus to do his job properly and lead on this issue, whether it’s for or against R4L.
You seem to be under the impression that I’m somehow involved with R4L or Rust, or that I even use Rust. None of these are true. I’m just seeing an example of bad project management, and people like you that keep lying to justify the maintainers decision.
Linus owes you, nor anybody not signing his paycheck, a goddamed thing. Did you bother to read the article linked here?
Ok then.
Nobody committing code to the Linux project, nor anybody doing the administrivia work owes anyone not involved in the project a goddamned thing. If you think you can manage it better, then fork, and do it.
Otherwise, you’re expecting other people to do free labor for you, and to do it to your specs. The world doesn’t work that way, and nobody owes you their labor.
Labor does. Laying out demands on labor does nothing, unless you’re the one meeting their material needs.
No, he owes the community to fulfill his role in this community project. He’s not a king or a monarch or whatever you think he is. If he’s not ready to fulfill this role, he should step down as project lead.
Not really. He owes nobody his labor. If people don’t like how he runs it, they can fork, and run it as they please.
Of course he’s not. And, neither are you. Neither of you can place demands on others to perform free labor.
Well, he thinks he is fulfilling his role. You don’t. So, its up to you to show everyone how to do it right.
I’ve found most people who claim others “aren’t doing it right” actually mean that “they aren’t doing it how I want it to be done, and therefore I demand they do the work per my spec, even though I’m not meeting any of their material needs.”
You’ve brought this up in several comments. given the situation, what do you think is the answer to replacing a huge c codebase with rust under the specific conditions of Linux development (open source, overwhelmingly maintained by 9-5 lifers employed by disparate organizations, in use everywhere for everything) when maintainers say they’ll oppose it?
Microsoft made the news a year or so ago announcing a rewrite of some libraries in rust, but conditions and limitations in Redmond are very different than those faced by the kernel team.
Nobody is trying to replace a huge C codebase.
The project lead OK’d the R4L experiment (which, again, is NOT about replacing C). Why should individual maintainers be able to completely block this outside their own subsystems?
Okay so if the point of the rust for Linux project isn’t to replace c code with rust then what is the point?
I understand the project maintains a coy line regarding that question but let’s be serious for a second and really consider why r4l is happening.
The purpose is to allow new modules to be written in Rust, not to replace C code. Why are you acting like you don’t know this already?
So why can’t rust modules use the c bindings?
What im building towards is: if r4l isn’t about replacing c code then it doesn’t need to be in the kernel. If its about replacing c code (which it absolutely should be, that’s the whole point of memory safe languages like rust) then r4l people need to have a clear process and understanding of how they expect to accomplish that goal and be open about it.
They can, if wrappers are written. These wrappers were blocked by a maintainer.
Why? It needs to be in the kernel for new code to get written in Rust. Why can it only be in the kernel if the goal is to replace existing code?
They do!
This is where you lose me. I’m not a good programmer or a very smart person, but I have enough experience with c, c++ and rust to know that those wrappers don’t need to be in the kernel if the kernel has c bindings.
If I were writing something in rust I could just include the r4l wrapper for the kernels c bindings and everything would work fine. The wrapper doesn’t need to be in the kernel.
There’s a fundamental disconnect here. When people speaking about r4l including official statements from the r4l project say “our plan to add rust, a language intended to address shortcomings of c, to the kernel is only for new code, not a rewrite of existing systems.” I don’t believe them.
Not only do supporters of and contributors to the r4l project make offhanded remarks about how different things would be better if they were written in rust but if they truly believed in the language’s superiority to c then they would be trying to replace existing c code with rust.
Then the whole rust using and supporting world melts down when people oppose adding it into an existing huge c codebase.
Then they all complain that they’re being discriminated against for “nontechnical reasons”, which is becoming a great dog whistle for if you should just disregard someone’s opinion on rust outright.
Perhaps that explains some of why I don’t believe rust people when they flip out over not being allowed to do the thing that no one else is allowed to do either.
I think you have a fundamental misunderstanding of the topic.
We’re talking about device drivers, which are part of the Linux kernel. If you develop these wrappers outside the kernel tree, you’re making the situation even worse, since the kernel suddenly has a new dependency.
This approach was never considered, even by the maintainers that blocked wrappers, because it would be far worse than every other possibility.
Instead the question is: does every driver have to include a copy of the wrapper, or can there be one copy that’s used by all the drivers? And obviously one copy makes far more sense than N different copies.
I’ll skip over the rest of your comment, since it all seems to be built on a broken foundation.
Yes, literally include the wrapper code in every rust driver that needs it then when you push the wrapper on its own you can say “this code is currently duplicated 900 times because there isn’t a rust wrapper” not “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future” and no one will bat an eye!
That’s how you get things added to the kernel!
If it was about adding rust code to the kernel, which is what r4l universally says they’re doing, then they’d be taking that approach instead of farting around with the chicken and egg problem trying to get rust everything first.
That’s the whole point of the part of my comment that you dismissed out of hand. They’re nearly universally behaving in a way that it takes actual concerted brainpower to read as anything other than duplicitous.
And then when people say “hey, why don’t you not act like that” you get responses like “Linus said we could!” And “nontechnical nonsense” and “Dino devs”.
I don’t think that’s a broken foundation.
That is what they are already doing and it’s introducing unnecessary work! There’s nothing about “hypothetical rust drivers”, it’s the case right now.
Weird, how come C drivers don’t have to track these interfaces in their own trees? Why is this the way to get Rust code added to the kernel, but all other code doesn’t have to jump through these hoops?
I’m not at a computer with the source on it, so if you get to it before me, how many rust drivers are there? How many that would use the rust dma wrapper?
I ask because last year there were relatively few.
People writing in c don’t have to use a wrapper because there’s no need to wrap c code for use by other c code.
More broadly there are times when duplicated c code has been condensed into a library or something and added to the kernel.
… of course there aren’t many Rust drivers so far, since the project is still young, and it’s evidently still facing hurdles and not really accepted by everyone. But if there’s already a couple of Rust drivers and Rust has explicitly been accepted into the Kernel, we’re already past your “this would make it easier for hypothetical rust drivers that might hypothetically exist in the future”, so why argue such irrelevant points?
And that’s what has been blocked here…
They are not irrelevant points and hopefully I can show why.
So I went fishing through the kernel rust directory and didn’t find any drivers. It’s late and I definitely missed a lot (I didn’t even go through the drivers branch, but should rust code be there? I thought it all lived in /rust…), but the r4l page lists the nvme driver, an implementation of existing functionality in rust that is in the words of its description page “not suitable for general use”. The r4l page also has the null block driver, which is not a strictly speaking useful thing for actually doing stuff with the computer but is a great way to do a bunch of goofy crap and its page on the r4l website explains why it’s being rewritten in rust.
I just want to pause here in the comment and say that the null block driver is actually a phenomenal thing to be rewriting in rust for so many reasons.
Then there’s the android binder driver which is not something I understand enough to comment on, but is a rewrite in rust. I also saw a puzzlefs driver on the r4l page. Puzzlefs is an experimental file system written in rust to begin with so it’s no surprise the Linux driver is rust.
Last the r4l page offers two gpu drivers, the apple one that asahi uses and the nvidia nova one which seems to be in the early stages of development.
As I said, I probably missed some drivers and other rust code that needs to use —since it’s our topic of discussion— the c dma bindings through a wrapper.
But if all six of those used the dma c bindings wrapper then that’s still far short of my agreement with you that the right way would be to write a bunch of good rust shit that uses the wrapper then say “hey, if we move this wrapper into dma directly it’ll save 10k lines of code because it’s a hundred lines and used in a hundred things”.
Instead it’s used by three rewrites (the point of r4l!), an experimental file system, a in development gpu driver and the asahi mac driver.
For a third time, I’m absolutely 100% sure there’s more rust drivers than that, but enough to make the argument that you’re taking a hundred lines out of a hundred places?
When I was younger I was involved in local government. I was idealistic and thought that having been accepted at the table, the correctness of my ideas would be evident and they would be accepted and implemented quickly. Of course I was very wrong and was surrounded by competing interests vying for limited resources so the force of my argumentation had almost no effect.
What was effective was constructing scenarios that made it almost impossible for people to act in ways other than what I wanted.
I chose a narrative analogous to the common rust person complaint of “political reasons” here on purpose because ultimately instead of appealing to an authority to settle the chicken or egg problem for them (which is somehow not political, despite the authority existing within some governing structure but whatever!) rust devs should be saying “who the fuck cares, I’m headed to market with a cartload of chickens and eggs, you gonna give me a stall to sell out of or am I gonna be clogging up the thouroughfares?”
If we are going to be honest, let’s not be misleading.
Nobody is looking to replace C in the kernel just to switch out the language. This is not a “rewrite it in Rust” initiative.
What the R4L folks want is to be able to write “new” code in Rust and for that code to call into the C parts of the kernel in an idiomatic way (idiomatic for Rust). So they need to create Rust interfaces (which they, the R4L side, are doing). This whole controversy is over such an example.
At this point, we are talking about platform specific drivers.
Now, new kernel code is written all the time. Sometimes newer designs replace older code that did something similar. So yes, in the future, that new code may be written in Rust and replace older code that was written in C. This will be a better design replacing an inferior one, not a language rewrite for its own sake.
Core kernel code is not getting written in Rust for a while though I do not think. For one thing, Rust does not have broad enough architecture support (platforms). Perhaps if a Rust compiler as part of GCC reaches maturity, we could start to see Rust in the core.
That is not what is being talked about right now though. So, it is not a reasonable objection to current activity.
If R4L authors want to use Rust so badly, then still:
Maintain your own tree! Let’s see how simple and clean these interfaces are over the longer haul.
They will get mainlined if they are technically superior.
It was merged into mainline, in 6.1, over a year ago.
docs.kernel.org/rust/index.html
Then this isn’t being blocked?
I don’t know if the code marcan was talking about is still going to be merged. It wasn’t actually being blocked, but that doesn’t mean it was approved either.
So, not blocked, merged in, already maintaining a tree, just one maintainer isn’t sold yet on the implementation.
Im just not seeing a problem then? Aside from the person experiencing burnout, which I get. But burnout may not indicate a cultural problem, either. Especially if the person is coming off of a rough year, personally.
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.
Or just boycott Linux and use Redox if you like Rust.
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.
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 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.
.
Thing is, there is already Rust in Linux, and Torvalds wants more, faster. He’s being sabotaged by C purists, who at this point should stop acting unprofessionally, or at the very least make their own “only C” fork if they disagree with his leadership so much.
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.
Don’t desktop environments e.g., GNOME, KDE, fit the bill here? Sure they have their problems, but they are IMO about as polished as macOS or Windows.
I agree that GNOME and KDE are gorgeous and very polished in many ways. However, I have had some problems in GNOME, Fedora, or Open Suse:
Despite these problems, I do have to say that GNOME is absolutely gorgeous. It’s precisely the kind of user-centricity that I want to see in Linux.
However, the end-users aren’t the only users. There are also developers! For example, I remember listening to the developer of the Mojo language talking with Richard Feldman, and the developer said that the development of the Swift language made it clear to him that Apple is aggressively user-centric. I don’t doubt that there are many problems with Swift as with Apple products in general, but I don’t see that kind of discourse in Linux coming from the main maintainers. Instead, there seems to be a vanguard arguing for a better developer experience (such as writing kernel code in Rust), and they find loads of friction. Heck, key developers are leaving Linux!
Edit: Clarified what is strictly my interpretation.
Only if by “customers” you are referring to how they constantly find new ways to fuck you over.
Yup. Modern MacOS is only pleasant to use if you have absolutely no preferences on how your computing environment should work and am willing to completely accept the walled garden.
Otherwise, it’s a hellscape.
Fair enough. Now that I think about it, maybe the developer experience in Apple products are not universally lauded.
For example, I remembered Pirate Software saying that he didn’t develop for Mac because it was a pain, including having to pay Apple $100 yearly to distribute code without issues. Additionally, I remember my brother meeting a Spotify developer, and the Spotify developer said that Apple makes great hardware but lackluster software.
At the same time, it seems like Swift is not a hated language. The 2023 and 2024 Stack Overflow developer survey reports that, even though few people use Swift (~5% of developers), there’s ~60% of admiration for the language.
I’ve been using fractional scaling on my laptop with GNOME since I installed it about four years ago. It’s a bit heavy on battery usage but it’s worked as expected for all this time.
Oh. I see I was wrong. Amazing. I should look into that! How did you enable it? I did a quick search and found I just need to do
gsettings set org.gnome.mutter experimental-features “[‘scale-monitor-framebuffer’]”; is that it?I believe it was enabled by default on Ubuntu.
congratulations
none of that is true
I’m sorry for having said something untrue. For example, DannyBoy points out that GNOME and whatever Ubuntu uses do have fractional scaling.
However, is my experience untrue? Was I lying when I said that my track-pad two-finger scrolling is frustrating? Furthermore, it’s not unusual for people at work to try my track-pad and it being way too sensitive or too un-sensitive, but no in between.
Was I lying when I said that, for me, it’s hard to get software? Was I lying when I said that maybe this is a skill issue on my part, but even that is indicative of a lack of easy ways of getting reassurance in the way that Apple makes it easy to find software in their App Store?
Was I lying when I said that, to me, GNOME is gorgeous?
Was the creator of the Mojo language lying when he recounted his experience developing Swift?
Was I lying when I said that developers are leaving Linux?
apart from the Mojo thing you it wasn’t clear that this was only your experience, and none of which are accurate or useful observations
It sounds like you really value skill, precision, and usefulness.
GNOME is not user-centric. GNOME is GNOME-centric.
more so. windows is horrible and macos is distinctly average, it’s only selling point is their service/device integration which is the best
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.
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.
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:
Abdiel Janulgue submits the patch to Christoph Hellwig
Christoph rejects the patch because he doesn’t want to maintain it
Danilo Krummrich offers 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]”
Hector Martin adds Linus and says “If Linus doesn’t pipe up with an authoritative answer to this thread, Miguel and the other Rust folks should just merge this series once it is reviewed and ready, ignoring Christoph’s overt attempt at sabotaging the project.”
Linus says “How about you accept the fact that maybe the problem is you. You think you know better. But the current process works.”
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.
Sima (Simona Vetter) quotes “Being toxic on the right side of an argument is still toxic, […]” while being toxic