1. 23

    I think Josh addresses a good point here: systemd provides features that distributions want, but other init systems are actively calling non-features. That’s a classic culture clash, and it shows in the systemd debates - people hate it or love it (FWIW, I love it). I’m also highly sympathetic to systemd’s approach of shipping a software suite.

    Still, it’s always important to have a way out of a component. But the problem here seems to be that the scope of an init system is ill-defined and there’s fundamentally different ideas where the Linux world should move. systemd moves away from the “kernel with rather free userspace on top” model, others don’t agree.

    1. 17

      Since systemd is Linux-only, no one who wants to be portable to, say, BSD (which I think includes a lot of people) can depend on its features anyway.

      1. 12

        Which is why I wrote “Linux world” and not “Unix world”.

        systemd has a vision for Linux only and I’m okay with that. It’s culture clashing, I agree.

        1. 6

          What I find so confusing - and please know this comes from a “BSD guy” and a place of admitted ignorance - is that it seems obvious the natural conclusion of these greater processes must be that “Linux” is eventually something closer to a complete operating system (not a bazaar of GNU/Linux distributions). This seems to be explicitly the point.

          Not only am I making no value judgement on that outcome, but I already live in that world of coherent design and personally prefer it. I just find it baffling to watch distributions marching themselves towards it.

          1. 6

            But it does create a monoculture. What if you want to run service x on BSD or Redox or Haiku. A lot of Linux tools can be compiled on those operating systems with a little work, sometimes for free. If we start seeing hard dependencies on systemd, you’re also hurting new-OS development. Your service wont’ be able to run in an Alpine docker container either, or on distributions like Void Linux, or default Gentoo (although Gentoo does have a systemd option; it too is in the mess of supporting both init systems).

            1. 7

              We’ve had wildly divergent Unix and Unix-like systems for years. Haiku and Mac OS have no native X11. BSDs and System V have different init systems, OpenBSD has extended libc for security reasons. Many System V based OSes (looking at you, AIX) take POSIX to malicious compliance levels. What do you think ./configure is supposed to do if not but cope with this reality?

          2. 2

            Has anyone considered or proposed something like systemd’s feature set but portable to more than just linux? Are BSD distros content with SysV-style init?

            1. 11

              A couple of pedantic nits. BSDs aren’t distros. They are each district operating systems that share a common lineage. Some code and ideas are shared back and forth, but the big 3, FreeBSD, NetBSD and OpenBSD diverged in the 90s. 1BSD was released in 1978. FreeBSD and NetBSD forked from 386BSD in 1993. OpenBSD from NetBSD in 1995. So that’s about 15 years, give or take, of BSD before the modern BSDs forked.

              Since then there has been 26 years of separate evolution.

              The BSDs also use BSD init, so it’s different from SysV-style. There is a brief overview here: https://en.m.wikipedia.org/wiki/Init#Research_Unix-style/BSD-style

              1. 2

                I think the answer to that is yes and no. Maybe the closets would be (open) solaris smf. Or maybe GNU Shepherd or runit/daemontools.

                But IMNHO there are no good arguments for the sprawl/feature creep of systemd - and people haven’t tried to copy it, because it’s flawed.

            2. 6

              It’s true that systemd is comparatively featureful, and I’ll extend your notion of shipping a software suite by justifying some of its expansion into other aspects of system management in terms of it unifying a number of different concerns that are pretty coupled in practice.

              But, and because of how this topic often goes, I feel compelled to provide the disclaimer that I mostly find systemd just fine to use on a daily basis: as I see it, the problem, though, isn’t that it moves away from the “free userspace” model, but that its expansion into other areas seems governed more by political than by technical concerns, and with that comes the problem that there’s an incentive to add extra friction to having a way out. I understand that there’s a lot of spurious enmity directed at Poettering, but I think the blatant contempt he’s shown towards maintaining conventions when there’s no cost in doing so or even just sneering at simple bug reports is good evidence that there’s a sort of embattled conqueror’s mindset underlying the project at its highest levels. systemd the software is mostly fine, but the ideological trajectory guiding it really worries me.

              1. 1

                I’m also highly sympathetic to systemd’s approach of shipping a software suite.

                What do you mean here? Bulling all distro maintainers until they are forced to setup your software as default, up to the point of provoking the suicide of people who don’t want to? That’s quite a heavy sarcasm you are using here.

                1. 11

                  up to the point of provoking the suicide of people who don’t want to

                  Link?

                  1. 23

                    How was anyone bullied into running systemd? For Arch Linux this meant we no longer had to maintain initscripts anymore and could rely on systemd service files which are a lot nicer. In the end it saved us work and that’s exactly what systemd tries to be a toolkit for initscripts and related system critical services and now also unifying Linux distro’s.

                    1. 0

                      huh? Red Hat and Poettering strongarmed distribution after distribution and stuffed the debian developer ballots. This is all a matter of the public record.

                      1. 10

                        stuffed the debian developer ballots

                        Link? This is the first time I am hearing about it.

                        1. 4

                          I’m also confused, I followed the Debian process, and found it very through and good. The documents coming out of it are still a great reference.

                    2. 2

                      I don’t think skade intended to be sarcastic or combative. I personally have some gripes with systemd, but I’m curious about that quote as well.

                      I read the quote as being sympathetic towards a more unified init system. Linux sometimes suffers from having too many options (a reason I like BSD). But I’m not sure if that was the point being made

                      Edit: grammar

                      1. 5

                        I value pieces that are intended to work well together and come from the same team, even if they are separate parts. systemd provides that. systemd has a vision and is also very active in making it happen. I highly respect that.

                        I also have gripes with systemd, but in general like to use it. But as long as no other project with an attitude to move the world away from systemd by being better and also by being better at convincing people, I’ll stick with it.

                      2. 2

                        I interpreted it as having fewer edges where you don’t have control. Similar situations happen with omnibus packages that ship all dependencies and the idea of Docker/containers. It makes it more monolithic, but easier to not have to integrate with every logging system or mail system.

                        If your philosophy of Linux is Legos, you probably feel limited by this. If you philosophy is platform, then this probably frees you. If the constraints are doable, they often prevent subtle mistakes.

                    1. 2

                      He’s not wrong about some facets of what he says, particularly that given a real-world identity one can just rely on the existing legal system to enforce contracts. But here’s the thing: the existing legal system is really, really expensive (in the U.S., we spend about 38% of GDP on government). Is it possible to use something like a blockchain to provide many of the same benefits more cheaply and/or more accountably and/or with less susceptibility to corruption?

                      I don’t know, but it’s an interesting question. We’ll always need some form of physical government to provide physical security, but do we need a government to provide financial security?

                      1. 4

                        Is it possible to use something like a blockchain to provide many of the same benefits more cheaply and/or more accountably and/or with less susceptibility to corruption?

                        I’m a big cryptocurrency fan but I don’t think that anything like blockchains could possibly provide any government services in any sort of useful fashion. It very quickly degrades to real world identity problems that cannot be solved well without trust. If you have trust, you don’t need a blockchain.

                        1. 3

                          the existing legal system is really, really expensive (in the U.S., we spend about 38% of GDP on government)

                          Enforcing legal rules (courts and law enforcement) is a small part of that budget.

                          https://www.thebalance.com/u-s-federal-budget-breakdown-3305789

                          The discretionary budget will be $1.426 trillion. More than half goes toward military spending, including the Department of Veterans Affairs and other defense-related departments. The rest must pay for all other domestic programs. The largest are Health and Human Services, Education, and Housing and Urban Development.

                        1. 13

                          I feel like docker is too commercial. I worry about lock-in and how this business might turn.

                          I have experimented with it and it seems like a nice feature set. I am also encouraged by appc/rkt/buildah/podman but I have not yet seen a really simple tutorial (though I admit I haven’t looked very hard). It doesn’t seem to me like these have seen wide use – likely because of docker’s popularity.

                          1. 2

                            Podman is often just alias docker=podman once you get it installed…. Quite the escape hatch if docker implodes.

                          1. 4

                            Is this the extent of the announcement?

                            To the MIT community,

                            I am resigning effective immediately from my position in CSAIL at MIT. I am doing this due to pressure on MIT and me over a series of misunderstandings and mischaracterizations.

                            Richard Stallman

                            If so, it’s interesting, but this news/announcement is really really light on information, and hardly seems worth posting here..

                            1. 7

                              It’s from Stallman himself. Definitely worth posting and discussing IMO.

                              But an article that covers the details would be valuable for context, I agree. Especially for those of us who haven’t followed this issue.

                              Edit: for context: https://www.vice.com/en_us/article/mbm74x/computer-scientist-richard-stallman-resigns-from-mit-over-epstein-comments

                              1. 6

                                Thing that bothers me most is the combination of these statements:

                                “When someone else in the email thread pointed out that victim Virginia Giuffre, who was 17 when she was forced to have sex with AI pioneer Marvin Minsky, Stallman said “it is morally absurd to define ‘rape’ in a way that depends on minor details such as which country it was in or whether the victim was 18 years old or 17.””

                                “Stallman is known as a pioneer of the free software community and movement, which is closely related to the open source movement.”

                                Great fucking P.R. for the “free software community and movement.” They probably should’ve said something that indicated he was different than many or most of the other people involved in F/OSS. Media wise, this might be making casual readers suspect this is a larger problem among advocates for these types of software.

                                1. 7

                                  Great fucking P.R.

                                  Thankfully open source as a concept and movement has become ubiquitous enough that Stallman’s writings won’t damn it.

                                  Remember, this is the same guy who wrote about legalizing possession of child pornography (2012) or stating that bestiality, necrophilia and child pornography are illegal due to prejudice and narrowmindedness. He’s spent a lot more time talking about possession of child porn than one would expect. It’s rather unsettling to see the “It’s illegal because people are narrowminded!” (No Richard, child porn in specific is illegal because children cannot consent. Ever. And such is the fruit of the poisoned tree…)

                                2. 5

                                  Why is it worth posting or discussing?

                                  Is it actionable? Unless you’re RMS, not really.

                                  Is it going to foster productive discussion? Well, if you don’t agree with what happened or why, it seems like posting here about to that effect would at best be irrelevant and at worst could get you flagged…or worse. It’s hard to have a discussion when everyone is violently agreeing with each other–that’s more of a circlejerk.

                                  Is it something the practicing technologist can use? Unless we’re so cynical as to say “This is why you keep your head down in leadership roles”, no.

                                  Is covered elsewhere? Extensively, to varying degrees of accuracy.

                              1. 2

                                Thanks for sharing, this is a handy reference.

                                Aside: IMO logical expressions with == should be bool and not int.

                                1. 2

                                  This depends on the C standard – bool isn’t in C89, so it can become a portability issue.

                                  1. 1

                                    Y’know – I was tempted to add a snarky “unless you need to be compatible with C89 <scoff>”. I will acknowledge that there are some (hopefully very very few) legit use cases where bool support is missing.

                                    1. 2

                                      Indeed, and I’m inclined to agree otherwise.

                                      I’ve worked on a couple projects that needed C89 compatibility (mostly in embedded), and I begrudgingly keep greatest to -std=c89 just so that it’s always an option. There are some features that are only available when it’s built with >= C99 though.

                                1. 12

                                  Each clock cycle uses a little bit of power, and if all I’m doing is typing out Latex documents, then I don’t need that many clock cycles. I don’t need one thousand four hundred of them to be precise.

                                  I recall there being some paper or article that shows doing the work quicker with a higher frequency/power draw then moving into the low frequency is less costly for power savings that doing the work slower at a lower frequency. Basically the CPU would spend more time in sleep states in an ‘on demand’ type governor (run at low freq, but elevate to high freq when utilization is high) vs a governor that always ran at the highest p-state (lowest freq) all the time. I’m having trouble finding the specific paper/article though.. I’ll keep searching.

                                  1. 15

                                    Search for “race to idle”

                                    1. 8
                                    2. 4

                                      I remember reading the same thing, but I think it had the added context of being on mobile. Having the CPU awake also meant having other hardware like the radios awake, because it was processing notifications and stuff. In this case, the rest of the hardware is staying awake regardless, so I think it’s really just reducing the number of wasted CPU cycles.

                                      I’d be interested if you or someone else could find the original source for this again to fact check!

                                      1. 3

                                        The counterbalance here is the increasing cost for each 100MHz as frequencies get higher. This is old, but https://images.anandtech.com/doci/9330/a53-power-curve.png shows the measured shape of a real curve. This StackExchange response helps explain why it isn’t flat.

                                        So factors around race-to-idle include how that power-frequency curve looks, how much stuff you can turn off when idle (often not just the cores; see artemis’s comment) and how CPU-bound you are (2x freq doesn’t guarantee 2x speed because you spend some time waiting on main memory/storage/network).

                                        Some of that’s workload-dependent, and the frequency governor doesn’t always know the workload when it picks a frequency. Plus you’ve got other goals (like try to be snappy when it affects user-facing latency, but worry less about background work) and other limits (power delivery, thermals, min and max freq the silicon can do). So optimizing battery life ends up really, uh, “fun”!

                                        (Less related to race-to-idle, but the shape of the power curve also complicates things at the low end; you can’t keep a big chip running at all at 1mW. So modern phones (and a chip Intel is planning) can switch to smaller cores that can draw less power at low load. Also, since they’re tiny you can spam the chip with more of them, so e.g. Intel’s planning one large core and four small. Fun times.)

                                        1. 1

                                          Ooh, today somebody happened to post a couple pretty charts of recent high-end Intel desktop chips’ power/frequency curves, and charted speed per watt as a bonus. They also fit a logarithmic curve to it, modeling power needs as growing exponentially to hit a given level of perf, and it looks like it worked reasonably well.

                                        2. 1

                                          Yes, I remember reading the same thing. But, maybe on a CPU this old it isn’t as efficient as transitioning in and out of low power states? Just a guess, assuming his claim of +1 hour is true.

                                          1. 1

                                            Maybe it’s not linear. The comparison between ‘low freq’ and ‘high freq’ for that study could be comparing something like 40% (of the available clock range) vs 90%? And maybe at 1% the CPU power draw is so much lower that it’s even better than race-to-idle (but perhaps considered to be an unlikely/uncommon configuration).

                                            1. 1

                                              The power consumption of a CMOS circuit scales with the square of the operating voltage, though, so intuitively I would expect that 100 ms at 0.5V to be more energy-efficient then 50ms at 1.0V. Chips are extremely complex devices, though, and I’m probably ignorant about a power-saving strategy or physical effect that side-steps this. Please let me know when you find that article - I’m curious to see which of my assumptions have been violated.

                                              1. 1

                                                I found it and put the link in another comment

                                              2. 1

                                                This makes a lot of sense and mirrors my experience with an X220 on OpenBSD. I got about one more hour of battery life (about 5 hours -> 6 hours ish) just by allowing it to run at a higher frequency but still spend 95% of its time at a lower one.

                                                Also, while the tools built into OpenBSD do a good job of controlling power usage, I found I was getting even better battery life in a standard Arch Linux instal with no configuration of powertop or anything else.

                                              1. 0

                                                #ifdef APPLE y’know truncating an mmap’d file actually leads to a lot of undefined behavior

                                                … file can be truncated overwritten before tail can actually read it …

                                                Yeah, at the outset it sounded like the user was expecting too much from tail -f and it did not sound like an OS bug to me. Regardless of the BSD manpage.

                                                1. 1

                                                  Does anyone know about the kernel requirements for running podman (and its related software)? What’s the oldest ubuntu release that I could use it on?

                                                  EDIT: nm it appears that the PPA includes trusty, bionic, xenial.

                                                  1. 14

                                                    Occams razor: which is more likely?

                                                    1. You’ve been target by an undetectable son of stuxnet cyberweapon.

                                                    2. A cloud chat company is lying about their security.

                                                    1. 1

                                                      This fails to take into account the risk of delaying the remedy.

                                                      1. 2

                                                        There’s also the cost of the remedy to consider.

                                                      2. 1

                                                        I read that as advertising, as a statement of particularly high company security values.

                                                      1. 2

                                                        If the host sees that the user is attempting to use DisplayPort Alternate Mode with the wrong cable, rather than a silent failure (ie, the external display doesn’t light up), the OS should tell the user via a notification they may be using the wrong cable, and educate the user about cables with the right logo.

                                                        Anyone know how this would actually work? Presumably, if the wires aren’t there, one end won’t know the other end is trying to send signal down them. Or is all the negotiation to setup alternate modes done over the 2.0 wire pair?

                                                        1. 2

                                                          I see “Uses the USB-C Power Delivery messaging protocol over the USB-C Configuration Channel (CC) to negotiate into and exit out of DisplayPort Alt Mode signaling.” in some slides for a webinar on the topic.

                                                        1. 6

                                                          This describes the different compliant varieties but to make things yet more complicated it sounded like for some time there were a lot of manufacturers who were producing incorrectly-terminated cables. There was Benson Leung naming-and-shaming them for a while but I don’t know if that kind of scrutiny is necessary anymore. http://bensonapproved.com redirects and I can’t seem to access that site anymore.

                                                          1. 6

                                                            For the record Benson Leung is the author of this very post.

                                                            1. 2

                                                              I bought a cord he approved, it was a PoS. I think they got a bump from his endorsement and then cut quality to reap the profits. He’s only one person and he can’t continually test cables at his own expense, the USB licensors really need to implement some sort of QA process.

                                                            1. 5

                                                              It is mostly an change that empowers developers; but it also is a change that will cause some existing code to break.

                                                              This has been my impression of Rust, and why I’ve avoided doing much with it. It seems like it’s just a constantly moving target. I remember in its earlier days whole features (like classes) just being nuked out of existence. It may have settled down some now; I haven’t been keeping as close an eye on it.

                                                              1. 27

                                                                Since 1.0, this is the first major breaking change that I can recall. It’s also worth pointing out that any code that does break under NLL was fundamentally unsound – it shouldn’t have been compiling in the first place, but was, due to the limitations of the then-current lifetime analyzer. It’s also going to downgrade these breakages to just issuing warnings that this unsound code is going to stop compiling sometime in the future.

                                                                My personal take is that, in a language that’s trying to prioritize safety and correctness, privileging correctness over the sanctity of “existing code that compiles” is the right move.

                                                                Sure, in pre-release, there was a lot of churn as all manner of different ideas were tried out (like Classes) and subsequently removed. That’s, uh, why it was in pre-release. You need to get feedback somehow.

                                                                1. 2

                                                                  It’s also going to downgrade these breakages to just issuing warnings that this unsound code is going to stop compiling sometime in the future.

                                                                  What’s the practical difference between “unsound” code that compiles and runs versus “undefined” or “implementation defined” behavior in C and C++?

                                                                  I suppose it’s a moot issue because there’s only one Rust implementation?

                                                                  1. 4

                                                                    What’s the practical difference between “unsound” code that compiles and runs versus “undefined” or “implementation defined” behavior in C and C++?

                                                                    I don’t think there’s any relationship there at all. Undefined/implementation defined code in C is code where the standard says, essentially, “in these cases the compiler can do whatever: compile, reject, crash, launch nethack”.

                                                                    Unsound code that was compiling under the AST based borrow checker in Rust were simply compiler bugs — explicitly disallowed things that slipped past due to defects in the borrow checker. The analogous situation in C is again a compiler bug

                                                                    1. 1

                                                                      What’s the practical difference between “unsound” code that compiles and runs versus “undefined” or “implementation defined” behavior in C and C++?

                                                                      There might be a difference between “this is unsound, we don’t know if the code is valid”, and “there is a data race” or some other genuine undefined behaviour.

                                                                      If you overlap borrows, one of which is mutable, your program should be rejected. But if you’re single threaded, overlapping borrows should be just fine. Perhaps confusing and bug prone, but as long as you don’t have any actual concurrent access, it should work.

                                                                      That’s most likely why there’s an unsafe mode: it’s like telling the compiler “I know you can’t prove my program doesn’t have any data races, but trust me, there isn’t any”.

                                                                      1. 4

                                                                        But if you’re single threaded, overlapping borrows should be just fine.

                                                                        Overlapping borrows are unsound even on a single thread. The canonical example of the borrow checker people use in intro talks is single threaded:

                                                                        let v: &mut Vec<T> = ...;
                                                                        let x0 = &v[0]; // overlapping borrow
                                                                        v.push(...); // potential resize invalidating x0
                                                                        println!("{:?}", x0); // use-after-free
                                                                        

                                                                        Or this more blatant case:

                                                                        let o: &mut Option<String> = ...;
                                                                        if let Some(s) = o { // overlapping borrow
                                                                            *o = None; // string no longer has owner, is dropped
                                                                            println!("{}", s); // use-after-free
                                                                        }
                                                                        
                                                                        1. 1

                                                                          Crap, didn’t think of pointer invalidation. Good point.

                                                                    2. 1

                                                                      It’s also worth pointing out that any code that does break under NLL was fundamentally unsound

                                                                      I don’t think this is true:

                                                                      https://github.com/rust-lang/rust/issues/59159

                                                                      This issue doesn’t mention unsafety, just inconvenience for them.

                                                                      1. 1

                                                                        That’s not my reading of it.

                                                                        From reading the various issues and reasoning behind stacked borrows it seems that:

                                                                        That particular lint identifies an unintended pattern that was allowed to compile as a two-phase borrow. The pattern is unintended, and undesirable, because it violates fundamental validity guarantees that all Rust code, safe or unsafe, must adhere to in order for there to be a coherent set of rules (“stacked borrows”) about pointer aliasing in Rust that unsafe code and compiler optimizations can be asked to adhere to.

                                                                        The two phase borrow pattern in question, in violating those rules, creates situations in which unsafe code or compiler optimizations that follow the rules will nevertheless result in safety and/or validity issues. This was argued about for several months with a bunch of people proposing various ways to make this particular 2PB pattern “work” with aliasing rules — but none of them seems to have managed a working solution.

                                                                        Hence, the lint and eventual removal.

                                                                    3. 12

                                                                      oh, maybe my standard is lower than yours but with the language itself, I was always impressed how remarkedly well managed stability. But yes, they fix compiler bugs eventually. I was once affected and got a pull request to my crate from the compiler team to fix it. The compiler release before issued a warning.

                                                                      So, this affects compiler bugs which might lead to unsafe code. The compiler issued warnings for some releases, now it will stop compiling that code.

                                                                      In my view, a remarkable balance between stability and upholding the fundamental guarantees of rust.

                                                                      (the library ecosystem is a different story)

                                                                      1. 4

                                                                        Maybe not the best wording on the author’s part, but if you read the rest of the post you would have read that only unsound code is affected, and it will continue to compile for now; only a future-compatibility warning will be raised.

                                                                        Rust has strong backwards compatibility guarantees, and has since the 1.0 release in 2015. It’s only a moving target if you want to use the latest and greatest features, which are admittedly being added at a considerable rate. But that’s only a drawback if the features are not worth the maintenance overhead, which so far has not been a problem for Rust.

                                                                        1. -1

                                                                          ‘Unsound’ does not mean incorrect, it just means they can’t prove it is sound.

                                                                          only a future-compatibility warning will be raised.

                                                                          It is not useful to be told working code will maybe fail to compile at some nebulous point in the future when you specifically chose a stable release and edition to work with.

                                                                          1. 3

                                                                            ‘Unsound’ does not mean incorrect, it just means they can’t prove it is sound.

                                                                            That’s what the unsafe blocks are for. If you didn’t intend a particular piece of code to be unsound, it shouldn’t be, and you should fix it.

                                                                            1. 0

                                                                              This is a bad argument taken to the logical extreme - as a compiler gets more and more intelligent it can reject more and more code, to the point is just rejects all code ever written due to all code we write having bugs.

                                                                              My argument is simple, a rust edition should keep compiling things it accepted in the past. If they want to fix soundness problems, they should emit very loud and serious warnings and make a new edition. They shouldn’t retroactively stop compiling things they used to accept without a new rust edition.

                                                                              1. 4

                                                                                My argument is simple, a rust edition should keep compiling things it accepted in the past.

                                                                                That argument is wrong. The soundness rules are not just defined by the (only) reference implementation. The soundness rules stipulated that multiple borrows (one of which is mutable) is not allowed to overlap, and it used scope as an approximation. If the compiler allow such an overlap, this is a bug and it should be fixed.

                                                                                Likewise, if you unwittingly took advantage of this bug, and wrote unsound code outside of an unsafe block, you have a bug. Perhaps not a genuine bug, but you at least did not abide the soundness rules you should have. Thus, you should fix your code. I don’t care it’s something you consider “done” and no longer want to maintain. At the very least, you should accept a patch. If you don’t, well… there’s always the possibility of forking.

                                                                                If they want to fix soundness problems, they should emit very loud and serious warnings and make a new edition.

                                                                                Well, this is almost what they did: there’s a legacy compatibility mode, and warnings about that not compiling any more. That’s better than what C compilers do right now: when a new compiler spot an undefined behaviour it didn’t spot before, it could introduce a bug, without any warning, it didn’t used to introduce. (The magic of optimisations.)

                                                                                But this is not about undefined behaviour. This is about soundness. Which unlike undefined behaviour in general is perfectly checkable statically. This won’t get worse and worse as compilers get better. It’s just a matter of fixing compiler bugs.

                                                                                1. 0

                                                                                  I think it might annoy and cause reputational damage when all they need to do is make edition 2019-nll to avoid breaking the ecosystem.

                                                                                  Any crate with unsafe in it already has as much risk as something that has been there for years and nobody noticed any problem. They just need a warning and some bold flashy lights instead of permanently breaking our ability to compile a portion of crates.io. To maintain soundness they could make calling 2018 crates from 2019-nll an unsafe operation.

                                                                                  I think the right action depends how many crates they have obsoleted, which I don’t know. They should probably check and make it public, but I feel like they would rather not know.

                                                                                  1. 3

                                                                                    I think it might annoy and cause reputational damage when all they need to do is make edition 2019-nll to avoid breaking the ecosystem.

                                                                                    I dispute the assumption that they broke anything. Some code will stop compiling by default, but the old ways are just an option away. The warnings and the bold flashy lights is exactly what they have done. They have not broken your code, let alone permanently. Your code still compiles.

                                                                                    Sure, some users will get the warnings. Of course those users will file a bug. But your code still compiles, and will do for quite some time.

                                                                                    Any crate with unsafe in it already has as much risk as something that has been there for years and nobody noticed any problem

                                                                                    That’s just unsafe doing its job: a promise from the programmer that there isn’t any undefined behaviour, even though the borrow checker can’t verify it.

                                                                                    I think the right action depends how many crates they have obsoleted,

                                                                                    “Obsoleted” is such a strong word. I bet the changes required to fix the soundness errors in those crates will be minimal. I strongly suggest you take a look at your own crates, see where the new borrow checker got displeased, and do whatever is needed to please it again. This should be a quick fix.

                                                                                    1. 0

                                                                                      They have not broken your code, let alone permanently. Your code still compiles.

                                                                                      The warning specifically says they plan to stop it from compiling. Fine if it isn’t broken yet, but they told us the plan is to break things. They seem to have proposed adding these changes to edition 2015 to prevent even more code from compiling in the future.

                                                                                      I bet the changes required to fix the soundness errors in those crates will be minimal.

                                                                                      You also need to back port the changes to every major version release of your package to keep builds working for people depending on older API’s of your crates. Then you need to spend time testing each release, and publish them all. “Minimal” can quickly add up to an hour per crate., I don’t think all authors will do it, nobody is paying them to do it. Some probably don’t program rust anymore. It is just a loss for everyone.

                                                                                      “Obsoleted” is such a strong word. I bet the changes required to fix the soundness errors in those crates will be minimal.

                                                                                      Those crates simply won’t compile with newer versions of rustc 2018 edition without changes. The old versions just won’t work anymore without change, that sounds like obsoleting to me.

                                                                                      Anyway, obviously there are positives, like a lower maintenance burden so it isn’t totally bad.

                                                                                      1. 2

                                                                                        I don’t think all authors will do it,

                                                                                        I agree, they won’t. But I think it’s reasonable to assume that every single noteworthy crate will be addressed. The other can fall into oblivion like they would have anyway.

                                                                                        Those crates simply won’t compile with newer versions of rustc 2018 edition without changes.

                                                                                        The original post says: the 2018 edition of Rust […] has had NLL enabled ever since its official release.

                                                                                        It’s a new edition. If you don’t want to update your code, well, just put a note that you’re only Rust 2015 compatible. C++ broke compatibility in similar ways, by the way: remember how it hijacked the auto keyword ? Nobody complained, because everyone understood it was a major release of the language (and the auto keyword could easily be removed from old code).

                                                                                        And then there’s the migration mode, that allows you to take advantage of Rust 2018 even if you fall into one of those soundness bugs. Yes, they will turn it off eventually. But really, if you stopped maintaining your package, you are still using Rust 2015, and you will be fine. If you do maintain your package, well… what’s an hour per crate, really?


                                                                                        It is not possible, nor (I think) even desirable to add special cases to the NLL borrow checker so it is bug compatible with the old AST borrow checker. It doesn’t work the same way at all, and even if you could reach for bug compatibility, you’d still have a soundness bugs, and with it the possibility of data races or pointer invalidation in supposedly “safe” code. Is bug compatibility worth sacrificing correctness? Not in my book.

                                                                                        Then there are the benefits of the NLL borrow checker to begin with. Now pleasing the borrow checker will be much easier. Old complaints about it will likely fade away, and learning Rust will likely be less painful. Would you seriously sacrifice that just so you can be bug-compatible?

                                                                                        Make no mistake, this is bug compatibility we’re talking about. Breaking code that relied on a buggy version of the Rust compiler, and as a result were not as safe as rustc claimed it were. They did not remove any feature, they fixed a bug (several bugs, actually). Sucks that the bug lead rustc to accept unsound code, but it’s really really not the same as, say, removing support for some syntax sugar or whatever.

                                                                        2. 3

                                                                          Rust has been stable for a long time now, so the moving target you mention has long settled. And as /u/pkolloch mentioned, the breaking changes are just bug fixes essentially, and they are downgrading the errors to warnings for an indefinite time. You should definitely check the language again if you feel like it.

                                                                          1. 3

                                                                            I thought the same about Rust, but then I realized that it was only going to break things if I upgraded my toolchain. This wasn’t something where a “yum/apt/brew install” or even a rustup would nuke my existing binaries. Instead, it only applies to upgrading your toolchain.

                                                                            If the wrong version of python (2.6 instead of 2.7) is installed in a container or on a host I’m trying to use, I’ll see bugs or failures to run. God help me if I want to run Python 3 code. I hit that snag all the time.

                                                                            With Rust, that problem is more or less nonexistent. I use Python A LOT. However, I still see the merit of Rust on this front. I’ve seen and used @yonkletron’s work written in Rust in an incredibly risk-averse environment and I was quite impressed at how little I had to think about it compared to my own Python work.

                                                                            Rust may be less stable for me as a developer (and even that I’d question!) but it sure as hell seems pretty stable for me as an end user of apps written in it.

                                                                            1. 2

                                                                              It seems like it’s just a constantly moving target.

                                                                              It’s definitely pretty active. But IMO this particular case strikes me as fixing a compiler defect (permitting unsound code to compile). It was a defect not to emit an error for this case, IMO. Fixing defects that result in new errors is not instability from the toolchain, it’s a bugfix that Rust customers should welcome (even though fixing their bug is a prerequisite to accepting the new toolchain release).

                                                                              Maybe I didn’t quite read this article right but the fact that their 2015 example yields a warning that explicitly states that it was downgraded for compatibility makes it sound like the designation “will cause some existing code to break” is too pessimistic.

                                                                              1. 0

                                                                                They added warnings saying working code of mine in already released crates was going to stop compiling. I complained about it and nobody replied.

                                                                                To put it another way, rust already broke code in one of my ALREADY RELEASED crates WITHOUT AN EDITION CHANGE. It pissed me off so much.

                                                                                Not everyone has resources to go back and rewrite and retest code at their whims. In my opinion this change should be a strongly worded warning about potential unsafety + an edition change if they were serious about language stability. Don’t tell end users of my crate “hey, we might break your code maybe sometime, we don’t know when.”

                                                                                If by future versions, they meant “future editions” I would be much more okay with it.

                                                                                1. 2

                                                                                  If by “broke code”, you mean “emit warnings on newer versions of the compiler”, then maybe. What’s the crate? Where did you notify the developers (“complain”)? Are you sure the code is sound?

                                                                                  1. 0

                                                                                    Here is the issue, A report from a user of a released package:

                                                                                    https://github.com/andrewchambers/orderly/issues/20

                                                                                    Here is the complaint in the official thread for complaints of this issue:

                                                                                    https://github.com/rust-lang/rust/issues/59159

                                                                                    Are you sure the code is sound?

                                                                                    My reading of that issue is that it is sound, but inconvenient for them, but I don’t really care, they should do an emergency edition change for unsound code if the change isn’t backwards compatible. If code can’t last 6 months, what use is it? I want to write code that keeps working as when I wrote it for 20 years, 200 years if possible. They invented the edition system, why don’t they use it.

                                                                                    I don’t like how it is deemed ok to disregard small projects who put faith in rust.

                                                                                    1. 5

                                                                                      they should do an emergency edition change for unsound code if the change isn’t backwards compatible

                                                                                      No… Compiler bugs should be warned about once it becomes feasible to do so, with ample time before making them hard errors. Which is exactly what they’re doing… This looks like a great example of that system working. The warning drew your attention to your dependence on the compiler bug, and you fixed it the same day. All dependencies continued to compile, and assuming you released a patch version and yanked the previous version they always will.

                                                                                      If fixing any compiler bug required an edition bump, then the compiler would be riddled with bugs. Don’t pretend that you would prefer that.

                                                                                      1. 0

                                                                                        Now 0.1, 0.2,0.3,0.4 and 0.5 versions of my project on crates.io are useless junk. What is the point of them being there?

                                                                                        If my crate were a library this would also turn all crates depending on them into useless junk too. In my complaint I asked if they checked how many crates they are no only deprecating, but outright obsoleting.

                                                                                        If you also note, the issue I linked doesn’t say it is a soundness issue, just a mistake they made accepting things that makes some future changes more annoying for them.

                                                                                        1. 1

                                                                                          Traceability. Studying the history of the code. Reproducing the results if they download the needed version of Rust. Not too many practical reasons, though.

                                                                              1. 4

                                                                                musl libc: a project with no hype but huge impact musl libc is an alternative to GNU libc for Linux, created by Rich Felker, and with a healthy community of high-quality contributors. It’s been around for years, yet making less than V in donations.

                                                                                musl is super-great, without a doubt.

                                                                                In other, semi-related news: GOOG wants to add a libc to llvm, apparently for the sake of Fuchsia. It doesn’t sound like the initial scope is intended to match musl or glibc. But I wouldn’t be too surprised if it got there within a few years.

                                                                                I love to hate on GOOG for abandoning convenient service offerings, but they definitely do some good open source stuff. Andrew’s pledge to support musl (and others’ in-kind pledges) is/are laudable. But it’s good to know that there’s commercial support of open source projects, too.

                                                                                EDIT: lobsters discussion of the llvm libc here

                                                                                1. 3

                                                                                  It’s not for fuchsia; someone from fuchsia, apparently as an outsider, came in and said ‘that would be useful, can you make an aarch64 port?’

                                                                                1. 0

                                                                                  I think it’s a great effort, but I really dislike the impact sealed would have on the standard library, considering that the deprecation policy for stable things is already “never”, regardless of how broken things are (see env::home_dir).

                                                                                  1. 4

                                                                                    Considering the space we’re aiming at, libcore is more of our initial concern. Whether to ever even support libstd is a good question. Rust is fully capable of just using a different libstd replacement, which in such areas is highly likely. Public crate support is also rather unlikely.

                                                                                    I’m not sure what you are getting at with the deprecation policy, the usage of this function can be effectively avoided by setting the deprecation lint higher.

                                                                                    1. 1

                                                                                      I could make https://lib.rs show only “sealed-compatible” crates to users, and maybe even expose that as a cargo-compatible registry. Rust ecosystem already has stable vs nightly, std vs no_std subsets.

                                                                                      1. 2

                                                                                        Yep, all those things are options. Rust has always been about being the base for multiple ecosystems, so I see no conflict there.

                                                                                        (Is lib.rs currently okay? It seems to redirect to crates.io)

                                                                                        1. 1

                                                                                          (Is lib.rs currently okay? It seems to redirect to crates.io)

                                                                                          I was witnessing problems like these but it seemed to get better just now.

                                                                                  1. 7

                                                                                    From everything that I see on the sidelines, organizing community speakers in the tech scene seems really hard. I hear about people with really big heads, as well as people who then like to use their perceived clout to take advantage of others, professionally or otherwise. Then you’ll be getting people who have had to deal with this and are then jaded about it, and then the MRA and other trolls who will react, etc. Obviously this isn’t everyone, but yeah - seems really hard. I don’t envy organizers.

                                                                                    1. 8

                                                                                      I’ve organized community-run software conferences (read: not paid for by any one company or consortium) with 100 to 1,700 attendees yearly or more for seven years, and other events for 150+ people yearly since 2002, save one year that I took off to focus on finishing college. I’ve had a few things go awry but nothing ever this detractive, and hopefully I never will. I (really, we) take lots of precautions and stay up to date on the news around the events community.

                                                                                      The thing I ask the most of everyone involved – organizers, attendees, speakers, sponsors, vendors, security guards, union convention center workers, everyone – is to be kind. You can be firm. You can be loud or quiet. It’s difficult to understand all of the moving parts that make a conference happen. It’s difficult to empathize when something seems to be on fire. Assume the best intentions. Thank someone every chance you get. Criticism should be constructive or remain factual and kind when you have no suggestion to offer. Above all else, be kind.

                                                                                      1. 8

                                                                                        We did a mistake. We did not take enough precautions. People that worked with me knew about other issues that this people had. This year I wasn’t in the details of checking every speaker. I should have asked people if the speakers had any big issue with anybody before.

                                                                                        1. 3

                                                                                          don’t blame yourself; any other day and in any other situation your actions would be reasonable.

                                                                                          1. 0

                                                                                            This might be a stupid idea but have you considered re-engaging these (obviously hostile, childish) people and asking them what would satisfy them? Could there be some kind of compromise or would they only accept re-enstatment as a conference speaker and your sincere apology🙄🙄🙄?

                                                                                            It might be crazy to consider “giving in” like this but I wonder if maybe they might be more reasonable with face-to-face dialogue. AFAICT it’s probably harmless to try.

                                                                                            1. 1

                                                                                              Sure, we did think about that and we are still trying to do it. I have no problem to “give in”. I only want this to stop and continue doing productive things. On the long run with the legal justice I think things will get better. In the meantime: https://twitter.com/unbalancedparen/status/1131214746731077632

                                                                                          2. 2

                                                                                            This makes sense. And I wouldn’t be surprised if most conferences don’t have this behavior, the news is only filled with news-worthy things (so I only hear about the bad cases). It sounds like you treat this thoughtfully, which is really awesome.

                                                                                        1. 12

                                                                                          I recently introduced a subtle bug in a C++ codebase by failing to hold a union just right. The code misbehaved confusingly. It actually crashed clang’s ASan. Once I worked out WTF was going on I understood why it was doing what it was doing but until then it was mysterious, subtle and frustrating.

                                                                                          1. 18

                                                                                            There is a palpable sense that the entirety of the existing C++ tooling can barely manage to keep it’s head above the water.

                                                                                            1. 2

                                                                                              It actually crashed clang’s ASan.

                                                                                              Meaning that the compiler crashed but only with -fsanitize=address? Can you share more details about this?

                                                                                              1. 1

                                                                                                No, it crashed at runtime in the asan runtime instead either telling me what was wrong. Without asan it just kept going with corrupted state and crashed later. So asan sort of helped…

                                                                                            1. 1

                                                                                              Matplotlib has always been great but seaborn has higher-level abstractions that make some graphs and showing relationships much easier. Since seaborn layers on top of matplotlib, you can still leverage some of the detailed matplotlib knobs when seaborn alone can’t quite tweak the presentation just as you’d like.

                                                                                              1. 7

                                                                                                I recommend against anybody using seaborn, for reasons I’ve stated before here

                                                                                                Edit: Looks like the developer has gone so far as to delete the issue. Even more reason to avoid IMHO.

                                                                                                1. 4

                                                                                                  I actively considered & was urged to include Seaborn in this post. But on closer look I could not immediately provide the intended user with any advantages based on Seaborn. I tried to find a plot based on the datasets in the post where Seaborn would shine, but couldn’t find anything.

                                                                                                  1. 1

                                                                                                    Looks like the developer has gone so far as to delete the issue. Even more reason to avoid IMHO.

                                                                                                    I agree: assuming your description of the situation and the HN comments are all accurate, it doesn’t look good for the project’s maintainer(s).

                                                                                                    I would charitably assume that mwaskom mistakenly assumed your question was a misunderstanding of how seaborn/matplotlib works. And just maybe it’s the intended design. It looks as if mwaskom is particular about sweeping GH issues, so I could expect that he may have overlooked the importance of the issue that you identified. Maybe I’m bending over backwards here but – Hanlon’s razor – he may have deleted the issue because he recognizes that it makes him look rash or foolish and he’s embarrassed by the error.

                                                                                                    I don’t think I’d stop using seaborn over this, but I will certainly evaluate its output much more critically now that you’ve brought it up.

                                                                                                1. 6

                                                                                                  I always find it annoying when existing concepts (pipes/fifos) are renamed (channels).

                                                                                                  Are Cox, Pike et al involved in the project at all?

                                                                                                  1. 9

                                                                                                    I don’t know all the details about channels but it’s clear that they’re not the same as pipes/fifos. For one thing, it seems like it takes discrete messages and not a stream.

                                                                                                    1. 0

                                                                                                      That just means they are slightly less flexible than pipes/fifos, and I’m not sure why. Isn’t sending data “as it’s received” over a “channel” still a valid usecase?

                                                                                                      So once again, the wheel is reinvented in a worse way than before with no reason for doing so…

                                                                                                      1. 9

                                                                                                        I’m not sure why.

                                                                                                        Exactly. I don’t think you should rush to judgment on this one. I don’t know the answer but a good way to find out would be to ask the developers or use the source.

                                                                                                        no reason for doing so…

                                                                                                        Do you have to trap to send data on a channel? If not, it could be a lot more efficient than pipes are.

                                                                                                        1. 0

                                                                                                          OK, so then the analogy is a UNIX domain socket, not a pipe/FIFO. It still does not make a ton of sense that you can’t send stream data over them…

                                                                                                          1. 2

                                                                                                            I just RTFM’d a bit on channels and it seems to have very specific semantics which distinguish it from other IPC.

                                                                                                            I think it makes sense to have the features that channels do – they help satisfy the microkernel design and the partitioning/encapsulation of the different OS functions while hopefully not introducing significant overhead beyond what a monolithic kernel would have.

                                                                                                        2. 1

                                                                                                          Exactly. I don’t think you should rush to judgment on this one. I don’t know the answer but a good way to find out would be to ask the developers or use the source.

                                                                                                          Why worse? If a message is a single thing, then you don’t need to worry about PIPE_BUF size when sending? Could you not just send a stream of 4096 sized byte arrays to get a pipe?

                                                                                                    1. 3

                                                                                                      I recently upgraded and moved all of my networking and server equipment into a half-rack:

                                                                                                      I am simultaneously jealous/in awe of this setup and relieved that I don’t have it. It looks really cool and well organized. But I always found myself spending a lot of time keeping things like a ddWRT config and dyndns working. It was never quite robust (so maybe I should’ve invested yet more time).

                                                                                                      IMO UVerse’s stock router/AP is better than many previous generations stock-ISP gear. Both in terms of performance and reliability.

                                                                                                      USRobotics Total Control NETServer 8-modem chassis for my BBS

                                                                                                      This part takes the cake, a USR modem bank for a BBS‽ Man, who knew this was still kicking? Is there modern BBS software, or are we still using stuff like PCB/WWIV?

                                                                                                      1. 1

                                                                                                        spending a lot of time keeping things like a ddWRT config and dyndns working

                                                                                                        I’ve been using ddWRT for years on routers and have never had to do anything beyond the initial setup and the occasional update, do you mind if I ask what sort of things happened that required maintenance?

                                                                                                      1. 10

                                                                                                        The comment section on the linked post is is full of people getting upset at the very idea of someone not liking Rust. Never seen that before…

                                                                                                        1. 10

                                                                                                          Never seen that before…

                                                                                                          It seems common enough to me. At least I have seen it in action plenty of times, especially over on HackerNews. There is even a joke/moniker for it: “Rust Evangelism Strike Force”. People tend to get very worked up and defensive about things they like I suppose.

                                                                                                          Do note that it definitely seems, based on what I have read, that such behavior is generally frowned on by the Rust team itself. It also /maybe/ doesn’t seem quite as prevalent as it used to? Not sure.

                                                                                                          1. 4

                                                                                                            Yes, there is an ongoing significant effort by many of the people in the Rust community to actively work against aggression. There are a lot of messages happening behind the scenes on the platforms that support it where people will be asked to use language that will be more welcoming.

                                                                                                            1. 5

                                                                                                              Yeah I was being sarcastic :)

                                                                                                              Do note that it definitely seems, based on what I have read, that such behavior is generally frowned on by the Rust team itself.

                                                                                                              Given that people like Steve Klabnik do it on reddit all the time, I doubt that’s the case

                                                                                                              1. 10

                                                                                                                Steve can often be seen disagreeing with things he views as mischaracterizations, usually in a pretty respectful way. I can’t think of an example of him being upset that someone didn’t like rust though.

                                                                                                                I think people sometimes get the impression that he is on the RESF because he can be seen engaging everywhere, but he’s really advocated strongly for NOT doing what you describe. If you’re everywhere, you tend to get associated with the people who might seem to be “on your side” even if they are going about that in a way that you really disagree with. I don’t think Steve would consider people on the RESF to be on his side at all, though.

                                                                                                                1. 2

                                                                                                                  Well, also cuz it was his job to be everywhere promoting it. All the community team members have publicly denounced the kind of behavior in that comment thread, though. They know it’s not good for their goals. Certainly not coming from them. Just Internet as usual.

                                                                                                            2. 6

                                                                                                              I’ve seen it often enough that I don’t bother talking about Rust any more.

                                                                                                              I’m a C++ developer, but I keep an eye on Rust and Go just to stay up on what’s going on in “systems languages”. I’ve mentioned several times that I don’t see a big advantage to using Rust, since I already know C++ well enough to avoid most of the errors Rust solves. Valgrind, Coverity, and newer C++ features like shared_ptr can eliminate a lot of the errors that Rust tries to solve.

                                                                                                              But according to some Rust zealots, there’s no way that’s true, and the mere fact that I’ve suggested it means I’m ignorant to the problem and I’m causing buffer overflows left and right.

                                                                                                              EDIT: Too early, took me a minute to notice it’s sarcasm

                                                                                                              1. 3

                                                                                                                newer C++ features like shared_ptr can eliminate a lot of the errors that Rust tries to solve.

                                                                                                                unique_ptr is slightly harder to misuse, IMO. shared_ptr preserves the ownership quandary that Rust helps mitigate.

                                                                                                                Undefined behavior is everyone’s nemesis, IMO. UBSan helps but

                                                                                                                I already know C++ well enough to avoid most of the errors Rust solves

                                                                                                                And so you probably know it well enough to recognize the bugs you’ve introduced when you’ve spent some time debugging an issue.

                                                                                                                Valgrind, Coverity, and …

                                                                                                                IMO if you value static checkers like Coverity’s, then it stands to reason that you might like a Sufficiently Smart Static Checker. But if C/C++ had to be constrained to a subset of the current language in order to give that Sufficiently Smart Static Checker the additional context it needed to find bugs, would you still find it interesting? If the answer’s “yes”, then it seems to me like Rust isn’t far from what you’d get from a constrained C++. If the answer’s “no” then maybe C++ is ideal for your use.

                                                                                                                cargo and the crates infrastructure is Rust’s big win, in my opinion. Safety features are just the entrance criteria for a new language.

                                                                                                                1. 1

                                                                                                                  I’m not a Rust zealot, but I settled on the default approach of “if you are using C or C++ for new things in 2019, there is something going horribly wrong; but I’m open to hear the reasoning to convince me otherwise”.

                                                                                                                  Nothing is worse than C/C++ developers thinking they understand their language, despite a million man-decades of evidence pointing to the exact opposite.

                                                                                                                  1. 6

                                                                                                                    There is a difference between knowing it well enough to write a compiler compliance suite, and knowing it well enough to quickly deliver business value.

                                                                                                                    Please do not keep parroting the same “C/C++ is evil” meme, and certainly don’t lump them together.

                                                                                                                    1. 3

                                                                                                                      The only difference is whether the result of not knowing it well enough will kill people or just slightly reduce some business value (isn’t it crazy how C and C++ have trained the general populace to not even expect programs to be reliable?).

                                                                                                                      Please do not keep parroting the same “C/C++ is evil” meme, and certainly don’t lump them together.

                                                                                                                      It took people a few decades to figure out that smoking kills, so regardless of whether you consider it “evil”, I hope that in the future C++ compilers ship with mandatory shock pictures that show the consequences of using C++.

                                                                                                                      1. 3

                                                                                                                        isn’t it crazy how C and C++ have trained the general populace to not even expect programs to be reliable?

                                                                                                                        Please provide evidence for such big claims. As a personal anecdote, I have to deal with much more unreliability caused by Java software than by C/C++.

                                                                                                                    2. 1

                                                                                                                      FWIW, this is exactly the type of response I was talking about. You’re right, obviously I have no idea what I’m doing.

                                                                                                                      I’m not interested in this tedious argument, so I won’t be replying again.

                                                                                                                  2. 2

                                                                                                                    Yeah, there were some assholes in there. They should knock it off given it’s certainly not doing any favors for Rust adoption or even making new friends who work on cool projects like Dust3D.