Resigning as Asahi Linux project lead
-
Tell me you are only familiar with stuff going on with the US and nowhere else without telling me.
-
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?
-
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.
-
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?
-
"Let's wait and C".
-
Which means unnecessary duplication of code, because every driver has to track kernel Interfaces separately. Why? What's the advantage?
-
Wow. The entitlement… maybe learn what a donation means
-
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
-
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?
-
The TV show is British with Rowan Atkinson from the 90s... I aint seppo
-
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.
-
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.
-
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.
