

Nothing like the very highly reliable pharmaceutical “science” done in the US, amirite?
Its not like we ever had “science” come from the US that said an extremely powerful opioid wasn’t addictive, amirite?
Nothing like the very highly reliable pharmaceutical “science” done in the US, amirite?
Its not like we ever had “science” come from the US that said an extremely powerful opioid wasn’t addictive, amirite?
I suppose we’ll need to worry about that, once we get a net positive output from a fusion reactor.
Well, the good news? A wider audience most certainly means a FLOSS suite that can parse the data from it. It doesn’t seem very opaque, but more like Markup++.
We did.
Boxed wine.
However, bottle design is pretty refined, and they are quite reusuable.
It’s like that to push you to buy two of them.
Eh, I prefer being able to specify block sizes, to maximize the throughput.
I dunno… I just use dd.
Yes, it is probably the oldest or second oldest server suite in the fediverse (diaspora is maybe older).
It was an early supporter of statusnet and pump.io, which are the earlier versions of ActivityPub.
It originally used it’s own protocol to talk to other friendica instances, but a lot of plug-ins came out adding support for everything, even Facebook support for a while.
Please be careful when copying anything that could be considered your employer’s intellectual property
Very unlikely $NEW_EMPLOYER will run all your ideas past $OLD_EMPLOYER to see if it’s their code…
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.
Then this isn’t being blocked?
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.
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.”
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.
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.
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.
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!
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.
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.
I just usually keep my hair tied back with a rubber band, a head band, or under a bandana, if doing most anything but just sitting.