• undu@discuss.tchncs.de
      3·
      1 month ago

      There’s time until March for the maintainers of the 3 niche architectures to organize and make rust available for them. Doesn’t sound that abrupt to me

    • LeFantome@programming.dev
      2·
      1 month ago

      The timeline is not super abrupt, especially for architectures where all he is asking is to ensure that your Rust toolchain is in order. That is especially true when you consider that Rust is already well maintained on all the Debian architectures that people actually use.

      The abruptness (almost rudeness) is in the second part where he basically says that, if you cannot get Rust going in time, you should just stop releasing Debian for that architecture.

      It is mostly just poorly worded though. Because none of these architectures have “official” support even now. This will not be the only way they are behind. So, there is not reason to be so dramatic.

      And that would be my response to him. Another option here is that these alternative architectures just continue to ship an older version of APT for now. Emergency avoided. Few of them ship with up-to-date versions of APT even now.

      Another solution is to use one of the multiple projects that is working to make Rust code build with the GCC compiler back-end. At least one of these projects has already announced that they want to work with these Debian variants to ensure that APT builds with them.

      So, the 6 month timeline is a reasonable impetus to make that happen which would be quite a good thing beyond just APT.

      There are many other useful tools written in Rust you are going to want to use on these architectures. It will be a fantastic outcome if this pressure from APT kickstarts that happening for some of these long abandoned architectures (by the mainstream at least).

    • ZoteTheMighty@lemmy.zip
      1·
      1 month ago

      For package maintainers, it’s reasonable to expect security updates are rolled out the same week that a vulnerability is found. If you can’t deploy a new version of a package in 6 months, not maintaining the package is also a valid option.

      • aubeynarf@lemmynsfw.com
        2·
        1 month ago

        how many compiler back doors have we seen versus use-after-free/stack overflow attacks?

        The anti-Rust crowd baffles me. Maybe C++ has rotted their brain to the point they can’t “get” the borrow checker.

        My only complaint is that its syntax is an ugly mishmash. Should have copied scala or f#

        • Shanmugha@lemmy.world
          01·
          1 month ago

          More like Rust has rotted someone’s brain. “Hey, I can’t code safely, so I will use this new toy that is supposed to make me”. This line of thought is OK as long as it does not get imposed on anything I do as a programmer

          • LeFantome@programming.dev
            1·
            1 month ago

            The industry cannot code safely. There are many reports, studies, and corporate disclosures highlighting that memory related bugs are the primary source of critical security issues in C and C++ code. That is why even NIH companies like Google and Microsoft are adopting Rust in their core products.

            That you want to publicly ignore all that evidence to paint it as an individual skill issue does not come across as competent or intelligent. Few of us are going to assume your code is free of these kinds of bugs.

            The fact that your have to say it so dismissively makes me think that you know it too.

            • Shanmugha@lemmy.world
              01·
              1 month ago

              Things are much simpler:

              1. Want a bug free code - do bug free code. Spend time carefully evaluating every line and interaction

              2. Want third-party code and safety - examine that code in the same way

              3. Whatever you do, assume there is a bug in any software you use, so plan and organize accordingly

              4. No amount of magic pills can substitute the above. So yeah, it is a skill issue. Also an issue of kids wining that there are bugs and they don’t feel safe, so they want to cling to magic pills instead of dealing with the reality

              • DeltaWingDragon@sh.itjust.works
                1·
                26 days ago

                It’s not a “magic pill”, it’s another tool. We’re not saying that it will magically fix everything, it will just make certain types of errors less probable.

                If you want bug-free code, will you (A) use a tool that makes it easier, or (B) use the same tool as before?

                “Skill issue” is not an answer.

                • Shanmugha@lemmy.world
                  1·
                  26 days ago

                  Wrong reasoning, friend:

                  Maybe C++ has rotted their brain to the point they can’t “get” the borrow checker.

                  Yeah, sure. Borrow checker fixes all. This is exactly the idiot attitude I am addressing.

                  And if I want a bug-free code, I will use same tool as ever: my brain

                  • DeltaWingDragon@sh.itjust.works
                    1·
                    26 days ago

                    I am not the person who said “C++ has rotted their brain”. I have not expressed a similar sentiment. I have never said that “borrow checker fixes all”, in fact I said that it will not magically fix everything.

                    And if I want a bug-free code, I will use same tool as ever: my brain

                    Is your brain infallible?

                    The strategy is not to 100% eliminate every bug in existence or theory, bugs are inevitable. The strategy is Swiss cheese security.

                    Something is better than nothing. Therefore (brain + something) > (brain + nothing). As long as “something” works to prevent bugs, to any extent, it will result in fewer bugs.