Announcement

Collapse
No announcement yet.

Wine-Staging 8.18 Brings Patch For An 8 Year Old Bug Report

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    This is almost a joke at this point!!!

    People have been claiming for years that open source is supposedly superior because bugs and vulnerabilities are found and fixed fast, but you have curl with a 2 year old vulnerability, this thing with an 8 year old bug, that other thing with a 35 year old vulnerability, Gnome had a memory leak for 10 years, the list goes on.

    My question to the Linux faithful is this, after all these bugs that have existed for years have come to light, how can you still propagate the myth that open source is superior?

    Comment


    • #22
      nice, always glad to see old bugs quashed, anyone who thinks that wine has bad management because there are a lot of patches between version numbers, or because there are old bugs, are quite frankly missing the point entirely. squashing old bugs is absolutely nothing new, low priority bugs are low priority for a reason.

      Comment


      • #23
        Originally posted by sophisticles View Post
        People have been claiming for years that open source is supposedly superior because bugs and vulnerabilities are found and fixed fast, but you have curl with a 2 year old vulnerability, this thing with an 8 year old bug, that other thing with a 35 year old vulnerability, Gnome had a memory leak for 10 years, the list goes on.

        My question to the Linux faithful is this, after all these bugs that have existed for years have come to light, how can you still propagate the myth that open source is superior?
        Fast does not have a fixed meaning. You have to remember bugs have different levels of critical. This is a bug with Wine that was known for 8 years and is not a vulnerability. This is case of 8 years not implementing something application goes and attempt to use the not implemented bit instant death. Some bugs stick around in open source for a long time because

        Yes problem effecting exactly 1 program no one else ever reported the same problem with any other program.

        35 year old vulnerability that X.org X11 server. There has been lots of write ups that X.org X11 server is insecure and we should not be using it. This is example we know there is security faults but then not investing the time to in fact fix them.

        Something to remember due to open source having public records of code changes this is how faults could be tracked back to be introduced 2, 10, 35 years ago.

        Something to remember you have old bugs like the wine ones that have been known for a long time and just classed not important enough to fix.

        Then you have faults that were only detected recently that have been in the code base for quite some time like the X11 bug and the curl bug that are only found because the source is open source so people can look at the code using newer tools and newer training.

        The idea that open source is superior is not that bugs don't exist. Fast is normally written as faster than closed source. Closed source software having faults for decades is in fact nothing strange. So the time frames you are talking about are not that large when it comes to software problems.

        Think about it open source knows fairly quickly how many years/decades a problem being around due to open source. Now closed source this is normally more painful process particularly with cases where closed source application source code archive has been deleted.

        See where your found and fixed fast is kind right in one light.
        1) How long have we had the major fault is answered fairly quickly if you have source code to go back and look how long the defect has been there,
        2) Fix is possible with your own staff with open source code.

        Closed source you found fault you may not have the source code to fix it and the company that made the software might be out of business. Having to spin up old OS versions to run the old binaries to find out if they have X and Y fault is very time consuming compared to be able to dive into source code archive looking for the defective code.

        Remember knowing point 1 is critical to know what systems you have to fix when a major fault is found. Point 2 is equally important to be able to

        Found you would not be thinking its not just finding the bug but knowing the effected items is key information. Closed source lot harder to get this.

        Comment

        Working...
        X