Etzos

Do you have any articles or any info on why they decided to stop using Rust? I remember seeing things about them using Rust but never saw anything about them not using it and I'm curious.

It's really sad because this is the first time I heard about this campaign. Had I known earlier I would have pledged sooner and spread the word around.

I think this might need a 2013 tag?

That seems like something that wouldn't be super valuable to put in place until all of the commands are completed, or at least close to completed.

I'm curious what parts of Rust you think are safer than Python.

Edit: The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?

I don't think that analogy is a fair comparison to make because it doesn't fairly portray that Purism doesn't have a choice in this. It is the upstream manufacturers who control this area, and they will have no reason at all to make something which is RYF approved unless someone big enough is pushing for it.

So to make this comparison more apt, it's more like a sausage maker who is focused on making vegetarian sausage. Now, it just so happens that they'd also love to make these sausages vegan sausages, but the suppliers of the contents of the sausage just don't make a "meat" which is vegan because literally no one with any power has asked for it before. If no one buys their sausages there is literally no chance of a vegan sausage being produced because there is just no reason for it.

Even that isn't really an apt comparison because it doesn't correctly portray the ubiquity of cell phones. I guess instead of a sausage maker it would be something more like "a producer of food", where there is literally no vegan food anywhere. So what I don't understand in all this is why someone who wants an RYF certified cell phone would choose not to support the one group even attempting such a thing. You don't even need to eat the sausage or use the phone in this case either, they just need the support.

I suppose I can understand this reasoning a bit, but it seems a little counter intuitive to me. There is literally no alternative. And without efforts like this it's unlikely there would ever be something that is RYF compliant. Accomplishing something like RYF certification requires work, money, and someone willing to try to accomplish it. There is someone that is willing to invest work to at least attempt to accomplish it, but they need money. Why not support them in their quest for this?

Considering how they phrased it and the fact that no phone has the FSF's RYF certification I would tend to think it's because it's currently impossible.

That they took the time to add a note about RYF certification and that they will continue to keep the FSF up to date on this shows that they do care about this. I honestly don't think there's any more you could ask of them.

I don't exactly see the Linux kernel dev community as being inclusive, so that's not really an apt comparison. Nor is it a language-based community. It's a very specific set of people who are expected to follow the rules and do things in a particular manner; and for them that's okay.

For a programming language community though I don't think that's the kind of approach to take. Sure, it could work and you may get some very talented people to help, but it's also arbitrarily limiting the kinds of people who can contribute and feel welcome based on the thickness of their skin, not on their technical ability. You may consider this timewasting, but I think it's more like a clever and nuanced form or marketing. Not only do you get the benefits of including more potentially skilled people into your community, you encourage them to actually get involved with the language. It seems like a worthwhile investment to me.

> Write a code of conduct, make sure everyone is respected, and make that the end of it.

But that's exactly what all of your examples are. In each situation the decision and action was to make things as neutral and inclusive as possible. That there are people in any given community which want things to be taken in a different direction (any direction, social or otherwise) seems like a pretty natural thing.

But it's true that there's nothing inherently "bad" about the code. It's just not conforming to the standard style. It seems pretty reasonable to want that to sound less menacing than "bad code", which would hint very strongly that one has something semantically incorrect.

This looks like it needs a (2016) tag in the title.

I'm not sure this really makes sense. It sounds like RedHat didn't hammer it down throats, but instead created a solution that had some guarantees of support and traction which distro maintainers then decided was better than the current alternatives. No one was holding a gun to distro maintainer's heads tell them that they needed to move away from the existing solutions or else, or at least I haven't seen any evidence of that.

So if they weren't forced into it and RedHat did indeed provide some guarantees, it does actually suggest what the parent says.