• lambalicious@lemmy.sdf.orgEnglish
    1·
    3 days ago

    So thats why whenever I try to find a package in apt, I have to iterate through thousands of simiparly named librust-{dictionaryword}-{component}-dev packages in order to find the simple component I want… Apt repos have really been trying too hard for granularity, I’m pretty sure there are more librust áckages than actual end-user program packages.

    • Matriks404@lemmy.world
      1·
      2 days ago

      Yeah, it’s pretty good. But now that I’ve started studying, and don’t have time for learning it (I’ve literally made a personal wiki with various documentation for myself), so I am thinking to switching to atomic distro instead (maybe KDE Linux).

    • LeFantome@programming.dev
      3·
      2 days 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·
      3 days 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.

    • undu@discuss.tchncs.de
      2·
      4 days 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

    • whoever loves Digit@piefed.socialBanned from communityEnglish
      01·
      4 days ago

      Rust adds another layer of trusting the compiler isn’t backdoored. All UNIX/Linux systems use the gcc toolchain, so having it written in C would mean less dependencies for the OS.

      Strange times.

      • aubeynarf@lemmynsfw.com
        1·
        3 days 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·
          3 days 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·
            2 days 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·
              2 days 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

        • whoever loves Digit@piefed.socialBanned from communityEnglish
          0·
          3 days ago

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

          Who cares? Why do you ask?

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

          I can’t code, so C++ doesn’t have much space in my brain, but Rust still seems a lot more sus to me than C.

          • aubeynarf@lemmynsfw.com
            0·
            3 days ago

            You care, you are the one that brought it up as an issue with rust.

            I ask as a rhetorical question to shed light on the fact that compiler back doors are a vanishingly small fraction of total security exploits, while the memory bugs that rust specifically addresses make up the vast majority.

            • whoever loves Digit@piefed.socialBanned from communityEnglish
              0·
              3 days ago

              You care

              About random numbers? Not really

              you are the one that brought it up as an issue with rust.

              Are you referring to where I said “I want to know some random numbers Rust isn’t giving me, and that’s a problem with Rust?”

              Because that was in your imagination.

              Or are you referring to where I said “Rust wants to know some random numbers it isn’t giving itself?”

              Because that was also in your imagination.

              In reality, I brought up that I’ve heard Rust adds another layer of trusting the compiler isn’t backdoored.

              • aubeynarf@lemmynsfw.com
                0·
                3 days ago

                While you’re spouting nonsense, this is happening:

                https://www.infoq.com/news/2025/11/redis-vulnerability-redishell/

                The vulnerability exploits a 13-year-old UAF memory corruption bug in Redis, allowing a post-auth attacker to send a crafted Lua script to escape the default Lua sandbox and execute arbitrary native code. This grants full host access, enabling data theft, wiping, encryption, resource hijacking, and lateral movement within cloud environments.

                13 years. That’s how long it took to find a critical safety vulnerability in one of the most popular C open source codebases, Redis. This is software that was expertly written by some of the best engineers in the world and yet, mistakes can still happen! It’s just that in C a “mistake” can often mean a memory-safety bug that would put user data at risk (…) That’s the nature of memory-safety bugs in C: they can hide in plain sight.

                • whoever loves Digit@piefed.socialBanned from communityEnglish
                  0·
                  3 days ago

                  While you’re spouting nonsense

                  I’m the guy you were replying to here. I’m not spouting any nonsense in this thread. Did you reply to the wrong person, or is this a false accusation?

                  this is happening:

                  https://www.infoq.com/news/2025/11/redis-vulnerability-redishell/

                  The vulnerability exploits a 13-year-old UAF memory corruption bug in Redis, allowing a post-auth attacker to send a crafted Lua script to escape the default Lua sandbox and execute arbitrary native code. This grants full host access, enabling data theft, wiping, encryption, resource hijacking, and lateral movement within cloud environments.

                  13 years. That’s how long it took to find a critical safety vulnerability in one of the most popular C open source codebases, Redis. This is software that was expertly written by some of the best engineers in the world and yet, mistakes can still happen! It’s just that in C a “mistake” can often mean a memory-safety bug that would put user data at risk (…) That’s the nature of memory-safety bugs in C: they can hide in plain sight.

                  Why did you make me read these paragraphs without explaining how they connect to the context? Let me guess: they don’t connect to the context, you’re just designing your replies to mislead people dumb enough to be vulnerable to your manipulation tactics? With no consideration for me whose time/energy you’re wasting, much less them who you’re confusing?

    • N.E.P.T.R@lemmy.blahaj.zoneEnglish
      1·
      3 days ago

      You can think yhat Wayland adoption was artificial, bit X.Org is unmaintained software and no developers are picking up reigns of X11. X is dead.

    • mmmm@sopuli.xyz
      1·
      3 days ago

      Uhm, what?

      Wayland has been in the works for more than a decade. Granted, there’s some people having issues with it, with propietary hardware (nVidia) and not-so-common setups like two monitors, but it happens that they are the most noisy. For the rest of us it’s been great, stable, and feels snappier than X.

      If you want to talk about shoehorning stuff into Debian, talk about systemd.

        • Yoddel_Hickory@piefed.caEnglish
          1·
          3 days ago

          I assume “weird two-monitors setups” that are not so common, not two-monitor setups as a whole, as Wayland works perfectly with two monitors. It even works way better than X11 if your monitors are different, like if only one has VRR or if both monitors need different scaling.

  • Mwa@thelemmy.clubEnglish
    0·
    3 days ago

    Maybe cause Apt is slow?
    edit: maybe i have a placebo effect or i am miss remembering :P

    • BillyCrystalMeth@slrpnk.net
      1·
      3 days ago

      Apt feels like one of the faster package managers. dnf is slow, yum is snail speed, zypper is slow as fuck too. Apt and Pacman is by far on the faster side

      • timbuck2themoon@sh.itjust.worksEnglish
        01·
        3 days ago

        Dnf5 is absolutely not slow.

        Moreover, apt’s output is God awful. How hard is it to put each package on its own line when doing an upgrade? Its commands are also esoteric (Madison?)?

        It works and I like Debian but apt is very Meh.

      • LeFantome@programming.dev
        1·
        3 days ago

        Rust is generally not going to outperform well optimized C code.

        That said, it is far easier to write performant Rust code than C code. So, what we see, is that projects that move to Rust frequently see performance gains.

        That just means the initial C code was not that great (performance wise). From observation, most C projects are fairly unoptimized.