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'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.
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.
Number 6 (more customization, highlighting complete themes) and number 8 (unique extensions, highlighting Tree Style Tabs) are shortly going to be things of the past. Neither of those features are fully set to make it past version 57 since they will be removing the ability for legacy extensions (those using binaries, XUL, or things of that nature; i.e. non-WebExtension extensions) to function.
Edit: I would like to add that both of those things will have some level of support, but the full range of features is just not there and providing the same kind of experience is just not part of Mozilla's scope, which is now strongly favoring keeping the UI as uniform as possible.
It's not as user-hostile as I originally assumed (I thought it was built and enabled with no option to turn it off). As long as it can be completely disabled so that nothing will ever touch it, then it's fine. And that does indeed appear to be the case here.
Regardless, I'm sure there are some people who would love to claim a few KiB back without having to compile things for themselves.
The title is slightly misleading since it is specifically the optional (but installed by default on Ubuntu) systemd-resolved package (an ancillary package under the systemd name), not systemd the init system as I think many people will assume.
Edit: It seems Ubuntu builds it together with systemd so users have no choice. There may be a good technical reason for this, but I'm not sure what it is because it seems very user-hostile to remove choice like this.
Edit2: Upon further inspection this appears to be common practice, you just don't enable the parts you don't want. It would be nice if they could be put into separate packages or something of that nature though.
I regularly use VS Code, and this is one of the few features that I don't miss much until I need it, and then I really, really wish it had support for it. This is definitely one of the major negatives for VS Code.
I see this kind of thing mentioned a lot which really disappoints me because systemd is not as monolithic as people seem to think it is. systemd (the init system) is a relatively small component with a modest set of dependencies. systemd (the umbrella project) includes a number of other projects which are separate and many of them aren't even required and are easy to replace with something else if it's needed.
If you're a programmer I highly recommend taking a quick browser through the systemd source code, it doesn't take long to see that it isn't really monolithic at all and is in fact a combination of individual tools which are combined to accomplish things. Just because they're all under the systemd umbrella and all in the same repository does not mean it's all one binary and that parts can't be swapped out.
This is somewhat off-topic, but I'm curious since every person who has had this sentiment that I've known was unable to provide specific parts which were lacking. Do you perhaps have a short list of top things which are missing their polish with the Qt version of Wireshark?
I'm just a light user of the tool and am genuinely curious about what things it may have lost in the transition.