- 29 Posts
- 106 Comments
It doesn’t solve this problem, but it could be useful some day. Bookmarked; thanks.
The point of posting is to create a record of the failure, for reference when someone wants to find a pattern or potentially fix it.
Several of us in this thread have already collected relevant information that might help pin it down.
Several times in the past, I have seen SDF members who also have a board account relay problems reported here to the board.
As for you yourself, maybe nothing? That’s fine. Feel free to ignore it.
I’ll take that to mean you have no particular reason to think that. As a general rule, I don’t like to poke the mods about operational problems that they are likely already aware of. They’re not sysadmins, after all, and having been in those shoes, I know extra demands for attention can get tiresome.
But if this persists for long, I might poke the mod. If other people start noticing it as well, perhaps they will bring it up, too.
Who’s to say I’m not a corvid imitating a human imitating a t-rex?
How much worse can they get
I think kbin.social showed us that overload can get much worse.
The sidebar shows only a moderator. I assume they can see this discussion already, but if you have reason to think they relay problem reports upstream when pinged, I suppose I could ping them.
What do you mean “was”? RAAAWR!
Hours wouldn’t raise my attention. I’m talking days.
I think they might be using some weird shit for “last mile”.
Given that lemmy.world uses Cloudflare, I wonder if their server is overloaded enough to sometimes exceed Cloudflare’s 100 second timeout, triggering http-524 errors during federation.
Welcome, yourself. ;)
No. I haven’t made an SDF board account, since I’m already overloaded with online accounts. I’m not aware of another way to reach them.
Completely off-topic:
I’m surprised to learn from the comments here that people on other instances subscribe to this sdf-specific community. I have no idea why they would, but it somehow makes me happy.
Thanks. So a post to this lemmy.sdf.org community reaches your instance, but my posts to lemmy.world communities do not.
Thanks, but the posts in question are not showing up on your instance, either.
Would a federation problem on lemmy.world block propagation to slrpnk.net? That would be a weirdly inefficient network design.
That’s (an example of) what I’m seeing right now. It’s abnormal.
Ted was being an unconscionably rude fucker, but - diatribe aside - his process question is a reasonable one, although his solution “well you’re SOL” was poor, undiplomatic, and unhelpful.
Maybe so. What I watched of the video had little surrounding context, though.
I’ve seen more than a few abrasive outbursts from people who care a lot about what they’re doing. When I see video of one, I try to keep in mind that they don’t often come out of nowhere. There’s a good chance that there was a much longer preceding exchange (perhaps not even in person) wherein the speaker had been trying to explain their perspective calmly and politely, but the other person was persistently missing it, due either to stubborn selfishness or to honest lack of understanding. Frustrated people sometimes resort to a blunt approach to try to get their message through.
In any case, I’m with you in noticing that important issues are being raised here. They’re not easy to solve, so it’s no surprise to see frustration along the way, but they still might lead to a good outcome.
Drew DeVault recently wrote up an idea similar to one that has been on my mind lately: What might come of a bunch of passionate Rust developers making a new kernel exposing Linux ABIs? It would be much faster and easier than a new kernel from scratch, because there’s already a working reference implementation in C. That seems like an effective way to work through design challenges without disrupting the existing system and development process, and once proven to work, might guide a better-defined path to integration with (or even replacement of) the C kernel. It would certainly have less friction than what we’re seeing now.
https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html
Looks like it received this one, but not the ones I mentioned that are in lemmy.world communities.
Your perspective makes more sense when you put it that way.
I think it’s important to understand that “having to learn Rust” is a proxy for “having to learn, become proficient in, become expert in, commit to regularly using, and take on the additional work of managing bindings between a large continually changing codebase and Rust, with no foreseeable end”. Multiply that by the number of kernel developers who would be affected, and remember that Rust in particular is famously time-consuming and (at least for some) often painful to use.
It’s not, “I don’t want to learn this”. (The people maintaining the kernel surely learn new things all the time in the course of their work, after all, as do most advanced programmers.) It’s more like, “I cannot reasonably take on such an enormous additional workload.”
The Rust camp in this disagreement doesn’t seem to grasp that yet. If everyone involved figures out a way to bridge that gap, I expect the frustrations will go away.
Mainlining memory safety improvements, in C, for C code should be welcomed and it is very concerning if she indeed got shunned because the end goal was to offer lifetime guarantees (which to my admittedly non-expert eye sounds like it would be a good thing for memory safety in general).
It would be a good thing. Nobody is debating that. It’s why Linus agreed to start experimenting with Rust in certain parts of the kernel.
However, trying to integrate one very specific approach to it into a large, already-working system that works quite differently, is a lot harder than writing from scratch one small component that mainly has to work in its own native ecosystem (as Lina has done).
Without good and realistic answers to how the long-term maintenance of such changes would be managed, it is myopically unrealistic to propose those changes, let alone to push this hard for them and be so dismissive of the folks who actually have the experience and responsibility to keep it all running. Especially when it’s something that the entire world has come to depend upon in one way or another, as is the case with the linux kernel.
The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.
Seems like a moral panic over absolutely nothing (where are the Rust developers allegedly forcing people to learn Rust? all I’ve seen in these threads today is Rust developers asking for an open mind and a willingness to collaborate), and that the response to this “concern” is to block any and all changes that might benefit Rust adoption is really concerning (but unfortunately not unsurprising) behavior.
The problem isn’t the immediate thing they’re asking for; it’s the inevitable chain reaction of events that will follow. They don’t seem to understand the bigger picture, so they don’t have answers for how it would be managed. The obvious but unstated solution would be that many kernel developers would have to invest an enormous amount of time (which they might not have) to become proficient in Rust and adapt an enormous amount of surrounding code to it, on top of their existing responsibilities. More than a few people (who are very much in a position to know) see that as unviable, at least for now.
No viable alternative has been offered. Hence the objection. And, since the vocal minority keep on pushing for their changes without addressing the issues that have been raised, the only sensible response is to reject their request.
Rust is—again for better or worse—something Linus thinks is good for the project, and thus learning Rust at least enough to not break the builds is a requirement for the project.
That misrepresents the situation. Linus accepted Rust provisionally, and only into certain parts of the kernel (drivers). It’s more of an experiment than what you wrote would suggest.
Rust is mainstream now,
Rust is highly visible now, due in no small part to its deafening evangelism. But it is not remotely mainstream in the sense of being a prevailing language, nor in the sense of being representative of the majority. It brings to the table a novel way to solve certain problems, and that is useful, but let’s not mistake that as the only way or those as the only problems.
Rust is mainstream now, and “i don’t want to learn this” is a dogshit technical justification.
That is a straw man.
- kernel
- shell
- compiler
Terrible idea, predictable results.