Resigning as Asahi Linux project lead
-
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.
-
Or just boycott Linux and use Redox if you like Rust.
-
Linux
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", the 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. -
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.
-
The very same, yes.
-
I agree that GNOME and KDE are gorgeous and very polished in many ways. However, there are some basic problems at least in GNOME:
- fractional scaling is non-existent
- the track-pad two-finger scrolling is painful (compared to a Mac)
- sometimes it's hard 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 recognize 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, Apple has cared about their developers as customers. I remember listening to the developer of the Mojo language talking with Richard Feldman, and he 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, let alone the kinds of positive developer experiences. Heck, key developers are leaving Linux!
-
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: https://lore.kernel.org/rust-for-linux/[email protected]/
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't get more explicit than this.
-
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?
-
Nobody prevents anyone from maintaining their own tree, thereby proving it works.
Yet the Linux project officially OK'd the R4L experiment, so why does this stuff still have to be kept out-of-tree?
And yes, Rust is trying to replace C, in the kernel.
No, Rust is not trying to replace C in the kernel.
Let's start off by being honest here, k?
Sure, why don't you give it a try?
-
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.
-
For example, Apple has cared about their developers as customers.
Only if by "customers" you are referring to how they constantly find new ways to fuck you over.
-
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.
-
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:
I will do everything I can do to stop this
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.
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.
I don't know how to better explain this to you.
-
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.
