The number of reported security vulnerabilities has gone up drastically. And so has the frequency, number, and volume of security patches. Which also makes the gap between fully supported distributions and ones with only partial security support larger. (Not every distribution provides full security upddates for the full announced life time of a release.)

How are you folks reacting to this?

  • thingsiplay@lemmy.ml
    link
    fedilink
    English
    arrow-up
    2
    ·
    23 hours ago

    Amount of bugs is finite.

    Resources are also finite. You can’t proof the absence of bugs, you can only proof the existence of it.

    Did you know, there are more ways to arrange a deck of cards than there are atoms on Earth. A standard deck has only 52 cards. Now imagine how many possibilities are there to have bugs in a code like the Linux Kernel. Just because something is finite does not mean we will ever reach that point.

    • truthfultemporarily@feddit.org
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      22 hours ago

      You can absolutely prove the absence of bugs via formal verification.

      The card example does not really make sense because the kernel is not a random set of syntax and bugs do not happen randomly. They usually happen because a dev overlooked a use after free or buffer overflow. Well we now have software really good at finding these things, as well as system languages that cannot have these bugs.

      If bugs are closed faster than they are opened, the total amount goes down. For orientation: around 25% of all CVEs ever published were published this year. That means around 6x more bugs were fixed this year than in the other years. I don’t think the kennel gained that amount of additional bugs.

      • thingsiplay@lemmy.ml
        link
        fedilink
        English
        arrow-up
        3
        ·
        22 hours ago

        You can absolutely prove the absence of bugs via formal verification.

        You can’t have a formal verification for an open ended system like the Linux Kernel. You can only have that with extremely narrow defined functions that only operate mathematical and the input and output are 100% deterministic. Someone has to make the test cases, and to my knowledge its not possible to do this with complex systems like the Linux Kernel.

        The card example does not really make sense because the kernel is not a random set of syntax and bugs do not happen randomly.

        It makes sense, because it proofs my point that a finite number is irrelevant if its that big. The randomness of it is absolutely not the point, its the sheer amount of possibilities.

        Well we now have software really good at finding these things, as well as system languages that cannot have these bugs.

        No software can test a complex system like this in its entirety to make sure there are no bugs. Those software itself need to be perfect themselves too. Therefore you introduce enormous complexity in solving bugs, which itself can have bugs.

        If bugs are closed faster than they are opened, the total amount goes down.

        I wasn’t arguing against that. I am arguing that a finite number of bugs is not a good argument to have none in the future. Because of the sheer amount of possibilities, and also because we cannot proof that Linux Kernel is perfect without any bugs. It is impossible.