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'm pretty sure this is a dupe of a post from just a few days ago. https://news.ycombinator.com/item?id=22098001

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.

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.

The 7.6 release was no more unstable than the 8.0 release. Unless you're referring to the fact that 8.0 is going to be a LTS release. But if that's the case, it's not happening for a while yet, 6.10 is still the current LTS version.

Async/await support (without the --harmony flag) was made default in version 7.6 when they updated V8 to version 5.5.

The biggest additions here with regard to async/await is the new promisify util and the async_hooks.

Edit: Changed wording and included more detail.

It's the fourth most downloaded crate.[1] Somebody may have "deprecated" it, but the users aren't paying attention.

The most downloaded stat appears to be for the most downloaded of all time. Considering the difficulty of using serde on stable until recently, it's not surprising that it has been downloaded so much and would continue to be as projects move away from it.

It's not listed as "deprecated" on its own Cargo page.

This is true, however as you said the GitHub page and the docs page both mention that. Unless one already knows how to use the crate, they are probably going to check the docs and see the deprecation. Although having a deprecation notice on crates.io does seem prudent.

Again, denial. Not seeing many links from the "everything is OK, don't need to look at this" crowd.

You kind of skipped over the part where the parent poster explained why it wasn't even a big deal in the first place. It really feels like you're grasping at straws to make a point and I don't see why. No one seems to be denying that a lot of unsafe code is potentially bad, but there is really no solid proof that there is an unreasonable amount of unsafe usage. In fact, the parent has mentioned and linked to a list of such usages. If you're going to make such an extraordinary claim I think it behooves you to provide more than just a handful of examples.

As someone who hasn't followed the actual specifics here, do you happen to have any links to those discussions/issues or other places these things happened? I'd really like to see their reasoning.

This seems like a bit of a knee-jerk reaction on your part. The article itself is interesting and points out an edge case which is likely to trip people up in certain situations. I don't really see the article mentioning or even hinting that "C is evil", it even includes a bit of a qualifier at the end: "C is reaching PHP-like levels of confusion here, but luckily for us this combination . . . is pretty hard to hit. I’ve never seen it in “real” code."

But how do you know it was because of Roundup? Just because they used Roundup does not necessarily mean that that's what caused the cancer, even if Roundup's ingredients are carcinogenic. So how are you so certain it was the Roundup?

Servo uses SpiderMonkey to provide Javascript support, so retiring Octane (a Javascript engine benchmark) would have nothing to do with Servo (a layout engine).

This is also in a similar boat. I'm having a hard time pinning down anything of any serious relevance from the GNOME/GTK side of things, but there is this[1] which shows that they had planned work on Wayland prior to the Mir announcement. It looks like they started actual work on it some time in 2013 which may look like it increased because of Mir, but I would tend to think that's more coincidence based on their prior plans.

From the Qt/KDE side of things we have work on QtWayland[2] and work on Plasma/KWin[3]. The former had development increase as work on Wayland continued and follows a general upward trend, especially after Plasma started using it. For the latter, the article covers the timeline pretty clearly.

From what I can tell my point still stands, even when talking about support from integrators.

[1] https://wiki.gnome.org/Hackfests/WaylandHackfest2012

[2] https://github.com/qt/qtwayland/graphs/code-frequency the spike you see happened Jan/Feb which was prior to the Mir announcement and if you check the number of commits there was no major increase at that time

[3] http://blog.martin-graesslin.com/blog/2013/04/the-history-on...

But now that you mention it, it's true that wayland was stagnating and that when Mir arrived, everything accelerated. Sometime having a common enemy is a good motivator.

This seems to be something a lot of people believe, but when you look at the history of it all it's really not the case.[1] I have a feeling it's because the controversy sparked a number of articles which talked about things in a more public way which made it feel like Wayland was suddenly making progress after stagnation, while in actuality development pace was chugging along as it always had been.

[1] Canonical announced Mir early 2013[2], you'll notice there is no great spike around that time in any of:

[1a] the Wayland repo https://github.com/wayland-project/wayland/graphs/code-frequ...

[1b] the weston repo: https://github.com/wayland-project/weston/graphs/code-freque...

[2] http://www.omgubuntu.co.uk/2013/03/canonical-announce-custom...

It's not that people chose not to believe this, it's that the whole point doesn't make sense at all when looked at in detail.

When asked to provide specific technical reasons for the existence of Mir beyond the nebulous ones stated in the article, Canonical was unable to list anything of any real value. Input was one of the things mentioned, but in the end they ended up going with the Wayland solution (libinput). The whole point of Mir's existence, that is a goal of convergence across several form factors, is also filled perfectly by Wayland. Mir provided no advantages over Wayland for that goal.

This is kind of frustrating because Canonical spent time working on a system which provided almost exactly the same thing as Wayland instead of contributing to Wayland. And that alone may not have been that bad if they had been open about it, but Mir development happened in the dark for a long time prior to announcement and when it finally was announced Canonical listed off a bunch of issues they had with Wayland which they had never even brought up with the Wayland developers.

All that would probably still be okay if at the end Mir offered something over Wayland, but that's just not the case. Even now there doesn't seem to be any technical reason for Mir to exist or have existed at all.